VPN a prova di bomba nel 2026: checklist passo passo per hardening, permessi e firewall

Perché l'hardening del server VPN nel 2026 non è più un lusso, ma un obbligo

Gli attacchi sono più veloci, ma gli errori restano gli stessi

Mettiamola così: un server VPN è la porta d'accesso alla nostra rete. Se la serratura alla porta è arrugginita, il resto serve a poco. Nel 2026 gli attaccanti hanno automatizzato oltre l’80% degli attacchi ai punti di accesso pubblici, con bot che scandagliano porte UDP e TCP, controllano versioni dei protocolli, configurazioni di default e persino differenze nei tempi di handshake. Possiamo permetterci errori? Assolutamente no. Qualsiasi sbaglio può far trapelare dati dei clienti e ci costringerà a giustificazioni interminabili. Meglio investire nella prevenzione.

L'hardening non è un problema, è disciplina

Molti confondono l'hardening con paranoia. In realtà si tratta di disciplina e pratiche ripetibili: permessi minimi, perimetro chiuso, regole di routing precise, audit regolari. Fai bene una volta e poi mantieni. Non costruiamo mura di cemento senza finestre, installiamo porte intelligenti, telecamere e allarmi. E sì, non è affatto spaventoso.

Performance e sicurezza possono convivere

C’è il mito che la sicurezza penalizzi la velocità. Falso. Gli stack moderni — WireGuard con ChaCha20-Poly1305, OpenVPN su TLS 1.3 e AES-GCM — offrono alta velocità anche con nftables rigorosi e limitazioni di sistema. Sysctl mirati, filtri eBPF, separazione tra piano di controllo e dati: sicurezza e velocità insieme. Qual è il trucco? La configurazione. Ma per questo c'è la checklist.

Modello di minaccia e scelta del protocollo: WireGuard, OpenVPN o IPSec

Definiamo il modello di minaccia

Prima di stringere le viti conviene chiarire da cosa e chi ci difendiamo. Il modello tipico nel 2026 per un server VPN comprende: scanner massivi, attacchi brute force sulle chiavi di gestione, sfruttamento di vulnerabilità nei daemon, phishing contro amministratori, tentativi di DDoS e exhaustion, fughe di chiavi e configurazioni, errori di routing e fughe DNS. A parte, i rischi cloud: abuso di metadata, politiche IAM deboli, security group troppo aperti. Tutto questo guida la scelta di stack e configurazioni.

WireGuard: moderno e minimalista

WireGuard è diventato lo standard per semplicità e velocità. Codice snello, crittografia solida di default, chiavi Ed25519, architettura stateless. Ideale per site-to-site e accessi utenti. Ma manca l’autenticazione tramite password o MFA a livello protocollo: tutto si basa sulle chiavi. Quindi gestione chiavi e politiche di emissione sono fondamentali. Si vuole SSO? Serve un livello superiore, ad esempio controllo accessi tramite coordinator o proxy.

OpenVPN: classico flessibile con TLS 1.3

OpenVPN non tramonta. Dove servono PKI complesse, CRL, certificati client, autenticazione PAM, LDAP o RADIUS è comodo. Nel 2026 si usa solo TLS 1.3, ECDHE con X25519 o P-256, cifrari AES-256-GCM e rigide politiche di renegoziazione. Più complesso da gestire, ma con MFA e ACL granulari disponibili out-of-the-box tramite plugin e script.

IPSec e ibridi

IPSec in IKEv2 è ottimo per tunnel intersito e integrazione con device di rete. Maturato e performante, richiede pazienza in configurazione e politiche di cifratura solide. Spesso nelle realtà si usano ibridi: WireGuard per dipendenti remoti, IPSec tra data center, OpenVPN per integrazioni specifiche client. Non serve discutere "cosa è meglio", ma scegliere in base a scenario e modello di minaccia.

Base minima del sistema: piattaforma, aggiornamenti, kernel, filesystem

Distribuzione e ciclo vitale

Si prevede stabilità per 5 anni? Si sceglie LTS. Nel 2026 parliamo di Ubuntu 24.04 LTS, Debian 12, Rocky Linux 9, AlmaLinux 9 o Alpine 3.20+ per installazioni leggere. Più base leggera significa meno pacchetti e quindi meno vulnerabilità. Blocchiamo subito i repository, abilitiamo unattended-upgrades o equivalente, ma kernel e servizi critici aggiorniamo con finestre controllate e rollback.

Kernel LTS e sicurezza

