Risico's van het gebruik van DoH en DoT minimaliseren
Bescherming tegen DoH en DoT
Controleert u uw DNS-verkeer? Organisaties besteden veel tijd, geld en moeite aan het beveiligen van hun netwerken. Echter, een van de gebieden die vaak onvoldoende aandacht krijgt, is DNS.
Een goede samenvatting van de risico's die DNS met zich meebrengt, is op de Infosecurity-conferentie.
31% van de onderzochte ransomware-classen gebruikte DNS voor sleuteluitwisseling. Bevindingen van het onderzoek
31% van de onderzochte ransomware-classen gebruikte DNS voor sleuteluitwisseling.
Het probleem is ernstig. Volgens het onderzoekslaboratorium Palo Alto Networks Unit 42 gebruikt ongeveer 85% van de malware DNS om een command-and-control-kanaal op te zetten, waardoor aanvallers gemakkelijk malware in uw netwerk kunnen inbrengen en gegevens kunnen stelen. Sinds de oprichting is DNS-verkeer overwegend onversleuteld en gemakkelijk te analyseren door NGFW-beveiligingsmechanismen.
Er zijn nieuwe protocollen voor DNS verschenen, gericht op het verbeteren van de privacy van DNS-verbindingen. Deze worden actief ondersteund door toonaangevende browserleveranciers en andere softwareleveranciers. Binnenkort zal er in bedrijfsnetwerken een toename van versleuteld DNS-verkeer plaatsvinden. Versleuteld DNS-verkeer dat niet goed wordt geanalyseerd en toegestaan, vormt een beveiligingsrisico voor het bedrijf. Een dergelijk risico zijn ransomware-operators, die DNS gebruiken voor sleuteluitwisseling. Aanvallers eisen nu soms miljoenen dollars om toegang tot uw gegevens te herstellen. Het bedrijf Garmin heeft bijvoorbeeld 10 miljoen dollar betaald.
Bij juiste configuratie kunnen NGFW's het gebruik van DNS-over-TLS (DoT) blokkeren of beschermen en kunnen ze worden gebruikt om het gebruik van DNS-over-HTTPS (DoH) te verbieden, waardoor al het DNS-verkeer in uw netwerk kan worden geanalyseerd.
Wat is versleuteld DNS?
Wat is DNS
Het Domain Name System (DNS) zet leesbare domeinnamen (bijvoorbeeld het adres ) naar een IP-adres (bijvoorbeeld naar 34.107.151.202). Wanneer een gebruiker een domeinnaam in de webbrowser invoert, stuurt de browser een DNS-verzoek naar de DNS-server om het IP-adres op te vragen dat aan die domeinnaam is gekoppeld. In reactie daarop retourneert de DNS-server het IP-adres dat deze browser zal gebruiken.
DNS-verzoeken en -antwoorden worden via het netwerk verzonden in platte tekst en ongecodeerd, waardoor het kwetsbaar is voor afluisteren of wijziging van het antwoord en het omleiden van de browser naar kwaadwillige servers. DNS-encryptie maakt het moeilijker om DNS-verzoeken te volgen of deze te wijzigen tijdens de overdracht. Het versleutelen van DNS-verzoeken en -antwoorden beschermt je tegen Man-in-the-Middle-aanvallen terwijl het dezelfde functies vervult als het traditionele DNS-protocol (domeinnamen systeem) in platte tekst.
In de afgelopen jaren zijn er twee encryptieprotocollen voor DNS geïmplementeerd:
DNS-over-HTTPS (DoH)
DNS-over-TLS (DoT)
Deze protocollen hebben één gemeenschappelijk kenmerk: ze verbergen opzettelijk DNS-verzoeken voor elke afluisteractie… inclusief voor de beveiligingsprofessionals binnen de organisatie. De protocollen maken voornamelijk gebruik van het TLS-protocol (Transport Layer Security) om een versleutelde verbinding tot stand te brengen tussen de cliënt die de verzoeken indient en de DNS-server die de verzoeken verwerkt, via een poort die doorgaans niet voor DNS-verkeer wordt gebruikt.
De privacy van DNS-verzoeken is een groot pluspunt van deze protocollen. Ze creëren echter problemen voor beveiligingsprofessionals die het netwerkverkeer moeten volgen en schadelijke verbindingen moeten detecteren en blokkeren. Aangezien de protocollen verschillen in hun implementatie, zullen de analysemethoden ook verschillen tussen DoH en DoT.
DNS over HTTPS (DoH)
DNS binnen HTTPS
DoH gebruikt de bekende poort 443 voor HTTPS, waarvoor in de RFC specifiek is vermeld dat de taak is om "DoH-verkeer te mengen met ander HTTPS-verkeer in dezelfde verbinding", "het analyseren van DNS-verkeer te bemoeilijken" en zo de maatregelen voor corporatieve controle te omzeilen ( ). Het DoH-protocol maakt gebruik van TLS-encryptie en de verzoeksyntax die wordt geleverd door algemene HTTPS- en HTTP/2-standaarden, waarbij DNS-verzoeken en -antwoorden bovenop standaard HTTP-verzoeken worden toegevoegd.
Risico's verbonden aan DoH
Als u niet in staat bent om regulier HTTPS-verkeer van DoH-verzoeken te onderscheiden, kunnen (en zullen) applicaties binnen uw organisatie lokale DNS-instellingen omzeilen door verzoeken naar externe servers te sturen die DoH-verzoeken beantwoorden, wat elke monitoring omzeilt en dus de mogelijkheid om DNS-verkeer te controleren, vernietigt. Idealiter zou u DoH moeten beheren met behulp van HTTPS-decryptiefuncties.
En in de laatste versies van hun browsers, en beide bedrijven werken aan het standaard gebruiken van DoH voor alle DNS-verzoeken. voor de integratie van DoH in zijn besturingssystemen. Een nadeel is dat niet alleen gerespecteerde softwareontwikkelaars, maar ook kwaadwillenden DoH zijn gaan gebruiken als een middel om traditionele bedrijfsfirewall maatregelen te omzeilen. (Bekijk bijvoorbeeld de volgende artikelen: , en .) In elk geval blijft zowel goed als kwaadaardig DoH-verkeer onopgemerkt, waardoor de organisatie blind is voor het kwaadaardige gebruik van DoH als een kanaal voor het beheer van malware (C2) en diefstal van gevoelige gegevens.
Zorg voor zichtbaarheid en controle van DoH-verkeer
Als de beste oplossing voor het controleren van DoH raden we aan om in de NGFW HTTPS-verkeer te decrypten en DoH-verkeer (applicatienaam: dns-over-https) te blokkeren.
Zorg eerst dat de NGFW is ingesteld om HTTPS te decrypten, volgens .
Ten tweede maakt u een regel voor het applicatieverkeer 'dns-over-https', zoals hieronder weergegeven:
Palo Alto Networks NGFW-regel voor het blokkeren van DNS-over-HTTPS
Als tussenalternatief (als uw organisatie HTTPS-decryptie niet volledig heeft geïmplementeerd) kan de NGFW worden ingesteld om de actie 'verboden' toe te passen op de applicatie-ID 'dns-over-https', maar het effect zal beperkt zijn tot het blokkeren van bepaalde goed bekende DoH-servers op hun domeinnaam, aangezien zonder HTTPS-decryptie het DoH-verkeer niet volledig kan worden gecontroleerd (zie: en zoek naar de term 'dns-over-https').
DNS over TLS (DoT)
DNS binnen TLS
Terwijl het DoH-protocol probeert zich te mengen met ander verkeer op dezelfde poort, gebruikt DoT in plaats daarvan standaard een speciale poort die gereserveerd is voor dit specifieke doel, waarbij het zelfs gebruik van dezelfde poort voor traditioneel niet-versleuteld DNS-verkeer verbiedt ( ).
Het DoT-protocol maakt gebruik van het TLS-protocol om encryptie te waarborgen, waardoor standaard DNS-verzoeken worden ingekapseld met verkeer dat gebruikmaakt van de bekende poort 853 ( ). Het DoT-protocol is ontworpen om het voor organisaties te vergemakkelijken om verkeer op de poort te blokkeren, hetzij door toestemming te verlenen voor het gebruik ervan, maar met decryptie op deze poort in te schakelen.
Risico's van DoT
Google heeft DoT geïmplementeerd in zijn client , waarbij de instelling voor automatisch gebruik van DoT standaard is ingeschakeld als het beschikbaar is. Als u de risico's hebt beoordeeld en klaar bent om DoT op organisatieniveau te gebruiken, moeten netwerkbeheerders expliciet uitgaand verkeer op poort 853 via hun perimeter toestaan voor dit nieuwe protocol.
Zichtbaarheid en controle van DoT-verkeer waarborgen
Als beste methode voor controle over DoT raden wij een van de bovenstaande opties aan op basis van de vereisten van uw organisatie:
Configureer NGFW om al het verkeer naar bestemmingspoort 853 te decrypten. Door de decryptie van verkeer zal DoT worden weergegeven als een DNS-applicatie waarop u acties kunt toepassen, zoals het inschakelen van een abonnement. om DGA-domeinen te controleren of al bestaande en anti-spyware.
Als alternatief kan het verkeer ‘dns-over-tls’ via poort 853 volledig worden geblokkeerd met de App-ID-engine. Dit is doorgaans standaard geblokkeerd, er zijn geen acties vereist (tenzij u specifiek de applicatie ‘dns-over-tls’ of verkeer via poort 853 hebt toegestaan).
Bron: habr.com
