Tatort Internet: Nach uns die SYN-Flut

Inhaltsverzeichnis

Ich kam gerade aus der Mittagspause zurück ins Büro, als mein Kollege auf den Überwachungsmonitor deutete und mir mitteilte, da sei vor ein paar Minuten „etwas rot geworden“. Auf dem Bildschirm sah ich, dass tatsächlich einer der überwachten Server nicht mehr ansprechbar war

Auf diesem Webserver lief nur eine kommerzielle Software für ein Forum zu einem kleineren Online-Rollenspiel. Ich verwarf sofort den eigentlich auf dem Weg zum Büro gefassten Entschluss, erst mal in Ruhe einen Kaffee zu trinken. Wenn das Forum wirklich „down“ war, würde es in Kürze sehr ungemütlich werden.

Noch während ich meinen PC entsperrte, klingelte mein Handy. Das konnte nur Christian sein, der Projektleiter des Spiels. Ich nahm das Gespräch trotzdem an.  “Hi. Ja, das Forum ist down. Ich habs gesehen und kümmere mich darum. Nein, ich weiß noch nicht, was das sein könnte, lass mich erst mal schauen. Ach, und sag bitte den GMs, sie sollen mir nicht auf die Nerven gehen, sonst dauert es noch länger.“ GMs, das sind Gamemaster, also Mitarbeiter, die die Spieler als Betreuer begleiten. Nette Jungs eigentlich, wenn sie nicht gerade nachbohren, wann es denn wieder weitergeht, bevor man auch nur im geringsten weiß, was los ist. Christian versprach mir, er kümmere sich um die Rasselbande und ich legte auf.

Treffer, versenkt!

Schon die ersten Tests zeigten, dass da was im Argen lag: Die Ping-Anfragen auf die IP-Adresse des Management-Interfaces lieferten vor allem Verlustmeldungen. Die wenigen ankommenden ICMP Echo-Reply-Pakete wiesen extrem hohen Latenzzeiten im Sekundenbereich auf; normal wären bei unserer Standleitung etwa 10 Millisekunden. Der Webbrowser bemühte sich vergeblich, die Login-Seite zu laden. Irgend etwas stimmte definitiv nicht: Der Server war nicht ganz tot, aber richtig lebendig eben auch nicht.

Und wenn die Spieler die Webseite nicht erreichen konnten, war das ein ziemliches Problem. Über das Forum lief extrem viel Interaktion der verschiedenen Spielerparteien, und da das Spiel sehr stark von einer aktiven Spielergemeinschaft abhing, musste das Forum unbedingt laufen. Genervte Spieler gleich weniger Spieler gleich weniger Abonnements – also nicht gut.

Ohne große Hoffnung versuchte ich, per ssh auf die Shell des Systems zu kommen. Wenn schon der Ping kaum klappt, würde eine richtige TCP-Verbindung kaum besser funktionieren. Und genau so war es – nach einer knappen Minute gab ich auf. Da der Forumsserver als virtuelle Maschine lief, hatte ich immerhin noch die Möglichkeit, über die Gastbetriebssystems-Konsole des Virtualisierungsservers mal nach dem Rechten zu sehen. Ich bekam den typischen Debian-Login-Prompt zu sehen und meldete mich an, allerdings nicht ohne sekundenlange „Denkpausen“ zwischen Usernamen- und Passworteingabe.

Auf der Kommando-Shell des virtuellen Servers angekommen, wollte ich zunächst sehen, woher die Last auf dem System stammte. Dazu nutzte ich das top-Kommando und staunte nicht schlecht: Die CPU Auslastung lag deutlich über 98 Prozent und das RAM war komplett in Verwendung, belegt von einer scheinbar ewig langen Liste von Apache-Threads. Typischerweise waren nur etwa eine Handvoll aktiv; der Server lief weit jenseits seiner Lastgrenzen.

Normal ist ein Reboot des Systems nur innerhalb der vorab angekündigten Wartungsfenster erlaubt. Aber da das Forum momentan sowieso nicht zu erreichen war, entschloss ich mich, als erstes einen kompletten Neustart zu versuchen. 

