Um Firewallregeln zu unterlaufen und Bandbreitenlimits zu entkommen, setzen Anwender ihre Applikationen auf unerwartete Portnummern. E-Mule & Co. erklären den Ungehorsam zum Prinzip und würfeln die Ports aus. Das Layer-7-Patch für IPtables bringt solche ungezogenen Protokolle zur Räson.

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.

Funktionsweise

Um Protokolle mittels regulärer Ausdrücke zu erkennen, muss L7 einen längeren Abschnitt des Datenstroms untersuchen. Der verteilt sich in der Regel auf mehrere Pakete. Per Default untersucht L7 maximal die ersten 2048 Byte oder die ersten zehn Pakete einer Verbindung (ältere Versionen: acht Pakete), je nachdem, was früher eintritt. Der Grenzwert für die Anzahl an analysierten Paketen ist im Proc-Interface einstellbar:

echo Anzahl > /proc/net/layer7_numpackets

Die Menge der gepufferten Bytes lässt sich seit Version 2.0 beim Laden des Moduls ändern. Dafür ist »modprobe ipt_layer7 maxdatalen= Bytezahl« zuständig. In früheren Version war ein Neukompilieren fällig. Im Normalfall sollte der Defaultwert von 2048 Byte aber ausreichen, bei zu großen Werten sinkt die Performance erheblich.

Erkennt L7 ein Protokoll, führt es die via IPtables-Target zugeordnete Aktion aus. Der Aufruf für HTTP lautet »iptables Optionen -m layer7 –l7proto http -j Regel-Target«. Hat L7 aufgegeben ein Protokoll zu identifizieren (weil keins der angegebenen Pattern passt), verwendet es den Namen »unknown«. Eine L7-Regel kann also gegen »unknown« matchen. Während L7 noch auf Daten wartet und das Paket weiter untersucht, gibt es dem Protokoll noch keinen Namen.

Schwieriger Treffer

FTP und das IRC-Teilprotokoll DCC (Internet Relay Chat, Direct Client-to-Client Protocol) sind weithin bekannte Sonderfälle, die den Firewalls schon lange Ärger bereiten [4]. Sie übermitteln ihre Daten über zusätzliche Verbindungen neben den Steuerdaten. L7 identifiziert zwar den Steuerkanal, die Datenverbindungen bleiben ihm aber verborgen. Abhilfe schaffen die Kernelmodule »ip_conntrack_ftp« und »ip_conntrack_irc«, sie sind bei IPtables schon enthalten (»FTP protocol support« und »IRC protocol support« im Konfigurationsbereich »Connection tracking«).

Am besten aufgehoben sind die L7-Matches in der »mangle«-Tabelle [5], bedingt auch in »filter«, aber keinesfalls in »nat«. Beim Blick auf den Paketfluss durch IPtables (vereinfachtes Diagramm in Abbildung 3) entsteht leicht der falsche Eindruck, dass alle eingehenden Pakete die Tabellen »mangle« und »nat« jeweils in der Chain »PREROUTING« durchlaufen. Ausgehende Pakete sind demnach in den gleichen Tabellen, aber in der »POSTROUTING«-Chain zu finden. Wäre diese Annahme korrekt, könnte man L7 an beiden Stellen platzieren.

Abbildung 3: Ein eintreffendes Paket durchläuft bei IPtables immer erst die »mangle«-Tabelle in der »PREROUTING«-Chain; danach folgt die »nat«-Tabelle. Ist das Paket für einen anderen Host bestimmt, leitet das Routing dieses Paket zur »mangle«-Tabelle in der »POSTROUTING«-Chain.

Dummerweise gilt dies nur für die Chains in der »mangle«-Tabelle. Die »nat«-Tabelle sieht ausschließlich das erste Paket einer Verbindung, wenn DNAT oder SNAT zum Einsatz kommen. Dann übernimmt ab dem zweiten Paket der Connection-Tracking-Code alles Weitere und leitet die Pakete an der »nat«-Tabelle vorbei – die NAT-Entscheidung steht ja bereits. Der Versuch, L7 an dieser Stelle einzusetzen, scheitert, weil L7 frühestens ab dem vierten Paket (nach dem Three-Way-Handshake) ein Protokoll identifizieren kann, oft erst noch später.

Zu früh geblockt

