Hardening di Linux nel 2026: la guida che parte dal threat model

La maggior parte delle guide all’hardening di Linux sono checklist. Ti dicono quali flag sysctl impostare, quali servizi disabilitare, quali moduli del kernel mettere in blacklist. Raramente rispondono alla domanda preliminare: contro quale minaccia ti stai effettivamente difendendo?

La risposta cambia il lavoro. Un giornalista che protegge le fonti da malware mirato ha bisogno di misure molto diverse da un sysadmin che riduce la superficie di attacco su un server senza minacce fisiche. Questa guida procede dal modello di minaccia alla misura, non dalla misura alla giustificazione.

È radicata nella tradizione di sicurezza di questo dominio — lo stesso pensiero operativo che ha animato la mailing list Secure Desktops (2015–2017), dove gli sviluppatori di Qubes OS, Tails e Subgraph discutevano di hardening pratico senza il marketing.

Passo zero: definisci il tuo modello di minaccia

Prima di toccare un solo file di configurazione, rispondi a queste quattro domande:

1. Chi è l’avversario? Opportunista occasionale, criminale organizzato, investigatore aziendale, Stato-nazione?
2. Cosa vogliono? File su disco, comunicazioni, credenziali, la tua identità, i tuoi contatti?
3. Come entreranno? Exploit di rete, accesso fisico, catena di fornitura, ingegneria sociale?
4. Quali risorse hanno? Tempo, denaro, zero-day, autorità legale?

Le misure di questa guida sono raggruppate per la minaccia che affrontano. Applica solo gli strati che corrispondono alle tue risposte. Fare un over-hardening di una workstation crea attrito senza un guadagno di sicurezza proporzionale, e l’attrito porta le persone a bypassare i controlli.

Hardening del kernel: parametri sysctl

I seguenti parametri sono appropriati per la maggior parte delle installazioni desktop e server hardenizzate. Non richiedono hardware specializzato e non hanno un impatto significativo sulle prestazioni.

# /etc/sysctl.d/99-hardening.conf

# Restrict kernel pointers from userspace (defeats certain info-leak attacks)
kernel.kptr_restrict=2

# Restrict dmesg access to root (prevents attackers reading kernel memory addresses)
kernel.dmesg_restrict=1

# Disable SysRq key (prevents certain physical-access attacks)
kernel.sysrq=0

# Restrict ptrace to processes with CAP_SYS_PTRACE (limits debug attach)
kernel.yama.ptrace_scope=2

# Disable unprivileged user namespaces (large attack surface, rarely needed on desktops)
kernel.unprivileged_userns_clone=0

# Disable unprivileged eBPF (significant attack surface for CVE exploitation)
kernel.unprivileged_bpf_disabled=1

# Enable TCP SYN cookies (basic DoS resistance)
net.ipv4.tcp_syncookies=1

# Disable ICMP redirects (routing manipulation attacks)
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0

# Disable source routing (rarely legitimate, used in spoofing attacks)
net.ipv4.conf.all.accept_source_route=0

# Enable reverse path filtering (defeats IP spoofing)
net.ipv4.conf.all.rp_filter=1

# Disable core dumps (prevents memory exposure of crashed processes)
fs.suid_dumpable=0

# Restrict symlink and hardlink following (prevents certain privilege escalation attacks)
fs.protected_symlinks=1
fs.protected_hardlinks=1

Applica subito senza riavvio:

sudo sysctl -p /etc/sysctl.d/99-hardening.conf

Da cosa questi non proteggono: sono parametri regolabili a livello di kernel, non difese a livello applicativo. Un exploit del browser che non ha bisogno di ptrace, user namespace o eBPF non è influenzato dai parametri pertinenti. Sono uno strato di supporto, non un sostituto dell’isolamento delle applicazioni (vedi Qubes OS se l’isolamento è il tuo requisito primario).

Mandatory Access Control: AppArmor vs SELinux

Sia AppArmor sia SELinux implementano il Mandatory Access Control (MAC): uno strato di policy che limita ciò che i processi possono fare indipendentemente dai permessi sui file. Il MAC impone il principio del minimo privilegio a livello di kernel.

