Proxmox Hardening – Deo 1: Host bezbednost i osnovni pristup

Ovim tekstom počinje nova serija posvećena hardeningu Proxmox VE — sve popularnijoj, besplatnoj alternativi VMware i Hyper-V virtuelizaciji, izgrađenoj na Debian Linux osnovi. Isti fundamentalni princip koji smo primenili na Hyper-V i VMware serijama na ovom blogu važi i ovde, samo sa jednom dodatnom, važnom napomenom specifičnom za Proxmox: sam Proxmox management sloj radi kao root proces na hostu, što znači da kompromitacija host sistema ne pogađa "samo" hipervizor u apstraktnom smislu, već direktno, neposredno, svaki VM i kontejner koji taj host pokreće. Prvi deo pokriva osnovu — pristup web interfejsu, SSH, i osnovnu bezbednosnu higijenu Debian osnove na kojoj Proxmox radi.

Podrazumevana instalacija nije podešena za produkciju

Vredi ovo reći direktno na početku, jer je čest izvor iznenađenja: sveža Proxmox VE instalacija je funkcionalna, ali ne i bezbedna po difoltu. Web interfejs (port 8006) radi bez ograničenja brzine pokušaja prijave, SSH prihvata autentifikaciju lozinkom, ugrađeni firewall je isključen, i sam root nalog je odmah dostupan i preko web interfejsa i preko SSH-a bez ikakvog dodatnog sloja zaštite. Ovo nije propust u dizajnu — Proxmox tim namerno prioritizuje jednostavnost prve instalacije, ostavljajući hardening kao svestan, naknadni korak administratora.

SSH — isti princip kao i za svaki drugi Linux server, sa jednim dodatnim upozorenjem

Veći deo preporuka iz ranije serije o hardeningu Linux servera direktno se primenjuje ovde, budući da Proxmox radi na Debian osnovi — SSH ključevi umesto lozinke, zabrana root prijave, ograničavanje pristupa na poznate mrežne segmente. Vredi, međutim, istaći jedno upozorenje specifično za Proxmox kontekst pre nego što se krene sa isključivanjem: za razliku od tipičnog Linux servera, Proxmox host često zahteva SSH pristup i za rutinske administrativne zadatke koje web interfejs ne pokriva u potpunosti (npr. izmena mrežne konfiguracije prilikom dodavanja novog PCIe uređaja, dijagnostika kad web interfejs iz nekog razloga nije dostupan) — potpuno isključivanje SSH-a je zato ređe opravdano nego na standardnom aplikativnom serveru.

Šta treba uraditi

• Onemogućiti SSH prijavu lozinkom (PasswordAuthentication no) i prijavu root korisnika preko SSH-a (PermitRootLogin no), po istom principu opisanom u seriji o hardeningu Linux servera
• Kreirati imenovan administratorski Linux nalog (ne root) sa sudo pravima za administraciju host operativnog sistema, odvojeno od Proxmox-specifičnog korisničkog naloga opisanog dalje u tekstu
• Zadržati SSH aktivan, ali strogo ograničen na nivou firewall-a (opisano dalje u tekstu) na poznat, uzak upravljački mrežni segment, umesto potpunog isključivanja servisa — praktičnost potrebe za povremenim SSH pristupom kod Proxmox-a nadmašuje marginalnu dodatnu korist od potpunog gašenja u odnosu na strogo ograničen pristup
• Ako se razmatra promena SSH porta na nestandardni, tretirati to isključivo kao meru za smanjenje "pozadinske buke" automatizovanog skeniranja u logovima (isti princip opisan u Linux Server hardening seriji), ne kao stvarnu bezbednosnu meru protiv ciljanog napada

