Il miglior firewall gratuito per un VPS Linux non è un singolo strumento. È un firewall a livello di host (lo strato di cui ha bisogno ogni server) e, se gestisci un'app web, un web application firewall al di sopra. Questa guida copre entrambi, indica le opzioni di firewall gratuite o open source più solide per ciascuno strato e specifica quanto ognuna ti costa in termini di RAM e impegno di configurazione. È pensata per chi gestisce un VPS Linux. Non è una carrellata su Windows.
La versione breve
- "Miglior firewall gratuito" indica quattro prodotti diversi: firewall host per Linux, distro firewall di rete, web application firewall (WAF) e strumenti consumer per Windows. Solo il primo e il terzo hanno senso su un VPS.
- A livello di host, usa lo strumento più semplice adatto alla tua distro: UFW su Ubuntu, firewalld sulla famiglia RHEL e UFW o nftables diretto su Debian a seconda di quanto controllo ti serve. I frontend moderni si appoggiano in genere a nftables, ma nftables stesso è il framework predefinito e consigliato su Debian.
- Un WAF è uno strato separato e complementare per le app web. Non sostituisce il firewall dell'host.
- SafeLine è il WAF gratuito più leggero (1 GB di RAM). BunkerWeb è il più completo ma richiede 8 GB. Haltdos Community è una terza opzione gratuita con una UI web.
Cosa tralascia questa guida
Alcune categorie di firewall che compaiono in altre liste di "miglior firewall gratuito" non si applicano qui, e nominarle una volta ti evita di rincorrere lo strumento sbagliato.
- Firewall endpoint per Windows e consumer (ZoneAlarm, Comodo, TinyWall). Sistema operativo sbagliato, macchina sbagliata.
- Firewall commerciali ed enterprise a pagamento (Cisco ASA, Palo Alto, Fortinet). Fuori dall'ambito "gratuito".
- WAF cloud in SaaS (Cloudflare, Sucuri). Validi, ma basati su DNS/proxy e fuori dall'ambito di questo VPS self-hosted. Cloudflare offre un set di regole WAF di base gratuito, mentre una copertura più completa di regole gestite e del set OWASP dipende dal piano.
- Eseguire pfSense o OPNsense come gateway su un VPS condiviso. Architetturalmente inadatto senza il passthrough della NIC. Spiegato nella sezione sulle distro di rete.
Cosa significa davvero "miglior firewall gratuito" (quattro categorie)
Il motivo per cui questo termine di ricerca ti fa girare in tondo è che copre quattro prodotti che risolvono quattro problemi diversi su quattro macchine diverse. Prima collocati in una categoria, poi scegli uno strumento.
- Firewall host/VPS Linux: software che gira sulla stessa macchina dei tuoi servizi e controlla quali porte sono raggiungibili. UFW, firewalld e nftables. Questo è lo strato di cui ha bisogno ogni VPS.
- Distro firewall di rete: sistemi operativi completi costruiti attorno a un motore firewall, installati su una macchina dedicata o una VM per proteggere un'intera rete. OPNsense, pfSense, IPFire. Sono pensati per un homelab o una LAN aziendale, non per il VPS che stai cercando di proteggere.
- Web application firewall (WAF): reverse proxy che ispezionano il traffico HTTP alla ricerca di attacchi a livello web come SQL injection, XSS e il resto della OWASP Top 10. SafeLine, BunkerWeb, Haltdos, ModSecurity. Sono pensati per un'app web o un'API in esecuzione sul tuo VPS.
- Firewall endpoint consumer/Windows: software desktop che controlla l'accesso a internet per singola applicazione su Windows. Citato qui solo per escluderlo.
Per un VPS, le categorie 1 e 3 sono quelle che esegui. La categoria 2 gira su una macchina diversa. La categoria 4 gira su un sistema operativo diverso. L'opzione di firewall gratuita o open source giusta per la tua situazione è lo strumento della categoria 1, ed eventualmente della categoria 3, che si adatta alla tua distro e al tuo traffico.
Verdetto rapido: Per la maggior parte di chi gestisce un VPS, usa UFW per l'host e aggiungi SafeLine se gestisci un'app web e vuoi un WAF senza dover mettere in piedi un server da 8 GB.
Punto chiave della sezione: Su un VPS scegli tra firewall host e WAF. Le distro di rete e gli strumenti consumer sono prodotti diversi per macchine diverse.
Firewall host: UFW vs nftables vs firewalld
Il firewall dell'host è l'unico strato di cui hai sempre bisogno. Controlla quali porte del tuo server accettano connessioni e, su un VPS appena creato, è ciò che distingue una macchina blindata da una aperta. Su Ubuntu, quel firewall di solito è UFW. Sulle distro della famiglia RHEL è firewalld. Su Debian, UFW è un semplice frontend per il firewall host, ma il framework di firewalling predefinito e consigliato di Debian è nftables.
Le tre opzioni si suddividono nettamente in base alla distro e a quanto controllo ti serve:
| Strumento | Predefinito della distro | Interfaccia | Ideale per | Complessità |
|---|---|---|---|---|
| UFW | Ubuntu, opzione semplice comune su Debian | CLI | Un singolo VPS, il caso comune | Basso |
| firewalld | RHEL, CentOS, AlmaLinux, Rocky | CLI (basata su zone) + systemd | Server della famiglia RHEL, regole basate su zone | Medio |
| nftables | Il motore alla base di entrambi | File di configurazione / CLI | Migliaia di regole, controllo granulare, throughput elevato | Alto |
UFW è lo strumento di configurazione del firewall predefinito di Ubuntu e una scelta semplice e comune su Debian, ma il framework di firewalling predefinito di Debian è nftables. Per un singolo VPS, UFW resta il punto di partenza più facile quando ti serve solo un piccolo insieme di regole di allow/deny. La CLI è la più semplice delle tre, le regole persistono automaticamente ai riavvii e pochi comandi coprono tutto ciò di cui ha bisogno la maggior parte di chi gestisce un VPS. Il suo limite sono le regole avanzate: la logica complessa basata su set o il matching granulare sono scomodi in UFW.
firewalld è predefinito su RHEL, CentOS, AlmaLinux e Rocky. È basato su zone, si integra con systemd ed è più capace di UFW nel segmentare il traffico per interfaccia o livello di fiducia. Quella potenza costa tempo di configurazione. Se sei su un VPS della famiglia RHEL, firewalld è già presente ed è la via di minor resistenza.
nftables è il motore a livello di kernel che sta alla base di entrambi. Lo usi direttamente quando ti serve davvero la sua scala di regole o la sua velocità: migliaia di regole, filtraggio ad alte prestazioni o un controllo che un frontend non espone. Secondo il confronto UFW vs nftables di Better Stack, nftables è da 10 a 100 volte più veloce di iptables quando sono presenti migliaia di regole. Quel dato riguarda nftables rispetto a iptables, non UFW rispetto a iptables. Per un VPS tipico con una manciata di regole di allow non percepirai quella differenza, e la curva di apprendimento più ripida e la mancanza di una UI comoda non valgono il prezzo. C'è anche un aspetto di sicurezza da tenere presente: nftables ha avuto bug reali nel kernel, tra cui CVE-2025-40206, quindi mantieni il kernel aggiornato con le patch. È un motivo per restare aggiornato, non per evitare il backend che stai già usando.
Se vuoi il tutorial pratico per le regole di UFW, la guida ai comandi UFW di Cloudzy illustra i comandi passo dopo passo. Questa sezione riguarda la scelta dello strumento, non la scrittura delle regole.
Consiglio pratico: "iptables è deprecato" non significa che tu debba fare qualcosa. nftables ha sostituito iptables come backend del kernel, e UFW e firewalld si appoggiano già a nftables sulle distro moderne. Le tue regole UFW esistenti non vanno riscritte; il comando del frontend è lo stesso, è cambiato solo il motore sottostante. Se arrivi da iptables puro e vuoi capire la transizione, il riferimento alle regole iptables di Cloudzy è ancora valido, poiché le regole che hai scritto si mappano sul nuovo backend.
Punto chiave della sezione: Usa il percorso normale della tua distro: UFW su Ubuntu, firewalld sulla famiglia RHEL e UFW o nftables diretto su Debian a seconda di quanto controllo ti serve. Ricorri direttamente a nftables solo quando ti serve davvero la sua scala di regole o la sua velocità.
Distro firewall di rete: dove si collocano OPNsense e pfSense (e perché non sul tuo VPS)
OPNsense, pfSense e IPFire sono sistemi operativi completi per una macchina dedicata o una VM che protegge un'intera rete. Non sono qualcosa che esegui sul VPS che stai cercando di proteggere. Vale la pena conoscerli perché i risultati di ricerca te li metteranno davanti, quindi ecco dove si collocano e dove no.
Quando ne vorresti davvero uno: un homelab o una LAN di un piccolo ufficio, su hardware dedicato o su una VM con passthrough della NIC, posizionato tra la tua rete e internet. Che tu stia proteggendo un rack di macchine d'ufficio o un lab personale che esponi a internet, questa è la categoria che fa il lavoro.
Perché è lo strumento sbagliato su un VPS condiviso: queste distro si aspettano di controllare il traffico tra più interfacce di rete. Su un VPS condiviso ciò richiede il passthrough della NIC, che la maggior parte dei provider non espone. Senza di esso stai eseguendo un OS da gateway di rete su una macchina che non ha alcuna rete da presidiare. Se hai un singolo VPS, tutta questa categoria è lo strato sbagliato, e UFW più un WAF è quello giusto.
Le tre opzioni gratuite al 2026, in breve:
- OPNsense (con licenza BSD, attuale serie stabile CE: 26.1, con 26.1.11 rilasciata il 1° luglio 2026). Completamente open source, aggiornato di frequente e non suddiviso nello stesso modello CE/Plus di pfSense. Questo lo rende la scelta gratuita più lineare come network appliance per molti utenti che vogliono una distro firewall completamente open source senza la confusione dei livelli di funzionalità.
- pfSense Community Edition (attuale release CE: 2.8.1, rilasciata a settembre 2025). Ancora gratuito e open source, con una documentazione e una libreria della community più ampie rispetto a OPNsense. Il punto critico è la divisione CE/Plus: pfSense CE resta il prodotto community gratuito, mentre pfSense Plus è il percorso commerciale separato per gli appliance Netgate, i deployment cloud e l'hardware di terze parti. Per le condizioni attuali di Plus, consulta la pagina pfSense Plus di Netgate anziché fidarti di un numero preso da un post di confronto.
- IPFire (ultima 2.29 Core Update 202, secondo il blog dei rilasci di IPFire). Un ingombro più leggero rispetto agli altri due, con una community più piccola. Una scelta ragionevole quando vuoi un appliance più snello e non ti serve l'ampiezza di plugin di OPNsense.
Questi riepiloghi si basano sulla documentazione e sulle note di rilascio attuali. Prova qualsiasi distro firewall di rete in una VM prima di affidarti a essa per una rete reale.
Punto chiave della sezione: Se hai una rete da proteggere e una macchina di riserva, OPNsense è la scelta gratuita nel 2026. Se hai un singolo VPS, tutta questa categoria è lo strato sbagliato.
Web application firewall: SafeLine vs BunkerWeb vs Haltdos
Un firewall host controlla quali porte sono aperte. Un WAF fa qualcosa di diverso: ispeziona il traffico HTTP alla ricerca di attacchi a livello web come SQL injection, XSS e il resto della OWASP Top 10, che un firewall basato sulle porte non può vedere. Se gestisci un'app web o un'API sul tuo VPS, un WAF è un secondo strato complementare. Non sostituisce il firewall host; i due si collocano in punti diversi dello stack.
Per i deployment su VPS, parti dall'ingombro di risorse. Il WAF che rientra nel tuo budget di RAM è di solito quello che riesci davvero a tenere in esecuzione.
| WAF | RAM minima | Licenza | Distribuzione | Interfaccia di gestione |
|---|---|---|---|---|
| SafeLine | 1 GB | Licenza GPL-3.0 | Docker | Interfaccia Web |
| BunkerWeb | 8 GB | AGPLv3 | Docker (reverse proxy NGINX) | Interfaccia Web |
| Haltdos Community | 2 GB | Edizione community gratuita | VM, Docker o hardware | Interfaccia Web |
SafeLine è il punto d'ingresso più leggero. Il suo repository GitHub lo identifica come un WAF/reverse proxy self-hosted con licenza GPL-3.0. Una guida all'installazione di terze parti indica come requisiti minimi 1 core CPU, 1 GB di RAM e 5 GB di disco, con Docker 20.10.14 o più recente e Docker Compose 2.0.0 o più recente. SafeLine usa l'analisi semantica anziché affidarsi solo a un tradizionale elenco di regole, ma i tassi di rilevamento pubblicati vanno considerati come affermazioni fornite dal progetto/vendor e non come risultati di benchmark indipendenti. Sulle sole risorse, SafeLine resta la scelta per i VPS piccoli.
BunkerWeb è il più completo e il più pesante. È un WAF reverse proxy basato su NGINX con licenza AGPLv3, costruito su ModSecurity con l'OWASP Core Rule Set. Il costo è la RAM. La documentazione ufficiale di BunkerWeb indica come specifica minima consigliata 2 vCPU e 8 GB di RAM, e 4 vCPU con 16 GB per la produzione con molti servizi.
Haltdos Community è la terza opzione gratuita. La sua pagina dell'edizione community elenca la copertura della OWASP Top 10, la protezione da DDoS e bot, il rate limiting, regole integrate e una GUI di gestione via web. La sua documentazione indica come requisiti minimi 2 GB di RAM, 60 GB di disco e almeno 2 vCPU, con supporto al deployment su VM, Docker o hardware.
SafeLine, BunkerWeb, e Haltdos sono tutti disponibili come deployment con un clic nel marketplace di Cloudzy, e funzionano anche su qualsiasi VPS in modo manuale. Che tu stia proteggendo un'API rivolta ai clienti o un servizio personale che esponi a internet, lo strato è lo stesso; la scelta dipende soprattutto da quanta RAM sei disposto a dedicargli.
Punto chiave della sezione: Un WAF è uno strato separato dal firewall dell'host. SafeLine è l'opzione gratuita più leggera; BunkerWeb è il più completo ma richiede un server molto più grande.
Se hai deciso che un WAF ha senso sul tuo server, la fase di deployment è dove il marketplace può farti risparmiare tempo. SafeLine e BunkerWeb girano entrambi in Docker, il che di solito significa un file Compose, la configurazione del reverse proxy e il debug al primo avvio. Le opzioni del marketplace di Cloudzy per SafeLine, BunkerWeb e Haltdos possono saltare la fase di installazione iniziale, ma devi comunque configurare il routing verso l'upstream, il DNS, il TLS, la gestione dei falsi positivi e le regole del firewall host. Lo strato del firewall host è di per sé leggero e di solito disponibile dai pacchetti della distro; assicurati che sia installato, configurato e abilitato prima di esporre i servizi. Dimensiona il piano in base al WAF: 1 GB va bene per SafeLine, ma il minimo di 8 GB di BunkerWeb richiede un'istanza più grande. Puoi installare un WAF su un VPS Linux Cloudzy ed eseguire il firewall host sulla stessa macchina.
Un avvertimento su Docker: se la tua app o il tuo WAF girano in Docker, non dare per scontato che UFW da solo controlli ogni porta di container pubblicata. Docker crea proprie regole firewall per impostazione predefinita, quindi vincola i container di backend a localhost o a reti Docker private dove possibile, ed esponi solo le porte rivolte al WAF che intendi davvero pubblicare.
Ti servono sia un firewall host sia un WAF?
Sì, se gestisci un'app web pubblica, proteggono strati diversi. Il firewall host (UFW o firewalld) controlla quali porte sono aperte ed è la base per ogni VPS. Un WAF ispeziona il traffico HTTP che attraversa quelle porte aperte alla ricerca di attacchi a livello applicativo. Il WAF non sostituisce il firewall host; si colloca dietro di esso.
Il firewall host non è negoziabile. Ne ha bisogno ogni VPS, con app web o meno, perché è ciò che impedisce al resto di internet di raggiungere servizi che non intendevi mai esporre. Il WAF è condizionale. Aggiungilo quando servi traffico HTTP o HTTPS che potrebbe essere attaccato a livello applicativo: un'API pubblica, un CMS, qualsiasi cosa che accetti input dell'utente via web. Un sito statico o un servizio solo interno dietro una VPN potrebbe non aver bisogno affatto di un WAF; in quel caso il solo firewall host è la risposta giusta, e aggiungere un WAF è un sovraccarico di cui non hai bisogno. Adatta gli strati a ciò che esegui davvero, non a una checklist.
Punto chiave della sezione: Il firewall host è la base per ogni VPS. Aggiungi un WAF quando esponi un'app web a internet.
Domande frequenti
iptables è deprecato su Linux?
In pratica sì. nftables ha sostituito iptables come backend di packet filtering del kernel sul Linux moderno. Ma è un cambiamento di backend, non una chiamata all'azione. UFW e firewalld si appoggiano già a nftables sulle distro attuali, e le tue regole UFW esistenti non vanno riscritte. I comandi del frontend sono invariati; è cambiato solo il motore sottostante.
pfSense è ancora gratuito nel 2026?
Sì. pfSense Community Edition, attualmente 2.8.1, è gratuito e open source. Il punto critico è la divisione CE/Plus: pfSense CE resta il prodotto community gratuito, mentre pfSense Plus è il percorso commerciale separato per gli appliance Netgate, i deployment cloud e l'hardware di terze parti. Per le condizioni attuali di Plus e l'eventuale costo dell'abbonamento, consulta la pagina pfSense Plus di Netgate anziché affidarti a una cifra di un confronto di terze parti.
Posso eseguire pfSense o OPNsense su un VPS?
Tecnicamente possibile, ma architetturalmente inadatto su un VPS condiviso. Sono sistemi operativi da gateway di rete che si aspettano di controllare il traffico tra più interfacce di rete, il che richiede il passthrough della NIC che la maggior parte dei provider VPS non espone. Su un singolo VPS, ciò che vuoi davvero è un firewall host (UFW o firewalld) e, per le app web, un WAF.
Mi serve un WAF se ho già un firewall sul mio server Linux?
Proteggono strati diversi, quindi dipende da cosa esegui. Un firewall host controlla quali porte sono aperte; un WAF ispeziona il traffico HTTP che le attraversa alla ricerca di attacchi a livello web come SQL injection e XSS. Se servi un'app web o un'API pubblica, aggiungi un WAF al di sopra del firewall host. Se esegui solo un sito statico o un servizio interno, il solo firewall host è sufficiente.
Qual è il miglior WAF gratuito per un piccolo VPS Linux?
SafeLine è l'opzione gratuita più leggera, con un minimo di 1 GB di RAM in esecuzione in Docker, adatto a un piccolo VPS. BunkerWeb è più completo ma richiede 8 GB di RAM, quindi non è un deployment da server piccolo. Haltdos Community è una terza opzione gratuita con una UI web; controlla la sua documentazione per i requisiti di risorse attuali prima di dimensionare il server.