DDoS atakos: kas tai ir kaip nuo jų apsaugoti instituciją

2022–2024 m. Lietuvos viešojo sektoriaus svetainės ne kartą tapo masinių DDoS atakų taikiniu — nuo Seimo iki savivaldybių ir energetikos sektoriaus puslapių. NKSC ataskaitos rodo, kad DDoS yra viena dažniausių kibernetinių grėsmių valstybės informaciniams ištekliams, o dėl geopolitinės situacijos atakų intensyvumas neatslūgsta. Institucijos vadovui tai reiškia vieną dalyką: klausimas ne „ar“, o „kada“ ataka pasieks jūsų infrastruktūrą.

Kas yra DDoS ataka

DDoS (Distributed Denial of Service) — paskirstyto paslaugos trikdymo ataka, kai užpuolikas iš daugybės užkrėstų įrenginių (botneto) vienu metu siunčia užklausas į taikinį, kol serveris arba tinklo kanalas nebepajėgia aptarnauti teisėtų vartotojų. Skirtingai nei duomenų vagystės ataka, DDoS netaiko duomenų bazės — ji siekia padaryti paslaugą nepasiekiamą.

Atakos skirstomos į tris pagrindinius tipus pagal OSI lygmenį:

• Tūrinės (volumetric) — užtvindo tinklo pralaidumą UDP, ICMP ar DNS amplifikacijos srautu. Dydžiai matuojami Gbps arba Tbps.
• Protokolo — išnaudoja TCP/IP silpnybes (SYN flood, Ping of Death), išsemia serverio jungčių lentelę.
• Aplikacijos (L7) — imituoja teisėtus HTTP/HTTPS užklausimus, pvz., daug kartų kreipiasi į paieškos formą ar prisijungimo langą. Sunkiausiai aptinkamos, nes srautas atrodo „normalus“.

Kodėl viešasis sektorius — patrauklus taikinys

Valstybės institucijų svetainės dažnai turi politinę vertę užpuolikams: jų sutrikdymas matomas viešai ir per žiniasklaidą sukelia rezonansą. Be to, dalis institucijų vis dar laiko svetaines vidinėje infrastruktūroje su ribotu pralaidumu, be CDN ar specializuotos DDoS filtravimo paslaugos. Net trumpalaikis e. paslaugų neveikimas (mokesčiai, pažymos, registrai) reiškia tiesioginį poveikį gyventojams ir prarastą pasitikėjimą.

Pažymėtina, kad DDoS atakos dažnai naudojamos kaip „dūmų uždanga“ — kol IT komanda gesina srauto bangą, paraleliai gali būti vykdomi įsibrovimo bandymai į kitas sistemas.

Techninės apsaugos priemonės

Veiksminga DDoS apsauga remiasi sluoksniuotu modeliu — viena priemonė problemos neišspręs:

• CDN ir reverse proxy su DDoS filtru (pvz., Cloudflare, Akamai, AWS Shield) — paslaugos teikėjas perima srautą savo tinkle dar prieš jam pasiekiant institucijos serverius. Tai standartas viešoms svetainėms.
• Rate limiting aplikacijos lygmenyje — riboti užklausų skaičių iš vieno IP ar sesijos per laiko vienetą.
• WAF (Web Application Firewall) — filtruoja L7 atakas pagal elgsenos taisykles ir žinomus atakų šablonus.
• Anycast DNS — paskirsto DNS užklausas tarp daugelio mazgų, kad pats DNS netaptų atakos auka.
• Autoscaling arba rezervinis pralaidumas — galimybė trumpam padidinti pajėgumus, jei naudojamas debesų teikėjas.
• Geo-filtravimas — esant didelei rizikai, blokuoti srautą iš regionų, iš kurių institucijos paslaugos paprastai nenaudojamos.

Organizacinės priemonės ir reagavimas

Techninės priemonės be procesų neveiks. Institucija turi turėti aiškų reagavimo į DDoS scenarijų, kuris yra incidentų valdymo plano dalis. Pagal kibernetinio saugumo reikalavimus valstybės informaciniams ištekliams ir ypatingos svarbos informacinei infrastruktūrai, apie reikšmingus incidentus privaloma pranešti NKSC.

Plane turi būti aprašyta: kas priima sprendimą įjungti „atakos režimą“ (pvz., agresyvesnį filtravimą, captcha visiems lankytojams), kaip komunikuojama su visuomene, kaip informuojamas paslaugų teikėjas, kokie kontaktai pas hostingo ir CDN tiekėją galioja po darbo valandų. Pratybos bent kartą per metus padeda išvengti panikos realios atakos metu.

Pirkimo ir sutarčių aspektas

Vykdant svetainės ar e. paslaugų pirkimą, DDoS apsaugos reikalavimai turi būti įrašyti į technines specifikacijas — ne kaip „pageidautina“, o kaip privaloma sąlyga. Verta nurodyti minimalų filtruojamą srauto dydį (Gbps), SLA reagavimo laiką, ataskaitų teikimą po incidento. Jei svetainę prižiūri rangovas, sutartyje turi būti aiškiai paskirstyta atsakomybė: kas stebi srautą 24/7, kas turi teisę keisti filtravimo taisykles, kokios kompensacijos numatytos už paslaugos neveikimą dėl rangovo aplaidumo.

Praktinis žingsnis

• Patikrinkite, ar institucijos viešos svetainės yra už CDN/DDoS filtro paslaugos (ne tik pas hostingo teikėją).
• Įsitikinkite, kad serverio realus IP adresas nėra viešai matomas DNS įrašuose ar senuose duomenų archyvuose.
• Įdiekite WAF ir rate limiting bent autentifikacijos, paieškos ir formų galinukuose.
• Parenkite incidento reagavimo planą su konkrečiais vaidmenimis, kontaktais ir sprendimų priėmimo grandine.
• Susitarkite su hostingo/CDN teikėju dėl 24/7 kontakto ir eskalavimo procedūros.
• Atlikite DDoS imitacines pratybas — bent „stalo“ scenarijų komandai.
• Pirkimo specifikacijose įtvirtinkite konkrečius DDoS apsaugos reikalavimus ir SLA.
• Užtikrinkite, kad incidentų stebėsenos žurnalai būtų saugomi ne tame pačiame serveryje, kurį gali užvaldyti ataka.
• Numatykite atsarginį komunikacijos kanalą (pvz., socialinis tinklas, alternatyvus subdomenas), jei pagrindinė svetainė nepasiekiama.
• Reikšmingo incidento atveju nedelsdami praneškite NKSC.