CrowdSec 対 Fail2Ban：実運用における違い

CrowdSecとFail2Banを正しく位置づける

適切な選択は、どのツールがより最新であるかという点ではなく、サーバー、ログデータ、および希望する適用ポイントによって決まります。 明確なエラーメッセージが出る単一のSSHサービスに対しては、Fail2Banが非常に直接的な解決策となります。CrowdSecが注目されるのは、複数のログソース、異なる保護レベル、あるいは分散システムをまとめて分析・保護する必要がある場合です。

どちらの解決策も、 ログベースの侵入検知: ログイン失敗などのセキュリティ関連のイベントを検知し、それらを特定のパターンに分類して、IPアドレスのブロックを実行できます。 Fail2Banは、この処理のためにフィルターとアクションを「ジェイル」内で連携させます。一方、CrowdSecは、読み込んだデータをセキュリティエンジンで処理し、判断を下します。その判断に基づく対応は、別の「リメディエーション・コンポーネント」が担当します。

重要なのは、実際に何がログに記録されているかです。タイムスタンプ、分析可能な送信元IPアドレス、適切なログソースがなければ、どのツールも攻撃を確実に特定することはできません。 また、ブロック措置は技術的に有効な範囲でのみ保護となります。トラフィックが事前に外部のリバースプロキシやロードバランサーを経由している場合、ローカルのファイアウォールルールだけでは自動的に効果を発揮しません。

として 侵入防止 これらのツールはいずれもセキュリティアーキテクチャを補完するものであり、それを置き換えるものではありません。 セキュリティアップデートは既知の脆弱性を修正し、強固で可能な限り多段階の認証はアカウントの不正利用を抑制し、制限の厳しいファイアウォールの基本ルールはアクセス可能なサービスを削減します。バックアップはインシデント発生後の被害を最小限に抑え、継続的なログ監視は、システム停止を引き起こさない問題も可視化します。

したがって、実務上の課題は次の通りです。どのようなパターンを検知すべきか、どの段階で対応を行うべきか、そしてルールや例外、ログの管理は誰が担当するのか？ その上で初めて、管理しやすいローカルなJail構成で十分なのか、それともCrowdSecのインフラ向け独立コンポーネントが明確な付加価値をもたらすのか、合理的な判断を下すことができます。

Fail2Ban が「Jails」とアクションをどのように関連付けているか

Fail2Banは、検知と対応を 刑務所. 例えば、SSHの場合、Jailは認証プロトコルやシステムログを読み取ります。フィルタは、それらの中から特定の送信元IPによるログイン失敗を検索します。設定された時間枠内で、そのIPの失敗回数が許容回数を超えた場合、Fail2Banはそのヒットをブロック対象として扱います。

その後のアクションによって、反応が決まります。多くの場合、ローカルファイアウォールのルールを補完するものですが、その他の設定済みアクションも可能です。これにより、一連の流れが明確になります。ログソースが行を供給し、フィルターが関連するイベントを検知し、ジェイルがそれらをカウントし、アクションが所定の対策を講じます。 ログ形式とフィルタが互いに適合していれば、これによりトラブルシューティングが容易になります。

1つのJailは1つのフィルターのみを使用しますが、複数のアクションを実行することができます。例えば、同じSSHブロック事案が、ファイアウォールアクションをトリガーすると同時に、通知も発信することが可能です。 複数のアクションにより対応の柔軟性は高まりますが、検知の根本的な仕組みは変わりません。すべてのアクションは、同じフィルターと、そのフィルターによるログ行の解釈に基づいています。

自分で書いたものには特に注意が必要だ 正規表現フィルター. 公開されているフィルタのドキュメントは、あくまでFail2Ban 0.9.0.dev向けの開発ガイドであり、特定の安定版パッケージの機能検証を目的としたものではありません。 フィルター開発においては、一般的な注意事項が依然として有用です。実際のログ形式のバリエーションを網羅しつつ、パターンのマッチング範囲が広すぎないようにする必要があります。したがって、新しいフィルターは、ブロックをトリガーする前に、匿名化されたサンプル行を用いてまず検証を行うべきです。

