image

SIDN luidt noodklok over DNSSEC-beveiliging domeinnamen

dinsdag 21 februari 2017, 11:02 door Redactie, 19 reacties
Laatst bijgewerkt: 21-02-2017, 12:45

De Stichting Internet Domeinregistratie Nederland (SIDN), verantwoordelijk voor de uitgifte van .nl-domeinnamen, luidt de noodklok over de DNSSEC-beveiliging Nederlandse domeinnamen. Het Domain Name System (DNS) is vergelijkbaar met het telefoonboek en vertaalt onder andere domeinnamen naar ip-adressen.

DNSSEC is een extensie van DNS die moet voorkomen dat internetgebruikers naar malafide websites worden doorgestuurd. Het doet dit door DNS-responses via digitale handtekeningen en 'public key cryptography' te authenticeren. Uit onderzoek van SIDN blijkt dat 46 procent van alle .nl-domeinen voorzien van een dergelijke digitale handtekening is voorzien.

Vooral in de bankensector (6 procent) en bij de internetproviders (22 procent) blijft de beveiliging van domeinnamen met DNSSEC achter. In aanloop naar de Tweede Kamerverkiezingen op 15 maart dit jaar heeft SIDN ook de domeinnamen van de politieke partijen, voorlichtingssites en wetenschappelijke bureaus meegenomen in de inventarisatie. Ruim de helft (54 procent) van de 74 onderzochte domeinen heeft de DNSSEC-beveiliging niet op orde.

"Als een domeinnaam niet met deze beveiliging is uitgerust, bestaat de kans dat gebruikers zonder dat ze het weten worden omgeleid naar een namaakwebsite waar valse informatie wordt gepubliceerd. Daarnaast vormt DNSSEC de basis voor nieuwe toepassingen, zoals het veiliger maken van e-mail en het eenvoudig delen van cryptografische sleutels om internetcommunicatie te beveiligen", aldus SIDN.

De stichting hekelt vooral het feit dat banken hun implementatie niet op orde hebben. "Banken zouden de belangrijkste gebruikers moeten zijn van DNSSEC-beveiliging, maar zij scoren voor de tweede keer op rij het slechtst van alle onderzochte domeinnamen. Met het sluiten van de fysieke bankkantoren en het verminderen van het aantal pinautomaten wordt de online voordeur van de banken steeds belangrijker”, aldus Roelof Meijer, algemeen directeur SIDN.

Reacties (19)
21-02-2017, 11:44 door Anoniem
Name and shame dus!
21-02-2017, 11:56 door Anoniem
Gelukkig heeft de Piratenpartij zijn DNSSEC wel op orde! http://dnssec-debugger.verisignlabs.com/piratenpartij.nl

TheYOSH
21-02-2017, 12:09 door Anoniem
Door Anoniem: Name and shame dus!
Klinkt als https://dnssec-name-and-shame.com/?
21-02-2017, 12:23 door Anoniem
Inderdaad "name and shame" want zeker financiële instellingen moet hier aan.

In de phisingmails staan heel andere links naar sites dus daar helpt dit allemaal niets. Pas als site zelf gekaapt wordt dan zal de browser moeten aangeven dat het niet klopt. Wij kunnen allemaal wel netjes DNSSEC implementeren maar zolang het in de praktijk niets in de browser mee gedaan wordt is het nutteloos.

Zelf gebruik ik DNS-validator.cz maar die wordt alleen nog maar gebug-fixed en hier zou SIDN in de samenwerking met CZ.cz meer kunnen doen en de maker van browser pushen dit meteen goed te regelen.
21-02-2017, 12:37 door Anoniem
Ik zou het ook graag anders zien, maar DNSSEC heeft nogal wat cruciale "probleempjes":
- is er iets mis met de domeininformatie dan "verdwijnt" de website
- cryptografisch gezien al enigszins verouderd en niet erg flexibel
- aanvulling op cruciale infrastructuur en dus redelijk complex om in te voeren (aanpassen softwarebibliotheken en servers, meer verkeer, risico tot asymmetrische stromen, mogelijkheid tot ander transportprotocol)
- makkelijkere en sterkere alternatieven die wel het end-to-end principe in stand houden (voor websites HSTS met preloading en/of HPKP en in het algemeen Googles certificate transparency)

