Az új DNS protokollok megnehezíthetik a DNS kérések monitorozását, valamint az azok módosításán, vagy szűrésén alapuló biztonsági intézkedések alkalmazását.
A protokollok a nem megbízható hálózatokon javulást jelenthetnek biztonsági és adatvédelmi szempontokból, azonban vállalati környezetben hatástalanná tehetik az alkalmazott biztonsági házirendeket. Ezeket a hatásokat hálózati szinten kezelni nehéz, így a DNS infrastruktúrát és az egyes eszközöket a megváltozott környezethez kell igazítani.
Névfeloldási nézetváltás a felhasználói szoftverekben
Egyre több szoftver változtat azon, hogy miként hajtja végre a névfeloldást. Az alkalmazások sokáig az operációs rendszer által nyújtott könyvtárakkal oldották meg a névfeloldási feladatokat. Ennek következményeképpen az alkalmazások egy névfeloldó kiszolgálót használtak, amelynek beállításai határozták meg, hogy a lekérdezések hova kerültek továbbításra.
Egyes fejlesztők a korábban használt operációs rendszer könyvtárai helyett magukba az alkalmazásokba integrálták a névfeloldást, ezzel lehetőséget adtak arra, hogy az alkalmazás ─ operációs rendszer szintű támogatás hiányában ─ élvezhesse az új DNS titkosítási protokollok nyújtotta előnyöket. Ebben az esetben az alkalmazás fejlesztője határozza meg, hogy a lekérdezések hova kerülnek továbbításra.
A Mozilla Firefox böngésző saját névfeloldási megoldást kínál a felhasználóinak, amely a DNS-over-HTTPS szabványt támogatja. A funkció jelenleg az amerikai felhasználók számára egy opt-out kísérlet keretében alapértelmezés szerint bekapcsolásra kerül (lásd: What’s next in making Encrypted DNS-over-HTTPS the Default – Future Releases).
A Google a Chrome böngésző felhasználói között DoH funkcionális tesztelést hajt végre (lásd: DNS over HTTPS (aka DoH) – The Chromium Projects).
Az Android 9 Pie a nyílt szöveges DNS kéréseket DoT protokollra „javítja”, amennyiben azt a névfeloldó kiszolgáló támogatja (lásd: Android Developers Blog: DNS over TLS support in Android P Developer Preview).
Mit jelent ez?
Azok a szervezetek, amelyek a nyílt szöveges DNS forgalom monitorozására hagyatkozva alkalmaznak biztonsági korlátozásokat, arra számíthatnak, hogy a látható kérések száma csökkenni fog és a rendszer szintű névfeloldási beállítások által eszközölt korlátozások hatástalanná válhatnak, ha a felhasználói szoftverek alternatív kiszolgálók felé fordulnak a kéréseikkel.
A DNS kérések érzékeny információkat tartalmazhatnak (meglátogatni kívánt weboldalak címei, cél domainek az e-mailek esetében, belső hálózati hosztnevek), ezért a névfeloldási feladatra kiválasztott kiszolgáló irányába egyfajta bizalom megléte szükséges. Ha a szervezet felügyelete alatt álló eszközök, szoftverek egy harmadik fél által irányított kiszolgálóhoz fordulnak a névfeloldási kérésekkel, akkor a nevezett érzékeny információk harmadik fél birtokába juthatnak. Ennek jogi háttere is összetett lehet, hiszen nem biztos, hogy a szervezetünkre vonatkozó jogszabályok lehetővé teszik harmadik fél ilyen jellegű bevonását, és egy adminisztrátor nem biztos, hogy minden esetben észreveszi, hogy egy felhasználói alkalmazás megkerüli a rendszer szintű DNS beállításokat. Ez kockázatot jelenthet.
Kapcsolat megtörése: egyes szervezetek a belső hálózati hosztneveik feloldására megtették a szükséges beállításokat a saját infrastruktúrájukban. Amennyiben egy felhasználói szoftver harmadik fél irányába küldi a névfeloldási kérést, a publikus kiszolgáló nem fogja tudni a megfelelő címre feloldani a kért hosztnevet. Ez okozhatja a belső hálózati kapcsolatok és VPN-ek használhatatlanságát.
Mit lehet tenni?
A szervezetek adminisztrátorainak szükséges felkészülni a névfeloldási megoldások jelentős megváltozására.
Felügyelet alatt álló rendszereknél
Érdemes egy kiszolgálót kiválasztani és rendszer szinten konfigurálni a használatát. Érdemes DoT vagy DoH protokollokat támogató névfeloldású kiszolgálókat beállítani.
Határozzuk meg, hogy az eszközök hova küldjék a DNS kéréseiket:
- Saját névfeloldó kiszolgálót használunk vagy harmadik fél biztosítja a szolgáltatást?
- Mi a következménye annak, ha a kliensek (eszköz, szoftver) nem preferált kiszolgálóra váltanak?
- bizalmasság sérülhet
- belső DNS zónák névfeloldása nem működik publikus kiszolgálókon
- teljesítmény és rendelkezésre állás kérdése (egy felhasználói szoftver nem biztos, hogy tartalmaz SLA-t a harmadik fél által üzemeltetett kiszolgálóval)
- biztonsági kontrollok (DNS szűrés, monitoring) hatékonysága csökkenhet
- hibakeresés megnehezítése
Lássuk át, hogy a felügyelet alatt álló eszközök miként jutnak a névfeloldási beállításaikhoz:
- a legtöbb hálózat DHCP-n terjeszti a DNS beállításokat
- hálózati flow segíthet a szervezetben használt névfeloldók azonosításában
Legyünk tisztában azzal, hogy mely alkalmazások használ(hat)nak alternatív névfeloldókat:
- web böngészők és kiegészítők
- mobil alkalmazások
A saját névfeloldási megoldással rendelkező kliensek (eszköz, szoftver) alapértelmezett beállításai is megváltoztathatóak:
- A Mozilla Firefox és Google Chrome böngészők beállíthatók, hogy a kívánt DoH kiszolgálók felé küldjék a DNS kéréseiket.
A nem megbízható hálózatok esetén (vendég hálózat, nem menedzselhető eszközök/BYOD hálózata)
Idővel az eszközök és szoftverek az új, DNS lekérdezés titkosítást használó protokollokat fogják használni, vagy olyan névfeloldási beállításokkal rendelkeznek majd, amelyek nem illeszkednek a szervezet házirendjébe. Az eszközök jelentette kockázatokat fel kell mérnünk és a kezelésükre választ kell adnunk az alábbiak figyelembevételével:
- a nyílt szövegű DNS kéréseken alapuló biztonsági kontrollok hatékonysága csökkenhet
- egyes alkalmazások figyelembe veszik a hálózati szinten megadott DNS kezelést
- a Mozilla Firefox egy „kanári domain” segítségével beállítható, hogy a megadott névfeloldó kiszolgáló DNS szűrési szabályait vegye figyelembe
Forrás: NCSC factsheet
