Hajautetut palvelunestohyökkäykset nousevat aika ajoin otsikkoihin. Niillä on vaikutusta suoraan meidän arkeen. Verkkopalvelut lakkaavat toimimasta – ja me oletamme nykyään näiden palveluiden olevan käytettävissämme käytännössä ympäri vuorokauden. Palvelunestohyökkäys aiheuttaa useasti poikkeustilan laajalle joukolle ihmisiä, ja siksi se toimii tehokkaasti. Sen lisäksi että itse palvelut lakkaavat toimimasta, aiheuttaa palveluiden epämääräinen toimimattomuus heti yleistä epävarmuutta.
Palvelunestohyökkäyksen kohteeksi joudutaan joko suoraan tai välillisesti. Palvelunestohyökkäys hyökkää yritysten palveluita vastaan, mutta yhä useammin myös yrityksen arvoja vastaan. Kun hyökätään arvoja ja mielipiteitä vastaan, voi kysymyksessä olla suoraan myös poliittinen vaikuttaminen. Poliittinen vaikuttaminen kohdistuu suoraan yhteiskuntaan – välillisesti kaupallisten toimijoiden kautta, mutta myös kohdistettuna suoraan arvokkaina ja tärkeinä pitämiimme instituutioihin.
Riskienhallintaa ja resilienssiä - tylsää mutta todellista
Kun palvelunestohyökkäys kohdistuu organisaatioon, joko suoraan tai välillisesti, ei ole mieltä pohtia syitä miksi niin tapahtuu ja mitä tehtiin väärin. Merkitystä on vain sillä, mitkä riskit toteutuvat. Jos ei ole nähty riskejä, ei tarvitse varautua. Jos on nähty riskejä, pitää varautua. Tietystikin voidaan sanoa, että jos ei ole nähty riskejä, riskianalyysit on tehty laput silmillä.
Kun riskit tunnetaan ja riskejä halutaan pienentää, rakennetaan resilienssiä. Resilienssi rakentuu monesta osasta, mutta tärkeimpinä voidaan pitää kahta kyvykkyyttä – nähdä hyökkäys ja puolustautua hyökkäykseltä. Nämä eivät ole sama asia. Analysoidaan näiden eroja lyhyesti kolmen skenaarion kautta.
Huomautan, että seuraavassa esittelemäni kokoluokat eivät olet Gartner-tason yleismaailmallisia vakiintuneita käsitteitä, vaan minun tapani esittää näiden asioiden suuruusluokkaeroja.
Gigabittiluokka
Kun otsikoidaan palvelunestohyökkäyksestä, on melkein aina kyse volumetrisesta (määrällisestä) hyökkäyksestä. Näissä hyökkäyksissä täytetään yksinkertaisesti kaista niin suurella liikennemäärällä, että mikään ei enää liiku. Hyökkäyksen toteutus ei ole kovinkaan vaikea, ja kustannuksetkin pysyy tänä päivänä hyvin maltillisina. Maltillisuus tietysti pitää peilata hyökkääjän tavoitteisiin. Valtiollisella hyökkääjällä on rajaton budjetti. Sohvalla istuvalla lähiön sankarilla ei tietystikään ole. Toisaalta, myöskin näiden strategiset tavoitteet eroaa merkittävästi – ja siksi myös vastatoimien on oltava erilaiset.
Gigabittiluokan hyökkäykset pysäytetään pesuripalvelulla. Tämä tarkoittaa sitä, että palveluntarjoajan tai teleoperaattorin toimesta hyökkäys pysäytetään ennen kuin liikenne pääsee asiakkaan johtoon asti. Avataan niin sanottu hukkaputki ja valutetaan pahat paketit avoviemäriin. Tämä on tehokasta siksi, että teleoperaattorin kapasiteetti maailmalle päin on poikkeuksetta suurempi kuin teleoperaattorila asiakkaalle päin. Vaikka liikenne edelleen tulee teleoperaatorille ja täyttää teleoperaattorin putket, voidaan asiakkaan omat yhteydet pestä. Pesuripalveluissa on aina tietty raja-arvo, jonka jälkeen peseminen aloitetaan. Pesuripalvelu ei ole mikään taikalaatikko, joka tunnistaa jokaisen yksittäisen paketin hyväksi ja pahaksi. Pesuri profiloi liikennettä, ja raja-arvojen ylittyessä, avaa hukkaputken.
On ymmärrettävää, että tämä toiminta skaalautuu ylöspäin jossain määri rajallisesti. Kun halutaan varautua gigabittiluokan yläpäähän – tai terabititluokkaan, siirrytään jo kyvykkyyksissä ja kustannuksissa eri tasolle. Normaalisti loppuasiakkaat eivät osta näitä kyvykkyyksiä, vaan ne on teleoperaattorien itse itselleenkin varaamia kyvykkyyksiä. Silloin kun koko operaattori (tai valtio) on uhattuna, on tietysti liiketoiminnalliset ja yhteiskunnalliset riskit ja vaikutukset suuria. Kun isoimpia hyökkäyksiä pestään, joudutaan hukkaputkea käyttämään yhä suruttomammin. Tällöin matkalle jää myös oikeita paketteja. Win some, lose some.
Näkyvyyden osalta isoissa hyökkäyksissä teleoperaattoriin kyvykkyys useasti riittää. Perushyökkäyksiä pestään rutiininomaisesti ja asiakkaalle näkyvyys on viikkoraporttitasolla.
Niin kivaa kuin onkin miettiä valtavia hyökkäyksiä, pitää miettiä myös seuraavan tasonriskejä. Mitä jos hyökkäys onkin himpun verran pesurin raja-arvon alapuolella? Kuka tai mikä meidät silloin pelastaa? Mikä silloin voi mennä rikki?
Megabittiluokka
Megabittiluokassa liikenne menee pesurin ohitse. Teleliikenneoperaattori ei siis runkoverkossa tai asiakkaan tietoliikenneyhteydessä pese tässä kohtaa mitään. Jos pesurin raja on asetettu olemaan 10Gbps, pitääkin riskeissä arvoida mitä tapahtuu kun liikennettä tulee seuraaville laitteilla 9Gbps. Tässä vaiheessa katsotaankin yleensä asiakkaan omaa infraa tai sovelluspalveluntarjoajan kyvykkyyksiä. Käytännössä kuormaa vastaanottamassa on palomuuri, kuormantasaus ja sovelluksen front-end palvelimet. Tässä järjestyksessä. Ja kun kyvykkyyksiä arvioidaan, pitää tietysti jokainen komponentti olla erikseen arvioitu sietokyvyltään. Tässä kohtaa sekä palomuuri että kuormantasauslaitteisto voivat mahdollistaa oman palvelunestohyökkäystä vastaan toimivia mekanismeja. On kuitenkin muistettava, että kun johdossa kulkee 9Gbps liikennettä, voi palomuuri suodattaa tästä pois palvelunestohhyökkäykseksi katsottavaa liikennettä, mutta jos johdon paksuus on vain 10Gbps, on johto silti täynnä paketteja. Yhteys on siis todennäköisesti erittäin hidas palomuurille asti, vaikka kuormantasaulaitteistolle asti ei paketteja mene. Sama logiikka pätee tietysti kuormantasaososastolla, jos liikennettä sinne asti päästetään.
Olennaista tässä luokassa on tietää, mihin laitteet kykenevät. Ja asettaa laitteet toimimaan loogisesti oikein – tärkeää on suodattaa oikeassa järjestyksessä oikeita asioita. Ja varmistaa että kaikki asetukset oikeasti toimivat halutulla tavalla. Ja siinä oikeassa järjestyksessä.
Näkyvyyden osalta ollaan megabittiluokassa paljon kriittisemmässä tilanteessa, kuin gigabittiluokassa. Pitää olla näkyvyttä sekä infran komponentteihin että sovellukseen, että sovelluksen takana majaileviin palveluihin – ja mahdollisesti myös kolmannen osapuolen rajapintoihin. Lisäksi näkyvyys on monesti asiakkaan itsensä vastuulla. Tässä pelaavat asiakkaan koordinoinmina yhteen infratoimittaja, käyttöpalvelutoimittaja, pilvitoimittaja, sovellustoimittaja sekä SOC-toimittaja (ja liuta muita toimittajia, tilanteesta riippuen) – sekä mahdollisesti iso joukko sisäisiä yrityksen omia asiantuntijoita, joiden pitää tietää asioista. Mielellään etukäteen. Mitä indikaattoreita tarvitaan, toimiiko hälytykset, toimiiko mittarit oikeassa ja loogisessa järjestyksessä – ja reagoidaanko mihinkään
Kuten ehkä jo käykin ilmi, on megabittiluokassa haasteet hallita kaikkia riskejä ja kokonaisuutta yleensä paljon laaja-alaisemmat kuin isoissa hyökkäyksissä.
Kilobittiluokka
Kilobittiluokassa ei puhuta volumetrisesta hyökkäyksestä. Palvelua saatetaan silti estää. Tähän kategoriaan kuuluvat muun muassa sovellukset, joiden toteutuksessa on merkittäviä suorituskykyongelmia. Tällöin esimerkiksi yhdellä pyynnöllä, voidaan aiheuttaa sekunnin kestävä kuormitustilanne palvelimelle. Sadalla pyynnöllä siis vastaavasti sata sekuntia. Jokainen kotiläppäri pystyy tähän. Itse asiassa siihen tarvitaan vain lukitsematon kone ja kissa. Jos tällä tavoin saadaan sovellus tai sen tietokanta jumiin, ollaan jo tehokkaasti palvelu estetty. Muitakin vaihtoehtoja on – mutta yhteistä kaikille on se, että hyvin pienellä volyymillä (ja vaivalla ja osaamisella), voidaan saavuttaa merkittävää hitautta ja saada palveluiden käyttö hidastumaan tai estettyä kokonaan. Jos penetraatiotestausraporteissa on mainintoja puuttuvista rate-limiteistä, nyt on hyvä hetki katsoa niitäkin havaintoja.
Kilobittiluokassa on usein ongelmana puutteet ohjelmistologiikassa, yllättävät riippuvuudet sovellusten tai sovellusten ja muun infran välillä – tai yksinkertaisesti huonoa koodia.
Kilobittiluokan kyvykkyydet jatkaa siitä, mihin megabittiuokka jää. Itseasiassa, kyse on enemmäkin raja-arvoista kuin uusista kontrolleista ja mittareista tällä tasolla. Mittareiden granulariteetti kasvaa.
No mitäs nyt sitten pitää tehdä
Kun palvelunestohyökkäykset nousevat riskikartalle, resilisenssiä halutaan testata. Yllä olen yrittänyt linjata (jossain kohti tietysti vetänyt linjoja suoriksi – en minäkään tiedä jokaisen teleoperaattorin tai valtion kyvykkyyksistä ja taktiikoista kaikkea) vähän apua siihen, mitä riskejä pitää katsoa. Näistä seuraa kovin erilaisia skenaarioita, joita voi ja pitää testata. Erilaisiin skenaarioihin ja tavoitteisiin päästään vähän eri menetelmillä. Menetelmillä on tietysti hintansa, kuten kaikella. Palvelunestohyökkäysten resilisenssin testaamisessa ei ole yhtä one size fits all -menetelmää.
Kun palvelunestohyökkäykset nousevat riskikartalle, asialle voidaan tehdään jotain ja sille voidaan tehdä jotain yhdessä.