Het is erg belangrijk dat DNS beveiligd wordt/kan worden, maar de vraag is ten koste van wat? Als misconfiguratie vaker voorkomt dan DNS hijacking of als het gewoon meer kost / meer schade berokkend dan moet je je afvragen of het wel een goed idee is, helemaal als het alternatief goed genoeg is. Persoonlijk denk ik dat DNSSEC minimaal een koppeling met de applicatielaag moet krijgen zodat gebruikers een specifieke melding en keuze **kunnen** krijgen bij een niet te valideren domein, anders zullen ISPs het liever niet invoeren en heb je er nog niets aan. Dan zijn er natuurlijk nog de inherente technische uitdagingen om het echt goed te maken (veilig en performant).

Banken zouden de belangrijkste gebruikers moeten zijn van DNSSEC-beveiliging, maar zij scoren voor de tweede keer op rij het slechtst van alle onderzochte domeinnamen. Met het sluiten van de fysieke bankkantoren en het verminderen van het aantal pinautomaten wordt de online voordeur van de banken steeds belangrijker

En hier wringt de schoen van DNSSEC dan ook. Internetbankieren moet werken. Als het niet werkt dan verliest men klanten en geld. De dienst is al complex genoeg en ligt er regelmatig uit. Bij een storing is dat nieuws. Wanneer iemands internetverbinding gehackt wordt dan is de impact voor de banken een stuk lager en is het geen groot nieuws (het komt ook nog eens een stuk minder voor en DNSSEC verhelpt dit probleem niet eens helemaal). De kans dat iemands computer of de internetbankieren-dienst zelf aan cybercriminaliteit ten prooi valt is een stuk groter dus daar gaat dan ook meer aandacht naar uit.

De analogie met de bankkantoren: als de authenticiteit van de kaart met de locaties van bankkantoren niet valt vast te stellen dan kan je nog steeds de locaties zien en ze bereiken. Voor eindgebruikers is dat met DNSSEC niet meer mogelijk, ze weten niet eens dat de kaart mogelijk niet klopt en vervalst is, hij verdwijnt gewoon volledig.

Zolang er meer (beveiligings)winst op andere vlakken te halen valt zal daar de aandacht naar uitgaan. Zorg ervoor dat DNSSEC nuttiger en praktischer wordt en men zal er meer mee doen.
21-02-2017, 12:57 door Anoniem
Door Anoniem: Name and shame dus!
Zoals https://dnssec-name-and-shame.com/domain/security.nl
21-02-2017, 14:20 door devias
... En hier wringt de schoen van DNSSEC dan ook. Internetbankieren moet werken. Als het niet werkt dan verliest men klanten en geld. De dienst is al complex genoeg en ligt er regelmatig uit. Bij een storing is dat nieuws. ...

Volgens mij wil je helemaal niet dat dat werkt als 't gehacked is...
21-02-2017, 15:12 door Anoniem
Door devias:
... En hier wringt de schoen van DNSSEC dan ook. Internetbankieren moet werken. Als het niet werkt dan verliest men klanten en geld. De dienst is al complex genoeg en ligt er regelmatig uit. Bij een storing is dat nieuws. ...

