Ist ICMP-Spoofing praktisch?

Wie praktisch ist ICMP-Spoofing?

Szenario 1: Wie verfolgt NAT in einer NAT-Umgebung ICMP-Sitzungen (technisch gesehen keine Sitzungen, da diese nicht verbindungsorientiert sind?). Für die ECHO / ECHO-Antwort verwendet Windows für jedes Paket dieselbe Kennung (0x1) und Sequenznummer mit 256 Inkrementen . Wie unterscheidet NAT eingehende ICMP-Pakete, wenn zwei Hosts denselben externen Server anpingen? Wie schwierig ist es, eine ECHO-Antwort zu fälschen, wenn das interne Netzwerk die Quelladresse nicht filtert? Anwendungsfall: ICMP-Ping, der für die Überwachung verwendet wird. Ein Load Balancer kann beim Empfang gefälschter ICMP-Antworten falsche / unnötige Maßnahmen ergreifen (Ziel nicht erreichbar, hohe Latenz usw.).

Szenario 2: Einige IPS-Geräte, z. B. die GFW, überprüfen Pakete auf dem Transitpfad. Wie praktisch ist es, ICMP-Fehlermeldungen zu fälschen, um eine Verbindung mit Stealth zu beenden. Anstatt TCP RST zu senden, sendet es einen nicht erreichbaren Zielport / ein zu großes Paket (dies könnte interessant werden :)) mit gefälschter Quell-IP (die legitime IP auf der anderen Seite oder einige Sprünge weiter unten im Pfad). Die Verfolgung des ursprünglichen IP-Headers und der ersten 64 Bytes kann teuer sein. Ist dies angesichts der heute verfügbaren Rechenleistung machbar?

Wie wahrscheinlich ist es, dass gefälschter ICMP entweder innerhalb oder außerhalb von NAT Schäden / Verwirrungen verursacht? Ich spreche nicht von ICMP-Flut.

Übrigens kann NAT mit anderen IP-Protokollen als TCP / UDP umgehen? Ich bin mir eigentlich nicht ganz sicher, wie es mit verschiedenen ICMP-Typen umgeht.

In RFC 5508 "NAT-Verhaltensanforderungen für ICMP" heißt es (Abschnitt 3.1):

Die Zuordnung von ICMP-Abfragen durch NAT-Geräte ist erforderlich, damit aktuelle ICMP-Query-basierte Anwendungen funktionieren. Dies beinhaltet, dass ein NAT-Gerät ICMP-Abfragepakete, die von den Knoten hinter NAT initiiert wurden, und die Antworten auf diese Abfragepakete in die entgegengesetzte Richtung transparent weiterleitet. Wie in [NAT-TRAD] angegeben, muss hierfür der IP-Header übersetzt werden. Ein NAPT-Gerät übersetzt die ICMP-Abfrage-ID und die zugehörige Prüfsumme vor der Weiterleitung weiter in den ICMP-Header.

Ein NAT-Gerät kann also tatsächlich einen eindeutigen Wert in das Feld Identifier eingeben, wenn eine Anfrage nach außen weitergeleitet wird. Zwei Maschinen im Inneren, die dieselbe Kennung verwenden, sind kein Problem. Das NAT-Gerät verwendet zwei unterschiedliche Werte und merkt sich die Kombination aus der ursprünglichen ID und der internen IP-Adresse.

Einige (alte) Cisco-spezifische Informationen finden Sie hier: http://www.ciscopress.com/articles/article.asp?p=25273&seqNum=3 . Diese Seite enthält auch eine Liste der unterstützten Protokolle / Anwendungen für NAT.

Wenn eine ICMP-Nachricht gesendet wird, um über einen durch eine TCP-Verbindung verursachten Fehler zu benachrichtigen, muss die ICMP-Nachricht den Header und einen Teil der Nutzdaten des TCP-Segments enthalten, das den Fehler ausgelöst hat. Dies ist erforderlich, damit der empfangende Host die TCP-Verbindung identifizieren kann.

Ein NAT-Gerät kann genau das Gleiche tun, um herauszufinden, wohin ICMP-Fehler gesendet werden sollen, die es empfängt. Wenn es eine Zuordnung hat, die dem TCP-Header in der ICMP-Nutzlast entspricht, weiß es, wohin die ICMP-Nachricht gesendet werden soll.

Ein Angreifer, der einen ICMP-Fehler fälschen möchte, muss die Quell- und Ziel-IP-Adressen und -Ports kennen, um seine Nachricht zu erstellen. Da die Nutzdaten der ICMP-Nachricht auch eine TCP-Sequenznummer enthalten, kann der TCP-Endpunkt auch überprüfen, ob diese Sequenznummer gültig ist (dh gesendet und noch nicht bestätigt). Dies erschwert das Spoofing erheblich, diese Validierung ist jedoch möglicherweise nicht in allen Systemen implementiert.

Sie sollten sich wahrscheinlich RFC 5927 "ICMP-Angriffe gegen TCP" genauer ansehen .

In jeder modernen Stateful-NAT-Implementierung ist die Verbindungsverfolgung im Allgemeinen ein wesentlicher Bestandteil ihrer Erleichterung. Es gibt keine wirklichen Einschränkungen, welche IP-Protokolle von NAT verarbeitet werden können - Linux Netfilter kann problemlos jedes IP-Protokoll NAT, aber natürlich mit der Einschränkung, dass nur eine innerhalb des Hosts vorhanden ist, wenn für dieses Protokoll keine spezielle Behandlung vorhanden ist (dh zusätzliche Diskriminatoren) in der Lage sein, gleichzeitig mit einem bestimmten externen Host zu kommunizieren.

Im Fall von ICMP echo requestist es sehr unwahrscheinlich, dass die Kennung und das Zeitstempelfeld mit denen eines anderen Hosts übereinstimmen, der denselben Remote-Endpunkt anpingt. Wenn also die NAT- / Verbindungsverfolgungsimplementierung diese Daten verwenden kann, kann zwischen beiden unterschieden werden. Denn destination unreachabledas NAT-Gerät müsste Nutzdaten (nämlich die ersten 8 Bytes) verfolgen, um die Gültigkeit der ICMP-Fehlermeldung sicherzustellen - dennoch sollte der Host-Endpunkt eine solche Nachricht auf jeden Fall selbst validieren.

Unter der Annahme eines RFC-kompatiblen Netzwerkstapels sollten gefälschte ICMP-Nachrichten im Allgemeinen kein Problem darstellen, da mehrere Felder eindeutig sind ... Es sei denn, der Angreifer ist ein direkter Mann in der Mitte, an diesem Punkt können sie ziemlich frei eingreifen. Aus diesem Grund gibt es natürlich Dinge wie IPsec, TCP-MD5 und TCP-AO.

nb: Obwohl es eine Reihe von RFCs in Bezug auf NAT gibt, sollte dies nicht als vereinbarter Standard angesehen werden, wie dies beispielsweise bei Routing-Protokollen der Fall ist.