Proxmox Hardening – Deo 2: Mrežna segmentacija i VM/kontejner firewall

Prvi deo serije pokrio je host bezbednost — pristup, autentifikaciju, osnovni firewall. Drugi deo ide dublje u mrežni sloj: kako razdvojiti različite tipove saobraćaja unutar Proxmox okruženja, i kako sprečiti da kompromitovan VM ili kontejner slobodno komunicira sa svime ostalim na istom hostu ili klasteru. Isti obrazac koji smo detaljno obradili za Kubernetes NetworkPolicy u ranijoj seriji na ovom blogu ponavlja se ovde, u drugačijem kontekstu: podrazumevano, sve je otvoreno, i mrežna segmentacija je svestna odluka koju administrator mora doneti, ne nešto što dolazi automatski.

Podrazumevani bridge — "svako sa svakim", isti problem kao kod Kubernetes-a

Ovo je verovatno najvažnija tačka celog dela, pa vredi je istaći na samom početku, po istom principu kao i kod Kubernetes NetworkPolicy dela serije. Podrazumevano, svi VM-ovi i kontejneri povezani na isti virtuelni bridge (tipično vmbr0) mogu slobodno da komuniciraju jedni sa drugima, bez ikakvog filtriranja — potpuno otvorena, "flat" mreža. Ovo znači da kompromitovan, javno izložen veb server na istom bridge-u kao interna baza podataka ili backup sistem ima direktan, nesputan mrežni put do njih, bez ijedne dodatne prepreke osim onoga što je eventualno podešeno unutar samih tih VM-ova. Isti obrazac lateralnog kretanja koji smo opisali za ransomware napade kroz celu ovu seriju o virtuelizaciji ovde nalazi svoj najčistiji, najjednostavniji put — flat mreža bez ikakve segmentacije.

VLAN-aware bridge — preporučen pristup za segmentaciju

Proxmox podržava dva pristupa VLAN segmentaciji: kreiranje odvojenog bridge-a za svaki VLAN, ili korišćenje jednog, VLAN-aware bridge-a gde se VLAN oznaka dodeljuje na nivou pojedinačnog VM-a ili kontejnera. Drugi pristup je opšte preporučen — čistiji je za održavanje i bolje se skalira kako broj VLAN-ova raste, jer ne zahteva kreiranje novog bridge objekta za svaki dodatni segment.

Šta treba uraditi

• Konfigurisati glavni bridge (npr. vmbr0) kao VLAN-aware (bridge-vlan-aware yes), uz definisan opseg dozvoljenih VLAN identifikatora (bridge-vids)
• Dodeljivati VLAN oznaku direktno na nivou mrežnog uređaja svakog VM-a ili kontejnera kroz Proxmox web interfejs ili konfiguraciju, umesto kreiranja posebnog bridge-a za svaki segment
• Grupisati radna opterećenja po nivou poverljivosti ili funkciji u odvojene VLAN segmente — na primer, odvojiti javno izložene servise, interne aplikacije, i upravljačku infrastrukturu (uključujući sam Proxmox management pristup) u zasebne segmente, po istom principu segmentacije koji se provlači kroz svaku prethodnu seriju na ovom blogu
• Imati na umu da VLAN-aware bridge sam po sebi obezbeđuje mrežnu izolaciju na L2 nivou (VM-ovi na različitim VLAN oznakama se podrazumevano ne mogu videti), ali ne kontroliše saobraćaj unutar istog VLAN-a — za to je potreban firewall opisan dalje u tekstu

Napomena o riziku: uvođenje VLAN segmentacije na postojećoj, aktivnoj infrastrukturi zahteva usklađenu konfiguraciju i na Proxmox strani i na fizičkom mrežnom switch-u (trunk port sa dozvoljenim VLAN opsegom) — nesklad između ta dva (npr. switch port koji ne prosleđuje sve potrebne VLAN oznake) rezultuje u VM-ovima koji iznenada gube mrežnu povezanost bez očigledne greške na Proxmox strani. Testirati svaku VLAN promenu na jednom, manje kritičnom VM-u pre šire primene, i imati potvrđenu konfiguraciju fizičkog switch porta pre oslanjanja na VLAN segmentaciju kao stvarnu meru izolacije.

