Wie TCP/IP-Verbindungen funktionieren
Transmission Control Protocol/Internet Protocol (TCP/IP) ist ein Dreh- und Angelpunkt für moderne Computernetzwerke. Es ist die Art und Weise, wie (in den meisten Fällen) Ihr Computer häufig Informationen über ein Netzwerk und das Internet anfordert und empfängt. Es verfügt über Fehlerkontrolle, Wiederholung von fehlenden/beschädigten Daten und einige andere wichtige Funktionen, die das Internet, wie wir es kennen, buchstäblich zuverlässig und funktional machen. Um jedoch zu verstehen, wie es missbraucht wird, müssen wir zuerst verstehen, wie es funktioniert.
Der Kürze halber werden wir nicht auf den gesamten TCP/IP-Verbindungsprozess eingehen. Wir werden uns nur auf den anfänglichen TCP-Drei-Wege-Handshake-Prozess konzentrieren, da dies alles ist, was für das Thema dieses Aufsatzes relevant ist.
Hosts in einem Netzwerk, die Daten mit TCP austauschen wollen, müssen zunächst eine Verbindung aushandeln. Hier kommt der TCP-Drei-Wege-Handshake ins Spiel. Der Handshake-Prozess ermöglicht es beiden Hosts, das erfolgreiche Senden und Empfangen von Netzwerkkommunikation zu bestätigen sowie ihre jeweilige Sitzung in Erwartung des Austauschs von Anwendungsdaten einzurichten.
Abbildung 1) TCP Drei-Wege-Handshake
In Abbildung 1 sehen wir einen Client, der eine TCP-Verbindung zu einem Server aufbaut. Der erste Schritt besteht darin, dass der Client ein Synchronisations- oder SYN-Paket sendet. Dieses Paket hat zwei primäre Aufgaben: Die erste besteht darin, die Fähigkeit zu testen, die entfernte Ressource zu erreichen. Wenn dieses Paket erfolgreich weitergeleitet wird, teilt es dem Server auch mit, dass ein entfernter Client den Prozess der Verbindungsaushandlung für den Datenaustausch beginnen möchte. Der Server antwortet mit einem SYN-ACK-Paket (Synchronization and Acknowledgment), das an den Client zurückgesendet wird, der die Verbindung initiiert. Der letzte Teil des Drei-Wege-Handshakes besteht darin, dass der Client auf das SYN-ACK-Paket mit einem abschließenden ACK-Paket (Acknowledgement) antwortet. Sobald dieser Handshake abgeschlossen ist, ist die Verbindung bereit, von der Anwendung für die bidirektionale Übertragung von Daten verwendet zu werden.
Die gängigste Methode für den Transport von TCP-Kommunikation ist über das Internet-Protokoll oder IP. Das bedeutet, dass die TCP-Pakete zwischen Client und Server über IP-Datagramme kommuniziert werden, die mit IP-Adressen für jedes der Geräte adressiert werden.
Wie dieser Angriff funktioniert
Angreifer nutzen diesen Handshake-Prozess aus, indem sie die Quell-IP-Adressen der SYN-Pakete fälschen. Dieses Spoofing veranlasst den Server, das SYN-ACK-Paket an die Opfer-IP zu senden, von der der Server glaubt, dass sie die Sitzungsinitialisierung angefordert hat, und fungiert so als Reflektor.
Abbildung 2) SYN-ACK-Reflection
In Abbildung 2 sehen Sie eine sehr einfache Visualisierung dieses Angriffs. Diese zeigt jedoch nicht, wie ein reales Angriffsszenario aussieht. Die Realität ist, dass TCP für den Betrieb in unzuverlässigen Netzwerken konzipiert wurde, was bedeutet, dass ein einziges gefälschtes SYN einen Server dazu veranlassen kann, mehrere SYN-ACKs in schneller Folge zu senden, wenn er das letzte ACK des Handshakes nicht erhält. Die Anzahl der zu sendenden SYN-ACKs und wie schnell sie gesendet werden, ist eine konfigurierbare Metrik, so dass es schwierig ist, genau abzuschätzen, wie viele SYN-ACKs ein anvisiertes Opfer im Verhältnis zur Menge der von den Angreifern gesendeten gefälschten SYN-Pakete erhalten könnte.
Niedrige Bandbreite vs. hoher PPS
SYN-ACK-Angriffe sind keine typischen Reflection-Angriffe. Eine der Hauptattraktionen von UDP-basierten Reflection-Attacken ist ihr Verstärkungsfaktor, oder die Größe des Pakets, das beim Opfer ankommt, im Vergleich zur Größe des Pakets, das ein Angreifer senden muss. In vielen Fällen beträgt der Verstärkungsfaktor ein Vielfaches der ursprünglichen Anfrage. Im Fall der CLDAP-Reflection ist das resultierende Paket beispielsweise etwa 50-70x größer als das Paket, das der Angreifer senden muss, um die Reflection auszulösen. Amplifikationsangriffe werden oft als volumetrische Angriffe betrachtet, typischerweise mit dem Ziel, die Netzwerkverbindungen zu sättigen, die von den angegriffenen Servern und Anwendungen verwendet werden.
Im Fall von SYN-ACK-Reflexionen ist die Größe des Pakets, das an das Opfer geliefert wird, fast genauso groß wie das vom Angreifer gesendete Paket. Wir sagen „fast die gleiche Größe“, weil es möglich und sehr wahrscheinlich ist, dass, während der Angreifer ein SYN-Paket mit minimaler Länge sendet, einige Router im Netzwerk zwischen dem Angreifer und dem Opfer auch das TCP-Paket modifizieren, um zusätzliche Verbindungsinformationen hinzuzufügen, wie z. B. die TCP-Option Maximum Segment Size (MSS), wodurch die absolute Größe des vom Opfer beobachteten Datenverkehrs erhöht wird. Diese Option sorgt für zusätzliche 4 Bytes pro Paket im Vergleich zu dem, was der Angreifer gesendet hat.
20:56:32.296905 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xfa7c (correct), seq 1000, win 8192, urg 0, length 0
20:56:32.315637 IP (tos 0x0, ttl 124, id 4894, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6e18 (correct), seq 3609252029, ack 1001, win 60720,
options , length 0
Fig. 3) SYN-ACK 4-Byte-Verstärkung
Das bedeutet nicht, dass dieser Angriff keine Bedrohung darstellt. Während mehrerer koordinierter Angriffe gegen Akamai-Kunden wurden mehrere Fälle von Fluten mit hohen Paketen pro Sekunde (PPS) unter Verwendung von reflektiertem SYN-ACK-Verkehr beobachtet. Zwar ist es weniger wahrscheinlich, dass Datenverkehr mit geringer Bandbreite die Verbindungen sättigt, aber die hohen PPS können Probleme für Netzwerkgeräte verursachen, die versuchen, die Flut von SYN-ACKS zu verarbeiten und zu routen, die durch die Netzwerke rauschen.
Was ein Angreifer kontrollieren kann und was nicht
SYN-ACK-Angreifer sind von den TCP-Konfigurationen ihrer Reflektoren abhängig und davon, wie diese ihre TCP-Verbindungen behandeln. Das bedeutet, dass Angreifer in dem, was sie an das Opfer reflektieren können, eingeschränkt sind. Forscher bei Akamai haben einige Zeit damit verbracht, verschiedene TCP-fähige Dienste zu testen, die auf Rechnern im gesamten Internet ausgesetzt sind, um herauszufinden, welche Kombination von TCP-Flags &-Optionen zu den wirkungsvollsten Angriffsszenarien führen könnten. Wir werden einige Angriffsszenarien behandeln, wie sie sich unterscheiden und wie Angreifer SYN-ACK-Angriffe in Zukunft ausnutzen könnten.
TCP-Optionen und gepolsterte SYN-ACKS
Angreifer können den Inhalt eines SYN-ACK-Pakets nicht kontrollieren. Während wir seit Jahren gepolsterte SYN-Floods sehen, ist die Idee eines gepolsterten SYN-ACK nicht etwas, das wir erwarten. In der realen Welt, als SYN-ACK-Angriffe gestartet wurden, hatten die Pakete, die in den Netzwerken der Opfer ankamen, eine vorhersehbare Länge von 44 Byte. Wie bereits erwähnt, bedeutet dies, dass die Angreifer höchstwahrscheinlich optionlose SYN-Pakete mit einer Länge von 40 Byte verschickten, wobei die MSS-Optionen höchstwahrscheinlich von Netzwerkgeräten auf dem Übertragungsweg gesetzt wurden. Daraus ergibt sich ein kleiner Verstärkungsfaktor, aber wir wollten testen, wie groß SYN-ACKs von echten Servern werden können.
Die Tests wurden mit verschiedenen Variationen von TCP-Optionen durchgeführt. Das Ziel der Tests war es, die Optionen zu identifizieren, die zuverlässig verwendet werden konnten und zu einer größeren SYN-ACK-Antwort von zufällig ausgewählten Servern im Internet führten. Die Optionen, die von einem Angreifer verwendet werden könnten und zu größeren SYN-ACKs führen, sind Maximum Segment Size (MSS), Timestamp (TS) , Selective ACK (SAckOK), Window Scale (WScale), & TCP Fast Open (TFO) Cookies.
Einfach durch die Verwendung gültiger Optionen konnte ein Angreifer etwa 62 % mehr Bandbreite verbrauchen als mit einem minimalen SYN-Paket (72 Byte vs. 44 Byte). Durch die Verwendung dieser Optionen verringern Header das Verstärkungsverhältnis (aus 10 % Verstärkung werden 6-7 %); es ist jedoch immer noch möglich, eine Verstärkung zu erreichen, indem man einfach die MSS-Option weglässt, da sie im Transit gesetzt wird, unabhängig davon, ob der Angreifer sie sendet oder nicht.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options
, length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win
60192, options , length 0
Bild. 4) SYN-ACK-Padding mit TFO
Während der Tests war es möglich, die TS, SAckOK, WSCale zu nutzen, & TFO-TCP-Optionen (und NOP-Padding) zu nutzen, um ein 68-Byte-SYN-Paket auszusenden, das zu einer 72-Byte-SYN-ACK-Antwort führte, die dem Opfer zugestellt wurde (siehe Abbildung 4). Wenn ein Host TFO nicht unterstützt, kann ein Angreifer immer noch ein 56-Byte-SYN-Paket ausgeben, das zu einer 60-Byte-SYN-ACK-Antwort führt, die an das Opfernetzwerk weitergeleitet wird, wie unten in Abbildung 5 zu sehen ist.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options
, length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192,
options , length 0
Fig. 5) SYN-ACK-Padding minus TFO
SYN-ACK-Verstärkung
Eine geringe Verstärkung ist mit SYN-ACK-Angriffen möglich, aber es ist möglich, diesen Verstärkungsfaktor zu erhöhen, indem man auf einen zugewiesenen, aber nicht belegten IP-Raum abzielt (d. h. die IP ist routingfähig, aber kein Rechner ist derzeit im Einsatz und/oder wickelt Netzwerkverkehr ab). In diesem Szenario können Angreifer die TCP-Wiederholungsversuche voll ausnutzen, was wiederum den Verstärkungsfaktor und den Bandbreitenverbrauch erhöht.
Wenn ein normaler Rechner ein SYN-ACK außerhalb des Status von einem Reflektor empfängt, antwortet er mit einem RST-Paket, wie unten in Abbildung 6 dargestellt. Dieses RST-Paket wird vom Reflektor empfangen, und die TCP-Sitzung auf dem Reflektor wird beendet.
21:33:15.173204 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xfa7b (correct), seq 1000, win 8192, urg 0, length 0
21:33:15.191517 IP (tos 0x0, ttl 124, id 46635, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xb751 (correct), seq 1209013908, ack 1001, win
60720, options , length 0
21:33:15.191558 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 6) SYN-ACK ohne Status löst eine RST-Antwort aus
Wenn dieses SYN-ACK-Paket für eine IP-Adresse bestimmt ist, die zugewiesen, aber nicht belegt ist, wird das SYN-ACK weitergeleitet (mit Auswirkungen auf die Netzwerkausrüstung auf dem Weg), erreicht aber nie einen echten Rechner, der ein RST ausgeben würde. Das Fehlen des RST-Pakets führt dazu, dass der Reflektor von einer fehlgeschlagenen Zustellung des SYN-ACK ausgeht und erneute Übertragungsversuche startet.
In Tests liegt die Anzahl der erneuten Übertragungsversuche typischerweise zwischen 5 und 7 SYN-ACK-Paketen, die für jedes gesendete SYN an das Opfer gesendet werden. Wenn wir annehmen, dass ein Angreifer einen 40-Byte-SYN sendet, können wir erwarten, dass 5-7 44-Byte-SYN-ACKs das Netzwerk des Opfers durchlaufen. In einem Worst-Case-Szenario mit 7 empfangenen Paketen führt dies dazu, dass eine 40-Byte-Anfrage 308 Byte an Paketen erzeugt, die an den Grenzen des Opfers ankommen, was einem Verstärkungsfaktor von 770 % entspricht. Durch die Verwendung von TCP-Optionen-Headern zur Generierung größerer SYN-ACKs könnte ein Angreifer diese Zahlen auf 56 Byte drücken, was zu 420 Byte reflektiertem Verkehr führt, einem Verstärkungsfaktor von 750 %.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options , length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:24.965713 IP (tos 0x0, ttl 124, id 46784, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfd96 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:26.965689 IP (tos 0x0, ttl 124, id 47738, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf5c6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:30.965750 IP (tos 0x0, ttl 124, id 49898, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xe626 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:38.965701 IP (tos 0x0, ttl 124, id 53757, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xc6e6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:54.965710 IP (tos 0x0, ttl 124, id 61887, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x8866 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
Fig. 7) SYN ergibt 6 SYN-ACKS
TFO, Padding und Amplifikation
TCP Fast Open (TFO) wird hier ausführlicher besprochen, um einige interessante Randfälle abzudecken, die in Tests beobachtet wurden. Durch die Verwendung von TFO-Cookies ist es möglich, größere Antworten auszulösen (zusätzliche 12 Bytes pro SYN-ACK); aufgrund von Versehen in der TFO-Implementierung können diese Maßnahmen jedoch die Verstärkungsfaktoren verändern, und unter verschiedenen Szenarien können die TFO-fähigen Angriffe wünschenswerter sein.
Angreifer, die versuchen, TFO-fähige Reflektoren zu nutzen, können dies nur unter bestimmten Umständen für sich fruchtbar machen. Diese Umstände wären Fälle, in denen es keinen IP-Raum gibt, der nicht von einem lebenden Rechner bearbeitet wird. Wenn ein Angreifer reflektierte SYN-ACK-Pakete an echte Rechner richten muss, die mit RST-Paketen antworten, ist die TCP-Retransmission-Amplification im Wesentlichen überflüssig, da der Reflektor aufhört, SYN-ACKs zu senden, sobald er die RST-Antwort von den Rechnern des Opfers erhält.
Um diesen Vorschlag noch weniger wünschenswert zu machen, werden TFO-fähige Hosts die 12-Byte-Header-Option für das TFO-Cookie nicht in zusätzliche SYN-ACK-Pakete nach dem ersten ausgegebenen Paket aufnehmen. Kurz gesagt bedeutet dies, dass die Verstärkung in diesem Szenario nicht aus einer Reihe von 72-Byte-Paketen besteht, die das Opfer treffen. In realen Tests wurde beobachtet, dass das erste SYN-ACK 72 Byte groß ist, aber die folgenden 5-6 Wiederholungsversuche diese TCP-Option auslassen und zu einem 60-Byte-Paket führen. In diesem Fall resultiert ein 72-Byte-Paket in einer 432-Byte-Reflektion; der einzige Vorteil sind im Wesentlichen die 12 zusätzlichen Bytes des allerersten Pakets gegenüber einer Reflektion ohne die TFO-Cookie-Option.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options , length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:46.651887 IP (tos 0x0, ttl 124, id 51447, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6bb0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:48.651862 IP (tos 0x0, ttl 124, id 52323, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x63e0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:52.651854 IP (tos 0x0, ttl 124, id 54181, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x5440 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:00.651876 IP (tos 0x0, ttl 124, id 58527, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x3500 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:16.651862 IP (tos 0x0, ttl 124, id 2147, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf67f (correct), seq 3436032873, ack 1001, win 60192, options , length 0
Fig. 8) Wegfall des TFO-Cookies nach der ersten Antwort
TFO-fähige Hosts setzen ihre Handshake-Cookie-Maßnahmen zurück, wenn sie ein RST von dem/den angegriffenen Opferrechner(n) erhalten. Das bedeutet, dass ein Angreifer, der echte Rechner mit TFO-fähigen Reflektoren angreift, zuverlässig eine Reihe von 72-Byte-SYN-ACK-Paketen an den Endpunkten des Opfers ankommen lassen kann.
Der Verstärkungsfaktor beträgt nur 4 Byte, wenn man davon ausgeht, dass eine 68-Byte-Anfrage des Angreifers zu einem 72-Byte-SYN-ACK führt, das beim Opfer ankommt, gefolgt von einem RST-Paket vom Opfer zum Reflektor. Wenn dies kontinuierlich geschieht, dann werden die TCP-Sitzungen, die über den Angreifer auf dem Reflektor initiiert werden, immer zu einem SYN-ACK-Paket führen, das die zusätzlichen Bytes enthält, die die TFO-Cookie-Option darstellen.
20:54:41.611605 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x8762 (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:41.629518 IP (tos 0x0, ttl 124, id 14354, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6ade (correct), seq 3714341928, ack 1001, win 60192, options , length 0
20:54:41.629548 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:42.664171 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xc1bd (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:42.682391 IP (tos 0x0, ttl 124, id 15171, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6d0a (correct), seq 3730789605, ack 1001, win 60192, options , length 0
20:54:42.682440 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:43.781512 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x7dde (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:43.800464 IP (tos 0x0, ttl 124, id 15726, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xf5fe (correct), seq 3748251272, ack 1001, win 60192, options , length 0
20:54:43.800534 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 9) TFO-Cookie-Einbindung nach RST
Bedenken zur Entschärfung
Die Entschärfung einer SYN-ACK-Reflexion kann knifflig sein und muss sorgfältig durchgeführt werden. Es ist sehr einfach, diese Art von Angriff zu stark zu entschärfen und selbstverschuldeten Schaden an echten Clients und TCP-Sitzungen in Produktionsnetzwerken zu verursachen. Diese betroffenen Sitzungen würden sich in Verbindungsproblemen, verminderter Leistung und der Blockierung legitimer Hosts/Benutzer in Ihren Netzwerken niederschlagen. Diese Over-Mitigation-Maßnahmen können längere und folgenreichere Auswirkungen haben als der Angriff selbst.
In vielen Fällen kann die Over-Mitigation von TCP-beeinflussenden Angriffen auch unerwartete Folgen für die Opfer haben. Bei SYN-Floods ist es zum Beispiel üblich, dass eine zweite Angriffswelle über das Netzwerk anschwillt, sobald echte Dienste Probleme mit der Konnektivität bekommen. In solchen Fällen ist die „zweite Welle“ alles andere als das und ist typischerweise das Ergebnis von realen Clients/Benutzern, die erfolglos versuchen, legitime Verbindungen aufzubauen; dies führt zu einer Anschwellung von mehr als normalen SYN-Paketen, da die betroffenen Clients weiterhin versuchen, nicht bestätigte SYN-Pakete erneut zu senden.
Eine zu starke Entschärfung eines SYN-ACK-Angriffs könnte wahrscheinlich zu Problemen und ähnlichen Ergebnissen führen, insbesondere wenn die Entschärfung an einem Punkt im Netzwerk stattfindet, an dem echte Clients legitime ausgehende Anfragen stellen.
Die wirkliche Lösung für Reflection-Angriffe
Wie bei den meisten Spoofing-Angriffen liegt die wirkliche Lösung nicht im Einflussbereich einer einzelnen Organisation. Um dieses und andere Probleme im Zusammenhang mit Spoofing-Funktionen wirklich zu lösen, müssen wir uns an die IETF und die Netzwerkbetreiber wenden. Die IETF hat BCP38 veröffentlicht, das beschreibt, wie Netzwerkbetreiber das Routing von gefälschtem Datenverkehr erkennen und verhindern können. Letztendlich ist es etwas, das die Netzwerkbetreiber implementieren und durchsetzen müssen, wenn wir wirklich hoffen, dass diese Arten von Spoofed/Reflected-Attacken verschwinden oder zumindest deutlich schwieriger zu orchestrieren sind.
Zusammenfassung
Reflected SYN-ACK-Attacken sind nichts Neues; sie sind eigentlich so alt wie TCP selbst. Ihre mangelnde Popularität hat eher damit zu tun, dass andere UDP-basierte reflektierte Angriffe weitaus besorgniserregender und wirkungsvoller sind und Angreifern im Allgemeinen ein besseres Instrumentarium zur Verfügung steht. Sie sind kein Nebeneffekt einer fehlerhaften Implementierung, sie sind kein Exploit, sie sind ein Symptom dafür, dass IP-Spoofing im Internet auch fast 20 Jahre nach dem Entwurf und der Fertigstellung der vorgeschlagenen Lösung für Netzwerkbesitzer und -betreiber immer noch möglich ist.
Abgesehen davon können alte Angriffe immer noch schmerzhaft sein, und reflektierte SYN-ACKs sind keine Ausnahme. Unternehmen sollten ihre Fähigkeiten und Optionen zur Abwehr von Angriffen prüfen, da die Netzwerkausrüstung möglicherweise nicht in der Lage ist, hohe PPS-Fluten von Datenverkehr über Grenzen und Netzwerke hinweg zu bewältigen.
Es ist wichtig zu betonen, dass es bei Angriffen dieser Art eine reale Möglichkeit der übermäßigen Abwehr gibt, und sicherzustellen, dass Versuche, diese Art von Angriffen zu bekämpfen, nicht zu selbst auferlegten Ausfällen führen… eine Aufgabe, die viel leichter gesagt als getan ist.