Virtualis Gepek halozati vedelme

Hálózatok általános

Ez egy altalanos kerdes, nem feltetlen gyarto fuggo.
Adott egy host, amin fut X virtualis gep. Legyen VmWare, vagy KVM, OpenVZ, Xen de teljesen mind1.
Minden VM-en statikus IP van konfiguralva.
Hogyan lehet megelozni, hogy egy virtualis gep modositsa a sajat halozati beallitasait es egy masik meglevo gep IP-jet magara rantva halozati problemakat, IP utkozest idezzen elo. Esetleg magara konfiguralja a default gateway-t es adott hoston vagy halozaton belul teljes kaoszt okozzon?
Pl:
Adott VM1 es VM2. VM2-felveszi VM1 ip-jet es maris kesz a kaosz. A VM-en belul mindenki root joggal rendelkezik, a halozati beallitasok igy a gepen belul nem korlatozhatoak.

Van valami javaslat amivel ez a problema kivedheto?

  • 3577 megtekintés

( peta v | 2018. 07. 21., szo – 08:30 )

Belegondolva a kerdesbe azt se tudom a fizikai halozatot hogy vedenem meg ettol. Valami halvany ccna emlek van port-securityrol, de az talan mac cimekre vonatkozott. Gondolom a megfelelo vedelem az, ha adott porton csak adott ip cimrol jovo packetet fogadjuk, legyen az fizikai switch, vagy valamilyen virtualis halozati megoldas.

A port security nem egesszen erre valo. Port sec a mac alapjan szur. Ha masik mac jon adott adott port on, akkor lecsapja azt a portot es nincs tovabb forgalom. Gyonyoru lenne ha az egesz host ot mondjuk odavagnank az osszes vm el. Aztan lehetne vadaszni, hogy melyik volt a huligan.
Ip source guard ugy tudom jobb megoldas lenne csak az ugye fizikai gepen es nem virtualison mikodik

( zz7 | 2018. 07. 21., szo – 10:26 )

Nem egészen értem hogy miért módosítaná a saját IP beállításait a VM ha már statikus IP van beállítva.

Proxmox-ban a webes felületen elég jól konfigurálható tűzfal van a host-ra és a VM, CT gépekre külön-külön állítható szabályokkal.

Úgy hívják, hogy IaaS cloud.

Van egy infrastruktúra üzemeltető és vannak felhasználó "tenant"-ok akik a saját kis VM-jeiken belül full root joggal azt csinálnak amit akarnak. Az infrastruktúra képes kell legyen megvédeni magát és a többi tenant-ot egy esetleges rosszindulatú (vagy csak simán balfék) tenant tevékenységétől.

Úgy 10+ éve létezik ez a megoldás, mára az internet kb 70%-a pontosan ilyen "nem éppen ideális" rendszeren fut.
---
Régóta vágyok én, az androidok mezonkincsére már!

( blackluck v | 2018. 07. 21., szo – 10:52 )

Libvirt (kvm) -nel van networkfilter szabalylehetoseg (en nem probaltam egyelore, igy gyakorlatban nem tudom mennyire jo):
https://libvirt.org/formatnwfilter.html

Vagy openvswitch es tarsaival mintha fizikai gepet a fizikai switchen probalnad szabalyozni (persze abbol amit tud a virtualis switch limitalni), hogy csak adott mac adressel, hozza adott ipv4 cimmel (ip arp inspection), esetleg ipv6-al levo forgalmat (valami nd filter) engedje, netan multicast-ot, stp-t, dhcp snooping-ot es hasonlokat is limitalni/beallitani.

( XMI | 2018. 07. 21., szo – 12:03 )

Most teljes részletességgel nem akarok belemenni, de röviden erre van Openstack-ben a neutron port security, VMware NSX-ben meg azt hiszem PortGuard néven fut. Nyilván mind az openstack, mind egy NSX-el ellátott vCenter infrastruktúra elég nehézsúlyú dolog.

