Skip to content

Analyse einer DDOS-Attacke

Tagsüber führe ich ein unscheinbares Leben als Administrator für fensterbasierende Operationssysteme, Mausschubser und Käffchenjunkie. Nach Feierabend aber brauch ich ab und an mal was, was die Nerven beruhigt. Was vielleicht erheitert. Etwas entspannendes. Was den Kreislauf runterfährt. Etwas bei dem ich schon fast in meditative Trance verfallen kann. Kurz um: Ich administriere Linux und halte die Jungs auf Abstand, die meinen Internetservern was böses wollen.

Solch einen Fall habe ich heute wieder aufklären können. Schon seit einigen Tagen versuchte ich einen Webserver mit dem üblichen Apache-PHP-MySQL Dreisatz um eine weitere IP-Adresse zu erweitern. Ist an und für sich eine Aufgabe für die Halbschlaf. Aber immer wenn ich die neue Konfig aktiviert habe wurden keine Webseiten mehr ausgeliefert. Auch auf der alten IP nicht. In den Logs war auch nichts mehr zu finden. Mehrfach habe ich die Konfig wieder zurückgedreht und mich auf die Ursachenforschung begeben.

Läuft da vielleicht noch irgend ein Langzeitprozess vom Apache, der sich nicht sauber beendet? Einfach testen. Also wieder neue Konfig aktivieren, Apache stoppen und dann mal sehen, was ein ps -efw so zu Tage förder...

WAS IST DAS? Hunderte von Apache Prozessen, die sich nur langsam beenden? So viel ist auf der Kiste doch gar nicht los. Nach kurzer Zeit sind alle Prozesse beendet. Kein verklemter Prozess bleibt über. Merkwürdig. Also fix das die Reproduzeirbarkeit durch mehrfachen starten und stoppen des Apache verifizeiren. Es ist reproduzierbar.

Nächster Schritt: aptitude install -y tcpdump && tcpdump host NEUEIP endet in einem erstaunten "Fuck! Was ist hier den los???". Auf einer zweiten Konsole schalte ich den Apache wieder ab. Selbst jetzt wo die eingehenden Connections auf den Port 80 der neuen IP keine Antwort mehr bekommen rauschen die tcpdump-Ausgaben so schnell durch, dass ich nichts erkennen kann. Und das bei einer neuen IP...

Jetzt ist klar, dass dies ein externes Problem ist. Ein paar greps, Pipes, awks, sorts und uniqs später weiss ich auch, dass ich nicht nach einem einzigen Täter suchen muss. Die Connections kommen aus allen möglichen Subnetzen. Das Problem ist also mit einer einfachen Firewallrule nicht zu lösen, wenn ich auf der IP einen Webserver betreiben will.

Zur Erklärung: Das das Ding keine Webseiten mehr auslieferte lag ganz einfach daran, dass der Apache in kürzester Zeit die max. Anzahl zugelassener gleichzeitiger Prozesse erstellt hat und trotzdem die Anfragen nicht beantworten konnte. Auf einem Server mit Multicore-CPU und 16GB RAM ohne virtualisierung steht dann auch so viel Wums zur Verfügung, dass man das nicht mehr so wie früher an einer langsamen Konsole merkt.

Jetzt heisst es erstmal wieder die Webseiten online bringen. Also alte Konfig wieder herstellen, so dass der Webserver auf der neuen IP nicht mehr reagiert. Webseiten werden wieder anständig ausgeliefert...

Aber was macht man in solch einem Fall. Ich könnte mir jetzt eine eigene Apache-Instanz nur auf der IP einrichten, die keinerlei Module läd sondern einfach nur jeden Request Logt damit ich mehr Datenmaterial für die Auswertung habe. Aber das ist mir heute nicht kreativ genug. Den Weg kenne ich ja schon. Mir fällt dabei ein, dass ich mal irgendwo mit einem Python-Einzeiler einen Webserver für ein lokales Verzeichnis als Hilfe zum Download verwendet habe. Das war mit dem Modul SimpleHTTPServer. Da muss sich doch was machen lassen...

... wenige Zeilen Python später habe ich einen Webserver, der alles stumpf mit "Hello World" beantwortet, mir dabei aber die notwendigen Infos auf der Konsole logt. Schmale Lösung. Keine große Konfigdatei. Geringer Resourcenverbrauch. Passt schon.

Aus diesem Vorgehen gewinne ich ein Access-Log der Request. Ich lasse den selbstgebauten Webserver nur wenige Sekunden laufen. Was mir dabei an Logzeilen entgegenfliegt hätte wahrscheinlich auch schon zu mehrere 100KB Logfile gereicht. Damit habe ich ausreichend Infos für den nächsten Schritt. Auffällig ist, dass immer die gleiche URL aber mit anderen Parametern aufgerufen wurde. Mit ein bischen Phantasie könnte man aus dem URL-Teil "/Cnt/" schliessen, dass sich das wohl um einen Counter handelt. Aber damit weiss ich immer noch nicht welche Webseite mir das einbrockt. Irgendwo muss der Counter ja eingebunden sein.

Also den Webserver nochmal modifizieren. Diesmal will ich die HTTP-Header haben. Wichtig ist mir dabei der User-Agent, der Host und vor allem der Referer. Am User-Agent ist zu sehen, dass es sich um ganz normale Browser wie Du und ich handelt. Der Host zeigt mir den Namen des Webservers an, den der Browser aufruft. Der Spannung wegen halte ich den mal noch geheim. Im Referrer steht drinne, von welcher Webseite der Brower zu mir geschickt wurde. Und da liegt die Wurzel des Übels. Auf einem Webmail-Interface ist ein Counter eingebaut. Jedesmal wenn ein User in diesem Webmail durch die Gegend klickt wird der Counter aufgerufen. Der Hostname dieses Counters wird wahrscheinlich durch location based balancing auf verschiedene IPs verteilt. Das hängt dann vom Land ab in dem die anfragende IP sitzt. Und alles was aus Deutschland diesen Hostnamen im DNS auflöst erhält die IP, die ich als "neu" bekommen habe.

Also Problem gelöst. Noch kurz das ganze etwas technischer Aufgearbeitet und ins Abuse-Formular des Webmailanbieters gehackt. Eine Support-Ticketnummer habe ich auch schon. Jetzt muss ich erstmal abwarten.

Ach ja. Der Name des Webmail-System ist übrigens mail.aol.com...

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Thomas Heidrich am :

Ich danke Dir für die Deinen toll geschriebenen Blogbeitrag.

Das ist echt herb. Wäre ich an Deiner Stelle gewesen, hätte ich mir je nach Gemütslage überlegt, ob ich nicht mit einem hochperformanten Webserver wie gatling alle Requests mit 301ern beantworten lasse. Die Clients cachen das und bekoffern ab sofort nicht mehr Deinen Server sondern das von Dir ausgewählte Zielsystem. aol.com vielleicht? ;-)

Nach zweiter Überlegung hätte ich diese Idee natürlich sofort verworfen, weil es gegen Administratorgrundsätze verstößt. :-)

Frank Agerholm am :

Naja. Da der Hostname auf besagter Domain geheimatet ist und damit in den Request auch interessante Kekse mitgeliefert werden, hätte diese IP noch ganz andere Potentiale. Aber wie Du schon sagtest. Die Administratorgrundsätze...

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!

cronjob