Vlákno názorů k článku
Stavíme firewall (1)

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.