Dotaz: mam to spravne? - FireWall

[Vaškic]

Tak jsem konecne rozchodil router+FireWall o kterym musim pristi tyden odevzdat semestralku a protoze jsem v tomto zacatecnik tak bych se rad zeptal jestli to mam spravne? Sice to funguje, ale bral bych nazory a co vylepsit...
Jedna se o router na kterym nic nebezi (proto on ma cokoliv zakazano) a pouze zprostredkovava inet z eth0 na eth1 do vnitrni site.
# zapnu routovani paketu
echo 1 > /proc/sys/net/ipv4/ip_forward
# nejprve spustim firewall, kteremu budu predavat pravidla pomoci iptables
modprobe ip_tables
# umoznim pruchod aktivniho ftp firewallu
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
# prekladac adres - maskarada
modprobe ipt_MASQUERADE
# zprostredkovani pripojeni vnitrni site k internetu
iptables -t nat -I POSTROUTING -j MASQUERADE -s 192.168.0.0/24
#
# nastaveni pravidel FireWallu
#
#vychazim ze zahazovani vsech paketu ve vsech retezcich
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# povoleni portu 20 sluzba ftp data
iptables -A FORWARD -o eth0 -p tcp --dport 20 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --sport 20 -j ACCEPT
# povoleni portu 21 sluzba ftp
iptables -A FORWARD -o eth0 -p tcp --dport 21 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --sport 21 -j ACCEPT
# povoleni portu 25 sluzba smtp
iptables -A FORWARD -o eth0 -p tcp --dport 25 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --sport 25 -j ACCEPT
# povoleni portu 53 sluzba TCP/UDP pro DNS
iptables -A FORWARD -o eth0 -p tcp --dport 53 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --sport 53 -j ACCEPT
iptables -A FORWARD -o eth0 -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -i eth0 -p udp --sport 53 -j ACCEPT
# povoleni portu 80 sluzba http
iptables -A FORWARD -o eth0 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --sport 80 -j ACCEPT
# povoleni portu 110 sluzba pop3
iptables -A FORWARD -o eth0 -p tcp --dport 110 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --sport 110 -j ACCEPT
# povoleni portu 443 sluzba HTTPS
iptables -A FORWARD -o eth0 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --sport 443 -j ACCEPT
# povoleni portu 5190 sluzba ICQ
iptables -A FORWARD -o eth0 -p tcp --dport 5190 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --sport 5190 -j ACCEPT

Tot vse, jinac na netu je mooooc navoda a ukazek, ale takovejhle obycejnej jednoduchej sem nikde nenasel, tak doufam, ze to i treba nekomu pomuze...

Odpovědi

[martin]

Myslim, ze to je uplne spatne. Rozhodne by tam nemela byt pravidla iptables -A FORWARD -i eth0 ..., pokud nechcete, aby se dalo dostat z internetu do lokalni site. Misto toho by tam melo byt neco jako

iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Dale bych misto MASQUERADE pouzil SNAT, ale to uz neni tak hrozny.

[Vaškic]

Nejak to nejsem schopnej s timhle rozchodit. Mohl byste mne please ukazat jak by to melo vypadat napr. pro port 80?
A myslim, ze SNAT je jen pro jedno pripojeni, ja tam ale mam na eth1 vic pocitacu takze tam myslim maskarada musi byt?

[ttt]

Ten SNAT by mohl vypadat treba takto: iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to verejneIP

[Vaškic]

Uz jsem snad prisel na to kde byla chipka takze tady mam verzi 1.0.0.1 stabile ... Doufam, ze uz je to lepsi.

# zapnu routovani paketu
echo 1 > /proc/sys/net/ipv4/ip_forward
# nejprve spustim firewall, kteremu budu predavat pravidla pomoci iptables
modprobe ip_tables
# umoznim pruchod aktivniho ftp firewallu
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
# prekladac adres - maskarada
modprobe ipt_MASQUERADE
# zprostredkovani pripojeni vnitrni site k internetu
iptables -t nat -I POSTROUTING -j MASQUERADE -s 192.168.0.0/24
#
# nastaveni pravidel FireWallu
#
#vychazim ze zahazovani vsech paketu ve vsech retezcich
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# povoleni portu 20 sluzba ftp data
iptables -A FORWARD -o eth0 -p tcp --dport 20 -j ACCEPT
# povoleni portu 21 sluzba ftp
iptables -A FORWARD -o eth0 -p tcp --dport 21 -j ACCEPT
# povoleni portu 25 sluzba smtp
iptables -A FORWARD -o eth0 -p tcp --dport 25 -j ACCEPT
# povoleni portu 53 sluzba TCP/UDP pro DNS
iptables -A FORWARD -o eth0 -p tcp --dport 53 -j ACCEPT
iptables -A FORWARD -o eth0 -p udp --dport 53 -j ACCEPT
# povoleni portu 80 sluzba http
iptables -A FORWARD -o eth0 -p tcp --dport 80 -j ACCEPT
# povoleni portu 110 sluzba pop3
iptables -A FORWARD -o eth0 -p tcp --dport 110 -j ACCEPT
# povoleni portu 443 sluzba HTTPS
iptables -A FORWARD -o eth0 -p tcp --dport 443 -j ACCEPT
# povoleni portu 5190 sluzba ICQ
iptables -A FORWARD -o eth0 -p tcp --dport 5190 -j ACCEPT
# povoleni navratu paketu patrici nami vytvorenemu spojeni
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Takze please zase nejaky pripominky, napady... Diky

