Jsou nutná tato pravidla v iptables?

[Hamparle]

Jsou nutná pravidla v iptables? Ve smyslu dalšího zabezpečení, abych nebyl zdrojem bogus paketů, marťanských paketů, aby se do mé vnitřní sítě naopak tyto nedostaly.

Podstatou dotazu je ,zda sám systém řeší korektní směrování & filtrování tak, aby
z  WAN wlan0 neodcházely pakety s IP cílovou nebo zdrojovou patřící vnitřní síti (probíhá NAT)
na  byly blokovány příchozí pakety s IP zdrojovou adresou  rozsahu patřící vnitření síti mimo rozhraní eth0(kde se tato síť vyskytuje)

wlan=vnější rozhraní (upstream konektivita) WAN, síť např 192.168.2.0/24 - adresa stroje 192.168.2.32.
eth0=rozhraní vnitření sítě (192.168.1.0/24) - adresa 192.168.1.100

(komentáře vypadají stejně, ale liší se), pravidla jsou také zde v ukázce napsané vícekrát -mnohdy zbytečně. Která pravidla jsou naprosto zbytečná
--z důvodu že je řeší NAT nebo samotné forwardování a není potřeba se starat o fyzická rozhraní)
-- ale aby fungovoval přístup do internetu z vnitřní sítě

-A FORWARD -i wlan0 -o wlan0 -j DROP
-P FORWARD DROP
-A FORWARD -i wlan0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A POSTROUTING -t mangle -o wlan0 -s 192.168.1.0/24 -j DROP ## dohnané a ohnuté do extrému, smyslem mělo být "ať wlan0 neopustí paket s zdrojovou adresou mé sítě) - jenže filter nemá POSTROUTING
-A POSTROUTING -t mangle -o eth0 -s 192.168.2.0/24  -j DROP ## dohnané a ohnuté do extrému, smyslem mělo být "ať do Eth0 nepřijde paket s IP nadřazené sítě) - jenže filter nemá POSTROUTING
-A PREROUTING -t mangle -i wlan0 -s 192.168.1.0/24  -j DROP ## dohnané a ohnuté do extrému, smyslem mělo být "ať do wlan0 nnepřijde paket paket s IP mé sítě) - jenže filter nemá
-A PREROUTING -t mangle -i eth0 -s 192.168.2.0/24  -j DROP ## dohnané a ohnuté do extrému, smyslem mělo být "ať do eth0 nepřijde paket paket s IP nadřazené sítě) - jenže filter nemá POSTROUTING



2.revize

-A FORWARD  -i wlan0 -s 192.168.1.0/24 -j DROP ## pakety přicházející na WAN obsahující

-A FORWARD  -o wlan0 -d 192.168.1.0/24  -j DROP ##  smyslem mělo být "ať do wlan0 nnepřijde paket paket s IP mé sítě)


celkem je možno 8 kombinací  (-i / -o , -s / -d  wlan0/eth0)

Dopracoval jsem se k tomuto pravidlu (pro policy DROP)

iptables -A FORWARD  -s 192.168.1.0/24 -i eth0 -o wlan0    -j ACCEPT
iptables -A FORWARD  -d 192.168.1.0/24 -i wlan0 -o eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT


tím pádem jsou tyto zbytečná že:

-A FORWARD  -d 192.168.2.0/24   -j DROP # chci aby sítě 168.1 a 168.2. spolu nemluvily ( outbound ,není potřeba určovat -s)
-A FORWARD  -s 192.168.2.0/24   -j DROP # chci aby sítě 168.1 a 168.2. spolu nemluvily (inbound)

Je to dlouhý post plný pravidel firewallu, ale rád bych věděl, která pravidla jsou skutečně nutná a o která se není potřeba starat a vyplývají z logiky routování případně definice sítě (a zároveň bych se zbavil explicitních zápisu rozhraní a/nebo IP rozsahů kde to není bezpodmínečně nutné)


čili aby to nebylo tak dlouhé

Kód: [Vybrat]

# prázdná tabulka a policy DROP

iptables -A FORWARD  -s 192.168.1.0/24 -i eth0 -o wlan0    -j ACCEPT
iptables -A FORWARD  -d 192.168.1.0/24 -i wlan0 -o eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 

[Reklama]

[Miroslav Šilhavý]

Samotná pravidla bezpečnosti (co smí odkud a kam) se řeší výhradně na filteru. NAT to nezajistí (díky conntracku a helperům je dojem bezpečnosti NATU pouze zdánlivý). Mangle zase nemá informace o zdroji provozu. Do mangle patří úplně bazální kontroly, aby se na interfacu neobjevil provoz z/na IP adresu, se kterou si interface z logiky věci neporadí, nebo třeba kontroly MAC vs. IP apod. V mangle je častější notace v negaci (pokud packet nemá zdrojovou adresu X.X.X.X => DROP). Na filtru je obvyklejší notace přímá (a policy DROP). Tedy velmi nepřesně a velmi zjednodušeně: na mangle vypíšete, co všechno neočekáváte z/do daného směru. Do filtru naopak povolíte, co očekáváte.

