Het minimaliseren van de risico's van het gebruik van DoH en DoT
DoH- en DoT-bescherming
Heeft u controle over uw DNS-verkeer? Organisaties investeren veel tijd, geld en moeite in het beveiligen van hun netwerken. Eén gebied dat echter vaak niet genoeg aandacht krijgt, is DNS.
Een goed overzicht van de risico’s die DNS met zich meebrengt is op de Infosecurity-conferentie.
31% van de ondervraagde ransomware-klassen gebruikte DNS voor sleuteluitwisseling.Bevindingen van het onderzoek
31% van de ondervraagde ransomwareklassen 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 commando- en controlekanaal tot stand te brengen, waardoor aanvallers eenvoudig malware in uw netwerk kunnen injecteren en gegevens kunnen stelen. Sinds het begin is DNS-verkeer grotendeels ongecodeerd en kan het gemakkelijk worden geanalyseerd door NGFW-beveiligingsmechanismen.
Er zijn nieuwe protocollen voor DNS verschenen die de vertrouwelijkheid van DNS-verbindingen moeten vergroten. Ze worden actief ondersteund door toonaangevende browserleveranciers en andere softwareleveranciers. Het gecodeerde DNS-verkeer zal binnenkort in bedrijfsnetwerken toenemen. Gecodeerd DNS-verkeer dat niet goed wordt geanalyseerd en opgelost door tools vormt een veiligheidsrisico voor een bedrijf. Een dergelijke bedreiging vormen bijvoorbeeld cryptolockers die DNS gebruiken om encryptiesleutels uit te wisselen. Aanvallers eisen nu een losgeld van enkele miljoenen dollars om de toegang tot uw gegevens te herstellen. Garmin betaalde bijvoorbeeld $10 miljoen.
Wanneer ze correct zijn geconfigureerd, kunnen NGFW's het gebruik van DNS-over-TLS (DoT) weigeren of beschermen en kunnen ze worden gebruikt om het gebruik van DNS-over-HTTPS (DoH) te weigeren, waardoor al het DNS-verkeer op uw netwerk kan worden geanalyseerd.
Wat is gecodeerde DNS?
Wat is DNS
Het Domain Name System (DNS) zet voor mensen leesbare domeinnamen om (bijvoorbeeld adres ) naar IP-adressen (bijvoorbeeld 34.107.151.202). Wanneer een gebruiker een domeinnaam in een webbrowser invoert, stuurt de browser een DNS-query naar de DNS-server, waarin wordt gevraagd naar het IP-adres dat aan die domeinnaam is gekoppeld. Als reactie retourneert de DNS-server het IP-adres dat deze browser zal gebruiken.
DNS-query's en -antwoorden worden in platte tekst en niet-versleuteld over het netwerk verzonden, waardoor het kwetsbaar is voor spionage of wijziging van het antwoord en het omleiden van de browser naar kwaadaardige servers. DNS-codering maakt het moeilijk om DNS-verzoeken te volgen of te wijzigen tijdens de verzending. Het coderen van DNS-verzoeken en -antwoorden beschermt u tegen Man-in-the-Middle-aanvallen terwijl dezelfde functionaliteit wordt uitgevoerd als het traditionele DNS-protocol (Domain Name System) in leesbare tekst.
De afgelopen jaren zijn er twee DNS-coderingsprotocollen geïntroduceerd:
-
DNS-over-HTTPS (DoH)
-
DNS-over-TLS (DoT)
Deze protocollen hebben één ding gemeen: ze verbergen opzettelijk DNS-verzoeken voor elke onderschepping... en ook voor de bewakers van de organisatie. De protocollen maken voornamelijk gebruik van TLS (Transport Layer Security) om een gecodeerde verbinding tot stand te brengen tussen een client die vragen stelt en een server die DNS-vragen oplost via een poort die normaal niet wordt gebruikt voor DNS-verkeer.
De vertrouwelijkheid van DNS-query's is een groot pluspunt van deze protocollen. Ze vormen echter problemen voor bewakers die het netwerkverkeer moeten monitoren en kwaadaardige verbindingen moeten detecteren en blokkeren. Omdat de protocollen verschillen in hun implementatie, zullen de analysemethoden verschillen tussen DoH en DoT.
DNS via HTTPS (DoH)
DNS binnen HTTPS
DoH gebruikt de bekende poort 443 voor HTTPS, waarbij de RFC specifiek stelt dat het de bedoeling is om “DoH-verkeer te mixen met ander HTTPS-verkeer op dezelfde verbinding”, “het moeilijk te maken om DNS-verkeer te analyseren” en zo bedrijfscontroles te omzeilen ( ). Het DoH-protocol maakt gebruik van TLS-codering en de verzoeksyntaxis van de algemene HTTPS- en HTTP/2-standaarden, waardoor DNS-verzoeken en -antwoorden worden toegevoegd bovenop de standaard HTTP-verzoeken.
Risico's verbonden aan DoH
Als u het reguliere HTTPS-verkeer niet kunt onderscheiden van DoH-verzoeken, kunnen (en zullen) applicaties binnen uw organisatie de lokale DNS-instellingen omzeilen door verzoeken om te leiden naar servers van derden die reageren op DoH-verzoeken. het DNS-verkeer controleren. Idealiter zou u DoH moeten controleren met behulp van HTTPS-decoderingsfuncties.
И in de nieuwste versie van hun browser, en beide bedrijven werken eraan om DoH standaard te gebruiken voor alle DNS-verzoeken. over de integratie van DoH in hun besturingssystemen. Het nadeel is dat niet alleen gerenommeerde softwarebedrijven, maar ook aanvallers DoH zijn gaan gebruiken als een middel om traditionele bedrijfsfirewallmaatregelen te omzeilen. (Bekijk bijvoorbeeld de volgende artikelen: , и .) In beide gevallen zal zowel goed als kwaadaardig DoH-verkeer onopgemerkt blijven, waardoor de organisatie blind blijft voor het kwaadwillige gebruik van DoH als kanaal om malware (C2) te controleren en gevoelige gegevens te stelen.
Zorgen voor zichtbaarheid en controle van het DoH-verkeer
Als de beste oplossing voor DoH-controle raden we aan NGFW te configureren om HTTPS-verkeer te decoderen en DoH-verkeer te blokkeren (applicatienaam: dns-over-https).
Zorg er eerst voor dat NGFW is geconfigureerd om HTTPS te decoderen, volgens .
Ten tweede, maak een regel voor applicatieverkeer "dns-over-https", zoals hieronder weergegeven:
Palo Alto Networks NGFW-regel om DNS-over-HTTPS te blokkeren
Als tussentijds alternatief (als uw organisatie de HTTPS-decryptie nog niet volledig heeft geïmplementeerd), kan NGFW worden geconfigureerd om een 'deny'-actie toe te passen op de 'dns-over-https'-applicatie-ID, maar het effect zal beperkt blijven tot het blokkeren van bepaalde goed- bekende DoH-servers met hun domeinnaam, dus hoe zonder HTTPS-decodering DoH-verkeer niet volledig kan worden geïnspecteerd (zie en zoek naar "dns-over-https").
DNS via TLS (DoT)
DNS binnen TLS
Hoewel het DoH-protocol de neiging heeft zich te vermengen met ander verkeer op dezelfde poort, gebruikt DoT in plaats daarvan standaard een speciale poort die voor dat enige doel is gereserveerd, en verbiedt het zelfs specifiek dat dezelfde poort wordt gebruikt door traditioneel niet-gecodeerd DNS-verkeer ( ).
Het DoT-protocol maakt gebruik van TLS om codering te bieden die standaard DNS-protocolquery's omvat, waarbij verkeer de bekende poort 853 gebruikt ( ). Het DoT-protocol is ontworpen om het voor organisaties gemakkelijker te maken om verkeer op een poort te blokkeren, of verkeer te accepteren maar decodering op die poort mogelijk te maken.
Risico's verbonden aan DoT
Google heeft DoT in zijn client geïmplementeerd , met de standaardinstelling om DoT automatisch te gebruiken, indien beschikbaar. Als u de risico's hebt beoordeeld en klaar bent om DoT op organisatieniveau te gebruiken, moet u ervoor zorgen dat netwerkbeheerders uitgaand verkeer op poort 853 via hun perimeter expliciet toestaan voor dit nieuwe protocol.
Zorgen voor zichtbaarheid en controle van DoT-verkeer
Als best practice voor DoT-controle raden we een van de bovenstaande zaken aan, op basis van de vereisten van uw organisatie:
-
Configureer NGFW om al het verkeer voor bestemmingspoort 853 te decoderen. Door het verkeer te decoderen, verschijnt DoT als een DNS-toepassing waarop u elke actie kunt toepassen, zoals het inschakelen van een abonnement om DGA-domeinen of een bestaand domein te beheren en antispyware.
-
Een alternatief is om de App-ID-engine het 'dns-over-tls'-verkeer op poort 853 volledig te laten blokkeren. Dit wordt meestal standaard geblokkeerd, er is geen actie vereist (tenzij u specifiek 'dns-over-tls'-applicatie- of poortverkeer toestaat 853).
Bron: www.habr.com