Dotaz: Iptables a hex string

[Zdeněk Zámečník]

Dokázal by mi někdo poradit s následujícím problémem nebo spíše vysvětlit toto chování? Snažím se na routeru odchytávat nežádoucí DNS dotazy pomocí iptables. Dlouho jsem bojoval s modulem string, protože mi ignoroval řetezce obsahující tečku. Pak jsem našel něčí podobné řešení ze kterého jsem odvodil toto:

iptables -A FORWARD -p udp --dport 53 -m string --hex-string "zlaadresa|03|com" --algo bm -j DROP

Což funguje jak chci.

Nicméně není mi jasné, proč je tečka nahrazena |03|, protože v ascii tabulce jí odpovídá 0x2e. Pak jsem chtěl blokovat cz doménu a tam mi toto nefungovalo, po chvíli laborování jsem přišel na to že, funguje následující:

iptables -A FORWARD -p udp --dport 53 -m string --hex-string "zlaadresa|02|cz" --algo bm -j DROP

Dokáže mi někdo vysvětlit, proč to tak je? Jsem z toho zmatený a neumím si představit, jak bych řešil nějaká složitější pravidla. V manuálu iptables není o používání hex-stringu ani zmínka...

---

---

Odpovědi

[chrono]

Tie čísla sú vlastne dĺžka nasledujúcej časti toho názvu (com sú tri znaky a cz dva).

Aby si testoval naozaj to, čo testovať chceš, tak by si tam mal mať aj dĺžku tej, v tvojom prípade, prvej časti. Celé by to teda mohlo vyzerať nejako takto: |09|zlaadresa|02|cz|00|

[MMMMMMMMM]

spusť si Wireshark a sleduj dotazy, např. zlaadresa.c, zlaadresa.cz, zlaadresa.net, zlaadresa.info -> mění se podle délky stringu následujícího za tečkou, c->01, cz->02, net->03, info->04, zkus třeba i nejaka.zlaadresa.cz zajímavé

[chrono]

Zaujímavý bude aj tvar pre zlaadresa.zlaadresa.cz :) Popis toho, ako to funguje je napr. v RFC 1035 - 4.1.4. Message compression

[MMMMMMMMM]

ideální čtení přes spaním

[Zdeněk Zámečník]

Ta souvislost s délkou mi došla. Chytal jsem to tcpdumpem, vůbec mě nenapadlo, že wireshark mi napoví více. Ale vůbec mi nejde do hlavy proč se to jmenuje hex-string a ještě se v manu uvádí --hex-string pattern Matches the given pattern in hex notation. Když tam dám dám řetězec v jako hexa, tak to nevyhoví.

[Michal Kubeček]

Protože jako argument zadáváte řetězec, do kterého můžete vkládat hodnoty nezapsatelných bytů v šestnáctkové soustavě.

[Filip Jirsák]

Jak to že nevyhoví? Vždyť v dotazu sám píšete, porovnání s zlaadresa|03|com funguje. A v DNS paketu je přesně tenhle řetězec, tj. v C notaci zlaadresa\x03com.

Problém je už v té snaze DNS dotazy filtrovat pomocí shody s řetězcem. To nebude fungovat, DNS protokol nepřenáší doménové názvy jako jednoduchý text. Už jste narazil na první věc, že název se nepřenáší jako jednotlivé části oddělené tečkou a celé zakončené třeba nulovým bajtem, ale jméno je podle teček rozděleno na části, a ty se pak zapisují tak, že v prvním bajtu je délka části a následuje textová reprezentace dané části. Přičemž první bajt může nést i jinou informaci (délka části je max. 64 znaků, takže ještě zbývají volné bity na další informace). Tj. zlaadresa.com se přenáší jako \x09zlaadresa\x03com. Další věc je, že se názvy v paketu neopakují, ale je možné se tam odkazovat na předchozí výskyty.

Jinými slovy, porovnávat to jenom pomocí shody se vzorem nejde. Musel byste jedině použít nějaký DNS proxy server, který bude protokolu DNS rozumět. Ale moc nechápu smysl takového počínání.

[Michal Kubeček]

Navíc je DNS je case insensitive, takže by nebylo potřeba vymýšlet žádné speciality a stačilo by používat např. zlaAdresa.com.

[Zdeněk Zámečník]

Case sensivity lze vyřešit patchem, možná je to i v mainstreamu. Nevím, nezkoušel jsem, ale několikrát jsem na to již narazil.

[Zdeněk Zámečník]

Moc díky za vysvětlení, už to naprosto chápu. Hledal jsem problém úplně jinde a nenapadlo mne, že ta data se přenášejí v jiné formě. Chtěl jsem takto blokovat některé weby bez použití dns/http proxy.