ある日、サーバーが重かった

「あれ？最近EC2のCPU使用率が妙に高いぞ？」

CloudWatch を覗くと、いつもは5%程度のCPU使用率グラフが数分で一気に95%くらいまで駆け上がる異常状態。topコマンドを叩くと、httpd と php-fpm が走りまくってる。

「これは……何かが……来ている……！」

ログを辿っていくと、見慣れぬIPからの連打が。

GET /phpMyAdmin/scripts/setup.php
GET /webadmin/scripts/setup.php
GET /pma/scripts/setup.php

phpMyAdmin や sqlweb、dbadmin など、過去によく使われた Web管理ツールの既知パスをスキャンし、不適切に公開された setup.php を探す謎のスキャナに遭遇。しかもアクセスのたびに WordPressのcanonical.php が悲鳴を上げていた：

PHP Warning: Undefined array key "host"
PHP Warning: Undefined array key "scheme"

WordPressも困ってる。Apacheも焦ってる。
これはもう「戦うしかない」。

急ぎの応急処置：iptablesでシュッと制裁

まずは攻撃元を叩き落とすため、iptablesでDROPルールを叩き込みます。（XXX.XXX.XXX.XXXは攻撃者のIPアドレス）

sudo iptables -A INPUT -s XXX.XXX.XXX.XXX -j DROP

シュッ。静寂が戻る。
しかも iptables-save しておけば再起動後も忘れない（：

sudo iptables-save | sudo tee /etc/sysconfig/iptables > /dev/null

でも忘れがちなので、systemctlで自動起動もON！

sudo systemctl enable iptables
sudo systemctl start iptables

敵はひとりじゃなかった！まだくる別の奴らも撃退

なんだと！悪いヤツらは一人じゃないって？
104.234.x.x や 198.235.x.x など、名前は違えど顔は同じbotたちが続々と来襲。

手動で追加ブロックも面倒になってきたころ、ふと気づく。
　
そうだ、fail2banがあるじゃないか！
というわけで、Amazon Linux 2 に fail2ban を導入。
最初は「パッケージないじゃん！」と突っ込まれるも…

sudo amazon-linux-extras enable epel
sudo yum clean metadata
sudo yum install epel-release -y
sudo yum install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Apacheログを監視する jail を有効にする

sudo vi /etc/fail2ban/jail.local

次のように記述

[apache-badbots]
enabled = true
filter = apache-badbots
action = iptables-multiport[name=apache-badbots, port="http,https", protocol=tc$
logpath = /var/log/httpd/access_log
maxretry = 5
bantime = 86400
findtime = 600

再起動

sudo systemctl restart fail2ban

これで準備OK！
あとは設定して監視開始。今後は404連発とかしたやつは自動でBANだ！
　
ステータスは以下のコマンドで確認できる。

sudo fail2ban-client status apache-badbots

出力：

Currently banned: 0
Total banned:     0

スキャナたちは賢く、User-Agentを偽装していると、標準の apache-badbots じゃ力不足だ。

じゃあ作ろう、自作の404検出ルール！

以下を /etc/fail2ban/jail.local に追記：

[apache-404]
enabled = true
filter = apache-404
action = iptables-multiport[name=apache-404, port="http,https", protocol=tcp]
logpath = /var/log/httpd/access_log
maxretry = 10
bantime = 86400
findtime = 600
logtimezone = JST-9

※　jail.local はfail2ban全体の監視対象を定義する設定ファイルです。jail.confは編集せず、jail.localを使いましょう。
　
フィルター定義ファイルも作成（どこに？）
以下を /etc/fail2ban/filter.d/apache-404.conf として新規作成：

[Definition]
failregex = ^<HOST> -.*"(GET|POST|HEAD).*HTTP.*" 404
ignoreregex =

fail2ban 再起動で有効化

sudo systemctl restart fail2ban

　
その後どう？

sudo fail2ban-client status apache-404

で確認すると、短時間に /notfound1, /phpmyadmin2, /admin/setup.php などを連打してくるbotは見事にBANされます。

……が、毎日Fail2Banが落ちるように。

「えっ、fail2ban.sock がない！？」
毎朝 fail2ban-client 叩いても「サービスが落ちてます」表示。落ちてるのは bot じゃなく Fail2Banのほうだった。

ログを見ると…

ERROR Failed during configuration: Have not found any log file for openhab-auth jail

原因は jail.conf にあった不要な [openhab-auth] jail。ログファイルもないのに enabled = true のまま残っていた。

【安定化対応1】不要な jail を無効化！

[openhab-auth]
enabled = false

これは /etc/fail2ban/jail.local に記述することで jail.conf の内容を無効化できます。

【安定化対応2】fail2ban.sqlite3 が壊れても大丈夫な構成へ

Fail2Ban の SQLite DB が /var/lib/fail2ban/fail2ban.sqlite3 のままだと、破損して起動できなくなることが多い。
なので、以下のように安全な場所へ変更：

sudo nano /etc/fail2ban/fail2ban.local

次の記述を追記

[Definition]
dbfile = /tmp/fail2ban.sqlite3

そしてファイルを準備：

sudo touch /tmp/fail2ban.sqlite3
sudo chmod 666 /tmp/fail2ban.sqlite3

さらに /etc/fail2ban/jail.local の [DEFAULT] にある古い dbfile の記述を削除しておくのがポイント！

再起動して安定運用開始！

sudo systemctl restart fail2ban
sudo fail2ban-client status

出力：

|- Number of jail:      1
`- Jail list:   apache-404

これで、毎日落ちていたFail2Banが 完全復活 & 安定稼働 に！

まとめ：EC2直アクセスはツラいよ

今回コストの関係でCloudFrontもロードバランサも導入しませんでした（特にロードバランサは導入すれば総コストが倍近くなるんで・・）が、

• EC2を直接ネットに晒すのはあんまりだね
• WordPressは意外とログ吐きまくる（canonical.php さん、お疲れ様でした）
• 緊急措置として iptables + fail2ban の2段構えでひとまずの危機は回避できる

だけどもさ、やっぱりいろいろ危ういので最終的には CloudFront(or ALB) + WAF しかないんだよね。