Osobně ještě navíc doporučuji v rámci LAN nepoužívat DROP, ale REJECT s patřičnými parametry, zkrátíte si tím timeouty a vše se v síti chová spořádaněji. Směrem do internetu záleží na situaci. Při pomalejších linkách se musí preferovat DROP, pokud je linka rozumně dimenzovaná, je lepší REJECT s určitým limitem (po překročení přejde na DROP).

Pak jste se ptal, jestli něco dělá systém implicitně. Ano, dá se nastavit vícero parametrů, ale z hlavy mě napadá, že by Vás mohl zajímat rp_filter (https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html).

Myslím, že pro tyto účely je vhodné využít nějaký sofistikovanější firewall. Zkuste se podívat např. na https://shorewall.org/. Ten podle lidsky čitelnější konfigurace nastaví spoustu věcí sám.

Nicméně přemýšlíte o tom správně a kladete (si) správné otázky, které velká část "odborníků" (těch v uvozovkách) naprosto zanedbává.

[Filip Jirsák]

Firewall slouží k blokování nežádoucího provozu. O tom, co je nežádoucí provoz, rozhoduje správce. Nejsou tedy nutná žádná pravidla firewallu – konfigurace firewallu, která propouští veškerý provoz, je zcela legitimní. Takže o tom, zda jsou nějaká pravidla nutná nebo nejsou, lze rozhodnout teprve tehdy, až byste napsal, který provoz považujete za nežádoucí.

z důvodu že je řeší NAT

NAT provoz nijak neomezuje.

samotné forwardování

Samotné forwardování neřeší nic. Můžete si ale zapnout rp_filter, který blokuje pakety na základě odchozí IP adresy. Předpokládá, že do každé sítě je jenom jedna cesta, takže pokud máte síť třeba 192.168.0.1/24 na eth0, a paket se zdrojovou IPv4 adresou z této sítě se objeví na jiném rozhraní, rp_filter ho zahodí.

není potřeba se starat o fyzická rozhraní

Nerozumím, co jste tím chtěl říci.

Obecně k tomu vašemu dotazu – nastudujte si, co je firewall a co NAT. V Linuxu se sice obojí konfiguruje příkazem iptables, ale to neznamená, že je to to samé. Takže třeba POSTROUTING a PREROUTING jsou řetězce v NATu, takže v nich nic nefiltrujete a řešit tím „ať neopustí paket“ je špatně.

[Miroslav Šilhavý]

Tady je malůvka, jak packet prochází přes mangle, nat, filter (a další): https://en.wikipedia.org/wiki/Netfilter

[modnar]

Na blokovani ve FORWARD a na ty mangly se uplne vykasli a radsi si nastuduj si k cemu se pouziva rp_filter a nebudes je vubec potrebovat.

[Reklama]

[_Jenda]

Na blokovani ve FORWARD a na ty mangly se uplne vykasli a radsi si nastuduj si k cemu se pouziva rp_filter a nebudes je vubec potrebovat.

Když na WAN rozhraní přijde paket se src:internet (tedy je rp-legální, protože do internetu se routuje přes toto rozhraní) a dst:192.168.0.5, tak se RP filtr nijak neuplatní a router ho vesele pošle dovnitř, ne? Totéž pokud máš síť pro hosty s 192.168.1.0/24 a někdo z ní pošle paket na 192.168.0.5. Ten se dokonce ani nezmaškaráduje, protože nevylezl z WAN rozhraní kde je maškaráda, a tedy případná odpověď přijde úplně normálně.

[Miroslav Šilhavý]

Na blokovani ve FORWARD a na ty mangly se uplne vykasli a radsi si nastuduj si k cemu se pouziva rp_filter a nebudes je vubec potrebovat.

Hodně odvážné tvrzení. Taky dejte chvilku studiu.

[modnar]

Na blokovani ve FORWARD a na ty mangly se uplne vykasli a radsi si nastuduj si k cemu se pouziva rp_filter a nebudes je vubec potrebovat.

Hodně odvážné tvrzení. Taky dejte chvilku studiu.

Ceho? Toho pseudo anti-spoofingu?

quote author=_Jenda link=topic=23485.msg336053#msg336053 date=1599070634]

Na blokovani ve FORWARD a na ty mangly se uplne vykasli a radsi si nastuduj si k cemu se pouziva rp_filter a nebudes je vubec potrebovat.

