Polofunkční zvláštní druh DNS cenzury

[mikesznovu]

Narazil jsem na jedné korporátní síti na zvláštní druh cenzury. Chtěl bych rozluštit, jak to asi funguje, protože v něčem připomíná DNS blokování a zároveň fakticky není.

Za předpokladu, že se použije defaultní DHCP=jejich DNS (nějaké 160.xxx, ale netvrdím s jistotou), tak klasicky při pokusu otevřít stránku se klasicky ukáže  stránka s <title> o2 clean filter</title> a obsahem ikonky zákaz stání, Category:{porn,fake-ňůs,warez, atd například.} ...  Nezáleží na HTTPSvsHTTP (v praxi ano, mám https everywhere, hlásí to chybu certifikátu obvious,ale to je jen informační intermežo) Nuda s těmito informacemi dosud

1. Zvláštnost: Při použití jiného DNS (šifrovaného) (ale možná i klidně klasického na portu 53 ale na jiné adrese , netestováno!, proč mít palác na magistrále, když ho můžu mít rovnou na soukromém ostrově) stránky fungují a to v  i v HTTPvariantě. "Jeví se to jako DNS filtrování."

2. zvláštnost : Přesto ale  i defaultní DNS server vrátí pravou IP :  Separátní příkaz dig z terminálu - IP odpovídá skutečné. ... "To přeci nemůže být DNS filtrování"
(Hodně krajní věc co se mohla stát, že to při první resolvingu vrátilo podvrženou IP, ale pak už ne, ale to se mi zdá nesmysl)

Takže vlastnosti cenzury jsou:
-funguje i na https
-je polofunkční(s jiným DNS je eliminovaná)
* Nebýt právě toho faktu, že DNS vrací originální IP, by to byla klasika, nuda.

Čím myslíte že to je ?
Je tam nějaký stavový registr, který nějak si poznamenává položené DNS dotazy a z nich teprv dělá cenzuru, takže, co nezaregistruje, ho  nezajímá? + nějaká další logika ... Zřejmě pro nějaké ušetření zátěže(nebude dělat inspekci pro každé IP(:port)/tcp-spojení), ale jen o těch, o kterých ví, že se na ně user ptal přes DNS
Nebo třeba varianta, že nějaký vnitřní "démon" se v reálném čase zkusí nejdřív sám zkusí
Může tam být i nějaké porovnávání certifikátů?

Podle mě (tedy oCamurovy bŘit'vy) je nejjednoduší vysvětlení to správné . Není potřeba tam nějak míchat SNI inspekci, kontrolu (ze serveru)hlaviček TLS, napojení se nejdřív na vlastní pěst. Tedy pokud tam na začátku nemam chybu v úvaze

Pokud by tam bylo nějaké SNISNIfování, pak by mi šifrované DNS nepomohlo z čehož usuzuji že tam není.

[Reklama]

[Karmelos]

No hlavně tam pravděpodobně někde je ind co si zapisuje do notýsku pokusy zobrazit korporátně nehodný obsah a při překročení tresholdu obratem informuje lokálního it admina potažmo přímo vašeho nadřízeného.
Neradno dráždit korporátní kobru bosou nohou...
Toto z vlastní zkušenosti....

[vcunat]

To co projde přefiltrovaným DNS je na firewallu allow-listnuto, ideálně dočasně na dobu TTL příslušného záznamu + rezerva.  O takovém přístupu jsem rozhodně už slyšel.  A asi i zahlédl nějaké "skripty", možná https://openwrt.org/docs/guide-user/firewall/fw3_configurations/dns_ipset

Ta polofunkčnost v tomto případě může být chyba v jejich implementaci... nebo to dělají úplně jinak, anebo třeba v důsledku sdílení IP adres mezi různými doménami (velmi časté dnes).

[mikesznovu]

V tvé řeči ale , to co projde DNS, je blocklistnuto, protože pokud to neprojde DNSem, tak s tím není *listnuto nijak

Ale to je free wifina v obchoďáku.... A i kdyby, jak  pozná mého nadřízeného, když používám randomizaci MAC adres  8-D

[Karmelos]

V tvé řeči ale , to co projde DNS, je blocklistnuto, protože pokud to neprojde DNSem, tak s tím není *listnuto nijak

Ale to je free wifina v obchoďáku.... A i kdyby, jak  pozná mého nadřízeného, když používám randomizaci MAC adres  8-D

[Reklama]

[nocturne.op.15]

A i kdyby, jak  pozná mého nadřízeného, když používám randomizaci MAC adres  8-D

třeba auditem oveřovacích logů na AD serverech. Tak to používá třeba Fortinet a funguje to celkem slušně. Na MAC/IP adresy už dneska každý dlabe.

[monkey.d.luffy]

Nepíšete, jak jste digem získal adresu od firemního resolveru, tak tipuji, že jste na příkazové řádce neuvedl adresu nameserveru (@nameserver.example.cz) a ve skutečnosti tedy provedl úplný resolving od DNS rootu a místní dns server obešel. Takže mi to spíš vychází na obyčejné podvržení odpovědí z nameserveru, třeba přes RPZ.

[Zopper]

@monkey.d.luffy: Co si pamatuji (a v případě Macu jsem si to hned i ověřil), tak dig bez explicitního nameserveru použije systémové nastavení a ten lokální server je vidět v odpovědi jako zdroj.