Počítač se zapnutým forwardingem opouští pakety do cíle 10.0.0.0

[Hamparle]

Z jakého důvodu počítač v roli routeru (linux, ipv4.forwarding=1) opouští pakety s cílovou adresou 10.0.x.x do upstream sítě, když má vnitřní síť je 192.168.1.0/24  a upstream síť 192.168.2.0/24? Probíhá NAT na 192.168.2.99.

Brána providera vrací ICMP unreachable.  Tyto pakety (když už by neměly opouštět upstream síť) , což se neděje, tak nechci aby opouštěly mou síť . Je nějaký usecase, kdy je komunikace do privátních sítí legitimní (Samozřejmě kromě případů, že sám počítač do té sítě náleží)?

Nemá tomuto jádro zabránit bez explicitních pravidel ve firewallu, jelikož jde o privání rozsahy? Nebo je k tomuhle nějaký podobný flag v sysctl.net.* jako rp_filter?


Je lepší to řešit pomocí iptables -I FORWARDING -d 10.0.0.0/8 -j REJECT nebo ip route add blackhole 10.0...?.

[Reklama]

[Filip Jirsák]

Z jakého důvodu počítač v roli routeru (linux, ipv4.forwarding=1) opouští pakety s cílovou adresou 10.0.x.x do upstream sítě, když má vnitřní síť je 192.168.1.0/24  a upstream síť 192.168.2.0/24? Probíhá NAT na 192.168.2.99.

Buď takové pakety generuje nějaký proces na tom routeru, nebo na něj přicházejí z nějaké sítě, ke které je připojen.

Brána providera vrací ICMP unreachable.

To je správně.

Tyto pakety (když už by neměly opouštět upstream síť) , což se neděje, tak nechci aby opouštěly mou síť .

Upstream síť je síť ISP. Vy jste to na začátku psal opačně – ty pakety jdou z vaší sítě do sítě ISP.

Je nějaký usecase, kdy je komunikace do privátních sítí legitimní (Samozřejmě kromě případů, že sám počítač do té sítě náleží)?

Kdykoli, kdy existuje nějaká cesta do takové privátní sítě. To může být např. přes VPN nebo přes nějakou jinou síť. Ale nebude to váš případ.

Nemá tomuto jádro zabránit bez explicitních pravidel ve firewallu, jelikož jde o privání rozsahy?

Ne, musíte si na to nastavit sám pravidla ve firewallu. Jádro neví, jak vypadá vaše síť.

Nebo je k tomuhle nějaký podobný flag v sysctl.net.* jako rp_filter?

Ne.

Je lepší to řešit pomocí iptables -I FORWARDING -d 10.0.0.0/8 -j REJECT nebo ip route add blackhole 10.0...?.

Spíš to první. Případně, pokud nechcete odesílatele informovat, můžete místo REJECT použít DROP. Blackhole by se použilo někde na páteřní síti v případě, že by ten provoz byl tak silný, že byste se ho potřeboval co nejefektivněji zbavit – což nebude váš případ s počítačem v roli routeru.

[Miroslav Šilhavý]

10.x.x.x je pro router neznámá adresa, a tak ji zcela přirozeně předává na výchozí bránu.
Na interních rozhraních je dobré filtrovat jaké IP adresy očekáváte - tj. jen adresy použité ve vnitřních sítích.
Na externím rozhraní musíte naopak filtrovat, jaké IP adresy neočekáváte - tj. RFC1918.

Když už v tom budete, je samozřejmě na místě sanitizovat i další situace - např. nevalidní kombinace TCP flagů, nebo, pokud to jde, tak naopak vyjmenovat validní.

Správná reakce je REJECT (ale podle protokolu se liší, jaký typ rejectu odesíláte). Nicméně na externí lince by se mohlo stát, že při útoku jen zesílíte důsledky tím, že linku zahltíte o to víc tím, že rejecty odesíláte. Buďto se pak limituje počet rejectů (a následně se provádí DROP), nebo jen dropujete. Pokud chcete zpomalit TCP útoky, můžete použít TARPIT (ble, ale funguje). Do interní sítě bych preferoval REJECT nad DROP zcela určitě (i když výjimky z tohoto pravidla se taky najdou).

Nevýhoda linuxu a čistých iptables / nftables je to, že kvůli univerzalitě musíte každý sofistikovanější úkol (jako je třeba toto) řešit na více místech, hlídat si vše ručně je náchylné k chybě. Nebylo by jednodušší použít Shorewall? Ten poměrně hodně takovýchto věcí nastaví podle konfigurace a dá se i hodně přizpůsobit. Matlat to v čistých (ip|nf)tables je peklo.

Ip route blackhole bych nepoužíval, je to nepohodlné a nezapadá to do konceptu firewallu jako takového.

[Hamparle]

