VMware Hardening – Deo 1: ESXi hipervizor bezbednost

Ovim tekstom počinje nova serija posvećena hardeningu VMware infrastrukture — prvo ESXi, hipervizor koji pokreće same virtuelne mašine, zatim u nastavku serije vCenter i mrežni sloj (vSwitch/vMotion). Isti princip koji smo primenili na Hyper-V u ranijoj seriji na ovom blogu važi i ovde: host je jedna tačka kontrole nad svime što na njemu radi, i bezbednost hipervizora je gornja granica bezbednosti svakog VM-a koji taj hipervizor pokreće, bez obzira na to koliko je pažljivo hardenovan operativni sistem unutar svakog pojedinačnog VM-a. Prvi deo pokriva osnovu ESXi hosta — pristup, upravljanje, i osnovna zaštita boot procesa.

Lockdown Mode — ograničavanje puteva ka hostu, ne samo ko ima pristup

Ovo je najvažniji, centralni koncept u hardeningu pojedinačnog ESXi hosta, pa zaslužuje detaljno objašnjenje mehanizma. Podrazumevano, ESXi host može biti administriran na dva paralelna načina — direktno, lokalno na samom hostu (preko DCUI konzole, ESXi Shell-a ili SSH-a), ili posredno, kroz vCenter Server koji centralno upravlja svim hostovima. Problem sa ova dva paralelna puta je da direktan, lokalan pristup zaobilazi role, dozvole i audit koje vCenter centralno primenjuje — administrator (ili napadač sa ukradenim root kredencijalima) koji se prijavi direktno na host preko SSH-a radi mimo bilo kog centralnog nadzora.

Lockdown Mode rešava ovaj problem tako što onemogućava direktnu administraciju hosta, prisiljavajući sve operacije da prolaze isključivo kroz vCenter. Postoje dva nivoa: normalni Lockdown Mode i dalje dozvoljava određenim, imenovanim korisnicima (Exception Users lista) da se lokalno prijave preko DCUI konzole za osnovnu dijagnostiku, dok strogi (strict) Lockdown Mode potpuno zaustavlja DCUI servis, ne dozvoljavajući root pristup ni preko fizičke konzole hosta.

Šta treba uraditi

• Uključiti Lockdown Mode na svakom produkcionom ESXi hostu, sa strogim (strict) režimom kao ciljem za okruženja gde je vCenter dostupnost pouzdana — normalni režim kao prihvatljiv kompromis tamo gde je povremena, direktna DCUI dijagnostika bez vCenter-a stvarna operativna potreba
• Definisati Exception Users listu usko i namerno — samo nalozi koji imaju konkretnu, dokumentovanu potrebu za direktnim pristupom van vCenter-a treba da budu na toj listi, ne ceo administratorski tim "za svaki slučaj"
• Zadržati SSH i ESXi Shell servise isključenim po difoltu (podrazumevano stanje), i uključivati ih samo privremeno, za tačno određen zadatak, uz odmah gašenje nakon završetka — dugotrajno uključen SSH na produkcionom hostu je propust koji zaslužuje istu pažnju kao i otvoren RDP port opisan u Windows Server hardening seriji
• Postaviti automatski tajmer koji ograničava koliko dugo ESXi Shell i SSH servisi mogu ostati aktivni pre nego što se sami ugase, kao dodatnu, automatizovanu zaštitu za slučaj da neko zaboravi da ih ručno isključi nakon završenog zadatka

Napomena o riziku: uključivanje strogog Lockdown Mode-a pre nego što je veza sa vCenter Server-om potvrđeno stabilna i pouzdana nosi realan rizik potpunog zaključavanja iz hosta — ako vCenter postane nedostupan (mrežni problem, sopstveni pad vCenter servera) dok je host u strogom Lockdown Mode-u, ni lokalna DCUI konzola ne pruža izlaz. Testirati vCenter konekciju i njenu pouzdanost pre uključivanja strogog režima, i imati jasno dokumentovanu proceduru za slučaj nužde (npr. privremeno vraćanje na normalni režim preko fizičke konzole, gde je to još uvek moguće) pre nego što se stroga varijanta primeni na kritičnu produkcionu infrastrukturu.

Lozinke i autentifikacija na nivou hosta

ESXi koristi pam_passwdqc modul za proveru kompleksnosti lozinki, ali podrazumevana podešavanja tog modula nisu uvek dovoljno stroga za produkciono okruženje bez dodatnog podešavanja. Isti princip discipline lozinki opisan kroz celu ovu seriju blogova (dužina i složenost kao prioritet nad čistom, mehaničkom rotacijom, MFA gde je izvodljivo) primenjuje se i ovde, sa dodatnom napomenom specifičnom za ESXi kontekst — pošto ESXi hostovi retko imaju istu, čvrstu integraciju sa centralnim identity sistemom kao standardni serveri, disciplina oko same lokalne root lozinke dobija veći značaj.

Šta treba uraditi

