Firewalling und Traffic Shaping mit Analyse der Schicht-7-Protokolle

Ob sie ein Paket passieren lassen, entscheiden Firewalls anhand der IP-Adressen, TCP-Flags, MAC-Nummern, Ports und ähnlicher Kriterien, alle beheimatet auf den OSI-Layern 2 bis 4. Kommandos wie »iptables -A FORWARD -i -o -p tcp --dport 80 --syn -j ACCEPT« geben gute Admins im Schlaf ein. Schade nur, wenn der Webserver nicht auf Port 80 lauscht, sondern auf Port 8500. Oder ein Gameserver diese Nummer missbraucht. Noch schlimmer sind Peer-to-Peer-Anwendungen und deren kaum vorhersagbare Ports. VoIP komplettiert das Chaos. Denn dessen Real Time Protocol (RTP) nimmt sich alle Freiheiten bei der Wahl seiner UDP-Ports.

Selbst wer auf eine Firewall verzichtet, braucht für VoIP meist Traffic Shaping, um dem Echtzeitprotokoll den gebotenen Vorrang zu gewähren. Auch dafür muss ein Router die Protokolle auseinander halten. Die Portnummer taugt nur noch in einfachen Fällen zur Unterscheidung - es hilft nur, sich die übertragenen Daten genauer anzusehen. Für Admins kein Problem, für eine stur nach Regelwerk operierende Firewall aber ein Kunststück. Sie darf sich für die Analyse keine große Pause gönnen und dennoch nicht leichtfertig falsch raten.

Diesen Spagat versucht das L7-Patch für IPtables zu meistern [1]. L7 steht für OSI-Layer 7; auf dieser Schicht sind die Applikationsprotokolle wie HTTP oder SSH angesiedelt (Abbildung 1).

Abbildung 1: Mit installiertem L7-Patch arbeitet Netfilter zusätzlich zu den OSI-Layern 2 bis 4 auch noch in der Anwendungsschicht.

Haferlgucker

L7 untersucht den Inhalt der einzelnen Verbindungen. Im Unterschied zu aufwändigen Application Layer Gateways, die Protokolle nach allen Regeln der RFC-Kunst kontrollieren und nebenbei gefährliche Inhalte (etwa Active-X) ausfiltern, vergleicht L7 den Datenstrom mit flinken regulären Ausdrücken, sie beschreiben charakteristische Merkmale des jeweiligen Protokolls.

Für jedes unterstützte Protokoll erwartet L7 eine eigene Patterndatei. Deren Name besteht aus der Protokollbezeichnung und der Endung ».pat«, beispielsweise »http.pat« für eine Protokolldatei, die HTTP identifiziert. Sie nutzt dazu reguläre Ausdrücke. In den mitgelieferten Files sind alle Alternativen ausführlich erläutert und bis auf einen Ausdruck auskommentiert. Daneben finden sich eine qualitative Bewertung (wie schnell, wie sicher) und bei Bedarf weiterführende Erläuterungen zum konkreten Einsatz. Listing 1a und 1b zeigen die (gekürzten) Definitionen für FTP und SMTP.

01 # Pattern quality: great veryfast
02 # Matches the first two things a server should say.  Most servers say
03 # something after 220, even though they don't have to, and it usually
04 # includes the string "ftp" (l7-filter is case insensitive at the moment).
05 # This includes proftpd, vsftpd, wuftpd, warftpd, pureftpd, Bulletproof
06 # FTP Server, and whatever ftp.microsoft.com uses.  Just in case, the next
07 # thing the server sends is a 331.  All the above servers also send
08 # something including "password" after this code.
09 ftp
10 # actually, let's just do the first for now, it's faster
11 ^220[x09-x0d -~]*ftp
12 # This will match more, but much slower
13 # ^220[x09-x0d -~]*ftp|331[x09-x0d -~]*password

