Securitate AlmaLinux 9: ghid complet

Securitate AlmaLinux 9: ghid complet, subiectul pe care îl deschidem cu fiecare client care își mută serverul de pe CentOS 7, ieșit din suport în iunie 2024. AlmaLinux 9 este compatibil binar cu Red Hat Enterprise Linux 9, primește actualizări de securitate până în 2032 și vine cu aceleași unelte de protecție: SELinux, firewalld, auditd, OpenSCAP. Diferența o face configurarea lor, nu prezența lor.

Ghidul urmează ordinea în care lucrăm noi pe un server nou: întâi accesul, apoi rețeaua, apoi sistemul, apoi supravegherea. Comenzile sunt pentru AlmaLinux 9.4 și mai nou; pe versiunile 9.x mai vechi funcționează identic.

Securitate AlmaLinux 9: ghid complet

Prima oră: actualizări și un utilizator cu sudo

Un server abia instalat are pachete vechi de luni de zile față de depozite. Actualizați totul și reporniți dacă s-a schimbat nucleul:

sudo dnf upgrade --refresh -y
sudo dnf needs-restarting -r   # spune dacă e nevoie de repornire

Apoi creați un utilizator administrativ și nu mai lucrați ca root. Grupul wheel are drepturi sudo implicit pe AlmaLinux:

sudo useradd -m -G wheel admin
sudo passwd admin

Regulile pentru conturi cu drepturi strict limitate, potrivite pentru aplicații și scripturi, le-am descris în articolul despre crearea unui utilizator cu acces limitat.

SSH: chei, fără root, fără parole

Generați o cheie pe calculatorul propriu, copiați-o pe server și abia apoi dezactivați parolele. Ordinea contează: dacă închideți parolele înainte să testați cheia, rămâneți afară.

ssh-keygen -t ed25519 -C "admin@firma"
ssh-copy-id admin@adresa-serverului
ssh admin@adresa-serverului   # trebuie să intre fără parolă

AlmaLinux 9 citește configurația SSH și din /etc/ssh/sshd_config.d/, deci puneți setările într-un fișier propriu, care nu este suprascris la actualizări:

sudo tee /etc/ssh/sshd_config.d/50-intarire.conf <<'EOT'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3
AllowUsers admin
EOT
sudo sshd -t && sudo systemctl restart sshd

Schimbarea portului SSH reduce zgomotul din jurnale, dar nu ține loc de protecție; dacă o faceți, anunțați SELinux cu semanage port, altfel serviciul nu pornește. Blocarea încercărilor repetate o tratăm în ghidul despre atacurile brute force pe SSH.

firewalld: doar ce trebuie deschis

firewalld este activ implicit și permite doar SSH, DHCP și Cockpit. Pentru un server web, adăugați HTTP și HTTPS și scoateți ce nu folosiți:

sudo firewall-cmd --permanent --add-service={http,https}
sudo firewall-cmd --permanent --remove-service=cockpit
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Serviciile care ascultă pe alte porturi (baza de date, Redis, un panou de administrare) trebuie să asculte doar pe 127.0.0.1 sau să fie accesibile doar dintr-o listă de adrese, prin reguli rich în firewalld. Comanda ss -tulpn arată tot ce ascultă și pe ce interfață. Dacă veniți de pe Ubuntu, comparația cu UFW este în articolul despre configurarea firewall-ului cu UFW pe Ubuntu și AlmaLinux.

SELinux rămâne activ

Prima reacție a multor administratori la o eroare de permisiune este să oprească SELinux. Este greșeala cu cel mai mare cost: SELinux este stratul care oprește un proces compromis să citească fișierele altui serviciu. Verificați că este în modul enforcing și învățați să citiți refuzurile:

getenforce                       # trebuie să afișeze Enforcing
sudo ausearch -m avc -ts recent  # refuzurile recente
sudo dnf install setroubleshoot-server -y
sudo sealert -a /var/log/audit/audit.log

Majoritatea refuzurilor pe un server web au trei cauze: fișiere copiate cu context greșit (se repară cu restorecon -Rv /var/www), un serviciu care trebuie să se conecteze la rețea (se permite cu setsebool -P httpd_can_network_connect on) sau un port neobișnuit (semanage port). Explicațiile complete sunt în articolul despre ce este SELinux și cum influențează securitatea serverului.

Actualizări automate de securitate

Pachetul dnf-automatic instalează actualizările singur, la ora aleasă. Pentru servere de producție, recomandăm instalarea automată doar a actualizărilor de securitate, cu notificare pentru restul:

sudo dnf install dnf-automatic -y
sudo sed -i 's/^upgrade_type = .*/upgrade_type = security/; s/^apply_updates = .*/apply_updates = yes/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic*

Actualizările nucleului cer repornire; verificați săptămânal cu dnf needs-restarting și programați repornirea într-o fereastră cu trafic mic.

fail2ban și limitarea încercărilor

fail2ban vine din depozitul EPEL și citește jurnalele SSH, Apache sau Nginx, blocând temporar adresele care greșesc parola de mai multe ori. Pe AlmaLinux 9 folosește firewalld ca mecanism de blocare, fără configurare suplimentară:

sudo dnf install epel-release -y
sudo dnf install fail2ban -y
sudo tee /etc/fail2ban/jail.local <<'EOT'
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
[sshd]
enabled = true
EOT
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Configurarea pentru servere web și lista de închisori pe care le activăm sunt în ghidul despre securizarea unui server Linux cu fail2ban.

Sistemul: servicii, jurnale, audit

Opriți ce nu folosiți

