HAProxyを使用してDDoS攻撃を軽減する
今日、私たちはDDoS攻撃の標的にされました。ロードバランサー（HAProxy）には通常の20倍の接続があり、この攻撃の間、すべてのバックエンドノードがダウンし続けました。
System structure: HAProxy > Squid > Apache (for ModSecurity) > IIS app layer.
攻撃中に、ApacheでMaxClients Reachedエラーが発生したことに気付いたので、設定を150から250に上げました。ある程度。ただし、バックエンドを回復するには、Apacheを手動で再起動し続ける必要があるようでした。攻撃は約50分間続きました。
攻撃が収まり始めた後、各ノードで最後にApacheを再起動すると、グリーンになりましたが、そもそもなぜそれが発生したのかを調べています。 Apacheのエラーログには、次のようなものがたくさんあります。
[Wed Jun 22 11:46:12 2011] [error] [client 10.x.x.x] proxy: Error reading from remote server returned by /favicon.ico
[Wed Jun 22 11:46:13 2011] [error] [client 10.x.x.x] (70007)The timeout specified has expired: proxy: error reading status line from remote server www.example.com
Apacheはデフォルトのキープアライブ設定を使用しています（キープアライブが有効になっていて、タイムアウトが15秒に設定されています）。 HAProxy +キープアライブで追加の読み取りを行った後、キープアライブが有効になっているためにDDoSが悪化したと考えるのは合理的な結論ですか？
HAProxyの最大接続数はApacheで設定された最大値をはるかに下回っていますが、おそらく20x接続では、古いDOS方式で開かれている接続が多すぎますが、Apacheはそれらを開いたままにしていました。
最初の「攻撃」から数週間で問題がさらに数回発生した後、DDoSを警官として使用していた可能性があると思ったので、さらに深く掘り下げる必要がありました。
アクセスログとnetstatスナップショット（ログファイルに追加された接続数で並べ替えられた上位N個のIPを取得）は確かに非常に分散した量のIPアドレスを示していましたが、疑わしいと思われるアクセスログの特定のページを特定できました。
どうやら、開発チームは、AJAXを介してサードパーティのAPIリクエストを処理するために「プロキシ」ページを作成していました。問題は、このプロキシページがHAProxyの貴重な接続スロットを使い果たしていたことであるようです。サードパーティのサービスでAPIリクエストの処理に問題が発生すると、タイムアウトするまで非常に長い時間がかかります。最終的に、長時間のプロキシリクエストにより、HAProxyバックエンドが最大制限に達しました（したがって、すべての新しいリクエストがキューに入れられました）。その時点から、接続数がネットワーク上で増加し始め、公開されているWebサイトが通常の非AJAXリクエストのタイムアウトを開始しました。
私たちの場合の解決策は、これらのAJAX呼び出し専用にHAProxyに追加のバックエンドを作成することでした。次にサードパーティのサービスに問題が発生したときは、AJAXプロキシページが呼び出され、サイトの残りの部分は引き続きハミングします。
答えてくれてありがとう。ほとんどの人は「実際の」DDoS攻撃を軽減することに気を配っていたと思いますが、他の読者にとっては、自分が足を撃っていないことを確認するために内部を調べる価値があることを知っておくと役に立ちます。
私はあなたがこのシナリオの間違った潜在的な修正を追いかけていると思います。 DDoSされている場合、緩和策の唯一の実際のルートは、アップストリームプロバイダーと通信し、ネットワークに到達する前にトラフィックをヌルルート/ブラックホール化することです。そうしないと、何をしても、ネットワークのエッジに到達し、（おそらく）エンドで接続が飽和状態になる可能性があります。
唯一行うことは、ネットワークのエッジに到達する前にブロックすることです。トラフィックが無視/ブロック/ドロップされる前にネットワークに到達する必要があるため、どのような種類のDDoS緩和シナリオもそれほど有用ではない可能性があります。その結果、それでも帯域幅を消費します。
さらに、これらすべての子プロセスに使用できる十分なメモリが実際にない場合は、使用可能なワーカーの数を増やすだけで問題が悪化する可能性があります。ディスクへのスワップを開始すると、マシンは停止します。 mod_evasiveやmod_securityについても誰も言及していないことに驚いた。計算量の多いリソースへのアクセスをブロックする自動化されたヒューリスティックを使用すると、アップストリームでnullrouteを実行できない、または実行できない場合に非常に役立ちます。
編集：これはコメントでしたが、@ TomO'Connorの提案に従って答えに変えました。
@Tom O'Connorこれは、帯域幅/ ppsタイプのDDoSではありません。単純なサービス拒否のように聞こえます。
キープアライブはさらに悪化します。ここでの問題は、Apacheが要求を必要な速度で処理できず、要求に追いつくことができない多くのワーカーを生成することです。これが大きくなるにつれて、攻撃が続く場合、回復の可能性はほとんどゼロになります。
明らかにMaxClientsディレクティブを増やすことができますが、説明した内容から、1〜2分後にダウンするだけです。
実行しているスタックはわかりませんが、0.010秒以内に読み込まれる単一のリクエスト（PHPを実行していますか？MySQLに接続していますか？キャッシュしていませんか？）に対するApacheの応答を改善することが目標です。 MySQLで大量のコンテンツを検索し、リクエストごとに2秒で終了するサービス拒否.vsページへの応答が100倍向上します。
誰かが100のリクエストを行った場合、サーバーは200秒間動作する必要がありますが、一度にすべてを実行するため、2秒/リクエストは40秒/リクエスト* 100になります。リクエストが増えると、負荷が増えます。
これに対処する別の方法は、上位のxyz接続を識別し、それらを単にブロックすることですが、これは少し注意が必要であり、適切に試行するにはもう少し知識が必要です。