Puncte:0

Backtesting jurnalelor istorice în fail2ban

drapel tk

Înființat Rulez apache pe un server ubuntu. Am creat o regulă fail2ban care interzice un ip atunci când solicită prea multe pagini prea repede.

# Regula Fail2ban
failregex = ^.*?(:80|:443) <HOST> - .* „(GET|POST|HEAD).*$
ignoreregex =.*(.ico|.jpg|.png|.gif|.js|.css|.woff|.mp4)

timp de găsire = 30
maxretry = 10

Poartă:
Aș dori să rulez un vechi jurnal apache împotriva acestei noi reguli fail2ban, astfel încât să pot vedea dacă ar fi interzis orice solicitare legitimă.

Încercarea #1 M-am gândit că aș putea folosi fail2ban-regex pentru a obține o listă de utilizatori potențial interziși, dar nu are această funcționalitate.

Încercarea #2 M-am gândit că repetarea jurnalelor istorice în jurnalul pe care fail2ban îl urmărește în prezent le-ar face să fie analizate. După ce am remediat o mică blocare în care liniile de jurnal care aveau date vechi au fost ignorate (remediat prin adăugarea unui an la ele), fail2ban a început să le analizeze și să interzică IP-urile de pe acesta. Cu toate acestea, a trebuit doar să mă uit la primul IP interzis pentru a vedea că era greșit. IP-ul în cauză făcuse doar 10 solicitări în total și nu erau nicăieri aproape una de alta în timp. Pot doar să presupun că fail2ban nu folosește marcajul de timp al liniei de jurnal pentru a determina validitatea, ceea ce face ca această metodă de testare să fie greșită.

# exemplu de ecou
zcat other_vhosts_access.log.8.gz | sed -n 's/\/2022:/\/2032:/p' >> /var/log/apache2/fail2ban_test.log

Concluzie Cu ambele încercări anterioare eșuând, nu mă pot gândi la o modalitate sănătoasă de a aborda această problemă. Imi poate recomanda cineva o modalitate de a realiza ceea ce caut? Sau oferă o perspectivă despre motivul pentru care a doua mea soluție nu funcționează.

Puncte:0
drapel il

Încercarea #1

văzut direct, nu a fost într-adevăr, dar...

Deși cele mai noi versiuni ale fail2ban-regex acceptă parametrii de ieșire, așa că ați putea face ceva de genul acesta:

fail2ban-client set "$jail" banip $(
   fail2ban-regex -o 'ip' /var/log/path/some.log some-filter | sortare --unic | tr '\n' ' '
)

ar fi potrivit doar dacă ați găsi IP-uri care au eșecuri indiferent de număr/timp. În cazul dvs., cel puțin ar fi lipsit de sens fără o preprocesare suplimentară.

Încercarea nr. 2 m-am gândit că a face ecoul jurnalelor istorice în jurnalul pe care fail2ban îl urmărește în prezent le-ar face să fie analizate.

Nu ar funcționa, deoarece fail2ban nu ar lua în considerare corect ora mesajului: fie ar fi prea veche (dacă ați înregistrat înregistrarea nemodificată), fie ar fi incorectă (dacă este înregistrată acum ca moment de eșec, deoarece trebuie să luați în considerare maxretry și găsește timp privind utilizarea reală). Rețineți să menționați că fail2ban ar căuta acum - găsiți ora de la început (pentru că alte mesaje nu sunt interesante pentru el, deoarece sunt prea învechite), vezi https://github.com/fail2ban/fail2ban/issues/2909#issuecomment-758036512.

Oricum, în acest moment, este greu posibil cu instrumentele stock fail2bans scoase din cutie (cel puțin dacă această facilitate de „rescanare” de la RFE de mai sus este implementată și eliberată).

Dar din moment ce fail2ban (precum și fail2ban-regex) este un modul în python, ar fi posibil cu un filtru de la python scrierea interdicțiilor într-un jurnal sau trimiterea lor direct la instanța principală fail2ban, vezi https://github.com/fail2ban/fail2ban/issues/2909#issuecomment-1039267423 pentru un astfel de exemplu de script.

De asemenea, rețineți că filtrul dvs. este extrem de vulnerabil și lent, mai bine rescrieți-l cât mai precis posibil, cumva ca aici:

failregex = ^"<ADDR>" \S+ \S+ [^"]*"[A-Z]+ /(?:\S+/)*[^\.]*(?:\.(?!ico|jpg|png |gif|js|css|woff|mp4)\w+)? [^"]+"

Și nu în ultimul rând, de ce ai nevoie de asta? Dacă închisoarea cu un astfel de filtru este activă și astfel de crawler-uri revin, vor fi interzise de îndată ce fac maxretry eşecuri în timpul găsește timp, configurat pentru închisoare. Interzicerea preventivă nu este cu adevărat necesară și ar deranja subsistemul dvs. net-filter cu o mulțime de IP-uri (probabil că nu vor mai reveni niciodată).

drapel tk
Mulțumesc, Sebres. Nu aș fi putut cere un răspuns mai complet. Mă voi uita la acel script python. Îmbunătățirile tale regex sunt, de asemenea, foarte apreciate. În ceea ce privește motivele mele, nu încerc să fac interdicție preventivă, ci încerc să identific fals-pozitive. Prin reluarea jurnalelor vechi, sper să găsesc situații în care un utilizator a fost interzis pentru utilizare legitimă. Aș modifica apoi failregex-ul pentru a le accepta. Rularea unui backtest ar oferi rezultate mai rapide și mai precise decât testarea manuală.

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.