Majoritatea intruziunilor reușite pe servere nu se produc prin exploit-uri sofisticate, ci printr-o vulnerabilitate pentru care patch-ul a apărut acum câteva luni. Cauza nu este de obicei lenea: actualizarea manuală sperie, pentru că apt upgrade pe un server de producție repornește uneori ceva ce nimeni nu a cerut. Actualizările automate rezolvă problema, dar au o reputație proastă — meritată exact în măsura în care sunt configurate în grabă.

Să parcurgem configurația în care patch-urile de securitate sosesc singure, iar versiunea de PHP nu se schimbă în timpul nopții.

Instalare

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Dialogul creează /etc/apt/apt.conf.d/20auto-upgrades. Verifică ce a ieșit acolo:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Cifrele 1 înseamnă „zilnic”. Totul este pornit de un cronometru systemd, nu de cronul clasic:

systemctl list-timers | grep apt

Esențialul: doar securitate

Fișierul principal este /etc/apt/apt.conf.d/50unattended-upgrades. În el se află lista Allowed-Origins (pe Debian Origins-Pattern), iar implicit este activat doar depozitul de securitate. Așa să și rămână.

Tentația de a decomenta linia cu -updates este mare — „să se actualizeze tot”. Nu o face: depozitul de actualizări aduce versiuni noi, nu doar corecturi, și tocmai de acolo vin surprizele de noapte. Securitatea și prospețimea sunt sarcini diferite, iar a doua se face mai bine manual, când ești la tastatură.

Dacă un pachet nu poate fi actualizat automat, există pentru asta o listă neagră:

Unattended-Upgrade::Package-Blacklist {
    "mariadb-server";
    "php8.3-fpm";
};

Folosește-o conștient: fiecare linie de aici înseamnă „acest pachet îl actualizez eu” — iar promisiunea va trebui respectată.

Reporniri

Linia-cheie:

Unattended-Upgrade::Automatic-Reboot "false";

Păstrarea valorii false este corectă pentru un server cu site: o repornire la trei noaptea, fără avertisment, este mai rea decât un patch de nucleu amânat cu o zi. Această decizie are însă o a doua jumătate obligatorie, care se uită.

Când se actualizează nucleul, libc sau openssl, sistemul creează fișierul /var/run/reboot-required. Cât timp repornirea nu s-a făcut, pe disc stă versiunea corectată, iar în memorie rulează cea veche — vulnerabilitatea deci nu a dispărut nicăieri, deși pachetul figurează ca actualizat. Trebuie verificat explicit:

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Al doilea fișier enumeră din cauza cui anume este necesară repornirea. Regula este simplă: ai văzut indicatorul — planifică o fereastră în următoarele una-două zile, nu „cândva”.

Un caz aparte sunt bibliotecile. S-a actualizat openssl, dar nginx și PHP-FPM continuă să ruleze cu versiunea veche în memorie, iar niciun indicator de repornire nu apare. Cine anume are nevoie de repornire arată needrestart:

sudo apt install needrestart
sudo needrestart -b

Doar treci-l în modul „arată, nu întreba” — altfel începe să pună întrebări în mijlocul unei instalări neinteractive și o blochează. Pentru asta, în /etc/needrestart/conf.d/ se pune un fișier cu linia $nrconf{restart} = 'l';.

Verifică dacă funcționează în general

O rulare de probă fără instalare:

sudo unattended-upgrade --dry-run --debug

În ieșire se vede ce pachete se potrivesc regulilor și care au fost respinse și de ce. Ce s-a întâmplat cu adevărat — în jurnale:

sudo tail -50 /var/log/unattended-upgrades/unattended-upgrades.log

Câte actualizări așteaptă chiar acum:

apt list --upgradable 2>/dev/null | grep -i security

Ultima comandă este cea mai utilă dintre toate. Actualizările automate configurate au obiceiul de a se strica în tăcere: s-a terminat spațiul pe /boot, depozitul a schimbat cheia, cronometrul a fost oprit după o modificare manuală. În aparență totul este în regulă, iar patch-urile nu se instalează luni de zile.

Spațiul pe /boot

Un clasic: nucleele vechi nu se șterg, partiția /boot se umple, instalarea noului nucleu eșuează, iar actualizările se opresc complet. O dată la câteva luni merită să arunci o privire:

df -h /boot
sudo apt autoremove --purge

Sau activează curățarea automată în același 50unattended-upgrades: Remove-Unused-Kernel-Packages "true" și Remove-Unused-Dependencies "true".

Ce rămâne în seama omului

Actualizările automate elimină rutina, dar nu anulează supravegherea. Două întrebări la care trebuie să poți răspunde oricând: câte actualizări de securitate așteaptă instalarea și dacă este ridicat indicatorul de repornire. Ambele răspunsuri sunt o singură linie pe o pagină, iar tot rostul este ca acea linie să îți sară în ochi singură, nu din inițiativa ta o dată pe trimestru.