Linux：発信TCPフラッドを防止する

ロードバランサーの背後で数百のWebサーバーを実行し、多数のアプリケーション（多数のアプリケーション）をホストしています（これらのアプリケーションは制御できません）。毎月1回程度、サイトの1つがハッキングされ、洪水スクリプトがアップロードされて銀行や政治機関を攻撃します。以前は、これらは常にUDPフラッドでしたが、個々のWebサーバーで発信UDPトラフィックをブロックすることで効果的に解決されました。昨日、彼らはポート80への多くのTCP接続を使用して私たちのサーバーから米国の大規模な銀行をあふれ始めました。これらのタイプの接続は私たちのアプリケーションにとって完全に有効であるため、単にそれらをブロックすることは許容できる解決策ではありません。

以下の代替案を検討しています。どちらをお勧めしますか？これらを実装しましたか？

• 送信元ポートが！= 80のWebサーバー（iptables）送信TCPパケットの制限
• 同じだがキューイング（tc）あり
• サーバーごとのユーザーごとの発信トラフィックのレート制限。アプリケーションサーバーごとに数千人のユーザーが存在する可能性があるため、かなりの管理上の負担。多分これ：ユーザーごとの帯域幅をどのように制限できますか？
• 他に何か？

もちろん、ハッカーがホストされたサイトに侵入する可能性を最小限に抑える方法も検討していますが、そのメカニズムが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

乾杯！

私の考えにとって最良の解決策であり、私にとって非常にうまく機能している解決策は、宛先IPの接続/パケットの数を制限することです。制限を適切なレートに設定すると、攻撃者は大量の接続をターゲットに送信できなくなります。ポートとプロトコルの設定は良い考えではありません。攻撃者が今日httpフラッドを送信している場合、明日は別の種類の攻撃を使用するからです。したがって、一般的にIPごとの接続を制限することは、問題の解決策になります。

それが役に立てば幸いです:)

私が常に取っているスタンスは、Webサーバーが送信TCP接続をまったく行うべきではなく、受信要求に応答するサーバーとしてのみトラフィックを送信することです。（ウェブサーバーとSSHに対してのみインバウンドTCPも許可します。）（これに関連して、ウェブサーバーがメールを送信するのに適切なホストになることは決してないと思います。）これは、アウトバウンド攻撃を防ぐだけではなく、少し困難も加えます。システムで行われた攻撃に対して（ハッカーはxtermウィンドウを取得したり、ツールキットをホストに送信したりできません）。