7. Sicherheitsüberlegungen

7. Sicherheitsüberlegungen

Es bestehen erhebliche Risiken, beliebigen Clients das Erstellen eines Tunnels zu beliebigen Zielen zu gestatten, da dies böswilligen Akteuren ermöglichen könnte, Verkehr zu senden und ihn dem UDP-Proxy zuschreiben zu lassen. HTTP-Server, die UDP-Proxying unterstützen, sollten dessen Nutzung auf authentifizierte Benutzer beschränken.

Es existieren Software- und Netzwerk-Deployments, die Zugriffskontrollprüfungen basierend auf der Quell-IP-Adresse eingehender Anfragen durchführen. Einige Software erlaubt beispielsweise nicht authentifizierte Konfigurationsänderungen, wenn diese von 127.0.0.1 stammen. Solche Software könnte auf demselben Host wie der UDP-Proxy oder in derselben Broadcast-Domäne laufen. Geproxter UDP-Verkehr würde dann mit einer Quell-IP-Adresse empfangen, die zum UDP-Proxy gehört. Wenn diese Quelladresse für die Zugriffskontrolle verwendet wird, könnten UDP-Proxying-Clients den UDP-Proxy verwenden, um ihre Zugriffsprivilegien über die hinaus zu erweitern, die sie sonst hätten. Dies könnte zu unbefugtem Zugriff durch UDP-Proxying-Clients führen, es sei denn, der UDP-Proxy verbietet UDP-Proxying-Anfragen an gefährdete Ziele, wie z. B. die eigenen Adressen des UDP-Proxys und Localhost-, Link-Local-, Multicast- und Broadcast-Adressen. UDP-Proxys können den destination_ip_prohibited Proxy-Fehlertyp aus Abschnitt 2.3.5 von [PROXY-STATUS] verwenden, wenn sie solche Anfragen ablehnen.

UDP-Proxys weisen viele Ähnlichkeiten mit TCP CONNECT-Proxys auf, wenn man sie als Infrastruktur für Missbrauch zur Ermöglichung von Denial-of-Service (DoS)-Angriffen betrachtet. Beide können die Quelladresse des Angreifers vor dem Angriffsziel verschleiern. Im Falle eines zustandslosen volumetrischen Angriffs (z. B. ein TCP-SYN-Flood oder ein UDP-Flood) leiten beide Arten von Proxys den Verkehr an den Zielhost weiter. Bei zustandsbehafteten volumetrischen Angriffen (z. B. HTTP-Flooding), die über einen TCP CONNECT-Proxy gesendet werden, sendet der Proxy nur Daten, wenn das Ziel seine Bereitschaft zur Datenannahme durch Antworten mit einem TCP SYN-ACK angezeigt hat. Sobald der Pfad zum Ziel überflutet ist, empfängt der TCP CONNECT-Proxy keine Antworten mehr vom Ziel und stellt das Senden von Daten ein. Da UDP keinen gemeinsamen Zustand zwischen dem UDP-Proxy und dem Ziel herstellt, könnte der UDP-Proxy in einer solchen Situation weiterhin Daten an das Ziel senden. Während ein UDP-Proxy möglicherweise die Anzahl der UDP-Pakete begrenzen könnte, die er weiterzuleiten bereit ist, bis er eine Antwort vom Ziel beobachtet hat, bietet dies nur begrenzten Schutz gegen DoS-Angriffe, wenn Angriffe auf offene UDP-Ports abzielen, bei denen das über UDP laufende Protokoll antworten würde und dies vom UDP-Proxy als Bereitschaft zur Annahme von UDP interpretiert würde. Ein solches Paketlimit könnte auch Probleme für gültigen Verkehr verursachen.

Die in Abschnitt 4 von [HTTP-DGRAM] beschriebenen Sicherheitsüberlegungen gelten auch hier. Da es möglich ist, IP-Pakete über UDP zu tunneln, kann die Anleitung in [TUNNEL-SECURITY] gelten.