Backup Infrastructure Hardening – Deo 4: Veeam Backup & Replication – hardening konkretne platforme

Prethodna tri dela serije pokrila su principe nezavisne od konkretnog proizvođača — arhitekturu, zaštitu od ransomware-a, testiranje. Ovaj, poslednji deo pokazuje kako se ti principi prevode u stvarna, konkretna podešavanja unutar Veeam Backup & Replication (VBR) — jedne od najrasprostranjenijih backup platformi, i upravo zato česte, poznate mete napada. Svaka preporuka u ovom tekstu je direktna, praktična primena principa opisanog u prethodna tri dela, sada sa tačnim imenom podešavanja i mestom gde se ono nalazi.

Domen ili workgroup — odluka koja određuje sve ostalo

Ovo je prva, i verovatno najznačajnija arhitekturna odluka pri postavljanju Veeam infrastrukture, direktna primena principa odvojenog identiteta opisanog u drugom delu serije. Veeam-ova sopstvena dokumentacija eksplicitno preporučuje da backup server i ostale komponente infrastrukture ne budu deo iste Active Directory domene koju štite — za veća okruženja, poseban, izdvojen AD forest posvećen isključivo upravljanju backup infrastrukturom; za manja i srednja okruženja, gde poseban forest nije realan, bar odvojen workgroup, van standardne produkcione domene.

Razlog je isti koji smo detaljno objasnili u drugom delu serije: ako je VBR server član iste domene čiji je Domain Admin nalog kompromitovan, taj Domain Admin nalog po difoltu dobija i pristup backup infrastrukturi, čineći brisanje backup-a samo još jednim korakom u već uspešnom napadu, ne odvojenom preprekom.

Šta treba uraditi

• Za veće infrastrukture, postaviti VBR server i ostale komponente (proxy, repozitorijum) u zaseban Active Directory forest, sa sopstvenim, nezavisnim administratorskim identitetom
• Za manje i srednje organizacije bez resursa za poseban forest, postaviti VBR server u workgroup konfiguraciju, van produkcione domene, sa lokalnim nalozima umesto domenske autentifikacije — isti kompromisni pristup opisan u drugom delu serije za organizacije sa ograničenim resursima, gde potpuna izolacija nije uvek realna od prvog dana, ali delimični koraci i dalje vredno smanjuju rizik
• Nikad ne postavljati VBR server kao član produkcione domene "radi praktičnosti", čak i u manjim okruženjima gde je iskušenje da se sve upravlja jednim identity sistemom razumljivo

Jedna uloga po serveru — VBR server nije mesto za bilo šta drugo

Isti princip minimizacije površine napada opisan kroz Windows Server hardening seriju na ovom blogu ima ovde posebno strogu, direktnu primenu: server na kojem radi VBR ne treba da obavlja nijednu drugu ulogu — ne fajl server, ne WSUS, ne upravljanje antivirusom, i sigurno ne domain kontroler. Svaka dodatna uloga na istom serveru širi površinu napada, i, što je jednako bitno, otežava disciplinu ažuriranja i praćenja opisanu u ranijim serijama, jer server sa više uloga zahteva usaglašavanje potreba za zakrpama koje mogu biti u međusobnom sukobu.

Šta treba uraditi

• Dodeliti VBR serveru isključivo tu jednu ulogu — bez dodatnih rola operativnog sistema ili aplikacija koje nisu direktno deo Veeam infrastrukture
• Ukloniti nepotreban softver sa svake Veeam komponente (VBR server, proxy, repozitorijum) — veb pregledače, Java, PDF čitače i slične aplikacije koje nisu deo operativnog sistema niti aktivnih Veeam komponenti; svaki dodatni program je potencijalan dodatan put napada i dodatan teret za disciplinu ažuriranja
• Isključiti Veeam vPower NFS servis na svakoj komponenti gde se ne koriste funkcije koje ga zahtevaju (SureBackup, Instant Recovery, File Level Recovery) — nepotreban aktivan servis je nepotreban rizik, isti princip minimizacije opisan kroz seriju o hardeningu Linux i Windows servera
• Ukloniti podrazumevanu proxy i repository ulogu sa samog VBR servera ako se planira korišćenje odvojenih, dedikovanih proxy i repository servera — VBR server treba da ostane isključivo upravljačka komponenta, ne i mesto gde se stvarno prenose ili čuvaju backup podaci

