最新のLinuxサーバー向けのFail2Banの代替ツール

工具選定の前に、攻撃対象範囲を確認する

A Fail2Banの代替ツール 実際にアクセス可能なサービスが確定して初めて、適切な選択が可能になります。SSH、SMTP、IMAP、およびHTTPアプリケーションは、それぞれログイン手順、ログの出所、被害の様相が異なります。 一方、外部からアクセス可能なデータベースサービスについては、通常、インターネット遮断リストによって保護する必要はありません。そのネットワークアクセスは、必要なアプリケーションおよび信頼できるネットワークに限定されるべきです。.

管理上の新規登録については、 アクセス制限 また、強力な認証は、自動化されたIPブロックよりも優先されます。 VPN、バスティオンホスト、または固定の管理ネットワークの背後に配置されたSSHサービスは、世界中に公開されたポートに比べて、攻撃者にさらされる攻撃対象領域を大幅に縮小します。最新のセキュリティアップデート、特権アカウントの分離、そして慎重に検討されたパスワード認証は、ブロックリストだけでは解消できないリスクを低減します。.

SSHが意図的に外部からアクセス可能な状態にある場合、制限やログに基づくブロックにより、繰り返されるパスワードの試行を抑制することができます。しかし、これらはあくまで補助的な手段に過ぎません。共通のNATゲートウェイの背後にあるユーザーは同じ送信元アドレスを使用できる一方、分散型攻撃では多数のアドレスが利用されるためです。 メールサービスに関しては、外部ユーザーに対して実際にどのプロトコルが開放されているか、またどのログイン失敗がログに記録されるかも重要な要素となります。.

Webアプリケーションにおいては、リバースプロキシへのアクセス可能性と、内部のバックエンドサービスへのアクセス可能性を区別する必要があります。公開されているNginxは、データベース、キャッシュ、管理インターフェースがインターネットからアクセス可能である必要なく、HTTPリクエストを受け付けることができます。その 保全目標 したがって、単に「IPアドレスをブロックする」という一律的な対応ではなく、サービスごとに不正アクセスを制限し、正当な利用を維持しつつ、不必要なアクセス許可を避けることが重要です。.

変更を行う前には、担当者は、緊急時に必要なアクセス経路と、通常アクセスするソースネットワークを明確に把握しておく必要があります。この現状把握を行うことで、ファイアウォールルールが厳しすぎて、自社の管理用アクセスや自動化されたメンテナンスがブロックされるのを防ぐことができます。 その上で初めて、ログ分析、接続制限、あるいは多段階の対策のいずれが適切であるかを判断できるようになります。.

また、アクセスを遮断しても、そのサービスがそもそも公開されるべきかどうかという疑問には答えられません。この順序を逆にしてしまうと、目立つ接続は対処されるものの、根本的な露出状況は変わらないままとなります。 特に利用頻度の低い管理画面においては、ますます複雑化する検知ルールよりも、非公開のアクセス経路の方が、多くの場合、より効果的で運用も容易である。.

Fail2Banの代替案として、4つのアプローチ

単一の代替策を探すのではなく、検知と対応を分離する方が有益です。. CrowdSec 設定可能なログソースをパーサーやシナリオを用いて処理し、イベントの連鎖を評価して意思決定を行います。セキュリティエンジン自体はこれらの決定を直接実行するものではなく、その実行には別途、リメディエーションコンポーネントが接続され、正常に動作している必要があります。.

この構成は、同じ検知機能を異なる場所で適用したい場合に適しています。 ファイアウォールコンポーネントはネットワーク接続に対する判断を適用できる一方、Webサーバーやリバースプロキシ用のコンポーネントはHTTPトラフィックを対象とします。しかし、それにより要件も増大します。ログの取得、パーサー、ローカルAPI、権限管理、そして具体的な適用は、相互に関連した一連のプロセスとして計画する必要があります。.

