Lista di controllo per l'indurimento del server Linux

Un'installazione Linux predefinita non è un'installazione Linux sicura. La maggior parte delle violazioni è dovuta a configurazioni errate, come l'accesso root SSH aperto, firewall deboli e software non patchato. I nuovi server sono sottoposti a scansioni automatiche pochi minuti dopo la messa in linea, quindi l'hardening deve avvenire prima di ogni altra cosa.

Questa lista di controllo copre le fasi principali: blocco dell'SSH, configurazione dei firewall, patch, rafforzamento dei permessi sui file, abilitazione dei controlli di accesso obbligatori e impostazione dei log di audit.

Bloccare SSH

SSH è il punto di accesso principale e la prima cosa che gli aggressori sondano. La configurazione predefinita (password auth, login root, porta 22) è esattamente ciò che gli scanner automatici cercano.

Generate una coppia di chiavi Ed25519, che offre maggiore sicurezza e prestazioni rispetto a RSA:

ssh-keygen -t ed25519

Una volta che il login basato sulla chiave funziona, aggiornare /etc/ssh/sshd_config:

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

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

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

Aggiungere l'autenticazione a due fattori

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

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

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

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

auth required pam_google_authenticator.so

Quindi aggiornare /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

Mantenere una sessione attiva aperta durante i test. I codici TOTP dipendono dall'accuratezza dell'ora del sistema, quindi assicurarsi che NTP sia in funzione.

Configurazione di firewall e Fail2Ban

Eseguite un firewall basato sull'host anche se il vostro server si trova dietro un firewall di rete. Il principio è semplice: negare tutto il traffico in entrata per impostazione predefinita, quindi consentire solo quello necessario.

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 queste opzioni 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 vieta gli IP dopo ripetuti fallimenti. Creare /etc/fail2ban/jail.local (non modificare direttamente jail.conf, gli aggiornamenti lo sovrascriveranno) e configurarlo per vietare gli IP per un'ora dopo tre tentativi falliti nell'arco di 10 minuti. Impostare il backend corretto per il firewall(banaction = ufw o banaction = nftables).

Controllare i servizi e rimuovere i protocolli legacy

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

Rimuovere i protocolli legacy che trasmettono dati in chiaro:

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

Patch e aggiornamenti automatici

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

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

Quindi automatizzare le patch di sicurezza. Su Debian/Ubuntu, installate unattended-upgrades e configuratelo per applicare solo le patch di sicurezza. Su RHEL/Rocky, installare dnf-automatic e impostare upgrade_type = security in /etc/dnf/automatic.conf.

Impostare le notifiche via e-mail per i risultati degli aggiornamenti. Disattivare i riavvii automatici sui server di produzione(Automatic-Reboot = false) in modo che i riavvii avvengano durante le finestre di manutenzione pianificate. Per gli ambienti con tempi di attività elevati, considerare il live patching con Canonical Livepatch (Ubuntu) o kpatch (RHEL).

Protezione dei file system e dei permessi

Controllate innanzitutto i file binari SUID e SGID. Questi file vengono eseguiti con privilegi elevati e sono bersagli privilegiati per lo sfruttamento:

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 globale di 027 in /etc/profile per evitare che i nuovi file siano leggibili dal mondo.

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

Opzioni di montaggio sicuro

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

Testare 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. Utilizzate quello con cui viene fornita la vostra distribuzione: SELinux per RHEL/CentOS/Fedora, AppArmor per Ubuntu/Debian/SUSE. Il passaggio da un sistema all'altro causa problemi di compatibilità.

SELinux: Controllare lo stato con getenforce. Avviare in modalità permissiva(setenforce 0) per almeno due settimane per catturare il comportamento del carico di lavoro senza rompere nulla. Monitorare le violazioni con ausearch -m avc -ts recent. Usare audit2why per diagnosticare i blocchi e audit2allow -M [nome_modulo] per creare moduli di policy. Una volta che i registri sono puliti, passare all'applicazione con setenforce 1, quindi renderlo permanente in /etc/selinux/config.

AppArmor: controllare i profili attivi con aa-status. Installare apparmor-utils per i comandi di gestione. Avviare i profili in modalità complain con aa-complain, quindi passare alla modalità enforce con aa-enforce quando si è sicuri. Usare aa-genprof per creare profili per applicazioni personalizzate.

Impostare la registrazione e il monitoraggio degli audit

Senza registrazione, gli incidenti non lasciano traccia. Installate auditd:

sudo apt-get install auditd audispd-plugins

Aggiungere i controlli 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 aggiungere -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 linea di base nota. Installatelo, inizializzate il database con aideinit e spostate il file risultante in /var/lib/aide/aide.db.gz. Impostare un cron job giornaliero per eseguire aide --check e inviare i risultati via e-mail agli amministratori.

Centralizzare i registri

I log locali sono inutili se un utente malintenzionato con accesso root li cancella. Inoltrate i log a un server remoto in tempo reale usando rsyslog con crittografia TLS. Aggiungere a /etc/rsyslog.conf:

*.* @@remote-host:514

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

Manutenzione continua

L'hardening non è un'operazione una tantum. Le configurazioni vanno alla deriva, compaiono nuove vulnerabilità e i cambiamenti di personale lasciano gli account orfani.

Settimanalmente: Esaminare i registri Fail2Ban, controllare gli aggiornamenti non riusciti, verificare i backup.

Mensilmente: Controllare gli account utente e i permessi, esaminare i servizi in esecuzione, eseguire una scansione completa con Lynis o OpenSCAP.

Trimestrale: Ruotare le credenziali, aggiornare le regole del firewall, testare il disaster recovery.

Utilizzate strumenti di infrastructure-as-code come Ansible con i ruoli di hardening di dev-sec.io per imporre configurazioni coerenti in tutto il vostro parco macchine e prevenire le derive tra gli audit.

I server dedicati di FDC vi offrono un accesso root completo e il controllo totale del vostro stack di sicurezza. Esplorate le opzioni di server dedicati per costruire su una piattaforma in cui controllate ogni livello.