Restiamo su branche LTS del kernel 6.6 o 6.10 aggiornate costantemente. Verifichiamo retpoline e mitigazioni spettro attive, abilitiamo lockdown kernel, limitiamo interfacce non sicure: kptr_restrict=2, dmesg_restrict=1, regoliamo unprivileged_userns_clone secondo policy, disabilitiamo BPF per utenti non privilegiati o configuriamo bpf.strict_mode. Per WireGuard preferiamo modulo kernel invece di DKMS.

File system e mount

Partizioni separate per /, /var, /var/log, /var/log/audit e /tmp dove possibile. Montiamo /tmp e /var/tmp con opzioni noexec,nosuid,nodev. Per /home e /var usiamo nodev,nosuid. Su produzione utile la bandiera immutable su configurazioni rare da modificare. Log su disco o volume dedicato per evitare crash da attacchi DDoS con log. Se possibile, attiviamo integrità fs e controllo retroattivo con IMA o almeno AIDE.

Tempo e fonti di entropia

NTP non è un dettaglio. Tempo non sincronizzato invalida certificati, audit e rende le indagini un incubo. Usiamo chrony con più server, limitiamo fonti e permessi. Per crittografia controlliamo rngd o jitterentropy per evitare problemi di entropia su virtual machine all’avvio.

Principio del privilegio minimo: utenti, systemd, capabilities, MAC

Utenti e gruppi

Eseguiamo i daemon VPN con utente di sistema dedicato senza shell né login. Directory di configurazione e chiavi con permessi 750 o 700, file chiavi 600. Niente segreti leggibili a tutti. Amministratori con sudo basato su ruoli, niente NOPASSWD globale, e audit obbligatorio per escalation privilegi.

Hardening dei file unit systemd

Systemd offre molti flag di protezione. Usiamo DynamicUser dove possibile, ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, PrivateDevices=true, NoNewPrivileges=true, MemoryDenyWriteExecute=true, RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX, LockPersonality=true, ProtectClock=true, ProtectKernelTunables=true, IPAddressDeny=any con eccezioni puntuali, CapabilityBoundingSet= e AmbientCapabilities con liste precise. Qualche riga in più, e riduciamo drasticamente la superficie d’attacco.

Capabilities Linux e chroot

Se il daemon non necessita di CAP_NET_ADMIN dopo l’avvio, lo eliminiamo. WireGuard di solito richiede permessi amministrativi di rete solo all’inizializzazione dell’interfaccia, il resto si può delegare a un helper separato. Evitiamo l'esecuzione da root di default, separiamo init e runtime dove possibile. Chroot o bubblewrap per processi ausiliari riduce il rischio di fughe.

SELinux o AppArmor

Nel 2026 meglio vivere con profili AppArmor su Ubuntu o SELinux in modalità Enforcing su distro tipo RHEL. Usare policy pronte senza disabilitarle per "fix veloci". Un profilo che blocca accessi a percorsi o syscall non autorizzate spesso salva da RCE. Sì, occorre a volte aggiornare policy, ma è un investimento.

Crittografia e gestione delle chiavi: senza magie

Set di cifrari moderni

OpenVPN: solo TLS 1.3, cifrari TLS_AES_256_GCM_SHA384 o TLS_CHACHA20_POLY1305_SHA256, ECDHE con X25519, firme ECDSA P-256 o Ed25519, RSA almeno 3072, meglio 4096 per compatibilità. WireGuard usa ChaCha20-Poly1305, Curve25519, BLAKE2s, ottimo di default. IPSec IKEv2: AES-GCM, PRF-HMAC-SHA2, PFS su ECP256 o X25519. Niente SHA-1, 3DES, RC4, neanche in modalità legacy.

Prontezza post-quantum

Nel 2026 testiamo ibridi: X25519+Kyber per scambio chiavi, Ed25519+Dilithium per firme dove lo stack lo permette. In produzione ibrido solo dopo compatibilità testata. Per OpenVPN via patch e librerie esterne, per TLS in front-end già realtà. L’importante è seguire raccomandazioni di distro e provider crittografico senza fantasie.

PKI, emissione e revoca

Abbiamo una CA isolata offline, con durate chiare e policy di revoca. Emissione certificati client su richiesta, con audit, scadenza automatica e legame obbligatorio a utente e device. CRL e OCSP aggiornati regolarmente, non "quando capita". Per WireGuard gestione chiavi rigorosa: vietati config fatti in casa, coordinazione tramite controller o generator con logging.

Conservazione dei segreti e rotazione

