Achtung!
Dieser Artikel ist uralt und die Informationen darinnen ziemlich sicher nicht mehr zutreffend!

Nachdem ich in den letzten Monaten so viele tolle, neue sicherheits- und anti-spam features eingebaut habe, fehlte mir eigentlich nur noch eines: Wenn jemand schon mehrfach beim versenden von website-spam "ertappt" wurde, soll sein Zugriff auf den Server doch bitte gleich ganz gesperrt werden.
Dafür gibt es schon die eine oder andere Lösung, doch keine gefiel mir so recht, also habe ich mich selbst mal hingesetzt und mein bisher laengstes shell-script geschrieben: sw2ipt.
"sw" steht hierbei für "ScallyWhack" einem praktischen script-set rund um mod_security, welches von einem Freund von mir entwickelt wird: ScallyWhack.

Von ScallyWhack benötigen wir das script "spamstats.sh", welches per Pipe zur Verarbeitung der mod_security logs in der apache-config angegeben wird. Klingt kompliziert - ist es aber gar nicht.. :)
Dieses Script generiert anhand der mod_security-logs zum Einen Statistiken über das Spam-Aufkommen und zum Anderen sogenannte "schedule-files", die Aufgaben an dritte Programme, wie sw2ipt eines ist, weiterleiten.
Vorteil dieser Server/Client-Technologie ist zum Einen die Geschwindigkeit (die "Rechenintensiven" Aufgaben werden von eigenen Prozessen ausgeführt und halten somit den WebServer nicht von seiner Arbeit ab) und zum Anderen die Sicherheit: Während das spamstats-script naturgemäß noch mit dem Benutzer des WebServers läuft, kann sw2ipt mit einem beliebigen User ausgeführt werden, der eben auch iptables-regeln absetzen kann. So muss man dies nicht dem webserver-user erlauben - wobei ich immer ein etwas mulmiges Gefühl hätte...

Benötigt wird zum Einen das spamstats-script von otaku42 und dessen config-file:

und natürlich das sw2ipt-script:

die beiden scripte packen wir am besten nach "/usr/local/bin/", wo sie hingehören und das spamstats.conf kommt nach "/etc/"

Zunächst passen wir die spamstats-Konfiguration unseren Wünschen an. In den meisten Fällen sind die default-werte vollkommen okay, nur die Pfade müssen noch erstellt werden, sofern sie noch nicht existieren.

LOGDIR="/var/log/apache2/scallywhack-audit"
Wo spamstats.sh die index-log-files sichern soll.

LOGNAME="scallywhack-~date~.log"
Wie die logfiles benannt werden sollen (wobei "~date~" durch das aktuelle Datum ersetzt wird.)

REPORTDIR="/var/log/apache2/scallywhack-audit"
Wo die mod_security-logfiles gefunden werden können

TMPDIR="/var/tmp/scallywhack"
Das Verzeichniss, in dem scallywhack seine schedule- und statistik-files ablegen soll.


Nun passen wir die mod_security-Konfiguration an. Folgende Parameter müssen ergänzt, bzw. korrigiert werden:

SecAuditLogType Concurrent
Steht evtl. auf "Serial" - muss unbedingt auf "Concurrent" umgestellt werden.

SecAuditLog "|/usr/local/bin/spamstats.sh /etc/spamstats.conf"
Hier geben wir an, dass das Log nicht in eine Datei, sondern an das spamstats-script übergeben werden sollen. Das erste Kommando nach der pipe ("|") ist, wie immer, das auszuführende Programm - also spamstats.sh mit vollem Pfad. Der Parameter gibt an, wo das script nach seiner config suchen soll.

SecAuditLogStorageDir /var/log/apache2/scallywhack-audit
Wohin das Log gesichert werden soll - evtl. überflüssig..


Ist das alles erledigt, starten wir apache neu und beobachten den Inhalt des Verzeichnisses, welches wir unter "LOGDIR" angegeben haben. In unserem Beispiel wäre das "/var/log/apache2/scallywhack-audit/".
Hier sollten mit der Zeit immer mehr Dateien erscheinen. Ist dies der Fall, werfen wir noch einen Blick in das TMPDIR (/var/tmp/scallywhack/) - erscheinen hier bei geloggten spam-attacken Dateien mit dem Namen "ipbl-*" läuft spamstats.sh bereits einwandfrei und wir können sw2ipt.sh anhängen.

Auch dieses Script will zunächst konfiguriert werden:

THRESTIME=600
Funktioniert im Zusammenhang mit der nächsten Variable. Wenn ein Spammer $THRESCOUNT male innerhalb von $THRESTIME ertappt wurde, soll er geblockt werden. Angaben in Sekunden.

THRESCOUNT=3
Funktioniert im Zusammenhang mit der vorherigen Variable. Wenn ein Spammer $THRESCOUNT male innerhalb von $THRESTIME ertappt wurde, soll er geblockt werden. Angaben in Sekunden.

USERULES="95901 95902 95903"
Auf welche Regeln geprüft werden soll. Regeln, die hier nicht angegeben werden, werden zwar immernoch durch mod_security geblockt, aber nicht mehr an iptables weitergegeben..

IPLOG="/var/lib/rbldns/lists/websites"
Eine Liste der aktuell geblockten IPs zur weiteren Verwendung in einer DNSBL..

SW2IPTTMP="/var/tmp/sw2ipt"
Wo die temporären Dateien des Scriptes abgelegt werden können.

SWTMP="/var/tmp/scallywhack"
Wo die schedule-files von spamstats.sh gesucht werden sollen.

LOCKTIME=3600
Wie lange eine IP-Sperre bestehen bleiben soll.

SLEEPTIME="30s"
Wie viel Zeit zwischen zwei Checks vergehen soll.

BLOCKCOMMAND='iptables -A sw2ipt -s %s -j DROP'
Das Kommando zum Blocken (nicht ändern! es sei denn, Du weisst genau, was Du tust...!)

UNBLOCKCOMMAND='iptables -D sw2ipt -s %s -j DROP'
Das Kommando zum Blocken (nicht ändern! es sei denn, Du weisst genau, was Du tust...!)

LOGFILE='/var/log/sw2ipt.log'
Das Logfile von sw2ipt.sh

QUIET=0
Steht diese Variable auf "1" gibt das script status-meldungen auf STDOUT aus. Steht sie auf "1" gibt es seine Meldungen nur in's LogFile aus..


Ist alles fertig konfiguriert, können wir einen ersten test wagen und das script ausführen. Eigentlich checkt das script, ob alles so ist, wie es das erwartet und passt auch manches seinen Bedürfnissen an..
Sollte nach dem Ausführen einfach gar nichts passieren, ist das ein gutes Zeichen..
Wir können ja mal einen test-spam-kommentar absetzen und gucken, ob dieser im sw2ipt.log auftaucht. Ist dies der Fall, sollten wir aber auch ganz schnell wieder aufhoeren - mit der Beispiel-Konfiguration würden wir nach 2 weiteren Versuchen für eine Stunde von unserem eigenen Server ausgesperrt..

Wenn alles funktioniert wie gewünscht, können wir den Parameter "QUIET" auf 1 setzen und das Script mit einem angehängten "&" in den Hintergrund verfrachten: "/usr/local/bin/sw2ipt.sh &"

Gibt es doch noch Probleme, beschreibt diese bitte hier - in den nächsten Tagen und Wochen werde ich auch noch eine Troubleshooting-Sektion anfügen und den Artikel etwas übersichtlicher gestallten. Für heute muss das aber reichen. ;)

Gravatar
Thomas
hab versucht dir die ganze Fehlermeldung zu posten, aber anscheinend werden eingefügte inhalte auf dieser Seite als Spam erkannt und geblockt...
Ich habe dir ebenfalls ein mail an abuse at ambience-design dot com geschickt...

0
Gravatar
Thomas
hi,
habs versucht zu installieren bekomme jedoch beim apache-neu starten Modsecurity "access denied"...
syntax error on line 176 /pfad/modsecurity.conf
Modsecurity failed to open the audit lof pipe...

0
Gravatar
stimpy
Naja - das sind halt _bei mir_ die Regeln, die greifen sollen - welche regeln das bei dir sind, kommt drauf an, wie Du's bei Dir konfiguriert hast.. ;-)
Musst einfach mal die mod_security config durchgucken - bei den default-regeln steht ja bei, was sie machen und anhand dessen kannst Du entscheiden, ob die auch zu dem kompletten Block fuehren sollen..
Bei mir wird halt nur richtig geblockt, wer links in Kommentaren oder Shoutboxen zu hinterlassen versucht. Das sind schon ne ganze Menge.. ;-)

0
Gravatar
Thom
Hi!,

sind das die einzigen, die du angegeben hast??: USERULES="95901 95902 95903", oder gibt's noch andere sinnvolle??

Thom

0

5000 Characters left