Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Pavouk106 15. 04. 2014, 22:15:24
-
Jak už někteří vědí, bojuju doma s routerem Turris. Potřebuju teď nasekat pár přesměrování portů, ale zatím jsem byl políben pouze Mikrotiky a tam je to jednoduchoučké.
Teď teda začínám jako nepolíben s iptables. V přiloženém obrázku je "nákres sítě" a já teď vysvětlím o co jde a co se mi nezdá. Turris má IP přidělenou Mikrotikem 192.168.3.244 a na vnitřní podsíti má IP 192.168.2.254.
Používám pravidlo:
iptables -t nat -A prerouting_rule -i eth2 -p tcp --dport 22 -j DNAT --to 192.168.2.183
Z PC 192.168.3.1 se připojuju na SSH na IP 192.168.3.244 (router WAN) a tam jsem směrován na počítač v podsíti routeru s IP 192.168.2.183. To funguje.
Když ale předělám pravidlo na:
iptables -t nat -A prerouting_rule -i eth2 -p tcp --dport 22 -j DNAT --to 192.168.1.1
V podsíti routeru není PC s IP adresou 192.168.1.1 (v budoucnu bude) a router mě teď směruje někam k zařízení od ISP. To je nežádoucí, já bych očekával, že router bude směrovat jen do podsítě a ně někam do pryč.
Jak mám uděla iptables pravidlo tak, aby router pakety posílal jen a pouze do podsítě a ne někam libovolně po celé síti?
-
Diagram je sice hezký, ale bez masek sítí tak trochu k ničemu. Jak pak máme vědět do které sítě spadá adresa 192.168.1.1 a jak tam asi budou nastaveny routy. Doplň masky sítí a výpisy routovacích tabulek. Tipoval bych, že 192.168.1.1 bude směrováno defaultními routami, tedy k ISP.
-
Při čmárání a čumění na routy mi to došlo. Routy vedou k zařízení ISP, proto to tam router cpe. Podsíť v podsíti se stejným rozsahem je hovadina a pokud jde zroutovat do správnýho chování, tak to nebude jednoduchý na nastavení.
Nicméně původní dotaz měl znít, jak/jestli jde udělat iptables pravidlo, který pošle paket buď do vnitřní sítě, nebo nikam (reject nebo drop).
Pokud bych to měl říct na příkladu:
iptables -t nat -A prerouting_rule -i eth2 -p tcp --dport 22 -j DNAT --to nějaká.veřejná.ip.adresa
To by vlastně mělo fungovat v pohodě, přehodit mě na veřejnou IP (a to se taky stalo). Já bych ale chtěl to pravidlo udělat tak, aby ke spojení nedošlo, protože ta veřejná IP adresa není ve vnitřní síti LAN. Asi tu řeším blbosti...
-
Treba dropovat FORWARD...
A pre tento pripad pridat forward aj s -o ethX, kde ethX je interface vnutornej siete.
-
A pre tento pripad pridat forward aj s -o ethX, kde ethX je interface vnutornej siete.
tohle bych nedelal, tohle odrizne vsechen forward smerem ven (coz asi nechces)
videl bych to spis na -A FORWARD -i wan -o wan -j DROP
ale uprimne, jeste sem nic takoveho nepouzil
apropo, mikrotik pouziva iptables, z jejich pravidel se daj udelat iptables pravidla celkem primo
-
Do tabulky nat se dávají jenom pravidla, která natují - mění procházející pakety. Pravidla pro to, který provoz má projít a který zakázat, se dávají do tabulky filter (je defaultní, takže stačí bez -t nat), konkrétně pokud jsou to procházející pakety (nepochází z routeru nebo na něm nekončí), je to chain FORWARD. Tam můžete nastavovat pravidla podle zdrojových či cílových adres nebo podle rozhraní.
iptables -A FORWARD -i wan -o lan -j ACCEPT
iptables -A FORWARD -i lan -o wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -P FORWARD DROP
Třeba předchozí sada pravidel:
- Povolí vše, co prochází ze síťovky wan na síťovku lan
- Povolí vše v opačném směru, co souvisí s existujícími spojeními
- Vše ostatní (procházející) zahodí
Tahle sada pravidel nedovolí navázat spojení z vnitřní sítě ven. Většinou se teda používá přesně opačná konfigurace routeru...
Mimochodem, není tohle umístění proti pravidlům použití Turrisu? Měl by být hlavním přípojným bodem k internetu, ne?
-
Také bych něco podobného tušil, takhle by od tebe moc dat nenasbírali...
-
Eh ... to neni o znam mikrotika ... to je o ... nemam tuseni jak site fungujou. Ten router (zcela korektne) preda ten paket na default routu, protoze sit 192.168.1 ... vubec NEZNA. Vazne mevim pro vymejslis takovy brikule, ale pokud uz potrebujes uvnitr dve site ... je ti to bez fyzickyho oddeleni (nebo vlan) celkem nanic. Ale nejjednodussi varianta je pridat internimu rozhrani dalsi IPcko typu 192.168.1.x/24 (predpokladam, ze pouzivas Cckovy subnety).
Jinak double nat ... potes koste, to ti bude vitecne fungovat ...
-
Ahoj, nechci tady rozpoutávat flamewar, ale od té doby, co sem zkusil pf firewall, se k iptables už nevrátím (akorát, že BSD licence není slučitelná S GPL, takže se jej v Linuxu asi nikdy nedočkám). Ale kdyby existovala verze Turrisu s BSD, tak bych do ni šel.
-
Filip Jirsák: Ano, je to proti pravidlům. Nicméně na umístění, které jsem popsal CZ.NIC se dostanu nejdřív teď v neděli. Proto se snažím na tom routeru udělat co můžu, abych to pak jen převezl, připojil a už na to nemusel moc sahat (protože se víceméně hned po připojení otáčím a zase mizím). Proti pravidlům by taky bylo nespustit router do 14 dní od převzetí (to bych stíhal), pořád si ale říkám, že tomu radši dám pár dnů za NATEM a přiležitost to nastavit, než to nahodit na pravym umístění po 10 dnech od převzetí a pak nemít ani možnost to nastavit jak potřebuju. Router bude na relativně hezkym místě (na sběr statistik), myslím, že týden za NATem pak bohatě vynahradí ;-)
Jimm: Platí co jsem napsal na Filipovo reakci. Budu o tom psát i na blogu, ale to až bude router na svém místě. Obohatím to pak nejspíš i o statistiky.
j: Ano, nemám páru, jak to funguje. Všechno se totiž učím až za běhu, když něco potřebuju udělat/nastavit. Pochopil jsem ovšem, že Turris nemá o podsíti 192.168.1.0/24 ani páru a jen se to postupně přes routy všech zařízení dostane až k ISP. Doubla NAT to nebude. Víceméně by to byl teď, pokud bych to tak nahodil, ale v budoucím umístění nebude.
Vlastně se mi iptables jen chovaly nelogicky (z mýho neznalýho pohledu), přitom ale dělaly přesně to, co měly...
-
A pre tento pripad pridat forward aj s -o ethX, kde ethX je interface vnutornej siete.
Tak ratal som s tym ze ked sa jedna o firewall admina, z dlhodobeho hladiska bude pouzivat skor policy drop ako accept, pripadne mat pravidlo co dropuje vsetko (co pred tym nebolo acceptnute).
Preto by som odporucal hned na zaciatku NEvymyslal co dropovat (blacklisting sa malokedy osvedci), ale radsej budem vymyslat co acceptnut.
-
Tak ratal som s tym ze ked sa jedna o firewall admina, z dlhodobeho hladiska bude pouzivat skor policy drop ako accept, pripadne mat pravidlo co dropuje vsetko (co pred tym nebolo acceptnute).
Preto by som odporucal hned na zaciatku NEvymyslal co dropovat (blacklisting sa malokedy osvedci), ale radsej budem vymyslat co acceptnut.
Podle mne jsou počítače připojené k internetu zpravidla pro to, aby přes internet mohly komunikovat. Ideální stav je, kdy je počítač připojen do internetu přímo bez nějakého firewallu. Spuštěné jsou jenom ty služby, které má daný počítač poskytovat, tyto služby jsou bezpečné, a klienti používaní na tom počítači jsou také bezpeční, takže není nutné hlídat podezřelou odchozí komunikaci. V takovém ideálním světě nežijeme, proto se před síť dává firewall, ale ten by měl (v případě běžné domácí sítě) akorát zalepit ty díry, které zatím nejsou zalepené na počítačích v síti. Nemyslím si, že je správné, aby administrátor musel rozhodovat o každém jednotlivém typu komunikace a extra ji povolovat. Zvlášť když v mnoha případech ani není možné popsat ji pomocí kombinace IP adres a portů, protože se tyhle parametry určují náhodně.
Takže já jsem pro výchozí pravidlo accept a zakazovat jenom to, co určitě škodí.
-
Tak já to mám (alespoň v hlavě; těžko říct, jak to je v routeru, to by na to musel mrknou někdo znalý) tak, že router/firewall standardně neblokuje nic, jen přesměrovává vnější porty na vnitřní IP/porty. Takže na veřejný IP je vystavenej přímo router se svýma vlastníma službama a pár přesměrováníma, víc nic.
Domů by mi nemělo samo vlézt nic, pokud to nepřijde přes nějakou službu, na kterou je směrovaný zvenku nějaký port nebo přes nějakou službu/program, který si sám otevře spojení.
-
Pokud je to postavené jen na přesměrování (NATu), pak se dovnitř klidně něco mimo NATované služby dostat může. Pokud router na vnějším rozhraní dostane paket s IP adresou z vaší vnitřní sítě, normálně ho dovnitř přepošle. Samozřejmě je otázka, jak by se ten paket na to vnější rozhraní dostal – ale věříte ISP, že vám žádný takový paket nikdy nepošle?
-
Nejde len o podvrhnute packety... Ale dnes nie je problem spravit NAT traversal cez hoci aj cez WebRTC.
-
Minimalne by sis tam mel pridat pravidla, ktery znemoznej odchozi provoz na privatni IPcka a stejne tak prichozi provoz z privatnich/na privatni adresy. Samo pripadne s vyjimkou toho subnetu pres kterej to podruhy natujes.
=> pokud mas ven eth0 a dovnitr eth1 ... tak veskerej provoz kterej pude pres forward, a jako odchozi iface bude mit eth0 ... nesmi mit v dst nic jako 192.168./16, 10./8 ... a samo dalsi dle rfc. Tim zajistis ze tvuj nesmyslnej traffic nebude zatezovat tvoji (a providerovu) linku.
zadruhy ... veskerej provoz, kterej bude mit jako prichozi iface eth0 a v dst bude mit vyse zmineny IPcka nesmi projit, nebot je to zcela zjevny utok na tvoji sit a pokud takovy veci projit nechas, da se uplne vpohode navazat primej spoj s internima strojema, zcela bez ohledu na to, ze sou za NATem.
zatreti ... provoz, kterej prijde na eth0 a bude mit v dst verejnou adresu, ale v src privatni ... bys mel zablokovat taktez, da se to taktez da vyuzit k ruznym typum utoku.
Samo, jak bylo receno, nejlepsi je pristupovat ke kazdymu jednomu zarizeni v siti tak, ze je v siti naprosto verejne, a tudiz by nemelo do te site poskytovat nic, co zcela verejne poskytnout nechces. A uvedom si, ze nastavit korektne firewall tak, aby delal to co chces, a ne co si myslis ze dela ... neni vubec easy.
Jinak doporucuju IPv6, veci to velmi zjednodusuje, nemusis totiz resit co se kde na co preklada a co z toho ve finale vyleze ...
-
j: Díky za nasměrování a vysvětlení. Nejsem zase úplnej debil, snažím se to pochopit a naučit, mám před sebou mini seriály "Vše o iptables" a "Stavíme firewall" tady na rootu a prokousávám se tím.
Jinak u mých strojů to mám tak, že služby na který směruju porty, jsou braný jako kdyby stroj visel přímo v internetu. IPv6 mám, takže se podle toho musím taky chovat... (horší už to má brácha s Windows :-) tam se o zabezpečení ale musí postarat Microsoft)
To víte, že by mě zajímalo, jak moc to má všechno nastavený dobře/blbě, ale jak tohle zjistit? Bezpečnostní audit domácnosti platit fakt nechci ;D
Můžu tedy ještě dotaz(y)? Když směruju na routeru vnější port 22 na vnitřní IP na port 22, existuje možnost, že tehle forward bude zneužitej k tomu, aby se útočník dostal jinam, než na SSH na cílovym stroji? Jak?
-
To zalezi, jak ten forward mas nastavenej ... iptables umoznuji lecos (da se rict, ze naprosto cokoli). Jinak viz vejs, pokud ti poslu paket, kterej ma src 192.168.x.y ... a dst a.b.c.d (tvoje verejna) na port 22, tak se stane to, ze tvuj stroj prijme paket, a odpoved posle internimu stroji s IP uvedenou v src. Pak samo zalezi na tom, co a jak deravyho bezi na tom dalsim stroji. Jop, uvedom si, ze soucasti src je i port, takze defakto muzu takhle vyvolat komunikaci na port rpc, http ...
-
j: Díky. Začínám to v tom vidět. Je potřeba si ošéfovat, aby z veřejný IP nechodily dovnitř do sítě pakety z adres, který mám ve vnitřní síti (protože tím pádem by nešlo o moje pakety...).
To bude ještě zajímavý, čeká mě zjevně celkem boj :-)