Na interních rozhraních je dobré filtrovat jaké IP adresy očekáváte - tj. jen adresy použité ve vnitřních sítích.
Na externím rozhraní musíte naopak filtrovat, jaké IP adresy neočekáváte - tj. RFC1918.

Můžeš to rozvést? To vypadá jako chytrá myšlenka.
na "interních rozhraních"  očekávám, že src ip je z mé sítě. dst ip může  kamkoli
a
na "externím rozhraní" neočekávám , že dst ip by byla 192.168.2.0 (speciálně zvlášť uvádím), privátní rozsahy: 192.168.0.0(sem spadá i to předtím),  dále 10.0.0.0, 172.16., 100.64 A také že SRC by byla 192.168.1.0 (moje síť)

Pravidla ovšem mají jak -i, tak -o, a kromě -src i -dst.  Je to takhle kompletní? Tedy filozofie : externí  = "blacklist" v směru dst ip neočekávám privátní rozsahy a v směru  src neočekávám moji síť; interní="whitelist"= směr src pouze. Jelikož dst zde nedává logiku


 Co když používám pravidla která mají -i  + -o zároveň? (jelikož router má 2 interface ). Je to dobrá věc nebo zbytečná komplikace

[Miroslav Šilhavý]

@Hamparle

Předně bych počítal, že router může mít víc než dva interface. Ať už fyzické, nebo i jiné. Tím mám na mysli např. VPN, tunely, VLAN. Pravidla bych si tvořil dopředu tak, jako kdyby byla rozhraní tři, čtyři - je to lepší na představivost.

Teď začneme u záludnosti s NATEM. Na FORWARDU už u packetu uvidíte adresu po DNAT překladu. Takže na FORWARDU už nerozlišíte, jestli packet -o interni -dst 192.168.x.x takto přišel z internetu, nebo tu adresu získal až překladem. Ověření, jestli dst/src odpovídají tomu, co se očekává na interfacu musí přijít do místa, kde se s tím dá pracovat.

Kolegové mě opraví, nemám to před sebou, ale myslím, že je to nějak takto:
1) kontrola src vůči vstupnímu interface patří do raw/prerouting
2) kontrola dst vůči výstupnímu interface patří na dvě místa: filter/output + filter/forward

Osobně bych tyto kontroly nascriptoval, aby se příslušná pravidla vygenerovala, protože ta samá pravidla v obdobách patří do vícero míst.

Teprve po nich bych zpracovával pravidla pro filtrování provozu - tedy co kam smí a co kam nesmí. Jestli používat -i, -o, -src, -dst záleží na směru (a dalších okolnostech). Např. povolení provozu směrem ven z routeru bych řešil -src 192.168.x.x/24 -o vystupni_interface -j ACCEPT a naopak přesměrování portů dovnitř pomocí -i -dst.

Ku pomoci jsou chainy. Do chainu nasměrujete např. veškerý provoz z internetu dovnitř (pomocí -i), ale uvnitř chainu už můžete pracovat jen s -dst.

Metod je spousta, a těžko se radí, protože to záleží na situaci i gustu každého.

Znovu opakuji, nevynalézejte kolo, na toto jsou hotová řešení, kde si jiní lámali hlavu za Vás.

[Reklama]

[Filip Jirsák]

Kolegové mě opraví, nemám to před sebou, ale myslím, že je to nějak takto:
1) kontrola src vůči vstupnímu interface patří do raw/prerouting
2) kontrola dst vůči výstupnímu interface patří na dvě místa: filter/output + filter/forward

Nikoli, veškeré blokování provozu patří do tabulky filter. Průchozí provoz se kontroluje ve FORWARD, provoz z/na router v OUTPUT/INPUT.

[Miroslav Šilhavý]

Nikoli, veškeré blokování provozu patří do tabulky filter. Průchozí provoz se kontroluje ve FORWARD, provoz z/na router v OUTPUT/INPUT.

O tom se budu hádat. Tam už nerozlišíte dst před NATEM.
Sanitizace není filtrování v pravém slova smyslu, to je z pohledu routeru-firewallu nevalidní provoz a do reálných pravidel se ani dostat nemá.

Přiznávám, že to je z části filozofická otázka.

[Filip Jirsák]

Pravidla ovšem mají jak -i, tak -o, a kromě -src i -dst.  Je to takhle kompletní? Tedy filozofie : externí  = "blacklist" v směru dst ip neočekávám privátní rozsahy a v směru  src neočekávám moji síť; interní="whitelist"= směr src pouze. Jelikož dst zde nedává logiku

Musíte vědět, v jaké síti je váš router. Pokud je to ten nejjednodušší případ, máte router připojen do internetu a router má na svém vnějším rozhraní veřejnou IP adresu, router je tedy připojen do skutečného internetu. Pak se IP adresy z privátních rozsahů nemohou objevit u paketů z internetu ani v src ani v dst (ani pro INPUT ani pro FORWARD). Jedinou výjimkou by byl váš privátní rozsah v dst ve FORWARD, pokud byste používal DNAT (např. přesměrování portu z veřejné IP adresy do vnitřní sítě).

