Stačí toto jedno pravidlo na NAT a ICS?

[Ħαℓ₸℮ℵ ␏⫢ ⦚ »]

V návodech k zprovoznění sdílení internetu se uvádí obvykle několik řádek iptables pravidel. V jiných vidím jen jednu řádku (první). Moc se v tom nevyznám, zajímalo by mě co dělají ty 2 zbylé řádky navíc.  Můj tip je, že druhá  řádka  zajišťujě dovnitř z "internetu" prošly jen  pakety, které  jsou "pronatované" zařízeními za natem při první cestě ven. Nicméně mi to nedává smysl, protože si myslím, že neprojdou tak jako tak a slouží to podle mě jen k tomu, že pakety budou zahozeny "dřív" ,jen nevím kde

Případně jsem něco možná přehlédl v nějakých souvisejících konfiguračních souborech, které třeba pak dělají ty ostatní řádky nadbytečnými.  A nebo skutečně  je první řádek NAT, zatímco zbylé  jsou kvůli samotné možnosti se připojit? .Pro přehlednost jsou řádky očíslované

Kód: [Vybrat]

#1# iptables -t nat -A  POSTROUTING -o internet0 -j MASQUERADE

#2# iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
#3# iptables -A FORWARD -i net0 -o internet0 -j ACCEPT
A platí, že v obou případech je nutná podmínka sysctl net.ip.ipv4_forward=1 ?


například pro nftables se uvádí jen "ekvivalent" prvního pravidla.

Kód: [Vybrat]

nft add rule nat postrouting oifname internet0 masquerade

[Reklama]

[Miroslav Šilhavý]

První pravidlo říká, že vše, co jde do internetu (tj. -o internet0) se má skrýt za IP adresou co je na interface internet0. Bez toho pravidla by tam šel packet s interní IP adresou a na internetu by nikdo nevěděl, kam má poslat odpověď.

Druhá dvě pravidla jsou firewallovací. To druhé říká, že z net0 do internet0 se má povolit provoz.
To první říká, že odkudkoliv kamkoliv (tedy i z internet0 - z internetu do net0 - LAN) se má povolit provoz, který je odpovědí na nějaký jiný packet. (Bez tohoto pravidla byste poslal sice požadavek do internetu, ale nikdy byste nedostal žádná data nazpět).

Ta druhá dvě pravidla mají smysl pouze v kombinaci s tím, že buďto má FORWARD nastavenou POLICY DROP, nebo by za nimi muselo následovat iptables -A FORWARD -j DROP. Pokud je POLICY ACCEPT a žádný DROP nenásleduje, pak jsou tyto dva řádky zbytečné.

On jako firewall svým způsobem slouží i ten MASQUERADE, protože zvenčí nikdo nemůže poslat do vnitřní sítě požadavek (zvenčí nejde adresovat nic vevnitř). Ale kdybyste neměl MASQUERADE, ale měl přidělenou spoustu veřejných IP adres, je FORWARD jediné místo, kde můžete provoz sanitizovat (týká se např. IPv6, kde se privátní IP adresy nepoužívají).

Ve skutečnosti dobře nastavený firewall má mít o mnoho více pravidel, aby síť fungovala opravdu dobře - ale toto je takový základ, který funguje.

[Filip Jirsák]

protože zvenčí nikdo nemůže poslat do vnitřní sítě požadavek (zvenčí nejde adresovat nic vevnitř)

Ale může a jde. Když na rozhraní internet0 přijde paket s cílovou IP adresou z vnitřní sítě, tak ho router prostě přepošle do vnitřní sítě. Ten router neví nic o tom, že vy něčemu říkáte vnější a vnitřní síť, on jenom přeposílá pakety tam, kam podle cílové IP adresy patří.

On jako firewall svým způsobem slouží i ten MASQUERADE

Takže neslouží.

Ve skutečnosti dobře nastavený firewall má mít o mnoho více pravidel, aby síť fungovala opravdu dobře - ale toto je takový základ, který funguje.

