fail2ban で足りなくなる境目

まず功績を認める

fail2ban はどのディストリビューションのリポジトリにもあり、1 コマンドで導入でき、その晩のうちに実際の攻撃者を遮断します。何も見張っていない公開サーバーがあるなら、fail2ban を入れることは今の状態より厳密に良く、以下の内容はそれに異を唱えるものではありません。

このガイドが扱うのは、「今晩、実際の攻撃者を遮断する」と「1 年後、複数サーバーにわたってなお正しい」との間の隙間です。驚きはその隙間に住んでおり、そしてそれはめったに書き残されていません。

以下の限界はどれもバグではありません。単一のサーバーと単一の攻撃者の時代に設計されたログ解析デーモンという、fail2ban の本質からの帰結です。

限界 1：遮断するのはアドレスであってレンジではない

これが大きな 1 つです。攻撃トラフィックはホスティング事業者から来ており、そこでは 1 つの事業者がブロック全体を保有しています。203.0.113.47 を遮断すればボットネットは 1 時間以内に .48 へ移り、それも遮断されるまでにもう 1 巡ぶんの試行を受け止めることになります。/24 全体では、設定したしきい値の 256 巡です。

遮断を /24 に広げるカスタムアクションで近似できますが、そうするとシェルで CIDR 演算を保守することになり、誤れば必要だったものを遮断します。このツールにはレンジを一級の対象として扱う概念がありません。

測定できる効果はこうです。持続的な攻撃下のサーバーでは、レンジを遮断する防御は試行数が崖のように落ちるのに対し、アドレスを遮断する防御は巡回速度で決まる水準に横ばいします。

限界 2：遮断は期限切れになり、状態は残らない

既定の bantime は分単位です。実在の利用者が巻き込まれうる共用ホストでは妥当な既定値ですが、インターネットに面したサーバーでは誤りです。同じボットネットが今夜また来て、最初からやり直します。

bantime を -1 にすれば恒久遮断にできますし、そうすべきです——しかしそこで second の問題が現れます。遮断リストは fail2ban 自身のデータベースと稼働中のファイアウォールにあり、マシンを作り直す、イメージから復元する、新しいホストへ移行する、そのいずれでもサーバーが学んだすべてが消えます。

三次的な版もあります。2 年動いているサーバーは数万件のエントリを持つファイアウォールセットを溜め込み、そして最も古いものが今も照合に値するかを誰も一度も見直していません。

限界 3：どのサーバーも独りで学ぶ

これは構造的なもので、いかなる設定でも直りません。あなたの各サーバーは各攻撃者を独立に発見し、その発見の代価はあなたが設定したしきい値——5 回でも 10 回でも——そのものです。

10 台のサーバー、同じ攻撃者を 10 回、しきい値を 10 回受け止める。そしてその試行の 1 つ 1 つが本物の sshd フォークであり、本物のログ行であり、使い回されたパスワードが通ってしまう回になる本物の可能性です。

fail2ban には、あるサーバーの知識が別のサーバーに届く仕組みがありません。購読できるコミュニティのブロックリストはあり、それは助けになりますが、内容は一般的で数時間から数日遅れます。いま 3 号機を叩いているアドレスが、今朝 1 号機を叩いていたものだと教えてくれるものは何もありません。

限界 4：静かに壊れる

実際に人がサーバーを失う原因になるのがこの限界であり、そして最も注目されないのもこれです。

fail2ban はログ行を正規表現で一致させることに依存しています。ディストリビューションのアップグレードが sshd のメッセージ形式を変える。フィルタが一致しなくなる。jail は「動いている」ままで遮断数ゼロを報告し、それは平穏な一週間とまったく同じに見えます。パッケージ更新が jail.local を初期化した例もあります。systemd バックエンドの変更でジャーナルが読まれないままになる。再起動後にサービスが戻ってこない。

これらのどの場合でも、あなたがおそらく持っている監視——サービスは動いているか？——は「はい」と答えます。捉えられる問いは「最近誰かを遮断したか、その数はログで見える攻撃量に見合うか」であり、それをほとんど誰も問いません。

fail2ban をさらに押し広げる

使い続けたいなら——小規模な環境では正当な選択です——効果の大きい変更を、おおむね優先順に挙げます：

• bantime = -1 にし、findtime を大きくして、遅い攻撃者も捕まえる。その上に recidive jail を重ね、常習犯をエスカレートさせる。
• 遮断を /24 に広げるカスタムアクションを追加し、まず自分のアドレスレンジに対して演算を慎重に検証する。
• persistent 指定の nftables セットで遮断を再起動越しに残すか、起動時にデータベースから復元する。
• サービスの状態ではなく遮断数を監視する。認証ログに失敗があるのに遮断数がゼロなら警報を出す。
• 何よりも先に管理用アドレスを ignoreip に入れ、2 本目の接続から正しく入っていることを確認する。

マネージドエージェントが加えるもの

2 つあり、2 つ目はどんな設定でも単独では構築できません。

1 つ目は運用の土台です。サブネット遮断を一級の概念として扱うこと、遮断が恒久で起動時に復元されること、SSH の実ポートを推測ではなく sshd の設定から読むこと、インストール時点であなたのアドレスをホワイトリストに入れること、そして「これはまだ動いているのか」に答えるコンソール——実際に痛い目を見るのはこの故障の形です。

2 つ目は共有レピュテーションです。保護された各サーバーが共通のデータベースに寄与するため、昨日誰かを攻撃したアドレスはあなたに届く時点ですでに遮断されており、最初の N 回を受け止めることがありません。1 台のホスト上のログ解析器は、そのホストへの攻撃からしか学べません。

SSH Protector はエージェント側のローカルで判断するので、保護はクラウドの到達性に依存しません。接続が切れてもローカルポリシーが動き続けます。1 台は永年無料なので、1 週間 fail2ban と並走させ、それぞれが何を捕らえたかを比べるには十分です。