Lista di controllo per il rafforzamento della sicurezza dei server Linux

Un'installazione Linux predefinita non è un'installazione Linux sicura. Configurazioni errate come l'accesso SSH root aperto, firewall deboli e software non aggiornato sono responsabili della maggior parte delle violazioni. I nuovi server vengono sottoposti a scansioni automatiche pochi minuti dopo la messa online, quindi il rafforzamento della sicurezza dovrebbe avvenire prima di qualsiasi altra cosa.

Questa checklist copre i passaggi fondamentali: blocco di SSH, configurazione dei firewall, applicazione delle patch, rafforzamento dei permessi sui file, abilitazione dei controlli di accesso obbligatori e configurazione della registrazione degli audit.

Bloccare SSH

SSH è il vostro punto di accesso principale e la prima cosa che gli aggressori cercano di sondare. La configurazione predefinita (autenticazione tramite password, accesso come root, porta 22) è esattamente ciò che gli scanner automatici cercano.

Genera una coppia di chiavi Ed25519, che offre sicurezza e prestazioni migliori rispetto a RSA:

ssh-keygen -t ed25519

Una volta che l'accesso basato su chiave funziona, aggiorna /etc/ssh/sshd_config:

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

Cambia la porta predefinita da 22 a qualcosa di meno ovvio. Questo non fermerà un aggressore determinato, ma riduce significativamente il rumore delle scansioni automatiche.

Verifica sempre le modifiche da un secondo terminale prima di chiudere la sessione corrente. Esegui sudo sshd -t per verificare la presenza di errori di sintassi, quindi systemctl reload sshd per applicare le modifiche senza interrompere le connessioni attive.

Aggiungi l'autenticazione a due fattori

2FA significa che un hacker ha bisogno sia della tua chiave SSH che dell'accesso fisico al tuo dispositivo. Installa il modulo PAM di Google Authenticator:

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

Esegui google-authenticator per ogni utente per generare una chiave segreta e i codici di recupero. Conserva i codici di recupero offline.

Aggiungi questa riga a /etc/pam.d/sshd:

auth required pam_google_authenticator.so

Quindi aggiorna /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

Mantieni aperta una sessione attiva durante il test. I codici TOTP dipendono dall'ora di sistema esatta, quindi assicurati che NTP sia in esecuzione.

Configurare i firewall e Fail2Ban

Esegui un firewall basato su host anche se il tuo server si trova dietro un firewall di rete. Il principio è semplice: rifiuta tutto il traffico in entrata per impostazione predefinita, quindi consenti solo ciò di cui hai bisogno.

Per Ubuntu/Debian (UFW):

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

Per 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

Rafforzare lo stack di rete del kernel aggiungendo questi elementi a /etc/sysctl.conf:

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

Installare Fail2Ban

Fail2Ban monitora i tentativi di accesso e blocca gli IP dopo ripetuti fallimenti. Crea /etc/fail2ban/jail.local (non modificare jail.conf direttamente, gli aggiornamenti lo sovrascriveranno) e configurarlo in modo da bloccare gli IP per un'ora dopo tre tentativi falliti entro 10 minuti. Impostare il backend corretto per il proprio firewall (banaction = ufw o banaction = nftables).

Servizi di controllo e rimozione dei protocolli legacy

Controlla cosa è in ascolto con ss -tlnp e cosa è in esecuzione con systemctl list-units --type=service --state=running. Disattiva tutto ciò che non ti serve: Bluetooth, CUPS, avahi-daemon, rpcbind.

Rimuovi i protocolli legacy che trasmettono dati in chiaro:

Su Debian/Ubuntu: sudo apt-get --purge remove xinetd nis tftpd telnetd rsh-server. Su sistemi basati su RHEL: yum erase xinetd ypserv tftp-server telnet-server rsh-server. Verificare la rimozione con ss -tulpn.

Applicare patch e automatizzare gli aggiornamenti

L'aggiornamento del sistema è il modo più rapido per colmare le lacune di sicurezza note. Eseguire gli aggiornamenti immediatamente dopo il provisioning:

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

Quindi automatizza le patch di sicurezza. Su Debian/Ubuntu, installa unattended-upgrades e configurarlo in modo che applichi solo le patch di sicurezza. Su RHEL/Rocky, installare dnf-automatic e imposta upgrade_type = security in /etc/dnf/automatic.conf.

Configurare le notifiche via e-mail per i risultati degli aggiornamenti. Disabilitare i riavvii automatici sui server di produzione (Automatic-Reboot = false) in modo che avvengano durante le finestre di manutenzione pianificate. Per gli ambienti che richiedono un elevato tempo di attività, prendi in considerazione l’applicazione delle patch in tempo reale con Canonical Livepatch (Ubuntu) o kpatch (RHEL).

