Trackback-Spambots erzeugen Unmengen an Traffic

Vor einigen Wochen zog ich mit meinen Websites von einem Rootserver zum Rootserver bei einem anderen Anbieter um. Bei diesem habe ich ebenso unlimitierten Traffic inklusive, allerdings auch eine Möglichkeit diesen auswerten zu lassen und Grenzen zu setzen, bei deren Überschreitung ich benachrichtigt werden möchte.

Es dauerte nicht lange und die ersten Warnmails bzgl. der Überschreitung eines selbstgesetzten Traffic-Limits trudelten in meinem Postfach ein. Als ich mir dann die Auswertung des Providers anschaute, schwante mir direkt nichts Gutes. Ausgewiesen wurden mehrere Gigabyte Traffic innerhalb nur einer Stunde und das seltsame war, dass es sich um eingehenden Traffic handelte.

Nach Rücksprache mit dem Provider, der mir einen Ausschnitt des Netzwerkprotokolls zusandte und Recherchen in den Tiefen der Protokolle meines Webservers stellt sich das Bild nun wiefolgt dar:

Von einer relativ hohen Anzahl verschiedener Server werden in relativ kurzen Zeiträumen Unmengen an HTTP-Requests an meinen Webserver gestellt. Ziel dieser Requests ist das Absenden von Trackback-Spam-Einträgen in mein Weblog, denn die Anfragen sind POST-Requests und zielen stets auf Trackback-Adressen der Artikel. Das Problem des Trackback-Spam als solches ist nicht neu und es gibt vielerorts im Web Tipps, wie man ihn unterbinden kann, allerdings verhindern sie nur den Eintrag ins Weblog, nicht aber die Anfrage.

Die Anfragen in meinem Fall kommen alle vom UserAgent „Trackback/1.02“. Zwar blocke ich diesen ab, was mein Weblog frei hält von Trackback-Spam und den Server-Load niedrig hält, allerdings entsteht dennoch Traffic. Pro Anfrage von außen werden 1500 Bytes fällig, die abweisende Antwort meines Webservers schlägt in der Regel nochmal mit 52 Bytes in die andere Richtung zubuche. Die meisten Weblog-Betreiber werden das Traffic-Aufkommen gar nicht zur Kenntnis nehmen, da sie über die entsprechenden Daten nicht verfügen.

Nach Rücksprache mit meinem Provider ist klar, dass dieser mir direkt nicht weiterhelfen kann. Das hatte ich auch nicht anders erwartet. Der Aufwand den kompletten eingehenden Traffic eines Rechenzentrums abzuscannen und auf der Ebene des HTTP-Protokolls zu filtern, ist nicht vertretbar. Geraten wurde mir u.a. mir mal fail2ban anzuschauen. Dabei handelt es sich um ein Programm, mit dessen Hilfe man Logfiles nach selbst definierten Mustern absuchen und Aktionen festlegen kann. So ist es denkbar dieses Skript auf das Logfile meines Apache Webservers anzusetzen, dieses regelmäßig zu checken und automatisch für aufgefundenen IPs von der Trackback-Spam mit o.g. UserAgent Eintrag kommt, über eine Firewall-Regel mit ipchains bereits auf der Ebene des TCP/IP-Protokolls zu blocken.

Damit werde ich mich mal an einem ruhigen Tag, vielleicht am Wochenende, näher beschäftigen. Was mich interessieren würde ist, wieviel Traffic durch diese Spambots zustande kommt. Bei mir geht es derzeit ja nur um Angriffe auf ein einzelnes Weblog. Aber es gibt da draußen ja noch eine ganze Menge mehr…

Nur zur Info: Gestern, am 01.03.2007 verzeichnete mein Provider 9.3 GB eingehenden Traffic für mein Weblog und 0.3 GB ausgehenden Traffic. An einem ereignislosen Tag wie dem 27.02.2007 dagegen hatte ich 3 MB eingehenden und 41 MB ausgehenden Traffic…