Ve skutečnosti síť nejlépe funguje bez firewallu – firewall nemůže fungování sítě zlepšit, protože jenom nějaký provoz blokuje. Dobře nastavený firewall povolí veškerý legitimní provoz a zablokuje ten nežádoucí. Nedá se říci, jestli dobře nastavený firewall má hodně pravidle nebo málo, to záleží na konkrétní situaci. Ona je totiž především nesmyslná představa, že existuje něco jako univerzální nastavení firewallu. Firewall má chránit nějakou konkrétní síť a musí být nastaven na míru tomu, co v té síti je provozované.

Pokud někdo nerozumí sítím, je víceméně zbytečné, aby nastavoval firewall. Prostě je jeho síť součástí internetu, je veřejná, a pokusy s firewallem na tom obvykle nic moc nezmění.

[Miroslav Šilhavý]

Ale může a jde. Když na rozhraní internet0 přijde paket s cílovou IP adresou z vnitřní sítě, tak ho router prostě přepošle do vnitřní sítě. Ten router neví nic o tom, že vy něčemu říkáte vnější a vnitřní síť, on jenom přeposílá pakety tam, kam podle cílové IP adresy patří.

Tomu brání spoof protection (rp_filter) na Linuxu, ale ano, ta může být vypnuta.
Na takto malformovaný packet se útočník nedočká odpovědi, takže míra rizika dramaticky klesá.

On jako firewall svým způsobem slouží i ten MASQUERADE

Takže neslouží.

Pokud vezmete výchozí nastavení v Linuxu, tak ano. Vysvětluju tím tazateli to, proč v příkladech jsou mnohdy forward pravidla vynechána.

Ve skutečnosti síť nejlépe funguje bez firewallu – firewall nemůže fungování sítě zlepšit, protože jenom nějaký provoz blokuje.

Ano, přesně tak. Více pravidel jen doplní víc chování čisté sítě, oproti tomuto nastavení.

Nedá se říci, jestli dobře nastavený firewall má hodně pravidle nebo málo, to záleží na konkrétní situaci. Ona je totiž především nesmyslná představa, že existuje něco jako univerzální nastavení firewallu.

Vskutku, univerzální nastavení neexistuje. Já bych třeba doplnil hned na začátek nastavení na rychlé zahození packetů s malformovanými hlavičkami (neplatné kombinace flagů), v rámci vnitřní sítě bych na TCP nenastavoval DROP, ale REJECT, na UDP a ICMP příslušné ICMP odpovědi - eliminují se tím timeouty zevnitř ven. Někdy je účelné REJECT povolit i zvenčí, ale tam už je to daleko víc diskutabilní, stejně jako na druhé straně tcp tarpitting. Někdy se povoluje REJECT ale s limitací odpovědí (pro "legitimní" omyly to pak funguje čistě, proti útokům to chrání). Dobrým síťařským zvykem je taky mít "nahoře" povolené echo reuqest a reply, aby se dalo v síti něco zjistit (a nemuselo se spoléhat na pozdější pravidla).

Pokud někdo nerozumí sítím, je víceméně zbytečné, aby nastavoval firewall. Prostě je jeho síť součástí internetu, je veřejná, a pokusy s firewallem na tom obvykle nic moc nezmění.

Souhlasím. Příklady na internetu jsou víc toxické, než prospěšné.

[Filip Jirsák]

Tomu brání spoof protection (rp_filter) na Linuxu, ale ano, ta může být vypnuta.
Na takto malformovaný packet se útočník nedočká odpovědi, takže míra rizika dramaticky klesá.

Vidíte někde ve svém textu zkratku NAT? Nevidíte, správně. Takže NAT s tím nemá co do činění.

Vysvětluju tím tazateli to, proč v příkladech jsou mnohdy forward pravidla vynechána.

Ale vysvětlujete to špatně. FORWARD pravidla jsou při vysvětlování NATu vynechána proto, že s NATem nijak nesouvisí. V Linuxu se NAT konfiguruje stejným příkazem, jako firewall, je to stejný kód jádra, ale jsou to dvě různé věci. NAT provádí překlad adres, firewall filtruje (blokuje) síťový provoz. Každé to má jinou funkci a může to stát zcela samostatně – můžete používat jenom NAT nebo jenom firewall.

[Reklama]

[Miroslav Šilhavý]

