fail2ban で不正アクセスを防ぐ
インターネットに公開したサーバには、ログイン試行を繰り返す自動攻撃が日常的に届きます。fail2ban はログ（例: SSHの認証失敗）を監視し、短時間に何度も失敗した送信元IPを自動でファイアウォールにブロックさせるツールです。何回の失敗で何分間ブロックするかは設定で調整でき、人手をかけずに総当たり攻撃を弱められます。鍵認証やファイアウォールと組み合わせて、多層で守るのが効果的です。
インターネットに公開したサーバのログを眺めると、見覚えのない認証失敗がずらりと並んでいることがある。これは誰の仕業か。
多くは人ではなく、プログラムによる自動攻撃だ。
とりわけ SSH の22番ポートには、ありがちなユーザ名とパスワードの組み合わせを延々と試し続けるログイン試行が、世界中から絶え間なくやってくる。
1回1回は失敗していても、放っておけばログは大量の認証失敗で埋まる。ごくまれにでも弱いパスワードのアカウントがあれば突破されかねない。
こうした執拗な総当たり（ブルートフォース）攻撃に対し、人手をかけずに自動で立ち向かうツールが fail2ban（fail2ban）だ。
発想は単純で、「ログを監視し、短時間に何度もログインに失敗した送信元IPアドレスを、一定時間ファイアウォールでブロックする」というもの。
攻撃者は同じIPから試行を続けられなくなり、効率が大きく削がれる。
では、この「監視して弾く」という動きは、内部でどう成り立っているのか。
🧩 fail2ban のしくみ — jail・filter・action
fail2ban の動きは3つの要素で理解できる。
まず filter（フィルタ）が、ログファイルの中から「認証失敗」を示す行を正規表現で見つけ出す。
次に jail（ジェイル＝監視単位）が、「どのログを・どのフィルタで監視し・何回失敗したら・何分間・どうブロックするか」をまとめて定義する。
そして条件を満たしたときに実際の遮断を行うのが action（アクション）だ。RHEL/MiracleLinux系では firewalld（firewall-cmd で操作するあのファイアウォール）と連携して、該当IPを弾くルールを動的に追加する。
たとえば「SSH のログを監視し、10分以内に5回失敗したIPを10分間ブロックする」といった具合に、各 jail ごとに条件を決められる。
守りたいサービス（SSH、Web、メールなど）ごとに jail を用意できるのが柔軟なところだ。
しくみが分かったら、実際に入れて動かす番だ。
📦 導入と基本設定
RHEL/MiracleLinux系では、fail2ban は標準リポジトリにない場合がある。その場合は追加リポジトリ（EPEL）から `sudo dnf install fail2ban` で導入するのが一般的だ。
設定は /etc/fail2ban/ 以下にある。ここで重要な作法がある。
既定の設定は jail.conf に書かれているが、このファイルは更新で上書きされる可能性がある。だから直接編集せず、jail.local という別ファイルを作ってそこに上書き設定を書く（jail.local の内容が jail.conf より優先される）。
最小限の例として、jail.local に sshd の監視を有効化し、3つの値を書く。`bantime`（ブロック時間）、`findtime`（この時間内の失敗を数える）、`maxretry`（何回でブロックか）だ。
たとえば bantime = 600、findtime = 600、maxretry = 5 とすれば「10分以内に5回失敗で10分間ブロック」になる。
RHEL/MiracleLinux系で firewalld を使っている場合、遮断方式（banaction）を firewalld 連携にしておくと既存のファイアウォールときれいに協調する。
設定を書き終えたら、これをサービスとして走らせ、ちゃんと効いているかを見届けたい。
▶ 起動と状態確認
設定を書いたら、サービスとして起動・自動起動設定する。`sudo systemctl enable --now fail2ban` で、今すぐ起動しつつ次回起動時にも自動で立ち上がるようにできる。
きちんと動いているか、どのIPをブロック中かは fail2ban-client で確認する。`sudo fail2ban-client status` で全体の jail 一覧を、`sudo fail2ban-client status sshd` で sshd jail の詳細（これまでの失敗回数・現在ブロック中のIP数・対象IPの一覧）を見られる。
誤って自分や正規利用者をブロックしてしまったときは、`sudo fail2ban-client set sshd unbanip 192.0.2.50` のようにIPを指定して手動で解除できる。
動作確認やログ調査では /var/log/fail2ban.log を見ると、いつどのIPを ban / unban したかの記録が追える。
便利な道具だが、扱いを誤ると牙が自分に向く。
⚠ よくある失敗とセキュリティ上の注意
つまずきの代表が、自分自身を締め出してしまう事故だ。
設定を試している最中にパスワードを何度も打ち間違えると、自分の作業元IPがブロック対象になり、SSH でログインできなくなることがある。
これを避けるため、jail.local の `ignoreip` に、自分の固定IPや社内ネットワーク、ローカル（127.0.0.1/8 や ::1）を登録して除外しておくのが定石だ。
万一締め出されても、別経路（クラウドのコンソールや物理コンソール）から入って unbanip で解除できるよう、逃げ道を確保しておくと安心できる。
もうひとつの注意点として、fail2ban はあくまで「攻撃を弱める・ノイズを減らす」緩和策であり、これ単体で完全に守れるわけではない。攻撃元は次々とIPを変えてくるため、根本対策にはならない。
では、この緩和策はどう活かせば最大の効果を生むのか。
🛠 実務の使いどころ — 多層防御の一枚として
fail2ban が真価を発揮するのは、他の対策と組み合わせた多層防御の中だ。
まず SSH を公開鍵認証（公開鍵認証＝public-key-auth）に切り替えてパスワードという弱点をなくし、root ログインを禁止し、ファイアウォール（firewall）で不要なポートを閉じる。
そのうえで fail2ban を被せると、鍵認証で原理的に突破できない攻撃をさらにIP単位で弾ける。ログのノイズも大きく減らせて、本当に注意すべき異常が見つけやすくなる。
鍵認証だけでも安全度は高い。だが fail2ban を足すことで「無駄な試行を浴び続ける」状態自体を軽くできるのが利点だ。
SSH 以外にも、Web の管理画面やメールサーバなど、ログイン試行を受ける各サービスに jail を用意しておくと、公開サーバ全体の防御を底上げできる。
fail2ban は、人が四六時中ログを見張る代わりに、退屈で執拗な攻撃への一次対応を肩代わりしてくれる、運用の心強い相棒だと考えるとよい。