解決策 1:
DDOS (または DOS) は、本質的にリソースの枯渇です。ボトルネックを遠ざけることしかできないため、ボトルネックをなくすことはできません。
AWS では、ネットワーク コンポーネントが非常に強力であるため、幸運です。アップストリーム リンクが飽和していることを知ると、非常に驚くでしょう。ただし、CPU とディスク I/O はフラッディングしやすくなります。
最善の方法は、いくつかの監視 (SAR などのローカル、Nagios および/または ScoutApp を使用したリモート) といくつかのリモート ロギング機能 (Syslog-ng) を開始することです。このようなセットアップを使用すると、どのリソースが飽和状態になるかを特定できます (Syn フラッドによるネットワーク ソケット、不適切な SQL クエリまたはクローラーによる CPU、および … による RAM)。 EBS ボリュームにログ パーティション (リモート ロギングが有効になっていない場合) があることを忘れないでください (後でログを調べるため)。
攻撃が Web ページ経由で行われた場合、アクセス ログ (または同等のもの) が非常に役立ちます。
解決策 2:
EC2 インスタンスを Elastic Load Balancer の背後に置き、ELB インスタンスからのトラフィックのみを受け入れることで、EC2 インスタンスをさらに分離することもできます。これにより、DDOS 攻撃を管理する Amazon の責任が大きくなります。
SSH は引き続きすべての人に開かれていると思います。そのため、そのポートをいくつかの静的 IP にロックダウンできない限り、そこに不正なトラフィックが入ってくる可能性があります。 SSHd ポートをもっとわかりにくいもの (つまり、22 以外のもの) に変更して、DDOS ヒットをさらに減らすことができます (ほとんどのボットは既知のポートのみをチェックします)。
また、ログを監視し、IP テーブルを一時的に変更して特定の IP をブロックできる fail2ban についても言及します (たとえば、単一の IP アドレスからホストへの SSH 接続に 6 回失敗した場合、その IP を 30 秒間ブロックできます)。分かそこら）。 (Jordan が鋭敏にコメントしたように) fail2ban は、必ずしも元のリモート IP ではなく、プロキシの IP をブロックするため、プロキシされたトラフィック (ELB からのトラフィックなど) をブロックするのにはおそらく適切ではないことに注意してください。
私は使用していませんが、Apache mod_evasive も調査する価値があるかもしれません。ただし、IP ベースのブロックに関しては、fail2ban と同じ弱点がある可能性があります。
解決策 3:
Apache を使用している場合は、mod_security を使用することをお勧めします。ほとんどのベンダーによってパッケージ化されているコア ルール セットは、素晴らしい仕事をします。
もう 1 つの強化ステップは、Web サーバー レベルでリクエストを制限することです。 Nginx.、Apache は受信リクエストを調整および制限できます。
解決策 4:
AWSなどから出てくるリアルタイムの悪いアクティビティIPをブロックするために使用するソリューションはこれです... LFDブロックリストの構成にある私のCSFファイアウォールでは、ここにあるリストを使用します - http://myip.ms/browse/blacklist/ Blacklist_IP_Blacklist_IP_Addresses_Live_Database_Realtime
CSF ファイアウォールのブラックリストをダウンロード » http://myip.ms/files/blacklist/csf/latest_blacklist.txt
とてつもなく不快な AWS トラフィックはもうありません。
解決策 5:
私はコンテンツ配信ネットワークでセキュリティ プリセールス エンジニアとして働いているため、偏見があります。
ただし、コンテンツ配信ネットワークで Ddos 緩和ソリューションを利用すると、オリジンでリソースが不足することはありません。これは、サイトの前に F5 ロード バランサーを配置するのと似ていますが、世界中の何千もの場所に分散されます。
優れた cdn を使用すると、aws ファイアウォールにインストールするホワイトリストでオリジンをクロークできます。そのため、攻撃者が Amazon で偵察を行うと、すべてがブロックされるため、IP アドレスは空になります。
そのため、攻撃者にできるだけ近いノードにトラフィックが到達すると、Ddos 攻撃がブロックされます。これにより、保護しようとしている資産から遠く離れた場所で Ddos 攻撃を軽減できます。
優れた cdn は、ヘルス チェックを実行し、トラフィックを他の場所にフェールオーバーすることもできます。たとえば、お尻、Azure、ラック スペース、ソフト レイヤー、物理 DC などの別のエゴです。 RUDY、slowpost、slowloris、および sqli、xss、rfi、lfi など。
デフォルトでは、cdn は、ティアドロップ、icmp 攻撃、synfloods などのネットワーク層攻撃もブロックします。trey には、要求を受け入れ、悪いトラフィックを除外し、良いトラフィックを渡すための膨大な容量があるため、cdn は Ddos 攻撃を軽減できます。 ntp、DNS、ssdp、chargen、snmp ボリューメトリック攻撃などの増幅攻撃をブロックできます。
これまでに確認した最大の攻撃は、2014 年 7 月の 321 Gbps でした。この攻撃では、20 Gbps での DNS プロトコル攻撃もありました。そのため、膨大な数のリクエストに耐えられるよう、DNS インフラストラクチャの回復力も確保する必要があります。
あなたが提供した説明から、攻撃者が Web サーバー、アプリ サーバー、またはファイアウォールですべてのスレッドを消費するように多くのスレッドを開いた、枯渇攻撃を受けたようです。スローポストとかスローロリスとかRUDYとかに似てる。
アプリケーション層枯渇攻撃をブロックするには、Web アプリケーション ファイアウォール (WAF) を取得する必要があります。一般的なネットワーク ファイアウォール (Amazon ファイアウォールや次世代ファイアウォールを含む) ではブロックできません。最近の Sent work ファイアウォールは、最近のすべての攻撃の約 30% しかブロックできません (2014 年 11 月)。