Kampusverkko: IPv6 ja palomuuraus

Tämä sivu sisältää:

Tunniste	Funetin Parhaat käytännöt -dokumentti
Versio	1.0
Tila	valmis
Päiväys	25.3.2015
Otsikko	Kampusverkko: IPv6 ja palomuuraus
Työryhmä	AccessFunet
Laatijat	Ville Mattila/CSC, Tuukka Vainio/Turun yliopisto, Jani Myyry/CSC, Jari Miettinen/CSC, Janne Oksanen/CSC, Kaisa Haapala/CSC
Vastuutaho	Kaisa Haapala/CSC
Tyyppi	suositus

GN3 Kampus-projektissa julkaistu englanninkielinen versio.

Johdanto

Palomuureja käytetään yleisesti erottamaan erilaisia verkkoja. Tarkoituksena on haitallisen tai virheellisen liikenteen suodattaminen jo ennen sen pääsyä kohteeseen. Kampusverkoissa on usein palomuuri verkon ulkoreunalla ja joskus lisäksi muita palomuureja verkon eri osissa. Kampusverkkojen IPv6-siirtymää suunniteltaessa yhtenä alkuvaiheen tehtävänä on selvittää olemassaolevan verkkoinfrastruktuurin IPv6-valmius. Erityisesti palomuurien osalta IPv6-tuessa voi olla puutteita, jos IPv6-tuki ei hankintahetkellä ole ollut vaatimuksena. Joskus esimerkiksi laitevalmistajan lupaamien ominaisuuksien toteutusaikataulu on viivästynyt tai ominaisuuksien käyttöönotto alentaa merkittävästi laitteen suorituskykyä.

Lähtökohtana voidaan yleensä pitää sitä, että IPv6:n suodatuspolitiikka on sama kuin IPv4:lle. Suodatussäännöstön suunnitteluun tulee kiinnittää riittävästi huomiota. Suoraviivaisin tapa on luoda yhtenäiset suodatussäännöt nimipalvelua hyödyntäen sekä IPv4:lle että IPv6:lle, jos laite sitä tukee. Automatisoitujen sääntöjen luonnissa on laitevalmistajakohtaisia eroja, eivätkä kaikki toimi aivan odotetulla tavalla. Palomuurisääntöjen määrän kasvua ei voi välttää ja myös tiukka suodatuspolitiikka yhdistettynä tarpeettoman yksityiskohtaiseen suodatuskäytäntöön johtaa suodatussäännöstön kasvamiseen hyvin suureksi. Seurauksena suodatussäännöstön kokonaisuuden hallinta kärsii ja palomuurin toiminnallisuus voi kääntyä itseään vastaan.

Tähän dokumenttiin on kerätty IPv6-liikenteen suodatuksen suunnittelussa ja toteutuksessa huomioitavia asioita ja käytännön ohjeita. Lisäksi dokumentissa on kuvattu muutamia toimintoja, jotka IPv6:lla toimivat eri tavoin kuin IPv4:ssä. On myös hyvä pitää mielessä, että palomuuri ei ole ainoa tai paras ratkaisu kaikkiin tietoturvariskeihin.

IPv4- ja IPv6-liikenteen eroavaisuuksia

Siirtymätekniikat

IPv6 on tehnyt tuloaan jo yli kymmenen vuoden ajan. Siirtymää helpottamaan on kehitetty lukuisia erilaisia tunnelointimekanismeja, joita päätelaitteet käyttävät osin automaattisesti. Tunneloinnin kautta voi avautua sellaisia tietoturva-aukkoja, joita verkon palomuurissa ei ole otettu huomioon, koska tunnelointi voi avata kiertotien palomuurisääntöjen ohi. Esimerkkejä tunnelointitekniikoista ovat 6to4 ja Teredo (RIPE 68). Käytössä on myös välityspalvelimia joiden avulla liikenne saadaan kulkemaan IPv4- ja IPv6-verkkojen välillä. Välityspalvelimet tyypillisesti peittävät näkyvistä alkuperäisen lähdeosoitteen ainakin toiseen suuntaan.

IPv6-osoitteista

IPv6-osoiteavaruuden suuri koko mahdollistaa osoitteiden suunnitelmallisen käytön, jolloin verkkoja voi ryhmitellä esimerkiksi käyttötarkoituksen mukaan. Ryhmittelystä voi olla hyötyä suodatussäännöstön laadinnassa, jotta laajempia verkkoalueita voidaan käsitellä yhtenä ryhmänä. Palvelimille on perusteltua konfiguroida staattinen IPv6-osoite automaattisesti generoidun osoitteen sijaan, jottei osoite vaihdu esimerkiksi verkkokortin vaihdon yhteydessä. IPv6-aliverkkojen oletuskoko on /64, ja varsinaisessa käytössä olevien osoitteiden määrä on tästä vain pieni osa.