Napomena o riziku: pre bilo koje izmene SSH ili firewall konfiguracije, obavezno obezbediti alternativan put pristupa hostu — IPMI/iDRAC/BMC daljinska konzola, ili fizički pristup monitoru i tastaturi. Za razliku od tipičnog Linux servera gde je greška u SSH konfiguraciji neprijatna, ali rešiva, na Proxmox hostu greška koja odseče pristup istovremeno odseca i mogućnost administracije svih VM-ova i kontejnera na tom hostu preko web interfejsa, ako je i ono pogođeno istom greškom u firewall pravilima. Testirati svaku izmenu iz odvojene sesije pre zatvaranja postojeće, po istom principu predostrožnosti opisanom kroz celu ovu seriju blogova.

Web interfejs — glavna, svakodnevna administrativna površina

Proxmox web interfejs (port 8006) pruža punu administrativnu kontrolu nad hostom i svim VM-ovima/kontejnerima koje pokreće, i u praksi je primarni alat za svakodnevni rad, više nego SSH ili komandna linija. Upravo zato zaslužuje istu pažnju kao i sam SSH pristup.

Šta treba uraditi

• Ograničiti mrežni pristup portu 8006 na poznat, upravljački mrežni segment kroz firewall pravila (opisana dalje u tekstu) — web interfejs ne treba da bude dostupan sa opšte korisničke mreže, a pogotovo ne direktno sa interneta
• Uključiti dvofaktorsku autentifikaciju (2FA) za sve administratorske naloge koji pristupaju web interfejsu — Proxmox VE ima ugrađenu, nativnu podršku za TOTP (Time-based One-Time Password) bez potrebe za dodatnim, spoljnim modulom, kao i podršku za hardverske ključeve poput YubiKey-a
• Zahtevati 2FA na nivou realm-a (autentifikacionog domena), ne samo omogućiti je kao opciju — razlika je bitna, jer opcionalna 2FA ostavlja zaštitu na volji svakog pojedinačnog korisnika, dok obavezna primena osigurava dosledno pokrivanje svih naloga
• Za pristup van same lokalne, upravljačke mreže, koristiti VPN (npr. WireGuard, koji se dobro uklapa u Proxmox okruženja zbog jednostavnosti i performansi) umesto direktnog izlaganja porta 8006 internetu, bez obzira na to koliko su ostale mere zaštite dobro postavljene

root@pam — tretirati kao break-glass, ne kao svakodnevni nalog

Proxmox koristi format korisnik@realm za identifikaciju naloga, gde je root@pam podrazumevani, ugrađeni administratorski nalog koji se oslanja na standardnu Linux PAM autentifikaciju hosta. Isti princip opisan za break-glass nalog u vCenter delu VMware hardening serije primenjuje se ovde direktno — root@pam treba tretirati kao rezervni pristup za slučaj nužde, ne kao nalog za svakodnevnu administraciju.

Šta treba uraditi

• Kreirati odvojen, imenovan Proxmox korisnički nalog (npr. u pam ili, još bolje, u posebnom realm-u ako se koristi centralizovana autentifikacija) za svakodnevnu administraciju, sa dodeljenom Administrator ulogom kroz Proxmox-ov sopstveni permission sistem, umesto stalne prijave kao root@pam
• Zadržati root@pam kredencijale bezbedno čuvane, van svakodnevne upotrebe, sa istim nivoom pažnje opisanim za break-glass naloge kroz celu ovu i prethodne serije o virtuelizaciji
• Uključiti 2FA i na root@pam nalogu, ne samo na svakodnevnim administratorskim nalozima — upravo zato što je ovo nalog sa najvišim privilegijama, zaslužuje najmanje, ne najviše, izuzetaka od standardnih mera zaštite
• Auditirati svaku prijavu pod root@pam nalogom (Proxmox beleži ovo u sistemskom logu) sa povišenim prioritetom, po istom principu opisanom za break-glass naloge u VMware seriji

Ugrađeni firewall — tri sloja, isključen po difoltu