Když na WAN rozhraní přijde paket se src:internet (tedy je rp-legální, protože do internetu se routuje přes toto rozhraní) a dst:192.168.0.5, tak se RP filtr nijak neuplatní a router ho vesele pošle dovnitř, ne? Totéž pokud máš síť pro hosty s 192.168.1.0/24 a někdo z ní pošle paket na 192.168.0.5. Ten se dokonce ani nezmaškaráduje, protože nevylezl z WAN rozhraní kde je maškaráda, a tedy případná odpověď přijde úplně normálně.
[/quote]

a] Je tam maskarada, takze je uplne jedno co prijde z venku protoze netrackovane se to stejne zahodi.
b] Nekde vidis subnet 192.168.0.0/24? O nejake odpovedi nemuze byt rec. No a co, ze na to klient posle paket. Je to z LAN bloku neroutovelneho v netu zahodi to prvni router na ceste.
 

[_Jenda]

a] Je tam maskarada, takze je uplne jedno co prijde z venku protoze netrackovane se to stejne zahodi.

Maškaráda se neuplatní, neboť se spojení nenavazuje skrz maškarádované rozhraní ven.

b] Nekde vidis subnet 192.168.0.0/24? O nejake odpovedi nemuze byt rec. No a co, ze na to klient posle paket. Je to z LAN bloku neroutovelneho v netu zahodi to prvni router na ceste.

Dobře, tak naprosto konkrétní příklad (doufám že to mám nakonfigurované správně, nechce se mi nastavovat lab od nuly, tak jsem to vyzkoušel na existující síti; pro info router je aktuální OpenWRT):

• LAN 192.168.91.0/24, v ní zařízení 192.168.91.215 "oběť"
• WAN 192.168.12.0/24, v ní zařízení 192.168.12.1 "útočník"
• Router, který má wlan1 s adresou 192.168.12.150 a br-lan s adresou 192.168.91.1. Na wlan1 má nastavenou maškarádu. Má zapnutý RP filter a nemá zakázaný forward.
• Když na "útočníkovi" přidám routu 192.168.91.0/24 via 192.168.12.150 a napíšu ping 192.168.91.215, tak to normálně pingá, a když napíšu ssh 192.168.91.215, tak se normálně připojím.

[Miroslav Šilhavý]

b] Nekde vidis subnet 192.168.0.0/24? O nejake odpovedi nemuze byt rec. No a co, ze na to klient posle paket. Je to z LAN bloku neroutovelneho v netu zahodi to prvni router na ceste.

Pokud útočník sedí hned v segmentu za routerem (tedy zdánlivě "v netu"), tak se to tam odroutuje. Útok sice nemůže proběhnout z větší dálky (tam se to opravdu neodsměruje), ale když to bude Váš soused, tak říkajíc "na stejném switchi", tak má dveře otevřené.

rp_filter, některá mangle pravidla a forward prostě každý řeší něco jiného.
rp_filter lze nahradit manglem, je to aspoň částečné usnadnění (osobně preferuji nastavit to na mangle, nespoléhat se na to, že jiný sw nenastaví rp_filter na off nebo na loose)
jiná mangle pravidla nelze nahradit ničím jiním
forward nelze opomenout vůbec

[Filip Jirsák]

rp_filter lze nahradit manglem

Hodně odvážné tvrzení. Taky dejte chvilku studiu.

rp_filter, jak už název napovídá, je filtr – tedy zablokuje některé pakety.

mangle, podobně jako nat, slouží pro manipulaci s pakety – tedy k přepisu hodnot v hlavičkách paketu. Opět, název napoví. Konkrétně nat slouží pro manipulaci s adresami (Network Address Translation), mangle slouží pro manipulaci s dalšími údaji v hlavičkách, třeba QOS.

Pokud někdo firewallu nerozumí, jako Hamparle, mangle určitě nebude používat.

forward nelze opomenout vůbec

Jak jsem psal, firewall slouží pro zablokování nežádoucí komunikace, přičemž co je nežádoucí komunikace rozhoduje správce. Takže pokud neexistuje žádná nežádoucí průchozí komunikace, FORWARD se řešit nebude. Např. pokud bude zařízení plnit čistě funkci serveru (tedy nebude routovat) nebo čistě funkci routeru (bez firewallu).

[Miroslav Šilhavý]

mangle, podobně jako nat, slouží pro manipulaci s pakety – tedy k přepisu hodnot v hlavičkách paketu. Opět, název napoví. Konkrétně nat slouží pro manipulaci s adresami (Network Address Translation), mangle slouží pro manipulaci s dalšími údaji v hlavičkách, třeba QOS.

Pokud potřebujete určit, že na některém interface neočekáváte provoz v privátních rozsazích (RFC 1918), je mangle to pravé místo. To totiž není filtrovací pravidlo, ale základní sanitizace provozu. Tuto operaci nevyřeší ani rp_filter, ani FW filter. Na FW filtru už pracujete s adresami po překladu, takže tam už pravidlo nemůže zabrat (reagovalo by i na provoz, který tuto adresu získal NATEM). Samozřejmě, v mangle se řeší i ty další operace, jak jste psal.