Zu meiner Zufriedenheit startete der Server nach einigen Minuten anstandslos; das Forum lebte wieder. Ich beobachtete, wie sich die Online-Nutzerliste des Forums  wieder füllte. Wenig überraschend war der Ausfall das aktivste Diskussionsthema. In der Zwischenzeit wurde auch das Icon des Servers im Nagios-Überwachungssystem wieder grün und die Sache schien ausgestanden.

Die Syn-Flut

Die Syn-Flut

Allerdings war es ziemlich unbefriedigend, dass ich keine Ahnung hatte, was da passiert war – und ob das nicht wieder auftreten könnte. Das Ganze erinnerte mich fatal an einen Vorfall, von dem mir ein Kollege berichtete. Einer seiner internationalen Kunden bot Online-Wetten an und wurde kurz vor der Fußball-WM mit der Drohung erpresst, seinen Server mitten in der Hauptumsatzphase lahmzulegen. Zum Beweis ihrer Potenz ließen die Angreifer den Worten auch gleich Taten folgen und blockierten den Server für mehrere Stunden mit einer Distributed Denial of Service Attacke (DDoS).

Eine Analyse zeigte, dass es sich dabei um sogenanntes SYN-Flooding handelte. Um eine TCP-Verbindung zu einem Server herzustellen, sendet ein Client zunächst ein SYN-Paket. Der Server registriert den Verbindungswunsch, legt die dafür benötigten Datenstrukturen in Form eines Transmission Control Blocks (TCB) an und antwortet mit einem SYN/ ACK. Ein echter Client antwortet mit einem bestätigenden ACK und nach diesem Three-Way-Handshake steht die Verbindung.

Beim SYN-Flooding schickt der Client in rascher Folge SYN-Anfragen mit gefälschten Absenderadressen an den Server. Dessen SYN/ACK-Pakete gehen ins Leere, aber der Client hat ohnehin nicht vor zu antworten. Der angegriffene Server, der das nicht weiß, muss die TCBs eine Zeit lang aufbewahren. Damit läuft sein TCB-Puffer mit nutzlosen Daten voll, sodasss für ernst gemeinte Anfragen kein Platz mehr da ist. Der Server ist nicht mehr zu erreichen.

Natürlich kann man die Aufbewahrungszeit reduzieren und den TCB-Puffer vergrößern – aber gegen tausende Bot-Netz-Drohnen, die aus allen Rohren feuern, hat man so keine Chance. Das große Plus war, dass der Wettbetreiber sich nicht nur bei seiner Ehre gepackt fühlte, sondern auch bereit war, richtig Geld springen zu lassen. Kurz: Mein Kollege bekam Carte blanche.

Um den Server auch unter Last am Leben zu halten, installierte er einen SYN-Proxy. Das ist ein vorgeschalteter Server, der nichts anderes zu tun hat, als SYN-Anfragen zu beantworten und nur diejenigen an den eigentlichen Server weiter zu reichen, bei denen der Client ernsthaftes Interesse in Form eines ACK-Pakets bekundet hatte.

Natürlich kann auch der SYN-Proxy nicht beliebig viele Daten in TCBs zwischenlagern. Deshalb greift er zu einem erstmals von Dan J. Bernstein vorgeschlagenen Trick namens SYN-Cookies. Dazu bildet er aus den für die Verbindung relevanten Daten wie IP-Adressen und Ports sowie einem Geheimnis einen MD5-Hashwert. Dieses Cookie setzt er als initiale Sequenznummer seines SYN/ACK-Pakets, die normalerweise zufällig ausgewürfelt wird, um Session-Hijacking zu verhindern – also die Übernahme der Verbindung durch einen Angreifer. Der MD5-Hash ist genauso wenig zu erraten wie eine Zufallszahl, erfüllt diese Aufgabe also ebenfalls.

Antwortet der Client tatsächlich, um den Dreiwege-Handshake zu komplettieren, enthält das Antwortpaket eine Bestätigung der Sequenznummer als ACK(nowledge). Der Server bildet erneut den MD5-Hash über das Geheimnis, die Adressen und Ports des ACK-Pakets und vergleicht diesen Wert mit der vom Client bestätigten Sequenznummer. Stimmen die beiden überein, weiß der Server, dass der Client das Cookie von ihm haben muss und stellt die Verbindung her.