Rafforzare i file system e i permessi

Verificare innanzitutto i file binari SUID e SGID. Questi file vengono eseguiti con privilegi elevati e sono obiettivi primari per gli attacchi:

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

Restringere i permessi sui file critici: /etc/shadow dovrebbe essere 600, /etc/passwd dovrebbe essere 644, /etc/ssh/sshd_config dovrebbe essere 600. Impostare un umask di 027 in /etc/profile per impedire che i nuovi file siano leggibili da tutti.

Individuare e correggere i file scrivibili da tutti con find / -xdev -type f -perm -0002 -ls. Per le directory che devono rimanere scrivibili da tutti (come /tmp), applicare il bit sticky: chmod 1777 /tmp.

Opzioni di montaggio sicuro

Modifica /etc/fstab per limitare ciò che può accadere sulle partizioni critiche:

Verifica le modifiche con mount -o remount prima di riavviare per evitare problemi di avvio.

Abilitare i controlli di accesso obbligatori

SELinux e AppArmor aggiungono restrizioni a livello di kernel su ciò che i processi possono fare. Utilizza quello fornito dalla tua distribuzione: SELinux per RHEL/CentOS/Fedora, AppArmor per Ubuntu/Debian/SUSE. Passare da uno all'altro causa problemi di compatibilità.

SELinux: Verifica lo stato con getenforce. Iniziare in modalità permissiva (setenforce 0) per almeno due settimane per acquisire il comportamento del carico di lavoro senza causare interruzioni. Monitorare le violazioni con ausearch -m avc -ts recent. Utilizza audit2why per diagnosticare i blocchi e audit2allow -M [module_name] per creare moduli di policy. Una volta che i log sono puliti, passare alla modalità di applicazione con setenforce 1, quindi rendila permanente in /etc/selinux/config.

AppArmor: controlla i profili attivi con aa-status. Installare apparmor-utils per i comandi di gestione. Avvia i profili in modalità di segnalazione con aa-complain, quindi passare alla modalità di applicazione aa-enforce una volta che si è sicuri. Utilizzare aa-genprof per creare profili per applicazioni personalizzate.

Configurazione della registrazione e del monitoraggio degli audit

Senza la registrazione, gli incidenti non lasciano traccia. Installare auditd:

sudo apt-get install auditd audispd-plugins

Aggiungere il monitoraggio del file system per i file critici:

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

Tracciare l'esecuzione di tutti i comandi a livello di root:

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

Caricare le regole con augenrules --load e aggiungi -e 2 alla fine del file delle regole per rendere la configurazione a prova di manomissione (le modifiche richiedono un riavvio).

Monitoraggio dell'integrità dei file con AIDE

AIDE rileva le modifiche non autorizzate ai file confrontando lo stato attuale con una baseline nota come valida. Installalo, inizializza il database con aideinite sposta il file risultante in /var/lib/aide/aide.db.gz. Imposta un cron job giornaliero per eseguire aide --check e inviare i risultati via e-mail agli amministratori.

Centralizzare i log

I log locali sono inutili se un aggressore con accesso come root li cancella. Inoltra i log a un server remoto in tempo reale utilizzando rsyslog con crittografia TLS. Aggiungi a /etc/rsyslog.conf:

*.* @@remote-host:514

Set LogLevel VERBOSE nella configurazione SSH in modo che i log includano le impronte digitali delle chiavi per ogni accesso riuscito. Per gli ambienti di produzione che gestiscono più server, strumenti come Wazuh o OSSEC forniscono un sistema di rilevamento delle intrusioni basato sull'host con analisi centralizzata dei log.

Manutenzione continua

L'hardening non è un'attività una tantum. Le configurazioni cambiano, compaiono nuove vulnerabilità e i cambiamenti di personale lasciano account abbandonati.

Settimanale: esaminare i log di Fail2Ban, verificare la presenza di aggiornamenti non riusciti, verificare i backup.

Mensile: controllare gli account utente e le autorizzazioni, esaminare i servizi in esecuzione, eseguire una scansione completa con Lynis o OpenSCAP.

Trimestrale: ruotare le credenziali, aggiornare le regole del firewall, testare il ripristino di emergenza.

Utilizza strumenti di infrastruttura come codice (IaaSC) come Ansible con i ruoli di hardening di dev-sec.io per applicare configurazioni coerenti su tutta la tua flotta e prevenire deviazioni tra una verifica e l'altra.

I server dedicati di FDC offrono pieno accesso root e controllo completo sul proprio stack di sicurezza. Esplorare le opzioni di server dedicati per costruire su una piattaforma in cui si controlla ogni livello.