私はロードバランサーの背後で数百台のウェブサーバーを運用し、多数のアプリケーション（私が制御できないもの）を備えたさまざまなサイトをホストしています。月に 1 回程度、サイトの 1 つがハッキングされ、銀行や政治機関を攻撃するためのフラッド スクリプトがアップロードされます。これまでは、これらは常に UDP フラッドであり、個々のウェブサーバーで送信 UDP トラフィックをブロックすることで効果的に解決されていました。昨日、ポート 80 への多数の TCP 接続を使用して、当社のサーバーから米国の大手銀行にフラッド攻撃が始まりました。これらのタイプの接続は当社のアプリケーションにとって完全に有効であるため、単にブロックするだけでは受け入れられる解決策ではありません。
以下の代替案を検討しています。どれをお勧めしますか? これらはすでに実装しましたか? また、どのように実装しましたか?
- ウェブサーバー (iptables) の送信 TCP パケットの送信元ポートが 80 以外の場合の制限
- キューイングあり（tc）
- サーバーごと、ユーザーごとの送信トラフィックのレート制限。アプリケーション サーバーごとに 1000 人もの異なるユーザーがいる可能性があるため、管理上の負担はかなり大きくなります。たとえば、次のようになります。ユーザーごとの帯域幅を制限するにはどうすればよいですか?
- 他に何か？
当然のことながら、ハッカーが当社がホストするサイトに侵入する可能性を最小限に抑える方法も検討していますが、そのメカニズムが 100% 完全に保護されることはないため、侵入の影響を厳しく制限したいと考えています。
更新: 現在、この特定の攻撃を防ぐためのルールをテストしています。ルールをより汎用的にするにはどうすればよいでしょうか? SYN パケットのみにレート制限をかけると、既知の TCP DoS 攻撃を見逃してしまうのでしょうか?
iptables -A OUTPUT -p tcp --syn -m limit --limit 100/min -j ACCEPT
iptables -A OUTPUT -p tcp --syn -m limit --limit 1000/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A OUTPUT -p tcp --syn -j REJECT --reject-with tcp-reset
乾杯！
答え1
私の意見では、最善の解決策であり、私にとって非常にうまく機能した解決策は、宛先 IP の接続/パケット数を制限することです。制限を適切なレートに設定すると、攻撃者が大量の接続をターゲットに送信するのを防ぐことができます。ポートとプロトコルを設定するのは良い考えではありません。なぜなら、攻撃者が今日 HTTP フラッドを送信している場合、明日は別の種類の攻撃を使用するからです。したがって、一般的に IP ごとに接続を制限することが問題の解決策になります。
役に立つと嬉しいです:)
答え2
私が常に取ってきたスタンスは、Web サーバーは発信 TCP 接続をまったく行うべきではなく、着信要求に応答するサーバーとしてのみトラフィックを送信するというものです。(また、着信 TCP は Web サーバーと SSH のみに許可しています。) (これに関連して、Web サーバーはメールを送信するホストとして適切ではないとも考えています。) これにより、発信攻撃が防止されるだけでなく、システムへの攻撃も少し難しくなります (ハッカーは xterm ウィンドウを取得したり、ツールキットをホストに wget で取得したりできなくなります)。