SSHGuardは、より限定的なケースを想定して設計されています。 このツールはシステムログを集約し、繰り返し不審な動作を示す送信元をファイアウォールのバックエンドを通じてブロックすることができます。その目的には、SSHやその他のサービスに対するブルートフォース攻撃の防御が含まれます。したがって、Webリクエストの包括的な分析というよりは、原因が特定可能な認証エラーへの対応に適しています。.

ネイティブ nftablesのレート制限 別のアプローチを採用しています。 動的なセットとメーターは、送信元アドレスごとに新しいTCP接続を制限し、タイムアウトしたエントリを管理することができます。これにより、認証前の高速な連続接続を抑制でき、ログパーサーを必要とせず、同時にログインが失敗したのか、それともHTTPリクエストが悪意のあるものだったのかを判断することもありません。.

この際、ルールの適用方向が重要です。nftables は、一定レートまでのトラフィックを受け入れるルールと、 over, 、一定の上限を超えるトラフィックを排除するものです。したがって、この上限は、サービス、予想されるユーザーの行動、および共有されている送信元アドレスに適合するものでなければなりません。これは、疑わしいIDをすべて確実に分類するものではありません。.

明確なサービスが少数しかない単一のサーバーの場合、簡素なログ保護や適度な接続制限で十分である。 複数のホスト、一元化されたログソース、あるいは複数の適用ポイントが必要な場合は、モジュール式のアーキテクチャが適しています。いずれの選択肢も、パッチの適用、強固な認証、あるいは厳格なネットワークアクセス制御に代わるものではありません。.

したがって、Fail2Banに代わる適切な手段は、どのようなシグナルが利用可能か、そしてどこで反応を行うべきかという問いから導き出されます。ログパターンは繰り返されるログイン失敗の検知に有用であり、パケットルールは接続頻度を制限します。どちらの手法も、そのデータソースやルールが想定している範囲内の事象しか検知できません。.

ファイアウォールとHTTP保護を明確に分離する

Nginxサーバーまたはリバースプロキシは、混同してはならない2つの保護層を結びつけます。 ファイアウォールのブロック機能は、送信元アドレスからの接続を拒否または許可するものであり、SSH、SMTP、あるいはWebアクセスに同時に影響を及ぼす可能性があります。しかし、個々のHTTPパス、ヘッダー、またはリクエストの内容を評価することはありません。これらの情報はアプリケーション層に属するものです。.

CrowdSecでは、 検知と執行 それぞれ異なる役割を担っています。ログプロセッサは、ログデータおよび互換性のあるWebサーバーからのHTTPリクエストを分析します。AppSecはこのログプロセッサの一部であり、そのようなHTTPリクエストをフィルタリングします。一方、リメディエーションコンポーネントは、ファイアウォール、Webサーバー、リバースプロキシなど、選択されたレベルで決定を実行する役割を担っています。.

したがって、SQLインジェクション、クロスサイトスクリプティング、その他の悪意のあるリクエスト内容から保護するためには、ファイアウォールコンポーネントだけでは不十分です。互換性のあるWebサーバーとの連携に加え、適切なルールに基づくAppSec設定が必要となります。 これとは技術的に区別して考える必要があるのが「リメディエーション」であり、これは選択された適用ポイントにおいて決定事項を実行するものです。.

どちらのアプローチも、並行して有効である場合がある。ネットワーク全体でのブロックは、特定の送信元からのさらなる通信を抑制する一方で、 HTTP検証 AppSecリクエストに対応したWebサーバーを評価・フィルタリングします。ただし、IPブロックを行っても、SQLインジェクションやクロスサイトスクリプティングから自動的に保護されるわけではありません。リクエストの検証を行わなければ、ファイアウォールはパラメータもペイロードも認識できないからです。.

