彼のリクエストで、私はそれをハブに公開します この記事が気に入ったら、彼は喜んでhl.squirrel@yahoo.comに招待します 。
高強度のさまざまなタイプのDDoS攻撃に対する包括的な保護のためのソリューションスキームを簡単に説明します。 同様のソリューションが正常にテストされ、 stop-ddos.netサービスで動作します
このスキームは、保護システム（フロントエンド）とアプリケーションサーバー（バックエンド）の分離に基づいています。
DDoS攻撃には主に3つのタイプがあります。
- インターネット上のチャネルリソースのオーバーフローを狙った攻撃。
- 同時サーバー接続の最大数を超えることを目的とした攻撃（SYNフラッド）。
- サーバーのプロセッサ容量を使い果たすことを目的とした攻撃（頻繁に要求するページ-HTTPフラッド）。
ソリューションは、各タイプの攻撃に対する保護を提供する必要があります。
説明されている回路の写真は、記事の最後にあります。
ネットワークフラッド
これまで、通常のネットワークフラッドに対抗する最も効果的な方法は、ワイドチャネルです。 このタイプのほとんどの攻撃を撃退するには、10Gbpsチャネルで十分です。
このような攻撃中に機器を再度ロードしないように、アドレスへの余分なパケットを除外します。 たとえば、保護するサービスは、80番目のTCPポートで有効です。 この場合、宛先ポートが80以外のパケットを安全にステートレスフィルタリングできます。 CISCO 7600レベルのルーターは、これに非常に適しています。
ただし、少なくとも1Gbpsの幅のバックアップチャネルを忘れないでください。
SYNフラッド
ステートフルファイアウォール（SFFW）を使用して、SYNフラッドから身を守ります。
理想的には、ハードウェアファイアウォール（たとえば、Juniper SRX 5800）。 予想される攻撃力に応じて、必要な数のファイアウォールが選択されます。 保護の入り口にあるルーターで、保護するネットワーク（図では2.1.1.0/24）のルートが各SFFWのネクストホップアドレスとともに作成されます。
各SFFWには、次のルーターへの静的ネットワークルート1.1.1.0があります。 最後の保護レベルのノード、つまりUNIXシステムを備えたサーバー間で負荷を分散します。
この場合、BGP動的ルーティングプロトコルを使用すると便利です（1つのノードに障害が発生した場合、負荷は作業ノード間で自動的に分散されます）。 したがって、各サーバーは、ネクストホップセルフを使用してネットワーク1.1.1.0へのルートをルーターに通知します。
HTTPフラッド
このレベルの保護に到達したパケットは、リバースプロキシに送られます。 ボットと実際のクライアントを区別できるプロキシサーバーである必要があります。 たとえば、ログアナライザーを備えたnginx、あるアドレスからの同時接続数と、ユーザーが発明または発見した他の方法との組み合わせ。 そのようなソリューションの例はすでにHabrで公開されています。
プロキシで、例に示すようにポリシーベースのルーティングを構成します。 これにより、バックエンド要求がステートフルファイアウォールを2回通過するのを防ぎます。
次にバックエンドについて。 フロントエンドからのリクエストの送信先アドレスは、サーバーが管理されるアドレスとは異なる必要があります。 管理アドレスが強調表示されている場合（たとえば、アプリケーションによって生成された文字によって）、管理アドレスをいつでもブラックホールに投げることができ、これはアプリケーションの動作に影響しません。
実際には、図に示されている数のルーターを使用することは意味がありません。 代わりに、単一のデバイスを複数のルーティングテーブル（VRF、ルーティングインスタンス）または複数の論理ルーターを持つルーターとして使用する方が合理的です。
ハードウェアステートフルファイアウォールもこのスキームから除外でき、プロキシの代わりにSYNプロキシモードでPFを使用します（このモードのPFはネイティブOpenBSDで最高のパフォーマンスを示します。Linuxの場合はPFを完全に拒否し、必要に応じてsysctlを設定するだけです。 ） ただし、この場合のサーバーの数を増やす必要があります。
メール
受信メールをGoogle MXに送信して（誰かがそれらを絞め殺してみてください:)）、fetchmailでサーバーに返送するのが最も有利です。 DNSはホストされないことも最適です。大規模な外国のレジストラは、購入したドメインのNSとしてかなりフェイルセーフなクラスターを提供します。 また、有料で、NSサーバーでドメインをホストできます。
PS
転送、ありがとう！
UPD。 コメントへの回答は、記事の著者によって与えられます。