Name and shame dus!

Gelukkig heeft de Piratenpartij zijn DNSSEC wel op orde! http://dnssec-debugger.verisignlabs.com/piratenpartij.nl

TheYOSH

Klinkt als https://dnssec-name-and-shame.com/?

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.

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).


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.

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

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.

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/

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/

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 ;)

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.

Dus voor domein security dot nl zie: http://dnsviz.net/d/security.nl/dnssec/
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 .....

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...

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.

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?

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)