逆に、AppSecやIPベースの対策にも限界があります。閾値を下回る低速な試行、頻繁に変化する送信元アドレス、あるいは同じNATアドレスの背後にいる正当なユーザーなどが、送信元IPに基づく判断を困難にしています。 したがって、ルール設定においては誤検知の可能性も考慮し、通常のフォーム、API、自動化された統合へのアクセスを、一律に攻撃として扱わないようにすべきである。.

計画を立てるにあたっては、簡単な整理が役立ちます。その ファイアウォール層 アドレス、ポート、および接続特性に基づいてネットワークトラフィックを制御します。AppSecは、ログプロセッサの一部として、互換性のあるWebサーバーからのHTTPリクエストを処理・フィルタリングします。リメディエーションコンポーネントは、選択されたレベルで意図的に決定を実行します。.

また、公開Webシステムでは、責任範囲を明確に区分する必要があります。 リバースプロキシは必要なバックエンドにのみアクセスできる必要があり、管理用エンドポイントは、単にその手前にフィルタが配置されているという理由だけで、一般に公開されたままにしてはならない。このように、ネットワークのセグメンテーション、安全な認証、および的を絞ったルールが互いに補完し合い、個々のアクセス制御技術に対して、その能力以上の保護効果を過大評価することなく、全体としてセキュリティを強化する。.

一般的なLinuxサーバーの比較

Fail2Banの代替ツールは、単にブロック可能な回数だけで適切に選ぶことはできません。重要なのは、分析されるシグナルと、その適用される場所です。. CrowdSec セキュリティエンジンを、ファイアウォール、プロキシ、またはWebサーバーでの決定を実行するコンポーネントから分離しています。一方、SSHGuardはシステムログを分析して繰り返される攻撃の試みを検知し、nftablesはパケットパス上で直接、新しい接続を制限することができます。.

この表は順位を示したものではありません。ログイン失敗が明らかな単一のサービスの場合、簡素なログ分析と接続の集中攻撃に対する制限とは別物です。リバースプロキシの場合、さらに、互換性のある接続においてAppSecによってHTTPリクエストをフィルタリングすべきかどうかも考慮する必要があります。その 貫通点 保護対象に適合している必要がある：ファイアウォールルールはリクエストの内容を評価しないが、リメディエーションコンポーネントは、それぞれ選択されたレベルで決定を実行する。.

集中管理もまた、それ自体が目的ではありません。複数のホストにわたる意思決定やログ分析を統一することはできますが、堅牢なアクセス管理および障害対策の仕組みが求められます。小規模で孤立したサーバーの場合、この追加のアーキテクチャは、状況によってはセキュリティ上のメリットよりも、むしろ保守の負担を増やすことになりかねません。 逆に、複数のホスト上で同一のサービスが稼働している場合は、綿密に計画されたCrowdSecの中央管理環境の恩恵を受けることができます。.

設定を確実に確認し、分類する

有効化する前に、まずどのメッセージが実際にサービスに到達しているかを確認する必要があります。ログベースのソリューションでは、ログソース、パーサー、およびSSH、メール、プロキシイベントの具体的なフォーマットを確認してください。 CrowdSec では、アクティビティが検出されただけでは不十分です。登録済みで到達可能なリメディエーションコンポーネントが、所定のファイアウォールまたはプロキシ接続に対して決定事項を伝達する必要があります。.

以下のコマンドは、Linux システム上で実行する読み取り専用の確認操作であり、各ツールはすでにシステムにインストールされている可能性があります。これらのコマンドはルールを変更したり、パッケージをインストールしたりすることはありません。これらは、現在のルールセット、登録済みの CrowdSec コンポーネント、および Debian や Ubuntu で利用可能なパッケージ候補を確認するのに役立ちます。.

nft list ruleset
sudo cscli bouncers list
apt-cache policy crowdsec

