Îți supraîncarcă traficul de boți serverul? Studiu de caz: Juridice.ro

Când un tehnician de la Juridice.ro a observat o sarcină a serverului care părea prea mare pentru traficul pe care site-ul îl servea de fapt, întrebarea era simplă: de unde vine tot? Răspunsul s-a dovedit a fi sute de mii de cereri neinvitate pe zi — niciuna de la cititori.

Juridice.ro este una dintre cele mai mari și cunoscute resurse online pentru profesioniștii din drept din România, cu aproximativ 550.000 de vizite lunare conform SimilarWeb. Pentru o publicație ca aceasta, fiecare minut de performanță degradată erodează ceva mai greu de reconstruit decât un server: puterea de brand. Cititorii care vin pentru conținut juridic de autoritate se așteaptă ca site-ul pur și simplu să funcționeze.

Acest studiu de caz răspunde la o întrebare cu care se confruntă în cele din urmă orice site în creștere: când sarcina serverului crește, cum știi dacă e succes — sau paraziți?

Simptomul: o sarcină care nu se lega

Juridice era deja client Helios Live. Nu a existat nicio cădere, niciun incident, nicio alarmă — doar un tehnician cu instincte bune care simțea că serverele munceau mai mult decât justifica audiența și ne-a cerut îndrumare.

Ne-am dus la loguri. Ce am găsit s-a împărțit în două infestări separate:

• Sute de mii de încercări de login SSH pe zi — atacuri brute-force, cu IP-uri individuale trăgând de la zeci la mii de încercări fiecare.
• Zeci de mii de cereri web pe zi care scanau specific după exploit-uri — boți care sondau după plugin-uri vulnerabile, panouri de admin expuse și slăbiciuni WordPress cunoscute.

Nimic nu fusese încercat împotriva acestora înainte, dintr-un motiv simplu: nimeni nu știa amploarea. O migrare către Cloudflare era deja în curs — întâi ca CDN de fișiere statice, apoi ca proxy complet — dar fusese planificată pentru a economisi resurse, nu pentru a lupta cu cineva.

Actul unu: potopul SSH

Iată partea care contează înainte să descriem vreo soluție: șansa unei breșe reale era aproape zero. În lucrări anterioare cu Juridice, impuseserăm deja login SSH doar cu cheie pentru toate conturile privilegiate, cu autentificarea prin parolă dezactivată. Singurele conturi care mai permiteau parole aparțineau utilizatorilor site-ului — și niciunul dintre boți nu a ghicit vreodată un singur nume de utilizator valid.

Deci nu era o urgență de securitate. Era o problemă de resurse și zgomot: o armată de boți consumând CPU, conexiuni și spațiu de log non-stop, degeaba.

Prima noastră mișcare a fost cea clasică: fail2ban, banând automat IP-urile după încercări eșuate repetate.

A funcționat — pentru scurt timp. Apoi atacatorii s-au adaptat. Același volum general de încercări continua să sosească, dar răspândit pe mult mai multe adrese IP, fiecare trimițând mai puține cereri ca să rămână sub pragurile fail2ban. Scanerele pur și simplu se remodelaseră în jurul filtrului nostru.

Așa că ne-am uitat de unde veneau acele IP-uri noi. Practic fiecare dintre ele era deja listat pe AbuseIPDB, baza de date publică cu adrese malițioase raportate. Asta ne-a dat al doilea strat: un import zilnic automat al celor mai răi ofensatori de pe AbuseIPDB, blackhole-uiți la nivel de rețea înainte să poată măcar deschide o conexiune.

Rezultatul: de la sute de mii de încercări pe zi la aproximativ 1.000 — o scădere de 99% — cu câteva sute de IP-uri noi încă prinse și banate zilnic de sistemul combinat.

Actul doi: boții web

Logurile web erau de fapt locul unde ne uitaserăm prima dată, pentru că serviciile web sunt de departe partea cea mai solicitantă din infrastructura Juridice — iar scanerele de exploit-uri erau chiar acolo, la vedere.

Prima soluție a fost ieftină și satisfăcătoare: am mutat login-ul de admin WordPress la un URL nou și am îndreptat un filtru fail2ban spre orice mai cerea vechiul URL. Niciun vizitator legitim nu are vreun motiv să ceară o pagină de login de admin — fiecare accesare a vechiului URL era, prin definiție, un bot care se autoidentifica.

Apoi migrarea Cloudflare a introdus o răsturnare. Odată ce domeniul principal a intrat în spatele proxy-ului complet Cloudflare, serverele noastre nu mai primeau deloc cereri din internetul deschis — fiecare conexiune sosea de la IP-urile Cloudflare. Blackholing-ul la nivel de rețea a devenit brusc orb față de cine era vizitatorul real.

