HTTPS na privátní adrese

[Miroslav Šilhavý]

Akorát že vůbec nejde o počet spojení, ale o datový tok. Pokud má ta síť připojení do internetu 100 Mbit/s, musí ten router umět uNATovat 100 Mbit/s. Pokud bude mít server s 1 Gbit/s síťovkou, měl by ten router umět uNATovat 2 Gbit/s. To je sakra rozdíl.

U routeru bude zásadnější packet rate, než propustnost pásma. Pokud by se jednalo o gigabity, je jak otázka, tak zvažovaná řešení mimo mísu. V takovém případě by si to opravdu žádalo zajistit si veřejné ip adresy a servery mít na takovém segmentu.

Navíc na tom serveru nepoznáte, odkud ta spojení jdou, všechna budou z routeru – nemůžete dělat QoS, nic nepoznáte z logu.

Uznávám.

Že je to řešení pro síťaře čitelné a chová se vypočitatelně je snad vtip. Porovnáváte přímé spojení přes switch se spojením dvakrát NATovaným na routeru. Nechcete snad tvrdit, že ten dvojitý NAT to zpřehlední a vylepší…

Jak co. Pro ladění opravdu hlubokých problémů je dvojitý NAT peklo (ostatně, jakýkoliv NAT). Zase na ladění vyšších služeb, aplikací atd., aby člověk přemýšlel, kde je zadrátovaná IP adresa na pevno, jakou cestou se z jakého programu reslovuje atd. atd. Podle mě si nevyberete. Uznávám, že jsem tvrzení vzal moc zhurta, ono to bude asi prašť jako uhoď.

[Reklama]

[Stilett]

Děkuji za podněty. Asi se vydám cestou převádění na veřejné adresy (po ověření, že to v daných sítích funguje a nedělá nějaké veletoče na NATu).

Jinak doplním, že k žádnému přebíjení DNS nedochází. Prostě jsem dotyčnému serveru přiřadil normální doménové jméno, která vždy a všude ukazuje na jeho privátní adresu. Jestliže má server i veřejnou IP adresu, tak je pro ni použito jiné doménové jméno.

Detekce problému a poslání uživatele na server s veřejnou IP adresou by fungovalo dobře. Těch pár uživatelů, kteří nepojedou z centrálních serverů, se snese. Jediná nevýhoda je, že to vyžaduje dodělání podpory do aplikace, protože je potřeba to vyzkoušet ze strany klienta a nemohu detekci provést z backendu.

[Filip Jirsák]

U routeru bude zásadnější packet rate, než propustnost pásma.

Což na věci vůbec nic nemění.

Pokud by se jednalo o gigabity, je jak otázka, tak zvažovaná řešení mimo mísu.

Proč? Otázka i zvažovaná řešení (až na ten návrat k NATu) jsou na objemu přenášených dat zcela nezávislá.

V takovém případě by si to opravdu žádalo zajistit si veřejné ip adresy a servery mít na takovém segmentu.

Vy to prostě přes ten router poženete za každou cenu, i když jsou klienti i server na stejném segmentu sítě.

aby člověk přemýšlel, kde je zadrátovaná IP adresa na pevno, jakou cestou se z jakého programu reslovuje atd.

IP adresa není zadrátovaná napevno nikde, z programu se resolvuje normální cestou systémového resolveru, tak jako ze všech ostatních programů na daném počítači a jako ze všech ostatních zařízení v dané síti.

Podle mě si nevyberete. Uznávám, že jsem tvrzení vzal moc zhurta, ono to bude asi prašť jako uhoď.

Já si teda vyberu, nějak mi chybí ta správná motivace nacpat NAT kamkoli, i když tam vůbec není potřeba.

[V.]

Dobrou praxí je mít nějaké domény dostupné pouze zevnitř a některé pouze z venku. A podle záměru pak chodím tam, kam a jak potřebuji. Oddělím tak i přes DNS provoz.

