Uudised, sündmused ja blogi

RIPE 73: Osa 2 - anycast

Anycast on saamas registrite hulgas standardiks ja levib üha enam ka registripidajate ja domeeni omanike hulgas. Anycasti tehakse selleks, et suurendada DNS teenuse töökindlust, aga ka vähendada viivet kasutaja ja interneti teenuse vahel tuues nimeserveri talle lähemale. See on nimeserverite pilv, mis vastab ühe jagatud interneti aadressi alt ning kavalad marsruutingu programmid suunavad kasutaja lähima või kiireimini vastava nimeserverini. Siit küsimus, kui palju nimeservereid ühes pilves on piisav?

Juurnimeservereid teenindavate anycastide peal läbiviidud analüüs näitas, et süsteem toimib väga hästi - päringutele saadakse vastus keskmiselt 32ms ükskõik millisest maailma otsast. Võrreldes erinevaid juurnimeservereid omavahel - K root 8 serveriga ja L root 144 serveriga - selgus, et nende vahe on praktiliselt olematu. Kus on optimum? Lähem uurimine näitas, et tulemused on regionaalselt siiski väga erinevad ja selles vaates oli selgelt näha, et suurem hulk hästi jaotatud nimeservereid on suureks abiks. Järeldus - anycasti teenuse kvaliteedi puhul on nimeserverite arvust olulisem võimalikult hea jaotus üle maailma.

Korralikult toimiva anycast teenuse võtmekohaks on sellega seotud marsruutingu poliitika - kuidas leiab kasutaja süsteem enda vaatenurgast parima nimeserveri. Ühtset head tava või standardit siin kahjuks pole, mistõttu on poliitikad väga erinevad, andes erinevate teenuste puhul väga erinevaid tulemusi. Lisaks on marsruutingu poliitikad enamasti staatilised, st süsteem ei suuda kohanduda oluliste muudatustega võrgus. Näiteks ründe korral kasutajale lähima nimeserveri pihta ei suunata kasutajat ümber paremat kiirust pakkuva järgmise nimeserveri juurde. Olgugi, et anycasti püsti panemine on suhteliselt lihtne, on selle korrektne seadistamine ja haldus väga oluline. Lihtsalt ühe nimeserveri lisamine pilve võib tekitada hoopis olulise teenuse kiiruse languse.

2015. aastal toimus rünne juurnimeserverite vastu. Kuidas nö etalon anycast lahendused, mis teenindavad DNS juurnimeservereid, sellega hakkama said? DDoS on kasvav probleem. Viimastel aastatel on DDoS rünnete suurus kasvanud kordades (35Gb/s oli suurim registreeritud rünne 2005 aastal vs terabitid 2016). Sellele aitab kaasa asjade internet (IoT) oma halvasti turvatud, disainitud või korrektselt seadistamata seadmetega - kodused marsruuterid, külmkapid, televiisorid, võrku ühendatud kaamerad jne. Juurnimeserverite kättesaadavuse analüüs rünnete ajal andis väga erinevaid tulemusi mõju osas - kas teenus muutus lihtsalt aeglasemaks või oli täiesti kättesaamatu. Analüüs näitas, et kuigi erinevad nimeserverid andsid erinevaid tulemusi on üldpilt päris hea - kui konkreetne nimeserver ei saanud koormusega enam hakkama, suunati liiklus ümber mujale. Ses mõttes on põhjuse neist teenustest ja teenusepakkujatest õppust võtta.

Kuid kas anycast kõigile on ikka hea mõte? Anycasti plussidest, nagu parem kättesaadavus ja kiirem teenus, oli juba juttu, lisada võib veel kõrgema tsooni kvaliteedi - professionaalsed pakkujad valideerivad tsoonifaile enne kui neid avaldavad ja see parandab kvaliteeti tunduvalt. Küll aga on ka rida miinuseid - DNS maailm on üldiselt avatud lähtekoodi põhine. Anycast teenuse pakkujad on aga omavahel konkurentsis ja tendents liigub pigem kinnistele lahendustele, sest kuidagi peab üksteisest erinema. Et anycast oleks odav ja kättesaadav, peab olema palju kliente. Maailma jääb paljude väikeset asemel pigem vähe väga suuri. Kurikaelad võtavad sellisel juhul ühe Dyn-i asemel ette näiteks kolm suurimat korraga ja suudavad teha sellega väga ulatusliku kahju. Eks elu näitab.

Hüpates korraks tagasi DDoSi juurde võiks ka küsida, et miks üldse rünnatakse? Põhjuseid võib olla mitmeid - konkurents, väljapressimine, häktivism (fame ja sull), mingi muu tegevuse varjamiseks, riiklikud tegevused. Aga mis kõige kurvem - rünnata on palju odavam kui kaitsta. Täna saab u 50$ kuus rentida sisuliselt piiramatus mahus 10-12Gb/s ründevõimekusega botneti, kuid on ka tasuta alternatiive. Lihtsustatult näiteks väljapressimise majandust vaadates, on pilt ründaja poolt $30 otsest kulu tunnis, väljapressitud rahasumma on keskmiselt $8000 ja teenitud feim on hindamatu. Ohvri poolt vaadates tähendab see tootlikkuse langust, usaldusväärsuse ja klientide kaotust.

