Linux- und Cisco-IOS-Router (und möglicherweise weitere Netzkomponenten) können wegen einer liberalen Handhabung der TCP-Verbindungsflags in bestimmten Konfigurationen den Verbindungsaufbau zu Hosts mit einem TCP-Implementierungsfehler (z.B. Linux) nicht verhindern. (Diese Nachricht wird erneut veröffentlicht, da die erste Fassung fehlerhafterweise die Existenz des Linux-Linux-Problems leugnete.)

Betroffene Systeme

• GNU/Linux-2.x mit 2.x-Kernel, für die Verkehr auf Cisco-IOS-Routern zustandlos (stateless) gefiltert wird.
• GNU/Linux-2.x mit 2.x-Kernel, für die Verkehr auf Linux-2.x-Systemen zustandlos gefiltert wird.
• Wahrscheinlich sind weitere Kombinationen von diesem Problem betroffen.

Nicht betroffene Systeme
Nach gegenwärtigem Kenntnisstand funktionieren die Filter bei folgenden Kombinationen wie erwartet:

• Cisco IOS - Sun Solaris, BSD-Varianten, Windows NT/2000
• Linux 2.x - Sun Solaris, BSD-Varianten, Windows NT/2000
• Falls das connection tracking von netfilter verwendet wird, um den Rückkanal für TCP-Verbindungen zu öffnen, können (den vorliegenden Daten zufolge) Linux-Router für alle Hosts TCP-Verbindungen korrekt filtern.

Einfallstor
TCP-Pakete mit manipulierten TCP-Flags

Auswirkung
Der Paketfilter auf dem Router wird umgangen.

Typ der Verwundbarkeit
Unstimmigkeiten bei der Implementierung des TCP-Protokolls

Gefahrenpotential
Das Gefahrenpotential hängt von der Router/Host-Kombination und der Existenz weiterer Paketfilter ab, kann aber als sehr hoch einzustufen sein.
(Hinweise zur Einstufung des Gefahrenpotentials.)

Beschreibung
Laut RFC 793 tragen TCP-Pakete Flags, die im Laufe einer Verbindung unterschiedliche Werte annehmen. Im ersten Paket, das der Client zum Server zur Einleitung der Verbindung schickt, ist i.d.R. nur das SYN-Flag gesetzt (siehe unten). Von da an tragen alle Pakete in dieser Verbindung ein ACK- oder RST-Flag. Es gibt daher mehrere Möglichkeiten, Pakete, die einen Verbindungsbeginn kennzeichnen zu erkennen. Die üblichen Ansätze sind: sind:

1. nur das SYN-Flag ist gesetzt
2. weder das ACK-Flag noch das RST-Flag ist gesetzt (Cisco IOS)
3. das SYN-Flag ist gesetzt, jedoch nicht eines der ACK- oder RST-Flags (Linux 2.2, Linux 2.4 mit der --syn-Option von iptables)

Von diesen Möglichkeiten erscheint die erste zunächst die zuverlässigste, allerdings kann im Rahmen des TCP-Protokolls auch eine Verbindung mit einer Kombination SYN plus FIN aufgebaut werden. Die BSD-Sockets-Programmierschnittstelle für TCP/IP, die in irgendeiner Form auf nahezu allen heute gebräuchlichen Systemen verwendet wird, sieht keine Möglichkeit vor, den TCP/IP-Stack anzuweisen, in dieser Weise eine Verbindung aufzubauen. Deswegen kommen SYN-FIN-Pakete während des Verbindungsaufbaus in der Praxis nicht vor. Trotzdem bedeutet dies, daß nur die zweite und die dritte Möglichkeit korrekt im eigentlichen Sinne sind.

Auf der Host-Seite unterscheiden sich die Systeme deutlich in der Behandlung von exotischen Flag-Kombinationen beim Verbindungsaufbau. Nach ersten Tests ergibt sich folgendes Bild:

• Linux akzeptiert Verbindungen, die mit SYN- und ohne ACK-Flag initiiert werden. Weitere Flags werden nicht berücksichtigt.
• Die meisten Systeme akzeptieren die SYN-FIN-Kombination (siehe oben).
• Solaris-Systeme reagieren nicht auf SYN-RST-Pakete, ebenso Windows NT 4.0, Windows 2000 und Systeme mit BSD-TCP/IP-Stack.

