複数台のクラウドサーバー（顧客専用のクラウドシステムや当社で運用しているGenbaFlow というデジタル日報管理）を運用していて、ひさしぶりにfail2banのログをちゃんと見てみたんです。そしたら……思ってたよりずっとヤバいことになってて。焦って設定を見直したときの記録をまとめました。
まず、ログを数字にしてみた
grep '2026-03-26' /var/log/fail2ban.log | grep ' Ban ' | awk '{print $6}' | sort | uniq -c | sort -rn
結果はこんな感じ。
179 [sshd]
34 [nginx-bad-useragent]
8 [nginx-exploit]
1 [nginx-env-scan]
1日200件超のBan！？ SSHへの辞書攻撃がダントツなのは想定内だったけど、nginx系への攻撃も思った以上に……というか、めちゃくちゃ来てるじゃん！
攻撃の種類をざっくり整理すると：
- SSH辞書攻撃：
ubuntu、admin、root、deployとかをひたすら試してくる - 不審なUserAgent：スキャナーやボットが使う文字列でWebをノック
- Webエクスプロイト：既知の脆弱性を突くパスへの直接アクセス
-
.envファイルや設定ファイルを探し回るやつ
これ、全部自動化されたボットなんですよね。止める理由がないから、24時間、今この瞬間も動き続けてる。ほんと恐ろしい……。
bantimeが10分になってた……
デフォルトの設定を確認したら bantime = 10m になってました。
10分でUnbanされるとどうなるか。同じIPが1日25回以上もBanと解除を繰り返してたんですね。
Ban [攻撃元IP] → 10分後Unban → また攻撃 → またBan → 10分後Unban → …
これが1日中。fail2banは一応動いてるけど、これじゃ完全にイタチごっこじゃないか。
同じサブネット（/24）から複数のIPが組織的に攻撃してくるパターンもあった。個別IPをBanしても別のIPに切り替えてくるから、そのままじゃキリがない。というか、全然追いつかない！
やったこと
1. bantimeを伸ばす
/etc/fail2ban/jail.local のsshdセクションに追記。
[sshd]
enabled = true
filter = sshd
bantime = -1
maxretry = 5
action = iptables-multiport[name=sshd, port="ssh", protocol=tcp]
bantime = -1 で永久Ban。誤検知が怖いなら 48h あたりから試すのが無難かも。
2. 自分のIPをignoreipに登録
自分のIPもBanされたらシャレにならないので、先に登録しておきましょう。
[sshd]
enabled = true
filter = sshd
bantime = -1
maxretry = 5
ignoreip = 127.0.0.1/8 [自分のIP]
action = iptables-multiport[name=sshd, port="ssh", protocol=tcp]
3. しつこいサブネットをiptablesでDROP
同じサブネットから繰り返し来る場合は、fail2banのサイクルを待たずにパケットごと捨てちゃう。
このコマンドラインも、
ログ /var/log/fail2ban.logからサブネット単位でDropさせるコマンドラインを作って。
とclaude-codeとかに頼むのが楽。
sudo iptables -I INPUT -s [攻撃元サブネット]/24 -j DROP
再起動後も有効にするには：
sudo netfilter-persistent save
netfilter-persistent がないなら：
sudo iptables-save | sudo tee /etc/iptables/rules.v4
4. fail2banを再起動して確認
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
やってみてわかったこと
fail2banは入れるだけでも効果はある。でも「デフォルトのまま動かしてるから大丈夫！」っていうのは半分しか正しくない。というか、むしろ危険だな、って。
特に bantime = 10m のまま放置してたのは、本当にまずかった。今すぐ bantime を伸ばすべきですよ。 Ban数のカウントはされてるけど、同じIPがその日のうちに何十回でも再挑戦できちゃう状態だった。ザルすぎる……。
あと、nginx系への攻撃はSSHほど目立たないけど、.env ファイルや既知の脆弱性を狙ったアクセスが着実にきてる。Webアプリ側の設定も今すぐ見直した方がいいです。
ログを眺めてみると、自分のサーバーが思ってるより、はるかに多く叩かれてることがわかる。面倒だけど、今すぐ数字にしてみるべき。 対処の優先順位がはっきりして、マジで血の気が引くから。
フィルタは、LLMにログを食わせて作成するのが最善ですよ。 攻撃手法はどんどん進化してフィルタもすぐ陳腐化するから、人間が手書きするのは今の時代、無駄な時間を浪費するだけ。一刻を争う事態ならなおさら、LLMに任せてガシガシ改版していくべきです！
参考
- fail2ban公式ドキュメント
-
man jail.conf— bantime, findtime, maxretry の詳細はここが一番確実