Nimipalvelut paineen alla

Pertti Hämäläinen • Piirros: Petri Rotsten

Nimipalvelut paineen alla

Maailmanverkon perusinfrasta löytyy jatkuvasti uusia vikoja, koska vanhojen palveluiden paikkailu on helpompaa kuin iso kertaremontti.

Internetin dns-nimipalvelu (domain name service) täytti äskettäin 25 vuotta. Etelä-Kalifornian yliopiston tutkija Paul Mockapetris kollegoineen sai ensimmäiset prototyyppiohjelmansa toimimaan 23.6.1983. Vanhan ja koetellun järjestelmän perusteista löytyy kuitenkin edelleen aukkoja.

Tämän vuoden kesän suuri uutinen oli tietoturvatutkija Dan Kaminskyn dns-palvelusta löytämä vakava haavoittuvuus, jonka paikkaamisessa on ollut täysi työ. Ongelma koski itse dns-käytännön perusmäärityksiä, eikä kyse ollut minkään yksittäisen ohjelmistotalon töpeksinnästä.

Dns on netin ytimessä

Dns kuuluu niihin verkon peruspalveluihin, joiden pohtimiseen useimmat verkon pääkäyttäjät, tavallisista nettisurfailijoista puhumattakaan, eivät haluaisi uhrata yhtään ylimääräistä hetkeä. Parempi olisi uhrata, sillä ilman nimipalvelua mikään ei toimi.

Nimipalveluhan on se sisäisen humanistimme paras ystävä, jonka ansiosta ei tarvitse muistaa Tietokone-lehden web-palvelun ip-osoitteen olevan 62.78.223.16 vaan voi kirjoittaa selaimen url-riville yksinkertaisesti www.tietokone.fi.

Ennen nimipalvelun keksimistä nämä kytkennät tallennettiin staattisina taulukkoina tietokoneiden hosts-tiedostoihin. Koska taulukoiden ylläpito käsityönä kävi verkon kasvaessa pian mahdottomaksi, piti keksiä keino jaella tiedot ja muutokset netin käyttäjille automaattisesti.

Dns on hierarkkinen, hajautettu tietokanta, jota ylläpitävät Internetiin liittyneiden organisaatioiden verkkovastaavat. Vastuut ilmenevät suoraan verkkonimistä: esimerkiksi yritys.fi-loppuiset verkkonimet kuuluvat suomalaisen Yrityksen verkkovastaavan tontille. Hän huolehtii siitä, että Yrityksen nimipalvelimessa on oikeat ip-osoitteet esimerkiksi palvelimille www.yritys.fi ja mail.yritys.fi.

Kun web-selain tai jokin muu työasemaohjelma tarvitsee jotakin url-osoitetta vastaavan ip-osoitteen, se kysyy sitä lähimmältä nimipalvelimelta. Nimipalvelimen osoite puolestaan on tallennettu työaseman verkkosovittimen asetuksiin. Varmuuden vuoksi nimipalvelimia voi määritellä useita, jolloin kysely lähetetään vaihtoehtoiselle palvelimelle, jos ensimmäinen nimipalvelin ei vastaa.

Oikea osoite monen mutkan kautta

Kunkin organisaation nimipalvelimella on täysi valta ja vastuu huolehtia organisaation omien palvelinten osoitteista. Internetin osoitteet se taas löytää muiden nimipalvelinten avulla.

Osoitehierarkian määrittelevät pisteillä erotettujen verkkonimien osat oikealta lukien. Hierarkian ylimmällä tasolla ovat juurinimipalvelimet, jotka vastaavat pistetasosta eli tuntevat vain ja ainoastaan ylimmän tason nimipalvelimet: .com, .net, .fi ja niin edelleen. Nämä puolestaan löytävät organisaatiotason nimipalvelimet. Itse asiassa hierarkiassa voi olla miten monta tasoa tahansa, kunhan verkkotunnus vain ei kasva liian pitkäksi.

Kun yritys.fi:n nimipalvelimelta kysytään vaikkapa www.firma.ru:n ip-osoitetta, se kysyy ensin juurinimipalvelimelta .ru-tason nimipalvelimen osoitteen. Tämä tietää vain seuraavan tason osoitteet, ja palauttaa vastauksena firma.ru:sta vastaavan nimipalvelimen osoitteen. Seuraava kysely lähtee tälle nimipalvelimelle, jolta sitten löytyy itse web-palvelimen osoite.

Jos jokainen ip-osoite selvitettäisiin aina tällä tavalla, osoitekyselyt rassaisivat Internetiä aika lailla. Kuormituksen keventämiseksi työasemaohjelmat ja nimipalvelimet tallentavat saamansa vastaukset välimuisteihinsa. Toisaalta ip-osoitteet muuttuvat kaiken aikaa, kun palveluita siirretään koneesta toiseen. Tämän vuoksi kyselyt uudistetaan osoitekohtaisen ttl-vakion (time to live eli elinaika, yleensä muutamasta minuutista päiviin) umpeuduttua.

Muutakin kuin verkkonimiä

Edellä kuvattu hajautettu ja dynaaminen tietokanta on osoittautunut käytännössä erittäin toimivaksi. Harva Internetin palvelu onkaan säilynyt yhtä pitkään yhtä muuttumattomana kuin dns.

Vuosien varrella dns:n vastuualue on pikkuhiljaa laajentunut, ja verkkonimien ohella se pitää sisällään jo monia muitakin tietotyyppejä.