Az openstack azt csinálja, hogy:
- a neutron számontartja, hogy melyik virtuális gépnek melyik hálózaton milyen IP cím van kiosztva
- a KVM-ben futó gépnek létrejön a hoston egy tapXXXX virtuális interfésze
- ezt rákötik egy linux bridge-re
- bekapcsolják a kernelben a net.bridge.bridge-nf-call-iptables=1 sysctl paramétert
- ettől a bridge forgalma átmegy az iptables-en is, ahova felveszik filter szabálynak, hogy source interfesz = tapXXXX, source IP != kioszott IP, akkor DROP.
- Aztán még átmegy a forgalom egy pár openvswitch bridge-en is, ami végül a tényleges külső hálózatra kivezeti a forgalmat (igazából meg lehetne a source IP szűrést az openvswitch-ben is, az openflow tud matchelni IP header mezőkre is. Mindig az volt az érzésem, hogy szűkségtelenül túlkomplikálták)
- Mivel előfordul, hogy a VM-nek mégiscsak valós igénye van arra, hogy más gépek IP címeit felvegye - clustering megoldásoknál a közös virtuális IP átvétele tipikusan ilyen - ezért a neutronban létezik egy allowed address pair nevű paraméter, amivel a user - feltéve, hogy kapott rá jogot - megadhatja, hogy milyen egyéb forrás IP-ket akar whitelist-elni a VM-jére (pontosabban a VM egy adott hálózati portjára).

---
Régóta vágyok én, az androidok mezonkincsére már!

( mraacz | 2018. 07. 21., szo – 12:06 )

Ha mindegyik VM-en belül minden user root, akkor pontosan mire is keresel megoldást? Ha a rongálás veszélye merül föl, akkor nem lehet mindenki root... ha mindenki root, akkor annak következményei vannak.

Egyébként minek a statikus IP? A DHCP miért nem jó?

Erre van pl. a MAC address change reject ESXi-ben, ha átállítod a "fizikai" MAC címet a guest OS-ben, akkor elvágtad magad a hálózattól.

+ egy DHCP és meg van oldva.

Enterprise környezetben meg NSX.

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

mraacz:
Ha mondjuk vps-t szolgaltatsz akkor igen, mindenki root. Ha Dhcp-n ha osztogatnal publikus ip-t minden vm-nek, az sem lenne megoldas mert biztos lenne jelentkezo aki statikusan atirna a sajatjat es megboritana a masik gepet, vagy mondjuk a teljes infrastrukturat ha holnaptol mondjuk o lenne a default gateway es minden vm fele fordulna a router helyett.

( n.balazs v | 2018. 07. 21., szo – 17:35 )

Értem a problémád.
Egy naiv megoldás: külön vlan gépenként, majd a routeren szabályozod, hogy milyen forgalmat fogadsz el az adott vlanból, illetve mit továbbíthatsz felé.
Vswitch/switch szinten: tudod konfigurálni ACL-ekkel, hogy milyen forgalmat küldesz/fogadsz.
Egy korszerűbb megoldás: private vlan bevezetése. Na, ez egy külön sztori virtualizációnál. Sokat lehet vele szívni.

A port security nem megoldás, mert csak a MAC cím változtatás ellen védhetne, IP szinten nem ad védelmet.

( Imo | 2018. 07. 21., szo – 17:42 )

vSwitch Extended Port ACL

És ugye Hyper-V-n alapesetben is be van kapcsolva a ARP/ND Poisoning (spoofing) protection, tehát nem tud a VM más mac address-t felvenni, mint amit adtál neki és pl. magára terelni a forgalmat.
Ill. DHCP Guard protection, amivel nem tud DHCP szerverként megjelenni a külső hálózaton.

Ez a három, azért elég szokott lenni, ill. ha nagyon kell, akkor még Isolated VLAN.

Az ARP poisioning protection kényszeriti, hogy ne tudjon másik vm vagy fizikai gép mac addressét behazudni és magához irányitani a forgalmat.
A virtualswitch portján pedig be tudod állitani, hogy milyen IP-t engedjen meg a VM számára, minden mást eldob, teljesen mindegy mit állit be a vm-ben a user.

