Fórum Root.cz

Hlavní témata => Sítě => Téma založeno: Stilett 13. 06. 2018, 14:38:18

Název: HTTPS na privátní adrese
Přispěvatel: Stilett 13. 06. 2018, 14:38:18
Narazil jsem na jeden problém. Jak spolehlivě provozovat HTTPS na privátní IP adrese?

Situace: V síti některých poskytovatelů máme umístěný server, který posílá data uživatelům z dotyčné sítě, a tento server z důvodu omezení zátěže NATu vystupuje na privátní adrese (obvykle 10.x.y.z). Když detekuji, že uživatel přichází z dotyčné sítě, pošlu ho na privátní adresu serveru v té síti.

Zároveň chci použít HTTPS s důvěryhodným certifikátem. Přiřadil jsem tedy serveru doménové jméno z naší subdomény směřující na privátní adresu a získal důvěryhodný certifikát (přes DNS validaci).

Všechno to funguje. Až na to, že se ukázalo, že existuje jisté malé procento uživatelů, kteří mají doma router, který blokuje DNS překlad jmen na privátní adresy. Jedná se obvykle o zařízení s OpenWRT s dnsmasq, které má zapnutou volbu stop-dns-rebind. Tato volba blokuje překlady doménových jmen na privátní IP adresy, které přicházejí z upstream nameserverů (tedy nejsou lokálně nakonfigurované v dnsmasq). Pokud tedy popis volby správně chápu. Což je pro mé použití docela problém.

Smysl má být udajně ochrana před útokem DNS rebinding, ale blokuje to poněkud více věcí. Prý existuje RFC, které tvrdí, že takovéto směrování domén na privátní adresy se nemá dělat. Ale vždyť např. BIND má podporu split-horizon (split-view) DNS, který se používá částo právě pro přiřazování privátních IP adres, když přichází dotaz z privátní sítě.

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.
Název: Re:HTTPS na privátní adrese
Přispěvatel: n 13. 06. 2018, 15:14:39
A kdyz detekujes ze to nefunguje, tak udelej dalsi fallback na neco s verejnou adresou. Vykon bude sice suboptimalni, ale sluzba bude dorucena. Pokud tedy to "jiste male procento" neni veskutecnosti dost velke na to, aby si zaslouzilo vetsi mentalni investici do vyzkumu jak to resit jinak/lepe.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 13. 06. 2018, 15:22:18
Ano, IP adresy z privátních rozsahů by se ve veřejném DNS neměly objevovat, tvrdí RFC. Správné řešení je používat IPv6, kde je dost veřejných IP adres. Ostatní řešení jsou špatná – a z těch špatných je to nejméně špatné používat veřejné domény směřující na privátní IPv4 adresy.

Je to tedy pitomé chování toho routeru a řešením je uživatelům to vysvětlit a přesvědčit je, aby si ten router přenastavili (uživatelé OpenWRT to snad budou umět). Když nás takových bude víc, třeba autoři OpenWRT pochopí, že není ani rok 1998 ani 2038 a že je potřeba se s veřejnými doménami směřujícími na privátní IPv4 adresy smířit.

Další možnosti jsou používat vlastní certifikační autoritu nebo self-signed certifikáty, nebo HTTPS nepoužívat vůbec – všechno nesrovnatelně horší možnosti oproti privátním IPv4 adresám ve veřejném DNS, které jsou pouze kosmetickým problémem (DNS rebind je pouze zástěrka – pokud nějaký server zveřejňuje něco, co veřejné být nemá, je to bezpečnostní problém bez ohledu na to, jestli ten server má nebo nemá jméno).
Název: Re:HTTPS na privátní adrese
Přispěvatel: Miroslav Šilhavý 13. 06. 2018, 15:46:00
Když nás takových bude víc, třeba autoři OpenWRT pochopí, že není ani rok 1998 ani 2038 a že je potřeba se s veřejnými doménami směřujícími na privátní IPv4 adresy smířit.

To podle mě není dobré řešení. Přebíjet DNS odpovědi je "nebezpečné" - ve smyslu hledání problémů. Na takové řešení si po roce už nikdo nevzpomene a pak se obvykle v síti honí duchy.

Daleko lepší je dotaz na routeru, i za cenu více router-cyklů přechroustat SNATEM i DNATEM - tedy cíl přepsat DNATEM z veřejné IP adresy na privádní, a zdrojovou (aby se navrátila odpvěď) přepsat SNATEM naopak na veřejnou IP adresu routeru.