この出力だけでは、まだ保護効果は得られません。nftables において、関連する入力チェーンに期待されるフックと適切なデフォルトポリシーが設定されているか、また、既存の接続、ループバック、IPv4、IPv6、および実際のサービスポートに対するルールが定義されているかを確認してください。 また、登録済みのコンポーネントが、誤った適用ポイントに対して設定されている可能性もあります。さらに、パケット候補が検出されたとしても、そのバージョン、設定、およびパーサーがディストリビューションや自身のサービスに適合しているかどうかは判断できません。.

しきい値、ブロック期間、例外設定は、例をそのまま検証せずに本番環境に導入してはなりません。特に、共有NATアドレス、モバイルアクセス、自動化されたジョブなどは、そうしないと誤検知を引き起こす可能性があります。ネットワークイベントやシステムの動作を分析する際には、補足として LinuxモニタリングのためのeBPFトレース 役立つが、ログチェーンの検証や、利用停止に関する専門的な判断に代わるものではない。.

4つの運用シナリオに適した選択肢

世界中からSSH接続が可能な単一のVPSには、明確に定義された保護要件があります。SSHGuardは、該当するログで確認できる繰り返しの不正な接続試行を、ファイアウォールのバックエンドに報告することができます。 適度なnftablesの制限は、新規接続をさらに抑制できますが、ログインエラーを評価することはありません。優先されるのは、管理経路の制限と強固な認証であり、IPブロックはあくまで補完的な手段です。.

メールサーバーでは、SMTP、IMAP、Submissionがそれぞれ異なる認証およびログ記録の経路を経由します。 ログに基づく効率的な対応は、関連するメッセージがすべて完全に記録されている場合にのみ意味を成します。複数のシステムにわたる意思決定やログ分析を統合する必要がある場合、CrowdSecが選択肢となります。そのような必要性がなければ、明確に区切られたローカルソリューションと比較して、集中型アーキテクチャは不釣り合いなものとなります。.

Webアプリケーションの前にNginxやTraefikを配置する場合、SSH専用ツールだけでは不十分です。ここでは、 多層的な保護 HTTP検査によるネットワークアクセス：CrowdSec AppSecはLog Processorの一部であり、互換性のあるWebサーバーからのリクエストをフィルタリングできます。一方、Remediation Componentsは、Webサーバーやリバースプロキシなど、選択されたレベルで決定事項を実行します。これらの2つのタスクは、適切に連携させるとともに、個別に検証する必要があります。.

中央集約型のログ管理やKubernetesを採用した小規模な環境では、一元化されたローカルAPIや集中管理型のログ管理の恩恵を受けることができます。 しかし、それだけで運用が自動的に簡素化されるわけではありません。権限設定、インターフェースへのアクセス可能性、セグメンテーション、そして中央コンポーネントの障害への対応については、事前の計画が必要です。大規模なLinuxネットワークにおけるパケット処理や負荷分散に関する側面については、以下の記事でも取り上げられています。 Linuxサーバーネットワークにおけるレシーブサイドスケーリング. 。共通の運用プロセスを持たない少数のホストについては、ローカルな解決策の方が理解しやすい場合が多い。.

稼働中の論理ゲートを監視する

ブロックロジックを理解するには、ログデータの受信、そこから導き出される判断、そしてその技術的な実行という3つの段階を個別に検証する必要があります。 CrowdSecでは、セキュリティエンジンが設定されたログソースを読み取り、パーサーやシナリオに基づいて判断を下しますが、ブロックそのものは別のリメディエーションコンポーネントによって実行されます。.

まず、期待されるメッセージが実際に届いているかどうかを確認してください。SSHサービスの場合はログイン失敗、メールサーバーの場合はそれぞれの認証プロトコル、プロキシの場合はそのアクセスログやセキュリティログが重要です。 目に見えるイベントだけでは、防御効果が証明されたことにはなりません。ログの受信、シーケンスの認識、判断、そして有効なルールという一連のプロセスが揃って初めて、信頼性の高い診断が可能になります。.