Pristup konzoli — MFA, ograničen RDP, i automatski logout

Ovo je direktna primena phishing-otporne autentifikacije i just-in-time pristupa opisanih u drugom delu serije, ovde primenjena na Veeam konkretno. Vredi naglasiti hakerski ugao (kako Veeam-ova sopstvena zajednica formuliše ove preporuke): ako "običan" korisnički nalog može doći do kritičnih operacija unutar Veeam konzole — brisanje svih backup-a odjednom, izmena enkripcionih lozinki — posledice mogu biti katastrofalne, i to je tačno mesto gde MFA i ograničena, pažljivo dodeljena administracija prave razliku.

Šta treba uraditi

• Zahtevati MFA za pristup VBR konzoli, uklanjanjem podrazumevane Builtin\Administrator grupe iz Veeam administratorskih dozvola — Veeam-ova ugrađena podrška za MFA zahteva ovaj korak da bi zaista bila obavezna, ne opciona
• Izbegavati RDP kao standardan način pristupa VBR serveru — koristiti umesto toga Veeam konzolu instaliranu na odvojenom, upravljačkom serveru (idealno u DMZ zoni, kako Veeam-ova sopstvena arhitektura preporučuje), sa konzolom kao jedinom tačkom za svakodnevnu administraciju
• Ako RDP mora ostati dostupan (npr. za instalaciju ažuriranja ili firmvera na fizičkom serveru), ograničiti ga na tačno određene, poverljive IP adrese, sa Network Level Authentication uključenim, po istom principu opisanom u Windows Server hardening seriji — i koristiti ga isključivo za taj uzak, povremen zadatak, ne za rutinski rad
• Postaviti automatski tajmer za odjavu neaktivne Veeam konzolne sesije (dostupno od verzije 12) — ako je RDP sesija ka management serveru kompromitovana, aktivna, otključana Veeam sesija bez tajmera daje napadaču direktan, gotov pristup bez potrebe da ponovo prolazi kroz autentifikaciju
• Držati što manji broj istovremeno prijavljenih korisnika u Veeam konzoli, po istom principu ograničavanja izloženosti opisanom kroz svaku prethodnu seriju na ovom blogu

Hardened Repository — Veeam-ova nativna implementacija principa iz drugog dela serije

Hardened Repository je Veeam-ovo sopstveno, softversko rešenje za nepromenljivost, direktna implementacija WORM principa detaljno objašnjenog u drugom delu serije, primenjena na standardan Linux server (bez potrebe za specijalizovanim, skupim hardverom ili prilagođenom Veeam distribucijom) — koristeći ugrađene mogućnosti Linux fajl sistema (xattr atribute na XFS fajl sistemu) za sprovođenje nepromenljivosti na nivou samog operativnog sistema, ne samo kroz Veeam aplikativni sloj.

Interna arhitektura Hardened Repository-ja koristi tri odvojena naloga sa strogo razgraničenim ulogama, vredna eksplicitnog objašnjenja: root nalog, koji ne treba da se ikad koristi za ljudsku interakciju i treba biti zaključan odmah po instalaciji (isti princip opisan za root@pam u Proxmox seriji i root u Linux Server hardening seriji); admin nalog, korišćen za povremenu ljudsku administraciju samog repozitorijuma, sa preporukom da se ne koristi podrazumevano ime "admin" i da se zaštiti MFA ili ključ-baziranom SSH autentifikacijom; i servisni nalog, pod kojim radi sam Veeam Data Mover proces, ograničen isključivo na pravo pisanja u direktorijum repozitorijuma, bez ijedne šire dozvole.

Šta treba uraditi

