Linux Server Hardening – Deo 3: Automatsko ažuriranje i upravljanje paketima

Prethodna dva dela serije pokrila su pristup serveru i mrežnu izloženost. Treći deo se bavi disciplinom koja mora trajati kontinuirano, ne kao jednokratno podešavanje — redovnom primenom bezbednosnih zakrpa. Isti princip koji smo obradili za Windows Server u ranijoj seriji na ovom blogu važi i ovde, sa drugačijim alatima: ni ručno, sporadično ažuriranje "kad se neko seti", ni potpuno automatizovano ažuriranje svega bez razlike, nisu dobar odgovor. Cilj je strukturiran proces koji drži korak sa stvarnim rizikom bez nepotrebnog rizikovanja stabilnosti.

Zašto je ovo posebno bitno na Linux serverima izloženim internetu

Dobra ilustracija razloga zašto brzina reagovanja nije apstraktna preporuka nego konkretna potreba je regreSSHion ranjivost u OpenSSH-u (CVE-2024-6387), objavljena 2024. godine — zakrpa je bila dostupna u roku od nekoliko sati od objave, a ipak su mnogi serveri ostali nezakrpljeni danima, pa i nedeljama, tokom kojih su predstavljali lak cilj za automatizovano skeniranje. Razlika između servera koji je zakrpljen istog dana i servera zakrpljenog dve nedelje kasnije, u praksi, često je razlika između incidenta koji se nikad nije desio i incidenta koji jeste.

Alati za automatsko ažuriranje — po distribuciji

Na Debian/Ubuntu sistemima, standardan alat je unattended-upgrades — paket koji se konfiguriše da automatski preuzima i primenjuje ažuriranja, sa mogućnošću da se ograniči isključivo na bezbednosna ažuriranja (ne i na sva dostupna ažuriranja uopšte, što bi nosilo veći rizik od neplanirane promene ponašanja aplikacije). Na RHEL familiji distribucija (RHEL, Rocky, AlmaLinux, Fedora), ekvivalentan alat je dnf-automatic, koji radi kroz systemd tajmer i nudi istu mogućnost ograničavanja isključivo na bezbednosne ispravke (upgrade_type = security u konfiguraciji).

Šta treba uraditi

• Instalirati i konfigurisati odgovarajući alat za automatska ažuriranja (unattended-upgrades ili dnf-automatic) na svakom produkcionom serveru, umesto oslanjanja na to da će neko ručno pokrenuti ažuriranje na vreme
• Ograničiti automatsku primenu isključivo na bezbednosna ažuriranja (security-only), ne na sva dostupna ažuriranja — ovo smanjuje rizik od neplanirane promene ponašanja aplikacije koju donosi ažuriranje funkcionalnosti, dok i dalje zatvara realan bezbednosni rizik
• Uključiti obaveštenja (mejl ili slanje u centralni sistem za logovanje) o svakom primenjenom ažuriranju, kako bi tim imao uvid u to šta se menja na serverima, čak i kad je proces automatizovan
• Za servere koji zahtevaju stroži proces promena (regulatorni zahtevi, formalni change management), razmotriti postavku "preuzmi, ali ne primenjuj automatski" (download_updates=yes, apply_updates=no na RHEL sistemima), uz redovnu, ali ručno pokrenutu primenu preuzetih paketa

Napomena o riziku: automatska primena ažuriranja, čak i ograničena na bezbednosne ispravke, i dalje nosi mali, ali realan rizik od neočekivane regresije ili sukoba sa specifičnom konfiguracijom aplikacije. Za kritične servere (baze podataka, domain kontrolere ako je reč o Linux/Samba okruženju, servere sa strogim zahtevima za dostupnost), razmotriti test okruženje koje prima ista ažuriranja nešto ranije, sa periodom posmatranja pre nego što se ista ažuriranja primene i na produkciju. Nikad ne pretpostaviti da će se "verovatno" sve odigrati bez problema samo zato što se radi o "samo bezbednosnoj" zakrpi.

Upravljanje restartom nakon ažuriranja jezgra

Ažuriranje jezgra operativnog sistema (kernel) tipično zahteva restart servera da bi zakrpa stvarno stupila na snagu — sve dok se server ne restartuje, sistem nastavlja da radi sa starim, potencijalno ranjivim jezgrom u memoriji, bez obzira na to što je nova verzija već instalirana na disku. Ovo stvara praktičnu tenziju: automatski restart u nasumično doba dana nosi rizik prekida rada u neprikladnom trenutku, dok potpuno izostavljanje automatskog restarta znači da mnoge kernel zakrpe efektivno nikad ne stupe na snagu, jer niko ne restartuje server ručno.

Šta treba uraditi

