SNI a blokace IP/DNS

[dotk]

zajímá mě, zda je možné někde najít:

-které IP patří kolik domén
-může mít jedna doména víc IP??

Použití: chci blokovat  určitou doménu. Existuje nějaké řešení, kam stačí zadat název, a ono to pak nějak automaticky zjistí IP ablokuje? Nebo musím zjistit IP?

Zároveň jde filtrovat HTTPS traffic pro konkrétní doménu (z externího, jak odborníci říkají "předsunutého" nebo představeného nebo předzasutého nebo předpojatého nebo předřazeného firewallu- tedy např z routeru a nebo host computeru, pokud requesty jdou z virtuálky)?

[Reklama]

[MP]

zajímá mě, zda je možné někde najít:
-které IP patří kolik domén
-může mít jedna doména víc IP??
Použití: chci blokovat  určitou doménu. Existuje nějaké řešení, kam stačí zadat název, a ono to pak nějak automaticky zjistí IP ablokuje? Nebo musím zjistit IP?
Zároveň jde filtrovat HTTPS traffic pro konkrétní doménu (z externího, jak odborníci říkají "předsunutého" nebo představeného nebo předzasutého nebo předpojatého nebo předřazeného firewallu- tedy např z routeru a nebo host computeru, pokud requesty jdou z virtuálky)?

IP a pocet domen - nelze
jedna domena vice ip - lze

reseni - firewall s podporou fqdn, nebo proxy

[Miroslav Šilhavý]

Zjistit domény na IP nelze.
Zjistit IP pro doménu lze jednoduše - nicméně se to může v čase měnit.

Neznám firewall, který by fungoval na FQDN, všechny vyhodnotí DNS dotaz při startu a dál už blokují IP adresy, které resolvoval při startu.

Filtrovat HTTPS lze jedině tak, že v cestě bude (transparentní) proxy, ale jedině za cenu výměny certifikátu. Tj. jeden certifikát bude mezi proxy a cílovým serverm, druhý certifikát bude mezi proxy a PC s prohlížečem. V praxi to nefunguje dobře, protože aplikace kontrolují nejenom důvěryhodnost certifikátu, ale i to, jestli je použitý ten správný. Weby, které budou mít zapnuté HPKP (key-pinning) nebudou fungovat vůbec, protože to prohlížeč pozná.

Blokovat na DNS lze, ale musíte dobře rozvážit jak a co budete dělat. V DNS se nenacházejí pro doménu jen A, AAAA a CNAME záznamy důležité ponejvíc pro web, ale i další záznamy, které se čím dál častěji uplatňují. Když na Vašem DNS vyblokujete celou doménu, způsobíte si tím jiné problémy.

Jako fuj, ale nejspolehlivější řešení, které jsem zatím viděl je, zakázat uživatelům instalaci software, "přidělit" jim prohlížeče vlastní volby, a do nich instalovat speciální pluginy. Ty pak filtrují provoz, některé se dají centrálně spravovat.

Asi to není odpověď, kterou jste chtěl slyšet?

[Filip Jirsák]

Zároveň jde filtrovat HTTPS traffic pro konkrétní doménu (z externího, jak odborníci říkají "předsunutého" nebo představeného nebo předzasutého nebo předpojatého nebo předřazeného firewallu- tedy např z routeru a nebo host computeru, pokud requesty jdou z virtuálky)?

Na ostatní věci už tu jsou správné odpovědi, přidám ještě odpověď na toto. Hostname se přenáší v nešifrované části HTTPS spojení, takže na jeho základě je možné HTTPS spojení s určitou doménou zablokovat. Není to ale povinnou součástí HTTPS, je to rozšíření nazývané SNI, které je relativně nové. Všechny běžně používané prohlížeče už to podporují, ale nevím, jaká je podpora na straně různých firewallových řešení (aby tu doménu uměla v komunikaci najít).

Takže záleží na tom, k čemu tu blokaci chcete použít. Pokud chcete zamezit komunikaci běžných webových prohlížečů nebo klienta, o kterém víte, že SNI používá, můžete to použít. Ale musíte počítat s tím, že to není 100% řešení a pokud někdo může komunikaci ovlivnit, nemusí to rozšíření použít a pak přes firewall projde.