AppArmor (predefinito su Ubuntu, Debian, SUSE)

AppArmor usa profili basati sul percorso. Ogni applicazione riceve un profilo che specifica quali file può leggere, scrivere o eseguire, quali capability può usare e quali operazioni di rete sono permesse. I profili operano in due modalità: enforce (le violazioni vengono bloccate e registrate) e complain (le violazioni vengono registrate ma permesse — utile durante lo sviluppo).

# Check AppArmor status
sudo apparmor_status

# List all loaded profiles
sudo aa-status

# Put a profile into enforce mode
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

# Generate a new profile for an application
sudo aa-genprof /usr/bin/myapp

I repository di Ubuntu e Debian includono profili preconfezionati per le applicazioni comuni. Installali:

sudo apt install apparmor-profiles apparmor-profiles-extra

Raccomandazione pratica: su un sistema Ubuntu o Debian, assicurati che AppArmor sia abilitato all’avvio (verifica con sudo apparmor_status | grep "profiles are in enforce mode") e che Firefox, Chromium e qualsiasi processo server (nginx, sshd, cups) girino con profili in modalità enforce.

SELinux (predefinito su Fedora, RHEL, CentOS)

SELinux usa policy basate su etichette. Ogni processo, file, socket e utente riceve un contesto di sicurezza (un’etichetta), e le regole della policy definiscono quali contesti possono interagire. È più granulare di AppArmor ma significativamente più complesso da mantenere.

Su Fedora, SELinux è abilitato in modalità Enforcing per impostazione predefinita. Verifica:

getenforce
# Should output: Enforcing

Non disabilitare SELinux. Una risposta comune e sbagliata ai dinieghi di SELinux è setenforce 0. Invece, diagnostica il diniego:

sudo ausearch -m avc -ts recent | audit2allow -a

Lo strumento audit2allow suggerisce moduli di policy che permetterebbero l’azione negata. Esaminali prima di applicarli — l’obiettivo è capire perché si è verificato il diniego, non permetterlo in blocco.

Parametri di boot del kernel

I parametri di boot (impostati nella configurazione di GRUB) si applicano prima nel processo di avvio rispetto a sysctl e affrontano superfici di attacco diverse.

Aggiungi a GRUB_CMDLINE_LINUX in /etc/default/grub, poi esegui sudo update-grub:

# Disable SMT if you have a high-threat CPU side-channel model (Spectre, MDS)
# Performance cost: significant (up to 30–50% on multi-threaded workloads)
# Only appropriate for threat models involving local co-tenancy or targeted CPU attacks
# mitigations=auto,nosmt

# Enable all CPU vulnerability mitigations (default on most distros, worth verifying)
mitigations=auto

# Randomize page allocation (increases difficulty of certain heap exploitation)
page_alloc.shuffle=1

# Enable kernel lockdown (Integrity or Confidentiality mode)
# Locks down several features used by rootkits; may break some functionality
lockdown=integrity

# Disable old IPv4 network protocols rarely used (reduce attack surface)
ipv6.disable=0   # Keep IPv6 enabled; disable if genuinely unused

# Disable Firewire DMA (physical access attack vector on older hardware)
module.sig_enforce=1

Nota su lockdown=confidentiality: questa modalità impedisce anche a root di leggere la memoria del kernel tramite /dev/mem e interfacce simili. Rompe alcuni usi legittimi (certi driver, kexec, ibernazione). Usa la modalità integrity a meno che tu non abbia un motivo specifico per confidentiality.

Hardening del filesystem e dei servizi

Opzioni di mount

In /etc/fstab, aggiungi opzioni di mount di sicurezza dove appropriato:

# /tmp: no execution, no device files, no SUID bits
tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid 0 0

# /var/tmp: same
tmpfs /var/tmp tmpfs defaults,noexec,nodev,nosuid 0 0

# /home: no device files, no SUID (noexec breaks some workflows — test first)
/dev/mapper/home /home ext4 defaults,nodev,nosuid 0 2

Disabilita i servizi non utilizzati

Ogni servizio in esecuzione è una superficie di attacco. Su un desktop:

