NCSC: DoH en DoT maken dns-monitoring moeilijker
Nieuwe transportprotocollen voor het domain name system (dns) maken het lastiger om dns-verzoeken te monitoren en organisaties moeten hier rekening mee houden, zo adviseert het Nationaal Cyber Security Centrum (NCSC) van het ministerie van Justitie en Veiligheid in een nieuwe factsheet (pdf).
"Systeem- of netwerkbeheerders en securityprofessionals zijn gewend dat dns-verkeer onversleuteld naar poort 53 gaat. Recentelijk zijn er nieuwe dns-transporten gestandaardiseerd waarbij encryptie wordt gebruikt om vertrouwelijkheid en integriteit te bieden in de aanwezigheid van een kwaadwillende op het netwerk", zo laat NCSC weten. Het gaat om de dns-transporten DNS-over-HTTPS (DoH) en DNS-over-TLS (DoT).
Dns-verzoeken zijn normaal onversleuteld. Hierdoor kan informatie over de gebruiker lekken en is het mogelijk voor kwaadwillenden om dns-verkeer in te zien of te veranderen. DoH en DoT moeten dit probleem verhelpen door een versleutelde verbinding voor dns-verzoeken te gebruiken. Zowel Google als Mozilla zullen DoH aan hun browser toevoegen.
Het NCSC waarschuwt dat dit gevolgen heeft voor organisaties die onversleuteld dns-verkeer inspecteren. Die zullen na verloop van tijd hun inzicht zien afnemen. "Organisaties die security-monitoring of filtering doen op de resolvers die zijn geconfigureerd op systeemniveau zullen merken dat deze maatregelen ineffectief worden zodra applicaties een andere DNS-resolver gaan gebruiken", merkt de overheidsinstantie op. Zo is Mozilla van plan om voor DoH de dns-servers van Cloudflare te gaan gebruiken. Firefoxgebruikers slaan daardoor de dns-servers van hun eigen provider over.
Voor organisaties kunnen DoH en DoT verschillende gevolgen hebben, zoals beveiligingsmaatregelen die ineffectief worden, het lekken van gevoelige informatie en connectiviteitsproblemen op interne netwerken en vpn's. Het NCSC adviseert organisaties om op de apparaten die in beheer zijn een voorkeursresolver in te stellen. Wanneer de voorkeursresolver DoH of DoT ondersteunt kunnen de dns-transporten worden ingeschakeld.
"Hoe lang gecentraliseerde dns-monitoring nog een effectieve maatregel blijft, is sterk afhankelijk van de snelheid waarmee Mozilla en Google ondersteuning in hun software activeren. Als u vandaag begint met het aanpassen van uw dns-monitoring, dan wordt u niet verrast door de naderende veranderingen", besluit het NCSC.
Bedrijven zullen dus hiervoor gereed moeten zijn, want dit is een risico voor bedrijven. Technisch gezien kan iedere webserver DOH aanbieden, dus is zeer lastig te blockeren op firewalls.
Hopelijk zijn er snel lijsten let alle DOH beschikbaar die je kunt gebruiken op deze hosts op je firewalls tegen te houden
Momenteel zou ik iedereen direct adviseren om deze in ieder geval alvast op alle firewalls te blockeren.
# Block DoH to Cloudflare
deny tcp/udp in/out to 104.16.111.25 on port 443
deny tcp/udp in/out to 104.16.112.25 on port 443
deny tcp/udp in/out to 2606:4700::6810:7019 on port 443
deny tcp/udp in/out to 2606:4700::6810:6f19 on port 443
# Block DoH to Google Public DNS
deny tcp/udp in/out to 8.8.8.8 on port 443
deny tcp/udp in/out to 8.8.4.4 on port 443
deny tcp/udp in/out to 2001:4860:4860::8888 on port 443
deny tcp/udp in/out to 2001:4860:4860::8844 on port 443
Ter geruststelling; de echt slimme hackers hadden, voordat DoH bestond, vermoedelijk al lang een vergelijkbaar eigen proprietary systeem voor het heimelijk 'naar buiten smokkelen' van DNS-queries, buiten de officiële resolver om, waarschijnlijk...
Ter nuance; je bedoelt 'iedereen' die nu ook al UDP/TCP poort 53 verkeer blokkeert naar publieke, danwel de niet-interne, resolvers? Want waarom dit doen als je UDP/53 gewoon nog open hebt staan? Hackers en malware maken daar natuurlijk ook al tijdenlang met plezier gebruik van (zoals UDP poort 53 naar 8.8.8.8).
Op voorhand al incompleet. Ook 1.1.1.1 en 1.1.0.0 (en zijn IPv6 equivalenten) moet je dan meenemen.
Plus het feit dat er naast Google en CloudFlare nog wel meer publieke DoH-services zijn. Vaak bieden die ook DoT (DNS over TLS) op poort 853, dus ook dat zou je dan moeten blokkeren.
Het aantal DoH servers neemt toe, met blokkeren blijf je helaas achter de feiten aanlopen. O.a. daarom vind ik DoH zo'n slecht idee.
Klein voordeeltje is dat als je de nu bekende adressen blokkeert en bij pogingen die te gebruiken een alarm laat afgaan, je ofwel de betweterende gebruiker om z'n oren kunt slaan, of een PC kunt gaan null-routen en re-imagen.
Heel veel mensen denken helaas dat de Firewall ze tegen alles beschermt. Andere mensen nemen dit gedrag over de rest is overduidelijk wat er gebeurd dan
Nope.
Een beetje oplettende security lezer weet dat botnet operators doorhebben dat ze flexibel moeten kunnen zijn met hun C&C servers.
Ter geruststelling; de echt slimme hackers hadden, voordat DoH bestond, vermoedelijk al lang een vergelijkbaar eigen proprietary systeem voor het heimelijk 'naar buiten smokkelen' van DNS-queries, buiten de officiële resolver om, waarschijnlijk...
Ter nuance; je bedoelt 'iedereen' die nu ook al UDP/TCP poort 53 verkeer blokkeert naar publieke, danwel de niet-interne, resolvers? Want waarom dit doen als je UDP/53 gewoon nog open hebt staan? Hackers en malware maken daar natuurlijk ook al tijdenlang met plezier gebruik van (zoals UDP poort 53 naar 8.8.8.8).
Op voorhand al incompleet. Ook 1.1.1.1 en 1.1.0.0 (en zijn IPv6 equivalenten) moet je dan meenemen.
Plus het feit dat er naast Google en CloudFlare nog wel meer publieke DoH-services zijn. Vaak bieden die ook DoT (DNS over TLS) op poort 853, dus ook dat zou je dan moeten blokkeren.
Het scenario dat een device geheel geen DNS-lookups doet, ligt echter niet voor de hand, omdat gebruikers (als het goed is) niet de DNS-server instellingen van het OS kunnen wijzigen.
Het eerste probleem is dat gebruikers, meestal tegen de regels in, zelf bewust software installeren (onder hun account) die van DoH gebruik maakt of kan maken (zoals Firefox en Chrome). Als je dat niet wilt of kunt blokkereren, kun je dat in principe wel detecteren door te registreren of aan het bezoek van bekende websites, op basis van de IP-adressen (en/of SNI-informatie en/of ontvangen server-certificaten en/of CRL-downloads/OCSP lookups), er voorafgaande daaraan de gebruikelijke DNS-lookups plaatsvinden. Maar, zoals ik al schreef, dit is vaak ingewikkelder dan het lijkt, en doordat ook clients vask DNS gegevens cachen, is er een flinke kans op false positives.
Een tweede en m.i. grootste probleem is malware die een DoH lookup doet voor een C&C-server. Computers die ineens spontaan, d.w.z. zonder voorafgaande poort 53 UDP/TCP DNS-lookup, met een extern IP-adres communiceren, zouden verdacht kunnen zijn, maar ook dat weet je niet zeker.
Vandaar dat ik denk dat organisaties het beste alle communicatie tussen interne devices en externe DoH servers zoveel mogelijk kunnen blokkeren, en de lijst met bekende DoH-servers aanvullen zodra er nieuwe verschijnen.
Al met al blijf ik het jammer vinden dat het DoH concept ons door de strot wordt geduwd terwijl het malwaremakers faciliteert en nog een reeks andere nadelen heeft. Zeer ondoordacht dus.
Hoe je dat doet staat hier:
Do you want to use (or not use) DoH all the time? Use the configuration editor to configure DoH if you want to test DoH outside of a shield study. DoH support works best in Firefox 62 or newer. Shield studies will not override your manual configuration.
1] Type about:config in the location bar
2] Search for network.trr (TRR stands for Trusted Recursive Resolver – it is the DoH Endpoint used by Firefox.)
3] Change network.trr.mode to 2 to enable DoH. This will try and use DoH but will fallback to insecure DNS under some circumstances like captive portals. (Use mode 5 to disable DoH under all circumstances.)
4] Set network.trr.uri to your DoH server. Cloudflare’s is https://mozilla.cloudflare-dns.com/dns-query but you can use any DoH compliant endpoint.
The DNS tab on the about:networking page indicates which names were resolved using the Trusted Recursive Resolver (TRR) via DoH.
https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/
Daarnaast moet je ook even de vraag stellen, waarom er een bepaald ICT security beleid is. ICT maakt dit beleid niet, dat doet het bedrijf. ICT zorgt alleen voor de handhaving. Kleine nuance.... Gezien je opmerking, heb jij geen idee waarom ICT bepaalde maatregelen neemt. Dat doen ze niet voor hun lol.
alles lopend over poort 443. Blijf je een opt-out mogelijkheid houden?
Of is het enige wat de browser je (straks) nog te bieden heeft?
Gezien de proliferatie van Google Chrome en op Google Chrome gebaseerde browsers,
goed voor Google's doorgezette gebruikersprofilering, maar slecht voor de (laatste restjes) gebruikersprivacy.
Maar ja zoals Amerikanen ons al jaren verzekeren. Geen punt, privacy bestaat iemers toch niet meer.
Leg je er maar bij neer, begin er niet meer over.
Je merkt het toch niet, wat er allemaal aan de andere kant van je scherm aan het gebeuren is.
"We are the Borg, resistance is futile.
#sockpuppet
Hoe dat met DoH gaat, weet ik niet, maar als de browser de dns resolving doet, blokkeer je gewoon alles dat een ip-adres in het request heeft (op de proxy), omdat de proxy normaal de resolving zou moeten doen.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Information Security Officer (2fte)
Een uitdagende rol waarbij jij, op basis van security, de vertaalslag maakt tussen business en IT en direct bijdraagt aan de veiligheid van informatie binnen de gemeente Almere. Dat is in een notendop waar jij als Information Security Officer mee bezig bent. Interesse gewekt? Door groei van de organisatie zijn we op zoek naar twee nieuwe collega’s.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
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.
