Es ist schon traurig, da werden die Bandbreiten immer größer, man kann von zu Hause mit 100MBit ins Netz, nur wer hat davon am meisten?
Richtig, die Bot Netze mit ihrer unerschöpfliche Gier nach Bandbreite! Ich habe den heutigen Tag 
eigentlich nur damit zugebracht, mich mit Bilderklau, - auch so eine Seuche - und mit Referrer Spam auseinanderzusetzen.
Die allseits empfohlenen Rewrite Rules für Referrer Spam sind nicht so einfach automatisch umzusetzen und weil der Großteil der Spammer eh von dynamischen IPs kommen ist's auch eher sinnlos und kontraproduktiv. Was also tun?
2006 war mal im Linuxmagazin ein Bericht über ein neues Modul für den Apache. libapache2-mod-evasive. Das dient dazu DOS (denial of Service) Attacken automatisch zu blocken. Damals war es nicht ganz trivial das Modul auf einem Stable Debian Server zu installieren, heute genügt dazu ein schlankes apt-get install libapache2-mod-evasive und ein wenig fine tuning.
Das fine tuning beschreibe ich hier.
Man kann als fauler Admin auch einfach alles in Ruhe lassen, es funktioniert sofort. Denn das Modul wird durch die Installation automatisch enabled und hat funktionierende default Parameter.
Ob das Modul seine Arbeit tut, erfährt man durch einen Blick in /var/log/daemon.log und auch durch die Einträge in /tmp/dos-* .
Wo wir auch schon beim Thema Faul wären. Der Apache sollte temporäre Dateien nicht einfach in /tmp schreiben. Da lauern diverse Falle, die Angreifer leicht ausnutzen könnten. Beispielsweise ist hier ein Bericht dazu. Der engagierte Admin wird das also ändern wollen. Das ist ganz einfach. Zuerst eine neue Heimat suchen:
mkdir /var/log/apache2/evasive
chown -R www-data:adm /var/log/apache2/evasive
Nun muß das dem Modul mitgeteilt werden:
in /etc/apache2/mods-available/mod-evasive.load habe ich folgende Einträge drin:
Die Beispiel default Einträge habe ich zur Referenz auskommentiert darunter aufgeführt.
LoadModule evasive20_module /usr/lib/apache2/modules/mod_evasive20.so
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1.5
DOSSiteInterval 1.5
DOSBlockingPeriod 10
DOSLogDir "/var/log/apache2/evasive"
#
# DOSHashTableSize 3097
# DOSPageCount 2
# DOSSiteCount 50
# DOSPageInterval 1
# DOSSiteInterval 1
# DOSBlockingPeriod 10
#
Kurze Erklärung der Parameter:
DOSHashTableSize: Die Größe der Hashtable, die für die einzelnen nodes benutzt wird. Könnte für einen ApacheServer mit starkem Verkehr erhöht werden. Es werden Primzahlen benutzt. Es wird immer auf die nächst höhere gerundet.
DOSPageCount: Schwellwert für die einzelnen Seiten pro DOSPageInterval , ab wann die Ip auf die Blacklist kommt.
DOSSiteCount: Schwellwert für alle von einem Client angeforderten Resourcen pro DOSPageInterval, ab wann die Ip auf die Blacklist kommt.
DOSPageInterval: Zeitraum, für die einzelnen Seiten, default 1 Sekunde
DOSSiteInterval: Zeitraum, für alle Aufrufe der Site, default 1 Sekunde
DOSBlockingPeriod: Zeitraum für die der Eintrag in der Blacklist steht, default 10 Sekunden, größer ist normalerweise nicht notwendig
DOSLogDir: Absoluter Pfad zum (existierenden) Directory für die Ablage der Blacklisteinträge.
Daneben gibt es noch die Möglichkeit einige IP-Adressen auf eine Whitelist zu setzen und weitere Einstellungen wie DOSEmailNotify, DOSSystemCommand
Dazu steht mehr in der Original Readme.
Der Autor des Modules hat im README (zless /usr/share/doc/libapache2-mod-evasive/README.gz) ausdrücklich darauf hingewiesen, das in der /etc/apache2/apache2.conf noch ein paar Einstellungen überprüft werden sollten. So muß KeepAlive auf On stehen und MaxRequestsPerChild darf nicht auf 0 sein,weil sonst die gespeicherten Blocks nicht gelöscht werden würden. Ich habe mal 20000 eingestellt, der Debian default für MaxRequestsPerChild ist 0. Der KeepAliveTimeout steht schon bei Debian auf 15, icch habe ihn so gelassen.
Zusammenfassung:
In /etc/apache2/apache2.conf sollten folgende Einstellungen sein:
KeepAlive On
KeepAliveTimeout 15
MaxRequestsPerChild 20000
Nach den gemachten Änderungen kann man den Apache mit apache2ctl restart restarten.
Noch ein kleiner Hinweis zur DOSSiteCount.
Das ist ein Wert, der empirisch auf seiner eigenen Seite ermittelt
werden sollte, denn wer zum Beispiel in seinem Blog eine Ajax Live
Search Funktion implementiert hat, dem könnte es bei menschlichen
Besuchern durchaus passieren, das die Benutzer einen 403 Fehler kommen,
obwohl sie ja keine Referrer Spam Automaten sind. Vor allem wenn die
Besucher eine schnelle und vor allem kurze Anbindung haben. Wer also auf
meiner Seite davon betroffen ist, sei es auch nur sproradisch, bitte
melden, ich werde den Wert dann erhöhen. Meine Tests haben allerdings ergeben, das ich mit 50 auf der sicheren Seite bin. Mehr als 25 habe ich nicht in einer Sekunde festellen können
Erfolgskontrolle: (alias ltr=ls -ltr)
~var/log/apache2/evasive]# ltr
insgesamt 56K
-rw-r--r-- 1 www-data www-data 4 16. Dez 18:35 dos-84.132.23.200
-rw-r--r-- 1 www-data www-data 6 16. Dez 18:37 dos-91.40.41.216
-rw-r--r-- 1 www-data www-data 5 16. Dez 18:42 dos-77.21.23.66
-rw-r--r-- 1 www-data www-data 5 16. Dez 18:52 dos-77.185.40.188
-rw-r--r-- 1 www-data www-data 6 16. Dez 19:17 dos-77.10.150.190
-rw-r--r-- 1 www-data www-data 6 16. Dez 19:28 dos-95.89.50.13
-rw-r--r-- 1 www-data www-data 6 16. Dez 19:42 dos-194.246.122.11
-rw-r--r-- 1 www-data www-data 6 16. Dez 20:14 dos-91.186.46.168
-rw-r--r-- 1 www-data www-data 6 16. Dez 20:20 dos-31.17.63.12
-rw-r--r-- 1 www-data www-data 6 16. Dez 20:39 dos-79.235.241.62
-rw-r--r-- 1 www-data www-data 5 16. Dez 20:39 dos-188.100.5.129
-rw-r--r-- 1 www-data www-data 5 16. Dez 20:51 dos-87.158.41.156
-rw-r--r-- 1 www-data www-data 6 16. Dez 21:28 dos-93.223.51.108
-rw-r--r-- 1 www-data www-data 6 16. Dez 21:47 dos-77.10.0.219
Ich habe mir noch eine andere Art der Erfolgskontrolle überlegt. Eigentlich müßte die Anzahl der 403 Fehler seit enablen von mod evasive dratisch angestiegen sein. Mal sehen.
# grep '12/Dec/' other_vhosts_access.log|cut -d' ' -f10|grep 403|wc -l
18
# grep '13/Dec/' other_vhosts_access.log|cut -d' ' -f10|grep 403|wc -l
30
# grep '14/Dec/' other_vhosts_access.log|cut -d' ' -f10|grep 403|wc -l
12
# grep '15/Dec/' other_vhosts_access.log|cut -d' ' -f10|grep 403|wc -l
24
#grep '17/Dec/' other_vhosts_access.log|cut -d' ' -f10|grep 403|wc -l
1152
Whow! und der Tag ist ja erst halb rum
(16:50)
Am nächsten Tag fanden sich in meinem email Postfach einige Spam mails. Eigentlich war es in der letzten Zeit doch ziemlich ruhig. Ein Blick auf Munin verriet mir, das postgrey offenbar seinen Dienst quittiert hatte. Eine kurze Recherche führte mich zu einem fehlenden Eintrag in postfix/main.cf. Was das fehlte, habe ich schon mal beschrieben. Nach rücksichern von main.cf vom Backupserver lief postgrey sofort wieder. Auf den Screenshots von munin kann man das schön erkennen.
geht nur über einen Windows PC mit spezieller Software, die natürlich installiert werden muß. Ich habe mich exakt an die Anleitung gehalten, um das Teil nicht gleich zu bricken, es kam auch der erlösende Popup mit "Complete". Doch danach reagierte der Reader auf gar nichts mehr. 
Die letzten Kommentare