Configurare firewall avanzati con nftables su VPS gestite senza personale tecnico qualificato: guida operativa Debian e Ubuntu
Un VPS con MySQL esposto su porta 3306 a tutto internet e nessun firewall attivo: 23.000 tentativi di connessione in 48 ore. Configuro nftables da zero con policy default-deny, anti SYN flood, egress filtering, rate limiting SSH e ban dinamici via Fail2ban. La configurazione operativa che applico a ogni VPS LEMP, identica su Debian 12, Debian 13 e Ubuntu. Continua a leggere
Ultima modifica:
Un e-commerce Laravel su Hetzner fermo da 3 ore: schermata bianca, nessun log visibile, PHP-FPM che si riavvia in loop. La causa era un segfault in OPcache innescato dall'aggiornamento a PHP 8.2.21. Diagnosi con dmesg e strace, fix con disabilitazione JIT, e il protocollo che uso per ogni emergenza PHP su VPS unmanaged. 
Un mysqldump che girava ogni notte sullo stesso disco del server non ha salvato una PMI manifatturiera dal ransomware: i backup erano sul filesystem cifrato dall'attaccante. Ricostruisco qui la strategia che applico come standard a ogni VPS unmanaged: 3-2-1-1-0, BorgBackup con repository append-only, encryption AES-256 lato client, retention GFS e restore verificato. Backup veri, non speranze. 
Una PMI ligure con e-commerce Laravel su OVH VPS pagava 89€/mese per un server con problemi di I/O ricorrenti. Ho migrato tutto su Hetzner CPX31 a 16€/mese con rsync incrementale, replica MySQL e cutover DNS in finestra notturna. Zero downtime, zero ordini persi, metà del costo. Il protocollo operativo che uso per ogni migrazione VPS tra provider. 
Fail2ban installato su un VPS Digital Ocean con SaaS Laravel ma fermo da sei mesi - disabilitato durante un aggiornamento e mai riattivato. 14.000 tentativi SSH brute force al giorno, inoffensivi solo perché l'autenticazione era a chiave. Ma il login web Laravel non aveva nessuna protezione. Diagnosi, riattivazione, jail SSH, jail custom per login web e ban progressivo con recidive. 
Un e-commerce Laravel era irraggiungibile da 6 ore - il server Hetzner era online, Nginx rispondeva, MySQL funzionava. Il problema: il dominio era stato trasferito a un nuovo registrar la sera prima, e il record NS ancora puntava ai nameserver del vecchio provider che aveva già cancellato la zona DNS. Diagnosi in 10 minuti con dig e whois, fix con TTL basso e propagazione controllata, e le 5 misconfigurazioni DNS che trovo più spesso su VPS di PMI. 
Un portale B2B Laravel su Hetzner con certificato Let's Encrypt scaduto da 11 giorni - il rinnovo automatico di Certbot falliva perché la porta 80 era bloccata da una regola UFW aggiunta durante un hardening. HSTS attivo con max-age di un anno impediva il fallback a HTTP: il sito era un fantasma per tutti i browser. Diagnosi con openssl s_client, fix Certbot, rollout HSTS graduale e hardening Nginx per TLS 1.3 con A+ su SSL Labs. 
Un portale B2B Laravel su VPS OVH andava in 502 Bad Gateway ogni giorno tra le 10 e le 11 del mattino - l'ora di punta degli ordini. PHP-FPM veniva ucciso dall'OOM killer del kernel perché pm.max_children era impostato a 200 su un server con 8 GB di RAM e worker da 80 MB ciascuno. La matematica non tornava: 200 × 80 MB = 16 GB, il doppio della RAM disponibile. Diagnosi con dmesg, tuning di pm.max_children, auto-restart con systemd e prevenzione. 
Su un VPS Contabo con un gestionale Laravel 10, i backup automatici con spatie/laravel-backup fallivano da tre mesi - disco pieno sullo storage S3, credenziali scadute, e il notification channel configurato su un webhook Slack che non esisteva più. Il titolare l'ha scoperto quando ha avuto bisogno di un restore. Diagnosi delle cause di fallimento, ripristino della pipeline, test di restore verificato e monitoring che avvisa davvero quando qualcosa non funziona. 
Un e-commerce Laravel su Hetzner inviava 800 email transazionali al giorno tramite Postfix locale. Il 40% finiva in spam su Gmail, il 15% non arrivava affatto su Outlook. Il titolare non lo sapeva perché nessuno monitorava i bounce. Diagnosi: niente SPF, niente DKIM, niente DMARC, IP del VPS in due blacklist. La soluzione non era "aggiustare Postfix" - era ripensare come un'applicazione Laravel in produzione deve gestire le email transazionali nel 2025.