# List enabled services
systemctl list-unit-files --state=enabled

# Common candidates for disabling on a desktop with no network service requirements:
sudo systemctl disable cups   # Printing — if you never print
sudo systemctl disable avahi-daemon  # mDNS — if you don't need .local resolution
sudo systemctl disable bluetooth  # If not using Bluetooth

Su un server, il principio è più aggressivo: dovrebbero girare solo i servizi necessari alla funzione dichiarata della macchina. Ogni socket in ascolto dovrebbe avere una ragione documentata per esistere.

Verified Boot e Secure Boot

Secure Boot con le tue chiavi registrate (non solo le chiavi Microsoft predefinite) protegge dai bootkit che si caricano prima del sistema operativo. Su Fedora e Ubuntu, le distribuzioni firmano il loro bootloader e kernel con chiavi che il firmware UEFI considera affidabili per impostazione predefinita.

Per una configurazione a maggiore garanzia, sostituisci le chiavi predefinite con le tue:

1. Genera la tua Platform Key (PK) e Key Exchange Key (KEK).
2. Registra la tua chiave nel firmware UEFI (il processo varia in base al produttore).
3. Firma il tuo bootloader e i tuoi kernel con la tua chiave usando sbsign.
4. Disabilita “Other OS” o “Compatibility Support Module” nel firmware UEFI.

Questo è operativamente complesso e generalmente appropriato solo per deployment ad alta minaccia. Il progetto firmware Heads e progetti simili spingono oltre, estendendo il measured boot a una catena di fiducia ancorata al TPM.

Checklist per modello di minaccia

Opportunista / malware di massa: valori predefiniti di sysctl sopra, AppArmor/SELinux in enforcing, disco cifrato (LUKS), aggiornamenti regolari. Questo gestisce il 95% delle minacce comuni.

Attaccante mirato con accesso alla rete: aggiungi la minimizzazione dei servizi, un firewall restrittivo (nftables/ufw), il sandboxing delle applicazioni (Firejail o Flatpak), il monitoraggio del traffico di rete in uscita.

Avversario con accesso fisico e risorse: cifratura dell’intero disco con passphrase robusta + backup dell’header, Secure Boot con chiavi personalizzate, Tails OS per le operazioni sensibili, valuta Qubes OS per la compartimentazione. Rivedi la carta di Secure Desktops per i principi operativi dietro queste scelte.

Livello statale / Stato-nazione: valuta se una workstation Linux hardenizzata sia davvero lo strumento giusto. Qubes OS con un’architettura qubes attenta è più vicino allo strumento appropriato. Macchine air-gapped per le operazioni più sensibili. Nessun single point of failure per il materiale crittografico.

FAQ

D: Disabilitare gli user namespace non privilegiati rompe qualcosa? R: Rompe le applicazioni che vi fanno affidamento senza root — in particolare il sandboxing di Chromium sui sistemi che lo usano, e certi container runtime (Docker/Podman rootless). Su Ubuntu/Debian desktop, probabilmente dovrai riabilitarlo per Chromium. Il compromesso è documentato; decidi in base al tuo modello di minaccia.

D: Dovrei usare un kernel hardenizzato (linux-hardened su Arch, o grsecurity)? R: linux-hardened in Arch Linux applica un insieme ragionevole di patch di hardening upstream e vale la pena usarlo se sei su Arch. Le patch grsecurity non sono più disponibili pubblicamente. Il kernel upstream ha assorbito molte funzionalità un tempo esclusive di grsecurity (KASLR, stack protector, FORTIFY_SOURCE, ecc.) dalla fine degli anni 2010.

D: Fedora o Ubuntu è più hardenizzato di default? R: Entrambi sono distribuiti con MAC in enforcing (SELinux su Fedora, AppArmor su Ubuntu), valori predefiniti moderni di mitigazione del kernel e aggiornamenti di sicurezza automatici. Fedora in genere distribuisce versioni del kernel più recenti più velocemente. Ubuntu LTS scambia l’avanguardia per il supporto a lungo termine. Per una workstation hardenizzata, entrambi sono un punto di partenza ragionevole; le misure di questa guida si applicano a entrambi.