Pokud tedy máme:
10.0.0.45 (klient PC)
10.0.0.10 (server v privátním rozsahu)
10.0.0.1 (privátní IP routeru)
184.47.23.3 (veřejná IP routeru a zároveň veřejná IP serveru (NAT))


Takže z požadavku:
10.0.0.45 (klient) => 184.47.23.3 (server)
se v prvním kroku provede DNAT:
10.0.0.45 (klient) => 10.0.0.10 (server - privátní)
a v druhém kroku (kvůli zpětné cestě přes router, kvůli RP filtru)
10.0.0.1 (router-privátní) => 10.0.0.10 (server - privátní)

Takže požadavek bude:
10.0.0.45 => 184.47.23.3(<=DNAT+SNAT=>)10.0.0.1 => 10.0.0.10
a odpověď bude:
10.0.0.10 => 10.0.0.1 => 10.0.0.45

Název: Re:HTTPS na privátní adrese
Přispěvatel: MP 13. 06. 2018, 15:59:52
Když nás takových bude víc, třeba autoři OpenWRT pochopí, že není ani rok 1998 ani 2038 a že je potřeba se s veřejnými doménami směřujícími na privátní IPv4 adresy smířit.

To podle mě není dobré řešení. Přebíjet DNS odpovědi je "nebezpečné" - ve smyslu hledání problémů. Na takové řešení si po roce už nikdo nevzpomene a pak se obvykle v síti honí duchy.

Daleko lepší je dotaz na routeru, i za cenu více router-cyklů přechroustat SNATEM i DNATEM - tedy cíl přepsat DNATEM z veřejné IP adresy na privádní, a zdrojovou (aby se navrátila odpvěď) přepsat SNATEM naopak na veřejnou IP adresu routeru.

Pokud tedy máme:
10.0.0.45 (klient PC)
10.0.0.10 (server v privátním rozsahu)
10.0.0.1 (privátní IP routeru)
184.47.23.3 (veřejná IP routeru a zároveň veřejná IP serveru (NAT))


Takže z požadavku:
10.0.0.45 (klient) => 184.47.23.3 (server)
se v prvním kroku provede DNAT:
10.0.0.45 (klient) => 10.0.0.10 (server - privátní)
a v druhém kroku (kvůli zpětné cestě přes router, kvůli RP filtru)
10.0.0.1 (router-privátní) => 10.0.0.10 (server - privátní)

Takže požadavek bude:
10.0.0.45 => 184.47.23.3(<=DNAT+SNAT=>)10.0.0.1 => 10.0.0.10
a odpověď bude:
10.0.0.10 => 10.0.0.1 => 10.0.0.45

To reknete tem poskytovatelum, u kterych je ten "privatni" server umisten?
Název: Re:HTTPS na privátní adrese
Přispěvatel: Miroslav Šilhavý 13. 06. 2018, 16:04:40
To reknete tem poskytovatelum, u kterych je ten "privatni" server umisten?

Ano, asi by jim to mělo být řečeno :), protože server, který je z vnitřní sítě nedostupný, ač má být dostupný veřejně, je zjevná chyba.

S touto situací jsem se setkal jen v rámci jedné firmy, jedné přípojky, kdy zákazník má server ve vnitřní síti, a zvenčí je NAT a zevnitř je problém se na něj dostat (právě kvůli resolvování DNS na veřejnou IP adresu). U ISP, doufám, toto nenastává. Na hostingu je pořád standard veřejná IP adresa, pro tyto účely je jich pořád dostatek.
Název: Re:HTTPS na privátní adrese
Přispěvatel: samalama 13. 06. 2018, 16:08:27
Když nás takových bude víc, třeba autoři OpenWRT pochopí, že není ani rok 1998 ani 2038 a že je potřeba se s veřejnými doménami směřujícími na privátní IPv4 adresy smířit.

To podle mě není dobré řešení. Přebíjet DNS odpovědi je "nebezpečné" - ve smyslu hledání problémů. Na takové řešení si po roce už nikdo nevzpomene a pak se obvykle v síti honí duchy.

Daleko lepší je dotaz na routeru, i za cenu více router-cyklů přechroustat SNATEM i DNATEM - tedy cíl přepsat DNATEM z veřejné IP adresy na privádní, a zdrojovou (aby se navrátila odpvěď) přepsat SNATEM naopak na veřejnou IP adresu routeru.

Pokud tedy máme:
10.0.0.45 (klient PC)
10.0.0.10 (server v privátním rozsahu)
10.0.0.1 (privátní IP routeru)
184.47.23.3 (veřejná IP routeru a zároveň veřejná IP serveru (NAT))


