Lühidalt: Automatiseeritud rünnakud veebiserverite vastu käivad lainetena: programmid läbivad internetit kättesaadavate serverite leidmiseks, liigitavad need välistunnuste järgi ja proovivad tuntud turvauke nagu PHP2Shell massiliselt läbi. Ettevõtte suurus ei mängi seejuures rolli. Kaitse pakuvad paigatud PHP, väike ründepind ja seire, mis edukaid tabamusi kiiresti märkab.
Lähtepunkt: „Kes peaks meie veebisaidist huvitatud olema?“
Seda küsimust kuuleme pärast PHP2Shelli sageli, eriti väiksematelt ettevõtetelt. Aus vastus: tõenäoliselt keegi isiklikult. Aga seda ei ole sedalaadi turvaaukude puhul ka vaja. Rünnakuid teevad programmid, mis ei otsi nimesid, vaid võimalusi.
BSI (Saksamaa föderaalne infoturbeamet) arvestas PHP2Shelli puhul kiire ja laiaulatusliku ärakasutamisega. Cloudflare teatas rünnakukatsetest ja sellest, et ründajad muutsid oma mustreid, et kaitsereeglitest mööda pääseda. Mõlemad sobivad sellega, mis laialt levinud tarkvara kriitiliste turvaaukude puhul korrapäraselt juhtub.
Kuidas automatiseeritud rünnakud veebiserverite vastu käivad
Automatiseeritud kampaaniad järgivad tavaliselt sarnast mustrit. Järgmine ülevaade kirjeldab faase üldiselt, ilma ründeüksikasjadeta:
| Faas | Mis juhtub | Mis aitab |
|---|---|---|
| Otsimine | Programmid kontrollivad suuri aadressivahemikke või avalikke registreid, nagu sertifikaatide logid, kättesaadavate veebiserverite leidmiseks | vähe avalikult kättesaadavaid süsteeme, kõigi aadresside inventar |
| Liigitamine | Vastuseid hinnatakse: veebiserver, PHP versioon, CMS, tüüpilised teed | versiooniandmeid peita, mittevajalikud failid eemaldada |
| Proovimine | tuntud turvauke testitakse massiliselt, sageli ilma eelneva liigitamiseta | ajakohane PHP, taaskäivitus, WAF täiendava kihina |
| Kinnistumine | edu korral jäetakse tagauks, näiteks veebishell või cron-töö | piiratud kirjutusõigused, PHP käivitamise keeld üleslaadimiskaustades |
| Ärakasutamine | serverit kasutatakse näiteks rämpsposti, krüptokaevandamise, suunamiste või andmevarguse jaoks | protsesside, failide ja väljaminevate ühenduste seire |
Oluline on kolmas rida. Paljud kampaaniad ei vaevu servereid enne täpselt liigitama. Nad proovivad lihtsalt kõike, mis on kättesaadav. Seetõttu ei kaitse ainult märkamatus.
Miks rünnakud tulevad lainetena
Automatiseeritud kampaaniad harva käivad ühe korra ja siis enam mitte. Tüüpiline on lainetena muster. Esimene laine järgneb varsti pärast turvaaugu teatavaks saamist, sageli veel ebaküpsete vahenditega. Järgmised lained tulevad, kui ründajad oma vahendeid täiustavad või kaitsereeglitega kohandavad. Cloudflare täheldas PHP2Shelli puhul just seda: muudetud ründemustreid reeglitest möödapääsemiseks.
Teie jaoks tähendab see: server, mis esimese laine kahjuta üle elas, ei ole püsivalt kindel, kuni see on paigamata. Ja värskelt üles seatud server on sihtmärk sellest hetkest, kui see on kättesaadav. Kes näiteks laseb välja anda uue TLS-sertifikaadi, teeb nime nähtavaks avalikes sertifikaatide logides, mida skannerid samuti analüüsivad. Uus süsteem tuleks seetõttu võrku ühendada alles siis, kui see on juba uuendatud.
Miks väikefirmad on sama palju mõjutatud
Automatiseeritud rünnakute jaoks ei loe üksiku sihtmärgi väärtus, vaid hulk. Väikeettevõtte server pakub arvutusvõimsust, hea mainega domeeni, e-posti saatmist ja vahel kliendiandmeid. Ründajatele on see piisav.
Lisaks: väiksematel ettevõtetel pole sageli oma IT-d, mis uuendusi kohe paigaldaks. Nende serverid jäävad kauemaks haavatavaks ja satuvad seetõttu skannerite tulemusloenditesse sagedamini. Kes paikab esimesena, kukub neist loenditest välja.
Veel üks punkt on tarneahel. Paljud väikesed veebisaidid asuvad agentuuride või väikeste veebimajutajate serverites, kus kümned klienditööd töötavad kõrvuti. Ründajatele on selline server eriti tulus, sest üks tabamus mõjutab korraga paljusid veebisaite. Teie risk ei sõltu siis ainult teie enda hoolsusest, vaid ka teie teenusepakkuja omast.
Skaneerimine teie logides on normaalne ega ole sissemurdmise tõend. Edukas rünnak avaldub teiste jälgedega: uued failid, võõrad protsessid, tundmatud kontod, ebatavalised väljaminevad ühendused.
Mida saate ise kontrollida
Pilk logidesse näitab, kui tugevasti teie serverit skaneeritakse. Järgmised käsud ainult loevad ega muuda midagi:
# Kümme aadressi kõige rohkemate päringutega praeguses ligipääsulogis
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Päringud, millele vastati "ei leitud", sageduse järgi
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Kas server avaldab oma PHP versiooni päises?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Paljud päringud olematutele teedele on tüüpiline skaneerimismüra. Tähelepanelikumaks peaksite muutuma, kui sellistele päringutele järgnevad ootamatult edukad vastused, kui üleslaadimiskaustades kutsutakse välja faile, mida te ei tunne, või kui veebiserveri kasutaja käivitab protsesse, mida ta muidu kunagi ei käivita. Kinnitatud tunnuseid spetsiaalselt PHP2Shelli kohta siiani ei ole, hinnang põhineb seetõttu sellistel käitumuslikel kõrvalekalletel. Kuidas logisid põhjalikumalt analüüsida, kirjeldab juhend Veebiserveri logide analüüs. Kui kolmas päring näitab PHP versiooni, tasub seada expose_php = Off; taustinfo on lehel Versiooniandmete peitmine.
Kaitsekihid õiges järjekorras
- Uuendage PHP ja käivitage uuesti: Ilma selle sammuta jäävad kõik teised meetmed lapiliseks.
- Vähendage ründepinda: kasutamata veebisaidid, testsüsteemid ja vanad mikrosaidid välja lülitada või sisselogimise taha panna.
- Reeglid serval: Veebirakenduste tulemüür (Web Application Firewall) hooldatud reeglistikuga, näiteks OWASP Core Rule Set ModSecurity'ga, püüab osa katseid kinni.
- Pidurdage korduvaid katseid: Vahendid nagu Fail2ban blokeerivad aadresse, mis tekitavad silmatorkavalt palju vigu. Hajutatud skaneerimise vastu aitab see vaid piiratult.
- Jälgige: Hoidke silma peal veebiserveri kasutaja protsessidel, uutel PHP failidel ja väljaminevatel ühendustel, et edukas tabamus ei jääks nädalateks märkamata.
Kuidas PHP SOS konkreetselt aitab?
- Ründepinna kaardistamine: Selgitame välja, millised teie süsteemid on väljastpoolt kättesaadavad ja mida need enda kohta avaldavad.
- Paikamine ja karastamine: Uuendame PHP, käivitame uuesti ning vähendame versiooniandmeid, kirjutusõigusi ja mittevajalikke teenuseid.
- Reeglid ja blokeeringud: Seadistame WAF-i reeglid ja blokeerimismehhanismid teie rakendusele sobivalt.
- Jooksev seire: Teatame silmatorkavatest protsessidest, failidest ja ühendustest, enne kui tabamus muutub intsidendiks.
Kuidas see püsitöös välja näeb, kirjeldab Veebiserverite turvaseire.
Kokkuvõte
Automatiseeritud rünnakud ei küsi, kellele server kuulub. Nad küsivad ainult, kas see on haavatav. Parim vastus sellele on vähemärgatav: paikage kiiresti, pakkuge vähe, vaadake täpselt. Kes seda teeb, seda skaneeritakse edasi, kuid enam ei leita.
Korduma kippuvad küsimused
Kas väikeettevõtted on automatiseeritud rünnakute sihtmärgid?
Jah. Automatiseeritud skaneerimine kontrollib kättesaadavaid servereid käitajat arvestamata. Kas taga on kontsern või käsitööettevõte, ei mängi tarkvara jaoks rolli. Otsustav on, kas server tundub haavatav.
Millest ma skaneerimist oma logides tunnen?
Tüüpilised on paljud päringud teedele, mida teie veebisaidil üldse ei ole, sageli muutuvatelt aadressidelt ja silmatorkavate tunnustega. Sellised kirjed on normaalsed ega ole veel edukat rünnakut tõendavad, kuid näitavad, et teie serverit kontrollitakse.
Kas PHP versiooni peitmine aitab?
See raskendab skanneritel teie serveri sihipärast liigitamist ja on mõistlik põhisäte. Rünnakute vastu, mis proovivad lihtsalt iga serverit, see aga ei kaitse. Uuendus jääb kohustuslikuks.
Kas ma saan skaneerimist täielikult ära hoida?
Ei. Iga avalikult kättesaadavat serverit skaneeritakse korrapäraselt. Eesmärk ei ole skaneerimist takistada, vaid tagada, et see midagi ei leia: ajakohane tarkvara, väike ründepind ja seire, mis kõrvalekalletest teatab.