ローカルな変更は、原則として拡張子が .local, 出荷されていないものには .conf-ファイル。これにより、ログパス、許可されたネットワーク、またはアクションに関する独自の設定値が、パッケージの更新時にもより明確に把握できるようになり、単に上書きされることもありません。また、展開を行う前には、選択したログソースが実際に存在し、期待されるイベントが含まれているかどうかを確認する必要があります。

CrowdSecの「ログ」から「ブロック」への道のり

CrowdSecは、検知と対応をより明確に個別のコンポーネントに分離しています。まず、取得ソースが、どのログやイベントストリームを読み込むかを定義します。パーサーがこれらのデータを正規化し、その後、シナリオがパターンや挙動を評価します。 一致するパターンが検出されると、アラートが発生します。Local APIは、設定されたプロファイルに基づいて、時間制限付きのIPブロックなどの「決定」を生成することができます。

簡単な例でその流れを説明します。サービスの認証エラーは、Acquisitionを経由してエンジンに送信されます。パーサーは、時刻、サービス、送信元IPなどのフィールドを認識し、シナリオが繰り返し発生する失敗を評価します。 そこから生成されたアラートはローカルAPIに渡され、ローカルAPIは適切なプロファイルを用いてディシジョンを作成します。接続された 修復コンポーネント この決定を、所定の保護ポイントで実行する。

このコンポーネントは、従来「バウンサー」とも呼ばれています。バリエーションによっては、ファイアウォール、リバースプロキシ、Webサーバーなどで「ディシジョン」を適用することができます。 セキュリティエンジン単体では、インシデントを検知し、ローカルAPIを介してアラートやディシジョンを管理しますが、トラフィックを遮断することはありません。適切に接続されたリメディエーションコンポーネントがない場合、生成されたディシジョンは、ネットワークやアプリケーションの遮断が実行されない単なる情報にとどまります。

実質的に、この分離により、検知とブロックをさまざまなインフラストラクチャのポイントに分散させることが可能になります。ただし、運用範囲は広がります。ログソース、ローカルAPI接続、権限、およびBouncerの割り当てが互いに整合していなければなりません。 特に複数のサービスがある場合は、リメディエーション・コンポーネントが、ディシジョンに基づいてアクセスをブロックすべきサービスの前に確実に配置されているかどうかを確認する必要があります。

ローカルなシナリオの一致とは区別されるのが、オプションの コミュニティのブロックリスト. 自発的な参加により、シグナルを提供したり、既知の攻撃者に関する精査済みの判断情報を取得したりすることができます。これは追加的な予防策ではありますが、ローカルでの検知に代わるものではなく、また、新規または目立たない攻撃者を確実に検知できるという保証でもありません。 したがって、運用においては、ブロック決定の根拠が常に追跡可能であるようにする必要があります。

用途ごとにツールを比較する

CrowdSecとFail2Banのどちらを選ぶかは、一般的な品質評価ではなく、保護の観点から検討を始めるべきです。Fail2Banはフィルターを用いてログ行を分析し、それらを「ジェイル」内のアクションと関連付けます。 一方、CrowdSecはパーサーとシナリオを通じてログソースを処理し、アラートに変換します。Local APIは、そこからプロファイルを用いて決定を生成し、個別の修復コンポーネントに実行させます。いずれのソリューションも、正確に記録されたイベントに依存しています。

この表は順位表ではありません。ごく少数の、よく理解されているログパターンについては、ローカルなJailの方が検証しやすい場合がよくあります。ログソース、フィルター、ファイアウォールのアクションが互いに近接しているからです。 複数のソース、上流のシステム、あるいは異なる適用ポイントが関与する場合、CrowdSecにおいて検知と対応を分離することが有効となる場合があります。ただし、そのためにはコンポーネント間の関係を明確に把握した上で運用する必要があります。