Fiecare serviciu activ este o suprafață de atac. Listați-le și dezactivați ce nu are rost pe un server web:

systemctl list-units --type=service --state=running
sudo systemctl disable --now cockpit.socket
sudo dnf remove -y cups avahi   # doar dacă apar în listă

Păstrați chronyd (sincronizarea orei este obligatorie pentru jurnale corecte și certificate valide), rsyslog sau journald, auditd și firewalld.

auditd și jurnalele

auditd înregistrează evenimentele de securitate: autentificări, schimbări de utilizatori, accesări ale fișierelor supravegheate. Este activ implicit; adăugați reguli pentru fișierele sensibile:

sudo tee /etc/audit/rules.d/50-server.rules <<'EOT'
-w /etc/passwd -p wa -k identitate
-w /etc/sudoers -p wa -k sudo
-w /etc/ssh/sshd_config.d/ -p wa -k ssh
EOT
sudo augenrules --load
sudo ausearch -k sudo --start today

Jurnalele de sistem se citesc cu journalctl; cele mai utile interogări pentru securitate le-am adunat în ghidul rapid pentru journalctl. Trimiterea jurnalelor pe un al doilea server împiedică un atacator să le șteargă după intrare.

OpenSCAP: verificare după un standard

AlmaLinux 9 livrează pachetul scap-security-guide cu profiluri CIS și DISA STIG. O scanare produce un raport HTML cu fiecare regulă trecută sau picată, și poate genera un script de remediere:

sudo dnf install openscap-scanner scap-security-guide -y
oscap info /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml | grep -i profile
sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --report /root/raport-cis.html /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml

Nu aplicați remedierea automată pe un server în producție fără să citiți raportul: unele reguli CIS (de exemplu, partiții separate pentru /var și /tmp) nu se pot aplica după instalare, iar altele opresc funcții de care aplicația are nevoie.

Parametri de nucleu și pornirea securizată

Câteva setări sysctl reduc suprafața de atac de rețea: ignorarea pachetelor ICMP redirect, protecția împotriva falsificării adreselor sursă și jurnalizarea pachetelor suspecte. Se pun într-un fișier în /etc/sysctl.d/ și se aplică cu sysctl --system. Secure Boot, dacă serverul este fizic și are UEFI, garantează că pornește doar un nucleu semnat; starea se vede cu mokutil --sb-state. Pe servere virtuale, depinde de furnizor.

Aplicațiile web: unde se produc de fapt incidentele

Pe serverele pe care le curățăm după un atac, poarta de intrare este aproape întotdeauna aplicația, nu sistemul: un modul WordPress neactualizat, un formular fără validare, o parolă slabă la baza de date. Întărirea sistemului limitează pagubele, dar câteva măsuri la nivelul aplicațiilor previn intrarea:

• PHP-FPM cu un utilizator separat pentru fiecare site, nu apache sau nginx pentru toate. Un site compromis nu poate citi fișierele altuia.
• Baza de date care ascultă doar pe 127.0.0.1 (bind-address în my.cnf) și un utilizator per aplicație, cu drepturi doar pe baza lui.
• Fișierele de configurare cu parole (wp-config.php, .env) cu permisiuni 640 și proprietar utilizatorul site-ului, conform regulilor din ghidul despre chmod și chown.
• Dosarele de încărcare fără drept de execuție PHP, printr-o regulă în configurația serverului web.
• Un firewall de aplicație (ModSecurity cu setul de reguli OWASP) în fața aplicațiilor PHP.
• Actualizarea aplicațiilor și a modulelor în aceeași zi cu anunțul unei vulnerabilități; jurnalul serverului web arată încercările de exploatare în ore, nu în zile.

Dacă serverul a fost deja compromis

Semnele obișnuite: procese necunoscute cu consum mare de procesor, conexiuni de ieșire spre adrese străine, utilizatori noi în /etc/passwd, chei SSH necunoscute în authorized_keys, sarcini cron pe care nu le-ați creat. Nu reparați pe loc: izolați serverul din firewall, păstrați jurnalele și copiile, apoi reinstalați din imagine curată și restaurați doar datele, nu și fișierele executabile. Reinstalarea durează o oră; curățarea manuală a unui sistem cu rootkit nu se termină niciodată cu certitudine.

Rutina lunară

1. dnf upgrade și repornire dacă needs-restarting o cere.
2. fail2ban-client status și ausearch pentru autentificări reușite de la adrese necunoscute.
3. ss -tulpn: niciun port nou care ascultă pe interfața publică.
4. getenforce și ausearch -m avc: SELinux activ, fără refuzuri necunoscute.
5. Verificarea copiilor de siguranță prin restaurare de test, nu doar prin prezența fișierelor; procedura este în articolul despre copiile de siguranță cu cron și rsync.
6. O scanare OpenSCAP, comparată cu raportul din luna anterioară.

Dacă serverul rulează cPanel, o parte din aceste setări sunt administrate de panou (firewall-ul, actualizările, fail2ban prin cPHulk), iar restul rămân în sarcina dumneavoastră; particularitățile le găsiți în ghidul despre instalarea cPanel/WHM pe AlmaLinux 9 și în cel despre migrarea de la CentOS 7. Iar dacă serverul a fost deja atacat, ordinea pașilor de răspuns este descrisă în ghidul de răspuns la incidente.

Surse

• Wiki AlmaLinux: ciclul de viață al versiunilor, depozitele și notele de lansare pentru seria 9.
• Manualul de securizare Debian: principiile de întărire a unui sistem Linux, valabile indiferent de distribuție.