Hardening pentru servere Linux în 2026: checklist CIS explicat

CIS Benchmarks sunt ghiduri de configurare securizată publicate de Center for Internet Security și construite prin consens între practicieni. Există benchmark-uri separate pentru Ubuntu, Debian, Red Hat Enterprise Linux și derivatele lui (Rocky, AlmaLinux), fiecare cu sute de recomandări numerotate, cu explicația riscului, comanda de audit și comanda de remediere.

Recomandările sunt grupate pe profiluri. Level 1 e baza: controale cu impact mic asupra funcționalității, pe care aproape orice server le poate aplica. Level 2 adaugă apărare în profunzime — de exemplu partiții separate pentru jurnale sau reguli de audit mai stricte — cu riscul de a afecta unele aplicații. Pentru majoritatea organizațiilor, ținta realistă este Level 1 complet pe toate serverele și Level 2 pe cele expuse sau critice.

Lista de mai jos nu înlocuiește benchmark-ul oficial pentru distribuția ta, dar adună controalele care, în practică, reduc cel mai mult suprafața de atac:

Dacă ai timp pentru un singur lucru azi, începe cu accesul la distanță. Un sshd_config minimal întărit conține PermitRootLogin no, PasswordAuthentication no, MaxAuthTries redus și, unde e posibil, AllowGroups limitat la un grup de administratori. Validează configurația cu sshd -t înainte de restart și păstrează o sesiune deschisă cât testezi — un SSH configurat greșit te poate bloca afară.

Firewall-ul trebuie să pornească de la deny implicit pe intrare și să permită explicit doar porturile necesare, iar SSH-ul ideal doar din rețeaua de administrare. Parametrii sysctl din checklist (rp_filter, redirecționări ICMP, syncookies) se pun într-un fișier din /etc/sysctl.d/ ca să supraviețuiască repornirii.

Hardening-ul nu înseamnă doar prevenție. Când ceva trece, întrebarea devine „ce s-a întâmplat și când”, iar răspunsul depinde de trei controale care par plictisitoare: auditd cu reguli pentru modificări de identitate, utilizarea sudo și încărcarea modulelor de kernel; sincronizarea timpului, fără de care nu poți corela jurnalele între servere; și trimiterea jurnalelor pe un sistem central, unde un atacator cu drepturi de root pe un server nu le mai poate șterge.

Pentru organizațiile din sfera NIS2 aceste jurnale nu sunt opționale: fără ele nu poți reconstrui un incident pentru raportul final către autoritate. Vezi și notificarea DNSC pas cu pas.

Aplicat manual, un benchmark de câteva sute de recomandări se degradează în câteva luni: un pachet nou, un administrator grăbit, o imagine veche. De aceea verificarea trebuie automatizată și programată. Trei instrumente sunt folosite frecvent:

• CIS-CAT — instrumentul CIS care evaluează direct conform benchmark-ului; există o variantă Lite gratuită și o variantă Pro pentru membrii CIS SecureSuite.
• OpenSCAP cu conținutul SCAP Security Guide — open-source, include profiluri aliniate CIS pentru mai multe distribuții. Listează profilurile disponibile cu oscap info pe fișierul de conținut și rulează evaluarea cu oscap xccdf eval, care produce un raport HTML și rezultate XML.
• Lynis — audit general de securitate (lynis audit system), util pentru o primă imagine și pentru sugestii, dar nu este o evaluare formală CIS.

Indiferent de instrument, rulează scanarea programat (de exemplu săptămânal și după fiecare schimbare majoră), păstrează rezultatele și urmărește tendința: un control care trece din „pass” în „fail” e un eveniment de investigat.

Un auditor nu vrea să vadă un server, vrea să vadă un proces. Configurația securizată se mapează pe NIS2 Art. 21(2) litera (e) — securitate în achiziția, dezvoltarea și întreținerea sistemelor — și litera (i) — controlul accesului și gestionarea activelor — precum și pe ISO 27001:2022 controlul A.8.9 (managementul configurației). Dosarul minim:

1. Standardul declarat: ce benchmark, ce versiune și ce profil aplici, pe ce categorii de servere.
2. Rapoarte de scanare datate pentru fiecare server, păstrate pe perioada stabilită în politica de retenție.
3. Registrul de excepții: fiecare control neaplicat, cu justificare, risc rezidual, cine a aprobat și când se reevaluează.
4. Înregistrări de schimbare care leagă remedierile de tichete sau commit-uri.
5. Inventarul de active, ca să poți demonstra că scanarea acoperă toate serverele, nu doar pe cele pe care ți le amintești.

Pentru imaginea completă a controalelor tehnice cerute de directivă, vezi Art. 21 NIS2: controalele tehnice.

• Aplicarea Level 2 direct în producție, fără test. Controale ca noexec pe anumite partiții pot opri instalatoare sau aplicații legitime.
• Remedierea automată fără revizie. Scripturile de remediere sunt utile, dar trebuie rulate întâi pe un mediu de test, pentru fiecare imagine de server.
• Excepții nedocumentate. Un control dezactivat „temporar” acum doi ani, fără justificare, este o constatare de audit.
• Hardening doar la instalare. Fără scanare periodică, deriva de configurație e garantată.