Der Vorteil dieses Verfahrens ist, dass der Server für die sinnlosen SYN-Pakete keine Daten speichern muss. Er braucht nur genügend Rechenleistung, um die Cookies in Echtzeit zu berechnen. Mit Hilfe der kombinierten Verteidigungstechniken SYN-Proxy mit SYN-Cookies und etwas Mithilfe des Providers konnte der Server dann in der Tat eine SYN-Flood-Attacke mit einer Bandbreite von bis zu 100 MBit pro Sekunde abwehren. Und wie erhofft ließ sich der Bot-Netzbetreiber nicht auf ein langwieriges Kräftemessen ein, sondern suchte sich ein weniger wehrhaftes Opfer.

Dummerweise half mir das nicht wirklich weiter. Das hier war nicht World of Warcraft sondern eine recht kleines Online-Rollenspiel, und ich musste mit den vorhandenen Ressourcen auskommen. Immerhin hatte ich schon mal einen Sensor. Bei derartigen Vorkommnissen – allerdings bisher eher im Mail- und FTP-Betrieb – hatte ich mir angewöhnt, das Netzwerk-Monitoring anzuwerfen, damit ich bei erneuten Problemen wenigstens nachsehen konnte, was zuvor alles passiert war.

Zu diesem Zweck hatte ich im Rechenzentrum einen dedizierten Server als Messsystem eingerichtet, mit dem ich den gesamten Traffic vor der Firewall in Augenschein nehmen konnte. Dies war vor allem deswegen praktisch, weil ich die Firewall zu dieser Zeit nicht selbst administrierte und mit dem Messsystem überprüfen konnte, ob bei auftretenden Problemen der Fehler bei mir oder im Regelwerk der Firewall lag.

Ich startete also die Netzwerkanalyse-Software Wireshark auf dem Messsystem und setzte einen einfachen Capture-Filter auf die IP-Adresse des Forumsservers. Dabei definierte ich die Aufzeichnung als Multi-Dateimessung und legte einen Ring-Puffer mit 1000 Dateien à  32 MByte an. Das hat den Vorteil, dass die Festplatte nicht voll läuft, weil die ältesten Dateien immer wieder mit neuen Daten überschrieben werden. Allerdings läuft man Gefahr, wichtige Daten zu überschreiben, wenn man nicht schnell reagiert. Ich startete die Aufzeichnung, loggte mich aus dem Messsystem aus, warf noch einen Blick auf das Überwachungssystem – alles grün – und ging mir endlich meinen mühsam verdienten Kaffee holen.

Ich hatte ihn kaum ausgetrunken, als der Server-Status erneut von grün nach rot wechselte. Die Auslastung des Webservers zeigte das gleiche Bild wie schon zuvor: Alles lief extrem langsam und es waren wieder jede Menge Apache-Prozesse zu sehen. 

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.

Kinderspiel

Kinderspiel

Um in Bezug auf die Identität des Angreifers weiterzukommen, sah ich mir die aufgezeichneten Netzwerkdaten näher an. Interessanterweise starteten die Angriffe meist nach 13 Uhr und gingen maximal bis 1 Uhr morgens. Daraus schloss ich, das der Angreifer vermutlich noch zur Schule ging und erst nach Schulschluss wieder am Rechner saß. Dann kam mir eine Idee: Was wäre, wenn er einen Foren-Account hatte? Das ergäbe zumindest mal die E-Mail-Adresse, die für die Registrierung eingesetzt hat. Und vielleicht war er ja sogar selbst ein Spieler, der … aber eins nach dem andern.

Ich öffnete also eines der Tracefiles direkt vor einem Angriff und isolierte sämtliche Verbindungen des Angreifers. Er war durch die Angriffsmuster und die AOL-IP stets leicht zu identifizieren. Ich entdeckte einige HTTP-Anfragen circa 46 Sekunden vor dem Start der Angriffswelle und machte mich daran, aus den Paketen die HTML-Webseiteninhalte zu extrahieren.

