Perché questa serie
Un server Linux appena installato è comodo e insicuro: servizi in ascolto che non ti servono, un account root raggiungibile via SSH con password, permessi larghi, nessun audit. Hardening significa ridurre metodicamente tutto questo — la superficie d’attacco, i privilegi, le strade per muoversi dentro il sistema — fino a lasciare attivo solo ciò che serve, con il minimo dei permessi, sotto osservazione.
Questa serie è deliberatamente pratica. Niente elenchi di “best practice” senza contesto: ogni capitolo spiega perché un controllo conta e poi mostra i comandi e le configurazioni reali per applicarlo e verificarlo. Gli esempi sono pensati per distribuzioni mainstream (Debian/Ubuntu e RHEL/Fedora); dove divergono, lo segnalo.
Come leggerla
L’ordine costruisce dal basso: prima il modello (utenti, permessi), poi gli accessi (sudo, SSH, PAM), poi i servizi e la rete, la manutenzione, i controlli avanzati (capabilities, SELinux/AppArmor), il monitoraggio (auditd, journald, AIDE) e infine isolamento, kernel e automazione.
I capitoli
Fondamenta
- Il modello di sicurezza di Linux
- Utenti, gruppi e account
- I permessi dei file
- Permessi speciali: SUID, SGID, sticky
Accessi 5. sudo e l’escalation controllata 6. Hardening di SSH 7. Autenticazione e PAM
Servizi e processi 8. systemd: servizi e unit 9. Sandboxing dei servizi con systemd 10. Processi, risorse e cgroups
Rete 11. Firewall con nftables 12. Ridurre la superficie di rete
Manutenzione e boot 13. Aggiornamenti e gestione pacchetti 14. Boot sicuro e GRUB 15. Cifratura dei dischi con LUKS
Controlli avanzati 16. Capabilities: oltre il root tutto-o-niente 17. SELinux 18. AppArmor
Monitoraggio 19. Auditing con auditd 20. Logging e journald 21. Integrità dei file con AIDE
Isolamento, kernel, automazione 22. Namespaces e isolamento 23. Kernel hardening con sysctl 24. CIS Benchmark e automazione
Il filo conduttore
Tre principi attraversano ogni capitolo: privilegio minimo (dare il meno possibile, a persone e processi), superficie minima (ciò che non esiste non si attacca), e visibilità (un sistema che non osservi è un sistema di cui non sai nulla). Si parte dal modello che rende tutto il resto comprensibile: come Linux decide chi può fare cosa.