Proxmox dolazi sa sopstvenim, ugrađenim firewall sistemom (izgrađenim iznad standardnog Linux netfilter/iptables mehanizma opisanog u ranijoj seriji o hardeningu Linux servera) koji radi na tri nivoa: datacenter (podrazumevana politika za sav klaster), node (pravila specifična za pojedinačan host), i VM/kontejner nivo (pravila specifična za pojedinačno radno opterećenje). Ovaj firewall je, međutim, isključen po difoltu na svežoj instalaciji.

Šta treba uraditi

• Uključiti ugrađeni Proxmox firewall na datacenter nivou, sa podrazumevanom politikom "odbij" (deny) za dolazni saobraćaj, po istom "default deny" principu koji se provlači kroz svaku seriju na ovom blogu
• Eksplicitno dozvoliti isključivo neophodne portove i servise — web interfejs (8006), SSH, i, u klaster konfiguraciji, portove potrebne za komunikaciju između čvorova klastera, kao i protokole za deljeno skladište (NFS, iSCSI, CIFS) ako se koriste
• Postaviti pravilo koje dozvoljava već uspostavljene i povezane konekcije (ESTABLISHED, RELATED) na sam vrh liste pravila — firewall pravila se procesiraju odozgo nadole, i ovo pravilo mora biti pre restriktivnijih pravila kako se ne bi nenamerno prekinule već aktivne, legitimne konekcije
• Koristiti node-nivo pravila za dodatna, host-specifična ograničenja iznad datacenter podrazumevane politike, a VM/kontejner-nivo pravila za segmentaciju pojedinačnih radnih opterećenja jedno od drugog — ovo poslednje detaljnije obrađujemo u sledećem delu serije o mrežnoj segmentaciji

Napomena o riziku: uključivanje firewall-a sa restriktivnom politikom pre nego što je SSH i web interfejs pristup eksplicitno dozvoljen nosi isti rizik samozaključavanja opisan kroz celu ovu seriju blogova za slične promene — testirati svaku izmenu iz odvojene sesije, i imati potvrđen alternativan pristup (IPMI/fizička konzola) pre primene restriktivnih pravila na produkcionom hostu.

Ažuriranje sistema — repozitorijum koji zaslužuje posebnu pažnju

Proxmox po difoltu pokušava da koristi Enterprise repozitorijum za ažuriranja, koji zahteva plaćenu pretplatu — bez nje, pokušaji ažuriranja vraćaju grešku i, što je bitnije, mnogi administratori bez pretplate jednostavno prestanu da pokušavaju ažuriranje kad se prvi put suoče sa tom greškom, ostavljajući sistem nezakrpljen mesecima. Proxmox nudi besplatan, javno dostupan No-Subscription repozitorijum kao legitimnu alternativu za okruženja bez plaćene pretplate.

Šta treba uraditi

• Za okruženja bez Enterprise pretplate, eksplicitno preći na No-Subscription repozitorijum, kako bi redovna ažuriranja mogla nesmetano da prolaze — isti princip discipline ažuriranja opisan u Linux Server hardening seriji, koji ne funkcioniše ako je sam izvor ažuriranja pogrešno podešen
• Sprovoditi redovan ciklus ažuriranja (`apt-get update && apt-get dist-upgrade`), po istom principu discipline zakrpa opisanom kroz seriju o hardeningu Linux servera, uz istu opreznost oko planiranja restarta na produkcionom hostu koji trenutno pokreće aktivna radna opterećenja
• Za organizacije koje mogu priuštiti Enterprise pretplatu, razmotriti je — ona nosi pristup stabilnijem, kasnije-testiranom kanalu ažuriranja, uz formalnu podršku proizvođača, što je vredna razmena za produkcionu infrastrukturu većeg značaja

Sledeći deo serije bavi se mrežnom segmentacijom u Proxmox okruženju — kako razdvojiti upravljački, storage i saobraćaj samih VM-ova, i kako iskoristiti VM/kontejner-nivo firewall pravila pomenuta u ovom delu za ograničavanje komunikacije između pojedinačnih radnih opterećenja na istom hostu ili klasteru.