Käyttäjien kannalta oman haasteensa tuovat fe80::/10-alkuiset link-local-osoitteet. Palvelinylläpitäjät eivät välttämättä tee eroa globaalien ja link-local-osoitteiden välillä ja saattavat epähuomiossa pyytää palomuuriavauksia ei-reitittyville osoitteille. Samalla laitteella on yleensä ainakin kaksi eri näköistä IPv6-osoitetta. IPv4-privaattiosoitteita vastaavia FD00::/8-alkuisia, niin sanottuja ULA-osoitteita voidaan käyttää sisäverkoissa, joista ei ole yhteyttä internetiin tai jos verkon reunalla käytetään NPT-osoitemuunnoksia.

IPv6-osoitteilla on useita erilaisia esitystapoja. Osoitteen osat erotellaan kaksoispisteellä ja mahdollisesti neljä viimeistä tavua pisteillä. Lisäksi nollien merkitseminen tai merkitsemättä jättäminen voi vaihdella kuten myös käytetäänkö isoja vai pieniä kirjamia. Tämä pitää huomioida, jos osoitteille tehdään hakuja tai vertailuja. Esitystapoihin suositellaan noudattamaan RFC 5952:n ohjeita. (RFC 5952).

Huomioita IPv6-erityispiirteistä

Osoitemuunnokset, NPT ja NA(P)T

Jos IPv4:lle on käytössä NAT, täysin vastaavaa toiminnallisuutta IPv6:lle ei ole eikä sitä yleensä tarvita, vaan tilallinen suodatus riittää. NPTv6 (Network Prefix Translation, RFC6296) on tilaton osoitemuunnos, joka on kehitetty multihoming-tarkoitukseen. Siirtymätekniikoina käytetään osoitemuunnoksia kuten NAT64 (RFC6146) ja DNS64 (RFC6147), joilla IPv4-palvelimet saadaan näkymään IPv6-only-clienteille. NPT mahdollistaa myös ISP:n vaihdon ilman sisäverkon uudelleennumerointia.

IPv6-otsikon laajennukset, extension header

IPv6-paketin otsikko on 40 tavun mittainen ja lisäksi otsikossa voi olla vaihteleva määrä lisäkenttiä. Tällä tavoin olisi mahdollista tuoda verkkoon uusia toiminnallisuuksia joustavasti. Kääntöpuolena on se, ettei tietyn otsikkokentän sijaintia voida tietää käymättä läpi koko ketjua. Tämä tekee tilattomasta suodatuksesta IPv4:ään verrattuna työläämpää tai jopa riittämätöntä. Otsikkolaajennuksia voidaan käyttää hyökkäystarkoituksessa tekemällä niistä suuria, lisäämällä niitä paljon, lisäämällä viallisia otsikkokenttiä tai piilottamalla esimerkiksi TCP-yhteyden avaava SYN-paketti fragment-otsikkoketjun loppuun. (RIPE 68)

RFC 5095 toteaa haitalliseksi erityisen Routing header Type 0 (Source Routing) -lisäkentän, jonka ei pitäisi olla enää käytössä. Oman laitteen osalta kannattaa tarkistaa tilanne, mutta yleensä mitään toimenpiteitä ei tarvita. (RFC 5095)

Link local Multicast

IPv6:ssa käytetään multicastia monessa tilanteessa yhteydenmuodostukseen lähiverkossa, kun taas IPv4:ssä multicastia ei tarvita välttämättä lainkaan. Tarpeellista multicast-liikennettä ei tule estää (MLD).

ICMPv6

Kaikkea ICMPv6-liikennettä ei voi suodattaa, jotta yhteydet toimisivat. Toimiakseen päästä päähän Path MTU Discovery (PMTUD) vaatii ICMPv6 "packet too big" (type 2) viestien välittämisen, koska välillä olevat laitteet eivät fragmentoi paketteja, vaan liian isot paketit pudotetaan. ICMPv6 type 2 -paketit pitää olla sallittu kaikkialta. Lisäksi pitää sallia traceroute (jotkut palomuurit piilottavat itsensä traceroutesta).

IPv6 Neighbor Discovery

Älä suodata seuraavia paketteja: ICMPv6 type 133, 134, 135, 136.

IPv4:n ARP-toiminnallisuus on toteutettu IPv6:ssa Neighbor Discovery address resolution -toiminnallisuudella. Kun laite haluaa selvittää naapurin MAC-osoitteen, se lähettää Neighbor Solicitation -paketin (ICMPv6 type 135) naapurin IPv6-osoitteesta muodostettuun multicast-osoitteeseen. Naapuri vastaa tähän unicastilla Neighbor Advertisement -paketilla (ICMPv6 type 136). Laitteet ylläpitävät osoitetietoja Neighbor Cache -tilataulussa. Reitittimet löydetään vastaavasti router discoveryn avulla. Laite lähettää Router Solicitation -paketin (ICMPv6 type 133), joka lähetetään erityiseen all routers -multicast osoitteeseen (FF02::2) ja reitittimet vastaavat Router Advertisement -paketilla (ICMPv6 type 134) all nodes -multicast-osoitteeseen (FF02::1). IPv6 Neighbor Dicovery -paketeilla on vain paikallinen merkitys kyseisellä linkillä, eikä niitä ole tarkoitus välittää reitittimien yli. Pakettien TTL-arvon tulee olla aina 255, joten kauempaa tulevat paketit hylätään automaattisesti. Lisätietoa löytyy RFC 4890:stä "Recommendations for Filtering ICMPv6 Messages in Firewalls". (RFC 4890)

