Puncte:1

Fail2ban regex funcționează, dar nu este interzis. Avertisment DNS în schimb

drapel in

Am avut următoarea problemă (deja rezolvată) cu fail2ban și am plasat-o greșit pe stack overflow, așa că o pun aici acum.

Așa că citesc probleme de câteva zile și se pare că nu găsesc nicăieri o soluție. Fac câteva teste pe un laborator de server web, am configurat două VM-uri (Ubuntu 20.04) server și client. Pe server am o aplicație de conectare PHP configurată pentru a-mi oferi acest jurnal ori de câte ori cineva nu se conectează.

root@local:/var/log/apache2# tail -f error.log
[Veni, 18 iunie 10:13:37.657446 2021] [php7:notice] [pid 2465] [client 192.168.1.11:44750] [eroare] autentificare eșuată, referitor: http://192.168.1.10/index.php
[Veni, 18 iunie 10:13:41.434454 2021] [php7:notice] [pid 2465] [client 192.168.1.11:44750] [eroare] autentificare eșuată, referitor: http://192.168.1.10/index.php
[Veni, 18 iunie 10:13:46.236750 2021] [php7:notice] [pid 2465] [client 192.168.1.11:44750] [eroare] autentificare eșuată, referitor: http://192.168.1.10/index.php

Și Fail2Ban v0.10.2 configurat să-l prindă. /etc/fail2ban/jail.local:

[interdicție de conectare]
activat = adevărat
port = http,https
filtru = autentificare-ban
logpath = /var/log/apache2/error.log
maxretry = 3
timp de găsire = 180
bantime = 60

/etc/fail2ban/filter.d/login-ban.conf:

[Definiție]
failregex = ^\[.*\]\s\[.*]\s\[.*].*\[client.*<HOST>\].*\[eroare\].*
ignoreregex =

Acum, regex funcționează perfect, dacă verific cu fail2ban-regex:

fail2ban-regex /var/log/apache2/error.log /etc/fail2ban/filter.d/login-ban.conf --print-all-matched

eu iau

|- Liniile potrivite:
| [Ven 18 iunie 10:36:07.312503 2021] [php7:notice] [pid 780] [client 192.168.1.11:44754] [eroare] autentificare eșuată, referitor: http://192.168.1.10/index.php
| [Veni, 18 iunie 10:36:14.417955 2021] [php7:notice] [pid 784] [client 192.168.1.11:44756] [eroare] autentificare eșuată, referitor: http://192.168.1.10/index.php

Dar fail2ban nu interzice IP-ul și fail2ban.log îmi trimite un avertisment DNS:

2021-06-18 10:50:22,083 fail2ban.ipdns [2154]: AVERTISMENT IP determinat folosind Căutare DNS: 8 = {'0.0.0.8'}
2021-06-18 10:50:22,085 fail2ban.filter [2154]: INFO [login-ban] Găsit 0.0.0.8 - 2021-06-18 10:50:22

Am încercat să setez parametrul usedns la „nu” și la „raw”, singurul lucru care s-a realizat a fost să scap de jurnalul de avertizare dns, tot fără interdicție și să nu înregistrez gazda care încerca să se autentifice.

Sper că acestea sunt suficiente informații și că aceasta va ajuta pe cineva acolo la fel de mult ca mine.

Puncte:2
drapel in

SOLUŢIE

Utilizatorul @sebres mi-a răspuns:

doar opriți-vă pentru a folosi catch-alls (.* etc), e. g. o corectare pentru a-l face să funcționeze ar putea fi

- ... \[client.*<HOST>\] ...
+ ... \[client <HOST>:\d+\] ...

RE .* este lacom, deci se potrivește cu cât mai multe caractere, iar <HOST> poate potrivi orice (nume de gazdă), nu numai adresa, și mai bine folosiți <ADDR>, dacă versiunea fail2ban >= 0.10.

Și întreaga voastră expresie este „vulnerabilă” din cauza mai multor catch-all (deci ancora nu este luată cu adevărat).

*** Așa că am făcut schimbarea pe care mi-a sugerat-o, s-a terminat așa:

^\[.*\[client <ADDR>:\d+\].*\[eroare\].*

acum totul merge cum trebuie. Sper ca ajuta!

djdomi avatar
drapel za
vă rugăm să reamintiți să vă acceptați răspunsul.

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.