In die dritte Tabelle namens »filter« passen L7-Regeln nur, wenn die Chain-Policy auf »ACCEPT« steht. Die Hintergründe werden aus dem Ablauf beim Start einer TCP-Verbindung deutlich:

• Ein SYN-Paket kommt an, um die Verbindung zu initiieren.
• Diese SYN trägt keine Layer-7-Protokollinformationen, also
  kann L7 kein Protokoll erkennen und die L7-Regel trifft (noch)
  nicht zu.
• Das Paket geht weiter durch alle Regeln dieser Chain und trifft
  am Ende auf die Policy. Steht diese nicht auf »ACCEPT«,
  wird das Paket verworfen. Es kommt keine Verbindung zustande.
• Die L7-Regeln treffen in diesem Fall daher nie zu.

Weiter hinten in der Chain eigene Regeln einzufügen, um die ersten Pakete durchwinken, funktioniert nur bei bekannten Ports. Der Sinn von L7 ist aber gerade das Matchen unbekannter Ports, also wären zusätzliche Regeln nicht zielführend. Die Policies der beiden anderen Tabellen »mangle« und »nat« stehen aus gutem Grund fast immer auf »ACCEPT«.

Bei UDP findet kein Drei-Wege-Handshake statt, dieses Protokoll kommt direkt zur Sache. Passt das erste Paket auf den regulären Ausdruck, kommen auch die Antwortpakete bei einer »DROP«-Policy beim Empfänger an. Dafür sorgt das Connection Tracking von Netfilter.

Voller Durchblick

Die besten Ergebnisse erzielt L7, wenn es beide Seiten der Verbindung sieht, also sowohl eingehende als auch ausgehende Pakete. Das ist in den »INPUT«- und »OUTPUT«-Chains (sowie in der »raw«-Tabelle) nicht gegeben. Als problematisch erweist sich das beispielsweise, wenn eine L7-Regel in »INPUT« steht, der mittels regulärem Ausdruck zu suchende Text aber in der Antwort steckt. Dieses zweite Paket passiert nicht »INPUT« sondern »OUTPUT«, wovon die Regel nichts erfährt.

Eine einfache Lösung für dieses Dilemma nutzt die »mangle«-Tabelle. Alle Pakete, die die Firewall erreichen, müssen »mangle« via »PREROUTING« durchlaufen und alle ausgehenden Pakete gehen durch »mangle« und »POSTROUTING«. Daher lautet die Empfehlung:

• Bei weitergeleiteten Paketen (IP-Forwarding) die Regel nach
  Geschmack entweder in »PREROUTING« oder in
  »POSTROUTING« platzieren.
• Paket ist lokal: Regel sowohl in »PREROUTING« als
  auch in »POSTROUTING« einsetzen.

Von dieser Besonderheit abgesehen haben Matches mit L7 die übliche IPtables-Syntax. Folgende Regel versieht alle ausgehenden Pakete (»-A POSTROUTING«) des HTTP-Protokolls (»–l7-proto http«) mit der Marke »10« (»–set-mark 10«):

iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j MARK --set-mark 10

Zu beachten ist, dass die Protokollnamen exakt den Namen der Patterndateien (ohne deren Endung) entsprechen müssen, auch die Groß- und Kleinschreibung muss passen.

Entgegen der Empfehlung der Entwickler ist es durchaus möglich, bei aller gebotener Vorsicht mit L7 auch einzelne Protokolle zu blocken. Allerdings ist es ratsam, die Ergebnisse genau zu kontrollieren und bei Bedarf zusätzliche Maßnahmen zu ergreifen, sonst öffnen sich gefährliche Sicherheitslöcher. Um etwa den direkten Zugriff auf Newsgroups zu sperren, reicht diese Regel:

iptables -A FORWARD -p tcp -m layer7 --l7proto nntp -j DROP

Ein eventuell auf der Firewall laufender News-Proxy oder -Server bleibt von der Forwarding-Regel verschont.

L7 installieren