Ale vysvětlujete to špatně. FORWARD pravidla jsou při vysvětlování NATu vynechána proto, že s NATem nijak nesouvisí. V Linuxu se NAT konfiguruje stejným příkazem, jako firewall, je to stejný kód jádra, ale jsou to dvě různé věci. NAT provádí překlad adres, firewall filtruje (blokuje) síťový provoz. Každé to má jinou funkci a může to stát zcela samostatně – můžete používat jenom NAT nebo jenom firewall.

To si myslím, že je pro začátečníka těžké k pochopení. Dobré je na Google dohledat "packet flow in linux", třeba přes obrázky. Tam jsou pak schémata, jak teče packet přes bridge, nat, mangle, filter... Nebo i na Mikrotik.com je hezky packet flow (Mikrotik = Linux, takže to víceméně odpovídá).

Asi bych to zjednodušil, že bezpečnost se dělá na filtru (INPUT, FORWARD, OUTPUT). Na natu ji lze taky částečně suplovat - nejen v kombinaci s rp_filter, ale třeba při překladu dovnitř, kdy se specifikují jen otevřené porty. Ale i v tom případě je správně mít odpovídající pravidlo na FORWARDU (pochopí každý, kdo směruje víc než dva směry).

BTW linuxové packet flow i firewall jsou neuvěřitelně univerzální, ale je to dvousečná zbraň. Bez poměrně dobrého pochopení nelze firewall vystavět. Já třeba nedělám se sítí žádné moc velké opičárny a daleko víc mi vyhovuje PF v BSD. Taky je pravdou, že neuznávám kombinování serverů na routeru (DNS, DHCP atd.), které dost značně komplikují pravidla (potřeba je zdvojit, ztrojit atd.). Naopak za velmi šikovné považuji VRF (Virtual Routing and Forwarding), ale to se zrovna v internetových kuchařkách moc nenosí.

[Ħαℓ₸℮ℵ ␏⫢ ⦚ »]

