Ralf Zimmermann SIEGNETZ.IT GmbH

Persistente Daten ausgeben

Bei dem Erstellen und Testen von Modsecurity Regeln stolpert man öfters über Counter oder gesetzte Variablen. Mit den jwall-tools kann man sich sehr einfach diese Einträge anzeigen lassen. Der Befehl lautet jwall collections <database>.

Beispiel des Befehls jwall collections

root@lab:~# jwall collections /modsecurity/data/
Reading collections from /opt/modsecurity/data
Collection ip, last read @ Thu Nov 20 14:19:27 CET 2014 
   Created at Thu Nov 20 13:43:47 CET 2014
   ip[2a01:360:106::2_56a546b75cde883c21c296fc4c11523f6017c447].TIMEOUT = 3600
   ip[2a01:360:106::2_56a546b75cde883c21c296fc4c11523f6017c447].dos_counter = 1
This collection expires in 24 min 19 sec

Collection ip, last read @ Thu Nov 20 14:19:27 CET 2014 
   Created at Thu Nov 20 13:44:29 CET 2014
   ip[217.7.183.205_f299ccc9870697169883c2038cc870c47d5cdf62].TIMEOUT = 3600
   ip[217.7.183.205_f299ccc9870697169883c2038cc870c47d5cdf62].dos_counter = 7
This collection expires in 55 min 9 sec

Collection ip, last read @ Thu Nov 20 14:19:27 CET 2014 
   Created at Thu Nov 20 13:43:38 CET 2014
   ip[217.7.183.205_198132322d911d52b85c780e0eb0443fcfc2b3b5].TIMEOUT = 3600
   ip[217.7.183.205_198132322d911d52b85c780e0eb0443fcfc2b3b5].dos_counter = 96
   ip[217.7.183.205_198132322d911d52b85c780e0eb0443fcfc2b3b5].brute_force_counter = 7
   ip[217.7.183.205_198132322d911d52b85c780e0eb0443fcfc2b3b5].hp_request_count = 1  (expires in 32 sec)  last update was 7 sec ago 
   ip[217.7.183.205_198132322d911d52b85c780e0eb0443fcfc2b3b5].malicious_client = 1  (expires in 53 sec)  last update was 7 sec ago 
This collection expires in 59 min 53 sec

Vorbereitungen für Honeytraps

Um auffällige Clients zu blockieren kann man einfach eine Variable auswerten. Ist diese gesetzt und hat hier in diesem Beispiel den Wert 1, dann wird die IP Adresse des Clients geblockt. Hier wird die Variable &IP:MALICIOUS_CLIENT ausgewertet.

SecRule &IP:MALICIOUS_CLIENT "@eq 1" "id:'9999999',phase:2,t:none,log,block,msg:'HoneyTrap Alert: Known Malicious.'"

Beispiel Regel zum Blockieren von häufig attackierten Benutzernamen

Die folgende Regel sorgt dafür, dass Clients die die URL /admin/login.php aufrufen und sich z.B. mit dem Benutzernamen admin anmelden gesperrt werden. Hier wird die Variable user ausgewertet, die z.B. in einem Login Formular gesetzt wird. Verwendet ein Client einen der aufgeführten Benutzernamen, dann wird der Client für 60 Sekunden gesperrt. Lässt man den Parameter expirevar:ip.malicious_client=60 weg, dann bleibt der Client bzw. die IP Adresse gesperrt.

SecRule REQUEST_FILENAME "@streq /index.php" "chain,phase:4,id:'999321',t:none,block,msg:'Default/Common Username Submitted for Authentication',logdata:'%{args.user}'"
        SecRule REQUEST_METHOD "@streq POST" "chain"
                SecRule ARGS:user "@pm admin administrator root system guest operator super test qa backup" "setvar:ip.malicious_client=1,expirevar:ip.malicious_client=60"

Vorbereitungen für Honeytraps

Um auffällige Clients zu blockieren kann man einfach eine Variable auswerten. Ist diese gesetzt und hat hier in diesem Beispiel den Wert 1, dann wird die IP Adresse des Clients geblockt. Hier wird die Variable &IP:MALICIOUS_CLIENT ausgewertet.

SecRule &IP:MALICIOUS_CLIENT "@eq 1" "id:'9999999',phase:2,t:none,log,block,msg:'HoneyTrap Alert: Known Malicious.'"

Beispiel Regel für forbidden files Honeytrap

Diese Regel ist sehr einfach. Wird die URL /wp-admin/admin-ajax.php aufgerufen, liefert der Webserver einen HTTP Error Code 403 zurück und der Client wird für 60 Sekunden blockiert.

SecRule REQUEST_FILENAME "^/wp-admin/admin-ajax.php" "id:'9999031',phase:2,t:none,log,deny,status:403,msg:'HoneyTrap Alert: Forbidden not existing file',logdata:'%{matched_var}',setvar:ip.malicious_client=1,expirevar:ip.malicious_client=60"

Vorbereitungen für Honeytraps

Um auffällige Clients zu blockieren kann man einfach eine Variable auswerten. Ist diese gesetzt und hat hier in diesem Beispiel den Wert 1, dann wird die IP Adresse des Clients geblockt. Hier wird die Variable &IP:MALICIOUS_CLIENT ausgewertet.

