DNSSEC -implementatie Infoblox sterk verouderd
Belangrijke aandachtspunten bij het aan zetten van DNSSEC
Twee jaar geleden bespraken we de configuratie van DNSSEC op de Trinzic DDI appliances van Infoblox. De belangrijkste conclusies waren dat het ondertekenen en valideren in de grafische interface erg eenvoudig aan te zetten waren — slechts een kwestie van aanklikken — maar dat de default-instellingen wel dringend verbetering nodig hadden.
Infoblox beloofde destijds bij monde van Chief Infrastructure Officer Cricket Liu om deze zaken in een volgende release aan te passen. Inmiddels zijn we echter twee jaar en een major release verder, en blijkt er helemaal niets te zijn aangepast of toegevoegd. Daarmee zitten Infoblox-klanten met een inmiddels sterk verouderd systeem.
Wie al een Infoblox-system heeft staan en DNSSEC aan wil zetten, zal bij de configuratie daarvan extra aandacht moeten besteden aan de cryptografische default-instellingen van zijn appliance.
Eerdere bevindingen
De eerdere evaluatie betrof NIOS versie 6.10.5/6.12. Onze bevindingen met betrekking tot de default-instellingen waren destijds deze:
- De NTP service ondersteunt alleen de inmiddels onveilig geachte MD5- en DES-protocollen voor de authenticatie tussen systemen. De eerste heeft al meer dan tien jaar de status 'deprecated' en de tweede is vorig jaar gekraakt.
- De encryptie-algoritmen voor de KSK- en ZSK-sleutelparen staan standaard ingesteld op RSA/SHA1 (DNSSEC-algoritme nummer 5), terwijl SHA-1 inmiddels niet meer gebruikt zou moeten worden [1, 2].
- Bovendien wordt bij algoritme nummer 5 (en eerdere) gebruik gemaakt van NSEC, een methode om lege DNS replies (zoals een bericht "deze bestaat niet", NXDOMAIN) toch te kunnen voorzien van een DNSSEC-handtekening. NSEC biedt echter geen bescherming tegen "zone walking" of "zone enumeration", ook niet bij een afgeschermde zone transfer. Daarvoor moet opvolger NSEC3 worden gebruikt.
- Tenslotte ondersteunt de import-functie voor de DS-records van gedelegeerde domeinen alleen SHA-1 (digest algoritme #1) en geen SHA-256 (#2), terwijl die laatste van IANA wel de kwalificatie 'mandatory' heeft gekregen.
Voor de details van onze bevindingen verwijzen we naar onze eerdere evaluatie.
Niets gebeurd
We spraken destijds hierover met Cricket Liu, die deze problemen ook onderkende. Hij beloofde toen dat de ingenieurs van Infoblox zouden kijken naar ondersteuning voor Autokey, [1, 2] dat de verouderde default-waarden zouden worden aangepast in een volgende versie van NIOS, en dat de ondersteuning van SHA-256 in de volgende versie compleet zou worden gemaakt.
Een nieuwe evaluatie van de laatste versie van NIOS (versie 7.3.5) leert ons echter dat er van deze beloften geen enkele is nagekomen. Inmiddels zijn we twee jaar en een major release verder, maar er is op DNSSEC-gebied helemaal niets aangepast of toegevoegd aan de software.
Stilstand is achteruitgang
Twee jaar stilstand betekent in de zich snel ontwikkelende wereld van DNSSEC sowieso achteruitgang. Zo biedt Infoblox helemaal geen ondersteuning voor ECDSA (Elliptic Curve Digital Signature Algorithm), gebaseerd op Elliptic Curve Cryptografie (ECC). Deze algoritmen (nummer 13 en 14) worden sinds maart door SIDN ondersteund.
Omdat ECDSA het DNSSEC-protocol veiliger en korter maakt, wordt het gebruik hiervan sterk aanbevolen. Ook RFC 6944 adviseert het gebruik van algoritmen nummer 13 (ECDSA Curve P-256 with SHA-256) en 14 (ECDSA Curve P-384 with SHA-384), naast nummer 8 (RSA/SHA-256) en 10 (RSA/SHA-512). Met het nog aanbieden van algoritme nummer 1 (RSA/MD5) gaat Infoblox zelfs in tegen het advies van de RFC, waarin staat dat dit algoritme in ieder geval *niet* meer gebruikt moet worden vanwege de bewezen onveiligheid van MD5.
RFC 5011
Een andere feature die dringend aandacht behoeft is de (nog ontbrekende) ondersteuning in NIOS van RFC 5011. Deze standaard voorziet in een protocol waarmee nieuwe trust anchors automatisch en op beveiligde wijze (ondertekend) kunnen worden toegevoegd aan een DNSSEC-validerende resolver.
Dit protocol wordt snel belangrijker naarmate de roll-over van de root KSK-sleutels dichterbij komt. Deze staat nu gepland voor de tweede helft van volgend jaar. Hoewel het technisch geen probleem is om het nieuwe trust anchor voor de root met de hand toe te voegen, zullen beheerders alle systemen die deze update niet automatisch verwerken zelf af moeten lopen.
Geen beste beurt
De reden dat we zo zwaar tillen aan dit alles is drieledig. Ten eerste heeft Infoblox geen beste beurt gemaakt door ondanks de gedane beloften niets aan hun DNSSEC-implementatie te hebben verbeterd.
Ten tweede moeten we een leverancier van appliances de gebrekkige default-instellingen zwaarder aanrekenen. Appliances zijn immers bedoeld om met zo min mogelijk configuratie-inspanningen zo snel mogelijk ingezet te worden. De ervaring leert ook dat default-instellingen meestal blijven staan zoals ze zijn.
Tenslotte zijn degenen die achterlopen met hun DNSSEC-implementaties — banken, overheden en andere grote organisaties — ook relatief vaak Infoblox-gebruikers. De verouderde DNSSEC-implementatie helpt hen niet om deze achterstand in te halen.
De reactie van Infoblox op deze bevindingen geeft ook weinig zicht op verbeteringen. De leverancier geeft geen inhoudelijke reactie, maar laat weten deze problemen op hun prioriteitenlijst te hebben staan en dat ze nog niet hebben besloten wanneer ze de aanpassingen zullen doen.
Aandachtspunten
Voor diegenen die al Infoblox-systemen hebben staan en DNSSEC aan willen zetten, hebben we hier nog de drie belangrijkste aandachtspunten neergezet:
- gebruik voor de beveiliging van extern NTP-verkeer het (inmiddels onveilige) MD5-protocol, zolang er niets beters beschikbaar is
- stel de DNSSEC-algoritmen voor de KSK- en ZSK-sleutelparen in op RSA/SHA-256 (algoritme nummer 8), zolang nummer 13 niet beschikbaar is
- vraag de leverancier om een opwaardering van zijn software!