[Jesus Jimenez]

;) hlavne do te semestralky nepiste nic o "chipkach", nebo vas vyhodi hned mezi dvermi ;)

[Michal Kubeček]

Moc nerozumím tomu, proč vlastně cítíte potřebu omezovat, na které porty se smí přistupovat z vnitřní sítě ven...

Pravidlo pro překlad adres vypadá trochu divně, jednak bych na vašem místě přidal podmínku, aby se překládaly jen pakety, které jdou ven, jednak se mi moc nezdá ta podmínka až za akcí.

A ještě jedna praktická rada: kvůli efektivitě je vhodné, aby pravidla, která řeší největší část provozu, byla testována jako první. Vy to pravidlo, které typicky řeší největší část provozu, máte jako úplně poslední...

[Jarek Šeděnka]

aspoň pujde v logach videt, kdyz zacne radit Sasser nebo neco podobneho.. Taky se tim dost omezi trojsti konici (vim ze zvenku se pripojit nepujde, ale treba veci co napadnou pocitac a pak se poslusne hlasi u sveho pana?

[Michal Kubeček]

Tuto úvahu už jsem několikrát viděl a považuji ji za naprosto zcestnou. Představte si, že takového trojáka budete psát. Jakou formu komunikace zvolíte: něco zcela netypického na neobvyklém portu, co na sebe na první pohled upozorní, nebo raději něco, co bude pokud možno co nejvíce připomínat běžný provoz? Nevím jak vy, ale já bych určitě zvolil komunikaci, která by co nejvíce připomínala HTTP (a dost možná bych to udělal i tak, aby to opravdu bylo HTTP), SMTP, POP3 nebo podobně všudypřítomný protokol, který nikomu nebude naznačovat, že se děje něco nepatřičného...

[Vaškic]

Ja jsem prave myslel, ze nejlepsi je filozofie vsechno zakazat a pak postupne povolovat jen to co potrebuju.
Ten preklad adres zkusim jeste vylepsit (pokud zbyde cas)
Posledni podminku jsem uz dal na zacatek - diky

[Vaškic]

Ja jsem prave myslel, ze nejlepsi je filozofie vsechno zakazat a pak postupne povolovat jen to co potrebuju.
Ten preklad adres zkusim jeste vylepsit (pokud zbyde cas)
Posledni podminku jsem uz dal na zacatek - diky

[Michal Kubeček]

To samozřejmě je. Jenže to je filosofie při řešení přístupu zvenku, přičemž zvenku tu znamená i třeba přístup z vnitřní sítě na firewall samotný. Nemá ale IMHO smysl bránit vlastním uživatelům v přístupu ven. Bezpečnosti tím nepomůžete a budete jim jen zbytečně komplikovat život. Navíc tím podporujete čím dál rozšířenější pocit, že Internet je jen web (a možná ještě e-mail) a zbytek nestojí za řeč.

[Ondřej Suchý]

Firewallové omezení přístupu na vybrané služby zevnitř ven je stejně legitimní jako zvenku dovnitř. Může pro to být celá řada důvodů, například omezení aktivit zaměstnanců, ochrana vnějšího prostředí před útoky zevnitř (zejména viry a červy), či vynucení některých fines bezpečnostní politiky.

[Michal Kubeček]

Legitimní to samozřejmě je, ale o praktické užitečnosti mám vážné pochybnosti. Aktivity zaměstnanců výše popsané řešení neomezí - stačí jeden kamarád venku a stejně se dostanou, kam budou potřebovat; nemluvě o tom, že kdyby chtěl správce něco omezit, zrovna ICQ (které je zde mezi povolenými) bude na čelních místech. Vnější prostředí by se jednak mělo ochránit samo, jednak každý autor červa, který má rozum, pro komunikaci ven použije právě ty porty, které jsou zde povoleny (jak už jsem psal v minulém příspěvku). A co se vynucení bezpečnostní politiky týká, dokážu si představit omezování toho typu, že např. zakážu TCP provoz ven na port 25, aby pošta ven musela jít přes náš MTA, případně vynucení HTTP provozu přes proxy (s již několikrát zmíněnou výhradou) - jenže popsané řešení opět funguje přesně opačně. Takže ano, za určitých okolností má smysl omezovat provoz zevnitř ven, ale nevidím moc smyslu v tom, aby to někdo dělal tak, jak bylo popsáno v příspěvku tazatele.

[sake]

No, ci ono to obmedzenie nebolo myslene tak, aby napr. zamestnanci nestahovali filmy z P2P sieti a pod. a nezatazovali tym siet.