SecRule &IP:MALICIOUS_CLIENT "@eq 1" "id:'9999999',phase:2,t:none,log,block,msg:'HoneyTrap Alert: Known Malicious.'"

Beispiel Regel für robots.txt Honeytrap

Um Bots zu erkennen, die sich nicht an die robots.txt Angaben halten kann man einfach dynamisch einen Eintrag der robots.txt hinzufügen. In diesem Beispiel ist dies z.B. der Eintrag Disallow: /dbbackup.1414621388/ #TEMP DB BACKUP

SecRule REQUEST_FILENAME "@streq /robots.txt" "id:;999001',phase:4,t:none,nolog,pass,append:'Disallow: /dbbackup.%{time_epoch}/ #TEMP DB BACKUP'"

Ruft nun ein Bot trotzdem den dynamisch hinzugefügten Eintrag auf, kann man z.B. eine Basic Auth Authentifizierung einfordern. Dies geschieht durch das Setzen von setenv:basic_auth=1. Führt ein Bot oder ein Benutzer nun noch eine Authentifizierung aus, wäre es ja interessant zu wissen mit welchen Daten er sich authentifiziert. Dies wird hier mit der Regel 999004 erreicht. Die Regel sorgt dafür, das die Anmeldedaten gelogged werden und das der Client für 60 Sekunden blockiert wird.

SecRule REQUEST_FILENAME "^/dbbackup.\d{10}" "id:'999003',phase:2,t:none,log,deny,status:401,msg:'HoneyTrap Alert: Disallowed robots.txt Entry Accessed',logdata:'%{matched_var}',setenv:basic_auth=1"
SecRule REQUEST_FILENAME "^/dbbackup.\d{10}" "chain,id:'999004',phase:1,t:none,log,msg:'HoneyTrap Alert: Authentication Attempt to Fake Resource',logdata:'Credentials used: %{matched_var}'"
        SecRule REQUEST_HEADERS:Authorization "^Basic (.*)" "chain,capture"
                SecRule TX:1 ".*" "t:base64Decode,setvar:ip.malicious_client=1,expirevar:ip.malicious_client=60"

Beispiel Regel für Geolookup

Eine RBL (real-time block list) ist mit einer Regel zu aktivieren. Ist der Client gelistet, wird der HTTP Error Code 403 zurückgegeben.

SecRule REMOTE_ADDR "@rbl sbl-xbl.spamhaus.org" "phase:1,deny,status:403,log,msg:'Client denied by local RBL!'"

Hier eine erweiterte Regel. Ist der Client in der RBL gelistet, wird Verbindung blockiert und mittels Geolookup das Herkunftsland gelogged.

SecRule REMOTE_ADDR "@rbl sbl-xbl.spamhaus.org" "chain,drop,msg:'Client Denied By RBL Check',logdata:'%{TX.0}'"
SecRule REMOTE_ADDR "@geoLookup" "chain"
SecRule GEO:COUNTRY_CODE "^(.*)$" "t:none,capture"

Hier eine komplexere Regel.

SecRule REMOTE_ADDR "@rbl sbl-xbl.spamhaus.org" "phase:1,id:171,t:none,pass,nolog,auditlog, \
msg:'RBL Match for SPAM Source',tag:'AUTOMATION/MALICIOUS',severity:'2',setvar:'tx.msg=%{rule.msg}', \
setvar:tx.automation_score=+%{tx.warning_anomaly_score},setvar:tx.anomaly_score=+%{tx.warning_anomaly_score}, \
setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched_var},setvar:ip.spammer=1, \
expirevar:ip.spammer=86400,setvar:ip.previous_rbl_check=1,expirevar:ip.previous_rbl_check=86400,skipAfter:END_RBL_CHECK"

Weiteres ist in der Modsecurity Referenz zu finden.

Beispiel Regel für Geolookup

Um Geolookups durchzuführen ist mit dem Parameter SecGeoLookupDB eine Datenbank zu definieren. In diesem Beispiel wird die frei verfügbare DB GeoLiteCity.dat verwendet.

SecGeoLookupDB /.../GeoLiteCity.dat
SecRule REMOTE_ADDR "@geoLookup" "id:'1000001',phase:1,t:none,pass,nolog"

Im folgenden Beispiel wird nur der Zugriff aus Deutschland und den USA gestattet.

SecRule GEO:COUNTRY_CODE "!@pm DE US" "phase:'1',id:'999017',t:none,log,block,msg:'Client IP not from allowed Country',setvar:ip.malicious_client=1,expirevar:ip.malicious_client=60"

Das folgende Beispiel erlaubt alle IP Adressen die nicht aus den aufgeführten Ländern stammen.

SecRule GEO:COUNTRY_CODE "@pm CN UA ID YU LT EG RO BG TR RU" "phase:'1',id:'999018',t:none,log,block,msg:'Client not from allowed Country',setvar:ip.malicious_client=1,expirevar:ip.malicious_client=60"

Wer sich näher mit Geolookup beschäftigen möchte kann ausführliche Beispiele in der Modsecurity Referenz recherchieren.