Für QoS mit dem L7-Patch sind die IProute-2-Tools mit zugehöriger Kernelkonfiguration nötig. L7 allein braucht folgende Pakete: Aktuelles L7-Patch [1] (kürzlich erschienen ist Version 2.0) Protokollbeschreibungen als reguläre Ausdrücke [1] (derzeit 2005-11-20) IPtables-Sourcecode [2] (aktuell 1.3.4, mindestens 1.3.0) Kernelquellen [3]. Distributionsspezifische Kernel lassen sich eventuell auch patchen. L7 v2.0 ist für Kernelversionen bis 2.6.14 und 2.4.31 gedacht. Die beiden L7-Archive entpacken und die Patches anwenden. Dazu jeweils ins Quellverzeichnis von Kernel und IPtables wechseln und »patch -p1 < Patchdatei« aufrufen. Anschließend braucht im IPtables-Paket die neu hinzugekommene versteckte Datei »iptables-1.3.4/extensions/.layer7-test« Ausführungsrechte (»chmod +x«). Die Protokollbeschreibungen lassen sich recht bequem per »make install« in das Defaultverzeichnis »/etc/l7-protocols/protocols/« verfrachten. Wer diesen Ort ändert, muss anschließend das Protokollverzeichnis in jeder L7-Regel angeben. Kernel konfigurieren Für ein sinnvolles Zusammenspiel mit QoS (und für die Beispiele im Artikel) müssen in der Kernelkonfiguration etliche Optionen aktiv sein (»y« oder »m«, Angaben für Kernel 2.6), einige davon sind nur sichtbar, wenn »Code maturity level options | Prompt for development and/or incomplete code/drivers« aktiviert ist. Im Konfigurationsbereich »Networking | Networking support | Networking options | TCP/IP networking« sind zwei Optionen wichtig: »IP: advanced router« »IP: policy routing« und darunter »IP: use netfilter MARK value as routing key« In der Netfilter-Konfiguration unter »Networking | Networking support | Networking options | Network packet filtering | IP: Netfilter Configuration« sind folgende Einstellungen erforderlich: »Connection tracking« und darin vor allem »Connection tracking flow accounting« (Voraussetzung für L7). Zusätzlich »FTP protocol support« und »IRC protocol support«, um FTP- und IRC-Sitzungen zu erkennen. »IP tables support«, darin dann »Layer 7 match support« (Abbildung 2) sowie »netfilter MARK match support«, »Packet filtering«, »Packet mangling« und darin wiederum »MARK target support«. Abbildung 2: Die Konfiguration für L7, Netfilter und QoS liegt verstreut in mehreren Ästen von Qconf. Der »Layer 7 match support« versteckt sich unter »Networking | Networking support | Networking options | Network packet filtering | IP: Netfilter Configuration |IP tables support«. Verstreuter QoS-Support Die QoS-Optionen befinden sich unter »Networking | Networking support | Networking options | QoS and/or fair queueing«; wenn dieser Bereich aktiviert ist, sind dort folgende Häkchen zu setzen: »HTB packet scheduler« »SFQ queue« »QoS support« und darunter »Rate estimator« »Packet classifier API« Zwei QoS-Classifier-Optionen legt das Qconf-Konfigurationswerkzeug etwas überraschend nicht in den QoS-Bereich, sondern eine Hierarchiestufe darüber: »Firewall based classifier« »Traffic policing (needed for in/egress)« Die zuletzt genannte Option erscheint erst, wenn »Packet ACTION« nicht angewählt ist. Mit der fertigen Konfiguration dann den Kernel und anschließend das IPtables-Userspace-Programm kompilieren und installieren. Achtung: »iptables« landet per Default in »/usr/local/sbin«, während die meist schon vorhandene L7-freie Fassung in »/sbin« liegt und damit an einer vorderen Stelle im Pfad.

Teilen verboten

Im Admin-Alltag erweisen sich die Filesharing-Protokolle als großes Ärgernis. Mit höchst phantasievollen Techniken schmuggeln sich die Bandbreitenfresser durch jede Firewall. Port-basierte Filter scheitern, wenn etwa ein E-Mule-Server auf Port 80 lauscht. Manche Filesharing-Software nimmt dazu gleich HTTP. Das Problem löst L7 recht treffsicher mit guten Pattern, etwa für E-Donkey/E-Mule, Bittorrent und Fasttrack.

