0. Abstract
1. NAT
2 STUN
3 Bibliotheken
4 Anwendungsbeispiel
5 Weitere Informationensquellen
6 Über
2. STUN
Eines der o.g. Probleme welche durch NAT entstehen ist das Empfangen von UDP-Packeten.
Zwei Ursachen gibt es dafür:
  • Der absendende Host kennt die IP, an welche er das Packet senden muss, nicht, da der empfangende Host sie ebenfalls nicht kennt.
  • Ein richtig adressiertes Packet kommt nicht an, da der NAT (Router, Firewall, etc.) es nicht weiterleitet. Ursache hier ist entweder, dass nicht bekannt ist für welchen der internen Hosts es bestimmt ist oder 'Sicherheitsrestriktionen' es nicht zulassen. Siehe hierzu 'Typen von NATs'.
Genau hier kann STUN zur Lösung eingesetzt werden.

• Idee:
    STUN gibt dem Client ein Werkzeug in die Hand mit dem er
    • herausfinden kann ob er hinter einem NAT liegt,
    • den Typ (und z.T. die Einstellungen) des NAT sowie,
    • die öffentliche IP bestimmt und
    • Verbindungen offenhalten kann (keep alive)
    Erreicht wird dies durch ein 'Frage-und-Antwort-Spiel' des STUN-Clients mit einem STUN-Server. Durch die Auswertung des Inhaltes der Antworten kann auf o.g. Punkte geschlossen werden.
• Terminologie:
  • STUN Client:
    Ein STUN Client (Client) ist die Einheit welche STUN-Requests generiert. A STUN client kann auf einem End-User-System ausgeführt werden oder in einem Netzwerkelement, z.B. einen conferencing server.

  • STUN Server:
    Ein STUN Server (Server) ist eine Einheit die STUN-Requests empfängt und STUN-Responsen sendet. STUN servers sind immer im öffentlichen Internet befindlich.
  • Umgebung:
    Die Umgebung bezeichnet die Konstellation evtl. vorhandener NATs zwischen dem Client und dem öffentlichen Internet. Sie beinhaltet auch die Konfiguration der NATs sowie die öffentliche IP.
    Es ist möglich, dass mehrere NATs zwischen Client und öffentlichem Internet geschaltet sind. Beispielhaft sei hier eine mögliche Umgebung gezeigt: 
                                /-----\
                          // STUN  \\
                         |   Server  |
                          \\       //
                            \-----/
                                                 Public Internet
                       +--------------+             
       ................|     NAT 2    |.......................
                       +--------------+
                                                 Private NET 2
                       +--------------+             
       ................|     NAT 1    |.......................
                       +--------------+
                                                 Private NET 1
                            /-----\
                          // STUN  \\
                         |   Client  |
                          \\       //               
                            \-----/
    [aus: RFC3489]
  • Enthüllung:
    Eine Enthüllung bezeichnet den Vorgang (Teil-) Informationen über die Umgebung zu erhalten.

• Anwendbarkeit:
    Dieses Protokoll ist kein Allheilmittel für alle durch NAT verursachte Probleme.

    Es erlaubt keine eingehenden TCP-Verbindungen. Es erlaubt eingehende UDP-Packete, jedoch nur bei einer Teilmenge von existierend NATs. Insbesonders gestattet es keine UDP-Eingänge durch Symmetric NATs welche weit verbreitet sind in größeren Firmen. (STUN-Nutzung ist möglich, jedoch hilft sie bedingt durch die Definition dieses NAT-Types nicht. U.U. sind hier jedoch andere Strategien erfolgreich welche nichts mit STUN zu tun haben.)

    STUN's Prozeduren zur Enthüllung der Umgebung basieren auf der Art wie diese UDP behandeln; diese Annahme kann sich als falsch erweisen je nach dem wie sich NAT-Geräte-/Software entwickeln.

    STUN funktioniert nicht um eine Kommunkation mit einem Host vorzubereiten der sich im selben NAT befindet.

    STUN erfordert außerdem, dass der Server im öffentlichen IP-Adressraum anzusprechen ist.
