iptables 文字列マッチングの実現可能性。fail2ban での使用が可能

Question

ロード バランサーと CDN フロント エンドの背後に複数の Apache 2.4 Web サーバーがあり、HTTPS が終了しています。バックエンドの Apache ログには、フロント エンドからのヘッダーにクライアント IP が表示されます。Web サーバー マシンで iptables の文字列マッチングを使用して、特定のヘッダー (つまり、クライアント IP が含まれているヘッダー) のみに基づいて IP をブロックすることは可能でしょうか。

当社の Linux カーネルは最新であり、iptables カーネル モジュールは CONFIG_NETFILTER_XT_MATCH_STRING=m でコンパイルされています。

文字列の一致がクライアント IP を含む特定のヘッダーを超えて一致すると、CPU を集中的に使用し、意図しない結果が生じる可能性があると読みました。または、プロキシなど、これを実現するより優れたツールがあるようですが、Apache や fail2ban で iptables の文字列一致機能を使用している他のユーザーの体験について、さらに詳しく知りたいと思います。

理想的にはApacheはnginxの444のようなものを持っているはずです。IPに403を与えることができますヘッダーのIPの一致に基づいてしかし、444 の接続ドロップは、403 に比べてレベルが低く (より突然/望ましい)、リソースをあまり消費しないようです。しかし、本当にそうなのか疑問に思います。444 は 403 に比べてリソースを多く消費するのでしょうか?

ご意見をいただければ幸いです。

Answer 1

fail2ban と関連ロジックがバックエンド サーバーで実行されている場合、簡単な解決策はありません。

最初のステップはApacheを使うことだと思いますmod_remoteip; すると、バックエンド サーバーの Apache ログには、フロントエンドやロード バランサーの IP アドレスではなく、実際のクライアント IP が含まれます。

Apache はデフォルトで、接続のclient_ip値を使用してユーザーエージェントを識別し、接続remote_hostはremote_lognameこの値から派生します。これらのフィールドは、他のロード可能なモジュールによる認証、承認、ログ記録、およびその他の目的で役割を果たします。

mod_remoteip は、リクエストの期間中、接続のクライアント IP を、プロキシまたはロード バランサによって提供されるアドバタイズされたユーザー エージェント IP で上書きします。ロード バランサは、サーバーとの長期キープアライブ接続を確立する可能性があり、ロード バランサの基盤となるクライアント IP アドレスが変更されない場合でも、各リクエストには正しいユーザー エージェント IP が含まれます。

その後、Apacheログファイルに対してfail2banを簡単に実行して、問題のあるIPを特定できます。

次に、カスタムそして適切なfail2ban禁止措置バックエンド サーバーから発行されると、問題のある IP をブロックします。たとえば、フロントエンドの前のファイアウォールへの API 呼び出しで、問題のある IP をブロック リストなどに追加できます。