Ez miért nem out of the box válasz a problémára?

Az elsődleges konkurenciája (VMware/vSphere) viszont nem, NSX kell hozzá, ami egy vagyon, pláne hogy annak előfeltétele a vCenter, amiért már alapból mélyen a zsebbe kell nyúlni . Ha ezt a funkciót az ingyenes Hyper-V szerver is tudja (nem néztem utána), akkor pláne érdekes.

Ez érdekesen hangzik. Én futtatok vagy egy tucatot sokéve.
Mi hiányzik neked egész pontosan, az ingyenes Hyper-V serverből, ami miatt nem érdemes production környezetben használni?

(ha még az ingyenes esxi-ről beszélnénk, amit még backupolni sem lehet normálisan, azt jobban érteném. Hyper-V serveren a legfeltűnőbb "hiány" a GUI hiánya, de az pont nem kell production környezetben)

Ez eddig a legjobb otlet!
ebtables-t a host on konfigoljatok es igy szuritek a forgalmat ami a VM felol jon? Magyarul a VM-es interface es a host-nak a bridge-e kozotti forgalmat korlatozzatok. Ez baromi jo, mert minden VM-nek megvan a sajat interface-e es erre rakjatok a szabalyt, hogy adott interface-en nem johet masik IP vagy mac. Igy nagyon klonozni sem tudnak mit, mert a fileter-en bent van, hogy adott interface-en milyen mac nek kell virtani, es milyen IP-vel, vagy kulonben megy a levesbe.
Koszi az otletet! Ez a legjobb! :)

( VincentV | 2018. 07. 21., szo – 17:52 )

sub, mert én is agyaltam már ezen. Nagyon kíváncsi lennék rá, hogy a jelenleg működő vps szolgáltatóknál hogy van ez megoldva. Tartok tőle, hogy sehogy, de kipróbálni még nem mertem, mert nincs sehol olyan accountom amiért nem kár ha kivágják :) NSX-el megoldható, openstackre is írtak konkrét példát fentebb, de kötve hiszem hogy ezek implementálva vannak ezeknél a cégeknél. Szerintem ezt mindenki benyeli (ok, nyilván egy Amazon nem, de azt ne is vegyük ide, mert eléggé custom cuccokkal dolgoznak), mondván hogy majd ha rosszalkodó user jön, akkor egyedileg/manuálisan megoldják és szankcionálják. De ne legyen igazam.

Nem csak amazon, hanem legyen barmelyik nagyob VPS szolgaltato. DigitalOcean, Linode, MediaTemple, eleven2, stb... ezeknel biztos valahogy meg van oldva ez az “alap” szintu vedelem, kulonben eleg gaz lenne ha csak egy ip valtas megfektethetne a halozatukat.

Kar hogy nem probaltad. :-) ha esetleg ido kozben... :-)

DigitalOceant megnéztem most, a szomszédos IP-ken vannak mindenféle webes szolgáltatások, böngészőben is látható, élő weboldalak. Ezeket látom a gépem arp táblájában is, mivel egy subnetben vagyunk, szóval látszólag L2-őn kommunikálok velük. Esélyesnek tartom hogy ki tudnék velük cseszni, de nyilván ki kéne próbálni (amit meg nem szeretnék).

VRF et hasznalni publikus IP-n ongyilkossag... Gondold csak el, minden VM-nek sajat GW-t cmezni kulon-kulon, sajat mask-al, stb... Mennyi felesleges publikus IP-t hasznalsz el 500-1000 gepnel? Ha belso mondjuk 10.X.X. valamit hasznalsz azon remek megoldas lehet a VRF. de ki az aki virtualis gepet berel belso cimmel? Max adni kell hozza alapbol tuzfal szolgaltast is es ugy mar mukodhet :D

"Gondold csak el, minden VM-nek sajat GW-t cmezni kulon-kulon, sajat mask-al, stb..."

1-et hasznalnak el, nem 3-at. Ez amugy konkretan automatizalt.
Mi az Exponential-E tol kapjuk az egyik "kanocot" a cegemnek Londonban es /31-es maszkot hasznalnak a publikus cimen.