「Web保護」という基準においては、技術的なレベルが決定的な要素となります。CrowdSecのファイアウォール・バウンサーは、ネットワークレベルで判定を実行しますが、HTTPコンテンツの検査は行いません。 サポートされているAppSec構成では、対応するBouncerがHTTPリクエストをSecurity EngineのAppSecコンポーネントに転送し、そこでAppSecルールが評価されます。この検査は、既知の脆弱性を修正するのではなく、セキュアな開発やタイムリーな更新を補完するものです。

SSHを使用した単一のVPSの実例

SSHと管理しやすいWebスタックを備えた小規模なLinux VPSでは、Fail2Banは多くの場合、管理しやすい選択肢となります。 まず、SSHログインの失敗が、タイムスタンプと送信元IPアドレスとともに、指定されたログやジャーナルに確実に記録されているかを確認してください。これらのデータがなければ、Jailは失敗回数を正確にカウントすることも、アクションに正しいアドレスを渡すこともできません。

その後、適切なSSH-Jailを選択し、フィルタ、時間枠、許容される失敗回数、およびロック時間を、自身のログイン状況に合わせて確認します。 1つのJailは、1つまたは複数のアクションとフィルターを結びつけます。これにより、例えば、検知ロジックを重複させることなく、ロック処理をローカルファイアウォールに委譲することが可能になります。単一のホストに対しては、この連携により処理の流れが概ね透過的になります。

管理ネットワーク、緊急アクセス、および監視システムには、意図的に定義された例外設定が必要です。これらは厳格に制限されるべきであり、大規模なプロバイダーネットワークを一律に例外扱いしてはなりません。また、展開前に、その操作によって実際にどのようなファイアウォールルールが設定されるか、およびIPv4とIPv6がサーバーの設計コンセプトに適合しているかを確認してください。 ログを監視しながら段階的に開始する方が、即座に長期間のブロックを行うよりも安全です。

独自の 正規表現フィルター これらは、既存のフィルターでその具体的なログ形式をカバーできない場合にのみ有用です。フィルター開発用のガイドは、Fail2Ban 0.9.0.dev のドキュメントとして指定されているため、1.1.1 のような安定版には含まれていません。 とはいえ、その開発に関するヒントは実用的です。匿名化された実際のサンプル行や、類似しているが正当な行を用いて、新しいパターンを検証してください。テストツール fail2ban-regex これはフィルターの検証を目的としており、本番環境のロックには影響しません。

地域設定は .local-ファイル、出荷時に含まれていないもの .conf-ファイル。これにより、パッケージの更新時の変更内容が追跡可能となり、誤って上書きされることを防ぎます。変更を行うたびに、ログエントリ、Jailのステータス、およびトリガーされたアクションを個別に確認してください。実行中のサービスがあるだけでは、有効なロックチェーンが確立されたことにはなりません。

プロキシ、実際のクライアントIP、およびWeb保護

CDN、ロードバランサー、またはリバースプロキシは、サーバーが認識するアドレスを変更します。WebサーバーがプロキシのIPアドレスのみを受け取り、それをクライアントとしてログに記録した場合、ログに基づくブロック機能は、最悪の場合、攻撃を行っている訪問者ではなく、その仲介サーバーを誤って対象としてしまう可能性があります。 したがって、あらゆるジェイル、シナリオ、およびWAFルールにおいて、元のクライアントIPをどのように信頼できる形で転送、受け入れ、およびログに記録するかを事前に明確にしておく必要があります。

この信頼チェーンは、受信したヘッダーを無条件に受け入れてはなりません。既知のプロキシアドレスのみが、転送先アドレスを提供する権限を持つべきです。そうしないと、外部クライアントが、識別やブロック処理の根拠となる身元情報を偽装する恐れがあります。 匿名化されたログの抜粋を用いて、アプリケーションログとアクセスログに同じクライアントIPが記録されているかを確認してください。また、エッジとオリジン間のヘッダー転送についても記録を残してください。クライアントIPの確認を経て初めて、不審なHTTPイベントへの対応を適切に解釈することが可能になります。

