Firewall Handbuch für LINUX 2.0 und 2.2 - zurück

Sequenznummern, eine Überprüfung der CRC-Prüfsummen sowie weitere
Untersuchungen (Spoofing, Port, IP....) durch.
Sequenznummern (SSN) und Inkrement (ISN) sind charakteristisch für Betriebssysteme
und Versionen, sie zeigen einem Angreifer, welche Angriffe, z.B. "buffer overflows", DoS
oder andere, mit hoher Wahrscheinlichkeit direkt zum Erfolg führen, und welche Fehler im
Betriebssystem mit Sicherheit schon behoben worden sind.
Nur wenige Hersteller von Betriebssystemen bzw. Firewalls bieten eine "randomisierung"
der TCP-Sequenznummern an, was eine Vorausberechnung der Sequenznummern bzw.
einen session hijacking attack völlig unmöglich macht. Eine schnelle Firewall mit SPF-
Architektur leitet Pakete ohne Veränderung der TCP-Sequnznummern weiter, da sie sich
darauf verläßt , daß der TCP/IP-Stack des Ziel-Servers bei der Zusammensetzung der
Pakete Fehler bemerkt. Die Vorausberechnung der Sequenznummern ist für session
hijacking, also der Übernahme einer Verbindung nach erfolgter Authentifizierung
unbedingt erforderlich, hierzu muß der Angreifer sich möglichst nahe an dem Ziel
befinden. Schnelles Timing ist hier erforderlich. Daher funktioniert session hijacking einer
bereits authentifizierten Verbindung zu einem Server hinter einer Firewall immer dann,
wenn die Firewall selber die Sequenznummern nicht randomisiert.
SPF's haben den Vorteil, schnell zu sein, leider geht das immer auf Kosten der Sicherheit.
So lassen einige Firewalls vom Typ SPF inzwischen keine IP-fragments oder interlaced
fragments mehr passieren, wenn eine Reassemblierung von IP-Paketen durchgeführt
wird. Es können aber die darin enthaltenen TCP Pakete, die z.B. fehlerhafte Prüfsummen
oder zu große Offsets besitzen, immer noch Schaden auf dem Server hinter der Firewall
anrichten.
Die Argumentationsweise der Hersteller besagt, daß die Firewall nicht alle Pakete wirklich
prüfen muß, da z.B. Pakete mit fehlerhafte Prüfsummen (CRC) ja von dem
Betriebssystem hinter der Firewall, z.B. einem NT-Server erkannt und erneut angefordert
werden, wäre da nicht der kleine Fehler im TCP/IP-Stack von NT 4.0 bis SP2 . (Siehe
BUGTRAQ) Dieser reagiert auf ein speziell konstruiertes TCP-Paket nicht nur mit einer
neuen Anforderung dieses fehlerhaften Pakets, sondern initiiert zudem noch eine zweite
Verbindung von sich aus in das Internet, zu einer vom Angreifer zu bestimmenden IP -
Nummer. Hier erwartet der NT-Server eine Antwort von außen über die Firewall zurück,
welche die Firewall auch passieren läßt, da ja ein Verbindungswunsch von innen vorliegt.
Und schon hat ein Angreifer direkten Zugriff auf den NT-Server. Zugegeben, dieser Angriff
ist kompliziert und nur von wenigen Personen durchführbar, aber er funktioniert, und zwar
direkt über die Firewall hinweg. Zahlreiche Beispiele der TCP/IP-Stack-Angriffe auf NT-
Server, die in BUGTRAQ veröffentlicht wurden, funktionieren nachweislich auch durch
diese Firewalls hindurch.
Angesichts stark gestiegener CPU- und Memory-Bandbreiten sollten Firewalls mit
eigenem TCP/IP-Stack und PROXY-Diensten stets bevorzugt werden. Man sollte sich
daher immer gut überlegen, ob man eine Firewall einsetzt, die standardmäßig den
TCP/IP-Stack eines Betriebssystems nutzt (z.B. Microsoft PROXY-Server 2.0, WINGATE,
WINPROXY, CONSEAL........) oder nach dem SPF-Design arbeitet.
Ein dummes Problem bei Firewalls ist, daß man nicht genau weiß, ob die Firewall Teile
des IP-Stacks des Betriebssystems mitbenutzt, oder ob die Firewall sogar ihren eigenen
IP-Stack implementiert. Bei dem Maktführer Firewall-1 3.0 und 4.0 von Checkpoint ist das
Problem, daß die Zahl der Einträge in den connection table begrenzt ist, und die
Firewall-1 den Timeout auf 1 Stunde gesetzt hat. Die Firewall-1 kann dann keine Pakete
mehr annehmen und folglich ist ein DoS Angriff zu 100% erfolgreich. Mit Hilfe eines kleine
PERL-Skriptes auf der Firewall, welches in regelmäßigen Abständen nach den
sogenannten failed closed Verbindungen sucht (Siehe netstat -an), läßt sich das Problem
recht einfach beheben (jedenfalls bei den von mir installierten LINUX Firewalls). Das
Skript kann zudem noch einige anderen Probleme mit TCP/IP Stacks, die LINUX ja auch
hat, beheben. Für Betreiber von mission critical Systemen im Internet kann dies
erhebliche Verluste bedeuten. Von diesen Angriffen ist auch häufiger (nach meinen Test -
Erstellt von Doc Gonzo - http://kickme.to/plugins