• Konfigurisati automatski restart samo kada je zaista potreban (reboot=when-needed na RHEL sistemima, Automatic-Reboot na Debian/Ubuntu sistemima), ne bezuslovno nakon svakog ciklusa ažuriranja
• Definisati konkretan, unapred poznat prozor za automatski restart (npr. 3 ili 4 ujutru) usklađen sa stvarnim najnižim opterećenjem tog servera, a ne generičkim, podrazumevanim vremenom koje ne odgovara stvarnom obrascu korišćenja
• Za servere gde je čak i planiran, redak restart neprihvatljivo ometajući, razmotriti rešenja za "živu" primenu kernel zakrpa (kernel live-patching), koja omogućavaju da se bezbednosne ispravke jezgra primene direktno u memoriji, bez potrebe za restartom — dostupna kroz komercijalne ili besplatne opcije u zavisnosti od distribucije
• Nakon automatskog restarta, proveriti (ručno ili kroz monitoring) da su svi servisi koji treba da se pokrenu na startu zaista uspešno pokrenuti — restart koji "prođe" na nivou operativnog sistema ne garantuje da je i sama aplikacija ispravno nastavila rad

Izuzeci — planirani, ne slučajni

Neki paketi zaslužuju posebnu pažnju pre automatske primene ažuriranja — tipično baza podataka, verzija samog jezgra ako se koristi specifična, testirana verzija zbog kompatibilnosti sa hardverom ili aplikacijom, ili ključna aplikativna zavisnost gde i manja verzija ažuriranja može promeniti ponašanje. Izuzetak od automatskog ažuriranja treba da bude svesna, dokumentovana odluka — isti princip opisan za AD i MSSQL izuzetke kroz ranije serije na ovom blogu — ne slučajna posledica toga što je neko jednom isključio ažuriranje "privremeno" i zaboravio da ga vrati.

Šta treba uraditi

• Eksplicitno izuzeti (exclude na RHEL sistemima, Package-Blacklist na Debian/Ubuntu) tačno određene pakete koji zahtevaju ručnu, pažljivo testiranu primenu — ne čitave kategorije paketa "za svaki slučaj"
• Za pakete gde je bitno zadržati tačno određenu, testiranu verziju (npr. verzija baze podataka usklađena sa specifičnom aplikacijom), koristiti mehanizam zaključavanja verzije (versionlock na RHEL sistemima) umesto samo isključivanja iz automatskog ažuriranja — ovo sprečava i slučajnu ručnu nadogradnju na neusklađenu verziju
• Voditi jasnu, ažurnu evidenciju izuzetaka — koji paket, zašto je izuzet, i ko je odgovoran za njegovo ručno ažuriranje — kako izuzetak ne bi postao trajno zaboravljeno, nezakrpljeno mesto u infrastrukturi
• Periodično (bar kvartalno) preispitati listu izuzetaka i proveriti da li razlog za izuzimanje i dalje postoji, umesto da lista raste unedogled bez ikad revizije

Napomena o riziku: izuzimanje paketa iz automatskog ažuriranja rešava problem stabilnosti u kratkom roku, ali stvara dugoročan bezbednosni dug ako se izuzeti paket nikad ručno ne ažurira — server koji ima automatska ažuriranja uključena, ali sa širokom listom trajnih izuzetaka, može stvoriti lažan osećaj sigurnosti da je "sve pod kontrolom", dok stvarno kritične komponente ostaju godinama nezakrpljene.

Praćenje šta zaista stoji nezakrpljeno

Automatizacija ažuriranja ne oslobađa potrebu za povremenom, nezavisnom proverom stvarnog stanja — isti princip verifikacije opisan u seriji o Windows Server hardeningu, ovde primenjen na Linux alate.

Šta treba uraditi

• Redovno proveravati listu dostupnih bezbednosnih ažuriranja nezavisno od automatskog procesa (npr. `dnf updateinfo list --security` ili `apt list --upgradable` filtrirano na bezbednosne pakete), kao proveru da automatski proces zaista radi kako se očekuje
• Pratiti logove alata za automatsko ažuriranje (npr. /var/log/unattended-upgrades/ na Debian/Ubuntu, /var/log/dnf.log ili odgovarajući journalctl izlaz na RHEL sistemima) radi otkrivanja neuspešnih pokušaja primene, ne samo uspešnih
• Pretplatiti se na bezbednosna obaveštenja distribucije koja je u upotrebi (USN za Ubuntu, RHSA za Red Hat, DSA za Debian) radi ranog saznanja o kritičnim ranjivostima pre nego što redovan automatski ciklus stigne do njih
• Kombinovati ovo sa CISA KEV katalogom, opisanim u seriji o hardeningu Windows Server-a, kao dodatan, nezavisan signal o tome koje ranjivosti zaslužuju hitniji odgovor od standardnog ciklusa

Ovim se zaokružuje treći deo serije, i sa njim osnovna trojka tema neophodnih za bilo koji Linux server izložen mreži — pristup, mrežna izloženost, i disciplina ažuriranja. Sledeći deo serije bavi se logovanjem i auditom na Linux sistemu — auditd okvirom, centralizacijom logova, i onim što sistem inženjer i auditor treba tamo da traže kad se postavi pitanje ko je i kada nešto uradio na serveru.