[MP]

Neznám firewall, který by fungoval na FQDN, všechny vyhodnotí DNS dotaz při startu a dál už blokují IP adresy, které resolvoval při startu.

Filtrovat HTTPS lze jedině tak, že v cestě bude (transparentní) proxy, ale jedině za cenu výměny certifikátu. Tj. jeden certifikát bude mezi proxy a cílovým serverm, druhý certifikát bude mezi proxy a PC s prohlížečem. V praxi to nefunguje dobře, protože aplikace kontrolují nejenom důvěryhodnost certifikátu, ale i to, jestli je použitý ten správný. Weby, které budou mít zapnuté HPKP (key-pinning) nebudou fungovat vůbec, protože to prohlížeč pozná.

Pokud tim startem je mysleno navazani noveho spojeni pri pruchodu firewallem, tak asi mate pravdu, ze po dobu tohoto konkretniho spojeni to jinou IP nevezme bez odpovidajicich redirectu ze strany externi sluzby. Ale firewally prekladajici fqdn pravidla na IP pri navazovani spojeni normalne existuji (ale neresi samotne SNI).

Co se tyce proxy, transparentni proxy neni treba, staci proste zablokovat pristup na webove protokoly atd na firewallu a vse to tahat pres samostatnou proxy, na ktere se cachry s certifikaty delat nemusi, opet staci pravidla na domeny podobne jako u firewallu.

Pokud nekdo resi pripad jine domeny ve SNI a jine v pri navazovani spojeni, tak to je uz jina liga.

[Reklama]

[j]

... chci blokovat  určitou doménu. Existuje nějaké řešení,...

No jiste ... napise se to do hosts ... a odkaze na localhost. Funguje to na kazdym aspon trochu pouzitelnym systemu zcela spolehlive.

A nemusis resit ty ptakoviny ktery ti tu radej kolem ...

Samo ti pak na tu domenu nebude fungovat nic, nejen http(s).

[Filip Jirsák]

No jiste ... napise se to do hosts

Nikoli, změna /etc/hosts na routeru opravdu překlad DNS názvů na ostatních zařízeních v síti nijak neovlivní.

[Miroslav Šilhavý]

Ale firewally prekladajici fqdn pravidla na IP pri navazovani spojeni normalne existuji (ale neresi samotne SNI).

Omlouvám se, ale nemáte pravdu. Pokud by firewall měl např. 100 pravidel zadaných přes FQDN, pak by musel při každém novém spojení všech 100 FQDN resolvovat, než by zjistil, jestli packet smí projít. To není reálné na L3 firewallu.

Co se tyce proxy, transparentni proxy neni treba, staci proste zablokovat pristup na webove protokoly atd na firewallu a vse to tahat pres samostatnou proxy, na ktere se cachry s certifikaty delat nemusi, opet staci pravidla na domeny podobne jako u firewallu.

Také nemáte pravdu. Proxy pro HTTPS nejde bez změny certifikátu. HTTPS je navržený právě od toho, aby v cestě nemohl nikdo stát a naslouchat, tedy ani proxy. Pokud je navíc na doméně HSTS, nepůjde to ani za cenu akceptování výměny certifikátu.

[Filip Jirsák]

Pokud by firewall měl např. 100 pravidel zadaných přes FQDN, pak by musel při každém novém spojení všech 100 FQDN resolvovat, než by zjistil, jestli packet smí projít. To není reálné na L3 firewallu.

I kdyby to firewall dělal (třeba pro jedno pravidlo a nízký počet navazovaných spojení), nikde není řečeno, že klient přeloží doménové jméno na stejné adresy, jako firewall. I kdyby byl spřažený firewall s resolvujícím DNS serverem, aby klient dostával stejné odpovědi, s jakou pracuje firewall, není zaručeno, že klient nebude mít jinou hodnotu v cache (a klidně to může být cache aplikace, na kterou síťový administrátor nijak nedosáhne).