Ai veřejné IPv4 adresy lze mít na internetu neroutované, tj. jsou vyhražené pro nějaké DMZky, NATy (protože veřejná jde defaultkou z LAN pryč) apod.

[Ondřej Caletka]

Je to tedy pitomé chování toho routeru (dnsmasq), nebo by se taková věc opravdu neměla dělat? Jak mám tedy používat HTTPS na privátní IP adrese?

Na routeru lze obvykle nastavit výjimku pro určitou doménu, ale není to zrovna hromadné řešení problému.

Není to pitomé chování routeru. Privátní adresy by se ve veřejném DNS neměly vyskytovat už jenom z toho důvodu, že se k nim veřejným internetem nedá dostat. Stejnou ochranu má implicitně zapnutou i Unbound. Privátní adresy taky vůbec nepatří do sítě ISP jakékoli velikosti, protože zde hrozí riziko konfliktu rozsahu s místem, kam privátní adresy patří, tedy koncovou sítí zákazníka. Zákaznický router předpokládá, že na WAN straně je veřejná síť, ze které žádné odkazy na privátní adresy (= ty na straně LAN) nemají co chodit.

Použijte tedy adresu z vyhrazeného prefixu pro CGN 100.64.0.0/10. Adresy z tohoto rozsahu nejsou v DNS odpovědích filtrovány – přinejmenším ne v Unboundu a ne v dnsmasq. Další možností jsou dokumentační IP prefixy, které si lidé s oblibou půjčují, když chtějí „něco jako veřejnou adresu“. Tam je ale riziko, že po určité době napadne někoho jiného něco podobného a celé se to rozbije.

[Reklama]

[Filip Jirsák]

Není to pitomé chování routeru. Privátní adresy by se ve veřejném DNS neměly vyskytovat už jenom z toho důvodu, že se k nim veřejným internetem nedá dostat.

Ale „veřejné“ DNS přece vůbec neznamená, že je ta adresa veřejná. Přece proto se zavádělo třeba NSEC3, aby nebylo možné DNS záznamy vypsat.

Privátní adresy taky vůbec nepatří do sítě ISP jakékoli velikosti, protože zde hrozí riziko konfliktu rozsahu s místem, kam privátní adresy patří, tedy koncovou sítí zákazníka.

To, že jsou v síti privátní IP adresy, přece neznamená, že se nebude používat DNS. A DNS předpokládá, že se bude používat jeden společný root, tedy veřejné DNS – provozovat privátní DNS stromy je sice možné, ale není to podporované, jsou s tím problémy a budou s tím čím dál větší problémy.

Stejnou ochranu má implicitně zapnutou i Unbound.

Což nic nemění na tom, že je to – slušně řečeno – hloupý nápad.

[Ondřej Caletka]

Ale „veřejné“ DNS přece vůbec neznamená, že je ta adresa veřejná. Přece proto se zavádělo třeba NSEC3, aby nebylo možné DNS záznamy vypsat.

O to vůbec nejde. Jde o to, že ve veřejném DNS stromu, který je globálně dostupný, by měly být pouze globálně dostupné adresy. To nevylučuje použití veřejného DNS pro lokálně dostupné adresy, při kterém se takovéto DNS odpovědi nebudou šířit za hranu lokální sítě. A taková hrana logicky existuje i mezi sítí ISP a sítí zákazníka. Privátní adresy podle RFC 1918 navíc úplně jasně patří do sítě zákazníka, nikoli do sítě ISP, je tedy logické, že router zákazníka bude pokusy o průnik takových adres ze strany ISP blokovat.

Stejnou ochranu má implicitně zapnutou i Unbound.

Což nic nemění na tom, že je to – slušně řečeno – hloupý nápad.

Hloupý nápad to rozhodně není. Přeci nechcete, aby třeba Root.cz umístil do své domény A záznam s adresou 10.0.0.138 a během čtení článků nic netušícím čtenářům na pozadí AJAXem konfiguroval jejich ADSL modem.

[Vilith]