Volgens mij wil je helemaal niet dat dat werkt als 't gehacked is...
En laat daar mijn kritiek helemaal niet over gaan. Ik heb het juist over de situatie waar het niet gehackt is maar er een foutje in de configuratie is geslopen. Goede beheertools helpen dit te voorkomen maar niet (helemaal) te verhelpen en dit soort problemen en onzekerheden (risico's) zitten de succesvolle uitrol in de weg. Mocht het dan toch echt gehackt zijn dan wil je ook dat je gebruikers een melding krijgen te zien in hun browser of app zodat ze weten dat er bij de site of hun verbinding mogelijk een beveiligingsprobleem aanwezig is (goh, net als bij TLS, toch wel zo handig hè) in plaats dat ze een andere verbinding zonder DNSSEC raadplegen en daar hun zaakjes doen terwijl ze dan mogelijk verbinden met de site van criminelen. Als het een foute configuratie betreft dan wil je in veel gevallen over uitwijkmogelijkheden beschikken, zoals het negeren van de fout (bij banken natuurlijk liever niet en ook valt dit voor gewone gebruikers af te raden maar als je DNSSEC+DANE bij allerlei websites wil gaan gebruiken in plaats van TLS dan is dit wenselijk). Biedt je dit soort mogelijkheden niet dan maak je het kip-ei-probleem alleen nog maar erger.
21-02-2017, 15:28 door Anoniem
Ja en er moet soms voor betaald worden. Denk aan problemen bij GoDaddy etc.

Ondersteunt de hoster het wel? Geeft https daar dan al voldoende bescherming.

Doe je het dnssec-management zelf of besteed je het uit?
Bewaar de sleutels a.u.b. buiten de server. Zit alles goed met de zone transfers?

Check hier: https://dnssec-debugger.verisignlabs.com/ en hier: http://dnsviz.net/
21-02-2017, 16:01 door Anoniem
Voor de liefhebber een aardige plug-in om direct te kunnen zien of het domein dat je bezoekt SEC is.
DNSSEC/TLSA validator: https://www.dnssec-validator.cz/
21-02-2017, 16:40 door Anoniem
Door Anoniem:
Door Anoniem: Name and shame dus!
Zoals https://dnssec-name-and-shame.com/domain/security.nl

https://dnssec-name-and-shame.com/domain/www.security.nl
21-02-2017, 16:50 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Name and shame dus!
Zoals https://dnssec-name-and-shame.com/domain/security.nl

https://dnssec-name-and-shame.com/domain/www.security.nl

Ja maar ik ga altijd via https://security.nl welke wel weer redirect naar https://www.security.nl

Maar security.nl moet dan natuurlijk ook DNSSEC hebben... hoe moeilijk kan het nu zijn ;)
21-02-2017, 17:32 door Anoniem
DNSSEC kan moeilijker zijn dan het lijkt, en het is zeker niet zo simpel als soms wordt gedacht ('bind, powerdns, etc ondersteunen het, dus het is niet moeilijk'). Probeer eens domein delegaties van provider 1 naar provider 2... Inmiddels al jaren mee bezig maar de TLD provider (echt een hele grote!) krijgt het niet voor elkaar.
21-02-2017, 17:53 door Anoniem
Dus voor domein security dot nl zie: http://dnsviz.net/d/security.nl/dnssec/
Insecure (4)
security.nl/A
security.nl/MX
security.nl/NS
security.nl/SOA
Delegatie: 1 - nl to security.nl

Meer spoofing mogelijk: Check SPF record
WARNING: Domain doesn't have SPF record. SPF (Sender Policy Framework) record is designed to prevent e-mail spoofing. Typical SPF record would be:
v=spf1 a mx ~all or v=spf1 a mx include:_spf.google.com ~all if you are using Google Apps.
21-02-2017, 20:30 door Anoniem
Door Anoniem: Dus voor domein security dot nl zie: http://dnsviz.net/d/security.nl/dnssec/
Insecure (4)
security.nl/A
security.nl/MX
security.nl/NS
security.nl/SOA
Delegatie: 1 - nl to security.nl

Meer spoofing mogelijk: Check SPF record
WARNING: Domain doesn't have SPF record. SPF (Sender Policy Framework) record is designed to prevent e-mail spoofing. Typical SPF record would be:
v=spf1 a mx ~all or v=spf1 a mx include:_spf.google.com ~all if you are using Google Apps.

DNSSEC lijkt inmiddels gefixed

http://dnsviz.net/d/security.nl/dnssec/

Nog steeds geen SPF echter .....
22-02-2017, 09:42 door Anoniem
Door Anoniem: Ik zou het ook graag anders zien, maar DNSSEC heeft nogal wat cruciale "probleempjes":
- is er iets mis met de domeininformatie dan "verdwijnt" de website
- cryptografisch gezien al enigszins verouderd en niet erg flexibel
- aanvulling op cruciale infrastructuur en dus redelijk complex om in te voeren (aanpassen softwarebibliotheken en servers, meer verkeer, risico tot asymmetrische stromen, mogelijkheid tot ander transportprotocol)
- makkelijkere en sterkere alternatieven die wel het end-to-end principe in stand houden (voor websites HSTS met preloading en/of HPKP en in het algemeen Googles certificate transparency)

Klopt inderdaad!

In security moet je niet focussen op 1 bepaalde vulnerability, maar het gehele plaatje zien.
Iedere wijziging die je maakt heeft steeds voor-, maar ook nadelen.

