Az NSX egy svájci bicskához hasonlítható, bár egy olyanhoz képest a funkciói tényleg jól használhatók, míg egy olyan bicskával senki sem akarna nekiállni fát aprítani, holott van benne kis fűrész.
A teljes NSX-ben egy durva lista mire is képes:
- overlay hálózatok kiakalakítása – szóval L2 szegmensek kialakítása a fizikai hálózattól teljesen függetlenül – több hoszt, klaszter vagy adatközpont között
- elosztott tűzfal aka. mikroszegmentáció – akár egy szegmensen belüli tűzfalazási lehetőség, amely felvértezhető egyéb képességekkel. Felfogható east-west szűrésnek.
- gateway tűzfal – felfogható north-south szűrésnek.
- elosztott IDS/IPS
- gateway IDS/IPS
- gateway malware prevention
- distributed malware prevention
- load balancing – bár NSX-ben magában lassan deprecated
- NAT
- VPN
A fenti sokaság eltekintve attól, hogy milyen licensz kell hozzá és ahhoz milyen add-on, lényegében két fő csoportra bontható:
- Security
- Networking & Security
Rajzoltam egy ábrát, ami megmutatja kicsit érthetőbb formában.
A mikroszegmentációs törekvések esetén elegendő csak az elosztott tűzfal vásárlása, ami egy sokkal jutányosabb árban tükröződik és így ebben az esetben nem kell overlay hálózattal bajlódni, uplink profile-t, transport node profilt készíteni, magasabb MTU-t beállítgani, Edge node-okat telepítgetni és így tovább. Egy dolgot tud, a distributed tűzfalat, ami egyébként IDS/IPS-el és malware prevention-nal kiegészíthető (ATP).
Ezen kiadások így néznek ki:
- Distributed Firewall
For organizations needing implement access controls for east-west traffic within the network (micro-segmentation) but not focused on Threat detection and prevention services.
- Distributed Firewall with Threat Prevention
For organizations needing access control and select Threat prevention features for east-west traffic within the network. - Distributed Firewall with Advanced Threat Prevention
For organizations needing Firewall, and all advanced Threat prevention features for east-west traffic within the network. - Firewall for Baremetal Servers
For organizations needing an agent-based network segmentation solution for bare-metal workloads.
Vezessük be
A mikroszegmentáció bevezetése nem könnyű feladat, mivel olyan szabályrendszer az alapja, amely nem létezik, illetve ilyen formában nem létezik. Egyszer voltam egy nagy hírnevű biztonsági cégnél, aki egy egyetemnek „adtak tanácsot” és ők mondták, hogy NSX felesleges, a Neptun szervereken van windows tűzfal. Szóval, ha elengedjük a guest operációs rendszer tűzfalát és tényleg olyat akarunk, ami nem függ a guest operációs rendszer épségétől és kódjának minőségétől, akkor kell NSX. Ahhoz szabályok kellenek, méghozzá szegmenseken belül, két VM között is meg kell tudni mondani, mi, mivel, melyik porton, milyen protokol mentén kommunikál. Ha ez nincs meg, akkor zóna szintű szegmentációt tudunk csak megvalósítani, amihez meg nem feltétlen kell NSX, mert a VLAN-okat max egy tűzfalon termináljuk és akkor az ilyen forgalmak szűrhetővé válnak.
NSX Manager-re – egyre de még inkább háromra – mindenképpen szükség van. Ennek telepítéséhez két opció kínálkozik.
- Az egyik a vCenter-ből indítható:
A folyamathoz be kell tölteni az NSX ova-t és ki kell gurítani az első appliance-t. A további kettőt pedig majd az NSX felületéről lehet telepíteni – érdekes módon ezt a részt nem integrálták a vCenter varázslójába.
- A másik pedig, hogy mi magunk gurítjuk ki az NSX-et azonos OVA-ból, de nem a vCenter varázslójából. A különbség a kettő integrációjában van, azaz első esetben élvezhetünk az NSX-ben végrehajtható akciók indíthatóságát vCenter-ből.
Kell-e három manager? Ha csak DFW-t akarunk használni, akkor is kell – véleményem szerint – mivel ha nincs NSX Manager, mert az például, éppen újraindul vagy teljesen megáll, akkor nem tudunk szabályokat módosítani, sőt igazából VM-eket sem bekapcsolgatni, mivel az az ESXi kiszolgálók az NSX Manager-től kapják az utasításokat. Az NSX Controller/Manager cluster, három node-al az általam implementált rendszerekben kötelező.
Fogad tehát az alábbi döntési lehetőség:
- Security only
vagy
- Virtual Networking
Kicsit csalóka mert a második opció nem zárja ki a „security” képességet, szóval ez itt nem igazán vagy kapcsolat.
Ez a cikk a security only-ról szól szóval azt kiválasztva, fel is sorolja a vCenter által kezelt vSphere klasztereket és ezekre szabadon kiválasztható módon teszi fel a szükséges VIB-eket.
Az „Install NSX” megnyomása után mindenképpen felob egy figyelmezetetést, méhozzá hogy legalább 6.6-os VDS kell hozzá.
Hosztok számától függően olyan 3-10 perc alatt fel is települnek a szükséges komponensek az ESXi-re.
Ezen a ponton már üzemel is az NSX distributed firewall, csak éppen az alapértelmezett szabály mentén, ami teljesen megengedő – any-any-allow. A varázsló ennek kezelésére fel is ajánlja, hogy amennyiben rendelkezünk a szabályrendszer kialakítása tekintetében a megfelelő adatokkal, akkor ő máris fel is tud mindent konfigurálni annak megfelelően.
A distributed tűzfal forrás – source – és cél – destination – oldala csoportokat is képes használni, azaz nem szükséges mikromenedzselni ezeket. Egy csoport lehet statikus és dinamikus is, akármelyik is legyen a szabályok alkalmazódnak egy csoport minden tagjára. Ezért maguk a csoportok, a kategorizáció alapját alkotják, és a varázsló első kérdése, hogy melyek az infrastruktúra szempontjából általános kiszolgálók (Active Directory tartományvezérlők, DNS, NTP, CA stb.).
Alább például az Active Directory DC csoport kialakítása látható. Javasol nevet és tag-et, de ezek szabadon átírhatóak. Utóbbi tag-et hozzárendelve egy VM-hez, egyből a csoportba teszi az adott VM-et. Arra is van lehetőség, hogy IP vagy egy/több distributed port group kiválasztásával akossuk a csoportot – így bármely VM, ami az adott port group-on megelenik, a kívánt csoport tagja lesz.
Hasonlóan a fentihez, amolyan zónákat is alkothatunk, szóval ha körbe tudunk rajzolni VM-ek – IP-k/distibuted PG-k – több csoportját, amelyek mint egység kell vagy éppen nem kell elérjék egymást, akkor azt itt – is – meg tudjuk tenni.
Végére marad az egész esszenciája, az alkalmazás szintű szegmentáció. Nagyon erősen kétlem, hogy ezen a ponton bárki képes lenne az összes csoportot kialakítani ezen a ponton.
A csoportok elkészítésével tehát el is készültünk, azok pedig a szabályok alapját képzik, de nem elegendőek. A csoportok közötti tiltó és megengedő szabályokat még ki kell alakítani. Alább például a korábban felvett tartományvezérlőket tartalmazó csoport mint cél – kötelezően – szerepel, de a forrást és a port/protokol – L4 – meg kell adnunk. Lenti példában meglehetősen pongyola a beállítás – hiszen bárki, bármilyen porton elérheti a csoport tagjait – tehát érdemes ezt finomítani. Azonban nincs baj, ha nem állítunk be mindent itt, mert később is módosítható minden szabály.
Végére maradt a legfontosabb dolog, amivel egy teljes infrastruktúrát be lehet dönteni. A default szabály….
Alapértelmezetten minden forgalmat enged, de át lehet állítani drop,reject-re és akkor, amire nincs szabály, azt nem fogja engedni, tehát ha elfeleljtettünk bármit ami kellene, akkor baj lesz.
Az utolsó lépés csak egy megerősítés, hogy a telepítés és konfiguráció sikeres.
Innentől kezdve igazából az NSX Manager felületére kerülünk, ami egy iframe a vCenter Server ablakában. Semmiféle egyéb integráció nincs, tehát értelme nem sok van az a vCenter-ből kigördített security only opciónak – az overlay+security opciónál már más lenne a helyzet.
Keressük meg a szabályokat, amelyeket a varázsló hozott létre. Ahogy a legtöbb hasonló tűzfal termékben úgy itt is balról jobbra és fentről lefelé érvényesülnek a szabályok. Az infrastruktúra szabályok így a saját szekciójukban jöttek létre és tényleg annak megelelően, ahogyan azt abban a korábbi és meglehetősen egyszerű ablakban beállíthattuk. Alább persze lehetőség van layer 7 szintű szabályt kreálni, míg a varázslóban csak layer 4 volt elérhető.
Mi kell ahhoz, hogy a default szabályt nyugodt szívvel átállíthassuk drop/reject-re?
Tapasztalataim szerint három út vezethet el ehhez:
- az összes olyan rendszer tekintetében – ahol cél és/vagy forrás – rendelkezünk a szükséges portokkal – context profile (L7) – szabályrendszerrel.
- VMware Aria Operations for Networks – néhai nevén Network Insight – terméket haszálunk.
- kidolgozunk egy folyamatot, amivel kezelhető csoportokban derítjük fel a szükséges szabályokat.
Az első sosincs meg, a második sokszor pénzbe kerül – bár van olyan NSX kiadás amihez jár – szóval általában a harmadikat választja mindenki. Ehhez azonban mindenképpen szükség van egy jó naplózási megoldásra. Adódik a VMware Aria for Logs – néhai nevén vRealize Log Insight – használata, de bármi jó lehet, ami tud syslog cél lenni az ESXi kiszolgálók számára.
Erre azért van szükség, mert a distributed tűzfal szabályain beállított naplózás az ESXi kiszolgálókon generál bejegyzéseket, azok naplófájljaiban, tehát kell valamilyen megoldás, amivel központilag lehet ezeket a naplókat áttekinteni.
A következő részben a „VMware Aria for Logs” segítségével mutatom meg ezt a gyakorlatban!
