Pagina 1 di 1
La maggior parte dei server Linux in produzione è configurata con default comodi, non sicuri. SSH su 22 con password, firewall permissivo, aggiornamenti manuali sporadici, utenti con più privilegi del necessario. L'hardening di base riduce drasticamente la superficie d'attacco in poche ore di lavoro.
In questa categoria scrivo di sicurezza server: hardening SSH, firewall (nftables/ufw), fail2ban, aggiornamenti automatici, SELinux/AppArmor, monitoring di sicurezza. Scrivimi per un audit del tuo server, scopri il mio approccio.
Accedere al database MySQL di produzione da remoto senza esporlo su internet è un requisito frequente. Con SSH tunneling si ottiene un accesso sicuro con crittografia end-to-end senza modificare il firewall. Vi mostro i comandi per i casi d'uso più comuni che uso ogni giorno: MySQL, Redis, Elasticsearch e RDP. Continua a leggere
ModSecurity con le regole OWASP CRS di default blocca il 30% delle richieste legittime su applicazioni PHP complesse. Il tuning è il lavoro vero. Vi mostro il processo che uso: audit mode per una settimana, analisi delle regole che scattano di più, whitelist chirurgiche e graduale passaggio a blocking mode. Continua a leggere
Alle 2 di notte, un cliente mi chiama: il suo VPS ha comportamenti anomali. Nei successivi 30 minuti, ho fatto un elenco di azioni in ordine preciso. Quell'ordine è importante: sbagliarlo significa perdere prove forensi o dare tempo all'attaccante. Vi scrivo il runbook che tengo sempre pronto. Continua a leggere
Le best practice SSH standard (porta non-22, root disabilitato, chiavi invece di password) le applica ormai quasi tutti. Ma i tentativi di accesso continuano. Vi mostro le misure avanzate che aggiungo su VPS esposti: certificati SSH con CA interna, 2FA TOTP, AllowedUsers restrittivo e alert real-time. Continua a leggere
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
VPS compromesso: CPU al 100%, login SSH a forza bruta riusciti, un cryptominer nascosto in /dev/shm camuffato da thread del kernel. Il playbook di incident response che applico su un server unmanaged: triage senza riavviare, conservazione delle evidenze, forensics, eradicazione della persistenza, ripristino e hardening post-incidente. Con la prospettiva offensiva su come entra l'attaccante e cosa lascia dietro di sé. Continua a leggere
