Puncte:0

Detectarea botului de către fail2ban

drapel cn

Vreau să știu dacă este posibil să folosesc în fail2ban vreo regulă/script care detectează roboții, nu doar prin maxretry într-o anumită cantitate în secunde, ci prin identificarea unor modele pentru fiecare IP: de exemplu, să presupunem că un IP accesează o pagină la fiecare 10 până la 15 secunde, dar un alt IP o accesează la fiecare 30-45 de secunde.

Am probleme cu utilizatorii care folosesc scripturi pyautogui și nu pot detecta IP-urile din spatele roboților pentru că fiecare are un model diferit.

De asemenea, folosesc Sucuri, care are 0% protecție în acest caz de utilizare. Nu pot trece la alt serviciu de firewall pentru că acesta are doar 6 IP-uri (CloudFlare are peste 20, de exemplu) și am doar 10 reguli de firewall, de asemenea IP-uri maxime, pe lista albă în furnizorul meu de server (mă protejez de atacuri prin IP). , nu doar prin DNS).

Este un alt instrument care poate face asta? Multumesc anticipat pentru ajutor si sugestii!

Cele mai bune salutări!

djdomi avatar
drapel za
setați criteriile de căutare la aproximativ 3 ore la 5 eșuări, IP-ul va fi interzis cu siguranță
Puncte:0
drapel cn

fail2ban este bun la detectarea modelelor proaste cunoscute care se întâmplă în mod repetat. Mai multe erori de autentificare ssh se potrivesc cu o expresie regex și sunt interzise.

fail2ban este prost la detectarea modelelor necunoscute și nu are un mecanism evident de declanșare bazat doar pe sincronizare. Semnalarea totul ca eșuat și sortarea lui în acțiuni (pe care ar trebui să le scrieți) pare oribil. Fals pozitive peste tot, cum rămâne cu oamenii care tind să facă clic la fiecare 15 secunde în mod natural. Prost pentru performanță, trimiterea tuturor solicitărilor prin închisori fail2ban. Iar utilizatorii care doresc să arate mai puțin ca un bot pot masca modele de sincronizare inuman de precise. wget --aleatoriu-așteaptă este disponibil într-un instrument de linie de comandă, de exemplu.

Așa că căutarea unui instrument continuă. Va trebui să faceți această selecție, noi nu facem recomandări pentru Server Fault. Posibil un sistem centralizat de logare este adecvat, pentru a analiza și stoca evenimente. Gândiți-vă la întrebările la care ar putea avea nevoie să răspundă, cum ar fi „listați mesajele care conțin unele IP în toată infrastructura noastră”. Destul de instrumente de logare fanteziste se numesc pe sine gestionarea informațiilor de securitate și a evenimentelor (SIEM). Chiar și cei mai chic cu fluxuri de lucru de automatizare au început să se numească orchestrare, automatizare și răspuns de securitate (SOAR). Acestea ar putea fi totuși mult prea multe și poate că doar fișierele de jurnal grep pe o bază ad-hoc, atunci când roboții par a fi rău.


Lista permisă IP de o singură cifră pare mică. Ați găsit deja un serviciu (CloudFlare) care în sine a depășit asta.Listele practice de permise nu vor deveni mai mici, cu spațiu IPv4 mereu fragmentat și adăugând servicii și aplicații.

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.