DNS増幅攻撃を検出/回避するにはどうすればよいですか？
私は開発者であり、アプリケーションがDNS増幅の種類の攻撃に耐えられるようにするために何ができるかについて洞察を得ようとしています。そのような防止方法は、DOSタイプの攻撃にも役立ちますか？そのような攻撃の検出、防止、風化に対する業界のベストプラクティス、ガイドラインは何ですか。一般的な落とし穴はありますか？
検出
リフレクションDNS攻撃の目的は、正当なトラフィックをドロップさせるために、ホストに大量のネットワークトラフィックを送信することです。攻撃者がターゲットの帯域幅を超えるのに十分な帯域幅を自分で制御していない場合に選択されます。損傷は通常、パケットがサーバーに到達するまでにすでに発生しているため、ターゲットがDNSサーバーを実行しているかどうかはほとんど関係ありません。
表示される最初の症状は、サーバーがネットワーク経由で応答しないことです。アウトオブバンド接続（物理的にキーボードの前に座っている、iLOM、ALOM、iDracなどを使用している）の場合、サーバーの負荷はおそらく低くなります。
反映されたDNS攻撃の疑いがある場合は、tcpdumpを使用して、要求していない多数のDNS応答の到着を探すことができます。リクエストとレスポンスの追跡は難しい場合がありますが、anyリクエストを作成していない場合、すべてのレスポンスは攻撃の一部です。
tcpdump -A -n dst port 53 and not Host <local IP address>
-nオプションはDNSルックアップを行わないようにtcpdumpに指示するため、ここでは重要です。このような攻撃ではタイムアウトになります。 <local IP address>は、送信IPアドレスに置き換えてください。
サバイバル
実際にネームサーバーを実行している場合、送信元ポートのランダム化は、これらの偽の応答が引き起こす負荷を軽減するのに役立ちます。 Dan Kaminskyがコラボレーションを率いました 数年前、それにより、これがすべての現代のネームサーバーの標準的な部分になりました。
一部のステートフルファイアウォールは、UDP「セッション」を追跡できます。確立されたセッションの一部ではないポート53の受信をすべてドロップするようにファイアウォールを構成すると、偽の応答がマシンの有効なサービスに到達できなくなり、パケットを処理する必要がなくなります。 DROPルールは、ここではREJECTルールよりも優れています。REJECTルールは、実際に偽のDNS応答を送信するICMP応答を送信します（帯域幅をより多く使用します）一方で、DROPルールは、その場ですべてを停止し、無駄にしません。追加の帯域幅。
ネームサーバーを実行していると仮定して、キャッシュがオンになっていて機能していることを確認してください。 （実際、とにかくこれを実行してください。上流のサーバーに感謝します。）
残念ながら、ホスティングプロバイダーの帯域幅が使い果たされている場合、これらの3つはほとんど海の低下です。これはよくあることです。
帯域幅ベースのDoSを生き残るための2つの最も成功した戦略は、
- 攻撃者よりも帯域幅が広い。
- する人を雇う。
ボトルネックがホスティングプロバイダーのネットワーク内にある場合、「宛先ポート53のすべての受信UDPパケットをドロップする」などの具体的かつ正確なものを提供できる限り、トラフィックをさらにフィルタリングできる可能性があります。
それがネットワークの外部またはエッジにある場合、またはそれらのトラフィックをそれほどフィルタリングできない場合、次のステップは、DoS攻撃の軽減に特化した企業です。最近は数多くの選択肢があり、個人的な経験がなければ、どれもおすすめできません。 ServerFaultのクイックリスト があります。一般的なコンセンサスは、それらは高価ですが、多くの場合、ダウンタイムまたは攻撃の直後の恐喝リクエストよりも少ないということです。
攻撃を受けた場合の注意点として、攻撃者がデータを盗み出す前/後/その間にDoSが迂回することがあるという報告を耳にしました。
少し時間をかけて、次のサイトにアクセスしてください。 http://bindguard.activezone.de
このツールは、名前付き（BIND）に対するDNS攻撃を破棄するために開発されました。詳細については、上のページをご覧ください。ファイアウォールルールは必要ありません。
（開示-私はバインドガードと提携しています）