Vlákno názorů k článku
Otevřený resolver od CZ.NIC vypíná ochranu proti DNS Rebinding a upravuje DoH
od Martin Vancl - Tak konečně nebude nutné uživatelům s CZ.NIC DNS...
-
Ja jsem zastance, ze VPN nema menit DNS.
Sam jsem kvuli praci pripojeny do 3 VPN soucasne. A kdyby mi kazda "rozbila" DNS, nebyl bych rad.
Navic doma pouzivam ".lan". Takze napr. nas.lan. Kdyz mi VPN podvrhne vlastni DNS, prestane to vsechno fungovat.
Do doby, nez bude uplne vsude IPv6 je podle me nejmin spatne reseni mit ve verejnem DNS neverejne IPv4 (ano, 30 let stare RFC to nedoporucuje (ale nezakazuje)) a uzivatel at si pak pouzije DNS server, jaky chce.
-
Tak já teda nevím, spojím si v práci klidně pět VPN, každá natlačí svoje DNS a resolvuje to v pořádku požadavky do VPN a zbytek resolvuje na výchozích serverech. Mít ve veřejném DNS privátní adresy je prasárna na n-tou, stejně jako v interní DNS přebíjet veřejné záznamy.
Nicméně souhlasím s tím, že CZ.NIC nemá dělat policajta za druhé a vnucovat svoji vizi bezpečnosti jako univerzálně platnou.
-
Mít ve veřejném DNS privátní adresy je prasárna na n-tou
Proc presne?
Ja vam rad reknu, ze muj domaci NAS ma IP 10.123.1.1 a router 10.123.1.254. A k cemu vam to je, kdyz se do te site bez vpn nedostanete? Ano, pripadny utocnik ma vic informaci. Ale jak se do me site nekdo dostane, sit si proskenuje hned.Jak to vlastne je u IPv6, kde je z principu kazda IP adresa "verejna"?
Uz jen kvuli delce adresy bych rad pouzival DNS. A zabezpeceni resi firewall.
Jak je to tedy spravne? Mit extra DNS server pro vnitrni sit, aby to z internetu neslo resolvnout? Nebo vse ve vnitrni bude pouzivat IPv6 link-local (nebo jak se jmenuji "neverejne" IPv6) adresy?
Myslenka domaciho NASu s "verejnou" IPv6 je hezka, ale kdyz nebude mit DNS zaznam ve verejne dostupnem DNS, stejne se nevyhnu nejakemu cloudu/vpn, pres ktery se na nej budu pripojovat. A tim se zase kazi myslenka, ze kazde zarizeni v internetu ma verejnou IP adresu a muze komunikovat s libovolnym jinym zarizenim.stejně jako v interní DNS přebíjet veřejné záznamy.
s tim souhlasim -
Filip JirsákStříbrný podporovatelJak to vlastne je u IPv6, kde je z principu kazda IP adresa "verejna"?
Není. V IPv6 existují link-local adresy, které nejsou veřejné. Dále je v současné době z celého prostoru IPv6 adres vyňata jen malá část, která má dnes definovaná pravidla pro přidělování, zbytek je aktuálně nepoužívaný – takže to také nejsou veřejné adresy.Jinak v IPv4 byly původně také všechny IP adresy z principu veřejné, s výjimkou těch několika málo vyhrazených rozsahů.
Mit extra DNS server pro vnitrni sit, aby to z internetu neslo resolvnout?
To, že jde adresu z internetu přeložit, přece ničemu reálně nevadí. Dvojí DNS je mnohem větší zlo. -
To, že jde adresu z internetu přeložit, přece ničemu reálně nevadí. Dvojí DNS je mnohem větší zlo.Presne to si taky myslim! Informace, ze muj router ma 10.123.1.254 je temer k nicemu.
Ja to myslel trochu jinak. Kdyz mam od ISP globalni (nebo jak se jmenuji "verejne" IPv6), tak i tiskarna ma svoji IPv6. A ja pak mam i na tiskarnu AAAA zaznam. Ale muj firewall na ni nedovoli spojeni z internetu.
-
Filip JirsákStříbrný podporovatel
Dvojí DNS zlo není, split-horizon se dá udělat i dobře a bez rizik kolizí.
Jak vyřešíte změnu sítě? Síť nemusí změnit samotné zařízení, může ji změnit třeba WiFi AP, ke kterému je připojené. Dále to komplikuje třeba nasazení DNSSEC. -
> To, že jde adresu z internetu přeložit, přece ničemu reálně nevadí.
Záleží. Znalost IP adresy lze zneužít právě k DNS rebindingu. Na druhou stranu, obrana by IMHO neměla stát na neznalosti IP adresy, tu lze třeba i hádat.
A na třetí stranu, kdybych byl správce nějaké sítě s delší historií a neměl moc tušení, jak kdo v minulosti kde řešil bezpečnost, asi by hromadné vystavení privátních adres do veřejného DNS nebylo zrovna mým prvním krokem...
-
Filip JirsákStříbrný podporovatel
Proto jsem psal, že to reálně nevadí.
Nebavíme se o situaci, kdy by split horizon existoval a měl by se bezhlavě zrušit. Řešíme tu přesně opačnou situaci, zda to teď zavádět.
-
Neměl jsem na mysli bezpečnost, privátní adresy sice útočníkovi prozradí nějaké informace navíc, ale stejně na tom zabezpečení stát nemůže. Měl jsem na mysli hlavně provozní čistotu.
Z hlavy Vám vyjmenuju dva důvody, proč nemít privátní adresu v DNS:
1. když nebudete mít spojenou VPN, stejně se resolvne privátní adresa a služby budou čekat na timeouty, než zjistí, že je cíl nedostupný (málokterý router má pro vnitřní požadavky nastavený rychlý REJECT, obvykle se to prasí přes DROP)
2. když se potkáte se sítí se stejným privátním rozsahem, může se Vám stát i to, že se nějaká Vaše služba strefí do živé IP adresy a otevřeného portu - pak můžete zažít i divy.Jediným řešením je mít v privátní síti vlastní autoritativní DNS. DNS bude odpovídat pouze ve chvíli, kdy je VPN navázaná a cílová síť dostupná. Okamžitě budete vědět, že VPN neběží správně, když se adresa ani neresolvuje.
S IPv6 potřeba VPN prakticky odpadá a potřeba veřejného DNS roste. Můžete se samozřejmě rozhodnout využívat neveřejné rozsahy IP adres a spojovat se jen přes VPN. Nebo můžete využívat veřejný blok, ale zakázat směrování na routeru. Prefix pak může být dostupný jen přes VPN.
Na IPv6 můžete v DNS použít split-horizon nastavení. Ve vnitřní síti můžete povolit resolvovat víc záznamů, než ve veřejné síti. Při vypnuté VPN adresu privatni-sluzba.mojedomena.cz vůbec neresovlnete, ale při spojení VPN už ano. Toto řešení je narozdíl od přebíjení záznamů poměrně v pohodě. Abyste nemusel hlídat, že nevytvoříte kolizi (omylem nebudete přebíjet stejný veřejný záznam vnitřním), řešívá se to pře další řád domény - např. xxx.home.mojedomena.cz, kteréžto ve veřejné části vůbec nebudou.
Správných řešení je tedy víc, ty priváty ve veřejném DNS jsou opravdu zoufalost (obvykle z lenosti nebo neznalosti).
-
2. když se potkáte se sítí se stejným privátním rozsahem, může se Vám stát i to, že se nějaká Vaše služba strefí do živé IP adresy a otevřeného portu - pak můžete zažít i divy.
To bohuzel bezne resim. Ale DNS na tom nema zadny vliv. Kdyz uzivatel pise v prohlizeci rucne IP adresu, tlouct se to bude stejne. -
Ale Vy mi pisete, ze moje neverejna IP v DNS muze kolidovat s jinou siti.
Pokud máte interní resolver, který je dostupný jen po spojení VPN, tak se to nestane. Okamžitě vypadne error (nečeká se ani na timeouty). Kromě toho, co dělá uživatel ručně (třeba v prohlížeči), mohou se službami v privátní síti komunikovat i programy a služby bez interakce s uživatelem. Opět, když je nakonfigurujete přes FQDN a ne přes IP adresu, omezí se riziko těchto problémů.
-
Uzivatel ma doma sit 192.168.1.0/24.
Moje VPN ma rozsah treba 10.20.30.0/24 (nepotluce se hned na pripojeni), ale pres DHCP option posle uzivateli, ze ma pouzit VPN DNS server na 10.20.30.1.
server.example.net ve verejnem DNS neexistuje, ale ve vnitrnim ano - takze DNS server 10.20.30.1 uzivateli pripojenemu k VPN vrati "server.example.net A 192.168.1.1".Jasne, nikdo asi neda servery do 192.168.1.0/24. Ale muze. Ono i v 10.0.0.0/8 se da dojit ke kolizi.
A jak mi muj vyse popsany zpusob pomuze, aby se nepletly adresni rozsahy?
Muj DNS vrati 192.168.1.1, ale to je zaroven treba uzivateluv router. A kvuli metrice se pravdepodobne uzivatel pres server.example.net nedostane na muj server za vpn, ale na svuj router.Jak mi pomoho nemit neverejne IP ve verejnem DNS? Kolize stejne nastala.
Proste kdyz nemam kontrolu nad sitemi na obou stranach VPN, kolize adres vzdy muze nastat. -
@Martin Vancl
Pokud připojíte VPN síť s kolizním adresním prostorem, nedostanete se ani na to interní DNS. Tím pádem Vám DNS nevrátí záznam a služba (prohlížeč) se nepokusí připojit na kolizní IP adresu. Druhou výhodou je, že ten problém je rychle viditelný - TCP sese čekají na dlouhé timeouty, zatímco DNS timeoutuje rychle a se zcela zřejmou hláškou (not found, NXDOMAIN) oproti dost neurčité TCP connection timeout.
-
Presne tohle jsem resil pri stavbe novych DNS serveru (v kombinaci s ipv6), nebot extra interni servery zvysuji mnozstvi DNS serveru v siti, navic kdyz je vice lokalit a dela se redundance...
Nakonec jsem to prozatim vyresil jednoduse. Pred verejnymi auth servery je predsazeny dns balancer, ktery ridi pristup requestu na subfqdn/networks dle acl. Z tohoto reseni vyplynulo
1] netreba mit extra servery jen pro interni potreby - zadny split-view atd...
2] kazdy server muze byt v nouzi pouzity jako externiDelal jsem to hlavne pro to, ze zrovna requesty na AD radice neni moc optimalni mit verejne.
10. 7. 2020, 09:04 editováno autorem komentáře
-
„Jak to vlastne je u IPv6, kde je z principu kazda IP adresa "verejna"?“
„(nebo jak se jmenuji "neverejne" IPv6) adresy?“ULA nejsou veřejné. V případě jejich uvedení ve veřejném DNS je problém shodný s tím v IPv4.
Osobně si myslím, že co mám v DNS, je především mým problémem a můj problém to má řešit. Nikomu nevnucuju, aby se v mých doménových jménech hrabal.
Když si do svého doménového jména napíšu veřejnou, ale cizí IP, je to špatně? Je to podobný problém?
Zkráceno: Moje doména, moje věc. -
Když si do svého doménového jména napíšu veřejnou, ale cizí IP, je to špatně? Je to podobný problém?
Zkráceno: Moje doména, moje věc.Souhlas, ale bavíme se o DNS resolverech provozovaných CZ.NICEM za nějakým účelem. Kladou si za cíl zvyšovat bezpečnost a proto volí (volili) některá nastavení.
Nikdo nenutí druhý konec (VPN), aby využíval CZ.NIC nebo Google resolvery, DNS by se mělo brát descendentně od od ISP a potažmo místního routeru. K dodržování této praktiky jsou taky dobré důvody.
-
Filip JirsákStříbrný podporovatel
Mít ve veřejném DNS privátní adresy je prasárna na n-tou
Čemu to reálně vadí? Prasárna na n-tou je používat v internetu privátní IP adresy. Jenže když už veřejné IPv4 adresy dávno došly, nic jiného nám nezbývá. Že se privátní IPv4 adresy objeví v DNS, to už je jen důsledek. A jsou mnohem horší důsledky (třeba NAT). -
Každý moderný operačný systém vie používať viacero DNS (linux potrebuje používať dnsmasq alebo systemd-resolved, nie čistý /etc/resolv.conf), ku ktorým má info, ktoré zóny vie príslušný resolver obslúžiť.
Takže nie je najmenší problém, keď si každá jedna VPN nastaví svoj DNS a info, ktoré zóny sú cez ňu dostupné. Nnič nie je rozbité.
Naopak rozbité to je, ak sa niečo pchá do globálnej DNS a vždy sa nájde zákazník, ktorý má svoj resolver obmedzený na svoje ip adresy.
-
Jde treba nastavit OpenVPN a strongSwan, aby na Windows, Linuxu, MacOS i Androidu tohle delaly?
Jestli ne, zustavam u neverejnych IP ve verejnem DNS.
Je nerealne vsem vyvojarum a lidem z podpory (odepisovacum na emaily), kteri potrebuji mit pristup do internich systemu pres nejakou vzdalenou plochu ladit nastaveni DNS na jejich PC a mobilech...
A pokus o nastaveni vlastniho DNS serveru z VPN byl. Ale dost lidi se ozvalo, ze jim doma neco nefunguje, nebo naopak ze jim to rozbilo veci ve VPN od jineho zakaznika/zamestnavatele.
-
Jde treba nastavit OpenVPN a strongSwan, aby na Windows, Linuxu, MacOS i Androidu tohle delaly?
Jistě, standardně se to dělá přes DHCP options, stejně jako přes ně posíláte routy. StrongSwan jsem nezkoušel. (Pohodlnější je mi používat standardní typy - tedy L2TP a IKEv2, které jsou jak ve Windows tak v Macu hned dostupné).
-
Linux: Pokial používate NetworkManager pre konfiguráciu VPN, treba zmeniť v NetworkManager.conf dns=dnsmasq a v definícii VPN nastavit atribúty ipv4.dns-search, resp. ipv6.dns-search na zóny, ktore tam potrebujete a bude Vám to presne takto fungovať.
Vyskúšané so strongswan+l2tp (org.freedesktop.NetworkManager.l2tp), openvpn (org.freedesktop.NetworkManager.openvpn) a fortigate (org.freedesktop.NetworkManager.fortisslvpn).
Mac: používa nastavenie resolver v /etc/resolver. Je to texťák, ktorý definuje zónu a k nej patriace DNS resolvery. "echo nameserver 192.168.0.4 > /etc/resolver/zona.firma.cz", overenie cez "scutil --dns".
Windows: Nastavuje sa cez NRPT, "Add-DnsClientNrptRule -Namespace "zona.firma.cz" -NameServers "192.168.0.4"". Dá sa to nastaviť aj cez GPO.
-
Nezmysel, dnsmasq vyšiel už v roku 2001, systemd-resolved "iba" v 2016.
Kto dodnes používa /etc/resolv.conf ako primárnu konfiguráciu a nie ako fallback pre staré aplikácie, ktoré ignorovali systémový resolver (potažmo nsswitch), tak 100 rokov za opicami má spôsobené vlastnými rukami. V resolv.conf ani v budúcnosti nebudete môcť definovať viacero DNS serverov, per-interface DNS ani per-zone DNS, pretože je určený pre legacy aplikácie, ktoré dodnes neboli updatnuté, aby využívali systém tak, ako majú, takže veľa šťastia s ich updatovaním, aby nebodaj pochopili nový formát resolv.conf.
Linux totiž už roky ponúka iné mechanizmy, len ich treba použiť, resp. si aspoň niečo prečítať, nie len opakovať to, ako sa to robilo doteraz - aj historický RHEL6 používa NetworkManager. Jasné, že pri neustálom opakovaní starých vecí budete 100 rokov za opicami, ale to nie je chyba Linuxu.
-
No lenže to je presne to isté, čo robia systémy, ktoré nie sú "100 rokov za opicami". Na Windows beží servis "DNS client", na macOS mDNSResponder (áno, napriek názvu resolvuje aj normálne DNS). Okrem resolvovania aj udržujú cache naprieč procesmi.
Pokiaľ máte na serveri problém udržať bežiaci DNS resolver, tak tie problémy siahajú omnoho hlbšie...
Konfigurácia fallbacku sa neudržuje, je zvyčajne 127.0.0.53, a tam počúva práve ten démon, ktorý musí bežať. Resp. systemd-resolved to tiež vie udržiavať ako symlink na synteticky generovanú konfiguráciu.
-
Windows podporuje DHCP option 119 (dns-search) až od verzie 10 (1803). Verzie pred ním to museli mať nastavené cez GPO. Okrem toho všetky verzie podporujú DHCP option 15 (dns-domain), ale tam sa dá dať iba jedna doména, na rozdiel od 119.
Okrem toho niektoré VPN majú veľmi obmedzené možnosti, čo sa cez DHCP dá preniesť. Napr. taká L2TP nedokáže ani routy, takže treba dodatočne konfigurovať profil na klientovi.
-
Díky, aj som našiel stackoverflow článok na túto tému: https://serverfault.com/questions/574121/is-it-possible-for-l2tp-vpn-to-do-auto-route-configuration-for-client-during-con
Teraz ešte zistiť, ako donútiť Ubiquiti krabicu, aby vôbec posielala DHCP cez L2TP...
