Spambot TrackBack/1.02 aussperren

Situation

Kürzlich erst berichtete ich davon, wie TrackBack-Spambots täglich mehrere Gigabyte an eingehendem Traffic durch POST-Anfragen auf mein Weblog erzeugen. Durch eine entsprechende Konfiguration meines Weblogs via .htaccess Datei, konnte ich bereits verhindern, dass Unmengen ausgehenden Traffics erzeugt werden. Dazu muss die .htaccess lediglich folgendermaßen abgeändert werden:

<IfModule mod_rewrite.c>
RewriteEngine On
# die folgenden beiden Zeilen einfügen:
RewriteCond %{HTTP_USER_AGENT} ^TrackBack/.*RewriteRule ^.* - [F]
# ab hier kommt der Rest der bereits vorhandenen .htaccess
</IfModule>

Dies sorgt dafür, dass der Webserver Anfragen des Spambots nicht verarbeitet, der Spambot kann somit keinen Eintrag absetzen. Es verhindert nicht, dass der Webserver die Anfrage erstmal verarbeiten muss und daruch Netzwerkverkehr in Richtung des Servers erzeugt wird. Nachdem ich hier und dort im Netz nachgehakt hatte, habe ich einige Tipps miteinander kombiniert um diese Bots zuverlässig auszusperren.

Voraussetzungen

Mein Weblog liegt auf einem angemieteten dedizierten Server. Auf ihm läuft ein Linux (Debian Etch) und die komplette Administration erledige ich selber. Wer die Lösung nachahmen will braucht root-Rechte auf seinem Server, was bei Shared Hosting angeboten nie gegeben ist – sorry Leute!

Teil 1 – ModSecurity

ModSecurity ist ein erweiterndes Modul für den Apache Webserver. Mit ihm lassen sich Anfragen, die an den Webserver gerichtet werden zunächst einmal nahezu beliebig über Regeln untersuchen und ggf. geeignete Maßnahmen ergreifen. Ich habe die aktuelle Version 2.1.0 installiert. Achtet bitte darauf, dass ab Version 2 die Konfiguration stark verändert wurde und vermutlich unter älteren Versionen <= 2 so nicht laufen wird.

Zum Lieferumfang gehörten auch die Core Rules, also grundlegende Regeln. Bis die Datei modsecurity_crs_55_marketing.conf habe ich erstmal alle so übernommen. Diese kümmert sich nur um das bloße Protokollieren der Suchbots von Google, Yahoo und MSN. In modsecurity_crs_10_config.conf habe ich das Modul soweit durchkonfiguriert, im Grunde hat man erstmal nur Pfade und Einstellungen zur Protokollierung vorzunehmen.

Da die Trackbacks der Spambots oft gleich in sehr hoher Frequenz kamen und die Auswertung der HTTP-Requests durch ModSecurity auch Performance kostet, habe ich mich entschieden meine Regel gegen TrackBack/1.02 schon früh laufen zu lassen. Ähnlich wie bei einer Firewall (und mod_security ist gewissermaßen eine Anwendungs-Firewall) wird für jede Anfrage jede Regel der Reihe nach geprüft, bis alle durchlaufen sind, oder aber eine Regel erreicht wurde, die einen Abbruch der weiteren Verarbeitung definiert. So habe ich mich entschieden meine Regel in eine Datei modsecurity_crs_11_al.conf zu setzen, sie wird somit vor den folgenden Regeln in die Ausführungskette gesteckt. Die beinhaltete Regel schaut nun so aus:

SecRule HTTP_User-Agent "TrackBack/1\.02"
"drop,log,auditlog,phase:'1',msg:'TrackBack spambot action',severity:'1'"

Ausformuliert sagt die Regel soviel wie: Untersuche den UserAgent-String des HTTP-Requests. Entspricht dieser dem String „TrackBack/1.02“ (der „.“ wird mit einem „\“ escaped, da es sich bei dem String um einen regulären Ausdruck handelt), dann beende sofort auf TCP/IP-Ebene die Verbdinung mit dem Client (drop), protokolliere den Vorfall im Fehlerprotokoll des Webservers (log), protokolliere den Vorfall im Audit-Log von ModSecurity (auditlog), wende die Regel in Phase 1 an (in ihr werden durch ModSecurity die Request-Header untersucht), ordne dem Vorfall einen Nachricht zu (msg) und klassifiziere den Vorfall als Alarm (severity = 1).

