I Primi 30 Minuti: Checklist di Hardening VPS

Un VPS fresco riceve il primo probe SSH entro pochi minuti dall'ottenere un IP. Ecco la sequenza esatta che eseguo su ogni nuova macchina — pronta per copia-incolla su Debian 13, con una tabella checklist alla fine.

Presupposti: un'immagine Debian 13 fresca dal tuo deploy VPSRento, sei loggato come root via SSH, e l'IP di esempio è 185.220.101.14 — sostituiscilo con il tuo. Tempo totale: circa mezz'ora. Segui i passaggi in ordine; il passaggio 2 può bloccarti fuori se lo fai di fretta.

1. Crea il tuo utente sudo

Lavorare come root è il modo in cui i refusi diventano incidenti. Crea un utente reale, dagli sudo, e fai tutto da lì:

Copy# create the user (you'll set a password — still useful for sudo)
adduser ops

# grant sudo
usermod -aG sudo ops

Tutto ciò che segue viene eseguito come ops salvo diversa indicazione.

2. Solo chiavi SSH — niente password, niente login root

L'autenticazione con password è il più grande buco su una macchina esposta a internet. I bot martellano la porta 22 con liste di credenziali tutto il giorno, ogni giorno. Le chiavi rendono irrilevante l'intera classe di attacchi. Su la tua macchina locale:

Copy# generate a keypair if you don't have one (ed25519, no passphrase tradeoff is yours)
ssh-keygen -t ed25519 -C "ops@atlas"

# push the public key to the server
ssh-copy-id [email protected]

Verifica di poter accedere con la chiave in un nuovo terminale — ssh [email protected] — prima di toccare la configurazione. Tieni aperta la sessione root esistente come via di fuga. Poi modifica /etc/ssh/sshd_config:

Copy# /etc/ssh/sshd_config — the three lines that matter
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Copy# validate the config, then reload (Debian 13 uses ssh.service)
sshd -t && systemctl reload ssh

prohibit-password piuttosto che un file piatto no per root di proposito: root può ancora autenticarsi con una chiave dalla tua workstation, il che è occasionalmente utile per il recupero tramite console del provider — ma nessuna password funzionerà mai, per nessuno, da nessun luogo. Conferma con sshd -T | grep -E 'passwordauthentication|permitrootlogin'.

3. Firewall: rifiuto predefinito, consenti solo ciò che esegui

Il ufw di Debian è un livello sottile e sensato sopra nftables. La policy è la sicurezza; le regole sono solo eccezioni ad essa:

Copyapt update && apt install -y ufw

ufw default deny incoming
ufw default allow outgoing

# SSH stays open — add this BEFORE enabling
ufw allow 22/tcp comment 'SSH'

# whatever your box actually serves, e.g.:
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'

ufw enable
ufw status verbose

Ogni porta che apri dovrebbe avere un nome e una ragione. Se non puoi dire a cosa serve una porta, non ottiene una regola.

4. fail2ban: rallenta i bot fino a strisciare

Con l'autenticazione password disabilitata, la forza bruta è già morta — ma fail2ban mantiene i tuoi log leggibili e banna gli scanner che curiosano su tutto il resto:

Copyapt install -y fail2ban

Copy# /etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = ssh
maxretry = 5
findtime = 10m
bantime  = 1h

Copysystemctl enable --now fail2ban

# watch it work
fail2ban-client status sshd

5. Aggiornamenti di sicurezza automatici

La CVE non patchata è un rischio più grande del riavvio. Gli unattended-upgrades di Debian installano gli aggiornamenti di sicurezza da soli:

Copyapt install -y unattended-upgrades

# answer Yes to auto-install updates
dpkg-reconfigure -plow unattended-upgrades

La configurazione predefinita in /etc/apt/apt.conf.d/50unattended-upgrades attinge solo dalla suite di sicurezza — che è ciò che vuoi su un server: fix di sicurezza automatici, tutto il resto quando scegli tu.

6. Disattiva ciò che non esegui

Ogni servizio in esecuzione è superficie d'attacco che devi patchare. Vedi cosa sta effettivamente in ascolto:

Copy# who is listening, on what, as which process
ss -tulpn

# everything enabled at boot
systemctl list-unit-files --state=enabled

# example: you don't run a print server — nobody does
systemctl disable --now cups

La regola: se non puoi dire cosa fa un listener, scoprilo prima di lasciarlo vivere. Su un'immagine VPSRento minimale dovrebbe esserci ben poco oltre sshd e la tua applicazione.

7. Opzionale ma consigliato: un piano di gestione WireGuard

La versione più forte della sicurezza SSH è una SSH che non è affatto esposta a internet. Esegui WireGuard sulla macchina, consenti SSH solo all'interno del tunnel e la porta 22 sparisce da ogni scanner del mondo:

Copyapt install -y wireguard

# /etc/wireguard/wg0.conf — minimal management tunnel
# [Interface] Address = 10.8.0.1/24, ListenPort = 51820

# open the tunnel, not the shell
ufw allow 51820/udp comment 'WireGuard'
ufw allow in on wg0 to any port 22 proto tcp comment 'SSH via WG'
ufw delete allow 22/tcp

systemctl enable --now wg-quick@wg0

Dopo di che ssh [email protected] attraverso il tunnel, e l'IP pubblico risponde su esattamente una porta UDP. La guida completa a WireGuard — chiavi, peer, configurazioni client, QR code per il telefono — è nella guida complementare.

La checklist in 10 punti

Scorri questa tabella dopo ogni nuovo deploy, e di nuovo dopo ogni servizio che aggiungi:

La voce 10 merita una frase: prima hardening, poi snapshot, in quest'ordine — uno snapshot di una macchina pulita e indurita è il tuo rollback per ogni errore futuro. Gli snapshot offsite giornalieri sono un componente aggiuntivo da $1.99/mese nell' area clienti. Trenta minuti di prevenzione, un clic di assicurazione.