Új év, új kérdések és feladatok. Az NSX-T tűzfalazási és mikroszegmentációs képességeiről már írtam elég sokszor korábban, ez nem lehet újdonság senkinek sem, aki legalább egy előadást hallott már a témában. Pár éve találkoztam egy olyan ügyféllel, ahol a root (azaz a .) fel volt véve minden tartományvezérlő DNS-ébe mint zóna. A tűzfalon minden más DNS szerver tiltva volt a kliensek számára, csak a DC-ket használhatták DNS-ként, aki értheően csak azokat a kéréseket tudta kiszolgálni, amiről ő tud. Mivel a root zóna is fel volt véve ezért amit ő nem tudott, az nem is létezett. Mondhatni, hogy ez a megoldás egész jó – bár fals biztonságot sugall – de a modern világban lehetetlen a használata. Miért?
Azért mert akkor rájött az ügyfél hogy ő szeretne O365-ba költözni a levelezéssel. Viszont itt nem egyetlen IP-ről van szó amit felveszünk a szükséges zónába a DC-n – igen, mivel a root is rajta van – hanem több IP-ről, amelyek akár meg is változhatnak amikor a Microsoft úgy akarja. Ezt lekövetni saját DNS-ben, nem lehet.
Hasonló ez a tűzfallal is, azaz az olyan szabályok amelyek FQDN-t tartalmaznak, kihívás elé állítják a rendszert, hiszen a tűzfalnak kell lekezelnie, hogy mikor egy belső kliens az adott FQDN-el forgalmazna, feloldja azt IP-re és kezelje a forgalmat.
Az NSX-ben a Layer 7 képesség, azaz hogy context aware a tűzfala, pont erre használható. Sőt ez az FQDN/URL dolog simán megvalósítható már.
Azért írom hogy már, mert a 3.1-ig volt a gyári beégetett FQDN lista – a szerintük leggyakrabban használt elemekkel – és azokra lehetett szűrni.
A 3.1-ben megjelent a custom FQDN is, így végre szabadon lehet használni bármilyen FQDN-re amit szeretnénk.
Hogy kell?
- A kívánt FQDN/URL létrehozása – ha nem található alapértelmezetten.
Az NSX Manager-be belépve az Inventory -> Context Profiles -> FQDNs alatt látható az összes gyárilag beépített domain. A példa kedvéért én saját domain-en mutatom be a megoldást, a server.newman.cloud segítségével. (csak a teszt idején oldódik fel DNS-ben, mivel egy Azure-ban futó VM csak erre a célra)
2. A megfelelő Context profile létrehozása az előbb megadott FQDN(FQDNek) alapján.
Az első pontban létrehozott FQDN hozzáadása.
3. A DFW szabályok létrehozása.
Magyarázom rögvest, rule ID szerint:
- Rule ID 2: ez defult rule, ami nem tesz mást, mint minden forgalmat drop-ra tesz, ha egyetlen fentebbi szabályban sincs match.
- Rule ID 9192: Ez az egyik releváns szabály, ami azért kell, hogy az NSX-T deep packet inspection-nel ki tudja deríteni, hogy a VM-ből indított lekérés FQDN/URL-je milyen IP-re oldódik fel. Itt látható hogy a Services résznél DNS TCP és UDP is be van állítva – you mileage may vary – illetve hogy a context profile az DNS.
- Rule ID 9193: Itt adjuk meg hogy a korlátozni kívánt virtuális gépről a HTTP/HTTPS kérések mely cél FQDN/URL-re legyenek engedélyezve. Látható, hogy visszaköszön a Context profile amit a második pontban hoztunk létre.
Az applied to mező használatát nem mutatom be, akinek új, az olvasson vissza nálam.
Tesztelés
Ha minden jól megy, akkor a http://server.newman.cloud címen egy IIS kezdőlap köszönt. Megpróbálom megnyitni a https://blog.99999.hu-t is, annak nem szabad működnie.
Engedélyezzük a *.99999.hu-t is. Ehhez meg kell ismételni a 1-es pontot és a másodikban azt is hozzáadni a Context Profile-hoz.
Újabb teszt alapján már a https://blog.99999.hu is betöltődik.
Oké, http és https esetén ez eddig működik. Mi van akkor, ha például egy SSH-t vagy egy RDP-t kell így szűrni? Nyilvánvalóan az éppen érvényes szabályok csak a HTTP/HTTPS standard portokat engedélyezik szóval az RDP a TCP/3389-en nem megy.
Akkor állítsuk be ezt is, kiegészítve a már meglévő szabályt.
Megismételve az RDP-s csatlakozást, nyugtázzuk a sikerességet.
Ez mind szép és jó, de itt most portot engedélyeztünk tulajdonképpen, tehát ha például a TCP3389-ra átteszem az IIS-t, akkor is engedélyezett lesz a kommunikáció.
Itt két Context Profile-ra váltani, egyikben a HTTP/HTTPS service-t és a HTTP/SSL protokollt megadni, a másikban pedig az RDP service-et és egyező nevű protokollját. Ezt a kettőt pedig külön szabályba tenni – mivel egy szabályban nem enged több context profile-t. Így biztosan lehetünk abba hogy például a TCP/80-on http fog menni és véletlen sem RDP.
Összefoglaló
Nagyon komoly szabályrendszert lehet összehozni DFW-ben, igazából csak a képzelet szab határt annak, mennyire szofisztikáljuk a struktúrát. A képesség itt van, könnyen használható.