Der erste Versuch, mir die komplette HTTP-Sitzung über die Wireshark-Funktion „Follow TCP stream“ anzusehen, scheiterte an der Tatsache, dass der Server die Daten komprimiert verschickt hatte und ich „gzip“ nicht fließend lesen konnte. Also aktivierte ich die bei mir normalerweise abgeschaltete Option „Allow Subdisectors to reassemble TCP streams“ in den Optionen für das Protokoll TCP. Et voilà: Der Protokollanalysator lieferte mir den Webverkehr auf dem silbernen Tablett. Der Angreifer stöberte in einem Thread zum Thema DoS-Angriffe. Offensichtlich wollte er sich am Erfolg seiner Attacken ergötzen – und dabei wurde er leichtsinnig. Denn die extrahierte Webseite zeigte nicht nur den Nachrichtenverlauf, sondern oben rechts auch eine vom Server erzeugte Nachricht:

„Welcome, Blackhat6200“. Bingo! Damit konnte man arbeiten. Ich meldete mich als Administrator im Forum an, suchte mir den Useraccount heraus, und hatte in Null komma Nichts die E-Mail-Adresse, mit der er den Account angelegt hatte. Als Nächstes suchte ich erst mal Online nach Treffern zu dieser Adresse und fand interessanterweise einige Postings in Möchtegern-Hackerforen, wo er unter anderem nach Angriffsmöglichkeiten auf Forumsserver fragte – und zwar genau zu dem Hersteller unserer Software. Dies wurde ebenso dokumentiert wie bereits zuvor die Ergebnisse der Tracefile-Analyse.

Jetzt hoffte ich, dass das gezielte Interesse an diesem Forum nicht zufällig war, und ich es wirklich mit einem verärgerten Spieler zu tun hatte. Und wie ich es vermutet hatte, führte mich die E-Mail-Adresse im Bezahlsystem zu einem Abonnement mit Adress- und Bezahldaten des Users, der tatsächlich in England wohnte. Damit hatte ich im Grunde alles beisammen, was ich herausfinden konnte.

Wenig später traf ich mich mit dem Management des Publishers. Es wurde entschieden, dass die Sache so viel Zeit, Mühe und Geld beansprucht hatte, dass die Unterlagen an die Polizei übergeben und Anzeige erstattet werden sollte. Damit wurde die Rechtsabteilung betraut und ich war aus dem Fall raus. 

Doch einige Wochen später erhielt ich völlig überraschend Mail von Scotland Yard. Der Fall war dort auf dem Schreibtisch eines Constables gelandet, der mich bat, ihm meine Unterlagen zukommen zu lassen. Anscheinend hatte die Polizei in Berlin die Sache zwar weitergeleitet. Allerdings war für sie der Fall damit offenbar erledigt. 

Nachdem ich meine Unterlagen übersetzt und nach London geschickt hatte, dauerte es wieder einige Wochen, bis ich erneut Nachricht von Scotland Yard erhielt. Sie hatten den Verdächtigen verhaftet, seinen Computer konfisziert, forensisch untersucht und ihn verhört. Er gab die Tat ohne Umschweife zu und gab an, aus Ärger über einen Ausschluss aus dem Spiel durch einen Gamemaster gehandelt zu haben. Er wurde wieder freigelassen. Auf seinen Computer hat er vermutlich etwas länger gewartet – und ich hoffe, der Möchtegern-Blackhat hat richtig Ärger mit seinen Eltern bekommen.  (ju)

Diskutieren Sie mit im Forum zu Tatort Internet  oder werden Sie Fan von Tatort Internet auf Facebook

Über „Tatort Internet“

Die Serie "Tatort Internet" wurde ursprünglich im c't magazin veröffentlicht. Sie können dort Experten über die Schulter schauen, wie sie Angriffe im Internet nach allen Regeln der Kunst untersuchen. Die Artikel beruhen auf realen Vorfällen, die tatsächlich stattgefunden haben und mit den beschriebenen Methoden analysiert wurden. Die Rahmenhandlung wurde zumindest von realen Begebenheiten inspiriert.

Der Experte dieser ersten Folge der zweiten Staffel, Jasper Bongertz, arbeitet als Senior Consultant beim Fastlane Institute of Knowledge Transfer in Düsseldorf. Er beschäftigt sich schon seit 1992 mit IT-Security mit Schwerpunkt Netzwerke. Interessante Tracefiles und Paketdumps sind quasi seine bevorzugte Bettlektüre. Die Folgen der ersten Staffel finden Sie übrigens ebenfalls online. (ju)