Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: HanzHanz 22. 04. 2021, 15:38:12
-
Prosím o radu, jde-li vyřešit následující:
Chtěl bych, aby určité VMs měly přístup pouze na internet, ale neviděly ostatní stanice v lokální síti.
Zkoušel jsem přes iptables, ale vůbec se mi nedaří. Ideální by byl nějaký NAT setup pro VMs tak, aby neviděly síť 192.168.0.0/24, kromě routeru 192.168.0.1.
Děkuji!
-
Definuj si DMZ na samostatném segmentu sítě.
Firewall je pustí do netu.
Lokální stanice se na ně dostanou.
Vymalováno.
Až ti stanici v lokální síti někdo hackne, tak se tvým pravidlům v IPtables vysměje.
-
Stanici v lokální síti nikdo nehackne, protože v LAN jsem jenom já a z internetu není LAN dostupná.
Pokud někdo ví jak izolovat VMs s KVM NAT default network (192.168.122.0/24) od mé LAN (192.168.0.0/24) s tím aby VMs mohly přes router 192.168.0.1 na internet, budu vděčný.
Díky.
-
Udělat VLAN (přiřazení VLAN tag na KVM) pro VMs, co nemají vidět dovnitř. VMs se stejným tagem mohou komunikovat, s jiným nebo žádným ne.
Na routeru se to musí ještě nějak pořešit.
Sorry, pil jsem ;D
https://elkano.org/blog/vlan-tagging-on-linux-for-kvm/
-
Díky za odpověď, ale můj router neumí vlany...
Já bych potřeboval něco jako tohle:
když na VM přidám pravidlo: iptables -A OUTPUT -d 192.168.0.200 -j DROP zablokuju tím přístup VM na 192.168.0.200. Ale potřebovat bych tohle pravidlo udělat na KVM HOSTu, abych to nemusel na každý VM definovat zvlášť.
-
Routery umí i port isolation nebo client isolation.
Takže například nic připojeného do portu 4 nevidí do zbytku sítě, ale jen na net.
BTW, proč to oddělovat, když to nikdo nemůže hacknout?
Nedělej hérečku a popiš o co jde.
-
Já nedělám žádnou herečku, není důvod.
Chci prostě někomu externímu zpřístupnit VM na pokusy pomocí Anydesk a nechci aby mi viděl na zbytek sítě. Toť vše.
Potřebuji to vyřešit přes iptables nebo něčím podobným. Izolace portů je nesmysl, protože pak moje jiná PC v síti neuvidí na server (KVM host).
-
A chceš to chránit pořádně nebo jen tak naoko?
Jestli jen tak naoko, tak ty pravidla firewallu budou ok.
Jestli to chceš pořádně, pošlu návod, ale to řešení tě vyjde na 300 za zařízení.
-
Sice nechápu proč naoko, ale budiž. Ano stačí mi tedy naoko - pravidlo iptables na KVM hostu/serveru. Když mi poradíš to pravidlo, rád si nechám vysvětlit, proč je to jen naoko. Děkuji.
-
Takhle se blokuje celý rozsah:
iptables -A INPUT -s 192.168.0.0/24 -j DROP
/24 určuje masku, tj. pro Cčkovou masku.
Masku si můžeš šikovně upravit a máš vymalováno.
Pro tvůj účel by to mohlo stačit.
-
A reference, s kým se bavíme? Rád si zaplatím za kvalitu, tak šup sem s tím.
A chceš to chránit pořádně nebo jen tak naoko?
Jestli jen tak naoko, tak ty pravidla firewallu budou ok.
Jestli to chceš pořádně, pošlu návod, ale to řešení tě vyjde na 300 za zařízení.
-
Takhle se blokuje celý rozsah:
iptables -A INPUT -s 192.168.0.0/24 -j DROP
/24 určuje masku, tj. pro Cčkovou masku.
Masku si můžeš šikovně upravit a máš vymalováno.
Pro tvůj účel by to mohlo stačit.
Tak se teda pleteš. Tímto zablokuješ KVM host/server, ale VMs komunikují se sítí nadále a naprosto v pohodě...
-
Tak se teda pleteš.
Ukazoval jsem ti, jak se blokuje rozsah, ne konkrétní pravidlo a hotové řešení.
A KVM neznám.
Nevím, jak funguje, jestli vytváří virtuální switch, virtuální síťovky nebo mapuješ fyzické karty.
Budeš si to muset nastudovat a umístit si pravidla na správné místo.
Běžně používám VMware a občas HyperV.
-
Tak se teda pleteš.
Ukazoval jsem ti, jak se blokuje rozsah, ne konkrétní pravidlo a hotové řešení.
A KVM neznám.
Nevím, jak funguje, jestli vytváří virtuální switch, virtuální síťovky nebo mapuješ fyzické karty.
Budeš si to muset nastudovat a umístit si pravidla na správné místo.
Běžně používám VMware a občas HyperV.
Takže celou dobu ze sebe děláš bezpečnostního experta s tím, že pravidlo FW je řešení naoko a pak z tebe vypadne, že vlastně neumíš napsat ani to pravidlo FW. To je fakt vtip.
-
Ale já ho napsat dokážu ;D
Jen ti to nechci dát na stříbrném podnosu ;D
A KVM ... fuj :-D
-
Jak velky problem je proste vymenit router za neco schopneho provozu s VLAN?
Jak je pripojeny PC? Kabelem nebo pres WiFi?
Ty virtualni stroje vyuzivaji pripojeni k lokalni siti v rezimu NAT nebo bridge?
Jakz-takz bezpecna varianta je:
- zmenit konfiguraci virtualniho stroje, aby pouzival rezim bridge (virtualni stroj musi dostat IP adresu primo z lokalni sité tedy asi 192.168.0.x)
- povolit na hostitelskem stroji (ne ve virtualu) netfilteru, aby na bridge filtroval pravidla (hledejte googlem "bridge-nf-call-iptables=1", je to sysctl nastaveni)
- pridat na spravne misto ve firewallu pravidla, aby virtualni stroj mohl pristupovat jen na gateway; pokud je gateway 192.168.0.1 a adresa stroje 192.168.0.128, pak to bude neco jako
iptables -A INPUT -s 192.168.0.128 -j DROP
iptables -A FORWARD -s 192.168.0.128 -d 192.168.0.1 -j ACCEPT
iptables -A FORWARD -s 192.168.0.128 -d 192.168.0.0/24 -j DROP
iptables -A FORWARD -s 192.168.0.128 -d 0.0.0.0/0 -j ACCEPT
Konkretni realizace samozrejme zalezi na tom, jak se nastavuje firewall, jestli se treba nepouzivaji nftables, jaka distribuce se pouziva, atp.
Dal to taky neblokuje IPv6, takze scany po IPv6 porad budou mozne.
-
Ale já ho napsat dokážu ;D
Jen ti to nechci dát na stříbrném podnosu ;D
A KVM ... fuj :-D
Moc nechápu proč se tedy vůbec účastníš diskuse, když jediný tvůj výsledek je machrování bez ochoty naspat správně jeden řádek FW pravidla.
Věřím, že se najde někdo ochotný pomoci bez zbytečných keců okolo jako PanVP všeuměl.
-
Jak velky problem je proste vymenit router za neco schopneho provozu s VLAN?
Jak je pripojeny PC? Kabelem nebo pres WiFi?
Ty virtualni stroje vyuzivaji pripojeni k lokalni siti v rezimu NAT nebo bridge?
Jakz-takz bezpecna varianta je:
- zmenit konfiguraci virtualniho stroje, aby pouzival rezim bridge (virtualni stroj musi dostat IP adresu primo z lokalni sité tedy asi 192.168.0.x)
- povolit na hostitelskem stroji (ne ve virtualu) netfilteru, aby na bridge filtroval pravidla (hledejte googlem "bridge-nf-call-iptables=1", je to sysctl nastaveni)
- pridat na spravne misto ve firewallu pravidla, aby virtualni stroj mohl pristupovat jen na gateway; pokud je gateway 192.168.0.1 a adresa stroje 192.168.0.128, pak to bude neco jako
iptables -A INPUT -s 192.168.0.128 -j DROP
iptables -A FORWARD -s 192.168.0.128 -d 192.168.0.1 -j ACCEPT
iptables -A FORWARD -s 192.168.0.128 -d 192.168.0.0/24 -j DROP
iptables -A FORWARD -s 192.168.0.128 -d 0.0.0.0/0 -j ACCEPT
Konkretni realizace samozrejme zalezi na tom, jak se nastavuje firewall, jestli se treba nepouzivaji nftables, jaka distribuce se pouziva, atp.
Dal to taky neblokuje IPv6, takze scany po IPv6 porad budou mozne.
Děkuji Radku! Vyzkouším. Vhledem k tomu, že je to fakt řešení velmi dočasné a na domácí použití, výměna routeru s vlan nedává smysl.
-
Jak velky problem je proste vymenit router za neco schopneho provozu s VLAN?
Jak je pripojeny PC? Kabelem nebo pres WiFi?
Ty virtualni stroje vyuzivaji pripojeni k lokalni siti v rezimu NAT nebo bridge?
Jakz-takz bezpecna varianta je:
- zmenit konfiguraci virtualniho stroje, aby pouzival rezim bridge (virtualni stroj musi dostat IP adresu primo z lokalni sité tedy asi 192.168.0.x)
- povolit na hostitelskem stroji (ne ve virtualu) netfilteru, aby na bridge filtroval pravidla (hledejte googlem "bridge-nf-call-iptables=1", je to sysctl nastaveni)
- pridat na spravne misto ve firewallu pravidla, aby virtualni stroj mohl pristupovat jen na gateway; pokud je gateway 192.168.0.1 a adresa stroje 192.168.0.128, pak to bude neco jako
iptables -A INPUT -s 192.168.0.128 -j DROP
iptables -A FORWARD -s 192.168.0.128 -d 192.168.0.1 -j ACCEPT
iptables -A FORWARD -s 192.168.0.128 -d 192.168.0.0/24 -j DROP
iptables -A FORWARD -s 192.168.0.128 -d 0.0.0.0/0 -j ACCEPT
Konkretni realizace samozrejme zalezi na tom, jak se nastavuje firewall, jestli se treba nepouzivaji nftables, jaka distribuce se pouziva, atp.
Dal to taky neblokuje IPv6, takze scany po IPv6 porad budou mozne.
Tak mi to bohužel komunikuje nadále. VM používá bridge Macvtap s přiřazením názvu fyzické síťovky hosta (enp8s0). VM dostane od routeru adresu 192.168.0.14. Povolil jsem tedy sysctl net.bridge.bridge-nf-call-iptables=1 a napsal pravidla v pořadí jak jsi uvedl (samozřejmě s adresou 192.168.0.14). Je to divný, nevím proč to nejde.
-
Já jo... https://youtu.be/o1eHKf-dMwo
-
Doplnění pro: Radek Zajíc
KVM host (server) běží na Manjaru
VMs jsou Linux Mint 20.1, W7 a W10
-
Tak se teda pleteš. Tímto zablokuješ KVM host/server, ale VMs komunikují se sítí nadále a naprosto v pohodě...
Si myslím že tohle nejde protože na bridgi se používají ebtables, ne? (předpokládám že používáš bridge. Pokud používáš natovanou síť v userspace, tak bych spustil virtuál pod jiným uživatelem a omezení mu nastavil pomocí iptables match UID. Můžeš používat natovanou síť? Asi jo, ne, když je LAN stejně za NATem, tak to už ničemu neublíží. Ale nezkoušel jsem to, je možné, že user network jde „někudy jinudy“ a tohle fungovat nebude. Je to jenom nástřel.)
-
Tak se teda pleteš. Tímto zablokuješ KVM host/server, ale VMs komunikují se sítí nadále a naprosto v pohodě...
Si myslím že tohle nejde protože na bridgi se používají ebtables, ne? (předpokládám že používáš bridge. Pokud používáš natovanou síť v userspace, tak bych spustil virtuál pod jiným uživatelem a omezení mu nastavil pomocí iptables match UID. Můžeš používat natovanou síť? Asi jo, ne, když je LAN stejně za NATem, tak to už ničemu neublíží. Ale nezkoušel jsem to, je možné, že user network jde „někudy jinudy“ a tohle fungovat nebude. Je to jenom nástřel.)
Ahoj Jendo, děkuji za odpověď.
Ano, jak jsem psal výše: Když na VM přidám pravidlo: iptables -A OUTPUT -d 192.168.0.200 -j DROP zablokuju tím přístup VM na 192.168.0.200. Ale potřebovat bych tohle pravidlo udělat na KVM HOSTu, abych to nemusel na každý VM definovat zvlášť.
Takže, jo, dokážu zablokovat provoz přímo na VM (ať už konkrétní adresu nebo celou síť 192.168.0.0/24), ale nedokážu toho samého dosáhnout na KVM host, abych to nemusel pro každou VM definovat zvlášť. A je jedno jestli VM jede v řežimu NAT nebo bridge (macvtap).
-
Ale mně to funguje. Když pustím jako user s UID 1000 VM tímto příkazem:
qemu-system-x86_64 -enable-kvm -net user,hostfwd=tcp::10022-:22 -net nic -drive file=debian.img,index=0,media=disk,cache=unsafe -m 2048a následně udělám
iptables -A OUTPUT -m owner --uid-owner 1000 -d 192.168.11.0/24 -j REJECT
iptables -I OUTPUT -m owner --uid-owner 1000 -d 192.168.11.1/32 -j ACCEPT
tak se dostanu na net, ale nemůžu se připojit na jiné počítače v síti. Blbý je že nefunguje ping (https://wiki.qemu.org/Documentation/Networking), zkoušel jsem to pomocí wgetu. A je tam návod jak ping rozchodit (nezkoušel jsem).
-
Ale mně to funguje. Když pustím jako user s UID 1000 VM tímto příkazem:
qemu-system-x86_64 -enable-kvm -net user,hostfwd=tcp::10022-:22 -net nic -drive file=debian.img,index=0,media=disk,cache=unsafe -m 2048a následně udělám
iptables -A OUTPUT -m owner --uid-owner 1000 -d 192.168.11.0/24 -j REJECT
iptables -I OUTPUT -m owner --uid-owner 1000 -d 192.168.11.1/32 -j ACCEPT
tak se dostanu na net, ale nemůžu se připojit na jiné počítače v síti. Blbý je že nefunguje ping (https://wiki.qemu.org/Documentation/Networking), zkoušel jsem to pomocí wgetu. A je tam návod jak ping rozchodit (nezkoušel jsem).
Takže mám vytvořit jiného uživatele a pod ním spustit VM a pak přidat ta pravidla? A pravidla přidat na KVM host ok? Děkuji.
-
Takže mám vytvořit jiného uživatele a pod ním spustit VM a pak přidat ta pravidla?
Ano.
A pravidla přidat na KVM host ok?
Ano, kde jinde bys je taky chtěl přidávat? Ve VM být nemohou, když není důvěryhodná.
-
Takže mám vytvořit jiného uživatele a pod ním spustit VM a pak přidat ta pravidla?
Ano.
A pravidla přidat na KVM host ok?
Ano, kde jinde bys je taky chtěl přidávat? Ve VM být nemohou, když není důvěryhodná.
Jendo jsi borec funguje to!
qemu-system-x86_64 -enable-kvm -net user,hostfwd=tcp::10022-:22 -net nic -drive file=debian.img,index=0,media=disk,cache=unsafe -m 2048
Jen ve výše uvedeném řádku musím nechat uživatele "user", když ho změním na nově vytvořeného "fw" tak mi to hodí chybu - Invalid parameter "fw".
Nevíš jestli by se dala tímto způsobem VM spouštět automaticky přes virt-manager nebo virsh?
Každopádně moc děkuji!
-
Pro: Jenda
Ještě jeden dotaz. Když spustím VM z virt-manageru, tak je VM spuštěna pod uživatelem "nobody", který má user id 65534.
Proč nefunguje toto: iptables -A OUTPUT -m owner --uid-owner 65534 -d 192.168.0.240 -j REJECT
-
Jen ve výše uvedeném řádku musím nechat uživatele "user", když ho změním na nově vytvořeného "fw" tak mi to hodí chybu - Invalid parameter "fw".
wtf, to není jméno uživatele, to je typ síťového rozhraní…
-
Jen ve výše uvedeném řádku musím nechat uživatele "user", když ho změním na nově vytvořeného "fw" tak mi to hodí chybu - Invalid parameter "fw".
wtf, to není jméno uživatele, to je typ síťového rozhraní…
OK já nikdy takto VM nespouštěl a popletlo mě to vytvoření novýho uživatele (jsem vytvořil novýho uživatele OS :-))
A netušíš proč to nejde blokovat pro uživatele "nobody": iptables -A OUTPUT -m owner --uid-owner 65534 -d 192.168.0.240 -j REJECT
-
Jendo ještě jednou díky, už jsem na to přišel. I ve virt-manageru je možnost vytvoření "uživatelské relace", s výběrem sítě "uživatelské síťování" a pak se to chová přesně jak jsi mi poradil.
Vyřešeno. Díky!