Pe scurt: Atacurile automatizate asupra serverelor web vin în valuri: programe parcurg internetul după servere accesibile, le încadrează pe baza unor trăsături externe și încearcă în masă vulnerabilități cunoscute precum PHP2Shell. Dimensiunea companiei nu joacă niciun rol. Protecție oferă un PHP actualizat, o suprafață de atac mică și o monitorizare care observă rapid loviturile reușite.
Punctul de plecare: „Pe cine ar interesa site-ul nostru?”
Această întrebare o auzim des după PHP2Shell, mai ales de la companii mai mici. Răspunsul sincer: probabil pe nimeni personal. Dar la vulnerabilități de acest fel nici nu este necesar. Atacurile sunt executate de programe care nu caută nume, ci ocazii.
BSI (Oficiul Federal German pentru Securitatea Informațiilor) a anticipat la PHP2Shell o exploatare rapidă și pe scară largă. Cloudflare a relatat încercări de atac și faptul că atacatorii și-au schimbat tiparele pentru a ocoli regulile de protecție. Ambele se potrivesc cu ceea ce se întâmplă în mod regulat la vulnerabilități critice din software răspândit.
Cum decurg atacurile automatizate asupra serverelor web
Campaniile automatizate urmează de obicei un tipar similar. Prezentarea următoare descrie fazele în general, fără detalii de atac:
| Fază | Ce se întâmplă | Ce ajută împotriva ei |
|---|---|---|
| Căutare | programe verifică intervale mari de adrese sau directoare publice, precum jurnalele de certificate, după servere web accesibile | puține sisteme accesibile public, inventarul tuturor adreselor |
| Încadrare | răspunsurile sunt evaluate: server web, versiune PHP, CMS, căi tipice | ascunderea indicațiilor de versiune, eliminarea fișierelor inutile |
| Încercare | vulnerabilități cunoscute sunt testate în masă, adesea fără încadrare prealabilă | PHP actual, repornire, WAF ca strat suplimentar |
| Consolidare | la succes este plasată o ușă din spate, de exemplu un webshell sau un cronjob | drepturi de scriere restricționate, fără execuție PHP în directoarele de upload |
| Valorificare | serverul este folosit, de exemplu pentru spam, criptominare, redirecționări sau furt de date | monitorizarea proceselor, fișierelor și conexiunilor de ieșire |
Important este al treilea rând. Multe campanii nici nu se obosesc să încadreze serverele dinainte. Încearcă pur și simplu tot ce este accesibil. De aceea, discreția singură nu protejează.
De ce atacurile vin în valuri
Campaniile automatizate rareori rulează o singură dată și apoi niciodată. Tipic este un tipar în valuri. Primul val urmează la scurt timp după ce o vulnerabilitate devine cunoscută, adesea încă cu instrumente neîmplinite. Alte valuri vin când atacatorii își îmbunătățesc instrumentele sau le adaptează la regulile de protecție. Cloudflare a observat exact acest lucru la PHP2Shell: tipare de atac modificate pentru a ocoli regulile.
Pentru dumneavoastră înseamnă: un server care a trecut nevătămat de primul val nu este sigur pe termen lung cât timp este neactualizat. Iar un server nou configurat este țintă din momentul în care este accesibil. Cine, de exemplu, emite un certificat TLS nou face numele vizibil în jurnalele publice de certificate, pe care le evaluează și scanerele. Un sistem nou ar trebui de aceea conectat la rețea abia când este deja actualizat.
De ce firmele mici sunt afectate la fel
Pentru atacurile automatizate nu contează valoarea unei singure ținte, ci cantitatea. Un server al unei firme mici oferă putere de calcul, un domeniu cu reputație bună, trimitere de e-mailuri și uneori date ale clienților. Pentru atacatori, este suficient.
La aceasta se adaugă: companiile mai mici nu au adesea un IT propriu care să instaleze imediat actualizările. Serverele lor rămân vulnerabile mai mult timp și ajung de aceea mai des în listele de rezultate ale scanerelor. Cine actualizează primul iese din aceste liste.
Un alt punct este lanțul de aprovizionare. Multe site-uri mici se află pe servere ale unor agenții sau ale unor furnizori mici de hosting, pe care rulează în paralel zeci de proiecte de clienți. Pentru atacatori, un astfel de server este deosebit de rentabil, deoarece o singură lovitură afectează simultan multe site-uri. Riscul dumneavoastră depinde atunci nu doar de propria diligență, ci și de cea a prestatorului dumneavoastră.
Scanările din logurile dumneavoastră sunt normale și nu sunt o dovadă a unei intruziuni. Un atac reușit se arată prin alte urme: fișiere noi, procese străine, conturi necunoscute, conexiuni de ieșire neobișnuite.
Ce puteți verifica singur
O privire în loguri arată cât de intens este scanat serverul dumneavoastră. Comenzile următoare doar citesc și nu modifică nimic:
# Cele zece adrese cu cele mai multe cereri în logul de acces curent
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Cereri la care s-a răspuns cu „negăsit”, după frecvență
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Dezvăluie serverul versiunea PHP în antet?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Multe cereri către căi inexistente sunt zgomot tipic de scanare. Ar trebui să deveniți mai atenți dacă la astfel de cereri urmează brusc răspunsuri reușite, dacă în directoarele de upload sunt accesate fișiere pe care nu le cunoașteți sau dacă utilizatorul serverului web pornește procese pe care altfel nu le pornește niciodată. Semne de recunoaștere confirmate special pentru PHP2Shell nu există deocamdată, încadrarea se bazează de aceea pe astfel de comportamente neobișnuite. Cum analizați logurile mai temeinic descrie ghidul Analiza logurilor serverului web. Dacă a treia interogare arată o versiune PHP, merită setarea expose_php = Off; contextul se află la Ascunderea indicațiilor de versiune.
Straturile de protecție în ordinea corectă
- Actualizați PHP și reporniți: Fără acest pas, toate celelalte măsuri rămân improvizație.
- Reduceți suprafața de atac: opriți sau puneți în spatele unei autentificări site-urile nefolosite, sistemele de test și microsite-urile vechi.
- Reguli la margine: Un Web Application Firewall cu un set de reguli întreținut, de exemplu OWASP Core Rule Set cu ModSecurity, oprește o parte dintre încercări.
- Frânați încercările repetate: Instrumente precum Fail2ban blochează adresele care generează un număr neobișnuit de mare de erori. Împotriva scanărilor distribuite, aceasta ajută doar limitat.
- Monitorizați: Urmăriți procesele utilizatorului serverului web, fișierele PHP noi și conexiunile de ieșire, pentru ca o lovitură reușită să nu rămână neobservată săptămâni.
Cum ajută PHP SOS concret?
- Inventarierea suprafeței de atac: Stabilim care dintre sistemele dumneavoastră sunt accesibile din exterior și ce dezvăluie despre ele însele.
- Actualizare și securizare: Actualizăm PHP, repornim și reducem indicațiile de versiune, drepturile de scriere și serviciile inutile.
- Reguli și blocări: Configurăm reguli WAF și mecanisme de blocare potrivite aplicației dumneavoastră.
- Monitorizare continuă: Semnalăm procese, fișiere și conexiuni neobișnuite înainte ca o lovitură să devină incident.
Cum arată acest lucru în funcționarea de durată descrie Monitorizarea de securitate pentru serverele web.
Concluzie
Atacurile automatizate nu întreabă cui aparține un server. Întreabă doar dacă este vulnerabil. Cel mai bun răspuns la aceasta este lipsit de spectaculos: actualizați repede, oferiți puțin, priviți cu atenție. Cine face acest lucru va fi scanat în continuare, dar nu va mai fi găsit.
Întrebări frecvente
Sunt companiile mici ținte ale atacurilor automatizate?
Da. Scanările automatizate verifică serverele accesibile fără să țină cont de operator. Dacă în spate se află un concern sau o firmă de meșteșugari nu are importanță pentru software. Decisiv este dacă serverul pare vulnerabil.
Cum recunosc scanările în logurile mele?
Tipice sunt multe cereri către căi care nu există deloc pe site-ul dumneavoastră, adesea de la adrese variabile și cu identificatori neobișnuiți. Astfel de intrări sunt normale și nu sunt încă o dovadă a unui atac reușit, dar arată că serverul dumneavoastră este verificat.
Ajută dacă ascund versiunea PHP?
Le îngreunează puțin scanerelor încadrarea țintită a serverului dumneavoastră și este o setare de bază utilă. Nu protejează însă împotriva atacurilor care încearcă pur și simplu orice server. Actualizarea rămâne obligatorie.
Pot preveni complet scanările?
Nu. Orice server accesibil public este scanat regulat. Scopul nu este să împiedicați scanările, ci să vă asigurați că ele nu găsesc nimic: software actual, suprafață de atac mică și o monitorizare care semnalează lucrurile neobișnuite.