Fail2ban fermo da mesi su un VPS con Laravel: come un brute force SSH da 14.000 tentativi al giorno è passato inosservato
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. Continua a leggere
Ultima modifica:
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. 
Un VPS OVH con Debian 11 e Laravel 10 non vedeva un apt upgrade da 14 mesi. 247 pacchetti arretrati, 38 security patch mancanti, OpenSSH con regreSSHion non patchato. Il proprietario non lo sapeva - l'app funzionava. Il protocollo per aggiornare un server di produzione senza downtime: snapshot, dry run, upgrade in due fasi, needrestart, verifica applicativa e setup unattended-upgrades. 
Un VPS Contabo con un e-commerce B2B Laravel è rimasto fermo 60 ore - dal venerdì pomeriggio al lunedì mattina - perché il certificato SSL era scaduto e nessuno se n'era accorto. 80 ordini persi, circa 35.000 euro di fatturato evaporato in un weekend. Il problema non era il certificato: era l'assenza totale di monitoring. Prometheus, Grafana, Alertmanager, health check Laravel e regole di alerting concrete: ecco lo stack che installo su ogni VPS che prendo in carico. 
Quando un'applicazione Laravel cresce oltre le capacità di un hosting condiviso, la migrazione verso un VPS diventa inevitabile. Il problema è che molte PMI la affrontano come un trasloco meccanico, quando in realtà è una transizione architetturale che richiede pianificazione, hardening e verifica. In questo articolo racconto il metodo che applico nelle migrazioni reali, con le trappole più comuni e le decisioni che fanno la differenza tra un passaggio pulito e settimane di problemi. 
Quando il sito entra in maintenance mode per un deploy finito male e nessuno lo sa riportare online, il business perde fatturato per mesi in silenzio. Il caso reale di un e-commerce B2B HoReCa bolognese del giugno 2025 su Contabo VPS L, Laravel 9.52 in manutenzione da dodici settimane, il deploy abortito a metà con migration orfane e code bloccate, e i quattro giorni di lavoro con cui ho ricostruito lo stato consistente senza rifare l'applicazione.