Indurire un nuovo VPS

Cosa compromette davvero i server

Non zero-day. In pratica: forza bruta della password SSH contro credenziali deboli, servizi non aggiornati lasciati attivi per mesi, pannelli di amministrazione esposti con password predefinite e vulnerabilità applicative in ciò che l'operatore ha installato. La lista è noiosa e non è cambiata in quindici anni.

La checklist qui sotto è ordinata in base a quanto rischio rimuove ogni passo per minuto speso. Fai questi passi nell'ordine e fermati quando perdi la pazienza — avrai comunque rimosso la maggior parte del rischio.

Passo 1 — Solo chiavi SSH

Questa singola modifica elimina completamente l'attacco più comune. Genera una chiave Ed25519, copia la metà pubblica sul server, poi modifica /etc/ssh/sshd_config per impostare PasswordAuthentication no, PermitRootLogin prohibit-password e KbdInteractiveAuthentication no.

Prima di chiudere la prima sessione, testa la chiave in un secondo terminale. Chiudersi fuori è imbarazzante e, su una macchina con accesso alla console, del tutto recuperabile — ma fallo comunque nell'ordine giusto.

Passo 2 — firewall a default deny

nftables su Debian e Ubuntu moderni, o firewalld su derivate RHEL. Default-deny in ingresso, permette il traffico stabilito e correlato, permette la tua porta SSH, permette ciò di cui il carico di lavoro ha effettivamente bisogno e nient'altro.

La disciplina importante è che "nient'altro" è il punto centrale. Un firewall con una regola permissiva aggiunta durante il debug e mai rimossa è un firewall che non fa nulla.

• Policy predefinita: scarta in ingresso, accetta in uscita
• Accetta stabilito e correlato
• Accetta loopback
• Accetta la tua porta SSH, idealmente con rate limiting
• Accetta le porte del carico di lavoro, elencate esplicitamente
• Accetta ICMP echo — non rompere la path MTU discovery

Passo 3 — aggiornamenti di sicurezza automatici

unattended-upgrades su Debian e Ubuntu, dnf-automatic su derivate RHEL, configurati solo per gli aggiornamenti di sicurezza. La maggior parte delle compromissioni sfrutta vulnerabilità patchate mesi prima.

Abilita il riavvio automatico in una finestra di manutenzione se il tuo carico di lavoro lo tollera. Gli aggiornamenti del kernel non fanno nulla finché la macchina non si riavvia, e un server con 400 giorni di uptime e undici CVE del kernel in sospeso non è un distintivo d'onore.

Passo 4 — fail2ban, e una nota sul suo vero valore

Con l'autenticazione tramite password già disabilitata, fail2ban blocca relativamente poche compromissioni reali. Ciò che fa è ridurre drasticamente il rumore nei log, e questo conta perché un log pieno di migliaia di tentativi falliti è un log che nessuno legge, e i log non letti sono il modo in cui le intrusioni reali passano inosservate per settimane.

La jail sshd predefinita è sufficiente. Aggiungi jail per tutto il resto che esponi a internet.

Passo 5 — riduci la superficie d'attacco

Esegui ss -tlnp e guarda cosa è in ascolto. Su un'installazione predefinita, di solito include servizi che non sapevi fossero in esecuzione e di cui non hai bisogno. Rimuovili piuttosto che metterli dietro firewall — il software che non è installato non ha vulnerabilità.

Fai ascoltare i servizi che necessitano solo di accesso locale su 127.0.0.1 piuttosto che su 0.0.0.0. Un database in ascolto su tutte le interfacce dietro un firewall è a una configurazione errata dall'essere pubblico.

Cosa saltare

Cambiare la porta SSH riduce il rumore nei log e ferma esattamente zero attacchi mirati. Fallo se vuoi, ma non contarlo come sicurezza. Il port knocking aggiunge fragilità per un guadagno marginale. I sistemi di rilevamento intrusioni generano avvisi che nessuno esamina su un singolo server.

Se vuoi un altro passaggio significativo dopo i cinque sopra, sono i backup crittografati fuori sede in una giurisdizione diversa, testati eseguendo effettivamente il ripristino. La capacità di recupero vale più di un altro livello di prevenzione.