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.
Reacties (18)
04-10-2019, 16:22 door
Tha Cleaner
Door Anoniem: Goed advies van het NCSC!
Hackers en malware zullen hier inderdaad graag gebruik van gaan maken. 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
Hackers en malware zullen hier inderdaad graag gebruik van gaan maken.
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...
Momenteel zou ik iedereen direct adviseren om deze in ieder geval alvast op alle firewalls te blockeren.
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).
# Block DoH to Cloudflare
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.
Een beetje 'phone home' tool gebruikt gewoon een hard IP address. Problem solved.
04-10-2019, 16:56 door
Erik van Straten
Door Tha Cleaner: Hackers en malware zullen hier inderdaad graag gebruik van gaan maken.
Dat doen ze al een tijdje (Google: malware using DoH).Door marcod: 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...
Dat zal vast wel eens gebeurd zijn, maar is niet populair omdat de IP-adressen ervan snel geblacklist kunnen worden, en omdat veel bedrijven vanalles blokkeren in firewalls behalve DNS-verkeer tussen hun interne DNS-servers en DNS servers op internet. Google: fast flux.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.
Ik denk dat je vrij naief bent als je denkt dat je DoH en DoT kan blokkeren op je firewall. Die lijst is nooit compleet, en als een hacker die functionaliteit nodig heeft dan zet 'ie wel ergens een relay aan op een VPS of zo. Je loopt altijd achter de feiten aan. Beter lijkt me om dit op een andere wijze of onmogelijk te maken, of irrelevant voor de beveiliging van je netwerk...
Door Anoniem: Ik denk dat je vrij naief bent als je denkt dat je DoH en DoT kan blokkeren op je firewall. Die lijst is nooit compleet, en als een hacker die functionaliteit nodig heeft dan zet 'ie wel ergens een relay aan op een VPS of zo. Je loopt altijd achter de feiten aan. Beter lijkt me om dit op een andere wijze of onmogelijk te maken, of irrelevant voor de beveiliging van je netwerk...
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
Door Anoniem: Een beetje 'phone home' tool gebruikt gewoon een hard IP address. Problem solved.
Nope.
Een beetje oplettende security lezer weet dat botnet operators doorhebben dat ze flexibel moeten kunnen zijn met hun C&C servers.
Door marcod:
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...
Klopt ook. Maar er is ook zat die dit gewoon niet doen.Hackers en malware zullen hier inderdaad graag gebruik van gaan maken.
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...
Momenteel zou ik iedereen direct adviseren om deze in ieder geval alvast op alle firewalls te blockeren.
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).
# Block DoH to Cloudflare
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.
Door Anoniem: Ik denk dat je vrij naief bent als je denkt dat je DoH en DoT kan blokkeren op je firewall. Die lijst is nooit compleet, en als een hacker die functionaliteit nodig heeft dan zet 'ie wel ergens een relay aan op een VPS of zo. Je loopt altijd achter de feiten aan. Beter lijkt me om dit op een andere wijze of onmogelijk te maken, of irrelevant voor de beveiliging van je netwerk...
Daarom is het zo'n slechte en gevaarlijke oplossing.Zou je devices die wel netwerkactiviteit vertonen maar geen ‘gewone’ DNS-queries doen als netwerkbeheerder niet kunnen detecteren en blokkeren?
05-10-2019, 11:36 door
Erik van Straten
Door Anoniem: Zou je devices die wel netwerkactiviteit vertonen maar geen ‘gewone’ DNS-queries doen als netwerkbeheerder niet kunnen detecteren en blokkeren?
Voor een device, dat wel B doet maar niet A, vooral als A vóór B had moeten plaatsvinden, zijn niet altijd detectieregels voorhanden (dit moet "stateful" en dat levert altijd complicaties op).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.
Het woord hackers valt, maar men vergeet dat in sommige landen de overheid de grootste hacker is omdat zij ook graag "DNS-verzoeken" willen inspecteren, zoals in Engeland. Die houd je nu tegen met DoH. Overigens, mijn browser is daarop al ingesteld (Firefox).
Hoe je dat doet staat hier:
https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/
Hoe je dat doet staat hier:
How-To Manually Configure DoH
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.
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/
05-10-2019, 22:21 door
johanw
Veel reacties van controlfreaks die werken als systeembeheerder in een bedrijf hier. Tegenwoordig is het al heel makkelijk om onder onhandige blokkades van systeembeheerders uit te komen: je bedrijfscomputer gewoon laten meeliften op de 4G verbinding van de mobiele telefoon. Dan ben je in een keer van al dat gedoe af.
https://blog.apnic.net/2019/04/08/opinion-what-does-doh-really-mean-for-privacy/ Als ik dat lees dan vraag ik me inderdaad af wat DNS over HTTPS/TLS ons gaat bieden als gebruikers.
Door johanw: Veel reacties van controlfreaks die werken als systeembeheerder in een bedrijf hier. Tegenwoordig is het al heel makkelijk om onder onhandige blokkades van systeembeheerders uit te komen: je bedrijfscomputer gewoon laten meeliften op de 4G verbinding van de mobiele telefoon. Dan ben je in een keer van al dat gedoe af.
Kan je ook niet op de bedrijfs resources komen, je moet een wifi adapter in de bedrijfscomputer hebben.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.
Als ik het goed lees, is het dus de bedoeling alles te laten aflopen binnen de browser,
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
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
Door marcod:
Denk ook eens aan alle aps op smarttv's die ook buiten jouw dns om hun data naar hun homebase sturen en naar veel andere trackers. Maar als je als gewone webgebruiker eens wat privacy wilt (nu ja, de ip's waar je mee connect zijn altijd zichtbaar), is het ineens een probleem.Hackers en malware zullen hier inderdaad graag gebruik van gaan maken.
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...Door Anoniem:
Sterker nog, alleen webverkeer vanuit clients (http en https) word via een interne proxy doorgelaten, waarbij de dns-resolving via die proxy gebeurt. Daar kan dan ook nog extra gefilterd worden (maar waar haal je de juiste filtercriteria vandaan), maar whitelists blokkeren teveel en blacklists blokkeren niet alles blokkeren wat ongewenst is.Door marcod:
Hackers en malware zullen hier inderdaad graag gebruik van gaan maken.
Bij goede bedrijven mag DNS verkeer niet direct het Internet op vanuit clients. Daar loopt alles via Centrale DNS servers icm met DNS blacklists.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.
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.
