ICANN heeft vervangen DNSSEC-sleutels uitgesteld
ICANN, de organisatie die onder andere verantwoordelijk is voor de verdeling van ip-nummers en domeinen, heeft het vervangen van de geheime DNSSEC-sleutels uitgesteld en een nieuwe datum is nog niet gekozen. De reden is dat naar verwachting een aanzienlijk aantal internetgebruikers die dag in de problemen zou zijn gekomen, zo meldt de Stichting Internet Domeinregistratie Nederland (SIDN).
Het was de bedoeling om op 11 oktober het sleutelpaar dat aan de basis ligt van de hele DNSSEC-infrastructuur te vervangen. Dit sleutelpaar is het vertrouwde startpunt voor de validatie van DNSSEC. Het Domain Name System (DNS) is vergelijkbaar met het telefoonboek en vertaalt onder andere domeinnamen naar ip-adressen. DNSSEC is een verzameling extensies voor het DNS-protocol waarmee DNS-informatie digitaal wordt ondertekend. Het moet voorkomen dat internetgebruikers naar malafide websites worden doorgestuurd. Vanwege de veiligheid moet het sleutelpaar regelmatig vervangen worden. Dit is de eerste keer dat dit gebeurt sinds de introductie van DNSSEC in 2010.
Bij zijn beslissing heeft ICANN gebruik gemaakt van statistieken verzameld met het relatief nieuwe RFC 8145-protocol. Daarmee kunnen validerende resolvers aan een server laten weten welke sleutels zij als trust anchor gebruiken bij het opbouwen van de chain of trust. Op die manier krijgen beheerders van ondertekende domeinen informatie over de voortgang van het vervangen van het sleutelpaar. Volgens de meldingen die nu bij beheerders van de rootservers binnenkomen heeft meer dan 5 procent van de rapporterende resolvers alleen het 'KSK-2010 trust anchor' aan boord.
Dat is een probleem, aangezien na de vervangingsoperatie alle internetdomeinen dan onbereikbaar zijn voor gebruikers van resolvers die nog niet van het nieuwe KSK-2017 trust anchor zijn voorzien. Naar schatting maken wereldwijd zo'n 750 miljoen mensen gebruik van een DNSSEC-validerende resolver. De impact van het doorzetten van een roll-over waar de access providers en netwerkbeheerders technisch nog niet klaar voor zijn zou dan ook groot zijn, aldus SIDN. Op dit moment onderzoekt ICANN samen met de technische internetgemeenschap waarom te veel van de validerende resolvers nog niet zijn voorzien van het nieuwe trust anchor.
Maargoed, inmiddels is DNSSEC dusdaning belangrijk dat een overlijden als gevolg van gebrek aan informatie denkbaar is.
Desondanks, ikzelf had niet afgeblazen.
Want andersom is DNSSEC enorm overrated - als in men wenst graag dat het belangrijk zou zijn, maar -helaas- tonen de cijfers slechts marginaal gebruik.
Als ze de key vervangen, raken die systemen ws de weg kwijt en kúnnen ze niet meer updaten...
Catch 22
Nog te veel RC4, nog te veel Poodle, nog te vaak ontbrekende SRI-hashes, certificaat ellende en verkeerde configuraties (niet in de goede volgorde, zwakke ciphers, niet overeenkomstig de SAN, als root op de server geïnstalleerd). Af te voeren script bibliotheken, XSS kwetsbaarheden, php zwakheden, clickjacking, enz. enz. enz.
Om droevig van te worden, maar je kan het niet in ene vervangen, vanwege een update die een paar miljoen lieden zonder internet zou zetten.
Leve de mono-cultuur, leve de slechte educatie, leve het zitten op kennis.
Een (digitale) ideale wereld hebben we nog lang niet.
luntrus
Je had die ellende kunnen besparen door het commando tegelijkertijd naar alle devices te pushen via SNMP, dan had je enkel op de convergence tijd hoeven te wachten met minimale impact.
Je had die ellende kunnen besparen door het commando tegelijkertijd naar alle devices te pushen via SNMP, dan had je enkel op de convergence tijd hoeven te wachten met minimale impact.
Even beter nadenken voordat je denkt dat je 'gelijktijd' kunt doen .
Met een klein beetje timing probleem gaan devices dichterbij je management locatie eerst, en heb je de rest van het netwerk afgesneden omdat de update daar niet meer doorkomt - (goed zo als je out of band management hebt - maar dat is alleen een cli dus geen snmp ).
Mocht je Cisco's in gedachten hebben : je kunt geen 'commando's pushen met snmp' . Je kunt een configuratie fetch initiëren.
De update is bepaald niet atomic, en het device moet de download server (tftp nog vaak) nog kunnen bereiken .
Op nieuwere Cisco IOS versies (en hopelijk ook andere vendors) kun je meerdere keys met een lifetime configureren, en op die manier een nette key rollover doen.
Maar eerste poster heeft absoluut gelijk dat zo'n massale ospf password update een erg complexe operatie was met een heel grote kans op forse verstoringen.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