De amugy csak egy megoldast irtam, amit konkretan hasznal a Cisco is, ezert adtam referenciat is.
Nem mellesleg, ahogy mar tobben is irtak VLAN-al is kivitelezheto, plusz ACL a porton hogy csak az az IP cim mehet ki, mert ezzel teljesen el lehet szeparalni az ugyfeleket egymastol.

De amugy egy ugyfelnek kiadni egy gepet, eleg bonyodalmas es az hogy hozza kell adni ot egy mar felkonfigolt VLAN-hoz, pont nem szamit egy adatkozpontban. (Itt adatkozpontnal nem egy tipiko BT-s salgo polcos adatkozpontra gondolok, hanem egy Telehouse vagy Interoute/GTT-bol indulok ki)

Amugy csak felve kerdezem meg, hogy raneztel a linkre, amit kuldtem?

1 publikus IP-t? VRF-enkent... minden VRF nek van egy adott default gw-e. Ebben az esetben ha leszabdalnam a cimeket a legkissebb mask ra, akkor is /23 as taromanyok lennenek minden gepre. De lehet felreertem amit mondassz.

A linket megneztem, a peldan a cisco belso IP-ket emlit.

Ha vlan-okkal lennenek megvalostitva akkor is kellene valami ami szeparalja a vm-eket egymastol. Es ebben az esetben vagy vswitch ami kezeli a trunk-ot vagy valami ami levalogatja a vlan okat. De akkor is a vswitch en kene valami ami rogziti a portokhoz az ipt es a mac et. Vagy rengeteg quad kartya es akkor lehet a fizikai switch en is.

2 cimet hasznalsz el, mint ahogy az Exponential-E is csinalja.
Az hogy belso vagy kulso cim, az tok mindegy, itt az elvi megvalositas, ami a VRF-nel szamit, ha azon az uton oldod meg.

A VLAN-os verzional nem nagyon ertem, hogy mire gondolsz, hogy nincs elszeparalva.
Ha kulon VLAN-ban vagy, akkor gyakorlatilag nem latsz ki sehova a geprol, ha nincs mogotte egy kapcsolat egy masik gepre, vagy switch-re. De a masik VLAN-ban levo gep(ek) sem latjak egymast, mert el vannak szeparalva 100%-os szinten. http://www.jonkensy.com/wp-content/uploads/PortGroupVLAN.jpg

Amugy Pl: VMware-en letre lehet hozni 4096-at VLAN-t + ugyan ennyi a limit a virtualis switcheknel.
Ez pont tobb mint eleg, egy virtualis kornyezethez.

Itt egy pelda erre VMware + pfSense komboval: http://www.jonkensy.com/multi-tenantvlans-behind-a-virtualized-pfsense-…

Arra gondolok, hogy ha van egy publikus cimtartomanyod, mondjuk 256 db IP-vel, akkor azokat darabolnod kell kissebb halozatokra, es ezzel IP cimeket pocsekolsz a publikus halon. Fontos hogy Belso vagy kulso! VPS-t ha szolgaltatsz, altalaban mindenkinek kulso cim kell. Most ha ezeket Vlan-ozgatod, akkor kezdheted szeletelni a publikus ip cimtartomanyod. Nallatok 2 IP-t hasznaltak. Igen, ez lenne minden VM-re. Ha kulon VRF-re pakolod oket, akkor 100 gepnel ez a duplaja es meg a broadcast cime. Szoval a legkisebb mask amit ki tudsz adni az 4 IP cim /32, ha route-olod a forgalmat. ez 400 ip-t jelent 100 VM-nel. Ez annyira nem jo megoldas... Legalabbis nekem.

miert kellene publikus IP-t hasznalni GW-nek? Siman megy privaton atroutolva is.
GW privat a.a.a.a - vegpont privat b.b.b.b + publikus B.B.B.B/32

ip r a default via a.a.a.a src B.B.B.B/32 - linux eseteben a kliensen, de elvileg barhol (OS) megoldhato
ip r a B.B.B.B/32 via b.b.b.b - linux eseteben a GW gepen

