Tatort Internet: Nach uns die SYN-Flut
Seite 3: Der Heuhaufen
Der Heuhaufen
Messdaten remote auszuwerten ist nur begrenzt sinnvoll; man verbringt mehr Zeit mit dem Warten auf Bildaufbau als man wirklich Daten auswertet. Also lud ich mir die Dateien per FTP auf meine Workstation herunter, um sie lokal in Wireshark zu analysieren, während die Messung auf dem Server weiter lief. Das letzte Tracefile sah auf den ersten Blick nach ganz normalem Web-Traffic aus: Es wurden Webseiten angefragt und ausgeliefert. Also hatte ich es schon mal nicht mit einem SYN-Flood-Angriff eines Bot-Netzes zu tun.
Statt nun planlos durch die endlose Paketliste zu scrollen und darauf zu hoffen, dass mir etwas Interessantes ins Auge sprang, wandte ich mich zunächst den Statistikfunktionen von Wireshark zu. Die führen völlig zu Unrecht ein Schattendasein – vermutlich haben die meisten Anwender schlechte Erinnerungen an Statistik in der Schulzeit. Die Endpoint-Statistik zeigte zunächst keine auffälligen Häufungen – weder nach Anzahl der Pakete noch nach übertragener Datenmenge.
Dass der Server auf Port 80 selbst die Statistik mit großem Abstand anführte, überraschte wirklich nicht. Also wandte ich mich der nächsten Statistik zu: den Conversations, also Verbindungen, und in diesem Fall natürlich für das TCP-Protokoll. Es wurden insgesamt 1797 Verbindungen aufgelistet, und ich scrollte einmal komplett durch die Einträge, um mir einen Eindruck zu verschaffen. Dabei fiel mir eine IP Adresse auf, die mit sehr vielen extrem kurzen Verbindungen und mehr oder minder linear ansteigenden Ports arbeitete. Ich wählte eine davon aus und nutzte das sehr praktische Popup-Menü, um die Verbindung herauszufiltern.
Wireshark generierte automatisch den passenden Display-Filter und fräste sich durch den Trace, um mir die zur Verbindung gehörenden Pakete zu isolieren. Es zeigten sich mehrere SYN-Pakete und nach dem dann noch erfolgreichen Verbindungsaufbau eine HTTP-GET-Anfrage auf das Web-Root-Verzeichnis, die – zumindest in diesem Trace – unbeantwortet blieb. Soweit also noch nicht weiter ungewöhnlich.
Aber bei der weiteren Untersuchung der vielen anderen Verbindungen dieser IP zeigte sich, dass dieser Knoten wahllos und in extrem schneller Folge immer wieder die gleichen Anfragen stellte. Ich filterte auf die verdächtige IP-Adresse und suchte mir eine entsprechende Stelle ziemlich am Ende des Tracefiles. Hier konnte man jetzt schon in der Paketliste sehen, wie der Angreifer – und so musste man ihn ab diesem Fund bezeichnen – gezielt den Webserver mit sinnlosen Anfragen bombardierte.
Normalerweise dürfte ein einzelner Anwender durch Anfragen auf statische oder einfache dynamische Webseiten den Server nicht in die Knie zwingen. Das Problem war jedoch, dass die kommerzielle Forumssoftware mit eigenem Code aufwendig mit dem Spielportal und der Spielengine verknüpft war. Bei jedem Aufruf des Forums wurden Spielerstatistiken und spielinterne Counter aus der Datenbank geladen, was den Ladeprozess jeder Seite enorm aufwendig machte – und somit den Angriff von einer einzelnen IP aus erfolgreich werden ließ.
Das war einerseits gut und andererseits schlecht: Gut, weil man bei nur einer Angreifer-IP damit rechnen konnte, den Angreifer darüber identifizieren zu können, aber auch schlecht, weil anscheinend ein Angreifer alleine schon reichte, um den Server zu erledigen.
Es gab nun mehrere Dinge zu tun. Zunächst musste ich einen Weg finden, den Angriff zu vereiteln und den regulären Forenbetrieb für die normalen Anwender sicherzustellen. Zweitens mussten die Beweise für den Angriff gesichert werden, was noch die einfachste Aufgabe darstellte. Und dann musste ich soviel wie möglich über den Angreifer herausbekommen, um etwas gegen ihn unternehmen zu können.
Als Erstes schaute ich mir an, ob es bei den Angriffen ein Muster gab, über das man eventuell das eingesetzte Angriffswerkzeug erkennen könnte. Leider war in den Paketen nichts Ungewöhnliches zu erkennen, sodass es im Grunde genommen auch eine einfache Schleife mit Aufrufen von wget hätte sein können.
Was die Abwehr des Angriffs anging, wäre natürlich das Blockieren der IP-Adresse des Angreifers durch die Firewall die naheliegendste Maßnahme. Ich warf einen kurzen Blick auf www.dnstools.com und ließ mir dort die WhoIs-Informationen zu der IP heraussuchen: eine Adresse aus dem Einwahlbereich von AOL UK; der Angreifer saß höchstwahrscheinlich in England.
Ein Blockieren seiner IP brächte – wenn überhaupt – nur kurze Entlastung, denn sobald er sich neu in das Netz einwählte, bekäme er eine neue dynamische IP und der Filter ginge ins Leere. Als vorläufige Maßnahme bat ich den Firewall-Administrator trotzdem, die IP-Adresse zu blocken und startete den Webserver neu. Während sich der Webserver wieder mit Forumsnutzern füllte, sah ich im Messsystem, dass der Angreifer ausgesperrt war. Seine SYN-Anfragen blieben unbeantwortet, weil sie den Server nicht erreichten.
In den nächsten Tagen entwickelte sich ein Katz-und-Maus-Spiel. Wann immer der Angreifer eine neue IP-Adresse erhielt, bombardierte er den Forumsserver, bis wir auch diese Adresse aussperrten. Ich begann also meine Möglichkeiten durchzugehen. Das Online-Spiel war ein eher kleines Projekt mit sehr beschränkten Ressourcen. Damit waren schon mal alle Lösungen vom Tisch, die den Einsatz zusätzlicher Hardware erforderten. Auch den Umbau der Web-Applikation, etwa mit einem effizienten Caching der Spielstände, musste ich nach einer kurzen Abschätzung des Aufwands auf eine eher langfristige Wunschliste setzen.
Die Firewall war leider auch keine echte Hilfe. Schon mit einem halbwegs aktuellen Linux-System könnte man via
iptables -I INPUT -m state --state NEW -m recent --set
iptables -I INPUT -m state --state NEW -m recent \
--update --seconds 60 --hitcount 11 -j DROP
die Zahl der Verbindungsaufbauversuche pro IP-Adresse auf 10 pro Minute beschränken. Der Firewall-Admin beteuerte jedoch hoch und heilig, dass das steinalte Debian der Firewall das nicht könne; vielleicht hatte er auch einfach keine Lust auf Experimente. Letztlich blieb mir nichts anderes übrig, als zumindest vorläufig den kompletten IP-Bereich von AOL UK zu blockieren. Natürlich liefen wir damit Gefahr, auch redliche Kunden auszusperren. Aber die permanenten Downtimes, die alle Kunden betrafen, waren die schlimmere Alternative. Die Maßnahme zeigte Wirkung; die Angriffe waren schlagartig vorbei und der Server lief wieder stabil.
