Sziasztok!
Arra lennék kíváncsi, hogy van-e valakinek valamilyen gyakorlati, jó megoldása a DoH kontrollálására.
Kifejezések tisztázása:
- DoH == DNS over HTTPS, a DNS kérések HTTPS-en utaznak 443/tcp-n
- DoT == DNS over TLS, a DNS kérések TCP payloadként TLS-be tekerve utaznak 53/tcp-n
Háttér:
A környezet home environment, szóval semmi üzleti kritikus cumóról nincs szó. Fogalmazzunk úgy, hogy az otthoni infra permanens test lab mindenféle use-case-ek életszerű, mindennapi használattal járó kitesztelésére.
A cél:
DNS kérések utazzanak externet szakaszon secured transporton, de a belső DNS szerver ne legyen megkerülhető.
Per pillanat az intra DNS logika a következőképpen néz ki. Adott két ANS melyek a belső zónákat szolgálják ki. Adott két CNS, melyeken a conditional forwarderek az ANS-ek felé küldik a belső zónákra irányuló kéréseket. Minden egyéb kérést a CNS hostokon, localban figyelő dnscrypt-proxy továbbítja az upstream NS-ek felé DoT-on. A border GW-en minden 53-ra érkező kérés a belső CNS felé van forwardordolva tűzfal szabályokkal.
A jelen logika célja többrétű:
- A CNS-ek DNS alapú szűrést végeznek, így minden hálózatra kötött kliens bizonyos szintig védettséget élvez: ad, kártékony oldalak, session replay scriptek, stb. Pl. mobil folyton OpenVPN-en lóg és a CNS-eket kérdezi, szóval nem kell a szűréssel kliens oldalon bohóckodni.
- Egy esetleges belső host kompromittálódás esetén DNS alapú védelmi réteget biztosít. Pl. feltételezve hogy a kártékony kód logika hardkódolt DNS szervereket tartalmaz, az abba az irányba küldött kérést is az intra CNS terminálja, így szűri. Nyilván a védettség nem 100%-os, ez csupán az egyik védelmi réteg.
- A külső hálózaton a DNS kérések TLS-be tekerve utazzanak.
Viszont az utóbbi időben nagyon úgy néz ki hogy a DoH irányába mozdulnak el a browser vendorok [1]. A gondom ezzel az, hogy kb. pofán csapja a fenti logikát és teljesen kicsúszik a fent vázolt kontroll a kezemből. Értem én a privacy törekvéseket és bizonyos fokig még egyet is értek velük, de keresek valami egészséges egyensúlyt.
Látom pl. hogy nginx-ben implementálható a DoH/DoT GW [2]. Ha pl. a róka nagyon szeretne csak DoH-on beszélgetni, ez erre a részére megoldást jelenthetne. Viszont továbbra is kérdés a kimenő, DoH felett utazó, nem kívánatos kérések kontrollja. Nyilván a HTTPS tartalom vizsgálatára és annak függvényében valamilyen döntési mechanizmusra van szükség. Amire gondolni tudok az egy HTTPS proxy, ami érzésem szerint felhasználói oldalról nézve performancia overhead-et jelentene az egyébként normál HTTPS forgalom esetén is. Emellett, tekintve hogy ez feltételezi a teljes HTTPS forgalom vizsgálatát, meglátásom szerint éppen a HTTPS-sel járó privacyt csapja pofán. Permanens eavesdropping ha úgy tetszik.
Szóval a poszt célja kettős:
- Mit gondoltok erről az egész DoH témáról a poszt címe és a fentiek kontextusában?
- Van-e valamilyen gyakorlati, kiegyensúlyozott megoldási ötletetek arra, hogy az eddigi működési logika DoH mellett megmaradjon, feltételezve hogy várhatóan az hamarosan ki lesz kényszerítve.
--
[1] https://blog.mozilla.org/blog/2020/02/25/firefox-continues-push-to-bring-dns-over-https-by-default-for-us-users/
[2] https://www.nginx.com/blog/using-nginx-as-dot-doh-gateway/
