616 bandymų atakuoti per 8 dienas

Realių atakų nebuvo. Visi 616 išoriniai saugumo įvykiai, kurie buvo užregistruoti nuo 7 iki 15 liepos, pasirodė esą automatinių botų sukurtas triukšmas - skaitytuvai, kurie masiškai patikrina tūkstančius svetainių, ieškodami žinomų WordPress pažeidžiamumų. Mūsų svetainė nėra pastatyta ant WordPress, todėl ieškomi keliai niekada neegzistavo, o kiekvienas bandymas baigiasi blokavimoklaida 404.

Skaičiai

Ką tiksliai ieškota - ir kodėl tai pavojinga neapsaugotai svetainei

Žemiau esantys keliai yra klasikiniai WordPress tikslai. Mūsų atveju jie buvo nepavojingi, nes šių failų paprasčiausiai nėra, tačiau verta suprasti, kodėl šie konkretūs keliai apskritai ieškomi.

/wp-login.php - 273 prašymai, 197 unikalūs IP Tai WordPress administravimo prisijungimo forma. Botai bandydami jėga grubią jėgą (brute force) atakas - automatiškai patikrina tūkstančius naudotojo vardo ir slaptažodžio kombinacijų, tikėdamiesi atspėti galiojantį prieigą. Jei svetainė turi silpnas paroles arba neturi prisijungimo bandymų apribojimo, tokia ataka gali baigtis visu administratoriaus prisieiga.

/xmlrpc.php - 255 prašymai, 183 unikalūs IP Senas WordPress sąsajos failas, naudojamas nuotoliniam publikavimui. Tai populiarus atakų tikslas dėl dviejų priežasčių: jis gali būti naudojamas slaptažodžiams atspėti daug greičiau nei įprastos prisijungimo formos (šimtai kombinacijų viename prašyme), ir jis gali būti piktnaudžiaujamas DDoS stiprinimo atakose prieš trečiąsias šalis per „pingback" funkciją.

/en/wp-json/wp/v2/users/me - 23 prašymai, 21 unikalus IP WordPress REST API galas taškas, kuris pagal numatytuosius nustatymus gali atskleisti galiojančius naudotojo vardus. Pats savaime tai nėra ataka, bet tai yra žvalgymo žingsnis - sužinojus tikruosius naudotojo vardus, užpuoliko gali tiksliau nukreipti tolesnius jėga brukimo bandymus.

/.env - 14 prašymų, 12 unikalūs IP Tai yra vienintelis tikslas mūsų sąraše, kuris turėjo realų žalos potencialą. .env failai paprastai yra duomenų bazės slaptažodžiai, API raktai ir kiti paslapčiai. Jei toks failas yra pasiekiamas iš lauko (dėl netinkamo serverio konfigūracijos), jo turinio nutekėjimas gali reikšti visą sistemos susikompromitavimą - ne tik svetainę, bet ir susijusias paslaugas. Mūsų atveju Next.js šį failą nepatarnauja viešai, todėl visi bandymai baigiasi 404 arba blokavimoklaida.

/lv/wp-content/uploads - 7 prašymai, 7 unikalūs IP WordPress įkėlimo aplankas. Jei jis neteisingai sukonfigūruotas (pavyzdžiui, leidžia vykdyti PHP failus), užpuoliko, kuris jau gavo bent minimalią prieigą, gali įkelti kenksmingą scenarijų ir gauti visą serverio kontrolę.

Kaip veikia mūsų saugumo stebėjimas

Šie duomenys negrįžta iš įprastų serverio žurnalų - juos analizuoja mūsų sukurta AI saugumo sistema, kuri seka visą gaunamą srautą, klasifikuoja kiekvieną įvykį pagal sunkumą ir priima sprendimą dėl blokavimoreal laiku. Sistema yra sujungta su Discord pranešimų kanalu, kuriame du kartus per dieną paskelbtas suvestinis pranešimas - kiek įvykių buvo, kiek užblokuota, ar yra kažko, prie kurio reikėtų atkreipti dėmesį.

