1 april 2014
We zijn dringend toe aan een omgeving met meerdere lagen van bescherming
CWI voortrekker bij implementatie DNSSEC op Science Park
Het Centrum Wiskunde & Informatica (CWI) heeft een voortrekkersrol gespeeld bij de implementatie van DNSSEC op het Amsterdamse Science Park. Het project was een gezamenlijk initiatief van CWI, AMOLF en Nikhef. Deze drie aan NWO gerelateerde onderzoeksinstituten dienden anderhalf jaar geleden een voorstel in voor de Campus Challenge, een competitie georganiseerd door SURFnet en SIDN. De implementatie van DNSSEC was daar een onderdeel van.
Inmiddels is het project afgerond en zijn de drie instituten van zowel ondertekening als validatie voorzien. De techniek van DNSSEC is op zichzelf niet zo heel spannend. Het gaat om het maatschappelijk belang van een veiliger internet.
Bovendien was het voor het CWI een goede gelegenheid om de banden met andere instituten aan te halen, en kennis en technologie uit te wisselen.
De implementatie van DNSSEC — zowel ondertekening als validatie — was bij het CWI onderdeel van de Campus Challenge. Deze competitie werd anderhalf jaar geleden door SURFnet en SIDN gezamenlijk uitgeschreven om onderwijs- en onderzoeksinstellingen te stimuleren hun IT-infrastructuur te verbeteren. Daarmee maakt deze Challenge onderdeel uit van het veelomvattender GigaPort3-innovatieprogramma. Specifiek voor de implementatie van DNSSEC is door SIDN, de beheerder van het .nl top-level domein, een ton bijgedragen aan het beschikbare prijzengeld. Inmiddels zijn alle implementaties succesvol afgerond.
Het CWI werkte in dit project samen met twee andere instituten op het Amsterdamse Science Park: het FOM-instituut AMOLF en het Nationaal instituut voor subatomaire fysica (Nikhef). Bij het CWI zelf zijn 185 FTE werkzaam. Die gebruiken bij elkaar ongeveer 600 devices. Bij AMOLF werken zo'n 200 mensen, samen goed voor 750 devices. En de DNS -resolvers bij Nikhef tenslotte bedienen ongeveer 250 werknemers en 4000 devices. Dat laatste aantal is te danken aan het grid-systeem van dit instituut.
Goed kijken en rustig typen
We kregen de mogelijkheid om al in een vroeg stadium aan DNSSEC mee te doen en we zagen het belang daarvan,
vertelt hoofd systeembeheer Aad van der Klaauw. Volgens hem was de implementatie een makkie. We zijn maar een klein instituut, dus we hebben DNSSEC niet apart getest, maar nog eens gecheckt of we het goed hadden begrepen en het vervolgens gewoon aangezet. Een kwestie van goed kijken en rustig typen. Zo simpel kan het zijn.
We waren al bezig met een migratie van Unix naar Linux. Voorheen draaiden we meerdere services gebundeld op een fysieke server. Tegelijk met de overstap naar afzonderlijke gevirtualiseerde systemen met elk één dienst hebben we onze DNS-omgeving vernieuwd en DNSSEC aangezet.
We gebruiken hier al heel lang ISC Bind, en dat zijn we blijven doen. Onze configuratie is relatief eenvoudig en bestaat uit twee master DNS-servers en een externe secondary, alle gebouwd op Bind versie 9.8.2 en Scientific Linux 6.
De andere twee instituten hebben vergelijkbare configuraties opgesteld: Bij AMOLF staan twee primary nameservers, met een secondary bij SURFnet. Alle drie systemen draaien Bind op Red Hat Enterprise Linux (RHEL). Nikhef heeft één primary nameserver en drie secondaries, en gebruikt daarvoor Bind op een RHEL-kloon.
Eigen systeem
De gebrekkige ondersteuning van Bind versie 9.8 voor sleutelbeheer is volgens Van der Klaauw geen probleem. Dat gebruiken we sowieso niet. We hebben vijftien jaar geleden al ons eigen systeem opgezet. Daarvoor gaan we uit van een lijst met systeemgegevens — hostname, IP-adres, DHCP-informatie en dergelijke — en daar hebben we wat scripts van een paarhonderd regels omheen gebouwd. Die genereren automatisch de configuraties die vervolgens de services in gaan. Ik heb daar gewoon wat DNSSEC-functionaliteit aan toegevoegd. Je doet het eerst twee keer met de hand. Daarna begrijp je hoe het werkt en kun je het automatiseren. Tegenwoordig koop je dat in een kant-en-klaar doosje en dan heet het IPAM. Dan is DNSSEC gewoon een vinkje dat je kunt activeren. Wij hebben geleerd dat de tijd nemen om het zelf doen zich over de jaren heen makkelijk terugverdient.
Alleen naar tools voor logging en monitoring hebben we even moeten zoeken; er was op dat moment niet zo veel beschikbaar voor Nagios. Uiteindelijk kwamen we uit bij een half afgemaakt programmaatje van iemand bij de ETH in Zűrich. SURFnet heeft hier veel mooiere spullen voor; die gaan we binnenkort gebruiken.
DNSSEC-validatie
De DNS-resolvers die het CWI via DHCP aan zijn gebruikers aanbiedt doen ook DNSSEC-validatie. Internen en externen die hun eigen systemen beheren geven we de raad om dnsssec-trigger van NLnet Labs te gebruiken, tesamen met Secure Shell (ssh) en VPN.
Validatiefouten, waardoor gebruikers bijvoorbeeld websites en mail gateways niet kunnen bereiken, hebben volgens Van der Klaauw nog nooit tot problemen geleid. Voor ons was de Campus Challenge een goede gelegenheid om dit onderdeel te vernieuwen, maar we valideren al langer. In die paar jaar hebben we echter nog nooit een klacht van onze medewerkers gehad.
Mocht het desondanks toch voorkomen dat iemand een site niet kan bereiken, dan hebben we hier voldoende mogelijkheden om zo iemand te helpen. We zullen nooit een domein met problematische DNSSEC-instellingen whitelisten in onze productie-omgeving, maar we hebben hier los van ons eigen netwerk ook onbeveiligde internettoegang voor onderzoeksdoeleinden.
DANE
Voor de implementatie van DANE bij het CWI is het volgens Van der Klaauw nog net te vroeg. Op dit moment doen we nog geen DANE. Onze standaard DNS-software ondersteunt dat nu nog niet, maar zodra we overstappen naar een nieuwe distributie — naar verwachting later dit jaar — implementeren we ook DANE.
Wat betreft de validatie volgen we eenzelfde strategie als we met dnssec-trigger al doen voor DNSSEC. Er zijn twee browser plugins voor DANE beschikbaar, en mogelijk dat ook de Chrome browser straks DANE ondersteunt; Google is een voorloper op dit gebied. Kortom: alles is er al; ondersteuning is slechts een kwestie van tijd.
Dubbele bescherming
Hierbij benadrukt Van der Klaauw de noodzaak van een sterker beveiligde internet-infrastructuur. Met name de TLS/SSL-technologie waarop alle versleutelde verbindingen zijn gebaseerd blijkt kwetsbaar voor Man-in-the-Middle-aanvallen. In 2011 was er natuurlijk dat gedoe met DigiNotar. Maar ook de afgelopen maanden werden weer nieuwe problemen ontdekt. Eerst bleken Apple's iOS en OS X besturingssystemen een bug te bevatten waardoor certificaten niet goed gecontroleerd werden [goto fail]. Daarna werd een vergelijkbare bug gevonden in de GnuTLS library. En het is slechts een kwestie van tijd voordat de volgende kwetsbaarheden opduiken.
Het probleem met TLS/SSL is dat het slechts een enkelvoudige bescherming is. Dat blijkt regelmatig onvoldoende te zijn. Kennelijk is de implementatie van TLS/SSL of de uitvoering ervan zo ingewikkeld dat dat regelmatig gevaar oplevert voor de gebruikers. En zodra er ergens een probleem optreedt, is die beveiliging gelijk verbroken. DNSSEC in combinatie met DANE [een extra keten om certificaten te authenticeren] biedt een tweede bescherming daarbij. De techniek heeft zich inmiddels bewezen. En je ziet dat een bedrijf als VeriSign groot op DNSSEC heeft ingezet omdat ze daar geld aan willen verdienen.
Certificaten onbetrouwbaar
Of ze dat nu bekend hebben gemaakt of niet,
vervolgt Van der Klaauw, alle certificaat-leveranciers zijn wel een keer gekraakt. De bescherming van certificaten is flinterdun. Consumenten moeten zich daar niet mee bezig hoeven houden. Die moeten kunnen vertrouwen op de techniek. Nu is die onbetrouwbaar, en dat betekent dat we dringend toe zijn aan een omgeving waarin je meerdere lagen van bescherming hebt.
Na DANE zullen andere protocollen gauw volgen. Veel daarvan hebben we al in onze DNS-records opgenomen. In principe komt alles wat TLS/SSL gebruikt daarvoor in aanmerking. Als die techniek straks met de komst van quantumcomputers achterhaald blijkt, mag je hopen dat er inmiddels meerdere verschillende manieren worden gebruikt om systemen en verbindingen te beveiligen. Zo kun je van een aantal zwakkere systemen een sterk systeem maken. We zijn echt toe aan de invoering van zo veel mogelijk van dit soort beveiligingsmiddelen naast elkaar.
Van der Klaauw maakt hierbij een vergelijking met two-factor authenticatie. Wachtwoorden zijn inmiddels verworden tot simpele cijfersloten. Daarom krijgen we nu allerlei discussies over biometrische beveiliging. Gelukkig hoeven we die discussie voor DNSSEC niet te voeren. Dus ook daar is geen argument om met de invoering te wachten.
Automatiseren
Over de fouten die nu nog regelmatig gemaakt worden — denk aan het .mil top-level domein waarvan men de handtekening een jaar geleden per ongeluk liet verlopen — heeft Van der Klaauw geen zorgen. DNSSEC is veel strenger dan de certificaten zoals we die nu gebruiken. Klopt daar iets niet, dan kun je meestal een waarschuwing wegklikken en gewoon verder gaan. Als DNSSEC-validatie aanstaat word je in dat geval gelijk geblokkeerd. Dat lijkt me de meest veilige oplossing.
Dat betekent ook dat je je zaakjes voor elkaar moet hebben. Deze dingen gaan vooral mis als je ze niet geautomatiseerd hebt. DNSSEC bevindt zich nu nog in de aanloopfase. Straks is alles volledig geautomatiseerd. Dan staat DNSSEC overal standaard aan, en dan moet je zelfs moeite doen om het uit te krijgen. Leveranciers moeten hun infrastructuur goed beheren. Hun dienstverlening brengt ook bepaalde verplichtingen met betrekking tot de veiligheid met zich mee. Consumenten zien straks helemaal niets van DNSSEC, maar ze moeten wel het vertrouwen hebben dat alles goed en veilig werkt.
Voor beheerders die het moeilijk vinden om de stap te maken van het administreren van records naar het onderhouden van een cryptografisch beveiligde DNS-infrastructuur heeft Van der Klaauw geen begrip. Vergelijk het maar met het leren van een nieuwe taal; dat kost moeite. Maar als daar commercieel gewin tegenover staat omdat je zo beter zaken kunt doen, dan is het de normaalste zaak van de wereld. Zie DNSSEC gewoon als een investering in de maatschappij en in de veiligheid van internet.
Maatschappelijk belang
De DNSSEC-techniek is daarom op zichzelf ook niet zo heel spannend,
zegt Van der Klaauw. Die bestaat al veel langer. Het gaat om het maatschappelijk belang. Daarom verbaas ik mij dat met name grote partijen die zeggen veiligheid hoog in het vaandel te hebben staan passief blijven afwachten. De gebruikers — hun klanten — begrijpen nog niet hoeveel risico dat gedrag met zich meebrengt.
Hij doelt hiermee op de banken; op dit moment heeft geen van hen zijn domein nog ondertekend. Er zijn enkele banken in het buitenland die hier wel serieus mee bezig zijn. In die wereld kan de invoering van zo'n beveiligingstechnologie wel tien jaar duren. In Nederland heb ik nog van niemand gehoord dat ze hier aan werken. Hier introduceert men vooral nieuwe features.
Hetzelfde geldt voor de providers: Er is wel op grote schaal ondertekend waar dat in bulk mogelijk was, maar ik ken geen enkele provider die zijn klanten op dit moment de mogelijkheid biedt om DNSSEC als dienst af te nemen. Je zou verwachten dat ze de DNSSEC-faciliteiten beschikbaar in EPP ook in hun webinterface zouden opnemen zodat mensen hun sleutelmateriaal kunnen uploaden. Sterker nog, mijn provider thuis ondersteunt niet eens EDNS, een basisvereiste om DNSSEC űberhaupt te kunnen gebruiken. Dat zijn dingen die mij verbazen. Ondanks dat de veiligheidsproblemen met DNS al jaren bekend zijn, is men met hele andere dingen bezig.
Wij als instituut hebben de morele verplichting om daarin voorop te lopen, en die verantwoordelijkheid hebben wij genomen. Een bank die zijn internettoegang niet goed beveiligd heeft, kan straks moeilijk de verantwoordelijkheid voor problemen met internet-bankieren bij de consument leggen.
Early adopter
We zouden als instituut niet direct in de problemen komen als we niet voorop zouden lopen met zaken als DNSSEC,
vertelt Niels Nes, onderzoeker en hoofd van de afdeling Information Technology and Facilities (ITF). Het CWI profileert zich niet via zijn ondersteuning. Vroeger was de IT-infrastructuur wel zodanig vernieuwend dat het meer onderdeel was van het onderzoekswerk.
Niet toevallig is SIDN zelf ooit een spin-off geweest van het CWI. Destijds moesten we zelf de aansluiting met het internet maken. Maar inmiddels is IT een commodity geworden en zijn we vooral faciliterend bezig.
Dat betekent echter niet dat onze medewerkers die oude academische rol niet meer willen. Nieuwe technologische ontwikkelingen blijven we zo interessant vinden dat we daarin voorop willen lopen. Het zijn nog steeds de krenten in de pap. En we kunnen daarvoor ook aankloppen bij onze onderzoekers. We hebben hier voldoende experts in huis die we om advies kunnen vragen op het gebied van software en architectuur, en daar maken we graag gebruik van. Zij vinden het leuk om ook betrokken te zijn bij de praktische ontwikkelingen en het hoeft niet meer te kosten dan vijf minuten.
Samenwerkingsverbanden
De bijdrage van SIDN heeft de implementatie van DNSSEC op het Science Park een stuk makkelijker gemaakt. We hebben daardoor de tijd kunnen vrijmaken en meteen onze buren kunnen helpen,
zegt Nes. Er wordt al langer samengewerkt tussen de IT-afdelingen van het CWI, AMOLF en Nikhef. We zitten hier op één terrein, en onze onderzoekers zouden de data van de andere twee instituten prima kunnen gebruiken. Dergelijke samenwerkingsverbanden proberen we te stimuleren door de netwerklaag — inmiddels op level 2 en level 3 — en de storage-laag onderling te koppelen. Dat betekent ook dat we gezamenlijk kijken naar vernieuwing van netwerken en opslag. Daarbij kwamen ook IPv6 en DNSSEC ter sprake.
We proberen gedrieën steeds meer samen te doen. Deze gespecialiseerde instituten zijn eigenlijk te klein voor SARA [dat vooral rekenkracht en opslag levert] en SURFnet [dat de netwerken verzorgt]. Samenwerken betekent ook dat je een steviger vuist kunt maken.
Of dit uiteindelijk zal uitgroeien tot een gedeeld servicecenter durft Nes niet te zeggen. Ik verwacht wel dat we steeds meer samen zullen gaan doen. SARA is ooit op een vergelijkbare manier ontstaan. Een dezer jaren komt hier het Utrechtse ruimteonderzoekinstituut SRON nog bij. We hopen dat zij te zijner tijd als vierde partner aansluiting kunnen vinden.
Samenwerking met SIDN
Naast het verstevigen van de samenwerking tussen de instituten op het Science Park was de Campus Challenge ook een gelegenheid om de banden met SIDN aan te halen. Drie jaar geleden, niet lang na de ondertekening van het .nl-domein, hebben we al meegedaan met het Friends & Fans-programma,
vertelt Van der Klaauw. Destijds moest het aanleveren en verifiëren van sleutelmateriaal nog per mail en telefoon gebeuren. Gelukkig kan dat nu allemaal via de EPP-interface. Daar zijn we echt heel blij mee. Dat zouden eigenlijk alle providers moeten doen, zodat je DNSSEC helemaal kunt automatiseren, zoals gezegd een belangrijke voorwaarde voor een foutloze operatie. We mogen in Nederland blij zijn met een registry die zo voorop loopt.
Net als T-Mobile en SURFnet zal ook het CWI elke dag een overzicht van de opgetreden validatiefouten naar SIDN sturen. De registry gebruikt deze informatie om het aantal fouten actief naar beneden te brengen. SURFnet doet dat zelf ook voor zijn eigen klanten.
Goede buren
Om kennis op te doen hebben we de specialisten van NLnet Labs — zij zitten aan de overkant van de straat — een keer hier uitgenodigd om een middag over DNSSEC te praten,
aldus Van der Klaauw. Dan leer je dnssec-trigger kennen, en OpenDNSSEC en hun software HSM. Inmiddels worden die tools standaard meegeleverd met Linux-distributies. Maar we zijn heel blij met dat soort buren en weten ze te vinden als dat nodig is.
De andere winnaars van de Campus Challenge hebben we niet specifiek over DNSSEC gesproken. Wel weten we van elkaar waar we mee bezig zijn en gebruiken we elkaar tools. Daar vindt dus uitwisseling op technisch niveau plaats.
