Introduzione
La sicurezza Ubuntu Server non inizia quando il server è già online da tre mesi, pieno di servizi esposti e con una password scelta “al volo” perché tanto “poi la cambiamo”. Inizia subito dopo l’installazione, prima di caricare siti, gestionali, database, pannelli, servizi web o qualsiasi altra cosa debba stare su quella macchina.
Ubuntu Server è una base solida, soprattutto nelle versioni LTS, ma “solido” non significa “automaticamente blindato”. Un server appena installato va configurato con un minimo di metodo: aggiornamenti, firewall, SSH, utenti, backup, log e qualche controllo periodico. Niente paranoia da bunker sotterraneo. Solo buone pratiche.
Questa è una checklist pratica, pensata per utenti tecnici, piccole aziende e PMI che vogliono mettere online un server senza lasciarlo in balia del primo scanner automatico che passa.
Perché serve una checklist di sicurezza
Un server esposto su Internet viene scansionato continuamente. Non perché qualcuno ce l’abbia con voi personalmente, ma perché la rete è piena di bot che cercano porte aperte, servizi vecchi, login deboli e configurazioni dimenticate.
La classica installazione “avanti, avanti, fine” può andare bene per provare Ubuntu in laboratorio. In produzione, invece, serve almeno una base di hardening.
La checklist minima serve a rispondere a domande molto semplici:
- il sistema è aggiornato?
- il firewall è attivo?
- SSH è configurato in modo sensato?
- il login root è disabilitato?
- esiste un utente amministrativo dedicato?
- ci sono backup verificabili?
- i log vengono controllati?
- il disco ha spazio sufficiente?
- i servizi esposti sono davvero necessari?
Sembra banale. Infatti lo è. Ed è proprio per questo che spesso viene ignorato.
1 – Aggiornare subito il sistema
La prima operazione dopo l’installazione è aggiornare il sistema.
Comandi base:
sudo apt update
sudo apt upgrade
sudo apt autoremove
Con apt update aggiorni l’elenco dei pacchetti disponibili. Con apt upgrade installi gli aggiornamenti. Con apt autoremove rimuovi pacchetti non più necessari.
Su un server appena installato è buona norma riavviare se vengono aggiornati kernel o componenti importanti:
sudo reboot
Dopo il riavvio:
uname -a
e:
lsb_release -a
Così verifichi versione del kernel e release Ubuntu installata.
Aggiornamenti automatici: sì, ma con criterio
Per molti server ha senso abilitare gli aggiornamenti automatici di sicurezza:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades
Non significa dimenticarsi del server. Significa ridurre il rischio di lasciare vulnerabilità note aperte per settimane.
Per server critici conviene comunque avere una finestra di manutenzione, backup prima degli aggiornamenti importanti e un minimo di controllo dopo il riavvio. Perché aggiornare è giusto, ma aggiornare a occhi chiusi su una macchina delicata è sport estremo mascherato da efficienza.
2 – Creare un utente sudo e non lavorare come root
Un server amministrato direttamente come root è comodo. Anche attraversare l’autostrada bendati è rapido, almeno per qualche secondo.
Meglio creare un utente dedicato:
sudo adduser nomeutente
sudo usermod -aG sudo nomeutente
Poi verificare l’accesso:
su – nomeutente
sudo whoami
Se il comando restituisce:
root
l’utente ha privilegi sudo.
Da quel momento, l’amministrazione ordinaria va fatta con l’utente sudo, non con login diretto root.
3 – Mettere mano a SSH prima di esporre il server
SSH è spesso la porta principale di amministrazione. Di conseguenza è anche una delle prime porte bersagliate.
Il file da controllare è:
sudo nano /etc/ssh/sshd_config
Le impostazioni minime da valutare sono:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Attenzione: prima di disabilitare l’accesso con password, bisogna configurare e testare l’accesso con chiave SSH. Altrimenti il server diventa molto sicuro: così sicuro che non ci entrate più nemmeno voi.
Configurare una chiave SSH
Sul PC client si genera una chiave:
ssh-keygen -t ed25519
Poi si copia la chiave pubblica sul server:
ssh-copy-id nomeutente@indirizzo-server
Testare l’accesso:
ssh nomeutente@indirizzo-server
Solo dopo aver verificato che l’accesso con chiave funziona, si può disabilitare l’autenticazione con password.
Riavvio del servizio SSH:
sudo systemctl restart ssh
Prima di chiudere la sessione attuale, aprire una seconda sessione SSH e verificare che l’accesso funzioni. Regola d’oro: mai chiudere l’unica porta mentre si è ancora dentro casa.
4 – Attivare UFW, il firewall di Ubuntu
Ubuntu mette a disposizione UFW, cioè Uncomplicated Firewall, un’interfaccia semplice per gestire le regole firewall.
Prima di abilitarlo, bisogna permettere SSH. Se si usa la porta standard:
sudo ufw allow OpenSSH
oppure:
sudo ufw allow 22/tcp
Poi si abilita il firewall:
sudo ufw enable
Controllo dello stato:
sudo ufw status verbose
Una configurazione minima dovrebbe consentire solo ciò che serve davvero. Per esempio, su un server web:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
Poi verificare:
sudo ufw status numbered
Regola pratica
Aprire solo le porte necessarie.
Se il server deve fare web, servono HTTP e HTTPS. Se deve essere amministrato via SSH, serve SSH. Se non deve esporre MySQL, PostgreSQL, Redis o altri servizi verso Internet, quelle porte non devono essere aperte pubblicamente.
Sembra ovvio. Poi però si trovano database ascoltare allegramente su tutte le interfacce, perché “tanto era solo per fare una prova”.
5 – Installare fail2ban
Fail2ban controlla i log e può bloccare temporaneamente indirizzi IP che generano troppi tentativi falliti.
Installazione:
sudo apt install fail2ban
Creare una configurazione locale:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Aprire il file:
sudo nano /etc/fail2ban/jail.local
Per SSH si può partire da una configurazione semplice:
[sshd]
enabled = true
port = ssh
maxretry = 5
bantime = 1h
findtime = 10m
Riavviare fail2ban:
sudo systemctl restart fail2ban
Verificare lo stato:
sudo fail2ban-client status
sudo fail2ban-client status sshd
Fail2ban non sostituisce chiavi SSH, firewall e password robuste. È uno strato in più. E sugli accessi SSH esposti è uno strato che ha senso.
6 – Controllare quali servizi sono in ascolto
Dopo l’installazione e dopo ogni configurazione importante, conviene vedere quali servizi ascoltano sulla rete.
Comando utile:
sudo ss -tulpn
Qui si vedono porte TCP/UDP, indirizzi di ascolto e processi collegati.
Attenzione particolare agli indirizzi:
0.0.0.0
o:
::
Significano che il servizio ascolta su tutte le interfacce.
Non è sempre sbagliato, ma va saputo. Un servizio interno dovrebbe spesso ascoltare solo su:
127.0.0.1
oppure su una rete privata.
7 – Disattivare quello che non serve
Ogni servizio attivo è una superficie d’attacco in più.
Per vedere i servizi:
systemctl –type=service –state=running
Per disabilitare un servizio non necessario:
sudo systemctl disable nome-servizio
sudo systemctl stop nome-servizio
Non bisogna disattivare cose a caso, naturalmente. Prima si capisce cosa fa il servizio, poi si decide.
La sicurezza non è spegnere tutto come un interruttore generale e poi chiedersi perché il server non funziona più. È lasciare attivo solo ciò che serve.
8 – Verificare AppArmor
Ubuntu usa AppArmor per limitare cosa possono fare alcuni processi. È uno strato di protezione importante perché riduce i danni nel caso un’applicazione venga compromessa.
Controllo stato:
sudo aa-status
Se il comando non è disponibile:
sudo apt install apparmor-utils
Poi:
sudo aa-status
In genere non serve modificare AppArmor su un server base, ma è utile sapere se è attivo e quali profili sono in enforcement.
9 – Configurare backup veri, non “copie speriamo bene”
Un server senza backup non è un server: è una scommessa con il destino.
La checklist minima:
- backup dei file importanti;
- backup dei database;
- backup delle configurazioni;
- copia fuori dal server;
- test periodico di ripristino.
Per esempio, per salvare configurazioni importanti:
sudo tar -czf etc-backup-$(date +%F).tar.gz /etc
Per database MySQL/MariaDB:
mysqldump -u utente -p nome_database > nome_database-$(date +%F).sql
Poi il backup va copiato altrove: NAS, storage remoto, server di backup, cloud, repository sicuro. Tenere il backup solo sullo stesso server è utile quanto tenere la ruota di scorta dentro l’auto mentre l’auto brucia.
Backup da controllare
Un backup non testato è una decorazione.
Ogni tanto bisogna provare a ripristinare:
- un file;
- un database;
- una configurazione;
- un intero servizio, se possibile.
È noioso. Ma molto meno noioso che spiegare al cliente che “i dati forse ci sono, ma non siamo sicuri”.
10 – Controllare log e accessi
I log raccontano cosa succede sul server. Non leggerli mai significa guidare con il parabrezza coperto.
Comandi utili:
sudo journalctl -xe
Per SSH:
sudo journalctl -u ssh
oppure, in base alla versione e configurazione:
sudo tail -f /var/log/auth.log
Per controllare gli ultimi accessi:
last
Per tentativi falliti:
lastb
Se lastb non mostra dati, può dipendere dalla configurazione del file /var/log/btmp.
Una buona abitudine è controllare periodicamente:
- accessi SSH;
- errori di autenticazione;
- servizi che falliscono;
- riavvii anomali;
- errori disco;
- log del firewall.
11 – Monitorare spazio disco e risorse
Un server può fermarsi anche senza essere “bucato”. Basta un disco pieno.
Controllo spazio:
df -h
Controllo inode:
df -i
Controllo directory più pesanti:
sudo du -h –max-depth=1 /var | sort -h
Controllo memoria:
free -h
Processi:
top
oppure:
htop
se installato:
sudo apt install htop
Da monitorare con attenzione:
- /var/log;
- directory dei backup;
- directory dei siti web;
- database;
- cache applicative;
- code email;
- snapshot dimenticati.
Un server con disco pieno può bloccare database, posta, aggiornamenti e servizi web. E naturalmente lo farà nel momento peggiore, perché ha senso dell’umorismo.
12 – Impostare hostname e timezone
Non è solo ordine estetico. Hostname e timezone corretti aiutano nei log, nel monitoraggio e nella gestione multi-server.
Hostname:
hostnamectl
Impostarlo:
sudo hostnamectl set-hostname nome-server
Timezone:
timedatectl
Per l’Italia:
sudo timedatectl set-timezone Europe/Rome
Verifica:
timedatectl
Log con orari sbagliati significano perdite di tempo quando bisogna capire cosa è successo. E quando c’è un problema, perdere tempo sui fusi orari è una forma raffinata di autolesionismo.
13 – Controllare gli utenti presenti
Verificare gli utenti locali:
cat /etc/passwd
Utenti con shell interattiva:
grep -E ‘/bin/bash|/bin/sh’ /etc/passwd
Verificare chi ha privilegi sudo:
getent group sudo
Controllare chi può accedere via SSH è fondamentale. Account dimenticati, utenti di test e vecchie credenziali sono un classico.
Quando un utente non serve più:
sudo deluser nomeutente
Se bisogna rimuovere anche la home:
sudo deluser –remove-home nomeutente
Da fare con attenzione, naturalmente.
14 – Proteggere i permessi dei file sensibili
Alcuni file meritano attenzione particolare.
Per esempio:
ls -l /etc/ssh/sshd_config
ls -l ~/.ssh
ls -l ~/.ssh/authorized_keys
Permessi tipici per .ssh:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Se i permessi sono troppo aperti, SSH può rifiutare la chiave o, peggio, si rischia di esporre configurazioni sensibili.
15 – Tenere traccia delle modifiche
Su un server aziendale è utile sapere cosa è stato cambiato, quando e perché.
Anche una documentazione minima può bastare:
- data installazione;
- versione Ubuntu;
- servizi installati;
- porte aperte;
- utenti amministrativi;
- posizione backup;
- procedure di ripristino;
- modifiche principali.
Non serve scrivere un romanzo. Serve evitare la classica scena: “Chi ha cambiato questa cosa?” seguita da silenzio, sguardi nel vuoto e colpe attribuite genericamente “agli aggiornamenti”.
Checklist rapida finale
Dopo l’installazione di Ubuntu Server, controllare almeno questi punti:
- Sistema aggiornato con apt update e apt upgrade.
- Utente amministrativo creato con privilegi sudo.
- Login diretto root disabilitato.
- Accesso SSH con chiave configurato e testato.
- Autenticazione SSH con password disabilitata, se possibile.
- Firewall UFW attivo.
- Solo porte necessarie aperte.
- Fail2ban installato e attivo.
- Servizi in ascolto controllati con ss -tulpn.
- Servizi inutili disabilitati.
- AppArmor verificato.
- Backup configurati e copiati fuori dal server.
- Ripristino backup testato.
- Log SSH e sistema controllati.
- Spazio disco monitorato.
- Timezone e hostname corretti.
- Utenti locali verificati.
- Documentazione minima aggiornata.
Conclusione
La sicurezza Ubuntu Server non è una singola opzione da attivare. È una somma di buone pratiche: aggiornamenti, firewall, accessi corretti, backup, log e manutenzione.
Un server ben configurato non diventa invulnerabile, perché l’invulnerabilità esiste solo nelle brochure commerciali e nei discorsi di chi non deve poi intervenire alle due di notte. Però diventa molto meno esposto agli errori banali, agli attacchi automatici e alle dimenticanze più comuni.
Per una PMI o per un professionista, questa checklist è il minimo sindacale prima di considerare un server “pronto”. Poi si può andare oltre con monitoraggio avanzato, hardening specifico, VPN, autenticazione a più fattori, segmentazione di rete e procedure più strutturate.
Ma il primo passo resta sempre lo stesso: non mettere online un server appena installato sperando che Ubuntu faccia tutto da solo. Ubuntu aiuta. Il resto bisogna configurarlo.