Takže z požadavku:
10.0.0.45 (klient) => 184.47.23.3 (server)
se v prvním kroku provede DNAT:
10.0.0.45 (klient) => 10.0.0.10 (server - privátní)
a v druhém kroku (kvůli zpětné cestě přes router, kvůli RP filtru)
10.0.0.1 (router-privátní) => 10.0.0.10 (server - privátní)

Takže požadavek bude:
10.0.0.45 => 184.47.23.3(<=DNAT+SNAT=>)10.0.0.1 => 10.0.0.10
a odpověď bude:
10.0.0.10 => 10.0.0.1 => 10.0.0.45

co samozrejme nebude fungovat, pretoze klientovi v tomto pripade pride odpoved z 10.0.0.1 a nie z 184.47.23.3...
Název: Re:HTTPS na privátní adrese
Přispěvatel: Miroslav Šilhavý 13. 06. 2018, 16:10:17
co samozrejme nebude fungovat, pretoze klientovi v tomto pripade pride odpoved z 10.0.0.1 a nie z 184.47.23.3...

Cestou zpět se uplatní zase, takže jsem to měl napsat spíš jako:

10.0.0.10 => 10.0.0.1/184.47.23.3 => 10.0.0.45
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 13. 06. 2018, 16:18:42
To podle mě není dobré řešení. Přebíjet DNS odpovědi je "nebezpečné"
Vaše řešení asi dobré nebude. V mém řešení se ale žádné přebíjení DNS odpovědí nevyskytuje.

Daleko lepší je dotaz na routeru, i za cenu více router-cyklů přechroustat SNATEM i DNATEM
To, že se musí vedle DNATu udělat ještě SNAT, je na tom celém to nejmenší. Podstatné je to, že tu komunikaci nuceně ženete přes router, přestože by mohla jít přímo. Když budete chtít mezi klientem a serverem přenášet větší objem dat, je dost podstatný rozdíl, zda budete ze serveru na klienta přímo přes switch stahovat třeba 800 Mbit/s, nebo jestli to poženete přes router, který tím pádem bude potřebovat odbavit 1,6 Gbit/s a ještě to bude prohánět NATem.

Vzhledem k tomu, že Stillet píše o omezení zátěže NATu, je ta vaše rada přesně to, čemu se chce vyhnout.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Miroslav Šilhavý 13. 06. 2018, 16:20:06
To, že se musí vedle DNATu udělat ještě SNAT, je na tom celém to nejmenší. Podstatné je to, že tu komunikaci nuceně ženete přes router, přestože by mohla jít přímo. Když budete chtít mezi klientem a serverem přenášet větší objem dat, je dost podstatný rozdíl, zda budete ze serveru na klienta přímo přes switch stahovat třeba 800 Mbit/s, nebo jestli to poženete přes router, který tím pádem bude potřebovat odbavit 1,6 Gbit/s a ještě to bude prohánět NATem.

Vzhledem k tomu, že Stillet píše o omezení zátěže NATu, je ta vaše rada přesně to, čemu se chce vyhnout.

Souhlasím, ale považuji to za menší zlo než jiná řešení.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Vilith 13. 06. 2018, 16:37:53
Nejsnazsi se domluvit s temi sitemi a pouzivat verejnou IP z jejich rozsahu.
A nemusite se drbat levou rukou za pravym uchem.

Ale asi bude problem v tom, ze to je neco, o cem ti spravcove siti nevedi...
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 13. 06. 2018, 16:56:37
Nejsnazsi se domluvit s temi sitemi a pouzivat verejnou IP z jejich rozsahu.
Když se chce Stilett vyhnout NATu, není asi moc dobrá rada napsat (a ještě ne otevřeně)  „nejsnazší je použít NAT“. Může to tak být, ale pak je asi potřeba napsat „to, co chcete dělat, není z toho a toho důvodu dobrý nápad“.

Navíc úplně stejný problém nastává i tam, kde žádná veřejná IPv4 adresa není – kde je server v lokální síti, který z venku nemá být dostupný a žádnou nadbytečnou veřejnou IPv4 adresu, kterou byste na něj dal, nemáte. Představte si třeba školní síť se serverem, a od ISP dostane ta škola v lepším případě jednu dynamickou veřejnou IPv4 adresu pro vnější rozhraní routeru, v horším případě se bude dělat NAT až u ISP.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Miroslav Šilhavý 13. 06. 2018, 17:00:46
Navíc úplně stejný problém nastává i tam, kde žádná veřejná IPv4 adresa není – kde je server v lokální síti, který z venku nemá být dostupný a žádnou nadbytečnou veřejnou IPv4 adresu, kterou byste na něj dal, nemáte. Představte si třeba školní síť se serverem, a od ISP dostane ta škola v lepším případě jednu dynamickou veřejnou IPv4 adresu pro vnější rozhraní routeru, v horším případě se bude dělat NAT až u ISP.

