ip_conntrack a odpovedi na UDP broadcast

[Honza Houstek]

> UDP spojeni nenavazuje. To vim, ze vis ;-). Na fw se udp da identifikovat
> jako "spojeno", kdyz proudi pakety, ale tak rozhodli programatori iptables.
> Ale udp a jeste odpoved na broadcast uznat jako vytvoreni spojeni?
> Rozhodli ze ne! (koukam do zdrojaku _core.c, ale moc moudry z toho nejsem)

ip_conntrack funguje tak, ze kdyz uvidi nejaky paket, tak si ho nekde (s
urcitym timeoutem) poznamena a taky si poznamena ocekavanou odpoved. Kdyz
tu uvidi, bere to jako navazane spojeni. V pripade TCP pochopitelne kouka
na veci jako SYN, ACK, SYN + ACK, v pripade UDP jen na zdrojove a cilove
adresy a porty.

Chapu, ze nemusi byt vzdy rozumne povazovat odpoved na udp broadcast za
ESTABLISHED, ale nejaky helper, ktery by to umoznil matchovat jako RELATED
by se urcite hodil.

> Je-li to windowsi stanice, tak po zapnuti broadcastuje. Fw detekuje
> (jak chces) spojeni mezi A a B. Na jak dlouho?

Tusim ze timeout pro udp v ip_conntrack (po zachyceni prvniho paketu) je
20s (da se zmenit). Neni to windowsi stanice, ale wins server (samba),
ktery pomoci udp broadcastu hleda pocitace na siti.

> Vzdyt to broadcastuje porad. Takze je tam trvala dirka. Proc neudelat
> takoveto pravidlo:
> iptables -A neco -s A -d B -dport 137 -J sem
> iptables -A neco -s B -d A -sport 137 -J sem
> tim padem je povolena komunikace bez ohledu na pocatecni zdrojovy udp port.

Ano, jenze tim druhym pravidlem povolim pocitaci B posilat mi libovolny
UDP traffic (jen si musi nastavit zdrojovy port 137). To neni prijatelne.

Ohledne te diry ... ano, bude tam vzdycky nejakou dobu, ale jednak bude na
vysokem portu a druhak si ji otevre ten wins a ne stanice na siti.

-- Honza Houstek