Proxmox firewall na VM/kontejner nivou — filtriranje unutar istog segmenta

Proxmox ugrađeni firewall, pomenut u prvom delu serije na datacenter i node nivou, proteže se i na pojedinačan VM ili kontejner. Tehnički, ovo radi kroz iptables-bazirani servis koji se izvršava na svakom čvoru klastera pojedinačno (ne kroz centralizovanu firewall napravu), što znači da filtriranje ostaje aktivno i funkcionalno čak i ako komunikacija nikad ne napusti fizički host — dva VM-a na istom hostu i istom bridge-u i dalje prolaze kroz ovo filtriranje ako je uključeno na njihovom nivou.

Security Groups u Proxmox-u igraju ulogu analognu onoj koju NetworkPolicy label selektori igraju u Kubernetes-u — omogućavaju definisanje skupa pravila jednom, i njegovu ponovnu upotrebu na više VM-ova ili kontejnera koji dele istu bezbednosnu ulogu, umesto ručnog pisanja identičnih pravila za svaki pojedinačni VM.

Šta treba uraditi

• Uključiti firewall na nivou svakog VM-a i kontejnera koji zaista treba mrežnu izolaciju, ne samo na datacenter/node nivou — ovo je poslednji, najgranularniji sloj kontrole, i njegovo izostavljanje ostavlja rupu čak i kad su viši nivoi dobro podešeni
• Kreirati Security Groups za funkcionalne kategorije radnih opterećenja (npr. "web-servers", "internal-db", "management") i primenjivati ih dosledno na sve VM-ove/kontejnere te kategorije, po istom principu ponovne upotrebe pravila opisanom za Kubernetes NetworkPolicy u ranijoj seriji
• Postaviti podrazumevanu politiku na "odbij" za dolazni saobraćaj na nivou VM-a, sa eksplicitno dozvoljenim portovima koje ta konkretna aplikacija stvarno koristi — isti "default deny" princip koji se ponavlja kroz svaku seriju na ovom blogu
• Za VM-ove koji nikad ne treba da imaju direktan izlaz ka internetu (npr. interna baza podataka), ograničiti odlazni saobraćaj na tačno određene, potrebne destinacije, po istom principu opisanom za bazu podataka u Docker delu Container Hardening serije

Corosync — mrežni saobraćaj koji zahteva posebnu, izdvojenu pažnju

Ovo je tema specifična za klaster konfiguraciju (više Proxmox hostova povezanih zajedno), ali vredi je pokriti detaljno jer greška ovde ima ozbiljne posledice po stabilnost, ne samo po bezbednost. Corosync je protokol koji čvorovi klastera koriste za međusobnu komunikaciju o stanju ("heartbeat") — izuzetno je osetljiv na latenciju i gubitak paketa, i deli mrežni segment sa saobraćajem velikog obima (npr. storage replikacija ili live migracija VM-ova) redovno dovodi do toga da Corosync gubi vezu sa ostatkom klastera, što klaster tumači kao da je taj čvor otkazao — poznat obrazac koji izaziva takozvani "split-brain" scenario, gde delovi klastera pogrešno veruju da su ostali čvorovi nedostupni i preduzimaju konfliktne akcije.

Šta treba uraditi