DNSSEC is inderdaad een oplossing om DNS hijacking tegen te gaan, maar het stelt je infrastructuur ook bloot aan DoS aanvallen.
Daarnaast moet je client het ook ondersteunen, en je client moet goed functioneren.

m.a.w., zelfs als wordt voor een bepaald domein DNSSEC gebruikt, dan nog is het volledig afhankelijk van de client en zijn lokale infrastructuur (Client met malware, gehackte router, etc...)
Voor de meeste security/oplichtings issues bij banken is dat laatste een probleem en dat los je niet op met DNSSEC.

Heel vaak heeft DNSSEC dus geen toegevoegde waarde.
Het biedt geen voordelen voor de actuele problemen, maar het heeft wel het potentieel om er een heleboel nieuwe bij te creëren. Die nieuwe problemen moet je ook incalculeren.

Dit is ook waar voor een heleboel andere dingen, vb HTTPS. Alhoewel het gebruik van HTTPS vrij simpel is, creëer je ook een deel nieuwe problemen, zoals key management, etc...
22-02-2017, 16:23 door Anoniem
Ik denk dat het het voornamelijk wachten is op de ondersteuning op de clients en internetproviders.
Zolang de browser, de client resolver en de resolvers op in die verschillende routers het allemaal niet ondersteunen dan heeft DNSSEC helemaal geen toegevoegde waarde.
Daarbij wordt er niet vermeld wat voor ellende je kan krijgen als er een probleem is ergens in de keten waarbij je domein dan ineens niet meer bereikbaar is. Daar ga je dan met je reputatie.
23-02-2017, 01:34 door Anoniem
En zo zitten we maar steeds op oplossingen te wachten. Nog 60% moet er over op https. Hier ook weer wachten tot het eindelijk volledig kan worden uitgerold net als bij veel Nederlandse providers met IPv6. Eerst weer van centen koperdraad willen trekken zeker.....

Hoe lang gaat het nog duren voor M$ eindelijk het probleem met de onzichtbaarheid van dubbele extensies oplost?
Hoe lang wachten we daar nu al op. Ik hoorde van 'n insider uit Florida dat het nu niet zo heel lang meer gaat duren,
dat ze per default zichtbaar worden.

Als we in zo'n slakkengang naar een iets veiliger infrastructuur moeten hobbelen, geef mijn portie dan maar aan fikkie.

Altijd zei men te ver gezocht, maar het lijkt er warempel wel op dat sommige "gevestigde interesses" het liever toch wat aan de onveilige kant willen houden. Hoe moet je het anders verklaren.

En het onderwijs doet er ook niet te veel aan. Ik vroeg laats aan eerste jaars HBO informatica studenten of ze wel eens gehoord hadden van DNSSEC, SRI hashes, security header implementatie, retirable jQuery libraries, left code, inline javascripting en andere onveiligheid. Antwoord: "Mijnheer we weten totaal niet waar u het over hebt".

Mooi daar ga je dan met je Nederlandse infrastructuur veiligheid van de toekomst. Ja, ze krijgen het wel als technische IT en via een specialistische opleiding. Te weinig en te laat om echt zoden aan de digitale dijk te zetten.

Een van de studenten die af en toe wat bij kluste bij een hosting firma, zei nog tegen me: "Maar mijnheer daar hebben we toch een security officer voor in dienst". En als hij, de student of zijn baas, er niets van afweten, wie controleert dan uiteindelijk de competentie en het vakmanschap van die betreffende security officer en of deze niet af en toe een oogje dichtknijpt? Want we kennen het gezegde: "Om de smeer likt de kat de kandeleer!".

Opnieuw, daar ben je mooi klaar mee, wachten op de volgende grote data breach?
Wat vind men hier op security.nl eigenlijk van de problematiek rond de onveilige infrastructuur?
24-02-2017, 14:39 door musiman
Als IT docent laat ik mijn cursisten heel vaak zien dat met name de banken nog steeds geen DNSSEC geïmplementeerd hebben. Ik heb vaak medewerkers van diverse Nederlandse banken in mijn trainingen en keer op keer kaart ik dit aan.
Tja, wat kan ik nog meer doen?

(uiteraard hebben wij als security training bedrijf wél onze DNSSEC op orde. ;o)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.