Náhodná velikost písem v DNS logu

[Vietnamka]

Dobry den, netusite cim by mohlo byt ze se mi v logu zobrazuji tyto zaznamy? To divne je , ze maji nahodne prohozene velikosti pismen. Jak je videt nestava se to vzdy. Spis hodne zridka. A za druhe, u stejne domeny (zde hned prvni : code jquery.com) se to jindy ukazuje normalne,takze je to nahodne pro danou domenu a i v case.


Jde o log lokalniho dns serveru pri prohlizeni webu. Nektere radky mohou vypadat 'zdvojene' , ale to je tim, ze pokud pro nektery dns dotaz prijde CNAME, tak bud se do logu zapise i ta odkazovana domena podruhy . a mozna se emituje dalsi dns dotaz, to ale nevim.

Kód: [Vybrat]

code.jquery.com
cds.s5x3j6q5.hWCdN.net
cdn.jsdelivr.net
cdn.jsdelivr.net.cdn.cloudflare.net
codeorigin.jquery.com
www.reclaimtheblock.org
ext-cust.squarespace.com
assets.squarespace.com
static.squarespace.map.fastly.net
ipv4only.arpa
Ipv4ONLY.arpa
m.youtu.be
m.youtu.be.localdomain



Jo a bokem dalsi dotaz, proc tento Dns program vytvari (patrne na zacatku) dotazy typu www.t12345678.org, cisla se meni? (Samo sebou se neloguji v tomto pgramu) ale zachyti je nadrazeny dns.


Jde o personalDNSfilter

[Reklama]

[vcunat]

Může být řada důvodů, DNS je case-insensitive.  Taky existuje technika kdy se velikosti písmen berou doopravdy náhodně: https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00

[RDa]

Kodovanim male/velka pismena se pouziva DNS system pro odesilani vysosanych informaci - napr. hesel ci klicu.

[Filip Jirsák]

V DNS dotazu na velikosti písmen nezáleží. Čehož se někdy využívá a velikost písmen se nastavuje náhodně, aby dva dotazy na stejné doménové jméno nebyly stejné. Může to mít vliv třeba na šifrovanou komunikaci – když doménové jméno zapsané dvakrát stejně zašifrujete dvakrát stejným klíčem, dostanete stejný výstup. Nebo-li opačně, když někdo sleduje šifrovanou komunikaci, vnutí vám svůj DNS dotaz a pak v šifrovaném kanálu uvidí znova ta samá data, ví, kdy a na jaký DNS záznam jste se ptala. Když se ale náhodně změní velikost písmen, bude i v šifrovaném výstupu pokaždé něco úplně jiného, takže nikdo nepozná, že se ptáte na tu samou doménu.

[RDa]

V DNS dotazu na velikosti písmen nezáleží. Čehož se někdy využívá a velikost písmen se nastavuje náhodně, aby dva dotazy na stejné doménové jméno nebyly stejné. Může to mít vliv třeba na šifrovanou komunikaci – když doménové jméno zapsané dvakrát stejně zašifrujete dvakrát stejným klíčem, dostanete stejný výstup. Nebo-li opačně, když někdo sleduje šifrovanou komunikaci, vnutí vám svůj DNS dotaz a pak v šifrovaném kanálu uvidí znova ta samá data, ví, kdy a na jaký DNS záznam jste se ptala. Když se ale náhodně změní velikost písmen, bude i v šifrovaném výstupu pokaždé něco úplně jiného, takže nikdo nepozná, že se ptáte na tu samou doménu.

Pokud uz nekdo sifruje komunikaci, tak snad ne takto, bez IV a v ECB rezimu.

DNS ma snad jen DoT / DoH rezimy a ani jeden z nich zrejme neskonci produkovanim rovnakych dat na stejne dotazy.

[Reklama]

[Ondřej Caletka]

Ten hlavní důvod je přidání několika náhodných bitů (jeden bit na každé písmeno) k stávajícímu ID transakce (16 bitů) a číslu portu (~15 bitů). Dělá se to zejména proto, že dnešní sítě už jsou tak rychlé, že útočníci mohou stihnout vyzkoušet nasypat oběti všech ~32K kombinací ID transakce a čísla portu ještě před tím, než pravý server odpoví. Tím je možné otrávit cache resolveru, což může být poměrně nebezpečné.

Samozřejmě, je to pouze workaround. To správné řešení spočívá v používání DNSSEC. Ale k tomu je potřeba vůle na obou stranách.

[LeosB]

Ten hlavní důvod je přidání několika náhodných bitů (jeden bit na každé písmeno) k stávajícímu ID transakce (16 bitů) a číslu portu (~15 bitů). Dělá se to zejména proto, že dnešní sítě už jsou tak rychlé, že útočníci mohou stihnout vyzkoušet nasypat oběti všech ~32K kombinací ID transakce a čísla portu

Tohle nevychází, protože ~32K kombinací odpovídá 15 bitům, a přitom jich je k dispozici dalších 16 což je dohromady tak moc že to reálně nejde vyčerpat. Problém to byl když se používalo jen 16 bitů, to odhalil Dan Kaminsky a od té doby se přidává těch dalších ~15 bitů náhodnou volbou zdrojového portu.

[RDa]

... Tím je možné otrávit cache resolveru, což může být poměrně nebezpečné.

Nebezpecne to je snad jen u spatne napsaneho DNS serveru - i kdyz neznam detaily implementace, tak bych ocekaval maximalne tak DoS chovani - ze do request-response tabulky se jiz nevejdou nove prichozi dotazy, nez moznost podvrhnout falesna data.

Krome zdrojoveho portu prece musi byt soucasti klice i zdrojova adresa - a pokud je DNS traffic hrnut na jeden uzel, ktery to koncentruje skrz sebe, tak to holt neni chyba protokolu, ale realizace. Co brani velkym mezi-uzlum v pouzivani celeho C jako IP poolu, pro sve dotazovaci rozhrani? Kdyz chtej do vseho strkat nos, at ho maj alespon adekvatne dimenzovany.