Lista de verificare pentru întărirea serverului Linux

O instalare Linux implicită nu este o instalare Linux sigură. Majoritatea breșelor sunt cauzate de configurații greșite, cum ar fi accesul SSH root deschis, firewall-uri slabe și software nepatchat. Serverele noi se confruntă cu scanări automate în câteva minute de la punerea online, astfel încât întărirea ar trebui să aibă loc înainte de orice altceva.

Această listă de verificare acoperă pașii de bază: blocarea SSH, configurarea firewall-urilor, aplicarea de patch-uri, înăsprirea permisiunilor pentru fișiere, activarea controalelor de acces obligatorii și configurarea înregistrărilor de audit.

Blocați SSH

SSH este punctul dumneavoastră principal de acces și primul lucru pe care atacatorii îl sondează. Configurația implicită (password auth, root login, port 22) este exact ceea ce caută scanerele automate.

Generați o pereche de chei Ed25519, care oferă securitate și performanță mai bune decât RSA:

ssh-keygen -t ed25519

Odată ce autentificarea pe bază de cheie funcționează, actualizați /etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers yourname
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Schimbați portul implicit de la 22 la ceva mai puțin evident. Acest lucru nu va opri un atacator hotărât, dar reduce semnificativ zgomotul din scanările automate.

Testați întotdeauna modificările de pe un al doilea terminal înainte de a închide sesiunea curentă. Rulați sudo sshd -t pentru a verifica dacă există erori de sintaxă, apoi systemctl reload sshd pentru a aplica fără a întrerupe conexiunile active.

Adăugați autentificarea cu doi factori

2FA înseamnă că un atacator are nevoie atât de cheia dvs. SSH, cât și de acces fizic la dispozitivul dvs. Instalați modulul PAM Google Authenticator:

sudo apt install libpam-google-authenticator   # Debian/Ubuntu
sudo dnf install google-authenticator           # RHEL/Fedora

Rulați google-authenticator pentru fiecare utilizator pentru a genera o cheie secretă și coduri de recuperare. Stocați codurile de recuperare offline.

Adăugați această linie la /etc/pam.d/sshd:

auth required pam_google_authenticator.so

Apoi actualizați /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

Păstrați o sesiune activă deschisă în timpul testării. Codurile TOTP depind de ora exactă a sistemului, deci asigurați-vă că NTP rulează.

Configurați firewall-urile și Fail2Ban

Rulați un firewall bazat pe gazdă chiar dacă serverul dvs. se află în spatele unui firewall de rețea. Principiul este simplu: refuzați implicit tot traficul de intrare, apoi permiteți doar ceea ce aveți nevoie.

Pentru Ubuntu/Debian (UFW):

ufw default deny incoming
ufw default allow outgoing
ufw limit ssh
ufw enable

Pentru RHEL/Rocky/AlmaLinux (Firewalld):

firewall-cmd --set-default-zone=public
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

Întăriți stiva de rețea a nucleului prin adăugarea acestor elemente la /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1

Instalați Fail2Ban

Fail2Ban monitorizează încercările de conectare și interzice IP-urile după eșecuri repetate. Creați fișierul /etc/fail2ban/jail.local (nu editați direct jail.conf, actualizările îl vor suprascrie) și configurați-l pentru a interzice IP-urile timp de o oră după trei încercări eșuate în decurs de 10 minute. Setați backend-ul corect pentru firewall-ul dvs.(banaction = ufw sau banaction = nftables).

Auditul serviciilor și eliminarea protocoalelor vechi

Verificați ce ascultă cu ss -tlnp și ce rulează cu systemctl list-units --type=service --state=running. Dezactivați tot ce nu vă este necesar: Bluetooth, CUPS, avahi-daemon, rpcbind.

Eliminați protocoalele tradiționale care transmit date în text clar:

Pe Debian/Ubuntu: sudo apt-get --purge remove xinetd nis tftpd telnetd rsh-server. Pe sistemele bazate pe RHEL: yum erase xinetd ypserv tftp-server telnet-server rsh-server. Verificați eliminarea cu ss -tulpn.

Patch-uri și actualizări automate

Actualizarea sistemului dvs. este cea mai rapidă modalitate de a închide lacunele de securitate cunoscute. Rulați actualizările imediat după provizionare:

apt update && apt upgrade -y      # Debian/Ubuntu
dnf update -y                      # RHEL/Rocky

Apoi automatizați patch-urile de securitate. Pe Debian/Ubuntu, instalați unattended-upgrades și configurați-l pentru a aplica numai patch-uri de securitate. Pe RHEL/Rocky, instalați dnf-automatic și setați upgrade_type = security în /etc/dnf/automatic.conf.

Configurați notificări prin e-mail pentru rezultatele actualizărilor. Dezactivați repornirile automate pe serverele de producție(Automatic-Reboot = false), astfel încât repornirile să aibă loc în timpul ferestrelor de întreținere planificate. Pentru mediile cu timp de funcționare ridicat, luați în considerare patch-urile live cu Canonical Livepatch (Ubuntu) sau kpatch (RHEL).

