[vgwort line=“84″ server=“vg08″ openid=“b0a49986d4b74e20b36160370b4a5a24″]
Eine Woche ist es nun her, dass die DDoS Angriffe auf HTTP-Ebene begannen. In Google habe ich noch nicht viel über derartige Angriffsmuster gefunden. Ist auch schwer danach zu suchen. Die HTTP-Anfragen geben zu wenig Information.
Hier die Chronologie des oder der Angriffe.
Mittwoch, 21.11.
Letzten Mittwoch fing es harmlos an. Die Zugriffe (Hits) auf diese Seite vervierfachten sich von etwa 20.000 pro Tag auf 75.000 pro Tag. Das Muster der Zugriffe war immer gleich: Dutzende Zugriff in der Sekunde auf die Hauptseite von mehreren IP-Adressen mit verschiedenen Referer und User-Agent Angaben. Die 50.000 zusätzlichen Zugriffe verdreifachten auch den Datentransfer. Im Grunde nicht schlimm. Aber 1 GByte sinnloser Datentransfer will auch bezahlt werden. [ref]Ich sollte mal öfter nachschauen, wie die Vertragsbedingungen sich ändern. Der Inklusiv-Traffic ist neuerdings unbegrenzt. Na, dann![/ref]
Donnerstag, 22.11.
Am Donnerstag hatte sich der Wind gelegt. Die Zahl der Zugriffe und der Datentransfer war in der normalen Größenordnung, eher etwas niedrig. Aber es war nur die Ruhe vor dem Orkan.
Freitag, 23.11.
Gegen 10:33 Uhr nahm Strato den Server wegen einer DDoS Attack vom Netz, bis dahin waren es nur wenige Zugriffe. Im access_log / error_log des Apache ist von den Angriffen zu diesem Zeitpunkt nichts zu sehen. Nichts bedeutet in diesem Fall rein gar nichts. Wenigstens einen Eintrag hätte ich finden müssen. Es muss ein anderer Angriff gewesen sein, der sich nicht gegen den Apache richtete. (Die anderen Logs habe ich leider bei der Neuinstallation gelöscht, so dass ich nicht mehr nachschauen kann.) Der Rechner war den Rest des Tages nicht mehr verfügbar. Zeit sich um andere Dinge zu kümmern.
Samstag, 24.11.
Gegen 10 Uhr war der Rechner wieder am Netz und erreichbar. Auf Basis der Erfahrungen vom Mittwoch hatte ich ein RewriteRule in die .htaccess geschrieben, die die Abfragen der Angreifer wurden mit einem Fehler „403“ beantwortet. Statt 20-100 KByte pro Anfrage gingen so nur noch 1035 Byte nach draußen. Der Angriff auf den Apache begann dann ab 16:00 Uhr. Mit 187.000 Zugriffen empfand ich den Angriff schon als heftig, aber Dank der RewriteRule hielt sich der ausgehende Datenverkehr in Grenzen. Mit einen Datenvolumen über den Tag von ca. 600 MByte liege ich trotz 10-facher höherer Anfragen nur unwesentlich oberhalb normaler Tage.
Allerdings hatte ich die Kriterien für eine böswillige Anfrage zu eng gefasst, so dass einige Anfragen dennoch vollständig beantwortet wurden, was ich aber erst am Sonntag feststellte. Die Angriffe führen dazu, dass der Speicher zu 90% und der Prozessor meist zu 90-95% ausgelastet ist.
Sonntag, 25.11.
Am Sonntag wurde es richtig heftig. Ein ganzer Monat wäre im Rauschen diese Tags untergegangen. Über den Tag werden es fast 5,6 Millionen Zugriffe und 6 GByte Daten. Ohne die vorhergehenden Maßnahmen und Verbesserungen im Laufe des Tages hätten es leicht 600 GByte werden können. Das access_log erreicht über 700 MByte. Glücklicherweise lässt es sich gut komprimieren. Der Webalizer, der alle Stunde gestartet wird, kann die Daten nicht mehr bewältigen. Am Ende fast 8 Millionen Referer und 25.000 User-Agents zwingen ihn in die Knie und belasten ihn den VServer zusatzlich. Auswertung aussetzen.
Ab und an muss ich den Apache stoppen, um überhaupt arbeiten zu können. Ich bemerke, dass nicht alle unliebsamen Anfragen abgewiesen werden. Aber Strato registriert keinen Angriff und lässt den Server am Netz. Irgendwie will die SuSEfirewall nicht. Sie behauptet, es liefe noch eine andere Firewall. Darüber meckert sie auf diesem VServer schon seit der Installation. Bisher kam ich auch gut ohne klar.
Auch alle Versuche mit iptables sind wirkungslos. Die Suche nach anderen Firewalls verläuft ergebnislos. Es gibt scheinbar keine. Der Versuch die SuSEfirewall trotz ihrer Bedecken zu starten liefert den Hinweis, dass einige Module offensichtlich fehlen. Shorewall gibt es nicht in den Repositories. ip will auch nicht, wie ich will. Reperatur des Systems?
Ich deaktiviere das Plugins Counterize und senke ein paar auf großen Durchsatz ausgelegte Parameter in server-tuning.conf. Verlangsamen um den Rechner zu entlasten. Komisch, aber es funktioniert. Der Speicherbedarf geht von 2 GByte merklich unter 1 GByte zurück und die Prozessorlast bewegt sich auf einem erträglichen Level. Bei fast 100 Anfragen die Sekunde nicht schlecht.
Eine zeitweilige Änderung der IP-Adresse in ein schwarze Loch dauert zwei Stunden bis zur Sichtbarkeit an allen Stellen im Internet. Würde auch alle Nutzer betreffen und keine sinnvolle Lösung. Ich will dem Denial of Service nicht nachgeben. Ich mache die Änderung rückgängig.
Ich versuche, ob die Anfragen automatisch einem Redirekt folgen. Leider nicht. Meine Idee war, die Anfragen auf eine riesige Datei umzulenken, damit die Drohnen sich selbst abschießen. So geht es also nicht. Aber: Eine Umleitung (Fehler „302“) auf http://localhost/ ist nur noch 281 Byte groß. Damit sind die Antworten nochmals 70% kleiner. Allerdings ist die Leitung nicht mein größtes Problem. Bei 100 MBit/s schaffe ich meist so 4 MByte Up-/Download. Mit der Geschwindigkeit brauchen 6 GByte nur etwa 25 Minuten. Aber: Datenvolumen will bezahlt werden.
Montag, 26.11.
Die Angriffe gehen fast unvermindert weiter. Ein Versuch openSuSE 12.1 ohne Neuinstallation mittels zypper aufzudatieren scheitert. Offenbar sollen Dateien überschrieben werden, die der Server sich mit anderen virtuellen Gästen teilt. Da die Repositories hinüber sind, entschließe ich mich, den Rechner neu zu installieren. Bis dahin laufen 1.9 Millionen Zugriffe auf, die aber nur 600 MByte ausgehende Daten verursachen. Da sich die Angriffe auf unter 1.000 IP-Adressen beschränken, müsste dies mit einer Blacklist in der Firewall in den Griff zu beklommen sein.
Dienstag, 27.11.
Der Rechner ist aufgesetzt. Die Wiedereinrichtung ist nicht so einfach. Software ist nachträglich zu installieren, Strukturen sind neu anzulegen und wie üblich haben sich manche Dinge geändert, so dass darüber der Tag vergeht. Sogar die SuSEfirewall funktioniert jetzt! Und meine Regeln wirken.
Nebenbei läuft ein einzelner Rechner Amok und versucht mich weiter meinen VServer anzugreifen. Ca. 112.000 Abfragen kommen durch, bis ich mit der Firewall soweit bin, dass ich mir sicher bin, dass das Regelwerk funktioniert und ich mich nicht etwa selbst aussperre. Das Datenvolumen geht mit ~ 31 MByte im Rauschen unter.
Jetzt suche ich nur noch eine geeignete Stelle, um die zu sperrenden IP-Adressen automatisch in die Blacklist eintragen zu lassen. Dies erweist sich als Performance-Problem. Riesige Log durchsuchen, sortieren und prüfen, ob einen IP-Adresse schon bekannt ist, ist mit Text-Dateien zu aufwändig. Also stelle ich alles auf eine Datenbank um. Dies gibt mir später mehr Möglichkeiten.
Da ich nicht möchte, dass die Angreifer erfahren, anhand welcher Kriterien ich einen Angriff erkenne, und ihren Angriff entsprechend modifizieren, verzichte ich hier auf nähere Erläuterungen.
Mittwoch, 28.11.
Ein friedlicher Tag. Keine Angriffe! Mein Regelwerk ist fertig und der Angreifer macht einfach Pause. Tolle Scholle.
Bevor mich jemand fragt, warum ich nicht mit meinem Provider rede: Ich schreibe mir E-Mails mit ihm, aber es kostet mehr Zeit, als es hilft. Es hilft nichts.
Gute Nacht
Neueste Kommentare