Tatort Internet: Nach uns die SYN-Flut
Seite 2: 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.