Bei zustandslosen Filtern für TCP-Verbindungen wird, wie oben beschrieben, anhand der TCP-Flags ein Paket erkannt, das eine Verbindung einleitet. Bei den meisten Regelsätzen für solche Paketfilter findet sich eine Regel, die Pakete, die keine Verbindung starten, durchlassen, in der Annahme, daß sie zu einer bestehenden Verbindung gehören. (Bei IOS geschieht das mit einer Regel der Form "permit tcp any any established".) Falls Filter-Implementierung auf dem Router und TCP-Implementierung auf dem Host nicht dieselben Pakete als verbindungseinleitend erkennen, können entweder erwünschte Verbindungen verhindert oder unerwünschte zugelassen werden.

Insgesamt ergibt sich folgendes Bild für die Filtermöglichkeiten (wobei "BSD-Host" hier auch Solaris und Windows einschließt):

	Linux-Host	BSD-Host
Cisco-IOS-Router	nein	ja
Linux-Router	nein	ja

Hinweis: In der ersten Version dieser Nachricht wurde behauptet, dass Linux-Router für Linux-Hosts in der Voreinstellung (mit --syn) korrekt filtern könnten. Dies ist jedoch nicht korrekt, wir bitten diesen Fehler zu entschuldigen.

Gegenmaßnahmen

• Die Annahme von Verbindungen, die mit SYN-RST-Paketen eingeleitet werden, ist ein Fehler im Linux-Kernel. Es ist davon auszugehen, daß er in einer nächsten Kernel-Version behoben wird.

• Ob Cisco IOS dahingehend ändern kann, daß auch für ungepatchte Linux-Hosts zuverlässig gefiltert werden kann, ist noch unklar. Der Einsatz reflexiver Access-Listen stellt in vielen Situationen keine adäquate Alternative dar (Probleme mit Timeouts, Performance und Router-Stabilität). Erste Experimente mit undokumentierten IOS-Features verliefen nicht erfolgsversprechend.

• Bei Linux-Routern kann auf connection tracking ausgewichen werden, wobei hier jedoch auch die Probleme, die reflexive Access-Listen aufweisen, auftreten können. Zusätzlich können unerwünschte TCP-Flag-Kombinationen verworfen werden, z.B. SYN mit RST und SYN mit FIN:

  $ iptables -I INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j Log_Drop
  $ iptables -I INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j Log_Drop
  

  (Log_Drop ist eine Filterkette, die das Logging wie gewünscht erledigt und danach das Paket verwirft.) Zur Erhöhung der Performance kann es auch sinnvoll sein, mit "-tcp-flags SYN SYN" auf Pakete mit SYN-Flag zu filtern (die im Normalbetrieb seltener auftauchen) und diese Pakete dann in einer separaten Filterkette genauer zu untersuchen.

Der Ansatz von Cisco stellt zwar keinen IOS-Fehler da, ist aber in Situationen wie z.B. in einem typischen Universitätsnetz ärgerlich, wo an zentraler Stelle gefiltert wird, um den Zugriff auf potentiell ungepflegte Server zu verhindern und so das Risiko für Angriffe von außen deutlich zu senken.

Weitere Information zu diesem Thema

• Transmission Control Protocol (RFC 793)
• Simple transactions using TCP (Jens-S. Vöckler)
• W. Richard Stevens, TCP/IP Illustrated, Valume 1, The Protocols, Addison-Wesley

Revisionen dieser Meldung

• V.1.0 (2002-10-21)
• V.1.1 (2002-10-21) IOS-Filter-Beschreibung korrigiert (negiert)
• V.2.0 (2002-10-24) Linux kann auch nicht für Linux filtern, iptables-Workarounds

Hinweis
Die in diesem Text enthaltene Information wurde für die Mitglieder der Universität Stuttgart recherchiert und zusammengestellt. Die Universität Stuttgart übernimmt keinerlei Haftung für die Inhalte. Dieser Artikel darf ausschließlich in unveränderter Form und nur zusammen mit diesem Hinweis sowie dem folgenden Copyrightverweis veröffentlicht werden. Eine Veröffentlichung unter diesen Bedingungen an anderer Stelle ist ausdrücklich gestattet.

Copyright © 2022 RUS-CERT, Universität Stuttgart, https://cert.uni-stuttgart.de/