Ping

RFC4890 suosittelee sallimaan Echo Requestin (Type 128) ja Echo Responsen (Type 129). Ping-paketteja voidaan käyttää tavoitettavuuden tutkimiseen. (RFC 4890)

Varaamattomien ICMP-tyyppien suodattaminen

Jos palomuurissa estetään tuntematonta tyyppiä olevien ICMPv6-pakettien välittäminen, on syytä tarkistaa säännöllisesti, onko IANA varannut uusia pakettityyppejä käyttöön.

Suodata nämä

RFC 4890 suosittelee suodattamaan seuraavat ulkopuolelta tulevat ICMPv6-paketit, joita ei pitäisi myöskään lähteä omasta verkosta ulos. Näiden suodattamisesta ei yleensä ole haittaa yhteyksien toiminnalle.

Node Information Query (Type 139)
Node Information Response (Type 140)
Experimental and extension (Types 100, 101, 200, 201, 127, and 255)

Laitetuki

Palomuurilaitteiden IPv6-tuki

Tällä hetkellä (03/2015) monet laajasti käytetyt tilalliset palomuurit eivät tue lainkaan IPv6:tta tai toteutukset ovat puutteellisia. Joitakin uudehkoja toteutuksia ei vielä ole ennätetty testata Funet-jäsenten verkkoympäristöissä. Tilallisen suodatuksen käyttöönottovaiheen ongelmista johtuen joissakin Funet-organisaatioissa on päädytty toteuttamaan IPv6-liikenteelle tilaton suodatus. On kuitenkin tilanteita, joissa tilallinen suodatus on tietoturvan kannalta ehdoton vaatimus.

Laitevalmistajasta riippuen IPv6:n käyttöönotto voi luoda palomuuriin oletussääntöjä, jotka sallivat joitakin IPv6:n toiminnalle tarpeellisia paketteja. Oletussäännöt voivat olla erilaiset riippuen siitä toimiiko palomuuri reitittävänä vai siltaavana. Sääntöjä ei välttämättä kuitenkaan voi nähdä palomuurin konfiguraatiosta tai käyttöliittymästä. Lisäksi monien laitevalmistajien IPv6-toteutuksissa on edelleen puutteita. Osa IPv6-ominaisuuksista on verrattain uusia ja niistä on vain vähän operatiivista kokemusta. Tilanne kuitenkin paranee vähä vähältä, kun vikoja havaitaan ja korjataan.

Palomuurin suorituskyky voi tulla ongelmaksi erityisesti IPv6:lla, koska toteutus voi olla paljon huonompi kuin IPv4:llä. Ylikuormittumista voidaan ehkäistä ennen palomuuria tehtävällä pakettisuodatuksella tai liikennerajoituksilla. Oman laitteen osalta IPv6-suodatusominaisuuksien ja IPv6-liikennemäärän vaikutuksista palomuurin suorituskykyyn kannattaa ottaa selvää laitevalmistajalta. Laitevalmistajalta on syytä selvittää miten palomuuri käsittelee extension header -otsikoiden taakse niin sanotut piilotetut ylemmän tason otsikot sekä fragmentteja hyödyntävät hyökkäykset ja miten näiden käsittely vaikuttavat palomuurin suorituskykyyn.

RIPE NCC:n IPv6-työryhmä on tuottanut dokumentin, joka listaa IPv6 toiminnallisuusvaatimuksia erilaisille verkon laitteille. Dokumenttia kannattaa hyödyntää mm. laitehankintojen apuna. (RIPE 554)

Ylläpitokäytännöistä

Jotta palomuurisäännöstö säilyy yhtenäisenä sekä IPv4- että IPv6-sääntöjen osalta, ylläpitokäytäntöjen tulee olla sellaiset, että molemmista huolehditaan (RIPE 68). Jos laite sen mahdollistaa, säännöt kannattaa luoda kerralla. Palomuurisäännösten hallintamenetelmät kannattaa suunnitella pitkää aikaväliä silmällä pitäen. Kannattaa varautua myös verkkotopologiamuutoksiin, esimerkiksi verkkojen kasvuun.

Hyvin suunniteltu osoitteistussuunnitelma helpottaa verkkojen ylläpitoa. Dokumentoitu verkkotopologia mahdollistaa joustavat verkkojen muutokset.