Die folgende Variante verpasst Filesharing-Verbindungen in der »mangle«-Tabelle via »MARK«-Target ein Stigma und überlässt das eigentliche Filtern der »filter«-Tabelle. So lassen sich unterschiedliche Protokolle zu Gruppen zusammenfassen, für die wenige Filterregeln genügen. Den Admin freut\’s, weil er nur noch an einer Stelle drehen muss, um alle Protokolle einer Gruppe gleichzeitig zu erwischen. Listing 2 zeigt einen Ausschnitt aus einem entsprechenden IPtables-Skript.

01 IPT_PRE="iptables  -t mangle -A PREROUTING  -m layer7 --l7proto"
02 IPT_POST="iptables -t mangle -A POSTROUTING -m layer7 --l7proto"
03 $IPT_PRE  fasttrack -j MARK --set-mark 13
04 $IPT_POST fasttrack -j MARK --set-mark 13
05 [...]
06 iptables -A FORWARD -m mark --mark 13 -j DROP
07 iptables -A INPUT   -m mark --mark 13 -j DROP

Doppelt hält besser

Die ersten beiden Zeilen füllen zwei Variablen, um später Tipparbeit zu sparen. Die Zeilen 3 und 4 versehen die Pakete des Fasttrack-Protokolls mit der Marke »13« – zur Sicherheit in »PREROUTING« und »POSTROUTING«. Diese zwei Zeilen sind für weitere Protokolle zu wiederholen. Die abschließenden beiden Zeilen befördern die Pakete in den elektronischen Mülleimer.

Achtung: Die Patterndatei »fasttrack.pat« verrät, dass das Muster nur Downloads erkennt, aber keine Suchanfragen. Für die meisten Aufgaben ist das völlig ausreichend. Das File verrät auch, dass Fasttrack mit normalen HTTP-Requests arbeitet. Daher ist es nötig, diese Regel vor einer eventuellen HTTP-Regel in der Chain zu platzieren. Kazaa, Morpheus, E-Mesh und Grokster verwenden das Fasttrack-Protokoll.

Zunehmende Verbreitung findet derzeit die Internet-Telefonie (VoIP, Voice over IP). Die Qualität der dazu passenden L7-Pattern ist leider erst mittelmäßig. Für die beiden Protokollstandards H.323 und SIP sind zudem die entsprechenden IPtables-Helfermodule erforderlich, da beide Protokolle auf mehreren Ports gleichzeitig arbeiten. Diese Module benötigen Kernel 2.6.11 oder neuer. Einzig Skype kommt ohne weitere Module aus.

Bandbreitenbegrenzung

Das vorgesehene Anwendungsgebiet von L7 ist QoS (Quality of Service), oft gleichgesetzt mit Traffic Shaping. Das Linux-Magazin 02/05 hatte QoS als Schwerpunktthema, technische Details zur Konfiguration von QoS finden sich dort [6]. Für die folgenden Beispiele kommt ein einfaches Standardsetup zum Einsatz (Abbildung 4), passend für eine maximalen Upload-Rate von 256 KBit und einen 3-MBit-Downlink. Diese Werte sind typisch für viele ADSL-Anbindungen. Listing 3a zeigt die dazu passenden TC-Befehle.

Abbildung 4: Das QoS-Setup (Quality of Service) verwendet drei Bänder mit verschiedener Bitrate, um den Upload-Verkehr in einer ADSL-Anbindung gerecht zu priorisieren.

Das Setup verwendet drei Bänder mit unterschiedlichen garantierten Bandbreiten (120, 80 und 40 KBit). Die beiden höher priorisierten Bänder dürfen sich gegenseitig überschüssige Bandbreite ausleihen. Das 40-KBit-Band ist Verlierer und bleibt immer auf 40 KBit beschränkt. Um die verschiedenen Prozesse, die sich ein Band teilen, gleich zu behandeln, wurde in den Leaf-Klassen die Default-Qdisc »fifo« durch »SFQ« ersetzt. Der Hashing-Algorithmus der SFQs ändert sich alle 10 Sekunden.

Die Classifier in Listing 3b weisen die von IPtables-Regeln gesetzten Marken je einem der QoS-Bänder zu. Der letzte Classifier ist nicht unbedingt notwendig, da alle Pakete ohne die Handles 10 oder 20 automatisch im 40-KBit-Band landen. Dafür sorgt der »default 30« in Zeile 1 von Listing 3a.