Trifft diese Regel auf einen HTTP-Request zu, protokolliert ModSecurity dies im Fehlerprotokoll des Apache (Error-Log), ggf. auch im Debug-Log (wenn konfiguriert) und im Audit-Log (wenn konfiguriert) von ModSecurity. Die Action „drop“ ist in diesem Fall besonders hilfreich, weil sie das Aufkommen jedes weiteren Datentransfers unterbindet. Wir könnten auch einen HTTP-Response-Code senden, z.B. 404 (Datei nicht gefunden) oder 500 (interner Server-Fehler), aber warum sollten wir das tun? Jedes gewechselte Wort mit einem Bot ist eines zuviel und kostet uns nur Performance und Traffic. Ein passender Eintrag im Apache ErrorLog sieht dann beispielsweise so aus:

[Sun Mar 11 17:45:52 2007] [error] [client 72.232.189.218]
ModSecurity: Access denied with connection close (phase 1).
Pattern match "TrackBack/1\\.02" at REQUEST_HEADERS:User-Agent.
[msg "TrackBack spambot action"] [severity "ALERT"]
[hostname "www.alexander-langer.de"]
[uri "/2005-08-14/die-insel.html/trackback/"]
[unique_id "Y8ktlFjGNIgAACMbB3wAAAAF"]

Teil 2 – Fail2Ban

Fail2Ban ist ein Logile-Scanner, der auf bestimmte Ereignisse in Logfiles reagieren kann. Ähnlich wie ModSecurity wird mit regulären Ausdrücken gearbeitet, um möglichst viel Freiheit bei der Definition der Regeln zu haben. Mit Fail2Ban kommen einige vordefinierte Regeln und Aktionen. So kann man im Hanumdrehen dafür sorgen, dass nach misslungenen Login-Versuchen auf ein geschütztes Webserververzeichnis oder auf SSH die IP des anfragenden Clients für x Minuten gesperrt wird. Die passende Aktion sorgt für einen Eintrag mittels iptables, so dass auf Netzwerkebene (Firewall) gearbeitet wird.

Was wir nun tun ist Fail2Ban auf das Fehlerprotokoll des Apache anzusetzen, in welches ja ModSecurity im Fall der Fälle die Anwendung unserer ModSec-Regel protokolliert. Dazu habe ich im Verzeichnis filter.d für die Filter-Definitionen von Fail2Ban eine Datei apache-modsecurity-trackback.conf angelegt, die folgendermaßen aussieht:

[Definition]
failregex = [[]client <HOST>[]] ModSecurity: .*TrackBack spambot action
ignoreregex =

Der verwendete reguläre Ausdruck erkennt Einträge mit dem von uns in der ModSecurity-Regel definierten Nachricht und liefert Fail2Ban die Infos, die es nun benötigt, nämlich den Zeitstempel des Log-Eintrags und die IP-Adresse des Client.

Im Verzeichnis, in der die jail.conf von Fail2Ban steckt, erzeugen wir nun eine jail.local . Sie ist dazu da eigene Konfigurationen aufzunehmen und vor dem Überschreiben bei Updates von Fail2ban zu schützen. Fail2Ban liest sie automatisch ein. Bei mir hat sie folgenden Inhalt:

[Default]
destemail = ich@meinServer.tld
action = iptables[name=%(__name__)s, port=%(port)s]
mail-whois-lines[name=%(__name__)s, dest=%(destemail)s, logpath=%(logpath)s]
[modsecurity-trackback]
enabled = true
port = http
filter = apache-modsecurity-trackback
logpath = /var/www/web*/log/error.log
maxretry = 1
bantime = 1800

