Na kratko: Samodejni napadi na spletne strežnike potekajo v valovih: programi iščejo po internetu dosegljive strežnike, jih razvrščajo po zunanjih značilnostih in množično preizkušajo znane ranljivosti, kot je PHP2Shell. Velikost podjetja pri tem ne igra vloge. Zaščito nudijo popravljen PHP, majhna površina napada in nadzor, ki uspešne zadetke hitro opazi.
Povod: „Kdo bi se zanimal za našo spletno stran?“
To vprašanje po PHP2Shell pogosto slišimo, predvsem od manjših podjetij. Iskren odgovor: verjetno nihče osebno. A pri ranljivostih te vrste to tudi ni potrebno. Napade izvajajo programi, ki ne iščejo imen, ampak priložnosti.
BSI (nemški zvezni urad za informacijsko varnost) je pri PHP2Shell računal s hitrim in obsežnim izkoriščanjem. Cloudflare je poročal o poskusih napadov in o tem, da so napadalci spreminjali svoje vzorce, da bi zaobšli zaščitna pravila. Oboje ustreza temu, kar se ob kritičnih ranljivostih v razširjeni programski opremi redno dogaja.
Kako potekajo samodejni napadi na spletne strežnike
Samodejne kampanje praviloma sledijo podobnemu vzorcu. Naslednji pregled splošno opisuje faze, brez podrobnosti napada:
| Faza | Kaj se zgodi | Kaj pomaga |
|---|---|---|
| Iskanje | Programi preverjajo velike naslovne obsege ali javne imenike, kot so zapisniki potrdil, glede dosegljivih spletnih strežnikov | malo javno dosegljivih sistemov, popis vseh naslovov |
| Razvrščanje | Odgovori se ovrednotijo: spletni strežnik, različica PHP, CMS, tipične poti | skriti podatke o različici, odstraniti nepotrebne datoteke |
| Preizkušanje | Znane ranljivosti se množično preizkušajo, pogosto brez predhodnega razvrščanja | aktualen PHP, ponovni zagon, WAF kot dodatna plast |
| Utrditev | Ob uspehu se odloži stranska vrata, na primer webshell ali cronjob | omejene pravice pisanja, brez izvajanja PHP v mapah za nalaganje |
| Izkoriščanje | Strežnik se uporablja, na primer za spam, kriptorudarjenje, preusmeritve ali krajo podatkov | nadzor procesov, datotek in odhodnih povezav |
Pomembna je tretja vrstica. Mnoge kampanje se sploh ne potrudijo, da bi strežnike predhodno natančno razvrstile. Preprosto preizkusijo vse, kar je dosegljivo. Zato samo neopaznost ne ščiti.
Zakaj napadi prihajajo v valovih
Samodejne kampanje redko tečejo enkrat in nikoli več. Tipičen je vzorec v valovih. Prvi val sledi kmalu po razkritju ranljivosti, pogosto še z nedodelanimi orodji. Nadaljnji valovi pridejo, ko napadalci svoja orodja izboljšajo ali prilagodijo zaščitnim pravilom. Cloudflare je prav to opazil pri PHP2Shell: spremenjene vzorce napadov, da bi zaobšli pravila.
Za vas to pomeni: strežnik, ki je prvi val preživel brez škode, ni trajno varen, dokler je nepopravljen. In na novo postavljen strežnik je tarča od trenutka, ko je dosegljiv. Kdor na primer da izdati novo potrdilo TLS, ime naredi vidno v javnih zapisnikih potrdil, ki jih ovrednotijo tudi skenerji. Nov sistem naj zato na omrežje pride šele, ko je že posodobljen.
Zakaj so mala podjetja prizadeta enako
Pri samodejnih napadih ne šteje vrednost posamezne tarče, ampak količina. Strežnik malega obrata ponuja računsko moč, domeno z dobrim ugledom, pošiljanje pošte in včasih podatke strank. Za napadalce je to dovolj.
Dodatno: manjša podjetja pogosto nimajo lastne IT, ki bi posodobitve namestila takoj. Njihovi strežniki ostanejo dlje ranljivi in zato pogosteje pristanejo na seznamih rezultatov skenerjev. Kdor posodobi prvi, z teh seznamov izpade.
Naslednja točka je dobavna veriga. Mnoge majhne spletne strani so na strežnikih agencij ali majhnih ponudnikov gostovanja, kjer drug ob drugem teče na deset projektov strank. Za napadalce je tak strežnik še posebej donosen, ker en sam zadetek zadene veliko spletnih strani hkrati. Vaše tveganje potem ni odvisno samo od vaše lastne skrbnosti, ampak tudi od skrbnosti vašega izvajalca.
Skeniranja v vaših logih so običajna in niso dokaz vloma. Uspešen napad se pokaže po drugih sledeh: nove datoteke, tuji procesi, neznani računi, nenavadne odhodne povezave.
Kaj lahko preverite sami
Pogled v loge pokaže, kako močno se vaš strežnik skenira. Naslednji ukazi samo berejo in ničesar ne spreminjajo:
# Deset naslovov z največ zahtevami v aktualnem dostopnem logu
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Zahteve, na katere je bilo odgovorjeno z "ni najdeno", po pogostosti
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Ali strežnik v glavi izda svojo različico PHP?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Veliko zahtev na neobstoječe poti je tipičen šum skeniranj. Pozornejši bodite, če na take zahteve nenadoma sledijo uspešni odgovori, če se v mapah za nalaganje kličejo datoteke, ki jih ne poznate, ali če uporabnik spletnega strežnika zažene procese, ki jih sicer nikoli ne zažene. Potrjenih znakov za prepoznavanje posebej za PHP2Shell zaenkrat ni, zato ocena temelji na takih nepravilnostih v vedenju. Kako loge temeljiteje ovrednotite, opisuje vodnik Vrednotenje logov spletnega strežnika. Če tretja poizvedba pokaže različico PHP, se splača nastavitev expose_php = Off; ozadje je pod Skrivanje podatkov o različici.
Zaščitne plasti v pravem vrstnem redu
- Posodobiti PHP in ga znova zagnati: Brez tega koraka ostanejo vsi drugi ukrepi krpanje.
- Zmanjšati površino napada: neuporabljene spletne strani, testne sisteme in stare mikrostrani izklopiti ali postaviti za prijavo.
- Pravila na robu: Web Application Firewall z vzdrževanim pravilnikom, na primer OWASP Core Rule Set z ModSecurity, ujame del poskusov.
- Zavirati ponavljajoče se poskuse: Orodja, kot je Fail2ban, blokirajo naslove, ki povzročajo opazno veliko napak. Proti porazdeljenim skeniranjem to pomaga le omejeno.
- Nadzorovati: Imeti na očeh procese uporabnika spletnega strežnika, nove datoteke PHP in odhodne povezave, da uspešen zadetek ne ostane tednami neopažen.
Kako konkretno pomaga PHP SOS?
- Zajem površine napada: Ugotovimo, kateri vaši sistemi so dosegljivi od zunaj in kaj izdajo o sebi.
- Popravki in utrditev: Posodobimo PHP, znova zaženemo ter zmanjšamo podatke o različici, pravice pisanja in nepotrebne storitve.
- Pravila in blokade: Pravila WAF in mehanizme blokiranja uvedemo glede na vašo aplikacijo.
- Stalni nadzor: Javljamo nenavadne procese, datoteke in povezave, preden zadetek postane incident.
Kako to izgleda v stalnem delovanju, opisuje Varnostni monitoring za spletne strežnike.
Sklep
Samodejni napadi ne sprašujejo, čigav je strežnik. Sprašujejo samo, ali je ranljiv. Najboljši odgovor je neopazen: hitro posodobiti, malo ponujati, natančno gledati. Kdor to stori, bo še naprej skeniran, a ne bo več najden.
Pogosta vprašanja
Ali so mala podjetja tarča samodejnih napadov?
Da. Samodejna skeniranja preverjajo dosegljive strežnike, ne glede na upravljavca. Ali stoji za njim koncern ali obrtniški obrat, za programsko opremo ni pomembno. Odločilno je, ali strežnik deluje ranljivo.
Po čem prepoznam skeniranja v svojih logih?
Tipične so številne zahteve na poti, ki jih na vaši spletni strani sploh ni, pogosto z menjajočih se naslovov in z opaznimi identifikatorji. Taki vnosi so običajni in še niso dokaz uspešnega napada, kažejo pa, da je vaš strežnik pod drobnogledom.
Ali pomaga skrivanje različice PHP?
Skenerjem nekoliko oteži ciljno razvrščanje vašega strežnika in je smiselna osnovna nastavitev. Pred napadi, ki preprosto preizkusijo vsak strežnik, pa ne ščiti. Posodobitev ostane dolžnost.
Ali lahko skeniranja povsem preprečim?
Ne. Vsak javno dostopen strežnik se redno skenira. Cilj ni preprečiti skeniranja, ampak poskrbeti, da ne najde ničesar: aktualna programska oprema, majhna površina napada in nadzor, ki javlja nepravilnosti.