17. Sicherheitserwägungen (Security Considerations)
Dieser Abschnitt betrachtet Angriffe, die gegen TURN-Bereitstellungen durchgeführt werden könnten, und diskutiert, wie diese Angriffe durch Mechanismen im Protokoll oder empfohlene Praktiken in der Implementierung gemildert werden können.
Die meisten Angriffe gegen TURN werden dadurch gemildert, dass der Server verlangt, dass Anfragen authentifiziert werden. Aus diesem Grund schreibt diese Spezifikation die Verwendung von Authentifizierung vor. Der obligatorisch zu implementierende Mechanismus ist der Langzeit-Anmeldeinformationsmechanismus von STUN. Andere Authentifizierungsmechanismen mit gleichen oder stärkeren Sicherheitseigenschaften DÜRFEN verwendet werden. Es ist jedoch wichtig sicherzustellen, dass sie auf interoperable Weise aufgerufen werden können.
17.1. Externe Angriffe (Outsider Attacks)
Externe Angriffe sind solche, bei denen der Angreifer keine Anmeldeinformationen im System hat und versucht, den Dienst zu stören, wie er vom Client oder Server gesehen wird.
17.1.1. Erhalt nicht autorisierter Zuweisungen (Obtaining Unauthorized Allocations)
Ein Angreifer könnte aus einer Reihe von böswilligen Gründen eine Zuweisung auf einem TURN-Server erhalten wollen. Ein TURN-Server bietet einen Mechanismus zum Senden und Empfangen von Paketen, während die tatsächliche IP-Adresse des Clients verborgen wird. Dies macht den TURN-Server zu einem attraktiven Ziel für Angreifer, die ihn verwenden möchten, um ihre wahre Identität zu verschleiern.
Ein Angreifer könnte auch einfach die Dienste eines TURN-Servers nutzen wollen, ohne dafür zu bezahlen. Da TURN-Dienste Ressourcen des Anbieters erfordern, wird erwartet, dass ihre Nutzung mit Kosten verbunden ist.
Diese Angriffe werden durch die Verwendung des Langzeit-Anmeldeinformationsmechanismus verhindert, der es dem TURN-Server ermöglicht, die Identität des Antragstellers zu bestimmen und ob der Antragsteller berechtigt ist, eine Zuweisung zu erhalten.
17.1.2. Offline-Wörterbuchangriffe (Offline Dictionary Attacks)
Der von TURN verwendete Langzeit-Anmeldeinformationsmechanismus ist anfällig für Offline-Wörterbuchangriffe. Ein Angreifer, der in der Lage ist, einen Nachrichtenaustausch zwischen einem Client und einem Server abzuhören, kann das Passwort bestimmen, indem er eine Reihe von Kandidatenpasswörtern ausprobiert und sieht, ob eines davon korrekt ist. Dieser Angriff funktioniert, wenn Passwörter eine niedrige Entropie haben (z.B. Wörter aus einem Wörterbuch). Dieser Angriff kann durch die Verwendung starker Passwörter mit großer Entropie gemildert werden. In Fällen, in denen eine noch stärkere Abschwächung erforderlich ist, kann TLS-Transport zwischen Client und Server verwendet werden.
17.1.3. Gefälschte Aktualisierungen und Berechtigungen (Faked Refreshes and Permissions)
Ein Angreifer könnte eine aktive Zuweisung angreifen wollen, indem er ihr eine Refresh-Anfrage mit sofortigem Ablauf sendet, um sie zu löschen und den Dienst für den Client zu stören. Dies wird durch Authentifizierung von Aktualisierungen verhindert. Ebenso wird ein Angreifer, der eine CreatePermission-Anfrage senden möchte, um eine Berechtigung für ein unerwünschtes Ziel zu erstellen, durch Authentifizierung daran gehindert. Die Motivationen für solche Angriffe werden in Abschnitt 17.2 beschrieben.
17.1.4. Gefälschte Daten (Fake Data)
Ein Angreifer könnte Daten an einen Client oder Peer senden wollen, als ob sie vom Peer bzw. Client kämen. Um dies zu tun, könnte der Angreifer eine gefälschte Data-Indikation oder ChannelData-Nachricht an den Client oder eine gefälschte Send-Indikation oder ChannelData-Nachricht an den TURN-Server senden.
Da Indikationen und ChannelData-Nachrichten nicht authentifiziert sind, wird dieser Angriff nicht durch TURN verhindert. Dieser Angriff ist jedoch im Allgemeinen bei IP-basierten Kommunikationen vorhanden und wird durch TURN nicht signifikant verschlimmert. Betrachten Sie eine normale IP-Sitzung zwischen Hosts A und B, die TURN nicht verwendet. Ein Angreifer kann ein Paket an B senden, das von A zu stammen scheint, indem er das Paket mit der gefälschten IP-Adresse von A sendet. Dieser Angriff erfordert, dass der Angreifer die IP-Adressen sowohl von A als auch von B kennt. Mit TURN muss ein Angreifer, der ein Paket an den Client unter Verwendung einer Data-Indikation senden möchte, die IP-Adresse (und den Port) des Clients, die IP-Adresse und den Port des TURN-Servers und die IP-Adresse und den Port des Peers (zur Aufnahme in das XOR-PEER-ADDRESS-Attribut) kennen. Um eine gefälschte ChannelData-Nachricht an den Client zu senden, muss der Angreifer die IP-Adresse und den Port des Clients, die IP-Adresse und den Port des TURN-Servers und die Kanalnummer kennen. Diese besondere Kombination ist etwas leichter zu erraten als der Nicht-TURN-Fall.
Diese Angriffe werden besser durch Authentifizierungstechniken auf Anwendungsebene gemildert. Im Fall von Echtzeit-Verkehr kann die Verwendung von SRTP [RFC3711] diese Angriffe verhindern.
In einigen Fällen könnte der TURN-Server so im Netzwerk positioniert sein, dass er an Hosts senden kann, die der Client selbst nicht direkt erreichen kann. Zum Beispiel, wenn der Server sich hinter einer Firewall befindet, die es Paketen von außerhalb der Firewall erlaubt, zum Server zu gelangen, aber nicht zu anderen Hosts hinter der Firewall. In diesen Fällen könnte ein Angreifer eine Send-Indikation an den Server senden können, mit einem XOR-PEER-ADDRESS-Attribut, das die Transportadresse eines der anderen Hosts hinter der Firewall enthält. Wenn der Server es erlaubt, dass Verkehr an jeden Peer weitergeleitet wird, würde dies dem Angreifer eine Möglichkeit bieten, einen beliebigen Host hinter der Firewall anzugreifen.
Um diesen Angriff zu mildern, verlangt TURN, dass der Client eine Berechtigung für einen Host einrichtet, bevor er Daten an ihn sendet. Somit kann der Angreifer nur Hosts angreifen, mit denen der Client bereits kommuniziert hat, es sei denn, der Angreifer ist in der Lage, authentifizierte Anfragen zu erstellen. Darüber hinaus kann ein Serveradministrator den Server so konfigurieren, dass er den Bereich der IP-Adressen und Ports einschränkt, an die er Daten weiterleiten wird. Um noch größere Sicherheit zu bieten, kann ein Serveradministrator vom Client verlangen, TLS für alle Kommunikationen zwischen Client und Server zu verwenden.
17.1.5. Vortäuschen eines Servers (Impersonating a Server)
Wenn ein Client die weitergeleitete Adresse von einem TURN-Server lernt, verwendet er diese weitergeleitete Adresse in einem Anwendungsprotokoll, um Verkehr zu empfangen. Somit könnte ein Angreifer, der diesen Verkehr abfangen oder umleiten möchte, versuchen, sich als TURN-Server auszugeben und dem Client eine gefälschte weitergeleitete Adresse zu liefern.
Dieser Angriff wird durch den Langzeit-Anmeldeinformationsmechanismus verhindert, der Nachrichtenintegrität für Antworten bietet und authentifiziert, dass sie vom Server stammen. Darüber hinaus kann ein Angreifer alte Serverantworten nicht wiedergeben, da die Transaktions-ID im STUN-Header dies verhindert. Replay-Angriffe werden weiter unterbunden, indem der Nonce-Wert häufig geändert wird.
17.1.6. Abhören von Verkehr (Eavesdropping Traffic)
TURN befasst sich hauptsächlich mit Authentifizierung und Nachrichtenintegrität. Vertraulichkeit ist nur ein sekundäres Anliegen, da TURN-Kontrollnachrichten keine besonders sensiblen Informationen enthalten. Der primäre Protokollinhalt der Nachrichten ist die IP-Adressen der Peers. Wenn es wichtig ist zu verhindern, dass ein Abhörer auf einer TURN-Verbindung dies erfährt, kann TURN über TLS ausgeführt werden.
Die Vertraulichkeit der von TURN weitergeleiteten Anwendungsdaten wird am besten vom Anwendungsprotokoll selbst bereitgestellt, da das Ausführen von TURN über TLS die Anwendungsdaten zwischen Server und Peer nicht schützt. Wenn die Vertraulichkeit der Anwendungsdaten wichtig ist, sollte die Anwendung ihre Daten verschlüsseln oder anderweitig schützen. Zum Beispiel kann für Echtzeitmedien Vertraulichkeit durch Verwendung von SRTP bereitgestellt werden.
17.1.7. TURN-Schleifenangriff (TURN Loop Attack)
Ein Angreifer könnte versuchen, Datenpakete unendlich zwischen zwei TURN-Servern schleifen zu lassen. Der Angriff läuft wie folgt ab. Zuerst sendet der Angreifer eine Allocate-Anfrage an Server A mit einer Quelladresse von Server B. Server A sendet seine Antwort an Server B, und damit der Angriff erfolgreich ist, muss der Angreifer in der Lage sein, den Inhalt dieser Antwort zu sehen oder zu erraten, damit der Angreifer die zugewiesene weitergeleitete Transportadresse erfahren kann. Der Angreifer sendet dann eine Allocate-Anfrage an Server B mit einer Quelladresse von Server A. Wiederum muss der Angreifer in der Lage sein, den Inhalt der Antwort zu sehen oder zu erraten, damit die zugewiesene weitergeleitete Transportadresse erfahren werden kann. Mit denselben gefälschten Quelladressen-Techniken bindet der Angreifer dann eine Kanalnummer auf Server A an die weitergeleitete Transportadresse auf Server B und bindet ähnlich dieselbe Kanalnummer auf Server B an die weitergeleitete Transportadresse auf Server A. Schließlich sendet der Angreifer eine ChannelData-Nachricht an Server A.
Das Ergebnis ist ein Datenpaket, das von der weitergeleiteten Transportadresse auf Server A zur weitergeleiteten Transportadresse auf Server B schleift, dann von der Transportadresse auf Server B zur Transportadresse auf Server A, dann wieder schleift.
Die Abschwächung gegen diesen Angriff ist wie folgt. Indem verlangt wird, dass Anfragen authentifiziert werden und/oder indem die für die weitergeleitete Transportadresse zugewiesene Portnummer randomisiert wird, zwingt der Server den Angreifer, Antworten abzufangen oder zu sehen, die an Dritte (in diesem Fall den anderen Server) gesendet werden, damit der Angreifer die Anfrage authentifizieren und die weitergeleitete Transportadresse erfahren kann. Ohne eine dieser beiden Maßnahmen kann der Angreifer den Inhalt der Antwort erraten, ohne sie sehen zu müssen, was den Angriff einfacher durchführbar macht. Darüber hinaus zwingt der Server durch das Verlangen authentifizierter Anfragen den Angreifer, Anmeldeinformationen zu haben, die der Server akzeptiert, was es zu einem Insider-Angriff anstelle eines Outsider-Angriffs macht und es ermöglicht, den Angriff auf den Client zurückzuverfolgen, der ihn gestartet hat.
Weitere Abschwächung kann erreicht werden, indem Limits pro Benutzername für die von Zuweisungen verwendete Bandbreite für das Weiterleiten von Daten auferlegt werden, die diesem Benutzernamen gehören, um die Auswirkungen dieses Angriffs auf andere Zuweisungen zu begrenzen. Weitere Abschwächung kann durch Dekrementieren der TTL beim Weiterleiten von Datenpaketen (wenn das zugrunde liegende Betriebssystem dies zulässt) erreicht werden.
17.2. Firewall-Überlegungen (Firewall Considerations)
Eine wichtige Sicherheitsüberlegung für TURN ist, dass TURN nicht die Schutzmechanismen schwächen sollte, die von einer Firewall geboten werden, die zwischen dem Client und dem TURN-Server bereitgestellt wird. Es wird erwartet, dass TURN-Server oft im öffentlichen Internet vorhanden sind, während Clients häufig in einem Unternehmensnetzwerk mit einer Unternehmens-Firewall lokalisiert sind. Wenn der TURN-Server eine "Hintertür" in das Unternehmen bietet, wird TURN von diesen Firewalls blockiert.
Daher emuliert ein TURN-Server das Verhalten eines NAT-Geräts, das adressabhängige Filterung [RFC4787] implementiert, was eine häufige Eigenschaft in vielen Firewalls ist. Wenn ein NAT oder eine Firewall dieses Verhalten implementiert, dürfen Pakete von einer externen IP-Adresse nur dann an eine interne IP-Adresse und einen Port gesendet werden, wenn die interne IP-Adresse und der Port kürzlich ein Paket an diese externe IP-Adresse gesendet haben. Ein TURN-Server führt das Konzept der Berechtigungen ein, das genau dasselbe Verhalten auf dem TURN-Server bietet. Ein Angreifer kann kein Paket an einen TURN-Server senden und erwarten, dass es an einen Client weitergeleitet wird, es sei denn, der Client hat zuerst versucht, den Angreifer zu kontaktieren.
Es ist wichtig zu beachten, dass die Richtlinien einiger Firewalls noch strenger sind als adressabhängige Filterung. Firewalls können auch für adress- und portabhängige Filterung konfiguriert werden oder können so konfiguriert werden, dass sie überhaupt keinen eingehenden Verkehr zulassen. In diesen Fällen wäre die Kommunikation mit einem Client weniger eingeschränkt als die Firewall normalerweise erlaubt, wenn der Client sich mit einem TURN-Server verbinden darf.
17.2.1. Gefälschte Berechtigungen (Faked Permissions)
In Firewalls und NAT-Geräten werden Berechtigungen implizit durch Pakete erteilt, die von innen im Netzwerk zum äußeren Peer durchlaufen. Somit können Berechtigungen per Definition nicht von einer Entität außerhalb der Firewall oder des NAT erstellt werden. Mit TURN gilt diese Einschränkung nicht mehr. Da der TURN-Server außerhalb der Firewall sitzt, kann ein Angreifer außerhalb der Firewall jetzt Nachrichten an den TURN-Server senden und versuchen, Berechtigungen für sich selbst zu erstellen.
Dieser Angriff wird blockiert, weil alle Nachrichten, die Berechtigungen erstellen (nämlich ChannelBind und CreatePermission), authentifiziert sind.
17.2.2. Gesperrte IP-Adressen (Blacklisted IP Addresses)
Viele Firewalls können mit Sperrlisten konfiguriert werden, um zu verhindern, dass Clients hinter der Firewall Pakete an gesperrte IP-Adressbereiche senden oder von diesen empfangen. Dies wird erreicht, indem die Quell- und Zieladressen von Paketen, die in die Firewall eintreten und aus ihr austreten, jeweils untersucht werden.
Diese Fähigkeit ist auch in TURN vorhanden, da es dem TURN-Server erlaubt ist, den Bereich der Adressen von Peers, an die er weiterleitet, beliebig einzuschränken.
17.2.3. Betreiben von Servern auf bekannten Ports (Running Servers on Well-Known Ports)
Ein bösartiger Client hinter einer Firewall könnte versuchen, sich mit einem TURN-Server zu verbinden und eine Zuweisung zu erhalten, die er dann verwenden kann, um einen Server zu betreiben. Zum Beispiel könnte der Client versuchen, einen DNS-Server oder einen FTP-Server zu betreiben.
Dies ist mit TURN nicht möglich. Ein TURN-Server wird niemals Verkehr von einem Peer akzeptieren, für den der Client keine Berechtigung installiert hat. Somit kann ein Peer nicht einfach eine Verbindung zum zugewiesenen Port herstellen, um einen Dienst zu erhalten.
17.3. Insider-Angriffe (Insider Attacks)
Bei einem Insider-Angriff hat der Client legitime Anmeldeinformationen, verstößt aber gegen die Vertrauensbeziehung, die mit diesen Anmeldeinformationen einhergeht. Diese Angriffe können nicht durch kryptografische Mittel verhindert werden, müssen aber im Protokolldesign berücksichtigt werden.
17.3.1. DoS gegen TURN-Server (DoS against TURN Server)
Ein Client, der den Dienst für andere Clients stören möchte, könnte eine Zuweisung erhalten und diese dann mit Verkehr überfluten, um zu versuchen, den Server zu überlasten und ihn daran zu hindern, anderen legitimen Clients zu dienen. Dies wird gemildert, indem empfohlen wird, dass der Server die Menge an Bandbreite begrenzt, die er für einen bestimmten Benutzernamen weiterleiten wird. Dies verhindert nicht, dass der Client eine große Menge an Verkehr sendet, aber es ermöglicht dem Server, den überschüssigen Verkehr sofort zu verwerfen.
Da jede Zuweisung eine Portnummer auf der IP-Adresse des TURN-Servers verwendet, ist die Anzahl der Zuweisungen auf dem Server endlich. Ein Angreifer könnte versuchen, alle Zuweisungen zu verbrauchen, indem er eine große Anzahl von Zuweisungen anfordert. Dies wird durch die Empfehlung verhindert, dass der Server eine Grenze für die Anzahl der zu einem Zeitpunkt aktiven Zuweisungen für einen bestimmten Benutzernamen auferlegt.
17.3.2. Anonymes Weiterleiten von bösartigem Verkehr (Anonymous Relaying of Malicious Traffic)
Ein TURN-Server bietet ein gewisses Maß an Anonymisierung. Ein Client kann Daten an einen Peer senden, ohne seine eigene IP-Adresse zu offenbaren. Somit könnte ein TURN-Server ein attraktives Werkzeug für Angreifer werden, um Angriffe auf ein Ziel zu starten, ohne Angst vor Entdeckung. Tatsächlich könnte ein Client mehrere TURN-Server miteinander verketten, sodass eine beliebige Anzahl von Relays verwendet wird, bevor das Datenpaket beim Ziel ankommt.
Ein Administrator, der sich um diesen Angriff sorgt, kann Protokolle führen, die die tatsächliche Quell-IP und den Port des Clients erfassen, und möglicherweise sogar jede Berechtigung, die dieser Client installiert hat. Dies würde eine forensische Rückverfolgung ermöglichen, um die ursprüngliche Quelle zu bestimmen, wenn ein Angriff entdeckt wird, der über einen TURN-Server weitergeleitet wird.
17.3.3. Manipulation anderer Zuweisungen (Manipulating Other Allocations)
Ein Angreifer könnte versuchen, den Dienst für andere Benutzer des TURN-Servers zu stören, indem er Refresh-Anfragen oder CreatePermission-Anfragen sendet, die (durch Quelladress-Spoofing) so aussehen, als kämen sie von einem anderen Benutzer des TURN-Servers. TURN verhindert dies, indem verlangt wird, dass die in CreatePermission-, Refresh- und ChannelBind-Nachrichten verwendeten Anmeldeinformationen mit den Anmeldeinformationen übereinstimmen, die zum Erstellen der ursprünglichen Zuweisung verwendet wurden. Somit werden gefälschte Anfragen von einem Angreifer abgelehnt.
17.4. Weitere Überlegungen (Other Considerations)
Jede über eine Allocate-Anfrage erlernte weitergeleitete Adresse wird nicht ordnungsgemäß mit IPsec Authentication Header (AH) [RFC4302] im Transport- oder Tunnelmodus funktionieren. Tunnel-Modus IPsec Encapsulating Security Payload (ESP) [RFC4303] sollte jedoch weiterhin funktionieren.