Traffic Shaping mit iptables und tc

Zusammenfassung

Letzten Monat bekam ich einen automatischen Alarm wegen übermäßiger Bandbreitennutzung, normalerweise ein Zeichen für Ärger. In so einem Fall folgt man einem Standardverfahren für Störungen und versucht, die Quelle des Datenverkehrs einzugrenzen, bevor man sie abschaltet. Die Ursache war diesmal aber nicht das, was ich erwartet hatte... und verlangte eine andere Lösung als eine simple Sperre.

Volltext

Alarm wegen übermäßiger Bandbreite

Wer Server verwaltet, merkt schnell, dass der Internetverkehr meist vorhersehbaren Mustern folgt. Wie auf echten Straßen gibt es feste Zeiten, zu denen viel los ist, und ruhige Zeiten.

Dank dieser Regelmäßigkeit lassen sich Auffälligkeiten automatisch erkennen. So wie ein Stau auf der Autobahn zu einer ungewöhnlichen Zeit von einem Unfall kommen kann, können unerwartete Ausschläge im Internetverkehr auf einen Vorfall im Cyberspace hinweisen.

Die Quelle eingrenzen

Zuerst solltest du die Ursache des Problems finden. Dazu analysierst du die Auffälligkeit so:

• Stelle fest, ob der zusätzliche Verkehr eingehend oder ausgehend ist (Upload oder Download?)
• Finde die zugehörigen Quell- und Ziel-IP-Adressen heraus (welcher Server ist betroffen? Wohin geht der Verkehr, woher kommt er?)
• Bestimme die Art des Verkehrs (E-Mail, Web oder etwas anderes?)

Dafür schaust du dir die Verkehrsdiagramme an, die meist Eingang und Ausgang getrennt zeigen. Dann versuchst du, die betroffenen IP-Adressen zu finden. Dazu musst du vielleicht weitere Diagramme (einzelner Server) und Statistiken von Switches, Routern und Servern ansehen. Danach prüfst du CPU-Auslastung und Logdateien, um zu erkennen, welche Anwendung betroffen ist, zum Beispiel Mail oder Web. Je größer die Auffälligkeit, desto leichter ist sie zu finden.

Vielleicht juckt es dich, die Auffälligkeit sofort abzuwürgen, sobald du sie gefunden hast, und den Verkehr zu stoppen. Lass sie aber (zumindest etwas länger) am Leben, damit du so viel wie möglich daraus lernst.

Mit einem Tool wie iftop siehst du in Echtzeit, wie viel Bandbreite jede verbundene IP-Adresse verbraucht. Das ist sehr nützlich, um zu verstehen, was los ist, besonders zusammen mit Logdateien (die IP-Adresse lässt sich einzelnen Konten zuordnen).

Eine ungewöhnliche Ursache

Der Server mit der übermäßigen Bandbreitennutzung war ein Mailserver. Solche Server haben Hacker oft im Visier, um sie in ein Spam-Relay zu verwandeln. Das geht auf verschiedene Weise, meist, indem Spammer einen gültigen Login abgreifen. Dann entsteht viel ausgehender Verkehr, weil die Spammer massenhaft E-Mails verschicken. Läuft auf deinem Server eine Spam-Welle, siehst du das wahrscheinlich in den Logs, denn Spam-Nachrichten kommen oft zurück, und die Mail-Warteschlangen laufen schnell voll. Dann wird es schnell unübersichtlich. Auf diesem Server gab es dieses Chaos aber nicht, nur eine ungewöhnlich hohe Bandbreitennutzung.

Mail (und Spam) wird über das SMTP-Protokoll verschickt, aber der Verkehr auf dem SMTP-Port dieses Servers war ganz normal. Das war sehr ungewöhnlich, denn es hieß, dass der übermäßige Verkehr von etwas anderem kam. Aber von was? Nachdem ich verschiedene Logdateien des Mailservers ausgewertet hatte, wusste ich: Das Protokoll, um das es ging, war IMAP. Irgendwie sorgte ein Client, der per IMAP mit dem Mailserver verbunden war, für riesige Mengen Netzwerkverkehr. IMAP dient dazu, E-Mails zu lesen, nicht zu senden. Auffälligkeiten rund um IMAP sind deshalb sehr selten.

In den Logs des Mailservers fand ich den Nutzer, der den Verkehr verursachte. Ich rief den Kunden an und fragte, ob ihm bei sich etwas Seltsames aufgefallen sei. Wenig überraschend: Sein Computer fühlte sich in letzter Zeit etwas träge an.

