Una checklist pratica per un VPS appena creato: autenticazione SSH con chiave, firewall, aggiornamenti automatici e monitoraggio - la base che applichiamo a ogni server EGYmass.
I sette passi di sicurezza che ogni VPS dovrebbe avere sono: autenticazione SSH con chiave, un firewall host, aggiornamenti automatici di sicurezza, una protezione anti-forza-bruta in stile fail2ban, TLS ovunque, backup automatici giornalieri e un monitoraggio che ti avvisa quando qualcosa non va.
Il login con password è il servizio più attaccato su Internet. Disattiva l'autenticazione tramite password e il login root via SSH, e richiedi una chiave - idealmente una chiave ed25519 protetta da passphrase, generata con ssh-keygen e copiata sul server con ssh-copy-id. La regola che ti salva dalla storia del restare chiuso fuori: tieni aperta la sessione attuale, modifica sshd_config impostando PasswordAuthentication no e PermitRootLogin prohibit-password, poi collegati da un secondo terminale e conferma che la chiave funziona. Solo allora puoi chiudere la prima sessione. Infine, tratta la chiave come la chiave di casa: una sul tuo computer, un backup offline e un percorso di recupero documentato - perché una chiave persa senza piano B significa un ticket di supporto e una reinstallazione forzata.
Apri solo le porte di cui un servizio ha davvero bisogno - in genere SSH, HTTP e HTTPS - e nega tutto il resto per impostazione predefinita: ogni pacchetto in ingresso rifiutato a meno che una regola esplicita lo permetta, traffico in uscita consentito. Applica le stesse regole a IPv6, non è un dettaglio di secondo piano - un server che filtra solo IPv4 resta pienamente raggiungibile tramite il suo secondo stack. Rendi le regole persistenti, così un riavvio non lascia il server completamente esposto. La trappola classica è attivare un firewall senza aprire la porta SSH attraverso la quale sei connesso: al primo pacchetto bloccato sei fuori, esattamente come perdendo la chiave - quindi apri prima quella porta e verifica da una seconda sessione prima di salvare.
Attiva gli upgrade non presidiati per le patch di sicurezza, così una CVE viene corretta in ore anziché in settimane. Gli aggiornamenti a livello di pacchetto sono quelli che non devono mai aspettare una persona; l'unica parte che merita una pianificazione deliberata è un aggiornamento del kernel, che richiede un riavvio per essere applicato - scegli una finestra di manutenzione, o usa il live patching se la distribuzione lo supporta. Due abitudini rendono sicuri gli aggiornamenti automatici invece di spaventare: leggi regolarmente il log degli aggiornamenti, così i fallimenti silenziosi emergono invece di accumularsi, e controlla i pacchetti bloccati o fissati, perché un pacchetto fissato e vulnerabile non si riparerà da solo. Gli aggiornamenti di sicurezza applicati con una settimana di ritardo sono il modo in cui piccoli server diventano parte di grandi botnet.
I bot martellano SSH e le pagine di login giorno e notte. Con SSH solo tramite chiave, l'attacco in forza sulla porta SSH è già una via morta - ed è esattamente per questo che i bot sono passati alle superfici ancora aperte: i login web, i pannelli di amministrazione, la posta. Esegui uno strumento come fail2ban o un limitatore di frequenza comparabile che banna i tentativi falliti ripetuti abbastanza a lungo da rendere l'indovinare economicamente inutile, e lascialo alimentare il firewall, così i ban diventano regole vere invece di righe di log. Aggiungi il rate limiting e un WAF davanti alle app web per filtrare le richieste malevole prima che raggiungano il tuo codice. Misuralo una volta al mese: se un singolo IP ieri ha prodotto migliaia di login falliti, la guardia sta facendo il suo lavoro.
Termina TLS 1.3 davanti ai tuoi servizi - come minimo 1.2, mai nulla di più vecchio - con cipher moderni e forti, e reindirizza ogni richiesta HTTP verso HTTPS, così un URL digitato male non consegna le credenziali alla rete. Aggiungi HSTS dopo che il redirect è attivo da un po', e blocca del tutto il downgrade al primo accesso. Gestisci i certificati con un client ACME automatizzato, con il rinnovo controllato ogni giorno e la data di scadenza esportata nel monitoraggio: un certificato che si rinnova in silenzio può anche fallire in silenzio, e un certificato scaduto è l'unico disservizio che i visitatori vedono prima di qualsiasi tua dashboard. Il rinnovo non deve mai essere un promemoria sul calendario che un giorno diventa silenziosamente un incidente.
Un backup che non hai mai ripristinato non è un backup - è una speranza. Automatizza snapshot giornalieri di ciò che ricostruisce davvero il servizio: i dump del database, i file di configurazione e i dati degli utenti, non solo l'intero disco. Conserva copie fuori dal server e idealmente fuori sede - questa è la differenza tra un guasto hardware e una brutta mattina - e imposta una politica di conservazione, così i backup vecchi si puliscono da soli invece di riempire il disco che monitori al passo sette. Cifra tutto ciò che lascia il server. Poi dimostralo: una volta ogni tre mesi, ripristina in un ambiente di prova e conferma che il servizio torna davvero - perché un backup silenziosamente corrotto fallirà nel giorno in cui ti serve, e quello è il giorno sbagliato per scoprirlo.
Non puoi rispondere a un incidente di cui non senti mai parlare. Monitora disco, memoria, CPU e la salute di ogni servizio, e genera avvisi sul trend anziché sullo stato binario: un disco all'85 percento in crescita è un avviso, un disco che resta all'85 percento per un anno non lo è. Includi ciò che si guasta in silenzio - la scadenza dei certificati, i job di backup che si sono fermati, i login falliti in forte aumento, gli aggiornamenti di sicurezza che non vengono più applicati - perché sono gli incidenti che altrimenti scopri dal messaggio di un cliente. Indirizza gli avvisi su un canale che qualcuno legge davvero, con una regola di escalation per notti e weekend. L'obiettivo è scoprire che un disco è quasi pieno prima che si porti giù il database con sé.
Prima le chiavi SSH e il firewall - sono i più economici e fermano gli attacchi più comuni -, poi gli aggiornamenti automatici, poi fail2ban. TLS, backup e monitoraggio possono seguire, ma nessuno dovrebbe attendere più di una settimana su un server esposto a Internet.
È la base. La produzione necessita anche di un livello WAF/IDS davanti, una procedura di ripristino testata, ambienti isolati e una politica di controllo degli accessi. Questi sette passi portano un server da vulnerabile-di-default a solido.
Sì - è esattamente la base che applichiamo a ogni server EGYmass, e lo stack dietro al nostro servizio di setup VPS. La stessa automazione e lo stesso monitoraggio tengono online anche i nostri prodotti.
Setup VPS EGYmass con multi-hosting, TLS 1.3, monitoraggio 24/7 e deployment automatizzato.
Filtraggio a livello di rete che tiene lontani dal tuo team e dai tuoi server i domini di malware e tracker.
Filtraggio a livello di rete che tiene lontani dai tuoi server e dal tuo team i domini di malware e tracking.
EGYmass si occupa di hosting, sicurezza e gestione continuativa - così tu puoi concentrarti sul tuo prodotto.
Consulenza gratuita