UDPフラッド攻撃を緩和する方法は？
私の友人は私にあなたが$ 5.00/mを払ってたくさんの'dos stresser'を提供するツールudp flooding、およびその他の悪意のあるフラッダー。これはウェブベースのシステムで、IPを入力するだけで完了です。それは文字通りそれほど悲しいことです。
私の問題は、Linux vpsでiptablesの背後にいて、すべてのUDPパケットをドロップしている場合でも、それらのパケットがサーバーにヒットすることです。ソフトウェア層（またはクライアントサーバー）に到達できないように、物理層または物理ファイアウォールで着信UDPパケットをブロックする方法はあるのでしょうか？それが理にかなっている場合：P。私はこれを説明しようとするのが非常に苦手です。
ありがとう！
あなたの説明は大丈夫です！私はあなたの質問を理解したと思います。
DDoSミティゲーションは、通常、インターネット接続の上流にミティゲーションデバイス/システムを配置することで機能します。これらのサービスについては、ProlexicなどのDDoS軽減サービスを契約できます。または、任意のベンダーからのDDoS軽減がすでに含まれているクラウドプロバイダーを利用できます。
パケットがネットワーク上の次のホップにフラッディングする可能性があるため、サーバーから物理レベルでDDoSを軽減することは不可能です。 ISPのローカルスイッチ。そのため、必要なすべてのパケットをドロップできますが、パケットはISPスイッチからネットワークに送信され、帯域幅を利用しています。したがって、攻撃を緩和するには、パケットをアップストリームでドロップする必要があります。
小規模なWebサイトの場合は、CloudFlareのようなプロキシサービスを使用できます。実際、これは、非常に大きなサイズに達するまで、多くの人に推奨されるソリューションです。 CloudFlareは、ドメインのDNSを制御することで機能します。次に、DDoS攻撃に耐え、XSSやSQLインジェクションなどの他の一般的なハッキング攻撃を阻止するために大幅に強化されたネットワークとサーバーを介して、すべてのWebトラフィックをプロキシします。正当なトラフィックはWebサーバーに転送され、疑わしいトラフィックは上流でドロップされるため、潜在的なDDoSの影響を受けません。
一般に、パケットのフラッドを軽減するためにできることは3つあります。
- サーバーが着信パケットを処理するために過剰なリソースを必要としないことを確認してください。まともなサーバーは、1 Gbit/sのエコー要求に簡単に応答できます。ただし、未確認の送信元アドレスからの着信UDPパケットが大量のメモリとCPU能力を必要とする計算を開始し、最終的に複数のUDPパケットを使用してクライアントに応答を転送する場合、サーバーは簡単なターゲットになります。注意する必要があるのはアプリケーションだけではありません。ファイアウォールルールがある場合は、そこでの各パケットの処理量にも注意してください。
- 十分な帯域幅がある。受信したパケットは、パケットの処理方法に関係なく受信帯域幅を消費するため、十分な受信帯域幅を確保することが重要です。
- トラフィックに対してフィルターを後方にプッシュします。これには、プロバイダーからの協力が必要です。正当なトラフィックとフラッドを区別するために使用できる簡単に認識できるパターンがある場合は、リンクが過負荷にならないようにフィルターを早期に適用できます。
上記の緩和策は、直接攻撃されている場合と、リフレクション攻撃の被害者である場合の両方に適用されます。その性質上、リフレクション攻撃はより強力になる可能性がありますが、リフレクション攻撃に対して行うことができるより多くの対策もあります。
リフレクション攻撃について
まず最初に、リフレクション攻撃がどのように機能するかを理解することが重要です。リフレクション攻撃は、攻撃を受けたときにそれを認識する可能性があるからです。
- 攻撃者は、スプーフィングされたソースIPアドレスを含むパケットをサービスに送信します。
- サービスは要求を処理し、要求より大きい応答を偽装されたソースIPに送信します。
- 最終的なターゲットは、攻撃者が直接生成できたよりも大きなパケットのフラッドを受け取ります。
- 返信が認識されないため、ターゲットはエラーメッセージをサービスに送り返します。
- エラーメッセージは進行中の操作に関連しないため、サービスは無視します（サービスの観点から、この要求はステップ2で処理され、忘れられました）。
ステップ2で言及したサーバーは、リフレクターとも呼ばれます。通常、攻撃はUDPベースのサービスを実行しているリフレクターを標的にします。多くの場合、DNSが標的にされ、EDNSおよびDNSSECを悪用する攻撃は特に効果的です。 NTPは、少なくとも1回は非常に効果的なリフレクターであることが証明されています。
管理者が何が起こっているのか理解していない場合、リフレクターとターゲットの管理者が互いに非難することは非常に簡単です。 2人の犠牲者が互いに非難し、それぞれが他の犠牲者が攻撃者であると想定することは、あまり生産的ではありません。理想的には、この2人の管理者が協力して攻撃を緩和します。
あなたがリフレクション攻撃の最後のターゲットである場合、通常は多数のリフレクターを扱います。各リフレクターの管理者と個別に作業することは、あまり生産的でない場合があります。また、リフレクターの管理者は悪意のあるわけではありませんが、怠惰な場合があることにも注意してください。
リフレクション攻撃に対する追加の対策
リフレクション攻撃に対する保護は、プロトコル設計から始まっています。クライアントアドレスがまだ確認されていない場合は、そのIPアドレスから受け取った以上のパケットまたはバイト数をそのIPアドレスに送信しないことが重要です。リフレクション攻撃は、応答が要求よりも大きいプロトコルで効率的です。
TCP=上で動作するプロトコルは、この問題を考慮する必要はありません。TCPハンドシェイクは、ほとんどのプロトコルよりもリフレクション攻撃に対してより堅牢です。下位層で動作するプロトコルのみTCPまたはUDPのようなより上に、反射を防ぐ必要があります。
すでに指定されたプロトコルを実装する場合、最初にプロトコルを十分に理解して、リフレクションに対する保護がある場所とない場所を正確に知る必要があります。プロトコルで指定されたリフレクションに対する保護は安全に実装する必要があります（ほぼ確実に、優れた乱数ジェネレータを使用する必要があることを意味します）。
さらに、実装しているプロトコルでリフレクションに対する保護が不足している場所を理解する必要があります。このような場合、緩和策をコードに実装する際には注意が必要です。
上記のリフレクション攻撃中に何が起こるかについての説明では、最後のステップはエラーメッセージを無視するサービスでした。これを無視する代わりに、サービスはこのようなエラーメッセージを潜在的なリフレクション攻撃の兆候として使用し、必要な対策を講じることができます。悲しいことに、そのような対策は広まっていません（誰かがそれらを適用したかどうかはわかりません）。
リフレクターとして使用される可能性のあるサービスを展開する管理者は、自分が何をしているかを理解する必要があります。このようなサービスは、必要な場合にのみデプロイしてください。進行中のリフレクション攻撃に注意を払い、可能な限りリフレクション対策を備えた実装を使用してください。
一般に、管理者は、予期しない、または無効なIP、プロトコル番号、またはポート番号に向けられたパケットに応答して、システムが適切なICMPエラーメッセージを送信するようにします。また、ICMPエラーメッセージがレート制限されていることを確認してください。
閉じたポートをターゲットとするすべての着信パケットに対してICMPエラーメッセージを送信すると、問題が発生する可能性があります。これは、ICMPエラーメッセージにトリガーパケットのコピーが含まれているため、元のパケットよりも大きくなるためです（結果が非常に大きくなって切り捨てられない限り）。受信するよりも多くのバイトを送信することにより、着信フラッドを発信フラッドに変えるリスクがあるだけでなく、リフレクターとして使用できるホストもできます。
ICMPエラーメッセージを送信することができたパケットの半分だけを送信すれば、発信バイトと発信パケットの数を着信よりも確実に少なくすることができます。したがって、ICMPエラーメッセージが反射ベクトルとして使用されるのを防ぎます。そして、それでも緩和の一部として使用できるという意味で十分なエラー応答です。
ICMPエラーメッセージを完全に無効にしないでください。これにより、自分とユーザーが接続の問題をデバッグすることがより困難になります。場合によっては、無効にされたICMPエラーメッセージが接続の問題の原因になることもあります。また、上記のリフレクション攻撃に対する緩和策も防止します。リフレクタのごく一部でもこのような緩和策を実装している場合は、ICMPエラーメッセージを価値のあるものにするだけで十分です。