Hier muss man ggf. etwas anpassen, je nach eigenen Pfaden, ob man ein einziges oder mehrere ErrorLogs hat (so wie ich), etc. Diese Regel sorgt dafür, dass beim ersten Auftauchen eines passenden Eintrags in einem ErrorLog die Client-IP für 30 Minuten gesperrt wird. Standardmäßig lasse ich mir alle Bans mit etwas Hintergrundinfos per E-Mail schicken. Diese beginnt dann z.B. so, gefolgt von WHOIS-Informationen und den passenden Log-Einträgen im ErrorLog:

Hi,
The IP 72.232.189.218 has just been banned by Fail2Ban after
1 attempts against modsecurity-trackback.

Erfolg

Es scheint, dass vor allem bei neuen Einträgen ins Weblog die Bots ganz besonders heiß auf mein Weblog werden. Allein heute hat Fail2Ban bis 16:45 Uhr 141 Banne allein auf Basis der Trackback-Regel ausgesprochen! Entsprechend ist nun auch die Traffic-Statistik des Servers wieder minimalisiert. Ich möchte gar nicht wissen wieviel Traffic und damit Kosten der ganze Krempel global gesehen erzeugt…

Ausblick

In näherer Zukunft werde ich meine Konfigurationen für Fail2Ban und ModSecurity noch erweitern. Mittlerweile halte ich beide für unverzeichtbar um einen Root-Server sicherer zu machen. Eine gute Anlaufstelle für ModSecurity-Regeln scheint # Got Root zu sein, auch wenn dort schon ein paar Monate lang keine Updates mehr gekommen sind. Neben dem Ausschluss von bekannten Spammern, E-Mail-Sammlern, etc. wird auch die Abwehr anwendungsspezifischer Angriffe (phpMyAdmin, Typo3, phpBB, …) eine spannende Geschichte werden.