[Filip Jirsák]

Pokud potřebujete určit, že na některém interface neočekáváte provoz v privátních rozsazích (RFC 1918), je mangle to pravé místo. To totiž není filtrovací pravidlo, ale základní sanitizace provozu. Tuto operaci nevyřeší ani rp_filter, ani FW filter. Na FW filtru už pracujete s adresami po překladu, takže tam už pravidlo nemůže zabrat (reagovalo by i na provoz, který tuto adresu získal NATEM). Samozřejmě, v mangle se řeší i ty další operace, jak jste psal.

Zdá se, že jste se neřídil svou vlastní radou, kterou jsem vám pro jistotu zopakoval.

Filtrování neočekávaného provozu na privátních rozsazích není podle vás filtrování, ale sanitizace provozu blokováním vadných paketů – tomu se ale jednoslovně říká filtrování.

Ve FORWARD pracujete s pakety, které už prošly PREROUTING, ale ještě neprošly přes POSTROUTING. V PREROUTING se dělá jen DNAT (nebo jeho speciální případ REDIRECT). Takže pokud vám přijde z internetu paket se zdrojovou IP adresou z RFC1918, zahodí ho buďto už rp_filter (pokud je to adresa z vaší vnitřní sítě), nebo ho můžete zahodit ve FORWARD (protože ta zdrojová IP adresa bude ještě nezměněná).

Dával jste sem odkaz na obrázek, jak paket putuje netfilterem. Tak si ho sám prostudujte a doplňte si tam, kde se dělá SNAT a kde DNAT.

[Hamparle]

a] Je tam maskarada, takze je uplne jedno co prijde z venku protoze netrackovane se to stejne zahodi.

Maškaráda se neuplatní, neboť se spojení nenavazuje skrz maškarádované rozhraní ven.

b] Nekde vidis subnet 192.168.0.0/24? O nejake odpovedi nemuze byt rec. No a co, ze na to klient posle paket. Je to z LAN bloku neroutovelneho v netu zahodi to prvni router na ceste.

Dobře, tak naprosto konkrétní příklad (doufám že to mám nakonfigurované správně, nechce se mi nastavovat lab od nuly, tak jsem to vyzkoušel na existující síti; pro info router je aktuální OpenWRT):

• LAN 192.168.91.0/24, v ní zařízení 192.168.91.215 "oběť"
• WAN 192.168.12.0/24, v ní zařízení 192.168.12.1 "útočník"
• Router, který má wlan1 s adresou 192.168.12.150 a br-lan s adresou 192.168.91.1. Na wlan1 má nastavenou maškarádu. Má zapnutý RP filter a nemá zakázaný forward.
• Když na "útočníkovi" přidám routu 192.168.91.0/24 via 192.168.12.150 a napíšu ping 192.168.91.215, tak to normálně pingá, a když napíšu ssh 192.168.91.215, tak se normálně připojím.

Zajímavé postřehy toto, ještě jsem to neměl čas vše vstřebat. (Jen na okraj, ten mangle jsem dal jako příklad, demonstrativní že chci v určité fázi zpracování paketu ho zahodit a vím že mangle a raw se zřídkakdy používají na běžné domácí firewallování.)

[Miroslav Šilhavý]

Takže pokud vám přijde z internetu paket se zdrojovou IP adresou z RFC1918, zahodí ho buďto už rp_filter (pokud je to adresa z vaší vnitřní sítě), nebo ho můžete zahodit ve FORWARD (protože ta zdrojová IP adresa bude ještě nezměněná).

rp_filter Vám zahodí jedině packet, který by přišel na interface a s adresou, která náleží jinému interface. Jenže on tam může přijít packet s RFC1918 adresou, kterou vůbec jinde na routeru nepoužíváte - tudíž rp_filter na tom nevidí nic podezřelého. Dokonce i odpověď na něj odejde ven, směrem k výchozí bráně. Jenže Vy víte, že z internetu nic z RFC1918 neočekáváte, proto se takovým packetem nechcete vůbec zabývat, chcete ho zahodit co nejdřív to jde.

Dále, rp_filter zahodí packety jen které kolidují s rozsahem na jiném interface. Jenže Vy ten rozsah můžete mít použitý hlouběji ve vnitřní síti (odroutovaný).

A poslední důvod je, že může dorazit "z internetu" packet, který nemá RFC1918 adresu jako destination, ale jako source. A ani to nechcete do sítě propustit, a za určitých nastavení se právě tato informace může ztratit díky DNATU, kterým to projde ještě před FORWARDEM.

Proto je rozumné tyto základní kontroly nastavit na mangle. Navíc to zpřehlední filter.