# Firewall per server web: aprire solo le porte necessarie

> Firewall per server web: verificare le porte aperte, abilitare solo 80 e 443, limitare SSH, circoscrivere le connessioni in uscita. Con nftables e ufw.

Fonte: https://phpsos.de/it/blog/firewall-fuer-webserver/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** un firewall per server web consente in ingresso solo TCP 80 e 443, con HTTP/3 in più UDP 443, e SSH solo da reti note. Tutto il resto viene scartato: database, cache, PHP-FPM e interfacce di amministrazione non vanno su Internet. Verifichi prima con `ss -tulpn` che cosa è in ascolto, costruisca poi un set di regole con impostazione predefinita «scartare» e testi il risultato dall'esterno. Limitare le connessioni in uscita restringe inoltre le conseguenze di un'intrusione.

## Le porte dimenticate accanto alla porta di casa

Con PHP2Shell l'attenzione si è rivolta al server web stesso, alle porte 80 e 443. Devono essere aperte, altrimenti non c'è sito. Negli inventari dopo vulnerabilità simili emerge però spesso altro: accanto alla porta di casa ci sono altre porte aperte. Un database in ascolto su tutte le interfacce di rete, un pool PHP-FPM sulla porta 9000, un servizio di cache senza password, un'interfaccia di amministrazione rimasta dalla fase di configurazione.

Ognuna di queste porte è una superficie d'attacco a sé, con vulnerabilità proprie. Un firewall che consente solo il necessario le chiude con poche regole. È una delle misure più efficaci nel mettere in sicurezza un proprio server, come descrive anche la pagina [Mettere in sicurezza da soli root server e vServer](https://phpsos.de/it/server/root-server-vserver/).

## Che cosa deve essere aperto e che cosa no?

Il principio è una lista di consenso: tutto è chiuso e solo i servizi abilitati consapevolmente sono raggiungibili. Il prospetto seguente aiuta nell'inquadramento.

| Servizio | Porta tipica | Raggiungibile dall'esterno? |
|---|---|---|
| HTTP e HTTPS | TCP 80, TCP 443 | sì |
| HTTP/3 (QUIC) | UDP 443 | solo se usato |
| SSH | TCP 22 | solo da reti note o tramite VPN |
| Pannello di hosting | secondo il prodotto | solo da reti note |
| MySQL/MariaDB, PostgreSQL | TCP 3306, TCP 5432 | no |
| Redis, Memcached | TCP 6379, TCP 11211 | no |
| PHP-FPM | TCP 9000 o socket Unix | no, meglio solo socket |
| Server di posta | TCP 25, 465, 587, 993 | solo se il server riceve o fornisce posta |