A IPブロッキング ファイアウォールレベルで、接続がアプリケーションに到達する前に制限しますが、リクエストの内容は検査しません。CrowdSec AppSecのサポート対象となる設定では、対応したバウンサーがHTTPリクエストをセキュリティエンジンのAppSecコンポーネントに転送し、 そこで、該当するAppSecルールが検証されます。一方、純粋なファイアウォール型バウンサーは、ネットワークレベルで判定を行い、HTTPの検証機能は備えていません。どちらのバリエーションが適しているかは、トラフィックの実際の進入点と、導入されているコンポーネントによって決まります。

さらに、ログベースの検知は事後対応的なものです。まずイベントが発生し、正しくログに記録され、パターンとして認識される必要があります。この手法では、目立った二次イベントを伴わない単発のエクスプロイトを阻止することはできず、パッチの適用や強固な認証に代わるものでもありません。 したがって、上流のコンポーネントは、その信頼できるデータ転送、ログ、および保護ポイントを通じて、セキュリティアーキテクチャ全体と整合していなければなりません。

具体的には、まずネットワークアクセス、HTTPリクエスト、あるいはその両方のレベルを保護すべきかを決定します。その後、パブリックアドレスからプロキシを経てログエントリに至るまでの経路を文書化し、許可されたテストアドレスを使用してブロック機能をテストします。そうすることで、一見正常に機能しているように見える 侵入防止 誤ったインフラストラクチャ・コンポーネントにのみ影響する。

複数のサーバーを管理しながらセキュリティ対策を講じる

複数のホスト、コンテナ、または一元的に収集されたログが関与する場合、CrowdSecにおける検知と対応の分離が実用的になります。 セキュリティエンジンは定義されたソースからのイベントを分析し、適切なリメディエーションコンポーネントが、それぞれの保護対象ポイントで決定を実行します。CrowdSecでは、このための分散型展開や、集中型ログパイプラインとの統合についてもドキュメント化されています。

それだけでは、運用コストが自動的に削減されるわけではありません。 まず、各ログソースがどのサービスおよびどのクライアントに割り当てられているかを追跡可能にしておく必要があります。その後、各バウンサーには、ローカルAPIへの明確に制限された接続と、独自のアクセスキーが必要です。例えば、リバースプロキシバウンサーは、必ずしも個別にアクセス可能なSSHサービスを保護するわけではありません。その バウンサーの割り当て 実際のデータ経路に従わなければならない。

したがって、運用においては、トークン管理、APIへのアクセス可能性、実行ログおよびエラーログ、ならびにブロック効果の検証をモニタリングの対象に含める必要があります。「Decision」は、所定のコンポーネントがそれを取得して適用するまでは、単なる検知結果に過ぎません。 コンテナ、プロキシ、またはファイアウォールルールに変更があった場合は、正常に機能している検知結果が見過ごされ、有効な対応が取られないことがないように、この一連のプロセスを再度確認する必要があります。

独自のチェーンやルールがすでに存在する場合、Firewall-Bouncerは セット専用モード あらかじめ作成されたセットのみを管理します。ルールやチェーンに関する責任は、意図的に運用者に委ねられます。これは、管理されたファイアウォール構想やコンプライアンス要件に適していますが、既存のルールの順序を理解する必要があり、初心者にとっては簡素化にはなりません。

よくあるミスを体系的にチェックする

ロックがかからない場合、安易に工具を交換するよりも、決まった検査手順に従う方が効果的です。 まず、期待されるイベントが妥当なタイムスタンプ付きで受信されているかどうかを確認する必要があります。次に、ログに記録されたアドレスが実際にクライアントのIPアドレスであるかを確認します。そうして初めて、フィルターやシナリオがそのパターンを認識し、それに基づいてブロック判断が下されるかどうかを適切に検証できるのです。

Fail2Banでは、ログの受信に続いて、ジェイル、フィルタ、およびヒット数のチェックが行われます。ジェイルは、フィルタと1つまたは複数のアクションを関連付けます。ファイルベースのログパスでは、起動時にGlobパターンに一致する既存のファイルのみが考慮されます。 systemdジャーナルの場合は、バックエンドとアクセス権を個別に確認する必要があります。一見正しく見えるJailであっても、実際のソースを読み取っていなければ保護にはなりません。

