Názory k článku Stavíme firewall (1)

Hlavni know-how pri vytvareni firewallu neni v tom,
jak se ta pravidla pisou, ale v tom do jakych casti
vlastne to filtrovani rozdelit. Prijde mi napriklad
naprosto zbytecne filtrovat cokoli v retezci OUTPUT. Take nevim, proc vsichni rozdeluji zvlast UDP a zvlast TCP provoz - tady zadnou funkcnost zavedenim dalsiho chainu neziskame. Naproti tomu kdybychom treba zavedli retezec "spoof", ktery by delal ochranu pred IP spoofingem a treba zahazovani RFC1918 IP adres na vstupu, tak tady se uz zvlastni chain vyplati - jednak muzeme misto ACCEPT/DROP rozhodovat stylem RETURN/DROP a pak zpracovavat dal, a jednak tento chain lze volat jak z INPUT tak z FORWARD (ja vim, ze zrovna tohle lze udelat i pomoci route path filteru, ale jsou situace, kdy rp_filter nelze pouzit - treba IPsec).

Dalsi poznamka je, ze vam to nebude fungovat, aspon pokud mate dostatecne novy BIND - ten pro odchozi dotazy nepouziva zdrojovy port 53, ale neco nahodneho nad 1023 (lze ho ovsem direktivou query-source prinutit k pevnemu portu). Takze odpovedi na vlastni DNS dotazy zahazujete v INPUT (i v INPUT je treba pouzit stavovou filraci, pripadne povolit packety z portu 53 na port query-source).

-Yenya

Ad: rozdělení TCP a UDP.
TCP je vhodné oddělit například tehdy, když chceme
filtrovat TCP pakety s příznakem SYN, které zároven
nejsou ve stavu NEW. Jistě to lze udělat i jinak, ale
tohle mi připadá jako dobrá motivace. Více bude v přpravovaném třetím díle článku.

Ad BIND:
Ano, funkční firewall by měl povolovat --state
ESTABLISHED,RELATED i v řetezci INPUT.

Dekuji za pekne napsany clanek. Doufam, ze se jemu podobnych bude na Rootu objevovat cim dal vice.

V uvodu mi trochu chybi informace, ze se tyka pouze 2.4 rady (prip 2.3), protoze ve 2.2 prochazi routovany paket vsechny tri chainy. Autor pouziva pro FORWARD modul state, coz je dobre, ale nepouziva ho pro INPUT. Tam se ale hodi mnohem vic, protoze pomoci nej muzeme firewall zjednodusit a predevsim omezit napr. skenovani portu ruznymi stealth technikami. Nema ani negativni dopad na vykon, protoze pokud je uz zapnuto sledovani konexi v kernelu, samotny test moc casu nezabere. K povolenym ICMP by se jeste dala pridat ICMP source-quench. Trideni provozu na UDP a TCP mi take unika, stejne jako filtrovani na OUTPUT. No a co mi prijde uz ponekud uplne mimo, tak mi tam chybi v INPUT nejake pravidlo, ktere by mi umoznilo jinou komunikaci nez je www a smtp. Treba tam obcas budu potrebovat stahnout nejaky update. Ale protoze nemam povoleny zadne pakety na jine nez www a smtp porty, tak si je asi nestahnu. Posledni drobnost, kterou bych autorovi vytknul, ze SNAT neni MASQUERADE. Hlavni rozdil je v tom, ze maskarada modifikuje zdrojovy port do oblasti nad 60000 (podle konfigurace), zatimco SNAT se snazi port zachovat.

Dekuji za reakci. Podrobnejsi informace o NATu budou
naplni druheho pokracovani clanku, stejne jako dalsi
priklady na stavovy firewall budou uvedene ve treti
casti, kde jiz by take mela byt uvedena take finalni
podoba sady firewallovych pravidel, pouzitelna v praxi.

Myslim, ze source-quench neni v soucasne dobe prilis
pouzivan a v RFC 1122 se pise: "routers should discard
them".

Filtrovani v OUTPUTu nema zadne velke vyuziti (coz
ostatne v clanku zaznelo), ovsem da se na nem snadno
demostrovat mechanismus tvorby filtrovacich pravidel,
stejne jako rozdeleni TCP a UDP provozu naznacuje
moznosti tvorby vlastnich retezcu, coz bylo zamerem
tehle casti.

snad chapu k cemu je program iptables, ale co dela daemon stejneho jmena? (sorry za blbej dotaz)

Pokud narazite na to, ze v RH 7.x je zaroven sluzba,
ktera se nazyva iptables, tak vezete, ze tato se stara
o nastavovani/zhazovani filtrovacich pravidel. Neni to
tedy demon, ale nadstavba nad iptables.