Kommentare (24)

  1. Das sieht sehr gut aus, danke für Deine ausführlichen Erklärungen! Werde ich bei mir die Tage auch mal umsetzen. :)

  2. Im Detail war die Installation von mod_security2 für Apache2 bei mir für Debian Etch (4.0) etwas tricky, weil die Anleitungen, die ich hatte, veraltet waren. Für andere Distributionen mag es das Ganze auch schon installationsfertig geben, k.A.

    Wie ich gestern merkte, hat der erste Spam-Server schon umgeschwenkt und benutzt nun den UserAgent „libghttp/1.0“. Dafür habe ich zunächst die Regel
    SecRule HTTP_User-Agent "libghttp/1\.0"
    “drop,log,auditlog,phase:’1′,msg:’TrackBack spambot action’,severity:’1′”

    hinzugefügt. In der Zukunft möchte ich die Regeln variabler gestalten in der Form, dass mitgezählt wird wie oft eine IP in einem Zeitraum x einen POST auf eine Trackback-URL absetzt und dann entsprechend gehandelt wird. Leider funktionieren meine entsprechenden Regeln derzeit nicht und liefern nen Fehler 500 und in den Logfiles finde ich keinen Hinweis auf das Warum und Wieso. :(

  3. Erst einmal herzlichen dank für diese Anleitung.

    Mir viel das letztens erst auf da die ausgelieferte Zahl der Seiten von einen auf den anderen Tag um den Faktor 5 stieg. Desweiteren waren das 120MB mehr Traffic als an normalen Tagen. Da kann man sich ja ausrechnen was bei grösseren Blogs an zusätzlichem Traffic anfällt.

  4. Ich selbst habe nun seit Wochen schon keinen Trackback-Spambot mehr „gefangen“. Es gab auch keine Auffälligkeiten mehr in den Traffic-Auswertungen und auch Stichproben in den Logs verliefen negativ. Wer und was auch immer dahinter steckt, dieser Server steht wohl nicht mehr auf der Liste – aus Sicht der Bots ist er ja auch gar nicht vorhanden, weils nur Fehler gibt.

  5. Ich habe mal die IP´s durchforstet und 75% kommen au dem DialUP Bereich und dann noch einige Firmen in den USA. Auch auffällig ist das die Bots in index.php posten wollen, was mir eigentlich keinen Sinn zeigt.

  6. Hallo
    Wie hast du das den auf debian etch installiert?Bei mir kommt ein Fehler das mod_security nicht installiert werden kann
    apt-get install libapache2-mod-security
    Kommt
    Die folgenden Pakete haben nichterfüllte Abhängigkeiten:
    libapache2-mod-security: Hängt ab: apache2-common ist aber nicht installierbar
    E: Kaputte Pakete

    MFg
    Rob

  7. Danke für dieses ausführliche Beschreibung.
    Hatte vor einigerzeit und habe es durch umbenennen der entsprechenden Dateien und fail2ban auf die Logfiles „unterdrückt“ bekommen.
    Habe aber dann fail2ban wieder deaktiviert nachdem die Bots von mir gelassen haben.
    Nun sind sie wieder da und ziehen den Server täglich an die Erde.
    Werde das nun mal zusätzlich mit ModSecurity machen :-)

  8. Ich benutze nur die offiziellen Pakete für mein Etch, von daher stehe ich noch einen Schritt davor und bekomme ein „E: Konnte Paket libapache2-mod-security nicht finden“.

    Ist aber nicht so wild, weil selbst Ungeübte ModSecurity2 problemlos selbst kompilieren und einspielen können. Neben dem üblichen Kram (Compiler + Tools) brauchts vorher nocht ein „apt-get install apache2-prefork-dev libxml++2.6-dev“. Der Rest läuft dann im Grunde wie in der offiziellen Installationsanleitung beschrieben.

    Wer noch warten möchte, dem sei gesagt, dass Falko Timme ein „ModSecurity + Debian Etch“ HowTo auf seiner ToDo Liste stehen hat und es demnach irgendwann mal auf howtoforge.com erscheinen wird.

  9. „Der Rest läuft dann im Grunde wie hier beschrieben.“ Leider führt der Link nur wieder zu deinem Kommentar.
    Hast du vieleich einen Link wo die installation „per Hand“ erklärt wird.Ich such mir bei Google die Finger wund. Außerdem bin ich noch Debian neuling
    Rob
    P.S Super wie schnell hier geantwortet wird:)

  10. Oops, habe meinen Link korrigiert. :)

    Das Lustige ist, dass ich seinerzeit selbst auch ne bessere Anleitung hatte. Ich meine es wäre ne englische Anleitung im Weblog eines Niederländers gewesen. Aber ich finds auch nicht mehr in meinen Bookmarks :(

    Vielleicht hilft dir dieser Link.

    Dann gibts es hier auch noch ne etwas ältere Anleitung zum Selberbacken für ne SuSE, die Pfade müssten also ggf. angepasst werden.

  11. Super, dann hast du ja nun die Qual der Wahl, was die Auswahl der Regeln angeht. Wenn man ne Voreinstellung trifft, dass bei Verstößen direkt ein 500er geworfen wird, sollte man in Ruhe alle Webanwendungen durchtesten. Hier und da muss man dann evtl. nohmal Regeln anpassen oder auskommentieren.

  12. Hallo
    Kannst du nichtmal deine rules posten?
    Ich kann fast nichts machen ohne das ich einen 500er bekomme:)Ich habe auch noch alle rules geladen die dabei waren.
    Rob

  13. Ich bin kein Anhänger von „one size fits it all“, von daher glaub ich nicht das unsere aktuellen Regeln ohne weiteres auf allen anderen Setups Sinn machen, da wir ggf. Anpassungen an bei uns laufenden Systemen auf Kundenwebsites gemacht haben (sind aber sehr wenige). Eigentlich fahre ich derzeit lediglich das Standard-Ruleset (20, 21, 30, 35, 40, 45, 50) und eben meine eigene Konfig auf der 11.

    Ich hatte mir seinerzeit noch nen Satz Regeln von http://www.gotroot.com/ runtergeladen, aber bisher noch nicht eingesetzt / evaluiert. Sehr strange ist zudem, dass die Website scheinbar nicht mehr gepflegt wird (obwohl sie sehr gut ist).

    Die Integration steht ebenso auf der ToDo-Liste wie die Evaluierung des Einsatzes von RBLs. Allerdings drückte der Schuh die letzten Wochen viel mehr auf der Mail-Seite, so dass ich noch keine Zeit gefunden habe mich hier näher mit zu beschäftigen.

    Mail ist da auch ein dankbarerer Service, weil an jeder Mail immmer ein Sender und ein Empfänger beteiligt ist. Wenn da was nicht funzt (Mail abgelehnt, Mail als Spam markiert, ..) dann rappelt das Telefon. Wenn aber irgendwo auf der Welt jemand nicht auf eine Website bei uns kommt, oder auf ner Website beim Abschicken eines Formulars nen 501 bekommt, dann zuckt er wohl nur mit den Achseln, schimpft und haut ab, ohne dass wir Feedback bekämen.

    Plan viel Zeit ein, in der du Website und Logfiles checkst ;)

  14. Hallo Alexander
    Hab mir meine Rules auch zusammen gebastellt.
    Werde dann mal die logs beobachten
    Muss ich dir Recht geben mit den Rules von dir und das war von mir nicht bedacht. Aber war schon spät gestern Abend:).
    Und wenn mann sich selber damit außeinander setzt, versteht man sieauch besser
    Aber trotzdem noch ein Dankeschön
    Rob

  15. Hallo Alexander,
    hab mir gerade nochmal fail2ban angeschaut.
    Warum nutzt du nicht den Filter apache-badbots?
    Der Greift doch auch TrackBack/1\.02 ab, oder übersehe ich da was?

  16. Vielen Dank für dieses Tutorial. Fail2ban habe ich bereits erfolgreich installiert. Mein System ist Suse Linux 10.3. Mal schauen, wie sich mod_security installieren lässt.

  17. Ich habe lange nichts mit SuSE gemacht, aber nehme an, du wirst ModSec von Hand kompilieren und installieren müssen. Das ist aber denkbar einfach und ist in der Doku auch beschrieben. Persönlich scheue ich auch so gut es geht davor zurück händisch erstellte Kompilate zu benutzen, einfach weil es den Pflegeaufwand des Systems erhöht (händischer Check nach Updates, manuelles Upgrade), aber glücklicherweise beschränkt es sich aktuell bei meinen Systemen (allesamt Debian Etch) auf ModSecurity 2 und eAccelerator als PHP Bytecode Cache.

    Anschauen sollte man sich in jedem Fall ModSecurityDirektiven für den Apache httpd, wie SecRuleRemoveById. Diese lassen sich global und auch in Directory-, Location-, … Direktiven z.B. in einer htaccess-Datei verwenden um gezielt für einzelne Skripte, Verzeichnisse, Webs, etc. Regeln außer Kraft zu setzen. Beispielsweise musste ich relativ früh eine Regel deaktivieren, die immer anschlug, wenn ich in einem Blogpost bestimmte Dateinamen oder Apache Direktiven erwähnte, weil ModSec diese als Code Injections „erkannte“. Das führt dann zum White Screen of Death.

  18. Hallo,

    ich brauche ein HowTo, wo erklärt wird wie man mod_security2 auf einem Suse 10.3 installiert. Gibt es da vielleicht was?

  19. SuSE 10.3? Ist auch nicht mehr ganz taufrisch… Die Installation aus den Sourcecodes erfolgt im Grunde nach Schema F und ist in der aktuellen offiziellen Dokumentation beschrieben.

  20. Danke … auf einem anderen Rechner läuft derzeit Debian etch … gibt es eine Anleitung, wie ich das mod_security2 dort richtig zum laufen kriege?

  21. Im Grunde ganz genauso, wie in der Doku beschrieben. Ich habs selbst auf ein paar Etch-Systemen (und seit gestern einem Lenny) laufen.

    Alternativ zum selbst kompilieren kann man für Etch-Systeme aber auch aufs Repository von Alberto Gonzalez Iniesta zurückgreifen: http://etc.inittab.org/~agi/debian/libapache-mod-security2/

    Da muss man nur seine sources.list anpassen, updaten, den zugehörigen Key installieren. Siehe auch: http://www.howtoforge.com/apache2_mod_security_debian_etch

Kommentare sind geschlossen.