Az előző cikket azzal fejeztem be, hogy nagyon kis esély van arra, hogy a mikroszegmentációhoz szükséges összes szabály már dokumentált és azt csupán be kell konfigurálni az NSX elosztott tűzfalába. Általában a zónák elválasztása legalább papíron szokott létezni, de ennél mélyebbre nem nyúl senki, mivel eddig maximum guest operációs rendszer oldalon lehetett szegmentálni.
Na de itt van az NSX és nem kell Windows tűzfal meg IP tables, ez a VM-től és annak operációs rendszerének épségétől függetlenül tudja a tűzfal képességét nyújtani. Egy élő rendszernél mégis hogyan juthatunk el addig a szabályrendszerig, hogy legalább a szükséges kommunikáció fedve legyen azokkal?
Első körben úgy, hogy mindenképpen felhasználunk egy normálisabb syslog kiszolgálót. Mivel én VMware-ezek ezért esetemben a vRealize Log Insight, új nevén Aria for Logs ajda magát. Az NSX DFW nem máshová naplóz, mint az ESXi-kre magukra, szóval ezért érdemes a syslog-ra összegyűjteni ezeket a naplókat róluk.
Tapasztalataim szerint érdemes darabokban megenni az elefántot. Erre több mód adódik:
- portgroup-ról, portgroup-ra haladva
- VLAN-ról, VLAN-ra haladva
- VM-ről, VM-re haladva
- szolgálatásonként haladva
Mondanám, hogy az első kettő pont teljesen azonos, de nem egyszer találkoztam már olyan rendszerrel, ahol ugyanaz a VLAN ID, több port group-ba is be volt írva. Ennek oka általában a promiscous/forged transmit/mac address change beállítás szokott lenni, ami egyik PG-n az ahhoz csatolt VM miatt fontos valamiért. Szintén van olyan, hogy forgalomirányítási szempontok miatt azonos VLAN-ból néhány VM-nél a forgalom az egyik, a másik csoportnál de azonos VLAN-ról beszélvén mondjuk a másik interfészen menjen ki aktívan.
Én a VLAN/PG alapot szoktam javasolni és első körben cél oldalon vizsgálódva.
Példának hoztam a következő kiépítést.
Első lépésben nézzük meg milyen forgalmak célozzák a ZONE 1-et vagy akár specifikusan az FS01-es VM-et. Hozzunk létre egy policy-t és benne egy szabályt.
Ennek dinamikusan tagjává teszek minden VM-et, amely a ZONE1 VDS port group-hoz van kapcsolva. Ha VM-ről VM-re halad a bevezetés, akkor nyilván csak ezt az egyetlen VM-et teszem a csoportba.
A létrehozott csoportot a szabályban célként állítom be. Semmi más specifikus nincs, látható a megengedő állapot, szóval semmi forgalmat nem fog érinteni ha alkalmazzuk, csak látni akarom a forgalmakat.
A fogaskerékre kattintva beállítom a log label-t. Enélkül is lehet élni, de megtalálni könnyebb lesz a szabályra illeszedő adatokat. Ebből a célból a log label-t nekem tetszőre állítom.
Alább generáltam némi forgalmat, pingelgettem és SMB-n tallóztam az FS01 megosztásait.
Értelmezzünk két ilyen sort:
- INET match PASS 2024 IN 60 ICMP 192.168.101.1 -> 192.168.99.1 ZONE1-catch-rule
- INET match PASS 2024 IN 52 TCP 192.168.101.1/49676 -> 192.168.99.1/445 SEW ZONE1-catch-rule
A lényegesebb részek:
- INET – azaz IPv4
- PASS – azaz átment a tűzfalon
- 2024 – ez a rule ID, amire a forgalom illeszkedik. Ezt a rule ID-t az NSX-ben meg is lehet találni, ez pont a catch-rule ugye.
- IN – bejövő irány
- 60 – a packet hossza
- ICMP – protokol
- 192.168.101.1 – forrás IP illetve forrás IP/port
- 192.168.99.1 – cél IP illetve cél IP/port
- ZONE1-catch-rule – a log label
Ha értelmezzük a két szabályt, akkor attól függően hogy zónák közötti vagy VM-ek közötti mikroszegmentáció a cél, egy-egy/két-két szabály közül válaszhatunk:
Zónák közötti szabályok
A log-okból az látszik, hogy a ZONE3 beszél a ZONE1-el és ICMP és SMB forgalom van.
Alább egy layer 4 szabály van, amiben együtt engedélyezem az ICMP-t és az SMB-t, de igazából ez lehet két szabály is. Ha layer 7 szeretnék szűrni, akkor két sorra kell bontani, mert két eltérő service-re nem lehet két eltérő context profile.
Ha nagyobb rendszerről van szó, akkor az applied to mezőben a ZONE1-et – vagy ha forrás oldalon szűrnék akkor a ZONE3-at – adnám meg.
VM-ek közötti szabályok
Két VLAN között bármilyen tűzfal képes erre és jelen esetben erről van szó, hiszen a forrás és a cél VM, más VLAN-ban van.
A megengedő specifikus szabály miatt, a fedett forgalmak esetén a catch rule, már nem fog match-elni rájuk, hiszen a szabályok kiértékelése fentről, lefelé halad. Ha mondjuk egy hétig/hónapig hagyjuk a rendszert működni és akkor nézzük meg a naplókat és úgy ítéljük meg, hogy nincs egyetlen találat sem – mert nem történik más forgalom – akkor vagy a catch rule módosítható például drop-ra vagy a default szabály – bár az azt jelenené, hogy minden szabállyal elkészültünk az összes VM-re nézve.
A fenti tehát akkor azt jelenti, hogy például CLIENT01 képes pingelni FS01-et, de CLIENT02 nem tudja. Ennek megerősítése látható alább.
VM-ek közötti szűrés VLAN-on belül
Nézzük meg, hogy miképpen lehetséges mondjuk CLIENT01 és CLIENT02 kommunikációját megakadályozni. Nincs reális ok amiért ez a kettő egymással forgalmazni akarjon. Ezt nem tudja senki így, csak valami egzotikus módon. Például nyilván lehet venni Aruba CX10000-res switcheket, meg Pensando NIC-eket aztán szét lehet faragni, csak hát biztosan jó olcsó lesz, a gyártónak meg fix bevétel.
Forrás és cél oldalon is a ZONE3 csoportot használom.
Ahogy arra számítani lehetett, a VLAN-on belül immáron nem éri el egymást a két VM.
Azonban a CLIENT01 továbbra is eléri a FS01-et, hiszen korábban hoztam létre az ahhoz szükséges szabályt.
Ha mondjuk a CLIENT02-ről is el szeretném érni az FS01-et, akkor csak a 2026-os szabályban kell a CLIENT02-t is a sources mezőbe tenni. Ha a teljes ZONE3-ból szeretném engedélyezni, akkor nyilván a ZONE3-at kell beletenni.
Ha minden szabály elkészült
Amennyiben minden szabály elkészült és a catch rule-okon nem keletkezik már bejegyzés vagy ami keletkezik azt nem szeretnénk engedélyezni, akkor a “Default Layer3 Rule”-t kell áttenni drop/reject-re.
A 3048, 3050 és 2027 szabályok igazából nem kellenek, mert a default rule – 2 – drop.
Összefoglaló
Mit értünk el az NSX DFW mikroszegmentációs képességével? Azt hogy akár VLAN-on belül képesek vagyunk tiltani/engedélyezni forgalmakat, egy egészen új szintre emelve a biztonságot. Ha a ZONE01-ben lenne még mondjuk száz VM, akkor azt nem egy egységként kezeljük – és maximum guest oldali tűzfallal daraboljuk tovább – hanem, VM-enként. Így egy támadó dolga megnehezíthető hogy horizontálisan/laterálisan mozogjon, egy ransomware/vírus észrevétlenül tudjon terjedni.
A következő részben a DFW egzotikusabb képességeivel fogunk megismerkedni….