Pokud nechcete, nemusite ji pouzivat a pravidla si
nastavovat primo, pomoci skriptu s primym volanim
iptables.

Ten clanok je dobry, ale napr. velmi by som privital clanok o obmedzovani pasma pomocou CBQ v kombinacii s iptables. Napr. obmedzenie maximalneho toku pre mail trafic a podobne.

Pokial vies anglicky, tak nasmeruj svoj prehliadac na www.ds9a.nl/lartc je tam cele HOW-TO ako to urobit, ale princip je taky, ze si cez iptables -j MARK --set-mark 1 a potom pouzijes "fw" classifier na precitanie toho mark-u a zaradenie do spravnej class/queue.

Pro zakladni omezeni muzete pouzit modul limit pro iptables. Rozvazovani provozu pomoci napr. CBQ na cilove stanici je neuskutecnitelne, linux nema vstupni frontu. To je mozne resit pres Ingres, ale myslim, ze omezeni modulem limit je postacujici.

Konkretne budem riesit obmedzenie asi na routeri, nie na koncovom pocitaci, inak s ingres som mal problem, vypisalo mi, ako keby neexistoval ten modul, zrejme som nieco nedokompiloval do jadra. Co sa tyka modulu limit, ten neviem, ci umoznuje kontrolovat priamo pocet pretekajucich bytov, skor pocet packetov (zatial som to vyuzival na obmedzenie vytvarania velkych logov). Ak sa mylim, opravte ma, pripadne skuste uviest nejaky jednoduchy priklad.

Ne omlouvam se, limit je jenom na pocet paketu. Jsem nad tim uvazoval, ale nez jsem to napsal, tak se myslenka kamsi vytratila ;-).

Dobrej clanek,pokracovat .....

Vazeni pratele, nedavno jsem narazil na zajimavy
problemek. Da se z NATovaneho paketu zjistit,
ze byl NATovan? Jinak receno, da se zjistit,
ze dany pocitac maskaraduje nejakou sit?
Dik Honza

No, z maskarady ano, zdrojovy port se toula mezi 61000 a 65000, u bezneho nemaskovaneho spojeni je mezi 1024 a 5000 (linux, u win jsem v zivote nevidel tak vysoky port jako je 4000). U SNAT je to uz vetsi problem, porty jsou vetsinou stejne. Nejjednodussi je, pokud na masine bezi identd. Na dotazy na maskovana spojeni odpovida chybovym hlasenim, na spojeni primo z masiny vrati jmeno uzivatele, kteremu spojeni patri. Trosku slozitejsi metoda by asi spocivala v pokusu vnutit do spojeni vadny paket, ktery by prosel NAT kodem, ale maskovany stroj by vratil chybovou ICMP zpravu. Ve 2.2 kernelu (tedy maskarada) nebyly tyto chybove zpravy zpetne maskovany, takze v nich bylo skutecne ip maskovaneho pocitace. Jak je to v NAT kodu 2.4 jsem zatim nezkoumal. Otazkou ale zustava, nakolik je mozne takovy vadny paket protlacit.

Dobrej clanek. Popisuje zaklady, ale clovek ma casto mezery v zakladech... I diskuze zde mne inspiruje k lepsimu a prehlednejsimu nastaveni.

Tak mě napadá, že ve článku by ještě mohl být odkaz
na to, jak vypadá hotový firewallový skript. Nebo
spíše jak bude vypadat po dokončení tohoto seriálu.

Napsal jsem tedy ukázková pravidla, hojně jsem je
okomentoval a vystavil na:

http://www.petricek.cz/mpfw/mpfw.sh.txt

Pokud to někomu pomůže budu rád :)

Opravdu muze byt TCP packet ve stavu NEW bez SYN
flagu? Mel jsem za to, ze takovyto packet je
ve stavu INVALID, nikoliv NEW.

???

-Yenya

Zminenou konstrukci jsem se inspiroval zde:
http://www.boingworld.com/workshops/linux/iptables-tutorial/iptables-tutorial/iptables-tutorial.html#AEN1632

Paranoidnejsi povahy povoluji routovani az po nastaveni firewallovacich pravidel.

Radek

$IPTABLES -A INPUT -i $INET_IFACE -p TCP --dport 113 -j REJECT #AUTH server

je dobre mit, bohuzel kernel vraci nevhodnou ICMP chybovou zpravu (tusim ze no route to host). Ta u vetsiny serveru, ktere se o ident pokouseji, zpusobi stejnou prodlevu. Druha vec je ta, ze je videt, ze je pocitac chranen firewallem, coz muze nekdy vadit. Myslim, ze nejvhodnejsi je:

$IPTABLES -A INPUT -i $INET_IFACE -p TCP --dport 113 -j REJECT #AUTH server --reject-with icmp-port-unreachable

to '#AUTH server' tam samozrejme nema co delat ;-).

Ano, mate pravdu. port-unreachable je lepsi nez prosty
REJECT. Jeste lepsi je ale --reject-with tcp-reset

Tesim se na dalsi dil.

na novom kerneli 2.4.16 mi to v nasom debiane (woody)
kraka pri pravidle
iptables -A FORWARD .. -state

nieco ako could'nt load state. couldnt open shared file or directory. nejaky help?

Zdravim!
Predem diky za clanek.
Vrta mi hlavou co se stane s pakety na vstupu kdyz projdou do 'retezce' tcp_segmenty, ale uz nesplni ani jedno pravidlo pro tento 'retezec'. Kernel se k nim zachova dle implicitni politiky pro INPUT (a) ci je pro nove zalozene 'retezce' treba nastavovat imlicitni politiku (b)?
Z cteni mezi radky jsem vydedukoval, ze a) je spravne, pricemz varianta b) mi pripada o neco logictejsi. Omlouvam se za dotaz na neco co bych mohl nacist v man ci info, ale momentalne nemam moznost si to vyzkouset. Dik.
Martin Trtusek

Vychozi politika retezce je RETURN. Tzn paket, ktery nebyl v uzivatelskem retezci filtrovan se vrati zpatky do INPUTU hned za pravidlo, ktere je tam predalo.

Omlouvam se za smesny dotaz, ale pri pokusu pripojit se FTP klientem z nejake stanice pres takto nastaveny firewall mi pise klient illegal port command. Vite prosim, jak toto odstranit. Dekuji.

Zavedte modul ip_conntrack_ftp a povolte prichozi ESTABLISHED a RELATED konexe na INPUTu, resp. FORWARDu.

Podivejte se do http://www.petricek.cz/mpfw/mpfw.sh.txt nebo pockejte na treti dil tohoto clanku ve kterem je problematika aktivniho/pasivniho rezimu rozebrana podrobneji.

A opet blby dotaz. Jak toto udelat na bezmodulovem jadru? Myslel jsem, ze je bezpecnejsi? :-)

Přikompilovat CONFIG_IP_NF_FTP do jádra.

BTW: bezmodulové jádro NENÍ bezpečnější.

sorry za offtopic, ale vazne by me zajimalo, proc $BTW ?

diky
0ndrej

Pouze ip_conntrack_ftp nestačí.
Ještě chybí zavést ip_nat_ftp pro rozumnou práci s ftp.

Zdravím a prosím vás o radu:
iptables -A INPUT -i eth0 -p TCP -dport 22 -j DROP
mi vyhodí chybu Bad argument '22'
Nevíte někdo co s tím? Děkuji

povedal by som ze by to malo byt:
iptables -A INPUT -i eth0 -p TCP --dport 22 -j DROP

chybala vam tam jedna pomlacka u dport

nie nahodou
iptables -A INPUT -i eth0 -p TCP -m tcp --dport 22 -j DROP

???

jak presne funguje to zadavanie urciteho rozsahu ip adries?
napriklad chcel by som aplikovat urcite pravidlo len na dany rozsah cize napriklad na lokalnej sieti by mali ipcky 192.168.33.102-192.168.33.170 povoleny port 5190 do internetu

iptables -I FORWARD -i eth1 -o eth0 -s xxxxxxxxx -p tcp -m tcp --dport 5190 -j ACCEPT

co napisat do toho xxxxx a na akom principe sa to urcuje. viem ze je tam ip/cislo a nieco so subnetom len som to akosi nepochopil

potom ohladom mac adries - jak vycucnem v tabulke forward mac adresu nejakeho pocitaca v lokalke? skusal som lognut -i eth1 ale bolo tam vsetko prave okrem mac adresy. v retazci input mi sice mac adresu chyti ale ja to potrebujem prave pre forward

je mozne postavit firewall tak aby mali Pocitace za nim verejne IP? ked ano tak ako?

Tak jeste prosim jak to uchovat po restartu :)
... neco jako /etc/rc.d/rc.local

Zkus iptables-save

iptables-save mě nefunguje
mam madreke 9.2 a shorewall nepoužívam

rad bych odebral shorewall a zprovoznil jen ciste iptables
nechtel bych ale znovu definovat vsechny pravidla

je mozne ze jsem jediny kdo resi prevod rules shorewall do iptables?