Nii jõuamegi Mirai juurde. See on avatud lähtekoodil põhinev ründevõrgustik, mis kasutab ära asjade interneti seadmete nõrkuseid, et nende abil rünnata keda iganes. Sellega võeti oktoobris maha Dyn - nimeserveri teenuse pakkuja, kes teenindab teiste hulgas ka näiteks Facebooki ja Twitterit. Mirai võrgus on enam kui 300 000 seadet, mis on veidi vähem kui tippajal suvel, kuid pahavara levib jätkuvalt edasi. Mirai kasutab IoT seadmete nõrkuseid - paljudel on tehase seadetes muutmata paroolid, osadel koguni ei saagi seda muuta. Lahendust sellele probleemile pole näha ja see tõttu peame jätkama suuremate müüride ja uhkemate anycasti laadsete pilvelahenduste arendamist.

Tänaste massiivsete rünnete valguses on põnev jälgida EU tegevust, kus tegeletakse liikmesriikide kohustuse küsimustega küberohtudega võitluses. Silmas peetakse eelkõige riikide ja EU seisukohast kriitilisi taristu lahendusi. Hoolsuskohustus (due dilligence) antud juhul ei tähenda muidugi rünnete vältimist, vaid selleks kõikvõimaliku tegemist. Kuidas aga kriitilist IT-taristut tuvastada? Selleks ei ole ju ainult konkreetne infosüsteem, selleks võib olla ka mingi laialt kasutatav vabavaraline tarkvara, mille viga või turvaauk võib seada ohtu väga kriitilised süsteemid.

Selgus ka, et EUl on olemas 5G mobiilside tegevusplaan. Selle järgi on 5G juurutatud üle terve EU aastaks 2025. Koordineeritud 5G juurutamise tegevusplaan saab oma lähte 2020 aastal. Aga töö osaliselt juba käib ning esimesed 5G väljalasked on plaanis 2018 Olümpiaks.

Kas kasutajal on võimalik kontrollida, kuidas tema interneti liiklust marsruuditakse - kas on võimalik vältida teatud riike ja kas on võimalik hoida kohalik liiklus kohalikuna? Näiteks erinevate isikuandmete ja jälgimise poliitikate tõttu võib olla soov vältida USA, Venemaa või Hiina võrke. Analüüs näitas, et olenemata kasutaja asukohast käib suur osa liiklusest läbi USA. Põhjuseks paljude populaarseteste teenuste paiknemine USAs. Samal ajal on aga ka märkimisväärne osa USAd mitte puutuvast liiklusest sealt läbi suunatud. See on riigiti erinev - Euroopas liigub suur osa liiklust USA asemel läbi UK. Näiteks käib ka Brasiilia kohalik liiklus suuresti läbi USA hoolimata sellest, et Brasiilia on riiklikult näinud palju vaeva, et sellist olukorda likvideerida. Kas internetikasutaja ise saab sellise marsruudi vältimiseks midagi teha? Alati mitte. Katsetus proksi serveritega näitas, et teatud riike on võimalik vältida ja teiste puhul vähendada tõenäosust liikluse sinna suundumiseks, kuid näiteks USAd on praktiliselt võimatu lõpuni vältida - kasuta missugust vaheserverit (proxy) tahes. Internetis puuduvad tegelikkuses riigipiirid, ISPd tegutsevad mitmes riigis ja puuduvad riiklikud marsruutingu poliitikad. Seega on siia sisse ehitatud konflikt, sest jälgimispoliitikad samal ajal on riiklikud.

Saalis tekkis selle esitluse peale kõva arutelu, kus ühel pool olid need, kes ei näinud uuringus mingit mõtet tingituna Interneti olemusest ja ülesehitusest. Teisel pool olid need, kes tunnetasid hästi probleemi. Ning vahepeal olid veel ka need, kes tuvastasid uuringumetoodikas auke - näiteks on traceroute suhteliselt kõrge taseme viis selliseks uuringuks ja ei anna ülevaadet madalal võrgutasemel toimuvast - kust reaalselt see fiiber jookseb ja mis seadmed teepeale jäävad. Kõik need punktid võimaldavad potentsiaalselt liiklust pealt kuulata ja analüüsida.

Huvitava esitluse tegi Facebook - kuidas nii mahuka teenuse puhul on lahendatud teenuse kiiruse ja ligipääsetavuse küsimused. Ei ole mõeldav, et kogu andmestik on ühes USA serveris, sest aeg ühenduse loomiseks ja andmete kätte saamiseks kasvab väga pikaks juba ainuüksi https käepigistuse tõttu - nii saab 100 ms pingist 0,5 sekundiline viive. See tõttu on vajalik viia andmed kasutajatele lähemale. Kuid see pole lihtne, sest Facebookis on lisaks staatilisele pildiinfole ka palju dünaamilist - meeldimised, oleku teated ning nüüd üha rohkem ka mahukas videomaterial. Tuleb ju tagada, et info oleks kopeeritud kõikidesse maailma punktidese sisuliselt silmapilkselt. Lisaks on vajalik ka ümber marsruutimise lahendused, sest lähim server võib olla ülekoormatud ja teatud punktist alates on parem kasutaja suunata mõne kaugema punkti peale (a’la anycast). Õppetund, mille Facebook seda ülesannet lahendades sai ja nüüd ka teistega jagas oli - hoia asju lihtsana - eelkõige tuleks proovida probleeme lahendada juba kasutuses olevate laialt levinud vahenditega ja vältida uute keerukate lahenduste leiutamist. Facebook proovis ja kõrvetas näppu.

Sellega vast ongi hea see pikk ülevaade lõpetada. Kel huvi suurem siis RIPE lehel leiab pea kõigi esitluste slaidid, ärakirjad ja videosalvestused.