Také nemáte pravdu. Proxy pro HTTPS nejde bez změny certifikátu. HTTPS je navržený právě od toho, aby v cestě nemohl nikdo stát a naslouchat, tedy ani proxy. Pokud je navíc na doméně HSTS, nepůjde to ani za cenu akceptování výměny certifikátu.

Při použití SNI rozšíření se doménové jméno přenáší nešifrované, takže ho proxy může vidět. Na zablokování komunikace to stačí, nic víc proxy vidět nepotřebuje.

[Miroslav Šilhavý]

Při použití SNI rozšíření se doménové jméno přenáší nešifrované, takže ho proxy může vidět. Na zablokování komunikace to stačí, nic víc proxy vidět nepotřebuje.

To bych nenazýval proxy, ale spíš jako L7 firewall, a to by samozřejmě šlo. Bude to pak fungovat pouze pro SNI, a pak byste se musel rozhodnout, co udělat s non-SNI HTTPS přenosy. Jestli je zablokovat, nebo propustit. L7 firewall má ještě jednu slabinu - ve výkonu. Není reálné ho pustit nad všemi porty, takže by buďto muselo být HTTPS předpokládáno na 443, nebo ostatní porty úplně zablokovat.

[M.]

Vedle SNI ohlášení, tak mohu zcela snadno filtrovat i dle předloženého certifikátu tím HTTPS serverem. Tohle umí třeba i squid, že v access pravidlech se odvolávám na položky certifikátu poslaného serverm a blokuji pak podle toho, co tam je. Toto jde dělat také, aniž musím se snažit vrtat dovnitř HTTPS spojení.

[Lol Phirae]

Místo řešení kokotin. Na routeru zprovozni DNS server, požadované blokované domény nastav na 127.0.0.1 nebo 0.0.0.0, odchozí DNS provoz přesměruj na DNS server na routeru a vyřízeno.

Ad proxy bez certifikátu, to je záležitostí asi 3 řádků ve squid.conf, např.

Kód: [Vybrat]

acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump splice all

a pak si to můžeš blokovat jak chceš.

[MP]

Ale firewally prekladajici fqdn pravidla na IP pri navazovani spojeni normalne existuji (ale neresi samotne SNI).

Omlouvám se, ale nemáte pravdu. Pokud by firewall měl např. 100 pravidel zadaných přes FQDN, pak by musel při každém novém spojení všech 100 FQDN resolvovat, než by zjistil, jestli packet smí projít. To není reálné na L3 firewallu.

A jak asi dneska FW funguji? Cpou si IP do ACL? Vazne? Tak to chci videt, jak si chcete nacpat do toho listu seznam siti pro FB (27! ipv4 subnetu), AWS atd. a hlavne, hlidat i modifikace.

[MP]

Pokud by firewall měl např. 100 pravidel zadaných přes FQDN, pak by musel při každém novém spojení všech 100 FQDN resolvovat, než by zjistil, jestli packet smí projít. To není reálné na L3 firewallu.

I kdyby to firewall dělal (třeba pro jedno pravidlo a nízký počet navazovaných spojení), nikde není řečeno, že klient přeloží doménové jméno na stejné adresy, jako firewall. I kdyby byl spřažený firewall s resolvujícím DNS serverem, aby klient dostával stejné odpovědi, s jakou pracuje firewall, není zaručeno, že klient nebude mít jinou hodnotu v cache (a klidně to může být cache aplikace, na kterou síťový administrátor nijak nedosáhne).

Jo, tohle je pravda. Napr. ASA pridava k DNS TTL +1 minuta, takze u siti, ktere toci IP ve velmi kratkych casech se to rozbiji, pokud pozadavek z klientadorazi az po te rotaci. Cache aplikace je druha vec...predpokladam, ze v dobe cloudovych sluzeb dost problemova.

[Filip Jirsák]

Cache aplikace je druha vec...predpokladam, ze v dobe cloudovych sluzeb dost problemova.

Neřekl bych. Třeba Google Chrome DNS odpovědi kešuje, a předpokládám, že zrovna Google ví docela dobře, jak by se měl webový prohlížeč chovat ke cloudovým službám.