Mettere in sicurezza un nuovo VPS: la checklist

1. Installare tutti gli aggiornamenti

Le immagini cloud hanno spesso settimane. Aggiorna tutto prima di installare qualsiasi altra cosa, e riavvia se sono cambiati il kernel o le librerie di base.

sudo apt update && sudo apt full-upgrade -y
[ -f /var/run/reboot-required ] && echo "reboot needed"

sudo dnf upgrade --refresh -y
sudo dnf needs-restarting -r

Sulla famiglia RHEL, needs-restarting -r dice se serve un riavvio. Riavvia con sudo reboot e rientra.

2. Creare il tuo utente con sudo

Lavora come utente con nome e sudo, non come root: le azioni sono registrate a un nome, e l'accesso di root si può spegnere al passo successivo.

sudo adduser deploy
sudo usermod -aG sudo deploy

sudo useradd -m deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

Copia la tua chiave SSH sull'utente (ssh-copy-id deploy@SERVER_IP dal tuo computer), entra con l'utente da un secondo terminale e verifica sudo -v. Poi controlla che solo root abbia lo user ID 0 e che nessun account abbia la password vuota: il primo comando deve stampare solo root, il secondo niente.

awk -F: '$3 == 0 {print $1}' /etc/passwd
sudo awk -F: '$2 == "" {print $1}' /etc/shadow

3. Chiudere SSH

Solo chiavi, niente accesso di root, pochi tentativi per connessione. La procedura completa, con le verifiche e il cambio di porta, è in Come bloccare gli attacchi brute force SSH. La versione breve, quando l'accesso con chiave funziona:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 4
EOF
sudo sshd -t && echo "config OK"

sudo systemctl reload ssh

sudo systemctl reload sshd

4. Attivare il firewall

Blocca tutto in ingresso, poi apri solo quello che il server offre. Qui SSH sulla 22 e un web server su 80 e 443; togli quello che non usi.

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

• Su RHEL 9 e derivate la zona predefinita consente anche cockpit: toglilo con sudo firewall-cmd --permanent --remove-service=cockpit se non lo usi, poi ricarica.
• Docker pubblica le porte dei container con regole iptables sue, che ufw non vede: una porta pubblicata con -p 8080:80 è aperta anche se ufw dice il contrario. Pubblica su 127.0.0.1:8080:80 quando serve solo al proxy locale.
• Quasi tutti i provider hanno anche un firewall cloud o un security group. Usalo come secondo livello con le stesse regole.

5. Attivare gli aggiornamenti di sicurezza automatici

La maggior parte dei server compromessi usa software per cui una correzione esisteva da settimane. Lascia che il server installi da solo gli aggiornamenti di sicurezza.

sudo apt install -y unattended-upgrades
sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF
sudo unattended-upgrade --dry-run --debug 2>&1 | tail -n 20

Quali aggiornamenti vengono installati si imposta in /etc/apt/apt.conf.d/50unattended-upgrades (quelli di sicurezza su Ubuntu; quelli di sicurezza e delle point release su Debian). I riavvii automatici sono spenti, a meno di impostare lì Unattended-Upgrade::Automatic-Reboot "true";.

sudo dnf install -y dnf-automatic
sudo sed -i -e 's/^upgrade_type.*/upgrade_type = security/' \
  -e 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

• CentOS Stream non pubblica avvisi di sicurezza, quindi lì upgrade_type = security non installa niente: usa upgrade_type = default.
• Fedora 41 e successive usano dnf5: installa dnf5-plugin-automatic e imposta le stesse opzioni in /etc/dnf/automatic.conf (vedi man dnf5-automatic).
• Nessuno dei due riavvia da solo. Pianifica un riavvio quando si aggiorna il kernel.

6. Fare backup che escono dal server

Un backup sullo stesso server, o solo nello stesso account del provider, sparisce con il server o con l'account. Tieni almeno una copia altrove, cifrata, e prova un ripristino. Gli snapshot del provider sono utili in più, non al posto.

restic è un'opzione semplice: cifrato, deduplicato, verso SFTP, S3 e altri. È nei pacchetti di Debian e Ubuntu, e in EPEL per la famiglia RHEL. Sostituisci BACKUP_HOST con il tuo server di backup; restic chiede una password del repository, da conservare fuori da questo server.

