616 rünnak käigus 8 päevaga

Tegelikke rünnakuid pole olnud. Kõik 616 välistest turvalisuse juhuseid, mis registreeriti 7.–15. juulist, osutusid automaatsete botide loodud mürana – skännerid, mis massiliselt kontrollivad tuhandeid veebisaite, otsides teadaolevaid WordPress-i haavatavusi. Meie veebisait ei ole ehitatud WordPress-ile, mistõttu otsitud teed kunagi ei eksisteerinud ja iga katse lõppes blokeeringuga või 404 veaga.

Numbrid

Mida täpselt otsiti – ja miks see on ohutus kaitstud veebisaidele

Allpool esitatud teed on klassikalised WordPress-i sihtmärgid. Meie puhul olid need kahjutud, kuna neid faile lihtsalt ei eksisteeri, kuid tasub mõista, miks neid konkreetseid teid üldse otsitakse.

/wp-login.php – 273 päringut, 197 kordumatul IP-aadressil See on WordPress-i haldurite sisselogimise vorm. Botid üritavad vägivallatseid jõumeetodeid (brute force) – kontrollivad automaatselt tuhandeid kasutajanime ja parooliga kombinatsiooni, lootuses arvata ära kehtiv juurdepääs. Kui veebisaidel on nõrgad paroolid või puudub sisselogimise katsetel piir, võib selline rünnak lõppeda täieliku administraatori juurdepääsuga.

/xmlrpc.php – 255 päringut, 183 kordumatul IP-aadressil Vana WordPress-i liidese fail, mida kasutatakse kaugtegevusele avaldamiseks. See on populaarne rünnaku sihtmärk kahel põhjusel: seda saab kasutada paroolide arvamiseks palju kiiremini kui tavalist sisselogimisvormi (sadad kombinatsioonid ühes päringus), ja seda saab kuritarvitada DDoS-i võimendusrünnetes kolmandate osapoolte vastu "pingback" funktsiooni kaudu.

/en/wp-json/wp/v2/users/me – 23 päringut, 21 kordumatul IP-aadressil WordPress-i REST API lõpp-punkt, mis vaikimisi võib paljastada kehtivad kasutajanimed. Iseenesest see ei ole rünnak, kuid see on luure samm – teades tõelisi kasutajanime, võib ründaja järgmisi jõumeetodeid sihtotstarbelisemalt suunata.

/.env – 14 päringut, 12 kordumatul IP-aadressil See on ainus meie nimekirjas olev sihtmärk, millel oli reaalse kahju potentsiaal. .env failid sisaldavad tavaliselt andmebaasi paroole, API võtmeid ja muud saladusi. Kui selline fail on väljastpoolt kättesaadav (valesti serveri seadistuse tõttu), võib selle sisu lekkimine tähendada täielikku süsteemi kompromiteerimist – mitte ainult veebisaiti, vaid ka seotud teenuseid. Meie puhul ei jaga Next.js seda faili avalikult, seega kõik katse lõppesid 404 või blokeeringuga.

/lv/wp-content/uploads – 7 päringut, 7 kordumatul IP-aadressil WordPress-i üleslaadimiste kaust. Kui see on valesti konfigureeritud (nt lubab PHP failide täitmist), võib ründaja, kellel on juba vähemalt minimaalne juurdepääs, laadida üles pahatahtlikku skripti ja saada täieliku kontrolli serveri üle.

Kuidas töötab meie turvalisuse jälgimine

Need andmed ei tule tavalistest serveri logidest – neid analüüsib meie arendatud tehisintellekti turvalisuse süsteem, mis jälgib kogu sissetulevat liiklust, klassifitseerib iga juhtumi kaalumisastme järgi ja teeb otsuseid blokeerimise kohta reaalajas. Süsteem on ühendatud Discord-i teatiste kanaliga, kus kaks korda päevas avalikustatakse kokkuvõtlik aruanne – kui palju juhtuseid oli, kui palju blokeeriti, kas on midagi, millele tähelepanu pöörata.

Tavapäraste aruannete kõrval on süsteemil ka nn page call mehhanism – otsene kiire teatis arendusteamile, mis möödub tavapärasest kahekordses päevasest kokkuvõttest ja hoiatab kohe, kui midagi juhtub, mis nõuab viivitamatut reageeringut. Erinevalt tavalisest mürase logist (kus sadad boti päringud lihtsalt registreeritakse ja blokeeritakse vaikselt), on page call reserveeritud haruldaste, tõeliselt oluliste juhtumite jaoks.

Praktikas näeb page call välja nii: telefonil saadakse otsene kiire kõne, mis teavitab juhtunust. Seda kõnet ei saa edasi lükata (snooze) – selle peatamiseks peate üles tõusma ja süsteemiga ühenduma. Niipea, kui keegi meeskonnast on ühendunud, lülitub page call välja ja süsteem näitab, kes tegelikult intsidentiga tegeleb. Kui probleem on lahendatud, kontrollib süsteem automaatselt koodi, vigu ja haavatavusi enne käivitamist – esiteks enne, kui see jõuab meie privaatesse GitHub repositooriumisse, seejärel serverisse ja lõpuks otse-eeteerisse (live) veebisaidele –, et tagada, et igal pool on järjepidev ja fikseeritud versioon.

Viimasel ajal on see mehhanism toiminud kaks korda:

• Katse pääseda juurde .env failile – kuna see fail võib sisaldada andmebaasi paroole ja API võtmeid, klassifitseeris süsteem selle kõrge riskiga juhtumiks ja hoiatas kohe meeskonda, hoolimata asjaolust, et päring blokeeriti automaatselt.

• gramatika.evoex.eu kättesaamatavus – kui see alamdomeen muutus kättesaamatuks, tundis süsteem seda ära kui töökatkestu (mitte turvalisuse intsidendiks) ja hoiatas kohe meeskonda, et nad saaksid kiiresti reageerida ja teenuse taastada.

See kahetasandiline lähenemine – vaikne logimine massiliste boti müra korral, kuid silmapilkne teatis haruldaste, tõeliselt oluliste juhtumite puhul – võimaldab arendusteamil mitte keskenduda sadadele kahjututele skeneerimiskatsele, samaaegselt tagades, et tõeliselt oluline juhtum ei jääks märkamatuks kuni järgmisele plaanilisele aruandele.

Päritolu

Suurem osa liiklusest tuli USA-st (157), Prantsusmaalt (52), Suurbritanniast (48), Vietnamist (46), Saksamaalt (39), Singapurist (36) ja Indiast (32). User-Agent stringid olid võltsitud tavapärasete brauseritena – tüüpiline botneti tunnus, mis üritab välja näha nagu tegelik külastaja.

Trend on selgelt kahanev

Juhtumite arv päevade kaupa (07-07 kuni 07-15): 148 → 137 → 75 → 61 → 110 → 41 → 38 → 13 → 1.

Kukkumine ühtib 95 IP-aadressi püsiva blokeerimisega – kaitse töötab täpselt nii, nagu ette nähtud.

Järeldus

Edukat rünnakut, andmete lekkimist, vormi-rämpsu või autentimisvigu pole olnud. Kõik katsed olid automatiseeritud WordPress skännerid, kes otsisid sihtmärke, keda siin ei ole. See ei näita, et turvalisus on tarbetu – vastupidi, näitab, et õigesti konfigureeritud, mitte-WordPress arhitektuur ja aktiivne IP-aadresside blokeerimine tõhusat hoida isegi massilisi automatiseeritud rünnakuid enne, kui need võivad millestki väärtuslikule jõuda.