Linux Server Hardening – Deo 4: Auditd i centralizovano logovanje

Prethodna tri dela serije bavila su se prevencijom — pristupom, mrežnom izloženošću, disciplinom zakrpa. Četvrti deo prelazi na drugu stranu iste medalje, isti obrt koji smo napravili i u AD hardening seriji: kako znati da se nešto dešava, ili da se već desilo. Linux nudi za ovo namenski, kernel-nivoa alat — auditd — koji, slično kao i Windows Advanced Audit Policy iz ranijih serija na ovom blogu, ostaje bez svrhe ako se ne podesi svesno i ne prati aktivno.

Zašto auditd, kad syslog/journald već postoje

Standardno sistemsko logovanje (rsyslog ili systemd-journald) beleži poruke koje aplikacije i servisi sami odluče da zapišu — korisno, ali zavisno od toga da li je aplikacija uopšte programirana da nešto zabeleži. Auditd radi na drugačijem, dubljem nivou: kači se direktno na kernel i sistemske pozive (syscalls), beležeći događaje pre nego što bilo koji proces u korisničkom prostoru (user space) ima priliku da ih presretne ili izmeni. Ovo ga čini pouzdanijim izvorom istine za bezbednosno relevantne događaje — pristup osetljivim fajlovima, promene ovlašćenja, izvršavanje komandi — nego oslanjanje isključivo na to šta je svaka pojedinačna aplikacija odlučila da zapiše.

Osnovna pravila — šta prvo pratiti

Auditd radi na osnovu pravila koja se definišu u /etc/audit/rules.d/, i sam po sebi ne prati ništa dok mu se eksplicitno ne kaže šta da prati — isti princip praznog polaznog stanja koji smo videli kod Windows Advanced Audit Policy. Prioritet treba dat najosetljivijim, najčešće ciljanim tačkama sistema: fajlovima koji definišu naloge i njihova ovlašćenja, i tragovima privilegovanog izvršavanja.

Šta treba uraditi

• Pratiti izmene ključnih fajlova sa identitetom i ovlašćenjima naloga — /etc/passwd, /etc/shadow, /etc/sudoers, i /etc/group — kroz "watch" (-w) pravila koja beleže i pokušaje pisanja i promene atributa
• Pratiti izmene same SSH konfiguracije (/etc/ssh/sshd_config), kako bi svaka izmena pristupnih podešavanja opisanih u prvom delu serije ostavila trag
• Pratiti izvršavanje komandi za eskalaciju privilegija (su, sudo) kao izvršne (-x) putanje, kako bi svaki pokušaj postajanja root korisnika, uspešan ili neuspešan, bio zabeležen
• Kao poslednje pravilo u konfiguraciji, postaviti auditd u nepromenljiv (immutable) režim (-e 2) — ovo sprečava izmenu ili gašenje pravila do sledećeg restarta sistema, čime se napadaču sa root pristupom onemogućava da jednostavno isključi audit pre nego što nastavi sa svojim ciljem

Napomena o riziku: uvođenje immutable režima (-e 2) je nepovratno do restarta — ako se u pravilima kasnije otkrije greška, jedini način da se ona ispravi je restart sistema, ne prosta izmena konfiguracije. Testirati pravila temeljno u audit modu i van produkcije pre nego što se immutable režim uključi na produkcionim serverima, i planirati restart kao deo redovnog ciklusa ažuriranja opisanog u trećem delu serije, ne kao hitnu, nepredviđenu intervenciju.

Kapacitet i pouzdanost — audit koji gubi događaje je beskoristan

Auditd ima ograničen bafer (backlog) za događaje koji čekaju da budu obrađeni; na serveru sa intenzivnom aktivnošću, premali bafer znači da će se deo događaja jednostavno izgubiti pre nego što stigne do log fajla — tiho, bez očiglednog upozorenja, osim ako se to eksplicitno ne proveri. Isto tako, log fajl koji nekontrolisano raste može ispuniti disk, a podrazumevano ponašanje pri tome (rotacija, prepisivanje starih zapisa) može značiti gubitak upravo onog dela istorije koji bi bio najpotrebniji u istrazi.

