これまで、googlebotを許可するためにAS15169を許可していた。

Googlebot (AS15169)

echo “? - Fetching Googlebot ranges (AS15169)…”

whoisの出力を直接一時ファイルにリダイレクト

timeout 60 whois -h whois.radb.net -- ‘-i origin AS15169’
| grep -Eo ‘([0-9]{1,3}.){3}[0-9]{1,3}/[0-9]+’ » “$TMP_IPLIST” || true

これだと、下記のようにbc.googleusercontent.comからのスキャンを通してしまう・・・

162.15.169.34.bc.googleusercontent.com - - [18/Dec/2025:16:27:32 +0900] “GET //wp-includes/wlwmanifest.xml HTTP/1.1” 404 501 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4240.193 Safari/537.36”
162.15.169.34.bc.googleusercontent.com - - [18/Dec/2025:16:27:32 +0900] “GET //xmlrpc.php?rsd HTTP/1.1” 404 500 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4240.193 Safari/537.36”
162.15.169.34.bc.googleusercontent.com - - [18/Dec/2025:16:27:32 +0900] “GET / HTTP/1.1” 200 897 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4240.193 Safari/537.36”

■ はじめに：なぜDNS-01認証なのか
通常、Certbotでよく使われるのは80番ポートを利用した http-01 認証（ACMEチャレンジ）だが、本環境ではセキュリティ対策として 80番ポートおよび443番ポートへのアクセスを国内限定に絞っている。

Let’s Encryptの認証サーバーは海外からもアクセスしてくるため、この制限下では通常のWeb認証が通らない。
そこで、ポート開放状況に左右されずに証明書を発行・更新できる DNS-01チャレンジ を採用した。

また、ハニーポット（迷い込み用サイト）運用において、あえて正規ドメイン（sky.0t0.jp）用の証明書をハニーポット側にセットすることで、アクセス者に「ドメイン不一致の警告」を見せ、意図的に隙があるように演出している。
この正規証明書の更新プロセスを自動化した際の記録。

■ 1. 構築環境と課題
・対象ドメイン: sky.0t0.jp, deepsky.0t0.jp

・手法: Certbotの manual モード ＋ MyDNS DirectEdit（PHPスクリプト）

・直面した課題: certbot renew を実行すると、設定ファイル (.conf) に dns と記述していても、なぜかhttp-01 認証（Web 経由のチャレンジ）を試行してしまい、更新に失敗する。

■ 2. なぜ設定ファイルの記述だけでは不十分なのか
検証の結果、Certbotの仕様による以下の挙動が原因であることが判明した。

・設定ファイルの限界: /etc/letsencrypt/renewal/xxx.conf 内に preferred_challenges = dns と書いても、コマンドライン引数で明示的に上書きしない限り http-01 認証が実行されてしまう。
Certbot 1.12.0 では、renew 実行時に認証方式が明示されていない場合、manual 認証であっても http-01 が選択される挙動が確認された。
renewal 設定ファイル内の preferred_challenges = dns だけでは、この挙動を抑止できないケースがある。

・解決策: challenge 選択の曖昧さを回避するため、実行コマンド側に直接オプションを付与する必要がある。

■ 3. 運用のポイント：certbot.timer に頼らない自動化
certbot.timer はディストリビューション標準の ExecStart 設定で certbot renew を実行するため、
認証方式を上書きするオプションを注入できない。
そのため、上述した「履歴優先」の仕様によって http-01 に戻ってしまい、DNS-01認証が動かない。

しつこい嫌がらせアクセスが止まらない原因の一つは、こちらも暇に任せて相手の動きを弄んでしまったことかもしれない（笑）

このままでは延々終わりそうにないので、もう無視する方針に転換。
アクセスがほぼゼロになるのは寂しいが、なんとか我慢してDNATでのサーバー公開を 国内限定 にして放置することにした。

・jpnet（国内IP）だけを 80/443 に許可
・Google / Bing など主要検索エンジンは個別に許可
・25 / 587 / 993（メール関連）だけ国外からも許可
・FireHOL level1/2/3 は DROP
・SMB / NetBIOS / port111 などは完全遮断

問題は……
「アクセス激減」をどこまで我慢できるか。
結局は自分との闘いである（笑）

今回は、FireHOL の不正アクセス判定（firehol_level1～3）を軸にした 「シンプルかつ堅牢」な iptables の実例を紹介します。

最終的には、“iptables は FireHOL の結果を DROP するだけでよい”という構成に落ち着きました。

以下は最終的なルール（INPUT / FORWARD / OUTPUT）と、その解説です。

Chain INPUT（デフォルト DROP）

1 ACCEPT state RELATED,ESTABLISHED
2 ACCEPT in br0
3 DROP match-set firehol_level1 src
4 DROP match-set firehol_level2 src
5 DROP match-set firehol_level3 src
6 ACCEPT udp dpt:500
7 ACCEPT udp dpt:4500
8 ACCEPT in lo

● 解説

FireHOL の3段階ブロックを上から順に DROP
軽度 → 重度 の攻撃元を自動的に分類し、自動的に遮断。

LAN（br0）は信頼区画として全許可。

IPsec（500/4500）と lo を明示的に許可。

INPUT は “FireHOL + 必要最小限の許可” に徹しているため、無駄がない構成です。

先日iptablesの制限を強化したところ、公開サーバーのアクセスが極端に少なくなり、面白みに欠ける状態になったため、今回一部緩和しました。

・ブログ「海辺の放浪記」の公開停止
その代償として、20年以上続けていたブログ「海辺の放浪記」は、特定者からしつこくアクセスされ、古い記事まで大量に取得される動きがあったため、公開停止としました。

「海辺の放浪記」は既に更新を停止し、当ブログに引き継いでいます。
この公開停止には、過去をきっぱり忘れるという意味も込めています。

・iptables 運用の本質は「観察」
設定を見直していて改めて気づいたのですが、私にとってブログ等を公開するよりも、毎日ログを読むことが最も重要な目的だったのだと理解しました。

今回の記事は、その “観察対象” でもある iptables の現行フィルタリングルールを、番号ごとに解説した備忘録です。

・INPUT ルール解説
既存通信 (RELATED, ESTABLISHED) の全面許可

戻りパケットはすべて通す。基本中の基本。

LAN（br0）からのアクセスを許可

LAN 内は信頼できるため、広めに許可。

FireHOL Level1?3 の悪性 IP の DROP (ルール3?5)

ppp0（WAN）からのアクセスをチェックし、ブラックリストに載っている IP を即時 DROP。
ここは今後も厳格に運用します。

IPsec（UDP 500 / 4500）の許可 (ルール6?7)

VPN 用。必要最低限のポートのみ開放。

lo（ループバック）の許可 (ルール8)

ローカルプロセス連携に必要。

・FORWARD ルール解説（要点のみ）
RELATED, ESTABLISHED の許可

FireHOL IP を br0 側へ通さない (ルール2?4)

Windows ファイル共有（137?139 / 445）や portmap（111）を完全ブロック (ルール5?10)

LAN 192.168.1.0/24 → ppp0 の通信を許可 (ルール11)

jpnet（日本のアドレス帯）からの SSH を許可 (ルール12)