独自に作成した正規表現については、特に注意が必要です。公開されているフィルタガイドは、Fail2Ban 0.9.0.dev の開発ドキュメントとして指定されており、Fail2Ban 1.1.1 における同バージョンの参考資料として解釈すべきではありません。 とはいえ、独自のフィルターを開発する際には、このガイドラインの推奨事項に従うことが有益です。まず、匿名化された代表的なサンプル行や、意図的に条件に合わない行を用いてパターンを検証してください。そうすることで、本番環境でのブロックが実行される前に、ログ形式のバリエーションや誤検知の可能性を特定することができます。

CrowdSecでは、シナリオに一致した場合、さらにエンフォースメントチェーン全体を確認する必要があります。アラートが発生した場合、ローカルAPIはプロファイルに基づいてそのアラートから決定を生成できますが、その決定は所定のリメディエーションコンポーネントに到達しているでしょうか？Bouncerが正しく接続されていない場合、決定だけではアクティブなブロックは行われません。 その後、自身の管理者アクセス権を無効にすることなく、適切なエントリポイントにおけるファイアウォールまたはプロキシの効果を確認する必要があります。

最適なソリューションを持続的に運用する

Fail2Banは、SSHへの繰り返し失敗といった、明確でローカルなログパターンを持つ単一のサーバーに適していることがよくあります。その「ジェイル」、「フィルター」、および「アクション」は、特定のサービスに直接関連付けることができます。 CrowdSecは、複数のログソースや異なる適用ポイント、あるいは適切なコンポーネントを用いたWeb保護を連携させる必要がある場合に、より有用となります。重要なのは、データの流れが追跡可能であることであり、単に「より新しいツール」という理由だけで一律に判断することではありません。

どちらのソリューションも、体系的な変更プロセスが求められます。設定にバージョン管理を行い、新しいフィルターやシナリオについては、まず既知のログ例に対して検証を行い、ブロック状況を監視する必要があります。 アップデートについても同様の注意を払う必要があります。Fail2Ban 1.1.1は2026年8月15日にリリースされました。アップデートを行う前には、ローカルでのカスタマイズ内容や実際に適用されているファイアウォールアクションを、ターゲット環境と照合しておく必要があります。

侵入防止 セキュリティ基盤を補完するものではありますが、それに取って代わるものではありません。タイムリーな更新、強固で可能な限り多段階の認証、厳格なファイアウォール設定、バックアップ、およびログ監視は依然として必要です。特にホスティング環境においては、アプリケーションの実行環境のメンテナンスも行う必要があります。この記事は CloudLinuxのAlt-PHPとそのセキュリティ面 なぜ、分離され、適切に管理されたランタイム・バージョンが、堅牢な運用モデルの一部となるのかを示しています。

また、Webサービスにおいては、クライアントからCDNやリバースプロキシを経由してオリジンに至るまでの全経路を、運用ドキュメントに記載する必要があります。プロトコルや配信経路の変更は、どのコンポーネントが接続を受け付けるか、またログにどのアドレスが表示されるかに影響を与える可能性があります。この記事について ホスティングにおけるHTTP/2サーバープッシュ 例を挙げて、コンテンツ配信においてブラウザ、CDN、Webサーバーがどのように連携するかを説明します。ブロックロジックに関しては、それとは別に、信頼できるものとして渡されたクライアントIPが、適切な保護ポイントで利用可能であることが決定的に重要です。

恒久的な選択であっても、検証は可能です。ログ形式、プロキシ経路、サービス、あるいはサーバー数が変更されると、以前は適切だったコンセプトにも抜け穴が生じる可能性があります。そのため、どのイベントを検知すべきか、どこで決定が実行されるか、そして誰が例外を承認するかを明確に定めておきましょう。これら 業務規律 IPブロックを、監視されないファイアウォールの変更ではなく、管理可能な保護措置に変える。