8

SSDP M-SEARCHクエリに応答する必要があるデバイスを実装しています。

私はデバイス ベンダーであり、これらのデバイスが展開される場所を制御できません。

SSDP 検索増幅を使用する既知の DDoS 攻撃があります。つまり、攻撃者が偽のアドレスから検索要求を送信し、不十分にコーディングされた SSDP サーバーがその偽のアドレスに応答します。偽のアドレスは打ちのめされます。

デバイスがこのような攻撃に使用されないようにするにはどうすればよいですか?

  1. TTL=2 のみを設定し、ルーターに依存してパケットをドロップする
  2. 自分のサブネットからのリクエストにのみ応答する
  3. 有効なクエリ元サブネットの構成オプションを追加します
  4. 「ローカル」と「グローバル」の IP アドレスを推測する
  5. 応答スロットルを追加します。最善を尽くします
  6. あなたの提案は？

Wrt 1. TTL は SSDP 仕様ごとに構成可能にする必要があります。応答がかなり低い場合でも、ローカル ネットワークから漏れます。ネットワーク上にブリッジされた VPN がある場合、応答はかなり遠くまで漏れます。

Wrt 2. 複数のサブネット (たとえば、ワイヤレス クライアント用の 1 つのサブネット、デスクトップ用の別のサブネット、さらにサーバー用の別のサブネット) に到達可能な企業ネットワークを想像できます。そのため、デバイスはサブネット全体で検索可能でなければなりません (ただし、仕様ごとに TTL の対象となります)。

Wrt 3. 構成とメンテナンスの手間。

Wrt 4.それを行うための信頼できる方法はありますか? IPv6はどうですか？たとえば /28 スライスのグローバル アドレスを持つネットワークについてはどうでしょうか。

Wrt 5.無数のデバイスからのトリクルは、依然としてトレントに相当します...

参照: https://blog.sucuri.net/2014/09/quick-analysis-of-a-ddos-attack-using-ssdp.html

4

1 に答える 1

3

別のオプションは、ユニキャスト要求にまったく応答しないことです。ただし、これが許可されていることを明示的に示す情報源を提供することはできません. ドラフトの 1 つは確かにそうであるかのように読めます。また、そうであったとしても理にかなっています。結局のところ、これは発見プロトコルです。

正常なデフォルト設定ではマルチキャストはデフォルトでルーティングされず、239.0.0.0/8 はorganization-localであるため、マルチキャスト アドレスに到着するリクエストは本物であると安全に想定できます。(もちろん、自分のネットワークに攻撃者がいる場合を除きますが、それは別の問題です。)

Linux では、ソケット オプションを使用して受信 UDP パケットを検査しIP_PKTINFO、実際にマルチキャスト アドレスに送信されたことを検証できます。

https://stackoverflow.com/a/5309155/705086 http://www.linuxquestions.org/questions/programming-9/how-to-get-destination-address-of-udp-packet-600103/

于 2015-09-17T10:20:12.427 に答える