Segreti non in git né wiki. Usare vault o KMS cloud, per file config sops con chiavi in KMS o age. Rotazione chiavi e certificati calendarizzata: ogni 90 o 180 giorni, o subito in caso di compromissione. Revoca accessi a dipendenti cessati lo stesso giorno. L’automazione salva, processi manuali falliscono sempre, soprattutto di venerdì sera.

Firewall e perimetro: nftables, eBPF e buon senso

Politica base "deny all tranne"

Nel 2026 nftables è lo standard. Politica di default drop, consentiamo solo porte e protocolli precisi: UDP 51820 per WireGuard, UDP o TCP 1194 per OpenVPN, IKEv2 500 e 4500 per IPSec, più SSH per admin con limitazioni IP. Loopback locale consentito, tutto il resto tramite regole esplicite. Tabelle dedicate per input, forward, output, ognuna con logica propria, non un unico "kit completo".

Rate limit e anti-DDoS

Applichiamo limiti per frequenza nuove connessioni e handshake. Per UDP limiti per IP e subnet, usando sets e maps dinamici. A livello kernel tcp_syncookies attivi, code backlog e buffer aumentate ma con moderazione. Conntrack attivo e configurato, altrimenti si parano limiti improvvisi.

Routing, NAT e isolamento

Per WireGuard spesso policy routing: traffico da wg0 su tabelle dedicate con regole chiare. NAT solo dove serve e per intervalli specifici. Reti guest e admin separate, niente mescolanze. OpenVPN con client-config-dir per consegnare solo rotte e DNS necessari. Split-tunnel client solo con consenso e policy definite.

IPv6, DNS e metriche

IPv6 non va solo "spento". Se attivo, configuriamo indirizzamenti, RA e firewall come per IPv4. Chiudiamo fughe DNS: forziamo risolutori aziendali via push o config peer, vietiamo richieste DNS esterne se non parte di design. Metriche e log raccolti separatamente, idealmente su interfaccia management per non impattare traffico di produzione.

Disattiviamo il superfluo: riduciamo la superficie d’attacco

Servizi e pacchetti

Controlliamo systemctl list-unit-files e ss -tulpen. Disabilitiamo tutto ciò che non serve a VPN e supporto base: stampanti, avahi, auto-discovery, daemon aggiornamenti GUI, rpcbind ecc. Puliamo pacchetti lasciando solo il necessario. Meno codice significa meno vulnerabilità. E no, il "per sicurezza" come scusa non regge.

Profilo sysctl

Profilo sysctl rigoroso blocca intere classi di attacco. IPv4: net.ipv4.conf.all.rp_filter=1, accept_redirects=0, send_redirects=0, accept_source_route=0, tcp_syncookies=1, icmp_echo_ignore_broadcasts=1. IPv6: net.ipv6.conf.all.accept_ra=0 su server senza RA, blocco source route. Disabilitiamo risposte a pacchetti sospetti, limitiamo routing solo a ciò che serve all’interfaccia VPN. Persistenza tramite config, non echo runtime.

Container o bare-metal

VPN in container è possibile ma richiede modello chiaro di permessi e capabilities. Rootless, cgroup v2, netns limitate funzionano, ma complessità e impatto performance crescono. Per punti di carico elevato o semplicità meglio VM o bare-metal per minimizzare livelli di rischio. Se container, configurare capability set e profili seccomp espliciti.

Cloud e metadata

In cloud blocchiamo accesso metadati da interfacce pubbliche, usiamo meccanismi tipo IMDSv2, security group deny-all con eccezioni, subnet private per admin e bastion separato. Chiavi d’accesso salvate in KMS, mai su disco server. Snapshot criptati e accesso gestito come per database di produzione.

Audit, logging e monitoraggio: vedere, sapere, reagire

Audit di sistema

Attiviamo auditd, tracciamo tentativi di escalation, modifiche config, accesso chiavi e file unit. Log journald spediti in remoto con rotazione e protezione da saturazione disco. Su software VPN logghiamo solo dati utili per indagini, senza eccessivi PII. I log sono strumenti, non discariche.

Monitoraggio e metriche

I grafici parlano più delle parole. Raccogliamo metriche connessioni, latenza, errori handshake, buffer pieni, CPU e IRQ. Exporter Prometheus per sistema e VPN, alert SLO: disponibilità endpoint, tempo di instaurazione tunnel, carico massimo. Più teste sintetiche: script che avvia test tunnel ogni N minuti per controllo rotte.

Controllo integrità e EDR

AIDE o monitor integrità su pacchetti e config avvisano presto. EDR leggero con regole per comportamenti anomali processi VPN, azioni admin, blocco binari sospetti non è un lusso. Importante non esagerare: allarmi devono essere azionabili, altrimenti si spengono tutti.