S Jirsakem se nediskutuje: https://youtu.be/XDJEPjvbbs4

[Filip Jirsák]

O to vůbec nejde. Jde o to, že ve veřejném DNS stromu, který je globálně dostupný, by měly být pouze globálně dostupné adresy. To nevylučuje použití veřejného DNS pro lokálně dostupné adresy, při kterém se takovéto DNS odpovědi nebudou šířit za hranu lokální sítě. A taková hrana logicky existuje i mezi sítí ISP a sítí zákazníka. Privátní adresy podle RFC 1918 navíc úplně jasně patří do sítě zákazníka, nikoli do sítě ISP, je tedy logické, že router zákazníka bude pokusy o průnik takových adres ze strany ISP blokovat.

To, že je nějaký DNS název globálně dostupný, přece vůbec nic neznamená. DNS název používá ten, kdo ho zná, a DNS vůbec nemá řešit, odkud se na to ptá. V té privátní síti můžu být přímo, můžu tam mít VPN spoj. Router zákazníka nemá pouštět do vnitřní sítě pakety, které mají jako zdrojovou nebo cílovou adresu privátní síť, ale vnitřek komunikace ho zajímat nemá.

Hloupý nápad to rozhodně není. Přeci nechcete, aby třeba Root.cz umístil do své domény A záznam s adresou 10.0.0.138 a během čtení článků nic netušícím čtenářům na pozadí AJAXem konfiguroval jejich ADSL modem.

Tohle je ale problém zabezpečení toho ADSL modemu. Pokud se to někdo pokouší řešit v DNS, je to kontraproduktivní, protože to žádné zabezpečení není. Ten modem může mít veřejnou IP adresu, můžu dát do DNS CNAME záznam na jeho A záznam – a nebo ten ADSL modem půjde prostě překonfigurovat jedním POST požadavkem na IP adresu, a že se útočná webová stránka nedozví výsledek je úplně jedno.

Nepoužívat ve veřejném DNS IP adresy z privátních rozsahů by mělo smysl, kdyby byl dostatek veřejných IP adres a privátní IP adresy se používaly jenom ve výjimečných případech, kde by to dávalo smysl. To ale dnes neplatí a privátní IP adresy se používají jako náhrada veřejných IP adres tam, kde nemusí být daná zařízení dostupná z celého internetu, ale stačí z vybraných sítí.

Kvůli DNSSEC nebo TLS certifikátům chceme mít jeden DNS strom, tak holt musíme umět do tohoto stromu k neveřejným DNS záznamům přidat privátní IP adresy, když nic jako „neveřejné“ IP adresy neexistuje. Je to nejmenší zlo – a je jedině dobře, pokud to někomu zabrání myslet si, že zákazem A záznamu na ADSL modem něco zabezpečil.

[Vilith]

Privatni IP adresy do verejneho DNS proste NEPATRI

At si preferuje tenhle BORDEL kdo chce, ale kdo to blokuje, ten jen dela dobre

[Filip Jirsák]

Privatni IP adresy do verejneho DNS proste NEPATRI

„Prostě“ a tučné písmo jsou hodně slabé protiargumenty.

Co je podle vás „veřejné DNS“? Je „veřejné DNS“ privátní záznam, o kterém nikdo mimo vybraných uživatelů neví, že existuje?

kdo to blokuje, ten jen dela dobre

Proč? Čeho tím blokováním docílí?

Jinak tu řešíme prkotinu – kdo ve své síti privátní IP adresy a na ně směřující DNS záznamy používá, ten je na svém DNS resolveru povolí. Takže problém mohou mít akorát ti, kdo používají jiný DNS resolver, nejčastěji uživatelé připojení přes VPN – tak uživatelům VPN změníme DNS resolver, případně uneseme DNS dotazy, a problém je vyřešen. Já teda únosy DNS dotazů považuju za daleko větší problém, než privátní IP adresy v neveřejných DNS záznamech – jestli vy to máte opačně, je to váš problém.

