Wie kann man SSDP-Reflection / Amplification-Angriffe richtig verhindern?

8

Ich implementiere ein Gerät, das auf SSDP M-SEARCH Abfragen antworten sollte.

Ich bin ein Gerätehersteller und habe keine Kontrolle, wo diese Geräte bereitgestellt werden.

Es gibt einen bekannten DDoS-Angriff, der SSDP-Suchverstärkung verwendet, dh Angreifer sendet Suchanfragen von einer gefälschten Adresse und schlecht codierter SSDP-Server antwortet auf diese falsche Adresse. Gefälschte Adresse endet gehämmert.

Was kann ich tun, um zu verhindern, dass mein Gerät bei einem solchen Angriff verwendet wird?

  1. Setzen Sie nur TTL = 2 und verlassen Sie sich auf Router, um die Pakete zu löschen
  2. Antworten Sie nur auf Anfragen aus dem eigenen Subnetz
  3. Konfigurationsoption für gültige Abfrageursprungssubnetze hinzufügen
  4. Erraten Sie, welche IP-Adressen "lokal" und "global" sind
  5. Fügen Sie eine Antwort Drosselung, hoffe auf das Beste
  6. Ihre Vorschläge?

Wrt 1. TTL sollte konfigurierbar per SSDP-Spezifikation sein; Selbst wenn es sehr niedrige Antworten sind, leckt es immer noch aus dem lokalen Netzwerk heraus. Wenn im Netzwerk ein Bridge-VPN vorhanden ist, gehen die Antworten ziemlich weit.

Wrt 2. Ich kann mir Unternehmensnetzwerke vorstellen, in denen mehrere Subnetze erreichbar sind (z. B. ein Subnetz für drahtlose Clients, ein anderes für Desktops, ein weiteres für Server) und daher muss mein Gerät in Subnetzen durchsuchbar sein (obwohl TTL pro Spezifikation unterliegen) .

Wrt 3. Konfigurations- und Wartungsaufwand.

Wrt 4. Gibt es einen zuverlässigen Weg, das zu tun? Was ist mit IPv6? Was ist mit Netzwerken, die z.B. / 28 Stück globale Adressen?

Wrt 5. Ein Trickle von unzähligen Geräten ist immer noch ein Torrent ...

Hinweis: Ссылка

    
Dima Tisnek 15.09.2015, 09:06
quelle

1 Antwort

3

Eine andere Möglichkeit wäre, auf Unicast-Anfragen überhaupt nicht zu antworten. Ich kann Ihnen keine Quelle nennen, die ausdrücklich angibt, dass dies erlaubt ist. Einer der Entwürfe liest sich so, als ob es war, und es ' Es macht Sinn, wenn es auch war: Es ist schließlich ein Entdeckungsprotokoll.

Da Multicast in keiner normalen Standardkonfiguration standardmäßig geroutet wird, lautet 239.0.0.0/8 organisations-lokal , Sie können davon ausgehen, dass die an der Multicast-Adresse eingehenden Anfragen echt sind. (Außer natürlich, Sie haben einen Angreifer in Ihrem eigenen Netzwerk, aber das ist ein anderes Problem.)

Unter Linux kann ein eingehendes UDP-Paket mit der Option IP_PKTINFO socket überprüft werden, um zu bestätigen, dass es tatsächlich an eine Multicast-Adresse gesendet wurde:

Ссылка Ссылка

    
Phillip 17.09.2015 10:20
quelle