Așa că ne-am adaptat din nou: aceeași listă zilnică AbuseIPDB a fost importată în LiteSpeed, serverul web, care vede IP-ul real al vizitatorului transmis în spatele proxy-ului și poate respinge cererea la nivel de aplicație.

Cum blochezi boții răi fără să afectezi traficul bun

Pentru un publisher care trăiește din traficul de căutare, aceasta este întrebarea care contează cel mai mult: cum bombardezi boții fără să lovești Googlebot sau proprii cititori?

În practică, abordarea AbuseIPDB a rezolvat asta aproape de la sine. Google se poartă frumos cu site-urile pe care le crawlează, așa că nimeni nu îi raportează IP-urile — Googlebot a trecut neatins. Tiparele de trafic real nu s-au schimbat deloc și nu a existat nicio plângere de la vreun cititor.

O categorie de crawler, totuși, a fost prinsă — pe merit. Am observat rapid că printre IP-urile blocate erau crawlere AI ale Anthropic, iar logurile arătau de ce: bombardaseră site-ul cu cereri ciudate, repetitive. Acea prindere accidentală a rezolvat un element mai vechi rămas deschis — Juridice decisese deja să blocheze toate crawlerele AI, dar unele încă se strecurau prin măsurile existente până când filtrele noastre le-au ajuns din urmă.

Ca verificare finală a pagubelor colaterale: aproximativ 95% din toate IP-urile blocate erau localizate în afara României. Pentru o publicație a cărei audiență e în mod covârșitor formată din profesioniști juridici români, orice cazuri marginale prinse în plasă erau un compromis care merita făcut.

Rezultate

• Sarcina totală a serverului a scăzut cu aproximativ 15% — fără nicio schimbare de hardware.
• Scanarea după exploit-uri a ajuns la zero. Zeci de mii de sondări zilnice de vulnerabilități, dispărute.
• Încercările de login WordPress au scăzut cu 99%.
• Încercările de brute-force SSH au scăzut cu 99%, de la sute de mii pe zi la aproximativ o mie.

Iar reacția clientului? „Mulțumesc.” Ăsta e tot citatul — și, sincer, așa arată succesul în munca de infrastructură. Nimeni nu sărbătorește potopul care nu s-a întâmplat. Serverele pur și simplu au devenit mai liniștite, și toată lumea s-a întors la treabă.

Lecții învățate

Secvența fail2ban-apoi-adaptare-apoi-blackhole ne-a învățat ceva ce am transformat de atunci în practică standard: combinația import AbuseIPDB plus fail2ban face acum parte din procesul nostru implicit de hardening, aplicată din prima zi în loc să fie descoperită în mijlocul luptei. Atacatorii se vor adapta la orice filtru singular; filtrele stratificate care se bazează pe raportarea colectivă a mii de alte victime sunt mult mai greu de ocolit.

Dacă te gândești să-ți upgradezi serverele din cauza sarcinii prea mari, confirmă mai întâi că sarcina e cauzată de fapt de trafic legitim — înainte să angajezi un singur euro.

— Alexandru Eftimie, Helios Live

Aceasta e concluzia pentru fiecare proprietar de site care citește. Upgrade-urile de server sunt răspunsul scump la o întrebare pe care nu ai pus-o încă. În cazul Juridice, 15% din „creșterea” sarcinii erau paraziți — iar eliminarea lor a costat o fracțiune din ce ar fi costat scalarea pentru a-i acomoda.

Concluzie

Serverele Juridice.ro cărau două armate ascunse: brute-forceri SSH și boți web care vânau exploit-uri. Niciuna nu reprezenta un risc realist de breșă — munca anterioară de hardening avusese grijă de asta — dar împreună umflau sarcina, poluau logurile și taxau în tăcere o platformă de care jumătate de milion de cititori depind în fiecare lună.

Două apărări stratificate, în mare parte automate — fail2ban plus un blackhole zilnic AbuseIPDB, extins în LiteSpeed odată ce proxy-ul Cloudflare a schimbat terenul — au eliminat 99% din zgomot, au tăiat sarcina totală a serverului cu 15% și, incidental, au terminat treaba de a exclude crawlerele AI nedorite.

Fără dramă, fără downtime, fără hardware nou. Doar instinctul bun al unui tehnician, două fișiere de log și disciplina de a verifica cine bate de fapt la ușă înainte de a construi o ușă mai mare.