Ano, ale "uzváldat" SNAT+DNAT na routeru, např. ve školní síti, není zas až tak nepřekonatelný problém. Podle mě bude existovat jen málo skutečných situací, kdy nemáte možnost mít veřejnou IP adresu a zároveň nemáte ani možnost "ustíhat" NAT. Když si představím hraniční router takové sítě, podle mě na conntracku NATU má takové množství spojení, že ještě nějaká navíc zpět do vlastní sítě už nemohou hrát tak velkou roli. To řešení má velkou výhodu v tom, že je pro síťaře dobře čitelné a chová se vypočitatelně. Ale jak píšete, za cenu ztraceného výkonu na routeru.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 13. 06. 2018, 17:15:22
Ano, ale "uzváldat" SNAT+DNAT na routeru, např. ve školní síti, není zas až tak nepřekonatelný problém. Podle mě bude existovat jen málo skutečných situací, kdy nemáte možnost mít veřejnou IP adresu a zároveň nemáte ani možnost "ustíhat" NAT. Když si představím hraniční router takové sítě, podle mě na conntracku NATU má takové množství spojení, že ještě nějaká navíc zpět do vlastní sítě už nemohou hrát tak velkou roli. To řešení má velkou výhodu v tom, že je pro síťaře dobře čitelné a chová se vypočitatelně. Ale jak píšete, za cenu ztraceného výkonu na routeru.
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.

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.

