Názory k článku
Vše o iptables: IP část

V prvnim prikladu bude chybka, protoze z nasledujicich pravidel
iptables -A INPUT DROP
iptables -A INPUT -i eth0 -s 192.168.0.1 -j ACCEPT
se aplikuje na vstupni filtru pravidlo 1 a vsechny pakety se zahodi. Pravdepodobne mel autor na mysli
iptables -P INPUT DROP

respektive ani se neaplikuje, protoze chybi -j :-)

Ja vim, omlouvam se, ma tam byt skutecne "iptables -P INPUT DROP", potom jsem posilal i opravenou verzi do redakce, ale asi se to nejak pomichalo :)

tesim se na dalsi dil

opravdu bezva serie clanku
diky!

Těším se na pokračování.

Ahoj, opravdu precizne psany serial, clovek si to tak pekne vsechno utribi v hlave. A taky bych se rad zeptal na jednu malickost. Je tam uvaden parametr -g jako moznost jak se odkazat na jiny chain. Ja to resim pomoci -j , je to problem, funguje to take. Diky CD

děkuji za článek, dost fajn!

zajímalo by mě, zda se budete zabývat i možností přístupu k IPTABLES z programátorského hlediska?

ja som kedysi na to pouzival nejake api, ale to api nie je (nebolo) odporucane pouzivat. tusim, ze na nejakom stabilnom api sa stale pracuje ...

Super clanok

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 ...

díky, bude opraveno.

To je jednoduché: pokud máte chain A, z něj pomocí -j skočíte do chainu B a z něj zavoláte pomocí -g chain C, pak return z chainu C vás vrátí přímo do A.
Neboli nadřízený chain, který volá podřízený pomocí -g, bude při returnu přeskočen (a nejspíš nejspíš těch -g může být víc, potom budou přeskočeny všechny).

Programátorsky: --jump se chová jako CALL, neboli volání subrutiny se zapamatováním návratové adresy, --goto se chová jako JUMP, neboli skok bez zapamatování návratové adresy. :-)

Dik, chapu.

Jedno pravidlo vraci paket a druhe ne.
Tj pravidlo hodi paket do jinecho chainu kde se vyhodnoti a pak se vrati zpet a paket analyzuji dalsi pravidla.
Druhe pravidlo presune paket do jineho chainu ze ktereho jiz se nevrati.

Alespon si to tak myslim ze to tak je, ale nevim jake dela co, podle me goto nevraci paket z5.

Co se stane? Povoleny budou jenom ty z 192.168.0.3. Proč? Protože všechny pakety, které nejsou z 192.168.0.3, vyhoví v tom prvním pravidle - budou zahozeny, a další se už netestují. Vazne ? Ja ty vykricniky moc nepouzivam, ale IMHO prvni pravidlo zahodi vsechno co neni z 192.168.0.3 a pote se prejde k druhemu pravidlu co logicky zahodi cely zbytek ...

Ano mate pravdu, mozna jsem to napsal spatne, ale mel jsem na mysli ze se uz ta 192.168.0.1 testovat nebude, protoze se zahodi.

neni to nahodou tak, ze neprojde vubec nic? prvni pravidlo prece zahodi vsechny pakety mimo paketu prichazejicich z 192.168.0.3, ktere jsou posleze testovany na druhe pravidlo, ktere zahodi i je. takze nakonec jsou zahozene vsechny... nebo se mylim?

nejsem si jistý, ale jestli jsem to dobře pochopil, tak na první pravidle se všechny packety kromě packtů z IP 192.168.0.3 zahodí a tedy na ně bylo aplikováno pravidlo a dále se už netestují. Dále se testují jen packety z IP 192.168.0.3 a ty se pak zahodí protože nepochází z 192.168.0.1. Výsledek neprojde nic.

nejsem si jistý, ale jestli jsem to dobře pochopil, tak na první pravidle se všechny packety kromě packtů z IP 192.168.0.3 zahodí a tedy na ně bylo aplikováno pravidlo a dále se už netestují. Dále se testují jen packety z IP 192.168.0.3 a ty se pak zahodí protože nepochází z 192.168.0.1. Výsledek = neprojde nic.

Snazil jsem se, ale stejne se mi nepodarilo v prvnim dile nalezt zminku o vytvareni Chain..?

Jako temer uplny zacatecnik (obcas jsem menil nejake drobnosti v ipfwadm a pod..) z toho zatim moc moudry nejsem, muzete mi doporucit nejake dalsi materialy, knihy? Zatim mi chybi ten spravny "guru" ;-)

rekl bych ze je to zajimave seznameni s iptables pro lidi co o tomto programu nemaji velke znalosti,urcite je prinosem,skoda ze autor nepridal dalsi dil