ICANN roept op tot uitrol DNSSEC wegens dns-kapingen
ICANN, de organisatie die onder andere verantwoordelijk is voor de verdeling van ip-nummers en domeinen, heeft organisaties wereldwijd opgeroepen om DNSSEC uit te rollen. Aanleiding zijn recente berichten dat aanvallers wereldwijd de dns-instellingen van domeinen van bedrijven en overheden hebben aangepast om zo gevoelige gegevens te stelen.
Om de dns-instellingen van de domeinen aan te passen maken de aanvallers gebruik van gecompromitteerde inloggegevens. Via deze gegevens kunnen de aanvallers inloggen bij een dns-provider en een ander ip-adres voor bijvoorbeeld de website of mailserver van het slachtoffer opgeven. Het verkeer van gebruikers van de aangevallen organisaties loopt zo eerst via de server van de aanvallers. De aanvaller kan daarnaast vertrouwde certificaten voor de domeinnamen aanvragen en daarmee het netwerkverkeer onderscheppen.
Volgens ICANN vormen deze aanvallen een risico voor belangrijke delen van de domain name system (dns)-infrastructuur. Deze specifieke aanvallen werken alleen als DNSSEC niet wordt gebruikt, zo laat de organisatie weten. Domain Name System Security Extensions (DNSSEC) is een verzameling extensies voor het dns-protocol waarmee dns-informatie digitaal wordt ondertekend wat moet voorkomen dat internetgebruikers naar malafide websites worden doorgestuurd.
"Hoewel DNSSEC niet alle soorten aanvallen tegen het dns kan oplossen, zorgt het er wel voor dat ongeautoriseerde aanpassingen van dns-informatie zijn te ontdekken, en gebruikers niet de verkeerde richting op worden gestuurd", aldus ICANN. De organisatie stelt afsluitend dat alle leden van het dns-ecosystemen moeten samenwerken om betere tools en beleid te ontwikkelen om dns en andere belangrijke functies van het internet te beschermen.
Reacties (26)
Voor DNSSEC moet je toch ook iets installeren/activeren op je desktop pc? In elk geval in pi-hole moet je iets activeren als ik me kan herinneren. Het is al lang geleden dat ik nog iets met pi-hole heb gedaan, dus ik weet niet zeker.
Leuk dat ICANN't het roept, maar helemaal neutraal zijn ze er nou ook weer niet in. Het betekent meer macht voor hunnie en daarmee voor de (overheid van) de VS van Amerika. En ja, als je op globale schaal met kritieke infrastructuur aan het klooien bent, dan komt geopolitiek al snel om de hoek kijken. Technisch is er dan nog het probleem dat DNSsec slecht aansluit bij de meestvoorkomende vragen, namelijk "doe me eens een adres voor deze naam, wil je". DNSsec gaat dan eerst de integriteit van de hele domeininhoud van alle lagen eronder ook nog nakijken. Dat schaalt slecht.
Wat dat betreft is DNSsec een technological failure op dezelfde manier als IPv6 dat ook is: Ja, het bestaat, en ja het wordt her en der wel gebruikt, maar tjongejonge wat is dat met de uptake toch lastig. Dat is het tegenovergestelde van wat je wil, namelijk dat iedereen opstaat en roept "hee wat een goed idee" en mee gaat doen. Nu ICANN't weer: "Toe nou jongons, doe toch eens meedoen hee, asjeblief nou". Ja ja tuurlijk Sjakie, strakkies meschien.
Wat dat betreft is DNSsec een technological failure op dezelfde manier als IPv6 dat ook is: Ja, het bestaat, en ja het wordt her en der wel gebruikt, maar tjongejonge wat is dat met de uptake toch lastig. Dat is het tegenovergestelde van wat je wil, namelijk dat iedereen opstaat en roept "hee wat een goed idee" en mee gaat doen. Nu ICANN't weer: "Toe nou jongons, doe toch eens meedoen hee, asjeblief nou". Ja ja tuurlijk Sjakie, strakkies meschien.
DNSSEC bied geen enkele bescherming op het moment dat een aanvaller de inloggegevens van de DNS provider heeft en deze de records met DNSSEC ondertekend. Wat wel helpt is als DNS provider goede 2FA mogelijkheden aanbieden. Op dit moment ben ik alleen bekend met Gandi en Google DNS waarbij er via U2F ingelogd kan worden. Laat DNS providers eerst de inlog eens op orde hebben voor ze DNSSEC uitrollen.
Het hele idee dat DNSSEC je beschermd tegen verkeerde records valt in de praktijk ook best mee. Als je via DHCP een DNS server krijgt moet je maar hopen dat die toevallig de records valideert. Als je op een publiek wifi netwerk zit is de last mile niet beschermd, waarmee je nog steeds onbeschermd bent. DNSSEC is pas veilig als je zelf de validatie uitvoert. Echter mag duidelijk zijn dat de grote tech bedrijven het er niet zo mee hebben en ik verwacht niet dat dat op korte termijn gaat veranderen. De DNSSEC chain extensie was een aardige poging, maar dat is uiteindelijk niks geworden.
Dat wil natuurlijk niet zetten dat de uitrol niet goed zou zijn, alle beetjes helpen, maar de toegevoegde waarde van DNSSEC wordt zwaar overschat. En dan te bedenken dat er mensen zijn die hun certificaat validatie (DANE) willen overlaten aan een random DNS server die via DHCP is verkregen op een publieke hotspot, bevraagd wordt over een plaintext verbinding en je dan verteld dat je het certificaat voor de website van je bank veilig is... Nee bedankt!
Het hele idee dat DNSSEC je beschermd tegen verkeerde records valt in de praktijk ook best mee. Als je via DHCP een DNS server krijgt moet je maar hopen dat die toevallig de records valideert. Als je op een publiek wifi netwerk zit is de last mile niet beschermd, waarmee je nog steeds onbeschermd bent. DNSSEC is pas veilig als je zelf de validatie uitvoert. Echter mag duidelijk zijn dat de grote tech bedrijven het er niet zo mee hebben en ik verwacht niet dat dat op korte termijn gaat veranderen. De DNSSEC chain extensie was een aardige poging, maar dat is uiteindelijk niks geworden.
Dat wil natuurlijk niet zetten dat de uitrol niet goed zou zijn, alle beetjes helpen, maar de toegevoegde waarde van DNSSEC wordt zwaar overschat. En dan te bedenken dat er mensen zijn die hun certificaat validatie (DANE) willen overlaten aan een random DNS server die via DHCP is verkregen op een publieke hotspot, bevraagd wordt over een plaintext verbinding en je dan verteld dat je het certificaat voor de website van je bank veilig is... Nee bedankt!
Want jij weet t beter dan ICANN. Helaas weet ik nog wel een paar scenario’s te bedenken die je ongelijk geven. Bijv als de DNS provider alleen de slave DNS zone beheert en de master bij de eigenaar staat (ongepubliceerd).
Op deze site https://internet.nl/connection kun je eenvoudig testen of jouw DNS server DNSSEC ondersteunt.
24-02-2019, 12:50 door
Briolet
Bij Hostnet kun je ook voor een 2FA inlog kiezen en ze ondersteunen ook DNSSEC.
Ik laat mijn domein via een CNAME doorverwijzen naar een DDNS provider die ook DNSSEC ondersteunt. Toch geeft internet.nl aan dat er geen DNSSEC gebruikt wordt. Volgens internet.nl moet dit bij een CNAME wel mogelijk zijn.
Bij de individuele adressen zonder CNAME doorverwijzing geeft internet.nl wel aan dat alles klopt.
Iemand enig idee of ik wat kan doen, of dat het bij Hostnet mis gaat bij de doorverwijzing.
Ik laat mijn domein via een CNAME doorverwijzen naar een DDNS provider die ook DNSSEC ondersteunt. Toch geeft internet.nl aan dat er geen DNSSEC gebruikt wordt. Volgens internet.nl moet dit bij een CNAME wel mogelijk zijn.
Bij de individuele adressen zonder CNAME doorverwijzing geeft internet.nl wel aan dat alles klopt.
Iemand enig idee of ik wat kan doen, of dat het bij Hostnet mis gaat bij de doorverwijzing.
Bij een cname krijg je een ketting waarbij elke naam in de ketting wordt opgevraagd. Als je geen flattend-cname/alias hebt, zal dus elk record dnssec record moeten hebben ipv slechts de eerste.
Dit zal waarschijnlijk jouw probleem zijn. Ik kan aanraden om simpelweg je domeinnaannaam bij bijv cloudflare neer te zetten voor DNS beheer. Dan heb je tevens anti-ddos, en tls-terminering etc. En standaard ondersteuning voor alias/cname en apex flattening zonder dat het je ip exponeerd (zolang je geen gigantische aanvallen krijgt)
Dit zal waarschijnlijk jouw probleem zijn. Ik kan aanraden om simpelweg je domeinnaannaam bij bijv cloudflare neer te zetten voor DNS beheer. Dan heb je tevens anti-ddos, en tls-terminering etc. En standaard ondersteuning voor alias/cname en apex flattening zonder dat het je ip exponeerd (zolang je geen gigantische aanvallen krijgt)
Door Anoniem: Want jij weet t beter dan ICANN. Helaas weet ik nog wel een paar scenario’s te bedenken die je ongelijk geven. Bijv als de DNS provider alleen de slave DNS zone beheert en de master bij de eigenaar staat (ongepubliceerd).
Want als ik jouw inloggegevens heb buitgemaakt kan ik niet inloggen?
Die logica snap ik niet.
Door Anoniem: Helaas weet ik nog wel een paar scenario’s te bedenken die je ongelijk geven. Bijv als de DNS provider alleen de slave DNS zone beheert en de master bij de eigenaar staat (ongepubliceerd).
De aanvallen gaan om DNSpionage, waarbij iemand die je niet vertrouwd administrator rechten krijgt en dan aanpassingen op het domein kan doen. Dat je DNSSEC kan gebruiken om achteraf te kunnen zien dat iemand die je vertrouwde of mogelijk iemand anders met je zone heeft geknoeid maakt niet dat DNSSEC voorkomt dat iemand met je zone kan knoeien. Sterker nog, ICANN verwijst zelf naar dat artikel van Brian Krebs waar duidelijk in staat dat DNSSEC alleen in specifieke gevallen kan helpen. Maar ICANN maakt er van alsof het gebruik van DNSSEC op zich de aanval voorkomt. En dat is dus volstrekte onzin. Terecht dus dat er kritiek is.Als ik bij vyprvpn kijk dan bieden hun mij een beveiligde DNS aan om juist DNS kaping tegen te gaan. Ik maak daar graag gebruik van en denk zo dat ik goed beveiligd ben. Is mijn denkwijze correct? Is deze provider van beveiligde DNS te vertrouwen?
Misschien kan er eens een goed alternatief voor DNS bedacht worden. Want altijd maar dat punt nl en punt com, eigenlijk is dat heel lelijk. Ouderwets. En qua stylng en design geen gezicht meer. Het is altijd al lelijk geweest alleen toen kon het niet anders.
Er moet iets beters te bedenken zijn dat mooier is en waar niet mee te rotzooien valt. En wat efficient werkt. De spullen van nu zijn veel krachtier dan uit de tijd dat DNS bedacht werd. Ze staan echter stijf van ballast uit het verleden te corrigeren voor gevaren die destijds geen thema waren. En er wordt alleen maar meer bij ge-update. Het performance gevoel van de gebruiker is ondanks alle enorme vooruitgang in resources geen spat verbeterd. Wat eigenlijk de hele softwareindustrie tot de meest spectaculaire kwakzalverij uit de geschiedenis maakt. Tot nu toe. Het is pleisters met helende krachten, homeopathische verdunningen en voorlopig blijf je chronisch ziek. Want dan heb je de dokter weer extra nodig. En die vreet daar altijd nog het beste van. Plus twee keer per jaar op wintersport.
Daar moeten toch betere oplossingen bedenkbaar zijn? Als de mensen uit de tijd van het bedenken van DNS zouden weten wat er nu allemaal onder je motorkap draait, en hoe we dat verprutsen, ze zouden je waarschijnlijk slaan.
Er moet iets beters te bedenken zijn dat mooier is en waar niet mee te rotzooien valt. En wat efficient werkt. De spullen van nu zijn veel krachtier dan uit de tijd dat DNS bedacht werd. Ze staan echter stijf van ballast uit het verleden te corrigeren voor gevaren die destijds geen thema waren. En er wordt alleen maar meer bij ge-update. Het performance gevoel van de gebruiker is ondanks alle enorme vooruitgang in resources geen spat verbeterd. Wat eigenlijk de hele softwareindustrie tot de meest spectaculaire kwakzalverij uit de geschiedenis maakt. Tot nu toe. Het is pleisters met helende krachten, homeopathische verdunningen en voorlopig blijf je chronisch ziek. Want dan heb je de dokter weer extra nodig. En die vreet daar altijd nog het beste van. Plus twee keer per jaar op wintersport.
Daar moeten toch betere oplossingen bedenkbaar zijn? Als de mensen uit de tijd van het bedenken van DNS zouden weten wat er nu allemaal onder je motorkap draait, en hoe we dat verprutsen, ze zouden je waarschijnlijk slaan.
Door Anoniem: Misschien kan er eens een goed alternatief voor DNS bedacht worden. Want altijd maar dat punt nl en punt com, eigenlijk is dat heel lelijk. Ouderwets. En qua stylng en design geen gezicht meer. Het is altijd al lelijk geweest alleen toen kon het niet anders.
Ha, dacht je dat. Ga maar eens kijken wat het origineel was waar DNS de vervanging voor is.Precies, het hosts-bestand. IPadres, naam. Zonder punten. En hoe verspreid je dat? Nou, op een "well-known" IPadres kun je een nieuwe halen. En dat deden administrateurs dan ook, af en toe, als er weer eens een nieuwe machine op het 'net aangesloten werd. En dat wist je wel want de gemeenschap was maar klein. Maarja, toen er meerdere keren per dag wijzigingen in dat bestand werden gemaakt werd dat al snel onhoudbaar. Dus DNS, een gedistribueerde database. Dus die punten: Je hopt van de ene server naar de andere die je de vertelt waar je moet zijn voor de volgende stap.
Dus als je dat eruit wil hebben want "ouderwets", ga je eigenlijk weer terug naar de tijd voor DNS. Dan moeten de root servers van alle namen weten welk adres er bijhoort. Die moeten dan dus een stuk meer werk verzetten. Mischien kan het wel hoor, maar dan krijg je dus weer een soort AOL keywords.
Er moet iets beters te bedenken zijn dat mooier is en waar niet mee te rotzooien valt. En wat efficient werkt.
Doe eens een voorstel. Maar mischien eerst even inlezen hoe DNS nou precies werkt? Ik ben wel met je eens dat DNSsec ook het antwoord niet is (maar om andere redenen), maar verzin maar eens een goed alternatief.Door Anoniem: Want jij weet t beter dan ICANN. Helaas weet ik nog wel een paar scenario’s te bedenken die je ongelijk geven. Bijv als de DNS provider alleen de slave DNS zone beheert en de master bij de eigenaar staat (ongepubliceerd).
DNSSEC voorkomt inderdaad in een zeer beperkt aantal gevallen deze aanval. Het lijkt mij dat een degelijke beveiliging van het DNS beheer paneel in een stuk meer gevallen bescherming zou bieden en daarom als betere oplossing gezien moet worden. DNSSEC is (dan) pas nuttig als je slachtoffer wordt van een MITM aanval, daar lijkt hier geen sprake van.
Door Anoniem: Als ik bij vyprvpn kijk dan bieden hun mij een beveiligde DNS aan om juist DNS kaping tegen te gaan. Ik maak daar graag gebruik van en denk zo dat ik goed beveiligd ben. Is mijn denkwijze correct? Is deze provider van beveiligde DNS te vertrouwen?
Waarschijnlijk wordt er hier 'DNS leak protection' bedoeld. Dat staat los van DNSSEC validatie. Voor validatie kun je het beste, zoals Linux4 al noemde, https://internet.nl/connection bekijken. Als je ook nog wilt weten welke signatures de DNS server begrijpt kan je naar https://rootcanary.org/test.html gaan.
Door Anoniem: Misschien kan er eens een goed alternatief voor DNS bedacht worden. Want altijd maar dat punt nl en punt com, eigenlijk is dat heel lelijk. Ouderwets. En qua stylng en design geen gezicht meer. Het is altijd al lelijk geweest alleen toen kon het niet anders.
DNS is nog steeds een prima systeem. Redelijk decentraal door het delegeren van zones, dat is nou juist de kracht er van. Je kan .nl en .com misschien niet leuk vinden, maar een universele naamgeving is en blijft lastig om goed te doen.
Door Anoniem: Als ik bij vyprvpn kijk dan bieden hun mij een beveiligde DNS aan om juist DNS kaping tegen te gaan. Ik maak daar graag gebruik van en denk zo dat ik goed beveiligd ben. Is mijn denkwijze correct? Is deze provider van beveiligde DNS te vertrouwen?
Ik zou het eerder als onbetrouwbaarder beschouwen. Je hebt werkelijk geen idee hoe goed of hoe slecht de omgeving in elkaar zit. En VPN treks ook een hoop ongure types aan, die ook deze DNS gebruiken.
Ik zou meer vertrouwen hebben in mijn IPS DNS of eventueel mijn eigen DNS server.
Door Briolet: Bij Hostnet kun je ook voor een 2FA inlog kiezen en ze ondersteunen ook DNSSEC.
Stel je DNSSEC werkt (straks) goed en die 2FA werkt om in te loggen. Maar dan is er een hacker die door een beveiligingslek bij hostnet alsnog je domein en je DNSSEC-instellingen kan aanpassen. Niet ondenkbaar. De voorbeelden van het probleem waar de ICANN het over heeft gaan om dat soort fouten. Wat gaat dat DNSSEC jou dan helpen? Denk je dat de hele wereld het erg gaat vinden als je records keurig in orde zijn omdat de hacker je domein echt in handen heeft? Of dat iemand er maar iets om zal geven dat de hacker DNSSEC via je admin panel even uit zet?Het probleem is niet dat we geen DNSSEC hebben maar dat er te veel vertrouwen is in de veiligheid van de hosters en de admin panels die toegang geven tot de domeinen. 2FA werkt alleen goed als er geen fouten in die panels zitten en de hoster voor toegang tot het admin panel van je domein even goede of betere beveiliging heeft.
Als een fax of telefoontje naar de hoster om je domein even aan te passen werkt helpt 2FA of DNSSEC niet tegen deze domein hackers. Als een hacker via een fout in het panel je records officieel kan wijzigen heeft die 2FA of DNSSEC geen zin tegen de aanval. Als je hacker met een MITM aanval je 2FA van je admin krijgt en live kan inloggen helpt het ook niet. Staar je dus niet blind op de 2FA of DNSSEC maar vraag je af waarom je vertrouwen in je hoster van je domein hebt en of dat gegrond is.
Door Anoniem:
Precies, het hosts-bestand. IPadres, naam. Zonder punten. En hoe verspreid je dat? Nou, op een "well-known" IPadres kun je een nieuwe halen. En dat deden administrateurs dan ook, af en toe, als er weer eens een nieuwe machine op het 'net aangesloten werd. En dat wist je wel want de gemeenschap was maar klein. Maarja, toen er meerdere keren per dag wijzigingen in dat bestand werden gemaakt werd dat al snel onhoudbaar. Dus DNS, een gedistribueerde database. Dus die punten: Je hopt van de ene server naar de andere die je de vertelt waar je moet zijn voor de volgende stap.
Dus als je dat eruit wil hebben want "ouderwets", ga je eigenlijk weer terug naar de tijd voor DNS. Dan moeten de root servers van alle namen weten welk adres er bijhoort. Die moeten dan dus een stuk meer werk verzetten. Mischien kan het wel hoor, maar dan krijg je dus weer een soort AOL keywords.
Door Anoniem: Misschien kan er eens een goed alternatief voor DNS bedacht worden. Want altijd maar dat punt nl en punt com, eigenlijk is dat heel lelijk. Ouderwets. En qua stylng en design geen gezicht meer. Het is altijd al lelijk geweest alleen toen kon het niet anders.
Ha, dacht je dat. Ga maar eens kijken wat het origineel was waar DNS de vervanging voor is.Precies, het hosts-bestand. IPadres, naam. Zonder punten. En hoe verspreid je dat? Nou, op een "well-known" IPadres kun je een nieuwe halen. En dat deden administrateurs dan ook, af en toe, als er weer eens een nieuwe machine op het 'net aangesloten werd. En dat wist je wel want de gemeenschap was maar klein. Maarja, toen er meerdere keren per dag wijzigingen in dat bestand werden gemaakt werd dat al snel onhoudbaar. Dus DNS, een gedistribueerde database. Dus die punten: Je hopt van de ene server naar de andere die je de vertelt waar je moet zijn voor de volgende stap.
Dus als je dat eruit wil hebben want "ouderwets", ga je eigenlijk weer terug naar de tijd voor DNS. Dan moeten de root servers van alle namen weten welk adres er bijhoort. Die moeten dan dus een stuk meer werk verzetten. Mischien kan het wel hoor, maar dan krijg je dus weer een soort AOL keywords.
Er moet iets beters te bedenken zijn dat mooier is en waar niet mee te rotzooien valt. En wat efficient werkt.
Doe eens een voorstel. Maar mischien eerst even inlezen hoe DNS nou precies werkt? Ik ben wel met je eens dat DNSsec ook het antwoord niet is (maar om andere redenen), maar verzin maar eens een goed alternatief.Ik weet hoe DNS werkt en ook hoe het oude hosts bestand in elkaar zit.
Ik heb echter geleerd dat je bestaande problemen vaak op kan lossen door dieper in de werking (en ook in de historie) te duiken.
Maar dat je dan weer ook hele nieuwe ideeën komt door daar helemaal afstand van te nemen. Er vanuit te gaan dat er nog niks bestond.
Gedachte 1 is patch op patch op pleister op alabastine. En dan nog wat photoshoppen dat je de ouwe scheuren helemaal niet meer ziet.
Gedachte 2 prikkelt de creativiteit, met de spullen van nu.
Wat 2 betreft niet meteen een concrete gedachte, dus balletje opgooien, want ik ben niet de enige met een creatieve geest. DNS is als de oude telefoongids. Die telefoongids bestaat ook niet meer. En toch weten we elkaar te vinden. Die richting denk ik meer op. Als nu iemand de oude telefoongids wil aanvallen, ik zou er geen last meer van hebben. Al steken ze er hele pallets van in de fik.
Ik noem het om mee te denken. Ik speelde al met processors toen het hosts bestand nog niet eens bestond. Ook lekker belangrijk. Creatieve geesten prikkelen, veel belangrijker.....
Er zijn ook andere manieren: https://cleanbrowsing.org/guides/ met 3 vrije content filters.
Ik heb DNSSEC geinstalleerd. Voor OpenDNS gebruikers test bij http://welcome.opendns.com & http://www.internetbadguys.com/ & http://www.exampleadultsite.com/ (content filter test)
Goeie DNS check site: https://www.uptrends.com/de/tools/dns
Voor deze site
#sockpuppet
Ik heb DNSSEC geinstalleerd. Voor OpenDNS gebruikers test bij http://welcome.opendns.com & http://www.internetbadguys.com/ & http://www.exampleadultsite.com/ (content filter test)
Goeie DNS check site: https://www.uptrends.com/de/tools/dns
Voor deze site
Field Value Status
Primary server ns0.transip.net. OK
Hostmaster hostmaster.transip.nl. OK
TTL 3600 OK
Serial 2019012801 OK
Refresh 14400 OK
Retry 1800 OK
Expire 2419200 OK
Minimum TTL 300 Fehler
NS (3 records found)
Purpose TTL Status
ns0.transip.net. 86400 OK
ns1.transip.nl. 86400 OK
ns2.transip.eu. 86400 OK
A (1 record found)
Name IP / CNAME TTL Status
www.security.nl 82.94.191.109 60 OK
AAAA
Name IP / CNAME TTL Status
No AAAA records found
MX (1 record found)
Purpose Priority TTL Status
mx1.certifiedsecure.com. 10 60 OK
TXT Record
jNqOdn4alrFS81hS2jbBL+M8RMM+XMsZgKfUgtdhwMM=
Primary server ns0.transip.net. OK
Hostmaster hostmaster.transip.nl. OK
TTL 3600 OK
Serial 2019012801 OK
Refresh 14400 OK
Retry 1800 OK
Expire 2419200 OK
Minimum TTL 300 Fehler
NS (3 records found)
Purpose TTL Status
ns0.transip.net. 86400 OK
ns1.transip.nl. 86400 OK
ns2.transip.eu. 86400 OK
A (1 record found)
Name IP / CNAME TTL Status
www.security.nl 82.94.191.109 60 OK
AAAA
Name IP / CNAME TTL Status
No AAAA records found
MX (1 record found)
Purpose Priority TTL Status
mx1.certifiedsecure.com. 10 60 OK
TXT Record
jNqOdn4alrFS81hS2jbBL+M8RMM+XMsZgKfUgtdhwMM=
#sockpuppet
25-02-2019, 04:02 door
Bitwiper
De aanvaller kan daarnaast vertrouwde certificaten voor de domeinnamen aanvragen en daarmee het netwerkverkeer onderscheppen.
Als we op zouden houden DV speelgoedcertificaten te vertrouwen, die hun "betrouwbaarheid" ontlenen aan het sowieso onbetrouwbare DNS, was dit probleem (met ondertussen verreweg de meeste sites op https) een heel stuk kleiner.En zoals anderen hierboven al aangaven, DNSSEC gaat dit probleem niet oplossen, uit https://en.m.wikipedia.org/wiki/Domain_Name_System_Security_Extensions:
Domain owners generate their own keys, and upload them using their DNS control panel at their domain-name registrar
Het probleem is dat aanvallers onrechtmatige toegang weten te krijgen tot dat "DNS control panel" en het IP-adres van een of meer servers (niet alleen web-, kan bijv. ook om e-mail-servers gaan) wijzigen in dat van servers waar zij toegang tot hebben (vaak niet van henzelf, maar gehacked). Je kunt natuurlijk hopen dat die aanvallers niet weten wat DNSSEC is en wat zij ervoor moeten doen om dat goed te laten werken na het wijzigen van DNS domeinnaam-naar-IP-adres records.
Jammer dat ICANN het probleem van slecht beveiligde registrar-accounts aangrijpt om "hun" DNSSEC protocol te promoten - dat dit probleem niet oplost en vanwege verschillende redenen weinig gebruikt wordt. Fake news wat mij betreft.
Om de dns-instellingen van de domeinen aan te passen maken de aanvallers gebruik van gecompromitteerde inloggegevens. Via deze gegevens kunnen de aanvallers inloggen bij een dns-provider en een ander ip-adres voor bijvoorbeeld de website of mailserver van het slachtoffer opgeven.
Deze specifieke aanvallen werken alleen als DNSSEC niet wordt gebruikt, zo laat de organisatie weten.
Daar snap ik niks van! En anderen ook niet kennelijk.
Als ik op het beheerpaneel van mijn DNS provider inlog dan kan ik daar IP adressen aanpassen zonder dat ik ooit iets
van dat hele DNSSEC zie. Dat wordt allemaal achter de schermen geregeld. Ik pas een adres aan en keurig worden
de juiste records in DNS gezet zowel voor de data als voor de ondertekening.
Als mijn inloggegevens gecompromitteerd worden dan kan een aanvaller precies hetzelfde doen. DNSSEC of niet.
Dus wat is hier nou het punt? Het gaat hier niet om DNSSEC maar om de veiligheid van het inloggen. 2FA ofzo.
De meest betrouwbare informatie is bepaalde certificaatinformatie van de betreffende website.
Een certificaat wordt meestal aangehouden voor de duur van 1 jaar (soms langer) en de datum dat deze normaalgesproken "expired" raakt, is van tevoren redelijk goed bekend.
Het is slechts zeer zelden dat vervanging al een heel stuk eerder moet gebeuren.
Een certificaat is ontegenzeggelijk te herkennen aan zijn Fingerprint. (SHA256-fingerprint is betrouwbaarder dan SHA1)
Bijvoorbeeld de SHA256 -fingerprint van het certificaat van www.security.nl is momenteel :
E8:27:E0:41:BC:5C:30:EB:EF:77:42:CE:94:A5:F0:8F:99:9D:F5:FB:00:53:1C:5C:BE:00:CF:27:F4:7B:B8:50
(er staat trouwens binnenkort vervanging van het certificaat op stapel: expires 14 maart 2019 ! )
Maar wil je dus weten of je wel echt op www.security.nl zit, dan kun je een goed geverifieerde kopie van de (meestal ca. 1 jaar geldige) SHA256 fingerprint (veilig) lokaal op je PC bewaren, en controleren of deze overeenstemt met de SHA256 fingerprint van het certificaat van de site die je denkt te bezoeken.
Dus vervolgens ga je naar www.security.nl en vergelijk je je lokale SHA256-fingerprint kopie met wat het certificaat van www.security.nl op dat moment zegt. Dit moet met elkaar overeenstemmen, of anders klopt er ergens iets niet.
En mocht dit gebeuren dan moet men grondig onderzoeken wat er hoogst waarschijnliijk mis is.
Het klinkt misschien wat bewerkelijk en ingewikkeld allemaal, hoewel je scriptjes kunt schrijven om het leven te veraangenamen.
Ik blijf herhalen dat deze methode wat mij betreft de grootste zekerheid biedt dat je echt zit op de site waarmee je verbinding wil hebben, en dat hiermee een valse DNS zo goed als zeker door de mand zal vallen.
Een certificaat wordt meestal aangehouden voor de duur van 1 jaar (soms langer) en de datum dat deze normaalgesproken "expired" raakt, is van tevoren redelijk goed bekend.
Het is slechts zeer zelden dat vervanging al een heel stuk eerder moet gebeuren.
Een certificaat is ontegenzeggelijk te herkennen aan zijn Fingerprint. (SHA256-fingerprint is betrouwbaarder dan SHA1)
Bijvoorbeeld de SHA256 -fingerprint van het certificaat van www.security.nl is momenteel :
E8:27:E0:41:BC:5C:30:EB:EF:77:42:CE:94:A5:F0:8F:99:9D:F5:FB:00:53:1C:5C:BE:00:CF:27:F4:7B:B8:50
(er staat trouwens binnenkort vervanging van het certificaat op stapel: expires 14 maart 2019 ! )
Maar wil je dus weten of je wel echt op www.security.nl zit, dan kun je een goed geverifieerde kopie van de (meestal ca. 1 jaar geldige) SHA256 fingerprint (veilig) lokaal op je PC bewaren, en controleren of deze overeenstemt met de SHA256 fingerprint van het certificaat van de site die je denkt te bezoeken.
Dus vervolgens ga je naar www.security.nl en vergelijk je je lokale SHA256-fingerprint kopie met wat het certificaat van www.security.nl op dat moment zegt. Dit moet met elkaar overeenstemmen, of anders klopt er ergens iets niet.
En mocht dit gebeuren dan moet men grondig onderzoeken wat er hoogst waarschijnliijk mis is.
Het klinkt misschien wat bewerkelijk en ingewikkeld allemaal, hoewel je scriptjes kunt schrijven om het leven te veraangenamen.
Ik blijf herhalen dat deze methode wat mij betreft de grootste zekerheid biedt dat je echt zit op de site waarmee je verbinding wil hebben, en dat hiermee een valse DNS zo goed als zeker door de mand zal vallen.
Maar wat onze vriend, Bitwiper, hierboven benoemd heeft, is niet alleen met DNSSEC en maatregelen als https everywhere en dergelijke op te lossen. In dat opzicht +1.
Er zal veel meer moeten gebeuren aan echte veiligheid op de infrastructuur. Zolang ik nog dergelijke resultaten terugkrijg via een scan, bestaat deze brakke algemene situatie nog: https://webhint.io/scanner/83d1a5e3-1832-4298-b24d-9366912d7cc7 hebben we het lek nog steeds niet boven.
Er zal dus het nodige moeten gebeuren om lutsers en prutsers te weren, ja ook incompetente zogenaamde deskundige IT stafleden bij hosters, webservers en de security through obscurity bij Big Tech.
Gaan we door met het houtje touwtje en open gaten vergiet systeem of echt naar best policy veiligheid met direct sinkholen en neerhalen van onveiligheid, onbetrouwbaarheid en regelrechte cybercrime.?
Echter heel misschien wil het huidige systeem dat helemaal niet. Bijvoorbeeld website developers opleiden met security als 'first resort issue', veiligheidseisen stellen aan mensen die websites op het Internet in de lucht tillen, hosters en clouddiensten, die subdomeinen laten kapen, die configuratie en settings verprutsen, die niets weten van de hoed en nog minder van de rand.
Gaat het spul niet echt op de schop en het afkoppelen van het Russische Internet voor 1 april aanstaande zou een prachtige kans daartoe zijn, dan gaat er echt niks/naks veranderen. Heel jammer, maar zo is het nu eenmaal en ik roep dit al veertien jaar als een soort van roepende in de website woestijn. Helaas, pindakaas en die ziet tegenwoordig ook al grijs van de toegevoegde geharde palmolie. Zo gaan we goed met z'n allen, toch?
luntrus
Er zal veel meer moeten gebeuren aan echte veiligheid op de infrastructuur. Zolang ik nog dergelijke resultaten terugkrijg via een scan, bestaat deze brakke algemene situatie nog: https://webhint.io/scanner/83d1a5e3-1832-4298-b24d-9366912d7cc7 hebben we het lek nog steeds niet boven.
Er zal dus het nodige moeten gebeuren om lutsers en prutsers te weren, ja ook incompetente zogenaamde deskundige IT stafleden bij hosters, webservers en de security through obscurity bij Big Tech.
Gaan we door met het houtje touwtje en open gaten vergiet systeem of echt naar best policy veiligheid met direct sinkholen en neerhalen van onveiligheid, onbetrouwbaarheid en regelrechte cybercrime.?
Echter heel misschien wil het huidige systeem dat helemaal niet. Bijvoorbeeld website developers opleiden met security als 'first resort issue', veiligheidseisen stellen aan mensen die websites op het Internet in de lucht tillen, hosters en clouddiensten, die subdomeinen laten kapen, die configuratie en settings verprutsen, die niets weten van de hoed en nog minder van de rand.
Gaat het spul niet echt op de schop en het afkoppelen van het Russische Internet voor 1 april aanstaande zou een prachtige kans daartoe zijn, dan gaat er echt niks/naks veranderen. Heel jammer, maar zo is het nu eenmaal en ik roep dit al veertien jaar als een soort van roepende in de website woestijn. Helaas, pindakaas en die ziet tegenwoordig ook al grijs van de toegevoegde geharde palmolie. Zo gaan we goed met z'n allen, toch?
luntrus
25-02-2019, 14:37 door
Briolet
Door Anoniem: …Maar wil je dus weten of je wel echt op www.security.nl zit, dan kun je …
Het ging toch over dnssec? Security.nl gebruikt geen dnssec als ik het goed zie:
$ host -t dnskey www.security.nl
www.security.nl has no DNSKEY record
www.security.nl has no DNSKEY record
Bij dnssec krijg je de key als antwoord.
Door Briolet:
Het ging toch over dnssec? Security.nl gebruikt geen dnssec als ik het goed zie:
Bij dnssec krijg je de key als antwoord.
Het ging toch over dnssec? Security.nl gebruikt geen dnssec als ik het goed zie:
$ host -t dnskey www.security.nl
www.security.nl has no DNSKEY record
www.security.nl has no DNSKEY record
Bij dnssec krijg je de key als antwoord.
security.nl gebruikt wél DNSSEC
DNSKEY staat in de root van een domein... in dit geval security.nl
Door Anoniem: Leuk dat ICANN't het roept, maar helemaal neutraal zijn ze er nou ook weer niet in. Het betekent meer macht voor hunnie en daarmee voor de (overheid van) de VS van Amerika.
Euh.., nee ICANN is onafhankelijk tegenwoordig.
Sinds 3 sept. 2016
Door Anoniem: Want jij weet t beter dan ICANN.
Natuurlijk, wat dacht jij dan.Door Bitwiper:
Omdat elk certificaat op de dns-naam van de website is gebaseerd, is die net zo (on)betrouwbaar als de DNS, zowel voor DV als EV certificaten.De aanvaller kan daarnaast vertrouwde certificaten voor de domeinnamen aanvragen en daarmee het netwerkverkeer onderscheppen.
Als we op zouden houden DV speelgoedcertificaten te vertrouwen, die hun "betrouwbaarheid" ontlenen aan het sowieso onbetrouwbare DNS, was dit probleem (met ondertussen verreweg de meeste sites op https) een heel stuk kleiner.Zie hier https://www.troyhunt.com/extended-validation-certificates-are-dead/ hoe je aan een EV certificaat komt. Je moet gewoon door alle administratieve hoepels springen. Daarnaast is het verschil tussen de DV en EV certificaten in je browsers niet meer te zien.
Reageren
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.
