A DoH és DoT használatának kockázatainak minimalizálása
DoH és DoT védelem
Te irányítod a DNS-forgalmat? A szervezetek sok időt, pénzt és erőfeszítést fektetnek hálózataik biztonságába. Azonban az egyik terület, amely gyakran nem kap elég figyelmet, a DNS.
Jó áttekintést ad a DNS-sel járó kockázatokról az Infobiztonsági konferencián.
A megkérdezett ransomware osztályok 31%-a használt DNS-t kulcscserére
A megkérdezett ransomware osztályok 31%-a használt DNS-t kulcscserére.
A probléma komoly. A Palo Alto Networks Unit 42 kutatólaboratóriuma szerint a rosszindulatú programok hozzávetőleg 85%-a DNS-t használ a parancs- és irányítási csatorna létrehozására, amely lehetővé teszi a támadók számára, hogy könnyen bejuttassanak rosszindulatú programokat a hálózatba, valamint adatokat lopjanak el. Megalakulása óta a DNS-forgalom nagyrészt titkosítatlan, és az NGFW biztonsági mechanizmusaival könnyen elemezhető.
Új DNS-protokollok jelentek meg, amelyek célja a DNS-kapcsolatok bizalmasságának növelése. A vezető böngészőgyártók és más szoftvergyártók aktívan támogatják őket. A titkosított DNS-forgalom hamarosan növekedni fog a vállalati hálózatokban. Az eszközök által nem megfelelően elemzett és fel nem oldott titkosított DNS-forgalom biztonsági kockázatot jelent a vállalat számára. Ilyen fenyegetés például a titkosítási kulcsok cseréjére DNS-t használó kriptoblokkolók. A támadók most több millió dolláros váltságdíjat követelnek, hogy visszaállítsák az Ön adataihoz való hozzáférést. A Garmin például 10 millió dollárt fizetett.
Megfelelő konfigurálás esetén az NGFW-k megtagadhatják vagy védhetik a DNS-over-TLS (DoT) használatát, és felhasználhatók a DNS-over-HTTPS (DoH) használatának megtagadására, lehetővé téve a hálózaton lévő összes DNS-forgalom elemzését.
Mi az a titkosított DNS?
Mi az a DNS
A Domain Name System (DNS) feloldja az ember által olvasható tartományneveket (például címeket). ) IP-címekre (például 34.107.151.202). Amikor a felhasználó beír egy tartománynevet a webböngészőbe, a böngésző DNS-lekérdezést küld a DNS-kiszolgálónak, kérve az adott tartománynévhez társított IP-címet. Válaszul a DNS-kiszolgáló visszaadja a böngésző által használt IP-címet.
A DNS-lekérdezések és -válaszok sima szövegben, titkosítás nélkül kerülnek elküldésre a hálózaton, így sebezhetővé válik a kémkedés vagy a válasz megváltoztatása, valamint a böngésző rosszindulatú kiszolgálókra való átirányítása. A DNS-titkosítás megnehezíti a DNS-kérelmek nyomon követését vagy megváltoztatását az átvitel során. A DNS-kérelmek és -válaszok titkosítása megvédi Önt a Man-in-the-Middle támadásoktól, miközben ugyanazokat a funkciókat hajtja végre, mint a hagyományos egyszerű szöveges DNS (Domain Name System) protokoll.
Az elmúlt néhány évben két DNS-titkosítási protokollt vezettek be:
-
DNS-HTTPS felett (DoH)
-
DNS-over-TLS (DoT)
Ezekben a protokollokban van egy közös vonás: szándékosan elrejtik a DNS-kéréseket minden lehallgatás elől... és a szervezet biztonsági őrei elől is. A protokollok elsősorban a TLS-t (Transport Layer Security) használják, hogy titkosított kapcsolatot létesítsenek egy lekérdezést végző kliens és a DNS-lekérdezéseket feloldó szerver között egy olyan porton keresztül, amelyet általában nem használnak DNS-forgalomhoz.
A DNS-lekérdezések bizalmas kezelése e protokollok nagy előnye. Azonban problémákat jelentenek a biztonsági őrök számára, akiknek figyelniük kell a hálózati forgalmat, valamint észlelniük és blokkolniuk kell a rosszindulatú kapcsolatokat. Mivel a protokollok megvalósítása különbözik, az elemzési módszerek különböznek a DoH és a DoT között.
DNS HTTPS-n keresztül (DoH)
DNS HTTPS-en belül
A DoH a jól ismert 443-as portot használja a HTTPS-hez, amelyre vonatkozóan az RFC kifejezetten kimondja, hogy a cél az, hogy "a DoH-forgalmat keverje más HTTPS-forgalommal ugyanazon a kapcsolaton", "nehezítse a DNS-forgalom elemzését", és ezzel megkerülje a vállalati ellenőrzéseket. ( ). A DoH protokoll TLS titkosítást és a közös HTTPS és HTTP/2 szabványok által biztosított kérés szintaxist használja, hozzáadva a DNS kéréseket és válaszokat a szabványos HTTP kérésekhez.
A DoH-val kapcsolatos kockázatok
Ha nem tudja megkülönböztetni a normál HTTPS-forgalmat a DoH-kérésektől, akkor a szervezeten belüli alkalmazások megkerülhetik (és meg is fogják) megkerülni a helyi DNS-beállításokat azáltal, hogy a kéréseket a DoH-kérésekre válaszoló harmadik féltől származó szerverekre irányítják át, ami megkerül minden megfigyelést, azaz tönkreteszi a szabályozza a DNS forgalmat. Ideális esetben a DoH-t HTTPS visszafejtési funkciókkal kell vezérelnie.
И böngészőjük legújabb verziójában, és mindkét cég azon dolgozik, hogy alapértelmezés szerint minden DNS-kéréshez DoH-t használjon. a DoH integrálása az operációs rendszereikbe. Hátránya, hogy nemcsak a jó hírű szoftvercégek, hanem a támadók is elkezdték használni a DoH-t a hagyományos vállalati tűzfal intézkedések megkerülésére. (Például tekintse át a következő cikkeket: , и .) Mindkét esetben a jó és a rosszindulatú DoH forgalom is észrevétlen marad, így a szervezet vak lesz a DoH rosszindulatú felhasználása előtt, amely a rosszindulatú programok ellenőrzésére (C2) és érzékeny adatok ellopására szolgál.
A DoH forgalom láthatóságának és ellenőrzésének biztosítása
A DoH-vezérlés legjobb megoldásaként javasoljuk, hogy konfigurálja az NGFW-t a HTTPS-forgalom dekódolására és a DoH-forgalom blokkolására (alkalmazás neve: dns-over-https).
Először győződjön meg arról, hogy az NGFW a HTTPS visszafejtésére van konfigurálva .
Másodszor, hozzon létre egy szabályt az alkalmazásforgalomhoz "dns-over-https" az alábbiak szerint:
A Palo Alto Networks NGFW szabálya a DNS-t blokkolja a HTTPS-en keresztül
Átmeneti alternatívaként (ha szervezete nem valósította meg teljes mértékben a HTTPS visszafejtést) az NGFW beállítható úgy, hogy „megtagadás” műveletet alkalmazzon a „dns-over-https” alkalmazásazonosítóra, de ez a hatás csak bizonyos jól használható elemek blokkolására korlátozódik. a domain nevük alapján ismert DoH szerverek, tehát HTTPS dekódolás nélkül hogyan nem lehet teljes mértékben ellenőrizni a DoH forgalmat (lásd és keressen rá a "dns-over-https" kifejezésre).
DNS TLS-n keresztül (DoT)
DNS a TLS-en belül
Míg a DoH-protokoll hajlamos keveredni más forgalommal ugyanazon a porton, a DoT ehelyett alapértelmezés szerint egy speciális, erre a célra fenntartott portot használ, még akkor is, ha kifejezetten megtiltja ugyanazt a portot a hagyományos, titkosítatlan DNS-forgalom számára ( ).
A DoT protokoll a TLS-t használja a szabványos DNS-protokoll lekérdezések titkosítására, a jól ismert 853-as porton ( ). A DoT protokollt arra tervezték, hogy megkönnyítse a szervezetek számára a forgalom blokkolását egy porton, vagy fogadjon forgalmat, de engedélyezze a visszafejtést az adott porton.
A DoT-vel kapcsolatos kockázatok
A Google bevezette a DoT-t az ügyfélprogramjába , az alapértelmezett beállítással, hogy automatikusan használja a DoT-t, ha elérhető. Ha felmérte a kockázatokat, és készen áll a DoT használatára szervezeti szinten, akkor ehhez az új protokollhoz a hálózati rendszergazdáknak kifejezetten engedélyezniük kell a kimenő forgalmat a 853-as porton a kerületükön keresztül.
A DoT forgalom láthatóságának és ellenőrzésének biztosítása
A DoT-vezérlés bevált gyakorlataként a fentiek bármelyikét ajánljuk szervezete követelményei alapján:
-
Állítsa be az NGFW-t a 853-as célport teljes forgalmának visszafejtésére. A forgalom visszafejtésével a DoT DNS-alkalmazásként jelenik meg, amelyen bármilyen műveletet végrehajthat, például engedélyezheti az előfizetést. DGA tartományok vagy egy meglévő vezérléséhez és anti-spyware.
-
Egy másik lehetőség, hogy az App-ID motor teljesen blokkolja a „dns-over-tls” forgalmat a 853-as porton. Ez általában alapértelmezés szerint le van tiltva, nincs szükség semmilyen teendőre (hacsak nem engedélyezi a „dns-over-tls” alkalmazást vagy a port forgalmat 853).
Forrás: will.com