• Funktionsweise:
    Dieses Dokument erklärt nur beschränkt Details des Protokolles. Hier sei auf das RFC verwiesen. Einen gewissen Einblick bietet jedoch die im Anschluss folgende Untersektion 'Protokolldetails'.

    Eine Enthüllung beginnt mit einer Bindungssequenz in der sich der Client mittels TCP beim Server registriert. Näheres unter 'Sicherheitsbetrachtung'.

    Eine Enthüllung wird durch eine Anfrage des Client (UDP) an den Server erreicht. Die Anfrage kann unterschiedlich geartet sein und fordert den Server auf in definierter Weise zu antworten.

    Durch eine 'geschickte' Strategie von aufeinander folgenden Anfragen kann aus den Antworten (z.T. auch aus dem Ausbleiben dieser) auf die Umgebung geschlossen werden. Im wesentlichen geschiet dies indem der Server Informationen aus dem UDP-Packet-Header im Body noch einmal angibt. Der Client wertet evtl. Veränderungen des Headers durch den NAT (bzw. das Ausbleiben des gesamten Packetes) aus.

    So kann der Client den Server auffordern auf eine Anfrage eine Antwort zu senden die
    • an die Urspruchsadresse (IP & Port) gesendet wird,
    • an die Urspruchs-IP mit verändertem Port gesendet wird,
    • an spezielle Adresse gesendet wird,
    • mit veränderten Absenderdaten gesendet wird,
    • etc.

    Beispiel: Empfängt der Client ein UDP-Packet vom Server trotz manipulierter Absenderadresse so ist dies eine Eigenschaft eines Full Cone NATs, keinesfalls jedoch die eines Restricted Cone oder Port Restricted Cone.

    Hier das Flussdiagramm einer typischen Enthüllung:
                            +--------+
                        |  Test  |
                        |   I    |
                        +--------+
                             |
                             |
                             V
                            /\              /\
                         N /  \ Y          /  \ Y             +--------+
          UDP     <-------/Resp\--------->/ IP \------------->|  Test  |
          Blocked         \ ?  /          \Same/              |   II   |
                           \  /            \? /               +--------+
                            \/              \/                    |
                                             | N                  |
                                             |                    V
                                             V                    /\
                                         +--------+   Sym.     N /  \
                                         |  Test  |   UDP    <--/Resp\
                                         |   II   |   Firewall  \ ?  /
                                         +--------+              \  /
                                             |                    \/
                                             V                     |Y
                  /\                         /\                    |
   Symmetric  N  /  \       +--------+   N  /  \                   V
      NAT  <--- / IP \<-----|  Test  |<--- /Resp\               Open
                \Same/      |   I    |     \ ?  /               Internet
                 \? /       +--------+      \  /
                  \/                         \/
                  |                           |Y
                  |                           |
                  |                           V
                  |                           Full
                  |                           Cone
                  V              /\
              +--------+        /  \ Y
              |  Test  |------>/Resp\---->Restricted
              |   III  |       \ ?  /
              +--------+        \  /
                                 \/
                                  |N
                                  |       Port
                                  +------>Restricted
    [aus: RFC3489]
• Protokolldetails:
    STUN ist ein Request-Response-Protokoll: Clients senden eine Anfrage und der Server schickt eine Antwort.
    Es gibt zwei Arten von Anfragen: Binding Requests und Shared Secret Request.
    Die Antwort auf ein Binding Request kann entweder ein Binding Response oder ein Binding Error Response sein.
    Die Antwort auf ein Shared Secret Request kann ein Shared Secret Response oder ein Shared Secret Error Response sein.

    Header
    Alle STUN-Nachrichten beinhalten einem 20 Byte großen Header: 
        0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      STUN Message Type        |         Message Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Transaction ID
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Gültige Messagetypen sind:
    • 0x0001 - Binding Request
    • 0x0101 - Binding Response
    • 0x0111 - Binding Error Response
    • 0x0002 - Shared Secret Request
    • 0x0102 - Shared Secret Response
    • 0x0112 - Shared Secret Error Response

    Die Nachrichtenlänge ist Länge der gesamten Nachricht exklusive des Header in Byte.

    Die Transaction ID ist 128 Bit groß und eindeutig für jede einzelne Anfrage (selbst bei Wiederholungen). Sie wird auch als Saat für einen Zufallszahlengenerator benutzt. Alle Antworten tragen die selbe ID wie die zugehörige Anfrage.

    Attribute
    Auf den Header können Attribute folgen. Sie sind TLV-Codiert (Typ-Länge-Wert):
        0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type (16 Bit)         |       Length (16 Bit)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Value                           ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Gültige Attributtypen sind:
    • 0x0001 - MAPPED-ADDRESS
      Die Adresse die der Server als Absender einer Anfrage sah. (Vom NAT umgewandelt.)
    • 0x0002 - RESPONSE-ADDRESS
      Aufforderung des Clients wohin der Server antworten soll.
    • 0x0003 - CHANGE-REQUEST
      Der Client verlangt, dass der Server eine geänderte Abdenderadresse in den UDP-Packet-Header (nicht STUN-Header) einträgt wenn er antwortet. IP- und Port-Änderungen können einzeln gefordert werden.
    • 0x0004 - SOURCE-ADDRESS
      Immer die wahre Adresse des Servers.
    • 0x0005 - CHANGED-ADDRESS
      Beinhaltet die Absender-Adresse, die vom Server in den UDP-Packet-Header eingetragen wurde. Folgt auf eine Anfrage mit einem CHANGE-REQUEST-Attribut. Nicht die reale Adresse des Servers, falls eines der CHANGE-REQUEST-Flags gesetzt war.
    • 0x0006 - USERNAME
      Zur Sicherung der Integrität der Nachricht - s.a. 'Sicherheitsbetrachtung'.
    • 0x0007 - PASSWORD
      Zur Sicherung der Integrität der Nachricht - s.a. 'Sicherheitsbetrachtung'.
    • 0x0008 - MESSAGE-INTEGRITY
      Prüfsumme über das Packet. Muss zwingend das letzte Element bei mehreren Attributen sein.
    • 0x0009 - ERROR-CODE Im Falle eines Fehlers.
    • 0x000a - UNKNOWN-ATTRIBUTES Der Server zeigt an, dass er ein Attribut nicht verstanden hat.
    • 0x000b - REFLECTED-FROM
      In einer Antwort vorhanden, falls es in der Anfrage ein RESPONSE-ADDRESS gab. Es enthält die Identität des Anfrage-Absenders (in Form der IP). Damit ist gewährleistet, dass ein DOS-Angriff zurück verfolgt werden kann.

    Folgende Attribut-Nachrichtentyp-Kombinationen sind möglich: 
                                             Binding  Shared  Shared  Shared
                       Binding  Binding  Error    Secret  Secret  Secret
   Att.                Req.     Resp.    Resp.    Req.    Resp.   Error
                                                                  Resp.
   _____________________________________________________________________
   MAPPED-ADDRESS      N/A      M        N/A      N/A     N/A     N/A
   RESPONSE-ADDRESS    O        N/A      N/A      N/A     N/A     N/A
   CHANGE-REQUEST      O        N/A      N/A      N/A     N/A     N/A
   SOURCE-ADDRESS      N/A      M        N/A      N/A     N/A     N/A
   CHANGED-ADDRESS     N/A      M        N/A      N/A     N/A     N/A
   USERNAME            O        N/A      N/A      N/A     M       N/A
   PASSWORD            N/A      N/A      N/A      N/A     M       N/A
   MESSAGE-INTEGRITY   O        O        N/A      N/A     N/A     N/A
   ERROR-CODE          N/A      N/A      M        N/A     N/A     M
   UNKNOWN-ATTRIBUTES  N/A      N/A      C        N/A     N/A     C
   REFLECTED-FROM      N/A      C        N/A      N/A     N/A     N/A