• Postaviti stroža pravila kompleksnosti lozinke kroz pam_passwdqc konfiguraciju, ne osloniti se na podrazumevane vrednosti koje mogu dozvoliti relativno slabe lozinke
• Gde okruženje to podržava, integrisati ESXi hostove sa Active Directory-jem za administratorsku autentifikaciju, umesto isključivog oslanjanja na lokalni root nalog — ovo omogućava korišćenje AD grupa i centralizovane politike lozinki opisane kroz AD hardening seriju, uz jasnu, individualno praćenu autentifikaciju umesto deljenog root pristupa
• Imati u vidu poznato, dokumentovano ograničenje AD integracije kod ESXi-ja — implementacija ima istorijske slabosti oko obnavljanja Kerberos tiketa, i host bez ispravno podešenog rezervnog (fallback) metoda autentifikacije može postati praktično nedostupan ako AD veza otkaže; testirati ovaj scenario pre oslanjanja na AD integraciju kao jedini put administracije
• Čuvati root lozinku (ili rezervni pristup, ako je host integrisan sa AD-om) na bezbednoj, dobro dokumentovanoj lokaciji dostupnoj ograničenom krugu ljudi, po istom principu čuvanja kritičnih kredencijala opisanom kroz svaku prethodnu seriju

Zaštita boot procesa — UEFI Secure Boot i TPM

UEFI Secure Boot je deo standarda firmvera koji odbija da učita bilo koji bootloader, drajver ili kernel modul čiji digitalni potpis nije validan — za ESXi, ovo znači da host neće pokrenuti hipervizor ako je neko neovlašćeno izmenio kernel module ili VIB (vSphere Installation Bundle) pakete, jer izmenjena verzija neće imati validan potpis. Noviji ESXi hostovi dodatno mogu koristiti TPM čip za proveru integriteta celog boot lanca počev od UEFI firmvera pa naovamo, pružajući stroži nivo garancije od standardnog Secure Boot-a samog.

Šta treba uraditi

• Uključiti UEFI Secure Boot u BIOS/firmver podešavanjima fizičkog servera pre instalacije ESXi-ja, gde hardver to podržava — ovo je podešavanje na nivou firmvera, ne nešto što se naknadno uključuje kroz sam ESXi bez ponovne instalacije
• Gde je dostupno, uključiti TPM-baziranu Secure Boot proveru (Secure Boot Enforcement) za dodatan nivo garancije integriteta celog boot lanca
• Postaviti prihvatljiv nivo (acceptance level) za VIB pakete tako da se prihvataju isključivo paketi potpisani od strane VMware-a ili verifikovanih partnera — izbegavati CommunitySupported ili niže nivoe prihvatanja na produkcionim hostovima, jer oni dozvoljavaju instalaciju nepotpisanih ili slabije verifikovanih paketa
• Za okruženja sa povišenim zahtevima za integritet (posebno relevantno u kontekstu rastuće ransomware pretnje usmerene direktno na ESXi infrastrukturu), razmotriti execInstalledOnly podešavanje, koje dozvoljava izvršavanje isključivo binarnih fajlova instaliranih kroz zvanično potpisan VIB, blokirajući izvršavanje proizvoljnog koda čak i sa root privilegijama — ovo direktno otežava jedan od poznatih obrazaca napada gde ransomware grupe ciljano napadaju ESXi hostove kako bi jednim potezom enkriptovale sve VM-ove koje taj host pokreće

Napomena o riziku: uključivanje UEFI Secure Boot-a nakon što je ESXi već instaliran bez njega zahteva ponovnu instalaciju, ne prostu izmenu podešavanja — planirati ovo unapred, pri prvobitnom postavljanju hosta, jer naknadno uvođenje na aktivnom, produkcionom hostu nosi znatno veći operativni trošak. execInstalledOnly podešavanje takođe može ometati rad alata ili skripti koji očekuju mogućnost izvršavanja proizvoljnih binarnih fajlova direktno na hostu (uobičajeno kod nekih starijih backup ili monitoring agenata) — proveriti kompatibilnost postojećih alata pre uključivanja ovog podešavanja na produkcionoj infrastrukturi.

Osnovna higijena servisa i pristupa

Isti princip minimizacije površine napada opisan kroz Windows i Linux Server hardening serije važi i za ESXi — svaki nepotreban servis ili protokol koji ostane uključen je dodatna, nepotrebna prilika za napadača.

Šta treba uraditi

• Isključiti SLP (Service Location Protocol) servis ako se ne koristi — ovaj protokol je istorijski bio meta poznatih ranjivosti, i retko je stvarno neophodan u modernim implementacijama
• Isključiti SNMP ako se ne koristi za monitoring, a ako se koristi, koristiti isključivo noviju SNMPv3 verziju sa autentifikacijom i enkripcijom, ne starije, nezaštićene verzije protokola
• Ograničiti CIM (Common Information Model) pristup na nivo koji odgovara stvarnoj potrebi monitoring alata koji ga koriste, ne ostavljati na najširem, podrazumevanom nivou
• Konfigurisati ugrađeni ESXi host firewall da eksplicitno dozvoljava pristup samo sa poznatih, upravljačkih mrežnih segmenata, po istom "default deny, eksplicitno dozvoli" principu koji se provlači kroz svaku seriju na ovom blogu
• Postaviti persistent log lokaciju na ESXi hostu (podrazumevano, logovi mogu biti samo u memoriji na hostovima bez lokalnog diska ili sa specifičnom konfiguracijom, čime se gube pri restartu) i prosleđivati logove na centralni, udaljeni log server sa TLS zaštitom konekcije

Sledeći deo serije prelazi na vCenter Server — centralnu tačku upravljanja celom VMware infrastrukturom, i upravo zato posebno atraktivnu metu, gde ćemo pokriti autentifikaciju, role i dozvole (RBAC), i zaštitu same vCenter baze podataka.