Trumpai: Automatizuotos atakos prieš žiniatinklio serverius vyksta bangomis: programos naršo internetą ieškodamos pasiekiamų serverių, priskiria juos pagal išorinius požymius ir masiškai bando žinomas spragas, tokias kaip PHP2Shell. Įmonės dydis čia nevaidina jokio vaidmens. Apsaugo pataisytas PHP, maža atakos paviršiaus dalis ir stebėsena, kuri greitai pastebi sėkmingus pataikymus.
Pradžia: „Kas turėtų domėtis mūsų svetaine?“
Šį klausimą po PHP2Shell girdime dažnai, ypač iš mažesnių įmonių. Sąžiningas atsakymas: tikriausiai niekas asmeniškai. Bet tokio pobūdžio spragų atveju to ir nereikia. Atakas vykdo programos, kurios ieško ne vardų, o galimybių.
BSI dėl PHP2Shell tikėjosi greito, plataus masto išnaudojimo. Cloudflare pranešė apie atakos bandymus ir apie tai, kad užpuolikai keitė savo šablonus, kad apeitų apsaugos taisykles. Abu dalykai atitinka tai, kas reguliariai nutinka su kritinėmis spragomis plačiai paplitusioje programinėje įrangoje.
Kaip vyksta automatizuotos atakos prieš žiniatinklio serverius
Automatizuotos kampanijos paprastai seka panašų šabloną. Toliau pateikta apžvalga bendrai aprašo fazes, be atakos detalių:
| Fazė | Kas vyksta | Kas padeda |
|---|---|---|
| Paieška | programos tikrina dideles adresų sritis ar viešus katalogus, pavyzdžiui, sertifikatų žurnalus, ieškodamos pasiekiamų žiniatinklio serverių | mažai viešai pasiekiamų sistemų, visų adresų inventorius |
| Priskyrimas | analizuojami atsakymai: žiniatinklio serveris, PHP versija, CMS, tipiniai keliai | slėpti versijų nurodymus, šalinti nereikalingus failus |
| Bandymas | žinomos spragos išbandomos masiškai, dažnai be išankstinio priskyrimo | aktualus PHP, paleidimas iš naujo, WAF kaip papildomas sluoksnis |
| Įsitvirtinimas | pavykus paliekamos užpakalinės durys, pavyzdžiui, webshell arba cron užduotis | apriboti rašymo teisės, jokio PHP vykdymo įkėlimo aplankuose |
| Panaudojimas | serveris naudojamas, pavyzdžiui, šlamštui, kriptokasimui, nukreipimams ar duomenų vagystei | procesų, failų ir išeinančių jungčių stebėsena |
Svarbi trečia eilutė. Daug kampanijų net nesivargina serverių iš anksto tiksliai priskirti. Jos tiesiog išbando viską, kas pasiekiama. Todėl vien nepastebimumas neapsaugo.
Kodėl atakos ateina bangomis
Automatizuotos kampanijos retai vyksta vieną kartą ir daugiau niekada. Tipiškas šablonas yra bangomis. Pirmoji banga seka netrukus po spragos paviešinimo, dažnai dar su neišbaigtais įrankiais. Kitos bangos ateina, kai užpuolikai tobulina savo įrankius arba pritaiko juos prie apsaugos taisyklių. Cloudflare su PHP2Shell tai pastebėjo: pakitę atakos šablonai taisyklėms apeiti.
Jums tai reiškia: serveris, kuris pirmąją bangą išlaikė nepažeistas, nėra saugus ilgam, kol yra nepataisytas. O naujai pastatytas serveris tampa taikiniu nuo to momento, kai tampa pasiekiamas. Kas, pavyzdžiui, išduoda naują TLS sertifikatą, pavadinimą padaro matomą viešuose sertifikatų žurnaluose, kuriuos vertina ir skeneriai. Todėl naują sistemą į tinklą reikėtų jungti tik jau atnaujintą.
Kodėl mažos įmonės paveiktos lygiai taip pat
Automatizuotoms atakoms svarbi ne atskiro taikinio vertė, o kiekis. Mažos įmonės serveris suteikia skaičiavimo galią, gerą reputaciją turintį domeną, pašto siuntimą ir kartais klientų duomenis. Užpuolikams to pakanka.
Be to: mažesnės įmonės dažnai neturi savo IT, kuri atnaujinimus įdiegtų iš karto. Jų serveriai ilgiau lieka pažeidžiami ir todėl dažniau patenka į skenerių rezultatų sąrašus. Kas pirmas pataiso, iš šių sąrašų iškrenta.
Dar vienas punktas yra tiekimo grandinė. Daug mažų svetainių yra agentūrų ar mažų talpintojų serveriuose, kur greta veikia dešimtys klientų projektų. Užpuolikams toks serveris ypač naudingas, nes vienas pataikymas paliečia daug svetainių vienu metu. Jūsų rizika tada priklauso ne tik nuo jūsų pačių rūpestingumo, bet ir nuo jūsų paslaugų teikėjo.
Skenavimai jūsų žurnaluose yra normalūs ir nėra įsilaužimo įrodymas. Sėkminga ataka pasireiškia kitais pėdsakais: nauji failai, svetimi procesai, nežinomos paskyros, neįprastos išeinančios jungtys.
Ką galite patikrinti patys
Žvilgsnis į žurnalus parodo, kaip stipriai jūsų serveris skenuojamas. Toliau pateiktos komandos tik skaito ir nieko nekeičia:
# Dešimt adresų su daugiausia užklausų dabartiniame prieigos žurnale
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Užklausos, į kurias atsakyta „nerasta“, pagal dažnį
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Ar serveris antraštėje atskleidžia savo PHP versiją?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Daug užklausų neegzistuojančiais keliais yra tipiškas skenavimo triukšmas. Atidesni turėtumėte tapti, jei po tokių užklausų staiga seka sėkmingi atsakymai, jei įkėlimo aplankuose iškviečiami jums nežinomi failai arba jei žiniatinklio serverio naudotojas paleidžia procesus, kurių paprastai niekada nepaleidžia. Patvirtintų atpažinimo požymių būtent PHP2Shell kol kas nėra, todėl vertinimas remiasi tokiais elgsenos neįprastumais. Kaip žurnalus analizuoti nuodugniau, aprašo vadovas Žiniatinklio serverio žurnalų analizė. Jei trečioji užklausa rodo PHP versiją, verta nustatymo expose_php = Off; pagrindimą rasite skyrelyje Versijų nurodymų slėpimas.
Apsaugos sluoksniai teisinga tvarka
- Atnaujinti PHP ir paleisti iš naujo: be šio žingsnio visos kitos priemonės lieka lopinėjimu.
- Sumažinti atakos paviršių: nenaudojamas svetaines, bandomąsias sistemas ir senas mikrosvetaines išjungti arba paslėpti už prisijungimo.
- Taisyklės pakraštyje: žiniatinklio programų užkarda (Web Application Firewall) su prižiūrimu taisyklių rinkiniu, pavyzdžiui, OWASP Core Rule Set su ModSecurity, sulaiko dalį bandymų.
- Stabdyti pasikartojančius bandymus: įrankiai, tokie kaip Fail2ban, blokuoja adresus, kurie sukelia neįprastai daug klaidų. Nuo paskirstytų skenavimų tai padeda tik ribotai.
- Stebėti: akyse laikyti žiniatinklio serverio naudotojo procesus, naujus PHP failus ir išeinančias jungtis, kad sėkmingas pataikymas savaitėmis nepasiliktų nepastebėtas.
Kaip PHP SOS padeda konkrečiai?
- Surašyti atakos paviršių: Nustatome, kurios jūsų sistemos pasiekiamos iš išorės ir ką jos apie save atskleidžia.
- Taisyti ir sutvirtinti: Atnaujiname PHP, paleidžiame iš naujo ir sumažiname versijų nurodymus, rašymo teises ir nereikalingas paslaugas.
- Taisyklės ir blokavimai: Parengiame WAF taisykles ir blokavimo mechanizmus, tinkančius jūsų programai.
- Nuolatinė stebėsena: Pranešame apie neįprastus procesus, failus ir jungtis, kol pataikymas netapo incidentu.
Kaip tai atrodo nuolatiniame veikime, aprašo Žiniatinklio serverių saugumo stebėsena.
Išvada
Automatizuotos atakos neklausia, kam serveris priklauso. Jos klausia tik, ar jis pažeidžiamas. Geriausias atsakymas tam nespalvingas: greitai taisyti, mažai siūlyti, atidžiai žiūrėti. Kas taip daro, toliau skenuojamas, bet neberandamas.
Dažni klausimai
Ar mažos įmonės yra automatizuotų atakų taikiniai?
Taip. Automatizuoti skenavimai tikrina pasiekiamus serverius nežiūrėdami į operatorių. Ar už jo stovi koncernas ar amatininko įmonė, programinei įrangai nesvarbu. Lemia, ar serveris atrodo pažeidžiamas.
Pagal ką atpažinti skenavimus savo žurnaluose?
Tipiška: daug užklausų keliais, kurių jūsų svetainėje išvis nėra, dažnai iš kintančių adresų ir su krintančiais į akis identifikatoriais. Tokie įrašai yra normalūs ir dar neįrodo sėkmingos atakos, bet rodo, kad jūsų serveris tikrinamas.
Ar padeda paslėpti PHP versiją?
Skeneriams šiek tiek sunkiau tiksliai priskirti jūsų serverį, ir tai prasmingas pagrindinis nustatymas. Bet tai neapsaugo nuo atakų, kurios tiesiog išbando kiekvieną serverį. Atnaujinimas išlieka pareiga.
Ar galiu skenavimus visiškai užkirsti?
Ne. Kiekvienas viešai pasiekiamas serveris reguliariai skenuojamas. Tikslas ne užkirsti kelią skenavimams, o pasirūpinti, kad jie nieko neberastų: aktuali programinė įranga, maža atakos paviršiaus dalis ir stebėsena, kuri praneša apie neįprastumus.