Kommentare (7) Schreibe einen Kommentar

  1. Ich bin mal gespannt was Du mit Fail2ban erreichst. Klingt zumindest sehr vielversprechend, denn 9,3 GB Traffic für einen Blog an einem Tag ist schon verdammt hart …

  2. Das „Problem“ ist, dass zur Zeit nichts ungewöhnliches passiert. Da ist es dann halbwegs schwer Maßnahmen zu ergreifen und zu testen. Aber zuletzt waren zwischendurch auch immer wieder mal mehrere Tage Pause. Ich denke es wird schon wieder kommen und dann schauen wir mal.

  3. Bei mir hat fail2ban wirklich was gebracht damals. Die Kack-Bots haben mir immer die ganze Kiste an die Erde gezogen.
    Wohl habe ich fail2ban nicht auf den UA konfiguriert, sondern direkt auf den Auffruf der comments.php. Der UA lässt sich zu schnell ändern.

  4. fail2ban in meinem Fall auf URLs die auf /trackback enden anzusetzen, wäre auch ne Möglichkeit, da hast du Recht. *überleg*

    Inzwischen habe ich mod_security installiert und warte nun auf die Rückkehr meines speziellen Freundes um zu testen, ob meine Regel auf ihn anspricht. Dann würde ich fail2ban entsprechend konfigurieren die Ausgabe von mod_security im error.log des Apache zu parsen. Wenn man aber mal einen Spambot braucht, ist keiner da ;)

    Beizeien muss ich dann meine Erfahrungen und Anleitung (es war etwas abenteuerlich mit veralteten Anleitungen mod_security einzubinden) mal runterschreiben und als potenzielles Weltkulturerbe zur Verfügung stellen.

  5. Pingback: Alexander Langer » Spambot TrackBack/1.02 aussperren

  6. @ Alexander

    Meinst Du es würde was bringen, wenn Du die jeweiligen IPs per .htaccess sperrst? Dann dürfte doch noch nicht mal mehr Traffic verbraucht werden, oder?

  7. Das Sperren per .htacess hat mehrere Nachteile gegenüber der Lösung, die ich in Spambot Trackback/1.02 aussperren vorschlage:

    1. Zum Zeitpunkt wo der Apache Webserver die .htaccess ausführt ist die Anfrage (ein POST-Request des Bots, der den kompletten Spameintrag enthält) bereits vom Server entgegen genommen und verarbeitet worden. Dadurch wurde bereits eingehender Traffic generiert und der Webserver hat eine Apache-Prozess abgestellt um diese zu verarbeiten, bis er schlussendlich die .htaccess auswertet. D.h. Traffic und Last wurden durch die Bot-Anfrage bereits generiert.

    2. Die Adressen händisch einzupflegen ist viel Aufwand und benötigt einen Admin, der ständig die Logs überprüft, Adressen extrahiert und diese dann der .htaccess Datei hinzufügt.

    3. Hat der Admin einer Maschine den Bösewicht gefunden und eliminiert ist sein System sauber, aber durch die .htaccess weiterhin (mglw. bis in alle Ewigkeit) gesperrt.

    Von daher halte ich die Lösung modsecurity + fail2ban für überlegen. Das System erkennt den Übeltäter selbstständig, es sperrt ihn auf Netzwerkebene (es wird kein eingehender Traffic erzeugt und kein Apache Prozess angeworfen der für Last sorgt), es meldet ihn an den Admin und gibt die Adresse nach einer einstellbaren Zeit auch wieder frei.

    Wenn es einen wirklich hart getroffen hat, sorgt dieses Vorgehen dafür, dass man innerhalb kürzester Zeit keine Attacken mehr abbekommt. Da während der Sperre sich das System aus Sicht des Bots benimmt, als würde kein Webserver auf dem Rechner laufen / als wäre die angefragte Domain / IP nicht aktiv, vermute ich einfach, dass die IP / Domain Stück für Stück aus den Listen der Spammer entfernt wird. Derzeit verzeichne ich vielleicht noch ein bis zwei Sperrungen im Monat auf Basis o.g. Signatur. Diese Vorfälle melde ich entsprechend und oft genug erhält man auch Feedback, dass man sich des Problems annimmt, ein Kundenaccount gesperrt, ein Rechner neu aufgesetzt, … wurde.

    Für alle die ihre Website / ihr Weblog auf einem Shared Hosting Account betreiben gibt es allerdings kaum eine andere Möglichkeit als über .htaccess. Evtl. würde es aber helfen den eigenen Hoster auf diese Artikel aufmerksam zu machen, denn auch sie dürften Interesse daran haben, dass kein Spambot-Netz ihre Server zum Erliegen bringt.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.