その後、判断と登録済みのコンポーネントを個別に確認してください。CrowdSecが不審なイベントを検知しても、リメディエーション・コンポーネントが接続されていないか、または機能していない場合、その判断は効果を持ちません。 公式のエラードキュメントでは、まさにこのパターンが、セキュリティエンジンが動作しているにもかかわらずブロックが行われない原因として挙げられています。. 検知は遮断ではない.

Web保護では、さらに別のチェックが行われます。AppSecはLog Processorの一部であり、互換性のあるWebサーバーからのHTTPリクエストをフィルタリングします。Remediation Componentsは、Webサーバーやリバースプロキシなど、選択されたレベルで決定を実行します。 したがって、運用時には、拒否がHTTP検査によるものか、あるいはすでに適用された決定によるものかを判別できるようにしておく必要があります。そうすることで、エラーや誤検知を的確に調査できるようになります。.

誤警報は、多くの正当な利用者が同じパブリックアドレスを使用している場合に特に深刻な影響を及ぼします。NATゲートウェイ、モバイルネットワーク、CIシステムは、1つの送信元IPアドレスに多数の正当なログイン試行を束ねてしまう可能性があります。 したがって、実際のアクセス経路に基づいて閾値、ロック期間、例外を設定し、長いブロックリストを成功とみなすのではなく、決定の根拠や有効期限を含めて、その判断の経緯が追跡可能になるようにしてください。.

変更内容は、まず匿名化された過去のログやステージング環境でテストしてください。これにより、パーサーが想定されたパターンを正しく検出しているか、またリメディエーションが期待通りのレベルで機能しているかを確認でき、管理者のアクセス権を危険にさらすことなく検証できます。 SSHGuardはシステムログを処理し、さまざまなファイアウォールバックエンドと連携可能です。そのため、インストール環境においては、ログソースとバックエンドを一体として考慮する必要があります。.

管理された手順は、本番システムでの攻撃テストに代わるものではありません。 予想される事象、観察された判断、およびその結果として生じるルールの効果を記録し、その後、テストデータを削除するか、期間限定のエントリを通常通り期限切れにするようにしてください。そうすることで、本番環境のユーザーに対して意図的に実際のアクセス制限を発動させることなく、保護効果や発生しうる付随的な損害を検証し続けることができます。.

ログとルールのトラブルシューティング

トラブルシューティングは常にログソースから始め、そこから適用段階へと進めてください。適切なメッセージがない場合、ログパーサーもシナリオロジックやブロックロジックも確実に反応することはできません。 したがって、しきい値を変更したり、ファイアウォールルールを疑ったりする前に、サービス、ログリーダー、および実際のフォーマットを確認してください。.

CrowdSecでは、イベントや判断が可視化されているにもかかわらず、アクセスが引き続き可能である場合、その不具合の様相は明確です。つまり、エンジンによって判断が自動的に適用されていないということです。 適切なリメディエーションコンポーネントが登録され、アクセス可能であり、かつファイアウォール、Webサーバー、またはプロキシに実際に接続されているかどうかを確認してください。このコンポーネントがない場合、ブロックルールは適用されません。.

SSHGuardの場合、原因は多くの場合その前段階にあります。このツールはシステムログを集約しますが、不適切なログリーダーを使用していたり、サービスのフォーマットが想定されたパターンから外れていたりすると、有用な一致結果が得られません。 リポジトリ内の設定例には、可能な入力やオプションが示されていますが、これらは開発ブランチからのものです。そのまま採用するのではなく、パッケージのドキュメントやインストール済みのバージョンと照らし合わせて確認してください。.

nftables では、さらに、該当するチェーン内のルールが想定されたフックに配置されているか、実際のサービスポートをカバーしているか、そして必要なプロトコルファミリーに適用されるかを確認します。 このサンプルルールセットでは、IPv4とIPv6をそれぞれ独自のチェーンで分離し、確立済みの接続や関連する接続、およびループバックトラフィックを、ポート開放の前に許可しています。 IPv4専用に策定された保護策はIPv6をカバーしません。同様に、レート制限が厳しすぎると、正当な並行接続に影響を与える可能性があります。.

