
Ich betreibe mehrere Hosting-Server und habe in letzter Zeit viele Brute-Force-Angriffe auf Joomla-basierte Websites erlebt. Angreifer scheinen Brute-Force-Angriffe gegen administrator/index.php
Seiten zu versuchen.
Normalerweise sperre ich IPs, wenn sie versuchen, Wordpress-Anmeldungen mit Brute-Force-Methoden zu erzwingen, und verwende dazu den folgenden Regelsatz:
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134
<Locationmatch "/wp-login.php">
SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"
SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
</Locationmatch>
Ich kann jedoch keine ähnliche Regel für Joomla! finden, da der Antwortstatus sowohl bei gültigem als auch bei ungültigem Passwort „303, siehe andere“ lautet.
Irgendeine Hilfe? Danke im Voraus!
Antwort1
Hier ist meine Antwort.
Beim Überprüfen der Rückgabeheader ist mir aufgefallen, dass das Joomla!-Backend einige HTTP-Header zurückgibt, wenn die Anmeldung korrekt ist, und sie nicht zurückgibt, wenn die Anmeldung ungültig ist.
zB dieP3PDer Header wird nach einer erfolgreichen Anmeldung zurückgegeben, daher suche ich nur nach seiner Länge > 0
:
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000144
<Locationmatch "/administrator/index.php">
SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000145,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
SecRule RESPONSE_HEADERS:P3P "streq 0" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000146"
SecRule RESPONSE_HEADERS:P3P "!streq 0" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000147"
SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
</locationmatch>
Antwort2
Das Problem mit der akzeptierten Antwort besteht darin, dass sie nicht berücksichtigt, wann eine Aktualisierung der Anmeldeseite erfolgt. Wenn die Person also die Anmeldeseite aktualisiert, wird entweder 1) der Zähler zurückgesetzt (was schlecht ist) oder 2) die Aktualisierung als fehlgeschlagene Anmeldung gezählt (was ebenfalls schlecht ist).
Wir haben gerade eine Regel für den Umgang mit Brute-Force-Angriffen auf Joomla entwickelt, die auf dem Post-Wert "com_login" basiert. Wenn der Wert im Post-Wert enthalten ist, bedeutet dies, dass die Anmeldung fehlgeschlagen ist, wenn nicht, war die Anmeldung erfolgreich. Die Regel finden Sie unterHier.