Procedure di risposta

Gli incidenti capitano. Serve piano breve: chi è on call, come isolare nodo, come spostare traffico su backup, quali log raccogliere e dove inviarli. Una checklist di una pagina risolve più problemi di venti slide perse in Confluence. Esercitazioni ogni trimestre.

Gestione e processi: accesso, aggiornamenti, backup

Accesso admin e MFA

SSH solo con chiavi, password disabilitata, restrizioni IP. MFA per accesso privilegiato via PAM e chiavi FIDO2 se possibile. Proxy di sessione, log comandi, regole sudo minime. In produzione operazioni pensate e tracciate. Niente account "condivisi", ogni azione personalizzata.

Aggiornamenti senza stress

Finestre regolari, canarini, backup configurazioni, rollback automatico. Prima di aggiornare snapshot VM o config, dopo controllo checklist: interfaccia su, traffico ok, DNS funzionante. Crypto library e kernel solo con test. Non siamo eroi, siamo ingegneri.

Ridondanza e fault tolerance

Due nodi in zone o data center diversi, IP Anycast o DNS geo-distribuito, sincronizzazione liste client e chiavi. Config in git cifratI, CI per sintassi, CD per deploy via API. Test regolari di failover: meglio scoprirlo prima del cliente.

Compliance e privacy

Se trattiamo dati personali, abbiamo policy di logging e retention. IP sono dati personali per molte normative. Durate, anonimizzazione, accesso limitato ai log sono parte di regolamento. Benchmark CIS per OS e VPN, processi ISO 27001, audit interni: forse noiosi ma fondamentali per evitare figuracce.

Checklist passo passo per hardening server VPN

Preparazione piattaforma

1. Scegli distribuzione LTS e fissa repo. 2. Aggiorna sistema, installa kernel LTS, abilita mitigazioni necessarie. 3. Parti disco separate, mount rigidi, volume dedicato log. 4. Configura chrony, più fonti, accessi limitati. 5. Installa AIDE e base integrità iniziale.

Utenti e servizi

1. Crea utente di sistema per VPN senza shell. 2. Imposta permessi su cartelle e file chiavi. 3. Harden file unit systemd: ProtectSystem, PrivateTmp, CapabilityBoundingSet ecc. 4. Disabilita e rimuovi servizi e pacchetti inutili. 5. Attiva SELinux Enforcing o profilo AppArmor.

Crittografia e chiavi

1. Usa solo cifrari moderni e TLS 1.3 se OpenVPN. 2. Organizza CA isolata, emissione e revoca. 3. Imposta rotazione obbligatoria di chiavi e certificati. 4. Sposta segreti in deposito protetto. 5. Prepara pilota PQC e verifica compatibilità.

Rete e firewall

1. Abilita nftables con politica deny-by-default. 2. Consenti solo porte e famiglie indirizzi necessarie. 3. Applica rate limit a handshake e connessioni. 4. Separa routing e NAT solo dove serve. 5. Blocca fughe DNS e configura IPv6 consapevolmente.

Audit, monitoraggio, risposta

1. Attiva auditd, configura regole su operazioni chiave. 2. Invia log a collector remoto, gestisci rotazione. 3. Raccogli metriche e alert SLO. 4. Documenta piano di risposta e addestra team. 5. Controlla regolarmente integrità e configurazione.

Gestione e DR

1. Introduci MFA e regole sudo rigorose. 2. Organizza finestre aggiornamento con canarini e rollback. 3. Distribuisci secondo nodo e verifica failover. 4. Conserva config in repo cifrati e versionati. 5. Testa ripristino da backup e documenta risultati.

Errori comuni e casi reali

Tutti di default

Azienda lancia OpenVPN con profilo TLS 1.2, SHA-1 e nessun CRL. Una fuga chiave lasciava malintenzionati in rete per settimane. Corretto dopo anomalie utente: upgrade a TLS 1.3, CRL attivato, rotazione automatica. Duro ma efficace.

Ignorare IPv6

IPv6 disattivato «per semplificare». I dispositivi client avevano comunque IPv6 globale e bypassavano DNS aziendale, causando problemi strani e poi seri. Correzione: VPN con IPv6 configurato, rotte e firewall aggiornati, fughe chiuse.

Nessun piano di failover

Un server, un disco, un punto accesso. DDoS venerdì, ingegneri svegli lunedì. Adesso due punti, canali backup, alert. Semplice ridondanza architetturale vale più di server super potente.

