Majoritatea intruziunilor pe servere folosesc vulnerabilități pentru care patch-ul exista de săptămâni. Problema nu e lipsa actualizărilor, ci lipsa unei rutine: cine le aplică, când, cum afli că e nevoie de restart și ce faci dacă ceva se rupe.
Depozitul de securitate al distribuției conține doar corecții, fără funcționalități noi, deci riscul de a rupe aplicația e mic, iar riscul de a nu le aplica e mare. Le lași să ruleze zilnic, fără intervenție. Versiunile noi de PHP, PostgreSQL sau Node.js le tratezi ca pe o schimbare de aplicație: staging, planificare, documentare. Pe Debian și Ubuntu separarea se face în Allowed-Origins; pe RHEL, prin upgrade_type = security. Securitate automată plus funcționalități manuale e compromisul care ține.
Un patch de kernel instalat fără repornire nu protejează nimic: kernelul vechi rulează până la următorul boot. La fel glibc, folosită de toate procesele. needrestart îți spune ce servicii țin în memorie biblioteci înlocuite și dacă e nevoie de reboot. Planifici repornirea noaptea, anunți clienții, verifici după că totul a pornit. Dacă nu poți reporni, livepatch pe Ubuntu sau kpatch pe RHEL aplică o parte din corecții în memorie. Cu două servere în spatele unui load balancer, repornești câte unul.
Pentru entitățile înregistrate la DNSC sub OUG 155/2024, transpunerea NIS2 aprobată prin Legea 124/2025, gestionarea vulnerabilităților face parte din măsurile minime de gestionare a riscului, iar la un incident vei fi întrebat când a apărut patch-ul și când l-ai aplicat. Pentru orice firmă care prelucrează date personale, un server compromis printr-o vulnerabilitate corectată de luni de zile e greu de apărat în fața ANSPDCP sub art. 32 GDPR. Logul scris automat de unattended-upgrades e proba cea mai simplă.
| Tip de actualizare | Cum se aplică | Restart necesar | Staging |
|---|---|---|---|
| Patch de securitate pentru pachete | Automat, zilnic | Doar serviciul afectat (needrestart) | Opțional |
| Kernel, glibc, systemd | Automat, cu reboot planificat | Reboot complet sau livepatch | Recomandat |
| Versiune nouă de PHP, PostgreSQL, Node.js | Manual, planificat | Serviciul | Obligatoriu |
| Imagine Docker | Reconstruire în CI și rollout | Containerul se înlocuiește | Obligatoriu |
# /etc/apt/apt.conf.d/50unattended-upgrades (fragment)
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
# /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";sudo dnf install -y dnf-automatic
# /etc/dnf/automatic.conf (fragment)
[commands]
upgrade_type = security
apply_updates = yes
sudo systemctl enable --now dnf-automatic.timerapt list --upgradable
sudo unattended-upgrade --dry-run
sudo needrestart -bServerul nu fusese repornit de un an și rula un kernel cu vulnerabilități cunoscute, deși pachetele erau la zi. needrestart a arătat că și PHP-FPM folosea o bibliotecă înlocuită. Reboot-ul planificat marți, la trei dimineața, a durat două minute.
dnf-automatic aplica toate actualizările, inclusiv o versiune nouă de MariaDB care a schimbat un comportament de sortare. Configurația a trecut pe upgrade_type = security, iar upgrade-urile de funcționalități se fac lunar, întâi pe o copie de test.
Pentru vulnerabilitățile exploatate activ, în aceeași zi, chiar cu un restart neplanificat. Pentru restul, rularea zilnică automată e suficientă. Contează să știi în ce categorie ești: urmărești anunțurile distribuției și, dacă ai obligații NIS2, buletinele DNSC.
Rar, dacă le limitezi la depozitul de securitate. Riscul real vine din upgrade-urile de funcționalități aplicate automat și din repornirile fără verificare. Păstrezi un snapshot înainte de fereastra de mentenanță și un check simplu, dimineața, că serviciile răspund.
Compari versiunea instalată, cu apt policy sau dnf info, cu versiunea corectată din anunțul distribuției, care menționează identificatorul CVE. Pentru un parc mai mare, un scaner de vulnerabilități rulat periodic face comparația pentru tine.
Un server de producție e atacat automat din primele minute după ce primește IP public, indiferent cât de mic e proiectul. Ghidul ordonează controalele după impact, de la accesul SSH până la răspunsul la incident, cu legislația din România care se aplică. Fiecare temă are o pagină dedicată, cu răspuns scurt, exemple și configurări.