Puncte:0

Mod_Security previne forța brută pentru Joomla

drapel vn

Încerc să găsesc/creez o regulă Mod_Security pentru a detecta și bloca mai multe erori de conectare pe cea mai recentă versiune de Joomla. Am găsit un răspuns din martie 2015 aici: https://serverfault.com/a/646608/960638 dar în propriile mele teste nu detectează erori de conectare. Chiar și cu înregistrarea activată, nu detectează nimic. Bănuiesc că codul este depășit.

Am găsit o altă regulă ModSec publicată de IT Octopus la https://www.itoctopus.com/a-modsecurity-rule-to-block-brute-force-attacks-on-a-joomla-website Codul este mai jos. L-am testat pe un server, dar am găsit că este prea sensibil și m-a blocat după ce m-am conectat + deconectat de la Joomla (cu corect acreditări).

<Location /administrator>
    SecDefaultAction phase:2,deny,status:403,log,auditlog
    SecRule IP:bf_counter "@eq 5" "id:1000002,phase:2,log,block,expirevar:IP.bf_counter=3600,msg:'IP address blocked because of a suspected brute force attack on the Joomla website'"
    SecRule ARGS:option "@streq com_login" "id:1000000,phase:2,chain,t:none,log,pass,msg:'Multiple Joomla authentication failures from IP address', setvar:IP.bf_counter=+1"
</Location>

Apoi, am găsit o regulă ModSecurity la http://artefact.io/brute-force-protection-modsecurity/ și este cel pe care îl folosesc pe serverele mele de mai multe luni. A funcționat foarte bine până ieri când am găsit o eroare. Un client are 10 site-uri Joomla și a constatat că atunci când s-a conectat la ele (cu acreditările corecte) a dus la restricționarea IP-ului lor. Am reușit să reproduc asta în timpul propriilor mele teste. Prin urmare, codul de mai jos este cel mai bun cod pe care l-am găsit până acum, dar liniile com_login / login nu par să facă distincția între eșecurile de conectare și autentificarea reușită. Funcționează pentru a preveni forța brută generală, dar nu funcționează atunci când un client are multe site-uri Joomla și accesează în mod legitim mai multe instalări simultan. Acesta este codul:

# Forța brută Joomla
SecAction „phase:1,pass,setvar:TX.max_requests=6,setvar:TX.requests_ttl=180,setvar:TX.block_ttl=900,initcol:ip=%{REMOTE_ADDR},nolog,id:5001000”
<LocationMatch "/administrator/index.php">
SecAction „phase:2,chain,nolog,id:5001022”
SecRule REQUEST_METHOD „^POST$” „lanț”
SecRule ARGS_POST_NAMES „^nume utilizator$” „lanț”
SecRule ARGS_POST_NAMES „^passwd$” „lanț”
SecRule ARGS_POST:opțiunea „^com_login$” „lanț”
SecRule ARGS_POST:sarcina „^login$” „lanț”
SecAction „setvar:ip.request_count=+1,expirevar:ip.request_count=%{TX.requests_ttl}”

SecRule IP:request_count "@ge %{TX.max_requests}" "phase:2,drop,setvar:ip.blocked=1,expirevar:ip.blocked=%{TX.block_ttl},log,msg:'Joomla brute force . Blocare pentru %{TX.block_ttl} secunde',id:5001023"

</LocationMatch>

În cele din urmă, am citit câteva postări care sugerau „antetul P3P este returnat după o conectare cu succes” și acest lucru ar putea fi folosit într-o regulă ModSecurity. A fost sugerat de @godzillante aici: https://serverfault.com/a/646608/960638

Utilizează ModSecurity faza 5 (analizarea fișierelor jurnal), așa că nu sunt sigur dacă acesta este un dezavantaj. Și mai important, în testarea mea nu am reușit să-l fac să funcționeze. Chiar și cu înregistrarea în jurnal activată, nu a detectat conectări eșuate și nu a restricționat accesul. Iată codul:

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:'adresa IP blocată timp de 5 minute, mai mult de 5 încercări de conectare în 3 minute."
    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 5” „t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0”
</locationmatch>

Obiectivul meu aici este să îmbunătățesc codul „Joomla Brute Force” (mai sus), deoarece blochează inundațiile cu forța brută, dar, din păcate, blochează și utilizatorii atunci când se conectează în mod legitim la Joomla. Am nevoie de un cod care poate face diferența dintre un eșec de conectare și o conectare reușită la Joomla. Lucrez la asta de ceva timp, așa că mă adresez comunității de aici. Mulțumesc anticipat!

djdomi avatar
drapel za
la fel ca un lucru de bază - adăugați o autentificare de bază pentru /administrator și restricționați accesul ip, adică la vpn :)
Peter avatar
drapel vn
Acesta este un sfat bun pentru proprietarul unui site, dar vă întreb din punctul de vedere al unui administrator de server. Am nevoie de o soluție robustă pentru a lucra pe multe servere și multe site-uri web. Mulțumesc

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.