01 tc qdisc add dev bond1 root handle 1: htb default 30
02 tc class add dev bond1 parent 1:  classid 1:1  htb rate 240kbit ceil 240kbit
03 tc class add dev bond1 parent 1:1 classid 1:10 htb rate 120kbit ceil 240kbit
04 tc class add dev bond1 parent 1:1 classid 1:20 htb rate 80kbit  ceil 240kbit
05 tc class add dev bond1 parent 1:1 classid 1:30 htb rate 40kbit  ceil 240kbit
06 tc qdisc add dev bond1 parent 1:10 handle 10: sfq perturb 10
07 tc qdisc add dev bond1 parent 1:20 handle 20: sfq perturb 10
08 tc qdisc add dev bond1 parent 1:30 handle 30: sfq perturb 10

01 tc filter add dev bond1 parent 1: handle 10 fw protocol ip classid 1:10
02 tc filter add dev bond1 parent 1: handle 20 fw protocol ip classid 1:20
03 tc filter add dev bond1 parent 1: handle 30 fw protocol ip classid 1:30

Ziel markiert

Um die von L7 erkannten Protokolle dem passenden Band zuzuordnen, kommen IPtables-Marken zum Einsatz. Sie sollen folgende Regeln umsetzen:

• HTTP erhält höchste Priorität. Es handelt sich
  beispielsweise um den Webserver, der Seiten ins Internet
  ausliefert. Zu HTTPS & Co. gibt der Kasten “SSL und
  L7″ Auskunft.
• Alles, was den TOS-Wert 16 (hexadezimal 10, minimaler Delay) im
  IP-Header trägt, geht ebenfalls in das 120er Band, um die
  Interaktivität zu gewährleisten. SSH beispielsweise setzt
  das TOS-Feld auf diesen Wert.
• SMTP, POP3 und IMAP – ebenfalls gehostet auf dem Server
  – gehen in das 80-KBit-Band.
• Der Rest landet im 40-KBit-Band.

Folgende Kommandos setzen die Vorgaben um. Am Anfang steht wieder eine Bequemlichkeitsvariable »IPT« gefolgt von der TOS-Regel:

IPT="iptables -t mangle -A POSTROUTING -o $INET_IFACE -m layer7 --l7proto"
iptables -t mangle -A POSTROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 10
$IPT http -j MARK --set-mark 10
$IPT smtp -j MARK --set-mark 20
$IPT pop3 -j MARK --set-mark 20
$IPT imap -j MARK --set-mark 20

Die letzten vier Zeilen verteilen per L7-Matching die Protokolle in ihre Bänder. Alle Pakete, die nicht mit den Marken »10« oder »20« versehen sind, landen automatisch im 40-KBit-Band. Die Regeln beziehen sich auf die »mangle«-Tabelle und die »POSTROUTING«-Chain. Das passt, weil Traffic Shaping meist nur in ausgehender Richtung sinnvoll ist und hier der Upstream der Engpass ist (256 KBit). Oft laufen Dienste auf dem Rechner selber und die lokalen Prozesse generieren das Banner. Dies läuft ebenfalls durch die »POSTROUTING«-Chain, L7 erkennt die Protokolle zuverlässig.

Wie gut das Layer-7-Patch in der Praxis arbeitet, hängt vor allem von den Patterndateien ab. Hier wäre eine bessere Qualität gerade bei den heiklen VoIP-Protokollen wünschenswert. Standardprotokolle erkennen die erstaunlich einfach gehaltenen Pattern bereits bestens, bei Beachtung einiger Vorsichtsmaßnahmen auch die Sorgenkinder wie FTP oder IRC-DCC. Die Qualität bei den wichtigen (und oft lästigen) Filesharing-Protokollen ist ebenfalls gut.

Bessere Muster

Gerade zusammen mit Traffic Shaping sorgt L7 für Entspannung beim Admin: Er hat für das Katz-und-Maus-Spiel mit den Filesharing-Anwendern einen neuen Trick gelernt. Statt deren Tauschgeschäft komplett zu blockieren, bewährt es sich, die Transferrate angemessen zu bremsen. Die Schuld für langsame Übertragungen werden die wenigsten Anwender im eigenen Netz suchen. Selbst wenn sie den Trick durchschauen, können sie sich nicht beschweren, da ihr Treiben nur selten erwünscht ist. (fjl)