Be reguliarių ataskaitų sistema taip pat turi vadinamąjį page call mechanizmą - tiesioginis skubuspaziņojimas kūrimo komandai, kuris aplenkia įprastą du kartus per dieną suvestinį ir perspėja iš karto, kai nutinka kažkas, reikalaujantis neatidėliotinos reakcijos. Skirtingai nuo įprasto triukšmo žurnalo (kur šimtai botų prašymų paprasčiausiai užregistruojami ir tyliai blokuojami), page call yra skirtas retais, tikrai reikšmingais atvejais.

Praktikoje page call atrodo taip: telefone gaunamas tiesioginis skubus skambutis, pranešantis apie įvykį. Šio skambučio negalima atidėti (snooze) - norint jį sustabdyti, reikia kelti ir prisijungti prie sistemos. Kai tik vienas iš komandos narių prisijungia, page call išjungiamas, ir sistema parodo, kas tiksliai prisiėmė incidento šalinimą. Kai problema išsprendžiama, sistema prieš diegimą automatiškai patikrina kodą, klaidas ir pažeidžiamumą - pirmiausia prieš tai patekus mūsų privačiame GitHub saugykloje, tada serveryje ir galiausiai internete (live) svetainėje - siekiant užtikrinti, kad visur yra nuosekli ir pataisyta versija.

Šiuo laikotarpiu šis mechanizmas veikė du kartus:

• Bandymas pasiekti .env failą - kadangi šis failas gali turėti duomenų bazės slaptažodžius ir API raktus, sistema tai klasifikavo kaip aukšto riziko įvykį ir nedelsiant perspėjo komandą, nepaisant to, kad prašymas buvo automatiškai užblokuotas.

• gramatika.evoex.eu nepasiekiamumas - kai šis podomenis tapo neprieinamas, sistema tai atpažino kaip paslaugos nutrūkimą (o ne saugumo incidentą) ir iš karto pranešė komandai, kad galėtų greitai reaguoti ir atkurti paslaugą.

Šis dviejų lygių požiūris - tylus žurnalų apsaugos nustatymas masinio botų triukšmo atveju, bet neatidėliotinas pranešimas retais, tikrai svarbiais atvejais - leidžia kūrimo komandai nesisididinti šimtais nepavojingų skenavimo bandymų, tuo pačiu metu negarantavus, kad tikrai svarbus įvykis liktų nepastebėtas iki kito suplanuoto ataskaitos.

Iš kur kilęs

Didžioji dalis srauto kilusi iš JAV (157), Prancūzijos (52), Jungtinės Karalystės (48), Vietnamo (46), Vokietijos (39), Singapūro (36) ir Indijos (32). User-Agent eilutės buvo suklastos kaip įprasti naršyklės - tipinis botnet ženklas, bandantis atrodyti kaip tikras lankytoja.

Tendencija yra aiškiai mažėjanti

Įvykių skaičius per dieną (07-07 iki 07-15): 148 → 137 → 75 → 61 → 110 → 41 → 38 → 13 → 1.

Kritimas sutampa su 95 IP adresų nuolatinių blokavimų - apsauga veikia tiksliai taip, kaip numatyta.

Išvada

Nebuvo nė vienos sėkmingos atakos, nė vieno duomenų nutekėjimo, nė vienos formos spamdėjimode ar autentifikacijos klaidos. Visi bandymai buvo automatizuoti WordPress skaitytuvai, ieškojantys tikslų, kurių čia nėra. Tai nerodo, kad saugumas yra nereikalingas - priešingai, tai parodo, kad tinkamai sukonfigūruota, ne-WordPress architektūra ir aktyvi IP blokavimas veiksmingai sustabdo net maselinės automatizuotas atakas, kol jos gali pasiekti ką nors vertingo.