Ein Meterは、ソースごとに定義されたレートに基づいて新しい接続を制限し、タイムアウト付きの動的なセットエントリを管理できます。ただし、これはログイン失敗を評価するものではありません。 したがって、攻撃がレートを下回っている場合、ヒットしないことは必ずしもルールの不具合ではなく、選択したアプローチの限界である可能性があります。. フック、チェーン、測定点 期待される効果と合致していなければならない。.

変更は1つずつ行い、各ステップの後にログのエントリ、決定内容、および適用状況を再度確認してください。 ファイアウォールの設定を変更する前に、コンソール、バスティオンホスト、または分離された管理ネットワークなどを通じて、独立した緊急アクセス手段を確保してください。これにより、誤った位置に配置されたルールや、誤ったIPv6の追加によって、サーバーへの唯一のアクセスが遮断されるのを防ぐことができます。.

リスクと労力に基づいた判断

Fail2Banに代わる適切な代替手段は、一般的な順位付けではなく、攻撃対象となる範囲によって決まります。どのサービスが外部からアクセス可能か、ログイン処理を行っているか、どのログが確実に取得できるか、そして誰が設定を継続的に管理しているかを確認してください。 外部からアクセスできないデータベースサービスには、インターネットのブロックリストは必要ありません。そのネットワークアクセス権限の設定こそが、セキュリティ上より重要な判断となります。.

SSHやメールのログインエラーが繰り返し発生する、規模の小さい単一サーバーの場合、SSHGuardはログに基づく軽量なアプローチとなり得ます。 このプロジェクトは、SSHやその他のサービスに対するブルートフォース攻撃からの防御を目的としており、そのためにシステムログやファイアウォールのバックエンドを活用しています。ただし、具体的なログのカバー範囲やブロックパラメータは、インストールされているディストリビューションやサービスの形式に合わせて調整する必要があります。.

特に高速な新規接続を抑制したい場合、nftables のレート制限を適度に設定することが直接的な対策となります。メーターは送信元アドレスごとに接続数を制限することができ、次のようなルールで over 設定されたレートを超えるトラフィックを拒否します。これはログイン処理の前に実行されますが、ログインが失敗したのか、それともHTTPリクエストが悪意のあるものだったのかについて、意味的な情報を提供することはありません。.

CrowdSecは、複数のレベルや複数のホストにわたるログ分析とポリシーの適用を連携させる必要がある場合に適しています。 そのアーキテクチャはエンジンと修復コンポーネントを分離しており、中央集約型のLocal APIや一元化されたログを備えた分散型構成も可能です。この利点には、権限、可用性、セグメンテーション、および障害発生時の対応計画に関する追加要件が伴います。. 稼働性 したがって、これは機能範囲に加えて、選定基準の一つとなります。.

公開Webアプリケーションの場合、個々のHTTPリクエストを評価するには、ファイアウォールによるブロックだけでは不十分です。そのためには、適切なルールを備えた互換性のあるAppSec連携が必要です。 AppSecはログプロセッサの一部であり、互換性のあるWebサーバーからのHTTPリクエストをフィルタリングします。リメディエーションコンポーネントは、選択された適用ポイントで決定を実行します。重要なのは、保護が必要とされる対象が接続、認証イベント、あるいはHTTPコンテンツのいずれであるかという点です。.

IPベースの対策には限界があります。ボットネットは攻撃を多数のソースに分散させ、緩やかな攻撃は閾値を下回る場合があり、また共有アドレスでは、ブロック措置が関係のないユーザーにまで及んでしまうことがあります。 これらは自動化されたノイズを低減するが、タイムリーなパッチ適用、管理アクセス権の制限、および強力な認証に代わるものではない。特にSSHにおいては、鍵ベースの認証とアクセス制限が、ますます厳しくなるブロック閾値よりも優先されるべきである。.