M - zwingend
O - optional
C - abhängig von weiteren Faktoren
N/A - nicht sinnvoll

• Sicherheitsbetrachtung:
    Das STUN-Protokoll sieht mehrere verschiedene Mechanismen vor um Angriffe zu verhindern, zu erschweren oder nachverfolgen zu können.
    Mangels vollständig STUN-kompatibelen Implementationen sind diese momentan jedoch nur eingeschränkt nutzbar. Dies betrifft speziell die Umsetzung der Shared-Secret-Bestandteile.

    denkbare Angriffsszenarien:
    • Denial of Service
      • gegen einen STUN-Server
      • andere Elemente die STUN nutzen
        Viele Clients werden mit gefälschten MAPPED-ADDRESS-Attributen beliefert welche auf das Angriffsziel zeigen. Die Clients veranlassen nun Ihre Kommunikationspartner dazu das Ziel statt ihrer selbst mit UDP-Packeten zu beliefern. Der gesamte Traffic wird auf das Ziel fokusiert.
    • Täuschung eines Client
      Der Angreifer versucht einen Client daran zu hindern Dienste des Netzwerkes zu nutzen indem er die Enthüllung manipuliert.
      Dazu liefert er dem Client z.B. ein falsches MAPPED-ADDRESS-Attribut. Der Client zieht so falsche Schlüsse bzgl. seiner NAT-Umgebung oder ist für seinen Kommunikationspartner nicht erreichbar.
    • Lauschangriffe
      Werden dem Client gefälschte MAPPED-ADDRESS-Attribute geliefert welche auf den Angreifer selbst zeigen, so erhält dieser Daten die eigentlich für den Client bestimmt sind.

    Diese Angriffe können durch Eingriffe in das Netzwerk oder durch manipulierte STUN-Server eingeleitet werden.

    Sicherungsmaßnamen:
    • Limitierung der Ressourcen
      Ein STUN-Server sollte die Anzahl der gleichzeitigen TLS Verbindungen (Anmelden) und gespeicherten Shared Secrets beschränken. Dadurch wird eine DOS-Attacke verhindert.
    • Shared Secret
      Das STUN-Protokoll bietet die Möglichkeit, dass ein Client nur per vorheriger Anmeldung seine Anfragen an den Server richten kann.
    • USERNAME
      Wurde ein Shared-Secret vereinbart, so erhält der Client eine Eindeutige Kennung. Diese kann mittels zusätzlichem USERNAME-Attribut bei jeder Anfrage mitgeteilt werden. Somit ist es auschgeschlossen, dass unberechtigte einen Server benutzen/missbrauchen.
    • REFLECTED-FROM
      Dieses Attribut ist in einer Antwort vorhanden, falls der Client den Server beauftragte an eine bestimmte Adresse zu senden. Es enthält die Identität des Anfrage-Absenders (in Form der IP). Damit ist gewährleistet, dass ein DOS-Angriff zurück verfolgt werden kann.

, Dresden am 20.01.2006