23 april 2014
Rijksuniversiteit Groningen valideert DNSSEC voor 100 duizend apparaten
DNSSEC stond al heel lang op ons verlanglijstje
Sinds kort valideert de Rijksuniversiteit Groningen DNSSEC voor al haar gebruikers. In totaal gaat het maar liefst om 100 duizend apparaten. Bovendien heeft de universiteit de eigen Domeinnaam ondertekend. Meer domeinen, subdomeinen, servers en clients volgen.
Veiligheid is het belangrijkste argument om met DNSSEC aan de slag te gaan. In het verleden werd al het gebruik gedetecteerd van Russische nameservers, waarmee man-in-the-middle-aanvallen uitgevoerd konden worden. Door het gebruik van de eigen resolvers af te dwingen, kan deze kwetsbaarheid getackeld worden.
Deze DNSSEC-implementatie was onderdeel van de Campus Challenge, een competitie georganiseerd door SURFnet en SIDN met als doel om onderwijs- en onderzoeksinstellingen te stimuleren om hun IT-infrastructuur te verbeteren. Daarmee maakt deze Challenge onderdeel uit van het veelomvattender GigaPort3-innovatieprogramma.
Voorheen hadden we drie nameservers op basis van Bind,
vertelt netwerkspecialist Mente Heemstra. Die fungeerden niet alleen als autoritatieve servers voor het domein rug.nl maar tegelijkertijd ook als resolvers voor onze gebruikers. Dat hebben we in de nieuwe opzet uit elkaar getrokken. Nu hebben we een verborgen master waar de administratie van de domeinnamen plaatsvindt. De ondertekening daarvan gebeurt door een tweede verborgen server. Die fungeert dus als slave voor de administratieve server en als master voor de drie autoritatieve nameservers. Twee daarvan draaien op een gevirtualiseerde machine, de derde op een fysiek systeem om de robuustheid van onze DNS -infrastructuur te vergroten. Om diezelfde reden staat er ook nog een autoritatieve server bij SURFnet. Zo blijft onze domein-informatie ook beschikbaar als er problemen met het netwerk zijn.
Ondertekening
De tweede verborgen master maakt gebruik van OpenDNSSEC versie 1.4 en SoftHSM voor de ondertekening van de domeinnamen. Deze combinatie haalt de zone-informatie op bij de eerste verborgen master, ondertekent alle records, en maakt deze weer beschikbaar voor de autoritatieve nameservers. Uit veiligheidsoverwegingen zijn er voor elke zone altijd twee KSK's en twee ZSK's beschikbaar. De roll-overs gebeuren respectievelijk elk jaar en elke drie maanden. De DNS records zelf worden elke twee weken opnieuw getekend. Daarbij is alles zo veel mogelijk geautomatiseerd — waar nodig met behulp van eigen scriptjes en cron jobs — inclusief backups en statistieken op basis van MRTG. Alleen voor de jaarlijkse registratie van het nieuwe KSK-sleutelmateriaal bij SIDN is handmatige actie vereist. Een cron job stuurt daarvoor een mailbericht naar een beheeradres.
Op dit moment worden de domeinen kvi.nl, rug.nl en usor.nl, en een aantal subdomeinen hiervan ondertekend. We willen in ieder geval al onze services van handtekeningen voorzien,
aldus Heemstra.
Validatie
De drie resolvers die caching en recursie doen voor de gebruikers van het universiteitsnetwerk staan nu helemaal los van de autoritatieve servers. Ook hier zijn weer twee van de drie systemen gevirtualiseerd. Alle drie systemen valideren de geldigheid van DNSSEC-ondertekende records.
Op centraal niveau wordt DHCP gebruikt om de werklast van alle devices over de beschikbare resolvers te verdelen. We hebben ongeveer 8000 actieve medewerkers,
aldus Heemstra, een kleine 30 duizend eigen studenten, en nog eens 20-25 duizend gebruikers van eduroam en de Hanzehogeschool die toegang hebben tot onze bibliotheek. Het zou best kunnen dat we meer dan 100 duizend devices bedienen. We hebben wel eens geteld in ons draadloze netwerk, en toen kwamen we uit op meer dan 50 duizend apparaten.
Dichttimmeren
De bedoeling is dat straks alle gebruikers gedwongen worden om hun DNS queries via de resolvers van de RuG te laten lopen. Daarvoor zal alle TCP/UDP-verkeer naar poort 53 worden omgeleid. Iedereen krijgt nu wel onze DNS-servers via DHCP aangeboden,
zegt Heemstra, maar in principe ben je nog steeds vrij om je eigen resolvers te kiezen, of om zelf een resolver te draaien. Je hebt dan dus geen idee waar je uitkomt als je een webadres intikt. We willen naar een situatie waarin onze resolvers bepalen of er wel of niet geantwoord wordt en wat die antwoorden dan zijn. Op die manier wordt ook maximaal gebruik gemaakt van de DNS caches en het netwerk ontlast.
We hebben in het verleden al meerdere malen meegemaakt dat bots de stub resolvers op de clients overnamen en de DNS-servers ineens in Rusland plaatsten. Die servers gaven bij elke site hun eigen adres terug, zodat ze keurig als de man-in-the-middle fungeerden. Met DNSSEC hebben we een beveiligde DNS-infrastructuur opgezet waarmee dat niet zomaar meer kan. Om de voordelen daarvan daadwerkelijk te benutten, moet DNS wel gebruikt worden zoals wij dat bedoeld hebben.
Validatiefouten
Dat betekent ook dat gebruikers bij de beheerders aan zullen moeten kloppen bij het optreden van validatiefouten. Bij de Faculteit der Letteren hebben we al te maken gehad met een externe website die aangaf dat er ondertekend was terwijl de sleutels helemaal niet beschikbaar waren,
vertelt Heemstra. Onze resolver weigerde toen — terecht — om antwoorden door te geven. Natuurlijk kregen we reacties van studenten die zeiden dat het thuis wel werkte en hier niet. We konden hen ook prima uitleggen waarom de toegang geweigerd werd. Maar die website werd in het onderwijs gebruikt, dus toen hebben we de validatie even helemaal uitgezet. Inmiddels staat de validatie weer aan. Helaas ondersteunt Bind versie 9 geen whitelisting, of negatieve trust anchors zoals ze inmiddels heten. Wellicht dat we om deze reden unbound nog op de resolvers gaan installeren. Nu leggen we de verantwoordelijkheid bij de gebruiker: als je een validatieprobleem hebt, dan moet je de eigenaar van die site zijn DNSSEC in orde laten maken.
Gebruikers die echt in de problemen komen, kunnen natuurlijk altijd het IP-adres in hun hosts file opnemen. DNSSEC werkt uitsluitend op domeinnamen, dus ook alleen de naam wordt geblokkeerd. Meestal kun je gewoon het IP-adres in de webbrowser invullen.
Het uitzetten van validatie is voor Heemstra in ieder geval geen optie meer. Als je wilt dat DNSSEC wereldwijd goed ondersteund wordt, mag je geen water bij de wijn doen. We hebben gezien hoe dat met IPv6 is gegaan: Zolang je NAT of een andere work-around gebruikt, hoef je geen IPv6 te implementeren. Inmiddels zijn we twintig jaar verder, en pas sinds Microsoft IPv6 standaard aangezet heeft in Windows Vista [dual-stack] komt het een beetje op gang. Dat moeten we met DNSSEC niet laten gebeuren.
Reverse look-up
Hoewel de RuG op zo veel mogelijk domeinen DNSSEC wil implementeren, zal dat vanwege schalingsproblemen en IPv6-adresserings-issues voor de clients niet direct gebeuren. We willen in ieder geval al onze diensten volledig geauthenticeerd hebben, zodat anderen die die dienst gebruiken zeker weten dat jij degene was die die gegevens beschikbaar heeft gemaakt. Je ziet dat steeds meer dienstverleners verifiëren of een bezoeker inderdaad is wie hij zegt te zijn. Controle van de reverse look-up is steeds vaker onderdeel van die policies; is je adres niet geadministreerd, dan krijg je geen toegang. Op IPv4 moeten je clients nu eigenlijk allemaal geregistreerd staan. Dat is ook een goede reden om die records gelijk te ondertekenen.
IPv6 voegt daar echter een hoop complexiteit aan toe. Het vullen van de reverse domeinen voor een volledige DNSSEC-implementatie is een groot probleem, met name vanwege SLAAC (met of zonder encryptie) en de privacy optie [RFC 4941]. Bovendien krijg je het wel erg druk met alle handtekeningen en worden key roll-overs nogal intensief. Daar zijn we dus nog niet uit
Ondanks een heleboel praktische bezwaren is ondertekening van de reverse domeinen in principe geen probleem: zowel in-addr.arpa (voor IPv4) als ip6.arpa (voor IPv6) zijn ondertekend.
Windows clients
Een ander probleem aan client-zijde is dat Windows versie 7 DNSSEC niet volledig ondersteunt. De resolver doet het wel, maar als je nslookup gebruikt om alle records op te vragen, krijg je foutmeldingen voor de keys en de handtekeningen. Je bent dus afhankelijk van client-toepassingen die direct of met behulp van een plug-in DNSSEC controleren.
Windows is volgens Heemstra sowieso geen voordehandliggend platform om te gebruiken in combinatie met DNSSEC. Niet alleen gebruikt Microsoft een proprietary protocol (GSS-TSIG in plaats van TSIG) voor de overdracht van adres-informatie, ze misbruiken Dynamic DNS ook voor Active Directory en werkgroep-functionaliteit. Als iemand zijn eigen station een naam geeft, dan wordt die via Dynamic DNS automatisch gepubliceerd. Op die manier kan iedereen schunnige, beledigende of anderszins ongewenste namen aan ons netwerk koppelen. Dat willen we niet.
Active Directory
Als je pech hebt moet een dynamische host ook nog een handtekening krijgen,
vervolgt Heemstra, en daarmee kun je jezelf goed in de nesten werken. Hetzelfde geldt voor IPv6. Toen we daarmee experimenteerden, ging Windows allerlei dingen met multicast DNS doen. Als je dat in een grotere omgeving probeert, gaat je netwerk ten onder aan broadcast- en multicast-pakketten.
Wat we ervan geleerd hebben is dat bepaalde Windows-features vanwege deze problemen alleen inzetbaar zijn in kleinere netwerken. Wel wordt Active Directory nu al veel gebruikt in onze administratieve omgeving. Authenticatie in de rest van ons netwerk is nog gebaseerd op NDS [inmiddels eDirectory] van Novell. In onze nieuwe werkplek-omgeving wordt dat overal Active Directory.
Bind versie 10
We hebben in het verleden wel verzoeken gehad om Dynamic DNS te gaan draaien,
aldus Heemstra, maar we hebben dat altijd geweigerd, simpelweg omdat je een behoorlijk risico neemt met de beveiliging. Met het gebruik van DNSSEC vervalt dat dynamische aspect sowieso, dus inmiddels is dat een gepasseerd station. We gebruiken nu overal Bind versie 9.8 op Debian Linux, Zo'n UNIX-platform past ook meer bij een universiteitsomgeving.
Zodra Bind versie 10 stabiel is, wil de RuG overstappen naar dit compleet vernieuwde platform. We zijn er voorzichtig mee aan het spelen. Ik heb zelf een resolver op basis van versie 10 draaien. Er zitten nieuwe features in die we hier graag zouden inzetten — bijvoorbeeld de ondersteuning van negatieve trust anchors — maar het kan best nog een paar jaar duren voordat die software geschikt is voor operationeel gebruik.
Verlanglijstje
Het belangrijkste argument voor de RuG om met DNSSEC aan de slag te gaan, is de veiligheid van het universiteitsnetwerk. Zeker sinds we gemerkt hebben dat er Russische nameservers in onze netwerkomgeving gebruikt werden, willen we zo veel mogelijk in eigen hand hebben,
zegt Heemstra. DNSSEC is daar onderdeel van. Bovendien stond deze beveiligingstechnologie al heel lang op ons verlanglijstje. We hadden twee jaar geleden al vanuit het Kernfysisch Versneller Instituut (KVI) de vraag gekregen, deels uit veiligheidsoverwegingen, deels om vroegtijdig kennis en ervaring met DNSSEC op te doen. Als je er vroeg bij bent, kun je ook geen al te grote brokken maken bij de implementatie. De Campus Challenge was voor ons een mooie gelegenheid om DNSSEC breed in te zetten.
Bij de implementatie van DNSSEC is regelmatig contact met SIDN onderhouden, zowel voor het volgen van een DNSSEC-cursus vooraf als voor technisch advies tijdens dit project. We hebben geen inhoudelijk contact gehad met de andere winnaars van de Campus Challenge. SIDN wisten we sowieso al goed te vinden; we gaan regelmatig naar hun technische sessies. Maar we zoeken ook veel zelf uit en bouwen zelf kennis op, bijvoorbeeld van OpenDNSSEC.
