Ukratko: Automatizirani napadi na web-poslužitelje teku u valovima: programi pretražuju internet u potrazi za dostupnim poslužiteljima, razvrstavaju ih prema vanjskim obilježjima i masovno isprobavaju poznate ranjivosti poput PHP2Shella. Veličina tvrtke pritom nije važna. Zaštitu pružaju zakrpani PHP, mala površina napada i nadzor koji brzo uoči uspješne pogotke.
Povod: „Tko bi se zanimao za našu web-stranicu?“
To pitanje često čujemo nakon PHP2Shella, osobito od manjih poduzeća. Iskren odgovor: vjerojatno nitko osobno. No kod ranjivosti ove vrste to nije ni potrebno. Napade izvode programi koji ne traže imena, nego prilike.
BSI (njemački Savezni ured za informacijsku sigurnost) kod PHP2Shella računao je s brzim iskorištavanjem u velikom opsegu. Cloudflare je izvijestio o pokušajima napada i o tome da su napadači mijenjali obrasce kako bi zaobišli zaštitna pravila. Oboje se uklapa u ono što se kod kritičnih ranjivosti u raširenom softveru redovito događa.
Kako teku automatizirani napadi na web-poslužitelje
Automatizirane kampanje obično slijede sličan obrazac. Sljedeći pregled općenito opisuje faze, bez pojedinosti napada:
| Faza | Što se događa | Što pomaže protiv toga |
|---|---|---|
| Traženje | Programi provjeravaju velike adresne raspone ili javne imenike poput zapisnika certifikata u potrazi za dostupnim web-poslužiteljima | malo javno dostupnih sustava, inventar svih adresa |
| Razvrstavanje | Analiziraju se odgovori: web-poslužitelj, PHP verzija, CMS, tipične putanje | sakriti oznake verzija, ukloniti nepotrebne datoteke |
| Isprobavanje | poznate ranjivosti testiraju se masovno, često bez prethodnog razvrstavanja | aktualan PHP, ponovno pokretanje, WAF kao dodatni sloj |
| Učvršćivanje | pri uspjehu se ostavlja stražnja vrata, primjerice webshell ili cron posao | ograničena prava pisanja, nema izvršavanja PHP-a u mapama za upload |
| Iskorištavanje | poslužitelj se koristi, primjerice za spam, kriptorudarenje, preusmjeravanja ili krađu podataka | nadzor procesa, datoteka i odlaznih veza |
Važan je treći redak. Mnoge kampanje uopće se ne trude prethodno točno razvrstati poslužitelje. Jednostavno isprobavaju sve što je dostupno. Zato sama neupadljivost ne štiti.
Zašto napadi dolaze u valovima
Automatizirane kampanje rijetko teku jednom i nikad više. Tipičan je obrazac u valovima. Prvi val slijedi ubrzo nakon objave ranjivosti, često još s nezrelim alatima. Daljnji valovi dolaze kad napadači poboljšaju alate ili ih prilagode zaštitnim pravilima. Cloudflare je upravo to uočio kod PHP2Shella: izmijenjene obrasce napada radi zaobilaženja pravila.
Za Vas to znači: poslužitelj koji je prvi val prebrodio bez štete nije trajno siguran dok je nezakrpan. A novopostavljeni poslužitelj meta je od trenutka kad postane dostupan. Tko primjerice dâ izdati novi TLS certifikat, ime čini vidljivim u javnim zapisnicima certifikata koje analiziraju i skeneri. Novi sustav zato treba na mrežu tek kad je već ažuriran.
Zašto su mala poduzeća jednako pogođena
Za automatizirane napade ne računa se vrijednost pojedine mete, nego količina. Poslužitelj malog poduzeća nudi procesorsku snagu, domenu s dobrim ugledom, slanje e-pošte i katkad podatke o kupcima. Napadačima je to dovoljno.
Tome pridolazi: manja poduzeća često nemaju vlastiti IT koji odmah instalira ažuriranja. Njihovi poslužitelji dulje ostaju ranjivi pa se češće nalaze na popisima rezultata skenera. Tko prvi zakrpa, ispada s tih popisa.
Sljedeća je točka lanac isporuke. Mnoge male web-stranice leže na poslužiteljima agencija ili malih pružatelja hostinga na kojima uporedo radi na desetke projekata kupaca. Napadačima je takav poslužitelj osobito isplativ jer jedan pogodak istodobno pogađa mnoge web-stranice. Vaš rizik tada ne ovisi samo o Vašoj pažnji, nego i o pažnji Vašeg pružatelja usluga.
Skeniranja u Vašim logovima su normalna i nisu dokaz provale. Uspješan napad pokazuje se drugim tragovima: nove datoteke, strani procesi, nepoznati računi, neuobičajene odlazne veze.
Što možete sami provjeriti
Pogled u logove pokazuje koliko se Vaš poslužitelj skenira. Sljedeće naredbe samo čitaju i ništa ne mijenjaju:
# Deset adresa s najviše zahtjeva u aktualnom pristupnom logu
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Zahtjevi na koje je odgovoreno s "nije pronađeno", po učestalosti
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Odaje li poslužitelj svoju PHP verziju u zaglavlju?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Mnogo zahtjeva na nepostojeće putanje tipična je skenerska buka. Pozorniji biste trebali postati ako na takve zahtjeve iznenada slijede uspješni odgovori, ako se u mapama za upload pozivaju datoteke koje ne poznajete ili ako korisnik web-poslužitelja pokreće procese koje inače nikad ne pokreće. Potvrđenih obilježja za prepoznavanje posebno za PHP2Shell za sada nema, pa se procjena temelji na takvim neobičnostima u ponašanju. Kako logove analizirati temeljitije, opisuje vodič Analiza logova web-poslužitelja. Ako treća naredba prikaže PHP verziju, isplati se postavka expose_php = Off; pozadinu navodi članak Sakriti oznake verzija.
Slojevi zaštite u pravom redoslijedu
- Ažurirati PHP i ponovno pokrenuti: Bez tog koraka sve ostale mjere ostaju krpanje.
- Smanjiti površinu napada: neiskorištene web-stranice, testne sustave i stare mikrostranice isključiti ili staviti iza prijave.
- Pravila na rubu: Web Application Firewall s održavanim skupom pravila, primjerice OWASP Core Rule Set s ModSecurityjem, presreće dio pokušaja.
- Usporiti ponovljene pokušaje: Alati poput Fail2bana blokiraju adrese koje stvaraju upadljivo mnogo pogrešaka. Protiv distribuiranih skeniranja to pomaže samo ograničeno.
- Nadzirati: Procese korisnika web-poslužitelja, nove PHP datoteke i odlazne veze držati na oku kako uspješan pogodak ne bi tjednima ostao neopažen.
Kako PHP SOS konkretno pomaže?
- Utvrditi površinu napada: Utvrđujemo koji su Vaši sustavi dostupni izvana i što o sebi odaju.
- Zakrpati i ojačati: Ažuriramo PHP, ponovno pokrećemo i smanjujemo oznake verzija, prava pisanja i nepotrebne usluge.
- Pravila i blokade: Postavljamo WAF pravila i mehanizme blokiranja prilagođene Vašoj aplikaciji.
- Stalni nadzor: Javljamo upadljive procese, datoteke i veze prije nego što pogodak postane incident.
Kako to izgleda u trajnom radu, opisuje Sigurnosni monitoring za web-poslužitelje.
Zaključak
Automatizirani napadi ne pitaju kome poslužitelj pripada. Pitaju samo je li ranjiv. Najbolji odgovor na to je nespektakularan: brzo zakrpati, malo nuditi, pažljivo gledati. Tko to čini, i dalje će se skenirati, ali ga više neće naći.
Česta pitanja
Jesu li mala poduzeća meta automatiziranih napada?
Da. Automatizirana skeniranja provjeravaju dostupne poslužitelje bez obzira na operatera. Je li iza njih koncern ili obrtnička radnja, softveru je svejedno. Odlučuje djeluje li poslužitelj ranjivo.
Po čemu prepoznajem skeniranja u svojim logovima?
Tipični su brojni zahtjevi za putanje kojih na Vašoj web-stranici uopće nema, često s promjenjivih adresa i s upadljivim oznakama. Takvi su unosi normalni i još nisu dokaz uspješnog napada, ali pokazuju da se Vaš poslužitelj provjerava.
Pomaže li skrivanje PHP verzije?
Skenerima malo otežava ciljano razvrstavanje Vašeg poslužitelja i smislena je osnovna postavka. No ne štiti od napada koji jednostavno isprobavaju svaki poslužitelj. Ažuriranje ostaje obveza.
Mogu li skeniranja potpuno spriječiti?
Ne. Svaki javno dostupan poslužitelj redovito se skenira. Cilj nije spriječiti skeniranja, nego osigurati da ne nađu ništa: aktualan softver, mala površina napada i nadzor koji javlja neobičnosti.