Consolidarea sistemelor de fișiere și a permisiunilor

Auditați mai întâi fișierele binare SUID și SGID. Aceste fișiere rulează cu privilegii ridicate și sunt ținte principale pentru exploatare:

find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -ls

Înăspriți permisiunile pentru fișierele critice: /etc/shadow trebuie să fie 600, /etc/passwd trebuie să fie 644, /etc/ssh/sshd_config trebuie să fie 600. Setați un umask global de 027 în /etc/profile pentru a împiedica fișierele noi să poată fi citite de toată lumea.

Găsiți și fixați fișierele care pot fi citite de toată lumea cu find / -xdev -type f -perm -0002 -ls. Pentru directoarele care trebuie să rămână inscriptibile (cum ar fi /tmp), aplicați bitul sticky: chmod 1777 /tmp.

Opțiuni de montare securizată

Modificați fișierul /etc/fstab pentru a restricționa ceea ce se poate întâmpla pe partițiile critice:

Testați modificările cu mount -o remount înainte de repornire pentru a evita problemele de pornire.

Activați controalele obligatorii ale accesului

SELinux și AppArmor adaugă restricții la nivel de kernel cu privire la ceea ce pot face procesele. Folosiți cel cu care se livrează distribuția dumneavoastră: SELinux pentru RHEL/CentOS/Fedora, AppArmor pentru Ubuntu/Debian/SUSE. Comutarea între ele cauzează probleme de compatibilitate.

SELinux: Verificați starea cu getenforce. Porniți în modul permisiv(setenforce 0) timp de cel puțin două săptămâni pentru a surprinde comportamentul sarcinii de lucru fără a întrerupe nimic. Monitorizați încălcările cu ausearch -m avc -ts recent. Utilizați audit2why pentru a diagnostica blocurile și audit2allow -M [nume_modul] pentru a crea module de politici. Odată ce jurnalele sunt curate, treceți la aplicare cu setenforce 1, apoi faceți-o permanentă în /etc/selinux/config.

AppArmor: Verificați profilurile active cu aa-status. Instalați apparmor-utils pentru comenzile de gestionare. Porniți profilurile în modul "complain" cu aa-complain, apoi treceți la modul "enforce" cu aa-enforce atunci când sunteți sigur. Utilizați aa-genprof pentru a crea profiluri pentru aplicații personalizate.

Configurarea înregistrării și monitorizării auditului

Fără logare, incidentele nu lasă nicio urmă. Instalați auditd:

sudo apt-get install auditd audispd-plugins

Adăugați sisteme de supraveghere a fișierelor critice:

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity

Urmăriți toate execuțiile de comenzi la nivel de rădăcină:

-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

Încărcați regulile cu augenrules --load și adăugați -e 2 la sfârșitul fișierului de reguli pentru a face configurația inviolabilă (modificările necesită o repornire).

Monitorizarea integrității fișierelor cu AIDE

AIDE detectează modificările neautorizate ale fișierelor prin compararea stării curente cu o linie de bază bună cunoscută. Instalați-l, inițializați baza de date cu aideinit și mutați fișierul rezultat în /var/lib/aide/aide.db.gz. Configurați un cron job zilnic pentru a rula aide --check și pentru a trimite rezultatele prin e-mail administratorilor.

Centralizați jurnalele

Jurnalele locale sunt inutile dacă un atacator cu acces root le șterge. Transmiteți jurnalele către un server la distanță în timp real utilizând rsyslog cu criptare TLS. Adăugați la /etc/rsyslog.conf:

*.* @@remote-host:514

Setați LogLevel VERBOSE în configurația SSH astfel încât jurnalele să includă amprentele digitale ale cheii pentru fiecare autentificare reușită. Pentru mediile de producție care gestionează mai multe servere, instrumente precum Wazuh sau OSSEC oferă detectarea intruziunilor pe bază de gazdă cu analiza centralizată a jurnalelor.

Întreținerea continuă

Consolidarea nu este o sarcină punctuală. Configurațiile se modifică, apar noi vulnerabilități, iar schimbările de personal lasă în urmă conturi orfane.

Săptămânal: Revizuiți jurnalele Fail2Ban, verificați actualizările eșuate, verificați copiile de siguranță.

Lunar: Auditați conturile și permisiunile utilizatorilor, verificați serviciile care rulează, efectuați o scanare completă cu Lynis sau OpenSCAP.

Trimestrial: Rotiți acreditările, actualizați regulile de firewall, testați recuperarea în caz de dezastru.

Utilizați instrumente de infrastructură ca cod, precum Ansible, cu roluri de întărire dev-sec.io pentru a impune configurații coerente în întreaga flotă și pentru a preveni derapajele între audituri.

Serverele dedicate ale FDC vă oferă acces complet la rădăcină și control total asupra stivei de securitate. Explorați opțiunile de servere dedicate pentru a construi pe o platformă în care controlați fiecare strat.