• Postaviti Hardened Repository kao bar jednu od kopija u 3-2-1-1-0 okviru opisanom u prvom delu serije, po mogućstvu kombinovanu sa dodatnom immutable kopijom na object storage-u (S3 Object Lock, opisano u drugom delu serije) za dvostruku zaštitu
• Zaključati root nalog odmah po instalaciji, po istom principu opisanom kroz seriju o hardeningu Linux servera, i koristiti isključivo imenovan admin nalog za povremenu administraciju
• Konfigurisati servisni nalog (npr. veeamsvc) kao vlasnika repository direktorijuma sa ograničenim pravima, ne kao naloga sa širim pristupom "radi jednostavnosti" — isti princip least privilege servisnog naloga opisan kroz MSSQL i Linux Server hardening serije
• Koristiti single-use kredencijale koje Veeam nudi za inicijalno postavljanje Data Mover servisa — ovi kredencijali se koriste tačno jednom, u trenutku dodavanja repozitorijuma u infrastrukturu, i nikad se trajno ne čuvaju unutar backup infrastrukture, čime se eliminiše rizik da neko naknadno izvuče te kredencijale iz konfiguracije
• Postaviti period nepromenljivosti (immutability period) usklađen sa realnim vremenom potrebnim za otkrivanje incidenta plus vreme za oporavak, po istom principu opisanom u drugom delu serije za retention lock kod S3 Object Lock-a

Napomena o riziku: imati na umu razliku pomenutu u drugom delu serije — softverska nepromenljivost, čak i vrlo dobro implementirana kroz namenske mehanizme fajl sistema, ostaje teoretski zavisna od ispravnosti softvera koji je sprovodi, za razliku od fizičkog air-gap-a. Hardened Repository je snažan, praktičan, dokazan mehanizam, ali za organizacije sa najvišim zahtevima za otpornost i dalje vredi kombinovati ga sa dodatnom, fizički odvojenom kopijom, ne oslanjati se isključivo na jedan, ma koliko dobar, softverski mehanizam.

Enkripcija — na nivou zadatka, sa istom pažnjom kao svaki drugi ključ

Veeam podržava enkripciju na nivou samog backup zadatka (job-level), koristeći AES-256-CBC algoritam sa 256-bitnim ključevima — direktan ekvivalent klijentske enkripcije opisane za Proxmox Backup Server u ranijoj seriji na ovom blogu. Isti princip primenjuje se ovde: ako napadač dobije pristup samim backup fajlovima bez enkripcije, ima sve; sa uključenom enkripcijom, dobija samo šifrovan sadržaj bez praktične vrednosti bez odgovarajuće lozinke.

Šta treba uraditi

• Uključiti enkripciju za sve backup zadatke koji sadrže osetljive podatke, na nivou samog zadatka
• Čuvati enkripcione lozinke odvojeno od Veeam infrastrukture, po istom principu opisanom za PBS ključeve u Proxmox seriji i TDE sertifikate u MSSQL seriji — gubitak lozinke bez odgovarajuće rezervne kopije znači trajan gubitak mogućnosti dekriptovanja tih backup-a
• Uključiti enkripciju konfiguracionog backup-a same Veeam infrastrukture (backup samih Veeam podešavanja — lozinki, IP adresa, korisničkih naloga) — bez uključene enkripcije, ovi osetljivi podaci ostaju nezaštićeni čak i unutar backup-a namenjenog za oporavak same backup platforme u slučaju katastrofe
• Uključiti transportnu enkripciju (SSL/TLS) za saobraćaj između hosta i proxy servera, ne oslanjati se samo na enkripciju u mirovanju — po istom principu obuhvatne zaštite podataka i u prenosu i u mirovanju koji se provlači kroz svaku seriju na ovom blogu

Ovim se zaokružuje cela serija o hardeningu backup infrastrukture — od arhitekture i strategije, preko zaštite od ransomware-a i discipline testiranja, do konkretne primene tih principa unutar Veeam-a. Isti obrazac koji povezuje ovu seriju sa svakom prethodnom serijom na ovom blogu ostaje nepromenjen kroz sve: princip najmanjih privilegija, odvajanje kritične infrastrukture od onoga što štiti, i disciplina proveravanja da li sve to zaista radi — bez obzira na to da li se primenjuje na Active Directory, bazu podataka, hipervizor, ili, kao ovde, na sam backup koji sve to na kraju treba da spasi.