Vlákno názorů k článku
Vše o iptables: IP část

Neni vhodne blokovat pakety pomoci targetu DROP, nebot pri pouziti tohoto targetu se vas pocitac chova zpusobem, ktery neni v souladu s prislusnymi RFC dokumenty pro IP protokol. Vhodnejsi je pouzit target REJECT:

Pro blokovani TCP v chainu INPUT v pak jeste s atributem --reject-with tcp-reset .
Pro blokovani UDP v chainu INPUT bez argumentu.
Pro blokovani v chainech, ktere se aplikuji jindy nez INPUT, bude nejspis nejlepsi pouzit --reject-with s nekterou *-prohibited hodnotou.

Pri tomto pouziti REJECT pro chain INPUT se zablokovany port bude chovat z vnejsiho pohledu uplne stejne, jako by na nem nic nebezelo, a IP stack i aplikace se budou chovat rozumne (smysluplne chybove hlasky).

Obvykle blokovani pomoci targetu DROP v INPUT chainu zpusobuje problemy (dlouhe timeouty namisto okamziteho ohlaseni neuspechu) jen ostatnim, v nekterych pripadech to vsak zpusobuje problemy i uzivatelum blokujicicho systemu:

- Pokud se uzivatel snazi kontaktovat server, ktery si loguje uzivatelske jmeno pomoci sluzby auth/ident a nepovoli navazani spojeni pred dokoncenim pokusu o auth/ident. Tak se chova napr, xinetd v konfiguraci se zaplym logovanim USERID. S timto problemem se bezne setkavam.
- Pokud se uzivatel snazi kontaktovat pocitac, ktery provozuje IPSec v modelu 'opportunistic encryption'. S timto jsem se jeste nesetkal.
- dalsi pripady, ktere me nenapadly.

Osobne take pouzivam radeji DROP:

a) pokud mam sluzbu otevrenou, spojeni nabehne hned a nic se neblokuje, pokud mam spojeni zavrene, zrejme nechci, aby se mi na to pripojoval nekdo cizi a pokud to udela, musi pocitat s tim, ze ho muzu ignorovat (nebudu s nim komunikovat podle RFC)
b) v pripade *DoSu bude muj stroj odpovidat na kazdej TCP dalsim paketem s tcp-resetem, navic v pripade DDoS s fake IP bude muj stroj generovat peknej sitovej provoz. Proc bych mel byt generatorem nejakych dat, ktera generovat nechci?

"Pri tomto pouziti REJECT pro chain INPUT se zablokovany port bude chovat z vnejsiho pohledu uplne stejne, jako by na nem nic nebezelo"

S tim rozdilem, ze v pripade s REJECTem to bude vytrubovat do sveta (a prakticky "bude komunikovat"), kdezto s DROPem vubec nebude komunikovat.

a) pokud mam sluzbu otevrenou, spojeni nabehne hned a nic se neblokuje, pokud mam spojeni zavrene, zrejme nechci, aby se mi na to pripojoval nekdo cizi a pokud to udela, musi pocitat s tim, ze ho muzu ignorovat

No ale pak musis pocitat s tim, ze kdyz chces s nekym komunikovat (treba z libovolnym serverem na internetu), tak ten muze pred zacatkem komunikace zkusit kontaktovat nejaky port na tvem pocitaci, jemu to bude timeoutovat (protoze ho ignorujes) a v dusledku ty budes cekat, nez se otevre puvodni pozadovane spojeni. Coz se deje v tech pripadech, ktere jsem popisoval.

>> "Pri tomto pouziti REJECT pro chain INPUT se zablokovany port bude chovat z vnejsiho pohledu uplne stejne, jako by na nem nic nebezelo"

> S tim rozdilem, ze v pripade s REJECTem to bude vytrubovat do sveta (a prakticky "bude komunikovat"), kdezto s DROPem vubec nebude komunikovat.

Ano, vytrubovani do sveta je standardni chovani pro uzavreny port.

To ze me kontaktuje zpatky je OK u sluzby AUTH. Jinak je to podezrele a zahazuju to. Naopak je vyhodne nechat protistranu timoutovat, malinko to stezuje pripadne scanovani. Take se tim vice zamestna najekej otrava nakazeny virem (At zile Wokonous RPC!!) a nestihne tolik zaneradit internet. # Sluzbu AUTH neni dobre filtrovat pomoci DROP, protoze to muze # vest k prodlevam pri navazovani nekterych spojeni. Proto jej # sice zamitneme, ale tak, aby nedoslo k nezadoucim prodlevam. iptables -A INPUT -p TCP --dport 113 -j REJECT --reject-with tcp-reset #AUTH server iptables -A INPUT -p UDP --dport 113 -j REJECT #AUTH server

To ze me kontaktuje zpatky je OK u sluzby AUTH. Jinak je to podezrele a zahazuju to. Naopak je vyhodne nechat protistranu timoutovat, malinko to stezuje pripadne scanovani. Take se tim vice zamestna najekej otrava nakazeny virem (At zile Wokonous RPC!!) a nestihne tolik zaneradit internet.


<code>
# Sluzbu AUTH neni dobre filtrovat pomoci DROP, protoze to muze
# vest k prodlevam pri navazovani nekterych spojeni. Proto jej
# sice zamitneme, ale tak, aby nedoslo k nezadoucim prodlevam.
iptables -A INPUT -p TCP --dport 113 -j REJECT --reject-with tcp-reset #AUTH server
iptables -A INPUT -p UDP --dport 113 -j REJECT #AUTH server
</code>

Omlouvam se za formatovani predchoziho prispevku

Resim problem presne obracenou metodou - vetsinu portu REJECTuju (s limitem na maximalni pocet proti DOSu - limit: avg 128/sec burst 512 reject-with icmp-port-unreachable, asi zbytecne mnoho ale princip urcite dobry) a specificky windows RPC a par portu okolo (137:139) DROPuju ...