Un servizio che non deve andare verso l'esterno dovrebbe inoltre mettersi in ascolto solo su `127.0.0.1` o su un socket Unix. Allora resta irraggiungibile anche in caso di guasto del firewall. Per gli accessi di amministrazione sono adatte abilitazioni per IP o una VPN; i dettagli sono nell'articolo [Proteggere le aree di amministrazione con IP, VPN o protezione aggiuntiva](https://phpsos.de/it/blog/admin-bereiche-abschirmen/).

## Passo 1: stabilire che cosa è in ascolto

Prima di scrivere regole, si faccia un quadro generale. I comandi seguenti leggono soltanto:

```bash
# Tutte le porte TCP e UDP in ascolto con il processo
sudo ss -tulpn
# Set di regole attuale di nftables
sudo nft list ruleset
# Stato di ufw, se usato
sudo ufw status verbose
```

Nell'output di `ss` faccia attenzione all'indirizzo davanti alla porta. `0.0.0.0` o `[::]` significa: il servizio è in ascolto su tutte le interfacce. `127.0.0.1` significa: solo in locale. Annoti per ogni servizio se debba essere raggiungibile dall'esterno. Questo elenco è al tempo stesso un pezzo del Suo inventario dei server.

## Firewall per server web con nftables

nftables è il filtro dei pacchetti attuale su Linux. Il set di regole seguente si ispira all'esempio del wiki ufficiale di nftables e aggiunge un'abilitazione per SSH solo da una rete di amministrazione. Gli indirizzi sono esempi di documentazione e vanno sostituiti.

```nft
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    set verwaltung_v4 {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.0/28 }
    }

    chain input {
        type filter hook input priority 0; policy drop;

        ct state vmap { established : accept, related : accept, invalid : drop }
        iifname lo accept

        # IPv6 richiede il neighbor discovery
        icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
        icmp type echo-request limit rate 5/second accept
        icmpv6 type echo-request limit rate 5/second accept

        # Sito web
        tcp dport { 80, 443 } accept
        # solo con HTTP/3:
        # udp dport 443 accept

        # SSH solo dalla rete di amministrazione
        ip saddr @verwaltung_v4 tcp dport 22 accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}
```

Verifichi il set di regole prima di caricarlo con `nft -c -f /etc/nftables.conf`. La prima riga `flush ruleset` cancella tutte le regole esistenti, anche quelle inserite da Docker o Fail2ban. Sui server con Docker o altri servizi che impostano regole proprie, adatti quindi il set di regole invece di sostituirlo in blocco. Come Fail2ban collabori con il firewall è spiegato in [Configurare Fail2ban per i server web](https://phpsos.de/it/blog/fail2ban-fuer-webserver/).

Chi preferisce la semplicità usa `ufw` su Ubuntu. Importante è l'ordine: prima l'abilitazione di SSH, poi l'attivazione.

```bash
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow proto tcp from 203.0.113.0/28 to any port 22
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
```

> **Importante:**
> Modifichi le regole del firewall sui server remoti solo con una seconda via di accesso, ad esempio la console del Suo provider. Una regola SSH sbagliata altrimenti Le chiude fuori da sé.

## Connessioni in uscita: la metà sottovalutata

La maggior parte dei firewall consente tutto in uscita. Per un server web è generoso. Dopo un'intrusione gli aggressori usano le connessioni in uscita per scaricare strumenti, sottrarre dati o ricevere comandi. I processi del server web o di PHP che stabiliscono connessioni inattese sono quindi considerati un segnale d'allarme.

Una limitazione delle connessioni in uscita è più laboriosa, perché ogni connessione legittima deve essere nota: sorgenti dei pacchetti per gli aggiornamenti, servizi di pagamento, interfacce, invio di posta, server orari. Una via pragmatica è registrare prima le connessioni in uscita, formare poi una lista di consenso e solo dopo bloccare. Come verificare le connessioni esistenti lo descrive [Verificare le connessioni in uscita di un server](https://phpsos.de/it/blog/ausgehende-verbindungen-pruefen/); quali altre tracce indichino un'intrusione è spiegato in [Sono già stato compromesso?](https://phpsos.de/it/php2shell/bin-ich-gehackt-anzeichen/).

Per concludere, testi dall'esterno, da un altro computer e solo contro i Suoi sistemi, quali porte siano effettivamente raggiungibili. Solo questo test mostra se Docker, firewall del provider e regole del server insieme danno il quadro desiderato.

## Conclusione: poche regole, grande effetto

Un firewall per server web non deve essere complicato. Porte web aperte, amministrazione solo da reti note, tutto il resto scartato: con queste regole di base database, cache e servizi dimenticati spariscono da Internet. È una delle misure con il miglior rapporto tra sforzo e beneficio.

Contro le vulnerabilità nel server web o in PHP stesso il firewall non aiuta, perché proprio queste porte devono restare aperte. La sua forza sta nel mantenere piccola la restante superficie d'attacco e nel contenere, con una limitazione delle connessioni in uscita, le conseguenze di un'intrusione.

Decisiva è la manutenzione. Ogni nuovo servizio, ogni container e ogni modifica presso il provider può spostare il quadro. Ripeta quindi la verifica dall'esterno dopo ogni modifica più grande e a intervalli fissi, ad esempio una volta a trimestre.

## Come aiuta PHP SOS in concreto?

- **Rilevare lo stato:** rileviamo tutti i servizi in ascolto e verifichiamo dall'esterno che cosa sia effettivamente raggiungibile.
- **Costruire il set di regole:** creiamo una lista di consenso per le connessioni in ingresso e, dove ha senso, in uscita, armonizzata con Docker, Fail2ban e firewall del provider.
- **Passare in sicurezza:** attuiamo le modifiche con una seconda via di accesso e un piano di ripiego.
- **Documentare:** annotiamo porte, abilitazioni e motivi nell'ambito dell'[hardening del server](https://phpsos.de/it/leistungen/server-haertung/).


## Domande frequenti

**Di quali porte ha bisogno un server web?**  
Per i visitatori di norma solo TCP 80 e 443, con HTTP/3 in più UDP 443. SSH e interfacce di amministrazione dovrebbero essere raggiungibili solo da reti note o tramite VPN. Le porte di database, cache e PHP-FPM non vanno su Internet.

**Un firewall protegge da PHP2Shell?**  
No. PHP2Shell viene sfruttato tramite il server web, cioè proprio attraverso le porte che devono essere aperte. Il firewall riduce però il resto della superficie d'attacco, e una limitazione delle connessioni in uscita può contenere le conseguenze di un'intrusione.

**Perché ufw mostra come chiuse porte che sono comunque raggiungibili?**  
Un caso noto sono i container Docker: Docker inserisce le porte pubblicate direttamente nelle regole del filtro dei pacchetti, aggirando ufw. Verifichi quindi sempre le porte aperte anche dall'esterno.

**Il firewall del mio provider di hosting basta?**  
Un firewall a monte del provider è un buon secondo livello. Non sostituisce però il firewall sul server, perché non agisce in caso di errore nella configurazione del provider o per le connessioni interne. La cosa migliore è usare entrambi con le stesse regole di base.

## Fonti

- [Wiki di nftables: set di regole semplice per un server](https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server)
- [Ubuntu Server: firewall (ufw)](https://ubuntu.com/server/docs/how-to/security/firewalls/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks)