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 の監視を有効化し、`bantime`（ブロック時間）、`findtime`（この時間内の失敗を数える）、`maxretry`（何回でブロックか）を書きます。たとえば bantime = 600、findtime = 600、maxretry = 5 とすれば「10分以内に5回失敗で10分間ブロック」になります。RHEL/MiracleLinux系で firewalld を使っている場合、遮断方式（banaction）を firewalld 連携にしておくと既存のファイアウォールときれいに協調します。
起動と状態確認
設定を書いたら、サービスとして起動・自動起動設定します。`sudo systemctl enable --now fail2ban` で、今すぐ起動しつつ次回起動時にも自動で立ち上がるようにできます。きちんと動いているか、どのIPをブロック中かは `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 は、人が四六時中ログを見張る代わりに、退屈で執拗な攻撃への一次対応を肩代わりしてくれる、運用の心強い相棒だと考えるとよいでしょう。