Esimerkiksi sähköposti ei toimisi ilman dns:ää, koska postinvälityspalvelinten tiedot ovat dns-kannassa. Enum-hankkeessa dns-kantaan on puolestaan viety puhelinnumeroita Internet-puhelinpalveluita varten, ja yritysten sisällä Windowsin aktiivihakemisto hyödyntää dns:ää.

Keskeisen asemansa vuoksi nimipalvelu on houkutteleva kohde tietovarkaille. Jos dns palauttaisi yrityksen verkko-osoitteen sijasta hyökkääjän oman palvelimen osoitteen (niin sanottu pharming-hyökkäys), esimerkiksi erilaisten tunnustietojen kalastelu kävisi kovin helpoksi.

Välimuisti hyökkäyskohteena

Vuosien mittaan dns-toteutuksista on löydetty useita erilaisia haavoittuvuuksia, joita hyödyntämällä hyökkääjät voivat ujuttaa nimipalvelinten välimuisteihin omia tietojaan. Haavoittuvuustyypistä käytetään nimitystä DNS Cache Poisoning.

Tietoturvatutkija Kaminskyn tämän vuoden keväällä löytämä haavoittuvuus perustui siihen, että dns-kyselyihin voi vastata periaatteessa kuka hyvänsä. Missään ei pidetä kirjaa laillisista nimipalvelimista, joten hyökkääjä voi pahimmillaan ujuttaa oman dns-palvelimensa osoitteen vastaukseksi johonkin kohtaan dns-kyselyketjua.

Dns-palvelu tunnistaa kyselyt 16-bittisen satunnaisen id-numeron avulla. Hyökkääjä voi lähettää vastauksia nimipalvelukyselyyn peräkkäisillä id-numeroilla mielivaltaisen määrän, ja nimipalvelin vain hylkää tuntemattomalla id:llä saapuvat vastaukset. Jos oikea id osuu sarjaan ennen kuin todellinen dns-palvelin ehtii vastata, hyökkääjän tarjoama tieto tallentuu välimuistiin ttl-vakionsa mittaiseksi ajaksi. Todellinen vastaus hylkäytyy aikanaan, koska se ei ole enää vastaus mihinkään avoimeen kysymykseen.

Hyökkääjän ongelmaksi jää saada kohteena oleva nimipalvelin esittämään haluttu kysely. Tähän Kaminsky esitteli elokuun Blackhat-tietoturvakonferenssissa lukuisia skenaarioita.

Pikakorjauksena dns-palvelinten valmistajat satunnaistivat kyselyn id:n lisäksi myös kyselyjen käyttämän udp-portin. Tällä tavoin onnistuttiin kasvattamaan hyökkäykseen tarvittavien vastausten määrää usealla kertaluokalla.

Korjaukset osuivat pahaan saumaan kesälomakaudella, mutta ohjelmapäivitysten ajamisessa ei saisi viivytellä. Verkkovastaavien tulisi myös reagoida yhtäkkisiin piikkeihin nimipalvelimilleen saapuvassa liikenteessä ja suodattaa verkostaan väärennetyillä lähdeosoitteilla saapuvat paketit.

Turvallisemmat tunnukset eivät innosta

Ohjelmat kannattaa paikata, mutta nimipalvelinten välimuistihyökkäyksille on kehitetty tepsivä vastalääke jo kymmenen vuotta sitten. Dnssec (Dns security extensions, uusin versio RFC 4033 – 4035 vuodelta 2004) allekirjoittaa dns-tiedot julkisen avaimen menetelmällä. Hyökkääjä ei pysty väärentämään vastauksia, jos kyselyn esittäjä edellyttää niiden olevan allekirjoitettuja.

Dnssecin käyttöönotto vaatii kuitenkin kahta isoa asiaa. Ensinnäkin Internetin verkkotunnusten haltijoiden on allekirjoitettava omat verkkotunnuksensa. Toiseksi dns-ohjelmistojen niin palvelimissa, verkkolaitteissa kuin työasemissakin pitää tukea dnssec-määrityksiä. Ollaan klassisen muna-kana-ongelman edessä: kumpikaan osapuoli ei ole halukas hoitamaan omaa osuuttaan ilman varmuutta toisen samanaikaisesta sitoutumisesta.

Toistaiseksi ylimmän tason verkkotunnuksia on allekirjoitettu vasta muutamia. Edelläkävijämaita ovat Ruotsi, Brasilia, Puerto Rico sekä Bulgaria, jotka allekirjoittivat maatunnuksensa jo viime vuonna. Kesäkuussa ICANNissa tehtiin päätös .org:n allekirjoittamisesta.

Juurinimipalvelinten yleiseen dnssec-tukeen on vielä pitkä matka; kehitystä hidastavat sekä poliittiset erimielisyydet että kustannukset. Allekirjoitus- ja varmennejärjestelmän on arvioitu kuormittavan nimipalvelininfraa jopa kymmenkertaisesti nykyiseen versioon nähden.

Ohjelmistoyhtiöt ovat olleet vielä vastahakoisempia. Infoblox-yhtiön tekemän tutkimuksen mukaan alle prosentti dns-palvelimista käytti viime vuonna dnsseciä. Esimerkiksi Microsoftin Windows Server 2008 tukee vasta dnssecin vanhempaa RFC 2535 -versiota, eikä Vistasta löydy minkäänlaista tukea turvalliselle dns:lle.

Palvelimen ylläpitäjän olisi toistaiseksi varminta suojata palvelunsa DNS-palvelun turva-aukkoja vastaan käyttämällä SSL-varmenteita. Käyttäjä puolestaan voi vain toivoa parasta.