A legyeg, hogy a Publikus tartomany a routeren legyen atrouteolva. Router: Valami/24 -> Local GW -> fentebbi route -> Kliens
Innentol ha mas IP-jet vette fel route sincs hozza, mert a b.b.b.b nincs osszekotve a kamu IP-vel. Meg VLAN-ozhatod is, ha akarod.

(a parancsokat fejbol irtam - hibazhatok)

( apal v | 2018. 07. 22., v – 23:10 )

Ha mondjuk KVM-alapon csinalod, es mindegyik guest kap egy interface-t, akkor alapjaraton a host is latni fogja ezeket az interface-kat (mondjuk tap0, tap1, ... tap$((N-1)) neven, N db guest eseten), es onnantol kezdve rad van bizva hogy mit csinalsz. Alapjaraton ha nincsenek ezek konfiguralva akkor senki nem lat semmit (meg a guest sem latja a hostot es viceverza). Ha elkezded konfiguralgatni akkor csinalhatsz olyanokat hogy:
- a guest csak a hostokat lassa es forditva (ez a legegyszerubb)
- layer2-n csinalsz egy bridge-t (brctl addbr br0 && brctl addif br0 tap0 && brctl addif br0 tap1 && ...), es akkor a guestek is elkezdik egymast latni;
- itt eldonteted (ahogy fejesjoco kollega is irja feljebb) hogy csinalsz-e "smart switch"-et a sima layer2 mezei bridge-dbol a /proc/sys/net/bridge/bridge-nf-call-iptables, bridge-nf-call-arptables, ... hasznalhataval;
- efele meg csinalhatsz preroutingot/postroutingot is, sot, ugye kell is hogy a guest-ek kilassanak es/vagy kintrol belassanak;
- vagy kulon route-okat hozol letre az egyes tap* interface-khez es akkor nem lesz abbol problema hogy az egyik guest ip-je utkozne a masik guest ip-jevel - ellenben lesz egy kelloen komplex routing table-d.

Hogy mit valositasz meg ezekbol, az mar az egyeni igenyektol fugg, a topicindito-nak a fenti 3ik meg 5ik megoldas is fasza lehet. A 3ikkal meg nem foglalkoztam, csak "veletlenul" belefutottam. Az 5iket mar csinaltam hasonlo esetekben (pl fizikailag messze levo telephelyeken elszort gepeken futtatott virtualis gepeket tereltunk ossze egy LAN ala, mindenfele hasonlo + VLAN-os trukkozesekkel... pl ugy hogy a nativ VLAN az a host egyik bridge-jenek volt a resze, mig az eth0.10-es VLAN pedigegy masik bridge-nek, stbstb). A 4ik opcio az valoban kevesse biztonsagos.

Es ez meg csak a KVM/Qemu, vsz a tobbinel is van hasonlo megoldasok, kenyelmes gyari konfiguralasi lehetosegekkel. A KVM-nek az az elonye (szerintem) hogy igy jobban bele lehet latni hamar valamennyire ismeri az ember a linux networking alapokat.

( PunishR v | 2018. 07. 23., h – 01:27 )

- elfelejted a l2-t (nem bridgelgetsz stb)
- az adott vm/switch portra/vlan-ra routeolod a kívánt ipv4 címet /32-vel és elengeded a proxyarp-t
- használsz valami értelmes routeing protokolt a switchek/vm hostok között, mert lesz egy pár route...

( debtamas88 | 2019. 04. 07., v – 00:11 )

Szia!

Linux KVM/XEN alatt openvswitch - minden VM tap interfésze bridgelve majd az openvswitch-hez használsz egy sdn controllert (openflow)

Openvswitch alapból mindent enged - ha nincs controller beállítva - ha van controller, akkor semmilyen forgalmat nem enged - csak amit beállítasz.

Lényegében átveszi a vezérlést a bridgek felett.

Ilyet viszont a HyperV nem tud (openflow), de cáfoljatok meg :)

SDN Controller pl.: opendaylight; ryu