Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: Vietnanka 22. 05. 2021, 15:26:14
-
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.
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
-
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
-
Kodovanim male/velka pismena se pouziva DNS system pro odesilani vysosanych informaci - napr. hesel ci klicu.
-
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.
-
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.
-
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.
-
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.
-
... 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.