Hardening Linux 2026 per web agency: baseline seria per server di produzione

Molti parlano di hardening come se fosse una lista da spuntare una volta e dimenticare. In produzione non funziona così. L'hardening utile è una baseline operativa: riduce superficie d'attacco, limita i danni e rende più leggibili gli incidenti.

Questa guida raccoglie la baseline che ha senso applicare a un server Linux moderno per web agency. Non sostituisce un audit completo, ma evita il 90% degli errori più stupidi.

Per la parte solo SSH, hai già Hardening SSH: checklist operativa in 15 step. Se stai reagendo a una compromissione in corso, leggi prima Incident response: guida operativa per la prima ora. Se vuoi tradurre questa baseline in servizio continuativo, la pagina giusta è Security Hardening.

TL;DR

Baseline minima:

1. utenti e accessi puliti
2. patching e repository affidabili
3. firewall chiaro e minimale
4. servizi inutili spenti
5. log e audit attivi
6. backup e restore verificati
7. monitoring e alert presenti

Se ti manca uno di questi blocchi, il tuo hardening è incompleto.

1. Utenti: meno è meglio

Controlla subito:

getent passwd
last -20
lastb -20

Cose da fare:

• niente accessi condivisi
• niente utenti legacy senza owner
• niente root via SSH
• sudo nominativo, non generico
• chiavi SSH controllate e documentate

2. Patch management

Aggiornare “ogni tanto” non è una strategia.

apt update
apt list --upgradable
uname -a

Definisci:

• finestra patching
• criterio di priorità per CVE critiche
• processo di rollback
• verifica post-update

Patching senza finestra e senza verifica post-update crea downtime inutili.

3. Firewall

La regola giusta non è “blocca tutto perché sembra sicuro”. È: esponi solo ciò che serve davvero.

Con nftables, baseline minima:

nft add table inet filter
nft add chain inet filter input '{ type filter hook input priority 0; policy drop; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iif lo accept
nft add rule inet filter input tcp dport { 22, 80, 443 } accept

Poi restringi SSH, pannelli, exporter e accessi interni dove possibile.

4. Servizi inutili spenti

Ogni servizio aperto è una superficie in più.

ss -tulpn
systemctl list-unit-files --type=service --state=enabled

Se non sai perché un servizio è attivo, hai già un problema.

5. File system e permessi

Errori tipici:

• directory applicative scrivibili da tutti
• secret in file world-readable
• backup lasciati in web root
• script deploy con credenziali in chiaro

Controlli utili:

find /var/www -type f -perm -o+w
find / -xdev -type f -name "*.env" 2>/dev/null

6. Log e audit

Senza log, l'hardening è mezzo cieco.

Da tenere almeno:

• auth log
• journal systemd
• error log web server
• log applicativi
• slow log db se rilevante

Per casi più sensibili, attiva anche auditd o strumenti equivalenti.

7. Fail2ban e rate limiting

Fail2ban non salva il mondo, ma toglie rumore e attacchi banali.

apt install fail2ban
systemctl enable --now fail2ban
fail2ban-client status

Abbinalo a rate limiting e firewall, non usarlo come unica difesa.

8. Backup e restore

Un server hardened ma senza restore verificato resta fragile.

Questo è il motivo per cui il tema backup non va trattato separatamente dall'hardening. Integra questa baseline con Backup 3-2-1 WordPress: guida per web agency o con la pagina Backup & Disaster Recovery.

9. Monitoring minimo

Se nessuno ti avvisa che il disco è pieno o che un servizio è morto, l'hardening ti protegge solo a metà.

Aggiungi almeno:

• uptime esterno
• metriche host
• alert su disco, RAM, servizi
• log consultabili

Per questo c'è la guida Monitoring stack minimo: guida pratica per agency.

10. Contenuti applicativi

La sicurezza del sistema operativo non compensa:

• WordPress pieno di plugin abbandonati
• Magento senza patch
• pannelli admin esposti senza controllo
• chiavi API lasciate in chiaro

Hardening significa anche sapere dove finisce il sistema e dove inizia l'applicazione.

Errori classici

1. Hardening solo SSH

Meglio di niente, non abbastanza.

2. Copiare checklist senza capire lo stack

Rischi di rompere servizi leciti o lasciare buchi veri.

3. Fare tutto in una notte senza rollback

Modo perfetto per creare un incidente interno.

4. Nessuna documentazione

Dopo un mese nessuno ricorda cosa hai cambiato.

5. Nessuna revisione periodica

Un server sicuro nel 2025 può non esserlo più nel 2026.

Procedura pratica baseline

# 1. inventario
ss -tulpn
getent passwd
systemctl list-unit-files --type=service --state=enabled

# 2. patching
apt update && apt list --upgradable

# 3. log e accessi
last -20
lastb -20
journalctl -p err -n 50

# 4. spazio e permessi
df -h
find /var/www -type f -perm -o+w

Poi costruisci un piano di remediation per priorità:

• P1: accessi, servizi esposti, backup assenti
• P2: patching, log, alerting
• P3: ottimizzazioni e hardening avanzato

Quando questa guida non basta

Non basta se hai:

• requisiti compliance formali
• ambienti multi-server con segmentazione complessa
• incidenti già avvenuti
• clienti e-commerce ad alto rischio
• necessità di WAF, IDS/IPS o audit completo

In questi casi parti da Security Hardening o da un audit gratuito.

Checklist finale

• utenti nominativi e sudo controllato
• root SSH disabilitato
• patching definito
• firewall minimale attivo
• servizi inutili spenti
• log e audit consultabili
• backup verificati
• monitoring presente
• baseline documentata

L'hardening serio non rende un server invulnerabile. Lo rende meno esposto, più leggibile e meno costoso da difendere. Per un team operativo, è già un guadagno enorme.