Šta treba uraditi

• Redovno proveravati da li auditd gubi događaje (`auditctl -s`, polje lost) — bilo koja vrednost različita od nule ili blizu nule signalizira da bafer treba povećati
• Povećati backlog limit (`auditctl -b`) na serverima sa intenzivnom aktivnošću, posebno ako se prati veliki broj sistemskih poziva, ne samo uzak skup fajl pravila
• Podesiti retenciju loga (u /etc/audit/auditd.conf) tako da se stariji zapisi čuvaju, a ne tiho brišu kad se dostigne veličina — max_log_file_action postavljen na "keep_logs" umesto podrazumevanog ponašanja koje može prepisivati stare zapise
• Postaviti akciju za slučaj da preostali prostor na disku padne ispod praga (space_left_action) tako da administrator dobije upozorenje pre nego što prostor bude potpuno iscrpljen, a admin_space_left_action postaviti na "halt" za posebno kritične servere, gde je prioritet da sistem stane nego da nastavi rad bez ikakvog audit traga

Napomena o riziku: postavljanje admin_space_left_action na "halt" znači da će sistem zaista prestati da radi ako audit log potpuno ispuni disk — ovo je namerna, ozbiljna mera za okruženja gde je "nema audit traga" gori ishod od zastoja servisa, ali nije podrazumevano ispravan izbor za svaki server. Za manje kritične sisteme, blaži odgovor (upozorenje bez zaustavljanja) može biti primereniji — ovu odluku doneti svesno, u skladu sa stvarnim značajem tog konkretnog servera, ne primeniti je univerzalno bez razmišljanja.

Centralizacija — log na kompromitovanom serveru nije pouzdan izvor

Isti princip koji smo naglasili za Windows PowerShell logovanje u ranijoj seriji važi identično i ovde: log koji ostaje isključivo na serveru koji je i sam meta napada može biti izmenjen ili obrisan od strane napadača sa dovoljnim privilegijama, čineći ga nepouzdanim izvorom u trenutku kad je najpotrebniji. Prosleđivanje logova na odvojenu, centralnu lokaciju rešava ovaj problem — čak i ako napadač u potpunosti preuzme kontrolu nad serverom, zapisi koji su već otišli na centralni sistem ostaju netaknuti.

Šta treba uraditi

• Koristiti alat za prosleđivanje logova (rsyslog, Filebeat sa auditd modulom, ili sličan) da se auditd zapisi (podrazumevano u /var/log/audit/audit.log) šalju na centralnu lokaciju u realnom vremenu, ne tek periodično ili ručno
• Centralni sistem za prijem logova (SIEM ili namenski log server) zaštititi istim principima opisanim za backup infrastrukturu u MSSQL seriji — odvojen od produkcije, sa ograničenim, posebno kontrolisanim pristupom
• Filtrirati na nivou prosleđivanja ono što se šalje na centralnu lokaciju, ako je obim podataka prevelik za realne resurse SIEM sistema — zadržati prioritet na autentifikacionim događajima, promenama privilegija i integritetu ključnih fajlova, dok se manje relevantni, visokovolumni događaji (npr. rutinski mrežni saobraćaj veb servera) mogu selektivno izostaviti
• Nikad ne filtrirati van sistema autentifikacione događaje, promene privilegija ili integritet ključnih fajlova samo radi uštede na obimu podataka — ovo su upravo događaji koji nose najveću bezbednosnu vrednost, i njihovo izostavljanje poništava svrhu centralizacije

Ovim se zaokružuje osnovni ciklus Linux Server hardening serije — pristup, mrežna izloženost, disciplina zakrpa, i logovanje/audit koji sve to drži pod nadzorom, u istoj strukturi kao i ranija AD hardening serija na ovom blogu. Dalji nastavak može ići u dubinu na specifične teme poput SELinux/AppArmor mandatorne kontrole pristupa, ili bezbednosti kontejnerizovanih radnih opterećenja, u zavisnosti od toga šta se pokaže najkorisnijim za dalje čitanje.