Aandachtspunten bij de beveiliging van je IPv6-netwerk

Automatische adrestoekenning

Waar automatische adrestoekenning voor IPv4 meestal is gebaseerd op DHCP, wordt deze functie voor IPv6 in eerste instantie uitgevoerd via Stateless Address Autoconfiguration (SLAAC) en het Neighbor Discovery Protocol (NDP). Daarbij publiceren de routers de network prefixes voor de aangesloten netwerksegmenten via een Router Advertisement, en genereren de individuele devices een unieke interface identifier om het IPv6-adres compleet te maken. Duplicate Address Detection (DAD) zorgt ervoor dat een interface identifier niet al door een ander device op hetzelfde netwerksegment gebruikt wordt: elke keer als een interface een nieuw IPv6-adres in gebruik wil nemen, stuurt deze dat eerst rond in een speciaal multicast-bericht om te checken of andere hosts niet hetzelfde adres (willen) gebruiken. Merk op dat interfaces onder andere door het gebruik van de Privacy Extensions tegelijkertijd meerdere IPv6-adressen binnen dezelfde prefix kunnen hebben. Maar sowieso wordt aangeraden om verschillende IPv6-adressen (identifiers) op een interface te gebruiken voor verschillende functies (applicaties) op hetzelfde systeem. Uitgangspunt is dat de routers verantwoordelijk zijn voor de network prefixes. Bovendien kunnen zij delen daarvan ook weer toekennen aan routers lager in de hiërarchie (prefix delegation). De individuele devices zorgen zelf voor hun unieke interface identifiers. Daarmee is adrestoekenning zo veel mogelijk geautomatiseerd en is ook het omnummeren van een compleet netwerk makkelijker geworden. RFC 7721 bespreekt de security- en privacy-overwegingen met betrekking tot het genereren van IPv6-adressen.

DHCPv6

Het bekendmaken van de DNS-resolvers wordt ook door de routers verzorgd als onderdeel van NDP. Maar daarvoor kun je ook het later gedefinieerde DHCPv6-protocol inzetten. Dat wordt ook gebruikt voor andere aanvullende zaken zoals additionele IPv6-adressen voor multicasting en allerlei parameters voor IPv4-IPv6-transitiemechanismen.

Geen NAT

Omdat elk apparaat onder IPv6 zijn eigen unieke, routeerbare adres heeft, is NAT niet meer nodig. Dat betekent wel dat individuele apparaten via IPv6 vanaf het internet bereikbaar zijn. Om te voorkomen dat systemen gescand en belaagd worden, worden firewalls weer belangrijker, een functie waarvoor bij IPv4 vaak ten onrechte (gedeeltelijk) op NAT wordt vertrouwd. Hetzelfde geldt voor screening routers, proxies en de DMZ, allemaal beveiligingsmaatregelen die standaardpraktijk waren in de tijd dat individuele computers nog een routeerbaar IPv4-adres konden krijgen. Het universele gebruik van routeerbare adressen betekent ook dat je nu goed op moet letten dat intern verkeer niet onbedoeld buitenom over het publieke internet wordt gerouteerd. Bijkomstigheid is dat IPv6-adressen vanwege hun lengte moeilijk leesbaar zijn, dat network prefixes uit 3 niveaus bestaan voor de organisatie, afzonderlijke vestigingen en subnetwerken binnen die locaties, en dat filtering op basis van individuele adressen (blacklisting/whitelisting) niet meer mogelijk is (alleen op basis van prefixes). Het opstellen van een nummerplan is dan ook een cruciaal onderdeel van elke IPv6-implementatie.

RFC 9099

RFC 9099 bespreekt de praktische, operationele veiligheidsaspecten van IPv6, en dan vooral voor bedrijfsnetwerken en service providers. Daarmee vormt deze RFC een aanvulling op RFC 4942, dat de beveiligingsonderdelen van het IPv6-protocol zelf en de transitiemechanismen behandelt. Overigens is een aanzienlijk deel van de besproken issues in deze RFC's vooral van belang voor software-ontwikkelaars en hardware-leveranciers. Denk bijvoorbeeld aan het tegengaan van illegale DHCPv6-servers en gespoofde NDP-berichten die proberen valse informatie op het netwerk(segment) te injecteren of een Denial-of-Service (DoS)-aanval uit te voeren. Interessant in dit verband is RFC 8273, dat een adresschema beschrijft waarbij elke eindgebruiker een unieke prefix krijgt, zodat zij alleen indirect via een router met elkaar kunnen communiceren.

Relevante onderdelen

RFC 9099 behandelt vele tientallen onderwerpen, allemaal voorzien van verwijzingen naar de bijbehorende RFC's. We raden je aan om een keer door het hele document te lopen om te zien welke onderdelen voor jouw specifieke situatie van belang zijn. Zo zal het onderwerp logging/monitoring/auditing voor de meesten relevant zijn, terwijl je van de transitiemechanismen waarschijnlijk alleen die technologieën hoeft te bekijken die je zelf gebruikt of wilt gaan gebruiken. De operationele beveiligingsaspecten voor dual-stack en de IPv4-IPv6-transitie- en translatiemechanismen (voor bedrijfsnetwerken) worden besproken in RFC 7123. RFC 6169 doet dat voor IP-tunneling (in het algemeen). En RFC 3964 behandelt de beveiligingsaspecten specifiek voor 6to4, met beheersmatige aanvullingen in RFC 6343.

Licht aan het eind van de tunnel

Het ontwerp van IPv6 is er met zijn automatische adrestoekenning helemaal op gericht om het beheer van netwerken te vereenvoudigen. Bovendien zijn we met IPv6(-only) af van alle lapmiddelen als NAT, CGNAT en SNI. We zitten op dit moment echter in de overgangsfase van IPv4 naar IPv6, wat betekent dat we er niet aan ontkomen om tijdelijk allerlei behoorlijk ingewikkelde transitiemechanismen op onze netwerken te implementeren. De complexiteit daarvan brengt weer zijn eigen beheerlast en beveiligingsproblematiek met zich mee. Gelukkig gloort er licht aan het eind van de tunnel: IPv6 wordt wereldwijd al op grote schaal gebruikt. Inmiddels komt grofweg een derde van het bezoek bij Google over IPv6 binnen. Bovendien groeit dat aandeel met ongeveer 5 procentpunt per jaar.