Segreti in repository

Sì, succede ancora. Chiavi WireGuard committate in git, poi sorpresa per accessi notturni strani. Soluzione: sops, KMS e regole di accesso politiche. Alert su “private_key” in PR non guasta.

Configurazioni pratiche: dettagli che risparmiano ore

Sysctl utili per VPN

Parametri mirati eliminano lag e anomalie. Aumento net.core.rmem_max e wmem_max, net.core.default_qdisc=fq, tcp_congestion_control=bbr2 o cubic testati, attenzione net.netfilter.nf_conntrack_max in base a RAM e carico. Cambiamenti solo dopo test, non "per sentito dire".

nftables: sets e maps

Usiamo sets per indirizzi admin autorizzati e maps per limiti dinamici. Regole più leggibili e performanti. Log limitati in nft con burst per non saturare disco. Debug con nft monitor trace, attenzione in produzione.

WireGuard: politica AllowedIPs

Errore più comune: dare 0.0.0.0/0 eccessivamente. Assegniamo solo le subnet necessarie al client. Tunnel site-to-site con reti esplicite, niente routing transit superfluo. Keepalive su reti instabili a 25 secondi, ma non è una panacea.

OpenVPN: profilo server

tls-version-min 1.3, cipher AES-256-GCM, ncp-ciphers AES-256-GCM, reneg-sec adeguato, verify-x509-name client, crl-verify, tls-crypt per protezione handshake da scanner. Plugin auth-pam per MFA, script limitati in client-connect se previsto. Non dimenticare —explicit-exit-notify su UDP.

Controllo qualità e miglioramento continuo

Benchmark e SLO

Senza metriche target si naviga al buio. Definiamo SLO: tempo di tunnel, banda con N client, latenza media verso reti chiave. Benchmark ad ogni cambiamento significativo. Confrontiamo grafici prima e dopo, non solo sensazioni.

CI/CD sicuro per configurazioni

I config VPN sono codice pure loro. Branch, review, controlli statici sintassi, ambienti test. Deploy via pipeline, mai manuale. Riduce errori umani e agevola rollback. GitOps abbassa stress e aumenta prevedibilità.

Feedback dagli utenti

Se lamentano "lento", non discutiamo ma misuriamo. Spesso è DNS, routing inefficienti o collo di bottiglia Wi-Fi client. Checklist diagnostica in 5 passi risparmia ore: ping rotte, risoluzione DNS, controllo MTU, traceroute, test banda.

Trend 2026

Profili ibridi PQC su TLS, passaggio massiccio a nftables, policy systemd più stringenti, crescita eBPF XDP per filtraggio, Zero Trust a livello device che autorizza accesso solo dopo posture check. Non dobbiamo tutto adottare, ma è utile capire la direzione.

FAQ: in breve sul essenziale

Conviene passare subito da OpenVPN a WireGuard?

Se PKI, MFA e processi attorno a OpenVPN sono maturi, non c’è fretta. WireGuard offre semplicità e velocità ma richiede rifare gestione accessi. La scelta giusta dipende da politiche e integrazioni attuali.

Si può tenere la VPN in container in sicurezza?

Sì, ma con prudenza. Serve limitare capabilities, seccomp, rootless, rete definita e capire impatto performance. Per carichi alti o semplicità spesso si preferisce VM o bare-metal.

Come fare MFA per WireGuard?

A livello protocollo non si può. Si fa tramite controllo emissione e ciclo vita chiavi, accesso proxy o agent esterni che verificano posture di device e utente prima di fornire configurazione.

Conviene disabilitare IPv6?

Meglio configurarlo correttamente. Spegnere IPv6 spesso porta a fughe e bypass inattesi. Se non serve, disabilitarlo sistematicamente su interfacce e applicazioni. Se serve, configurare firewall e routing con stessa cura di IPv4.

Ogni quanto ruotare chiavi e certificati?

Almeno ogni 90-180 giorni per utenti, root secondo politica e rischio. Più importante è avere automazione e procedure testate per revoca dopo incidenti. Senza questo le scadenze sono solo numeri.

Quali log conservare e per quanto?

Solo quelli necessari a indagini: sessione avviate, metadati connessione, errori. Minimo dati personali. Durata stabilita da policy e legge, tipicamente 30-180 giorni, accesso rigorosamente limitato.

Cosa conta di più: firewall o SELinux?

Non è scelta. Firewall controlla la rete, SELinux o AppArmor il processo. Insieme creano difesa a più livelli. Eliminandone uno si apre un varco inatteso.