Ž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ší…
Název: Re:HTTPS na privátní adrese
Přispěvatel: Vilith 13. 06. 2018, 17:23:50
Zajimave, ze vsichni velci ISP to maji vyresene a radi urcite poradi s timto problemem (kazdy muze navrhnout jine reseni specificke pro jeho sit). V privatnich sitich v tom take neni problem, tam mate centralni spravu a vnutite klientum selfsigned certifikat a interni DNS
Cele to je o tom, ze se tady nejspis snazi nekdo s necim "vydrbat"...
Název: Re:HTTPS na privátní adrese
Přispěvatel: Miroslav Šilhavý 13. 06. 2018, 17:24:25
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ď.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Stilett 13. 06. 2018, 17:31:30
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.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 13. 06. 2018, 17:40:20
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.
Název: Re:HTTPS na privátní adrese
Přispěvatel: V. 13. 06. 2018, 17:54:55
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.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Ondřej Caletka 14. 06. 2018, 10:25:59
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 (https://tools.ietf.org/html/rfc6598) 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 (http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/rfc1035.c;h=29e9e65061f8b48b215b707fd3f61f32fefc7672;hb=29e9e65061f8b48b215b707fd3f61f32fefc7672#l726). 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.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 14. 06. 2018, 12:36:07
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.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Ondřej Caletka 14. 06. 2018, 12:51:06
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.

Název: Re:HTTPS na privátní adrese
Přispěvatel: Vilith 14. 06. 2018, 13:16:54
S Jirsakem se nediskutuje: https://youtu.be/XDJEPjvbbs4
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 14. 06. 2018, 13:47:57
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.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Vilith 14. 06. 2018, 13:50:48
Privatni IP adresy do verejneho DNS proste NEPATRI

At si preferuje tenhle BORDEL kdo chce, ale kdo to blokuje, ten jen dela dobre
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 14. 06. 2018, 14:02:01
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.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Vilith 14. 06. 2018, 14:15:45
https://youtu.be/XDJEPjvbbs4
Název: Re:HTTPS na privátní adrese
Přispěvatel: Ondřej Caletka 14. 06. 2018, 15:29:27
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.

Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 14. 06. 2018, 16:16:51
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.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Vilith 14. 06. 2018, 16:24:50
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
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 14. 06. 2018, 17:06:30
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
Vždyť jsem to psal – radši než povolit privátní IP adresy na DNS resolveru, unesete všechny DNS dotazy. Chcete zabránit kosmetickému problému, tak radši vyrobíte problém skutečný. Výborné bude, když se bude o DNS resolver přetahovat několik VPN. Nebo když vám CDN přes to VPNkové DNS naservíruje obsah poblíž vyústění té VPN, ke kterému se budete dostávat nejlépe přes tranzit, zatímco dotyčná CDN má server i u vašeho ISP. Samá pozitiva a sociální jistoty.

Privatni IP adresy do verejneho internetu nepatri
Také je tam nikdo necpe.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Ondřej Caletka 14. 06. 2018, 17:20:39
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ě.
Tak dobře, řekněme že má dvě VPN současně – a chce se připojit na webmail.intranet.firma1.cz a zároveň webmail.intranet.firma2.cz. Obě doménová jména budou dostupná ve veřejném internetu a budou se překládat na privátní adresu 192.168.1.1. A jsme v koncích, stejně se k jedné ze dvou služeb nedostaneme.

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.
Máte ověřeno, že tyhle služby privátní adresy v DNS odpovědích nefiltrují?
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 14. 06. 2018, 17:36:51
Tak dobře, řekněme že má dvě VPN současně – a chce se připojit na webmail.intranet.firma1.cz a zároveň webmail.intranet.firma2.cz. Obě doménová jména budou dostupná ve veřejném internetu a budou se překládat na privátní adresu 192.168.1.1. A jsme v koncích, stejně se k jedné ze dvou služeb nedostaneme.
Což není problém DNS, ale konfliktu používaných rozsahů privátních adres. Že takový konflikt může nastat neznamená, že musím preventivně rozbít i DNS.

Máte ověřeno, že tyhle služby privátní adresy v DNS odpovědích nefiltrují?
Jistě. Zkoušel jsem tedy jen IP adresy z 10.0.0.0/8 a 172.16.0.0/12, protože rozsah 192.168.0.0/16 nikde nepoužívám, ale nepředpokládám, že u něj by to bylo jinak.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Vilith 14. 06. 2018, 17:43:29
Patri k best practices, ze z VPNky nemam primy pristup na Internet, pouze do inside/interni DMZ kde je VPNka zakoncena...
Název: Re:HTTPS na privátní adrese
Přispěvatel: Filip Jirsák 14. 06. 2018, 18:11:33
Patri k best practices, ze z VPNky nemam primy pristup na Internet, pouze do inside/interni DMZ kde je VPNka zakoncena...
Což je mimoběžné s naší debatou, protože já píšu o případu, kdy do VPN směřuje jen provoz, který tam jít musí, a internet je z klienta normálně dostupný přímo. Protože když VPN používám jenom jako způsob, jak obejít nedostatek veřejných IP adres, není důvod cpát do VPN veškerý provoz.

Každopádně k best practices patří nerozbíjet něco, co rozbité být nemusí. Takže není potřeba vyjmenovávat případy, kdy rozbité DNS nevadí, když pořád existují případy, kdy rozbité DNS vadí. A bude jich čím dál víc, protože DNSSEC a HTTPS tlačí na rušení různých lokálních domén a používání jen veřejného DNS stromu, zároveň HTTPS tlačí na používání DNS místo IP adres. A kvůli nedostatku IPv4 adres nejspíš bude narůstat používání VPN, takže problémy s různými DNS resolvery poskytujícími jiná data, než jsou ve veřejném DNS, budou narůstat.
Název: Re:HTTPS na privátní adrese
Přispěvatel: Vilith 14. 06. 2018, 18:13:06
Ty musis mit vzdycky pravdu a posledni slovo...
Název: Re:HTTPS na privátní adrese
Přispěvatel: Pkl 14. 06. 2018, 18:51:38
Jo a firewally nechme v defaultu na accept, protoze jinak to bude rozbite..
Název: Re:HTTPS na privátní adrese
Přispěvatel: Stilett 15. 06. 2018, 12:52:45
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.
Konflikt u privátních IP adres může nastat nezávisle na DNS. Stejně tak problém s routovatelností. Když v URL pro HTTP použiji přímo IP adresu, tak vynechám DNS a problém je pořád stejný. Ten router by DNS překlad na 10.x.y.z blokl i kdybych zařídil, že to DNS bude dostupné jen v té síti 10.0.0.0/8. Ano, je to tím, že na jeho WAN rozhraní je privátní síť. Není to ideální, ale na IPv4 to už lepší asi nebude. Nehledě na to, že použití neveřejného DNS zase způsobí problémy uživatelům, kteří si nastavili DNS server na 8.8.8.8 apod.

Použijte tedy adresu z vyhrazeného prefixu pro CGN (https://tools.ietf.org/html/rfc6598) 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 (http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/rfc1035.c;h=29e9e65061f8b48b215b707fd3f61f32fefc7672;hb=29e9e65061f8b48b215b707fd3f61f32fefc7672#l726). 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.
Děkuji za tento nápad.  O tomto rozsahu jsem nevěděl. Pokud mi ho budou schopni naroutovat, tak by vyřešilo problém bez nevýhod ostatních řešení.