Děkuji za odpovědi, už jsem to pochopil i z první odpovědi že samotný nat je pravidlo 1 a že zbytek je politka povolení/zakázní trafficu -  že forward pravidla hrají roli jen když je defaultní chování Blokovat traffic. A že vlastně pravidlo s conn_track(#2#)  je závislé na #3#, samotné pravidlo #2# by nedávalo smysl, neboť bez odchozího trafficu by žádné otevření spojení nevzniklo.

> Paket s cílovou adresou z vnitřní sítě
Na takto malformovaný packet se útočník nedočká odpovědi, takže míra rizika dramaticky klesá.

Nedočká se z důvodu rp_filter, která je standardně(nebo to tak někdo předpokládá) zapnutá? I za předpokladu že policy je accept? (to je asi hloupá otázka jelikož pravidlo č.#3#  by odchod paketu tak jako tak povolilo). Samozřejmě za předpokladu, že vnitřní počítač na něj odpoví.

Ty diagramy flow jsou v několika variantách a 2 co jsem  našel jsou tedy celkem složité (takový kaskádový graf) a druhá komplexní graf, rozdělený do aplikační/transportní/síťové vrstvy (oba barevné)
Naopak z tohoto je to celkem zřejmé.

[Miroslav Šilhavý]

Nedočká se z důvodu rp_filter, která je standardně(nebo to tak někdo předpokládá) zapnutá? I za předpokladu že policy je accept? (to je asi hloupá otázka jelikož pravidlo č.#3#  by odchod paketu tak jako tak povolilo). Samozřejmě za předpokladu, že vnitřní počítač na něj odpoví.

Trochu jinak. Filip psal o podvrhnutí zdrojové IP adresy. Tedy že někdo zvenčí (z internetu) pošle na Váš router packet, který se bude jevit jako (např.) 192.168.0.55 => 192.168.0.68. Ale to jsou interní adresy, správně by takový packet vůbec neměl přijít, ale nešť, stát se to může. Co udělá router? Předá ho z internet0 na net0 a tam dorazí na počítač .68. Ten na packet odpoví, ale komu odpoví? Odpoví počítači .55, který byl podvržený jako zdrojová adresa. Ta odpověď se už zpět na router vůbec nedostane.

Takové packety mohou sloužit např. k DoS útoku. Nebo pošlete naslepo do sítě UDP datagram, který něco vykoná (typicky ovládací povel nějaké automatizace apod.) - tam nepotřebujete žádnou odpověď dostat a přesto to může uškodit.

RP filtr slouží k tomu, že se takový packet vůbec nedostane ze špatného interface dovnitř. Tedy, že 192.168.x.x může přijít jedině z net0. Pro základní použití je RP filtr užitečný, ale jsou situace, kdy je potřeba vypnout - a v tu chvíli už musíte vědět, co děláte a zabezpečit si to na firewallu.

[Filip Jirsák]

Na natu ji lze taky částečně suplovat - nejen v kombinaci s rp_filter, ale třeba při překladu dovnitř, kdy se specifikují jen otevřené porty.

Ne, nemůžete dávat do jednoho textu „pro začátečníky“, „pro jednoduchost“ a „NAT supluje bezpečnost“. Pro začátečníky a pro jednoduchost můžete napsat nanejvýš to, že NAT nezajišťuje vůbec žádné zabezpečení. To, že když víte, co děláte, můžete NATem útočníkovi trochu komplikovat život, začátečníkovi vůbec říkat nemáte, protože ho tím nanejvýš zmatete.

Trochu jinak. Filip psal o podvrhnutí zdrojové IP adresy.

Nikoli, routuje se na základě cílové adresy. rp_filter jste do toho zamotal vy, nijak s tím nesouvisí.

Tedy že někdo zvenčí (z internetu) pošle na Váš router packet, který se bude jevit jako (např.) 192.168.0.55 => 192.168.0.68. Ale to jsou interní adresy, správně by takový packet vůbec neměl přijít, ale nešť, stát se to může.

Jsou to adresy, které nejsou routovatelné v globálním internetu. V síti ISP klidně putovat můžou, takže na rozhraní vašeho routeru se takový paket klidně může dostat zcela legálně, nemusí to být žádná podvržená adresa.

Co udělá router? Předá ho z internet0 na net0 a tam dorazí na počítač .68. Ten na packet odpoví, ale komu odpoví? Odpoví počítači .55, který byl podvržený jako zdrojová adresa. Ta odpověď se už zpět na router vůbec nedostane.

To ale pořád předpokládáte zfalšovanou zdrojovou IP adresu. Nevím, proč jste si vymyslel zrovna takovýhle divný případ. Aby paket prolezl tím routerem, musí mít cílovou IP adresu z té domácí sítě. Zdrojovou adresu může mít úplně libovolnou, a odpověď pak půjde na tuhle adresu. Takže jediný problém je jak zařídit, aby paket s tou správnou cílovou adresou dorazil až na rozhraní toho domácího routeru. Obecně v internetu je to samozřejmě problém, protože to je adresa, která není globálně routovatelná. Ale víte, jak přesně se bude chovat síť ISP? Víte, co se stane, když takový paket odešle soused, který je na stejném segmentu sítě nebo na stejném WiFi sektoru?

RP filtr slouží k tomu, že se takový packet vůbec nedostane ze špatného interface dovnitř. Tedy, že 192.168.x.x může přijít jedině z net0. Pro základní použití je RP filtr užitečný, ale jsou situace, kdy je potřeba vypnout - a v tu chvíli už musíte vědět, co děláte a zabezpečit si to na firewallu.

RP filtr slouží k tomu, že paket přijde z té samé sítě, kam by měla být odeslána odpověď na něj. Řeší tedy pakety s podivnou zdrojovou IP adresou, přičemž k prostřelení NATu je potřeba naopak vhodná cílová IP adresa.

[Filip Jirsák]

Děkuji za odpovědi, už jsem to pochopil i z první odpovědi že samotný nat je pravidlo 1

Ano.

zbytek je politka povolení/zakázní trafficu

Ano.

forward pravidla hrají roli jen když je defaultní chování Blokovat traffic.

Ne tak docela. Pravidla se procházejí jedno po druhém, když nějaké vyhoví, provede se nastavený cíl a zpracování skončí. Když nevyhoví žádné pravidlo, použije se výchozí chování řetězce. Můžete mít tedy třeba pravidla 1. povol vše z mé IP adresy, 2. zakaž vše příchozí na port 22, výchozí pravidlo je akceptuj. Výchozí chování tedy je akceptace provozu, přesto jste provoz na port 22 z jiných IP adres než z vaší zakázal.

A že vlastně pravidlo s conn_track(#2#)  je závislé na #3#, samotné pravidlo #2# by nedávalo smysl, neboť bez odchozího trafficu by žádné otevření spojení nevzniklo.

Ano, je to typické nastavení firewallu. Řeknete, že všechny pakety, které souvisí s něčím, co už jste zkoumal, se mají propustit. Tohle pravidlo se nikdy nepoužije hned na začátku komunikace, logické by bylo dávat ho až na konec, ale dává se na první místo, protože mu vyhoví největší počet paketů a už se pak nemusí procházet další pravidla. A teprve za tohle pravidlo dáváte další pravidla, která se aplikují jen na pakety, které navazují spojení. A vycházíte z toho, že když neprojde paket navazující spojení, nemohou přijít ani žádné pakety, které s tím spojením souvisí.

Nedočká se z důvodu rp_filter, která je standardně(nebo to tak někdo předpokládá) zapnutá?

Motají se tu dohromady tři věci. Každá z nich může ovlivnit, zda nějaký paket projde a v jaké podobě, ale každé je to něco jiného. NAT jenom překládá adresy. Jako když vám do firmy bude chodit pošta pro slečnu Novákovou, ale na podatelně budou vědět, že se vdala a přepíšou to na obálce na paní Zemanovou. A když si zlý útočník venku zjistí, že se vdala a pošle dopis rovnou paní Zemanové, na podatelně s tím nic dělat nebudou a normálně to pošlou dál. Druhá věc je firewall, ten podle zadaných pravidel blokuje nějaké pakety. Např. že panu řediteli smí posílat dopisy jen pan majitel a nikdo jiný, a údržbář smí posílat dopisy jenom do železářství a do truhlárny a nikam jinam. Třetí je RP filtr, který kontroluje to, že když dopisy do Brna posíláte autem po D1 a dopisy do Plzně autem po D5, tak zase dopisy z Brna musí přijet autem po D1 a dopisy z Plzně autem po D5. A pokud autem po D5 přijede dopis, na kterém je napsáno, že je z Brna, tak ho zahodíte, protože tudy neměl přijet a je něco špatně. To samé se dá nastavit i na firewallu, ale RP filtr je mnohem jednodušší a můžete ho použít i tehdy, když žádný firewall nepoužíváte.

[Miroslav Šilhavý]

Tohle pravidlo se nikdy nepoužije hned na začátku komunikace, logické by bylo dávat ho až na konec, ale dává se na první místo, protože mu vyhoví největší počet paketů a už se pak nemusí procházet další pravidla. A teprve za tohle pravidlo dáváte další pravidla, která se aplikují jen na pakety, které navazují spojení. A vycházíte z toho, že když neprojde paket navazující spojení, nemohou přijít ani žádné pakety, které s tím spojením souvisí.

Toto je o návycích a konečně i o typu firewallu.

Např. PF (BSD) na navazující packety netvoří extra pravidlo - pokud chcete statefull vyhodnocení, přidáte do pravidla keep / modulate / synproxy state a zbytek už řeší firewall sám. To je třeba daleko šikovnější, přehlednější na správu. Vím, která spojení chci jen propustit, která modulovat a která synproxovat. V Linuxu to nastavuji daleko složitěji, ale zase můžu detailněji. Je to náchylnější na konfigurační chybu, když specialitky nevyžaduji.

Est, rel je na druhou stranu k ničemu mít nahoře, pokud potřebujete vyhodnocovat limity.

Jsou spojení, která mohu zpracovávat stateless. Typicky je to třeba management v zabezpečené síti. Jedno pravidlo propustí ssh dovnitř, druhé odpovědi ven. DNS taktéž. Výhodou stateless je zvýšení spolehlivosti při (re)konfiguracích, lze pak flushovat conntrack aniž by se rozpadlo ssh. Obecně považuji za lepší snižovat tlak na conntrack, když to jde. (A to, jestli to jde a jde bezpečně, už vyžaduje hlubší znalosti).