U paketů z vnitřní sítě se nesmí žádný privátní rozsah objevit v dst (pokud router propojuje jen vaši jednu privátní síť s internetem), v src bude jenom privátní rozsah z vaší sítě, ostatní také budete blokovat. Váš privátní rozsah v src je v pořádku, protože se následně v POSTROUTINGu aplikuje SNAT. Pakety, které vznikají na vašem routeru (INPUT) jako dst nemohou mít privátní rozsahy mimo ten, který používáte ve vaší interní síti.

Co když používám pravidla která mají -i  + -o zároveň? (jelikož router má 2 interface ). Je to dobrá věc nebo zbytečná komplikace

Mezi dvěma sítěmi (místní a internet) se to moc nepoužívá, protože obvykle na hranicích těch sítí zkontrolujete, že jde o povolený provoz z/do té sítě, a pak už mezi těmi sítěmi chcete povolit vše. Ale pokud byste měl sítí víc (a každou na samostatném rozhraní), dávají taková pravidla smysl – někdy budete chtít mezi různými sítěmi povolit různý provoz. Hodně primitivní příklad z dávných dob je ten, že do demilitarizované zóny povolíte z interní sítě přístup přes SSH, ale z internetu ne.

[Filip Jirsák]

O tom se budu hádat. Tam už nerozlišíte dst před NATEM.

Místo hádání si raději nastudujte průchod paketu netfilterem. Obrázek jste sám nedávno linkoval.

Sanitizace není filtrování v pravém slova smyslu, to je z pohledu routeru-firewallu nevalidní provoz a do reálných pravidel se ani dostat nemá.

Filtrování je blokování nevalidního provozu. Není rozdíl v tom, jestli paket zahodíte proto, že víte, že zařízení s cílovou IP adresou ve vaší síti není, nebo proto, že víte, že služba na cílovém portu není ve vaší síti poskytována ven. Například.

[Hamparle]

Tyto pakety (když už by neměly opouštět upstream síť) , což se neděje, tak nechci aby opouštěly mou síť .

Upstream síť je síť ISP. Vy jste to na začátku psal opačně – ty pakety jdou z vaší sítě do sítě ISP.

Na začátku jsem to psal správně. Myslel jsem to tak, že nejenže (z nějakýho stroje v mé síti) projdou mým routerem, který této síti šefuje, ale že dál  poté projdou ještě dalším routerem až pak teprv jsou v síti providera.


Můj router nemá veřejnou adresu, ale je za ním ještě další router a pak nějaká interní síť poskytovatele (10.*) a pak teprv je tam veřejná adresa.
Na prerouting se nedá dělat filtrování DROP/REJECT.

Ta poznámka s  nerozlišitelností ip adresy na FORWARD  je cenná, když ji budu vést v patrnosti, půjdou ty filtry konstruovat  lépe od ruky.

[Filip Jirsák]

Ta poznámka s  nerozlišitelností ip adresy na FORWARD  je cenná, když ji budu vést v patrnosti, půjdou ty filtry konstruovat  lépe od ruky.

V patrnosti byste měl vést především to, že ta poznámka s nerozlišitelností IP adresy ve FORWARD je nesmyslná. Pokud nebudete s pakety dělat nějaké nestandardní prostocviky, budete mít ve FORWARD takové IP adresy, aby se vám s tím dobře pracovalo. Ony ty řetězce PREROUTING a POSTROUTING a to, že v prvním se dělá DNAT a v druhém SNAT, nevymýšlel žádný hlupák.

Všimněte si, že Miroslav Šilhavý uvedl jediný příklad, kdy by měl ve FORWARDu problém – že nerozliší dst po DNATu. U typického případu, kdy máte jedno privátní síť připojenou přes jednoho ISP, ale nic takového rozlišovat nepotřebujete. DNATem uděláte portforwarding jedné veřejné IP adresy na jednu privátní, a ve FORWARDu tedy bude pracovat s tou privátní. Narazit byste na to mohl reálně tehdy, pokud byste měl dva ISP a veřejnou IPv4 adresu od každého z nich směrovat na jeden cílový server. Jenže pak zase nebudete ve FORWARDu potřebovat rozlišit, přes kterého ISP paket původně přišel. Pokud tam bude nějaká služba, obvykle budete mít tohle zapojení právě proto, aby byla dostupná přes oba ISP. A kdybyste náhodou chtěl některé služby vystavit přes oba ISP a některé jen přes jednoho, prostě na té službě budete dělat DNAT jenom na jednom rozhraní.

[neregistrovany]

Ip route blackhole bych nepoužíval, je to nepohodlné a nezapadá to do konceptu firewallu jako takového.

blackholing nema s firewallem nic spolecneho, ten se tyka routingu.