• Izdvojiti Corosync saobraćaj na sopstveni, dedikovan mrežni segment (fizička mrežna kartica ili barem posebna VLAN oznaka), potpuno odvojen od saobraćaja skladišta (storage) i live migracije VM-ova — ovo nije opciona preporuka za performanse, već preduslov za stabilnost klastera
• Konfigurisati bar dva odvojena Corosync linka (redundantni "ring0"/"ring1" pristup) preko fizički različitih mrežnih putanja, tako da otkaz jednog switch-a ili kabla ne ugrozi komunikaciju celog klastera
• Nikad ne deliti isti mrežni segment između Corosync-a i saobraćaja skladišta (npr. Ceph replikacija) — ovo je eksplicitno, ponovljeno upozorenje u zvaničnoj Proxmox dokumentaciji, jer intenzivan storage saobraćaj (posebno tokom oporavka nakon otkaza diska) rutinski zasićuje mrežu do te mere da Corosync heartbeat prestaje da stiže na vreme
• Onemogućiti Spanning Tree Protocol (STP) na portovima switch-a koji povezuju Proxmox bridge-ove, ili koristiti portfast/edge-port ekvivalent — STP izaziva kašnjenje od 30 do 50 sekundi pri podizanju linka, što može izazvati lažne Corosync timeout-e tačno u trenutku kad je mrežna veza zapravo ispravna, samo sporo inicijalizovana

Napomena o riziku: greška u Corosync mrežnoj konfiguraciji ne manifestuje se odmah kao očigledan bezbednosni problem, već kao nestabilnost celog klastera — čvorovi koji se neočekivano izbacuju iz kvoruma, VM-ovi koji se automatski migriraju bez jasnog razloga, ili u gorem slučaju, split-brain scenario gde dva dela klastera istovremeno pokušavaju da upravljaju istim resursom. Ovo direktno ugrožava i dostupnost i integritet podataka, ne samo mrežnu bezbednost u užem smislu — planirati Corosync mrežni dizajn pažljivo unapred, pre uspostavljanja klastera, jer naknadna izmena na aktivnom, produkcionom klasteru nosi realan rizik privremene nestabilnosti tokom same promene.

Izolacija upravljačkog pristupa od VM saobraćaja

Isti princip segmentacije upravljačke mreže koji se provlači kroz svaku seriju na ovom blogu (od AD, preko Hyper-V, do VMware) primenjuje se i ovde — web interfejs (port 8006) i SSH pristup Proxmox hostu ne treba da dele mrežni segment sa saobraćajem samih VM-ova, posebno ako neki od tih VM-ova imaju izlaz ka internetu ili manje poverljivim mrežama.

Šta treba uraditi

• Postaviti upravljački pristup (web interfejs, SSH) na dedikovan VLAN ili fizički odvojenu mrežnu karticu, dostupnu isključivo sa poznate, ograničene administrativne mreže
• Za scenarije gde su pojedini VM-ovi izloženi internetu ili manje poverljivim mrežama, potvrditi da ti VM-ovi nemaju mrežnu vidljivost ka upravljačkom segmentu Proxmox hosta, čak i ako su formalno na istom fizičkom hostu
• Za složenije scenarije koji zahtevaju kontrolisanu komunikaciju između različitih VLAN segmenata (npr. jedan segment sme da dopre do određenog servisa u drugom, ali ne obrnuto), koristiti namensku virtuelnu ruter/firewall aplikaciju (npr. pfSense ili OPNsense, koje rade odlično kao VM unutar samog Proxmox-a) kao kontrolnu tačku između segmenata, umesto pokušaja da se sva ta logika izrazi isključivo kroz osnovna Proxmox firewall pravila

Ovim se zaokružuje pregled mrežnog sloja Proxmox hardeninga — segmentacija VM saobraćaja, VM-nivo firewall filtriranje, i posebna pažnja posvećena Corosync stabilnosti klastera. Sledeći, poslednji deo serije bavi se zaštitom samih VM diskova i backup infrastrukture — enkripcijom skladišta, i specifično Proxmox Backup Server-om (PBS) kao namenskim, integrisanim rešenjem za backup cele Proxmox infrastrukture.