[Vilith]

https://youtu.be/XDJEPjvbbs4

[Ondřej Caletka]

Jinak tu řešíme prkotinu – kdo ve své síti privátní IP adresy a na ně směřující DNS záznamy používá, ten je na svém DNS resolveru povolí. Takže problém mohou mít akorát ti, kdo používají jiný DNS resolver, nejčastěji uživatelé připojení přes VPN – tak uživatelům VPN změníme DNS resolver, případně uneseme DNS dotazy, a problém je vyřešen. Já teda únosy DNS dotazů považuju za daleko větší problém, než privátní IP adresy v neveřejných DNS záznamech – jestli vy to máte opačně, je to váš problém.

O prkotinu jde v každém případě. Jen si stojím za tím, že filtrování privátních adres přijatých v DNS odpovědích z veřejného internetu je správné výchozí nastavení. Lidé, kteří vědí, že takové privátní adresy jsou v síti jejich ISP používány by měli nastavení upravit, ne naopak. Protože těch případů, kdy z internetu přijde A záznam mířící do privátního prostoru, který bude dávat smysl, bude jistě daleko méně, než případů, kdy půjde o nějakou chybu.

Nicméně použití vhodného IP rozsahu mimo vyhrazené prefixy RFC 1918 tento problém efektivně eliminuje a mělo by být tím správným řešením pro CDN server před CGN.

[Filip Jirsák]

O prkotinu jde v každém případě. Jen si stojím za tím, že filtrování privátních adres přijatých v DNS odpovědích z veřejného internetu je správné výchozí nastavení. Lidé, kteří vědí, že takové privátní adresy jsou v síti jejich ISP používány by měli nastavení upravit, ne naopak. Protože těch případů, kdy z internetu přijde A záznam mířící do privátního prostoru, který bude dávat smysl, bude jistě daleko méně, než případů, kdy půjde o nějakou chybu.

Nejde přece o IP adresy v síti ISP, ale o IP adresy v lokální síti uživatele (nebo v síti, kam má přístup – třeba přes VPN). Podle mne je to špatné výchozí nastavení, protože třeba ty VPN jsou případ, kdy se může připojovat úplný laik, který neví vůbec nic o tom, že by si v DNS resolveru na svém routeru měl vypínat nějaké divné výchozí nastavení. Pak to akorát vede k tomu, že správce takové VPN bude klientům nutit u svůj DNS resolver. A nedej bože, aby se uživatel připojoval do více VPN současně.

Ono ale bude mnohem jednodušší, než dotyčnému vysvětlovat, kde tenhle filtr vypne, poradit mu, jak si DNS resolver nastaví na čtyři jedničky, osmičky nebo devítky, čímž bude uživatel definitivně ochráněn od všech škodlivých odpovědí jeho lokálního DNS resolveru.

Kdyby to filtrování aspoň mělo nějaký význam… Ale ten vektor útoku, že se nastaví A záznam ale nešlo by to samé udělat CNAME záznamem; zařízení, na které se útočí, je zabezpečené právě tak divně, že pro konfiguraci není potřeba přihlášení ale je potřeba CSRF token – to je tak prapodivná kombinace, a místo odstranění bezpečnostní díry to „řešit“ tak, že se odfiltrují některé DNS odpovědi…

Nicméně použití vhodného IP rozsahu mimo vyhrazené prefixy RFC 1918 tento problém efektivně eliminuje a mělo by být tím správným řešením pro CDN server před CGN.

Problém to eliminuje do té doby, než si někdo všimne, že děravé ADSL modemy mají IP z rozsahů mimo vyhrazené prefixy RFC 1918 a začne v DNS odpovědích filtrovat ty další rozsahy.

[Vilith]

Pokud se pripojuji do VPN, tak pouzivam i prideleny DNS resolver z VPN
Pokud ne, tak je bud bordel v nastaveni VPN spojeni nebo mnou rozhazena konfigurace

Privatni IP adresy do verejneho internetu nepatri