Microsoft Outlook in der Synchronisierungsschleife

Nach etwas Herumprobieren am Telefon fanden wir heraus, dass irgendetwas Microsoft Outlook dazu brachte, die IMAP-Ordner in einer Schleife zu synchronisieren. Sein Computer lud dadurch den gesamten Inhalt seines Postfachs immer wieder herunter! Da das Postfach über 40 Gigabyte groß war, entstand ein enormer Datenverkehr. Offenbar liegt das an einem Fehler in Microsoft Outlook, und leider gibt es dafür keine einfache Lösung.

Entschärfen durch Traffic Shaping

Ich stand vor einer schwierigen Wahl: Entweder blockiere ich den (normalen, rechtschaffenen, zahlenden) Kunden, oder ich lasse den übermäßigen Verkehr weiterlaufen (und der Netzbetreiber trägt erhebliche Kosten). Legitime Nutzer zu sperren, die ihr Geschäft per E-Mail betreiben, ist eine sehr schlechte Idee, aber den Verkehr einfach laufen zu lassen, ist auch schlecht. Zum Glück fand ich einen anderen Weg, den übermäßigen Verkehr zu senken und dem Kunden trotzdem Zugriff auf seine Mails zu lassen (mit seiner vertrauten, aber fehlerhaften Outlook-App).

Traffic Shaping

Traffic Shaping ist eine Technik der Bandbreitenverwaltung: Du verzögerst einige (oder alle) Datenpakete, damit der Verkehr zu einem gewünschten Profil passt. Du formst also - im wahrsten Sinne des Wortes - die Verkehrsgrafiken, daher der Name.

Die Technik ist nicht unumstritten, denn sie ist das Gegenteil des oft gepriesenen Prinzips der "Netzneutralität". Mit Traffic Shaping kannst du bestimmten Verkehr absichtlich blockieren oder bremsen (oder dafür extra Geld verlangen). Grundsätzlich bin ich gegen alles, was der Netzneutralität schadet, aber in dieser Lage hatte ich keine brauchbare Alternative. Ich musste den Mailverkehr dieses einen Kunden deutlich bremsen und die Bandbreite senken, ohne ihm den Zugriff auf sein Konto zu nehmen.

Traffic Shaping umsetzen

Um Verkehr zu formen, musst du zwei Dinge tun:

• Verkehr markieren: Du willst nur bestimmten Netzwerkverkehr beeinflussen, hier den IMAP-Zugriff eines bestimmten Clients. Anderer Verkehr soll unberührt bleiben. Dafür markierst du Pakete mit bestimmten Merkmalen, etwa der Client-IP oder Portnummern.
• Die Shaping-Regel durchsetzen: Mit Tools zur Verkehrssteuerung wie 'tc' setzt du die Regel für den markierten Verkehr dann durch. Dafür gibt es mehrere Wege, ein gängiger sind sogenannte "Hierarchy Token Buckets" oder HTBs.

Hierarchy Token Buckets (HTBs)

Im Prinzip funktioniert ein Token Bucket wie eine Begrenzung der Fahrgäste in einem Zug: Es werden nur so viele Token ausgegeben, wie Plätze da sind. Steigen Fahrgäste (oder Datenpakete) in den Zug (oder das Netzwerk) ein, nehmen sie ein Token. Steigen sie aus (oder erreichen ihr Ziel), geben sie es zurück. Mit dem Token-Bucket-Prinzip steuerst du, wie viel Verkehr gleichzeitig im System ist.

Umsetzen kannst du das mit den Netzwerktools "tc" (für Traffic Control) zusammen mit "iptables". Ein Skript kann die Regeln zum Markieren und Durchsetzen setzen. Im Netz findest du verschiedene Beispiele, ich habe dieses hier von Julien Vehent benutzt.

Fazit

Manchmal sind Netzwerkauffälligkeiten nicht das, was du erwartest. Nimm dir deshalb immer die Zeit, ihnen auf den Grund zu gehen! Verkehr blind zu blockieren ist grob. Manchmal musst du deine Methoden verfeinern, um Probleme zu entschärfen.

Unorthodoxe Filtertechniken mag ich nicht besonders, aber manchmal sind sie das einzige Mittel zum Zweck. Wichtig ist, dass du weißt, was du tust und warum du es tust!