01 # Pattern quality: great veryfast
02 smtp
03 # As usual, no text is required after "220", but all known servers have some
04 # there.  It (almost?) always has string "smtp" in it.  The RFC examples
05 # does not, so we match those too, just in case anyone has copied them
06 # literally.
07 ^220[x09-x0d -~]* (e?smtp|simple mail)

Trennschärfe

Beide Ausdrücke beginnen mit dem Code »220«, der steht nämlich am Anfang beider Server-Banner (»220 Mailserver ESMTP...« oder »220 Welcome to FTP-Server «). Sowohl FTP als auch SMTP arbeiten als Ascii-Protokoll, das die Nachrichten in lesbarer Form in einzelne Zeilen schreibt. Nach dem Code 220 muss laut RFC nichts mehr folgen, aber es darf und ist in der Praxis auch so. Die üblichen FTP-Kommandozeilenprogramme geben diese Nachrichten auch aus. Der Aufruf »ftp kernel.org« zeigt das:

Connected to kernel.org.
220 Welcome to ftp.kernel.org.
Name (kernel.org:jha): anonymous
331 Please specify the password.
Password:

Die »Connected«-Mitteilung in der ersten Ausgabezeile produziert der Client selbst; danach folgt das Banner des Servers, das L7 auch in den übertragenen Daten aufspürt und daran das Protokoll identifiziert. Da im Banner »ftp« vorkommt, erkennt L7 beim Vergleich mit dem regulären Ausdruck (Listing 1a, Zeile 11) das FTP-Protokoll und unterlässt weitere Untersuchungen. Hätte der Server lediglich mit einem - RFC-konformen - »220« geantwortet, wären beide Protokolle für L7 nicht zu unterscheiden. Auch der SMTP-Ausdruck (Listing 1b, Zeile 7) passt nicht.

Im nächsten Schritt sendet der FTP-Client den Benutzernamen, der Server antwortet mit Code 331. Diese Zeile passt auf den derzeit auskommentierten Ausdruck für FTP (Listing 1a, Zeile 13), denn sie enthält die Suchkriterien »331« und »password«. L7 würde das FTP-Protokoll auch hieran erkennen.

Den Treffer landet L7 allerdings frühestens im siebten Paket der Verbindung, vorher kommen Three-Way-Handshake, Serverbanner, Login-Aufforderung und der Login-Name. Das erklärt den Kommentar zu diesem Ausdruck, der frei übersetzt lautet: Erkennt mehr, aber viel langsamer. Scheitert L7 an einem Protokoll, dann macht ein Blick in die jeweilige Protokolldatei zusammen mit dem Mitschnitt einer Session schlau. Ein Vergleich der Verbindungsdaten mit dem Ausdruck zeigt, wo es klemmt.

L7 beherrscht alle IPtables-Standard-Targets (»DROP«, »REJECT«, »ACCEPT« ...). Es wäre damit möglich, ein Firewallregelwerk allein anhand der L7-Matches aufzustellen. Das L7-Projekt rät aus gutem Grund davon aber deutlich ab. Für versierte Angreifer wäre es leicht, gezielt Protokollinformationen zu fälschen, um ein anderes Protokoll vorzutäuschen und damit unerwünschte Kommunikation in das Netzwerk zu schmuggeln. Nützlich sind diese Matches eher als Zusatz zu einem vorher schon strengen Regelwerk.

Das empfohlene und sinnvollere Einsatzgebiet für L7 ist QoS (Quality of Service). Mit QoS landet die falsch erkannte Verbindung schlimmstenfalls in einem Band mit der falschen Priorität. Das hält die Beschwerden der Benutzer auf einem für den Admin erträglichen Level. Der Lohn: Unwichtige Dienste, etwa Tauschbörsen, hält L7 davon ab, die komplette Bandbreite zu blockieren. Eine geschickte Konfiguration bremst diese meist unerbetenen Dienste, um den wichtigen Aufgaben Platz zu lassen. Sie vollständig zu blockieren würde nur die Phantasie der User anregen, die Sperre irgendwie doch zu unterwandern.