sudo apt install -y restic

sudo dnf install -y epel-release
sudo dnf install -y restic

sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) init
sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) backup /etc /home /root /var/www
sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) snapshots

Esporta i database su file prima del backup (mysqldump --single-transaction, pg_dump) invece di copiare le loro directory dati mentre girano. Poi dimostra che il ripristino funziona:

sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) restore latest --target /tmp/restore-test --include /etc/hostname
cat /tmp/restore-test/etc/hostname

7. Attivare monitoraggio e avvisi

Devi sapere, senza entrare, quando il server è giù, quando il disco si riempie e quando qualcuno entra o lo attacca. Come minimo:

• Un controllo esterno di disponibilità sul sito o sul servizio, da fuori dal tuo provider.
• Un avviso sullo spazio disco e sui servizi falliti.
• Un registro di chi è entrato, e un avviso sugli attacchi e sulle modifiche ai file di sistema.

Finché non c'è qualcosa che lo fa per te, questi mostrano gli ultimi accessi, gli errori dall'avvio e lo spazio libero:

last -n 20
sudo journalctl -p err -b --no-pager | tail -n 30
df -h /

8. Chiudere le porte che non servono

Elenca cosa è in ascolto. Un indirizzo 0.0.0.0 o [::] vuol dire ogni interfaccia, quindi internet, a meno che il firewall non lo fermi.

sudo ss -tulpn

• Ferma e disattiva i servizi che non usi.
• Database e cache usati solo dallo stesso server ascoltano su localhost: bind-address = 127.0.0.1 per MySQL e MariaDB, listen_addresses = 'localhost' per PostgreSQL, bind 127.0.0.1 -::1 per Redis.
• Non esporre mai su internet l'API di Docker (2375, 2376) o Redis senza password: sono due vie d'ingresso comuni per i crypto miner.

sudo systemctl disable --now SERVICE_NAME

Poi verifica da fuori, da un'altra macchina con nmap. Devono rispondere solo le porte aperte al passo 4.

nmap -Pn SERVER_IP

9. Tenere l'orologio sincronizzato

I log di server diversi si allineano solo se gli orologi concordano, e TLS, codici a due fattori e cronologie degli incidenti dipendono tutti dall'ora. Controllala:

timedatectl

Deve dire System clock synchronized: yes. Se dice no:

sudo apt install -y systemd-timesyncd
sudo timedatectl set-ntp true

sudo dnf install -y chrony
sudo systemctl enable --now chronyd
chronyc tracking

10. Conservare i log abbastanza a lungo

Quando succede qualcosa, la prima domanda è cosa è successo prima. Rendi persistente il journal di sistema, con un limite di spazio e una conservazione che scegli tu:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/retention.conf > /dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=1G
MaxRetentionSec=1year
EOF
sudo systemctl restart systemd-journald
journalctl --disk-usage

• Dimensiona il limite sul disco: 1 GB basta per un server piccolo.
• Per quanto tempo conservare i log dipende da contratti e obblighi (per esempio la notifica degli incidenti NIS2). Decidilo, scrivilo e impostalo qui.
• I log tenuti solo sul server possono essere cancellati da chi entra. Mandane una copia anche a un'altra macchina o a un servizio di log.
• I file in /var/log (web server, auth.log su Debian e Ubuntu) sono ruotati da logrotate: il valore rotate in /etc/logrotate.d/ dice quanti file vecchi tenere.

Domande

Basta il firewall del provider, o serve anche ufw o firewalld?

Usali entrambi quando puoi. Il firewall del provider ferma il traffico prima che arrivi al server; quello sul server lo protegge ancora se le regole cloud vengono cambiate per errore o il server si sposta.

Gli aggiornamenti automatici sono sicuri su un server di produzione?

Gli aggiornamenti di sicurezza delle release stabili di queste distribuzioni sono piccoli e provati, e molto meno rischiosi che tenere falle note. Lascia spenti i riavvii automatici e pianificali, e tieni un backup provato.

Per quanto tempo devo conservare i log?

Non c'è un numero unico. Dipende dai contratti e da norme come la NIS2 per le aziende che rientrano. Decidi un periodo, tieni una copia lontano dal server, e fai in modo che il server conservi almeno quanto basta per indagare sulle ultime settimane.