公開サーバーの守りを固める ― DMARC を quarantine に、xmlrpc.php を閉じ、fail2ban で WordPress のログイン失敗を締め出す
AWS に置いている公開サーバー（ブログとメール）の守りを、3つ固めました。メールのなりすましを迷惑メール扱いにする、WordPress の総当たりの入口を1つふさぐ、ログイン画面への失敗が続く相手を自動で締め出す、の3つです。どれも「家の中の機器には関係なく、外から見える場所だけ」の変更です。
- DMARC：自分のドメインを名乗るメールが本物か確かめる仕組み。確かめられなかったメールの扱いを、受け取る側に指示できる
- xmlrpc.php：WordPress を外のアプリから操作するための入口。1回の通信で何度もパスワードを試せるため、総当たりに使われやすい
- fail2ban：記録（ログ）を見張って、失敗が続く相手をファイアウォールで一定時間締め出す道具
1. DMARC を「none」から「quarantine」に
メールを新しいサーバーに移したとき、DMARC は様子見の p=none（確かめられなくても何もしない）にしていました。2週間あまり、受け取った側から届く集計レポートを読んでから、強める判断をしました。
- レポートは13通（すべて Google から）、合わせて66通分
- 2つのドメインとも、送信元は公開サーバー1台だけで、DKIM・SPF とも合格
- 不合格は、メールを移した初日の2通だけ（DKIM を入れる前の1通と、IPv6 から送った1通）。どちらも原因はその日のうちに直していて、翌日からの不合格は0
そこで、2つのドメインの DMARC を p=quarantine（確かめられなかったメールは迷惑メールへ）に変えました。DNS のゾーンの値を書き換えてシリアル（版の番号）を上げ、自分の DNS とセカンダリの DNS の両方で、新しい値が返ることを確かめています。
注意点として、集計レポートは Gmail 宛ての分しか届いていませんでした。Gmail 以外に送るメールの結果は確かめられていないので、しばらくレポートを見続けます。
2. xmlrpc.php を閉じる
アクセスの記録を見ると、約3日でログイン画面（wp-login.php）への送信が575回、xmlrpc.php への送信が139回ありました。xmlrpc.php のほとんどは1つの相手からです。スマホのアプリや外部の連携は使っていないので、Apache の設定で全サイト共通に閉じました。
# /etc/httpd/conf.d/block-xmlrpc.conf
<Files "xmlrpc.php">
Require all denied
</Files>設定を読み直したあと、xmlrpc.php は 403（拒否）、トップページとログイン画面は 200（今までどおり）を確認しました。記事の投稿や、家のテスト環境から本番への同期は、xmlrpc.php を使っていないので影響はありません。
3. fail2ban に WordPress のログイン失敗の見張りを追加
fail2ban は SSH とメールの見張りだけで、WordPress は見ていませんでした。WordPress のログイン画面は、失敗すると画面をもう一度表示する（200）、成功すると管理画面へ移る（302）ので、「ログイン画面への送信に 200 が返った」ことを失敗とみなします。
# /etc/fail2ban/filter.d/wordpress-login.conf
[Definition]
failregex = ^<HOST> \S+ \S+ .*"POST /wp-login\.php[^"]*" 200
ignoreregex =
# /etc/fail2ban/jail.d/wordpress.conf
[wordpress-login]
enabled = true
backend = auto
port = http,https
filter = wordpress-login
logpath = /var/log/httpd/ssl_access_log- 締め出しの条件は、全体の既定のまま（10分に5回失敗で1時間）。家の IP は対象外
- 過去の記録に当てると、ログイン失敗の246件を拾えた（
fail2ban-regexで確認） - HTTP（暗号化なし）のログイン画面は HTTPS へ転送されるだけなので、見張るのは HTTPS の記録だけ
つまずき：最初は正規表現に日付の部分（\[…\]）まで書いていて、1件も一致しませんでした。fail2ban は、日付の部分を取り除いてから正規表現と比べるためです。日付を書かない形にしたら一致しました。
4. やらなかったこと
- 管理者のユーザー名の変更：狙われやすい名前ですが、上の2つで入口と回数を絞れたので、今回は変えていません
- テーマ（Hueman Pro）は、開発元の対応表明が WordPress 6.7 まででした。今の WordPress 7 で不具合は出ていないので、そのまま使っています