Rocky Linux: gestire firewalld, zone, servizi e porte

Rocky Linux

Pubblicato 2026-11-03 Ultima modifica 2026-11-03

Su Rocky Linux, firewalld gestisce il firewall tramite zone, servizi, porte e regole per indirizzo sorgente; il client da terminale è firewall-cmd. Su un server remoto, prova prima la modifica nella configurazione runtime, cioè attiva in memoria, mantenendo aperta la sessione SSH; verifica nuove connessioni e salva soltanto la configurazione già controllata.

Gli esempi richiedono un sistema Rocky Linux con firewalld disponibile, i privilegi amministrativi indicati da sudo e, per le operazioni sui profili, NetworkManager. Prima di modificare un server remoto verifica una console alternativa realmente utilizzabile e annota configurazione iniziale, porta SSH e zona interessata. public è una zona di esempio: sostituiscila con quella che gestisce il traffico del tuo server.

Controllare firewalld e le zone attive

sudo firewall-cmd --state
sudo systemctl status firewalld
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone

Una zona raggruppa regole associate a un livello di fiducia e viene collegata a interfacce o sorgenti; NetworkManager può assegnarla tramite il profilo di connessione. Controlla le zone attive prima di modificare le regole: omettendo --zone agisci normalmente sulla zona predefinita, che potrebbe non essere quella del traffico da controllare. --state indica se il demone è in esecuzione, non se la configurazione consente già tutti i collegamenti necessari.

Se un'interfaccia non appare dove ti aspetti, ispeziona la connessione attiva di NetworkManager prima di aggiungere regole. Una regola corretta nella zona sbagliata non permetterà il traffico previsto.

Avviare firewalld e abilitarlo al boot

enable --now avvia subito il servizio e lo abilita per gli avvii successivi. Se firewalld era fermo, la sua attivazione può cambiare immediatamente l’accesso: controlla prima le regole permanenti previste e assicurati di poter intervenire dalla console.

sudo systemctl enable --now firewalld

Verifica sia l'impostazione all'avvio sia lo stato attuale del servizio:

systemctl is-enabled firewalld
systemctl is-active firewalld

Per rendere raggiungibile un’applicazione autorizza soltanto servizio, porta, protocollo e sorgente necessari. Fermare l’intero firewall può esporre altri servizi in ascolto. Nel cloud, gruppi di sicurezza, liste di controllo degli accessi di rete (ACL) e firewall del provider continuano ad applicarsi indipendentemente da firewalld.

Distinguere configurazione runtime e permanente

Configurazione	Quando ha effetto	Comportamento
Runtime	Subito, nel firewall in esecuzione	Le modifiche di zona non salvate si perdono con reload, riavvio del servizio o del sistema.
Permanente	Salvata con `--permanent`, caricata al reload	Resta memorizzata dopo il riavvio; molte modifiche non entrano subito nel runtime.

Aggiungi prima HTTP nel runtime della zona corretta e verifica che il servizio risulti configurato. Il comando --query-service restituisce uno stato 0 se il servizio è aggiunto e 1 altrimenti: non è una prova di connessione al server web.

sudo firewall-cmd --zone=public --add-service=http
sudo firewall-cmd --zone=public --query-service=http

Ora prova l’applicazione da un client che deve accedervi e apri una nuova sessione SSH, mantenendo quella esistente. Solo dopo l’esito corretto e la revisione di tutte le differenze esegui sudo firewall-cmd --runtime-to-permanent. Questo comando copia l’intera configurazione runtime attiva e sovrascrive quella permanente: non salva soltanto la regola HTTP appena aggiunta e può sostituire modifiche permanenti non ancora caricate. Non usarlo mentre altri amministratori stanno modificando regole diverse.

Se scegli invece di modificare soltanto la configurazione permanente con --permanent, controllala prima di attivarla; sudo firewall-cmd --check-config ne verifica validità e semantica, senza provare il traffico di rete. Quando la configurazione è pronta, puoi caricarla nel runtime:

sudo firewall-cmd --reload

--reload carica la configurazione permanente nel runtime e conserva le informazioni di stato delle connessioni; le normali modifiche di zona rimaste solo nel runtime vengono perse. Non confonderlo con --complete-reload, che può interrompere le connessioni. La conservazione della sessione corrente non prova che una nuova sessione sarà ammessa: controllala sempre dopo un cambio di regole.

Consentire e rimuovere servizi

Consultare le definizioni disponibili

firewall-cmd --get-services
firewall-cmd --info-service=http

Preferisci un servizio predefinito quando descrive esattamente l’applicazione. Una definizione può includere più porte, protocolli o helper: controlla --info-service invece di dedurre tutto dal nome. Il servizio standard ssh si riferisce alla sua definizione configurata; un server SSH su una porta diversa richiede regole coerenti con quella porta.

Aggiungere un servizio nel runtime

sudo firewall-cmd --zone=public --add-service=http
sudo firewall-cmd --zone=public --add-service=https

Una regola HTTP o HTTPS non avvia il server web. Controlla indirizzo e porta di ascolto e poi prova da un altro host. ss -lntup mostra socket TCP/UDP in ascolto; alcuni dettagli dei processi altrui possono richiedere privilegi amministrativi:

ss -lntup

Rimuovere un servizio consentito

sudo firewall-cmd --zone=public --remove-service=http

Rimuovi soltanto il servizio che intendi revocare e controlla l’effetto con nuove connessioni. Per SSH occorre prima predisporre una regola alternativa e la console di recupero, come nella procedura per sorgente descritta sotto; tenere aperta la vecchia sessione è utile ma non sufficiente.

Gestire porte personalizzate

Consentire TCP o UDP

sudo firewall-cmd --zone=public --add-port=8443/tcp
sudo firewall-cmd --zone=public --add-port=5000/udp

TCP e UDP richiedono regole separate. Controllare la documentazione dell'applicazione e aprire solo il protocollo e la porta effettivamente utilizzati.

Consentire un intervallo di porte

sudo firewall-cmd --zone=public --add-port=6000-6010/tcp

Prima di aprire un intervallo ampio, confermare l'intervallo esatto richiesto dall'applicazione. Dove possibile, limitare anche l'accesso a indirizzi sorgente conosciuti o a una rete di gestione dedicata.

Rimuovere ed elencare porte

sudo firewall-cmd --zone=public --remove-port=8443/tcp
sudo firewall-cmd --zone=public --list-ports

Esaminare le regole correnti

sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --list-all-zones
sudo firewall-cmd --permanent --zone=public --list-all

Il primo comando mostra il runtime della zona indicata, il secondo tutte le zone e il terzo la configurazione permanente di quella zona. Se differiscono, il comportamento può cambiare al prossimo reload o riavvio. Conserva un riferimento della configurazione iniziale e confronta i due ambiti prima di salvare una modifica.

Limitare SSH per indirizzo sorgente

Aggiungere una rich rule per SSH

Una rich rule è una regola estesa che combina condizioni, come la sorgente, con il servizio e l’azione da applicare. L’esempio seguente aggiunge un’autorizzazione IPv4; non costituisce da solo una politica che esclude tutte le altre sorgenti.

sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.10/32" service name="ssh" accept'

192.0.2.10/32 indica un singolo indirizzo IPv4 riservato agli esempi: sostituiscilo con la sorgente realmente vista dal server, tenendo conto di VPN, proxy e NAT. La regola ammette il servizio SSH da quella sorgente; non revoca altre autorizzazioni già presenti. Per IPv6 servono famiglia e sorgente IPv6 appropriate. La documentazione delle rich rule definisce sintassi e priorità.

Verificare l’accesso prima e dopo la restrizione

Prima della rimozione, registra le regole iniziali e verifica dalla console la possibilità di ripristinarle. Aggiungi la regola per sorgente e prova una nuova connessione dall’indirizzo ammesso. Questa prima prova, finché SSH è aperto a tutti, non dimostra ancora che il limite per sorgente funzioni. Il blocco seguente riguarda esclusivamente il caso in cui ssh sia già autorizzato come servizio generale nella zona corretta:

sudo firewall-cmd --zone=public --list-rich-rules
sudo firewall-cmd --zone=public --remove-service=ssh

Dopo aver rimosso il servizio generale, apri un’altra nuova connessione dalla sorgente consentita. Se possibile verifica anche, da una sorgente di prova autorizzata diversa, che l’accesso sia rifiutato. Controlla porte esplicite, altre rich rule, zone e policy che potrebbero ancora ammettere SSH: rimuovere il servizio SSH generale dalla zona non annulla le altre autorizzazioni né limita automaticamente IPv6.

Se perdi l’accesso previsto, usa la console e ripristina la configurazione annotata. Nel caso specifico in cui prima fosse presente il servizio generale SSH nella zona public, il comando di ripristino runtime è sudo firewall-cmd --zone=public --add-service=ssh; non salva in modo permanente. Verifica di nuovo l’accesso e non rendere persistente una configurazione ancora incerta. Indirizzi pubblici dinamici possono rendere fragile questo controllo: valuta una VPN o una rete di gestione stabile.

Associare una connessione NetworkManager a una zona

nmcli connection show --active
firewall-cmd --get-active-zones

La proprietà connection.zone conserva la zona nel profilo NetworkManager. Sostituisci System eth0 con il nome esatto, oppure identifica il profilo tramite UUID se i nomi non sono univoci. Annota la zona precedente e predisponi la console prima del comando: secondo la documentazione di connection.zone, su una connessione già attiva la modifica ha effetto immediato.

sudo nmcli connection modify 'System eth0' connection.zone public
sudo firewall-cmd --get-active-zones

Per cambiare soltanto connection.zone su un profilo già attivo non occorre riattivare la connessione con nmcli connection up. Controlla subito --get-active-zones e una nuova connessione SSH; per annullare il cambio, ripristina nel profilo il valore precedente della proprietà. Una zona non specificata usa quella predefinita del firewall. Eventuali altre modifiche che richiedono una riattivazione vanno pianificate con accesso alla console, perché possono interrompere la rete.

Individuare la causa di una connessione bloccata

Esegui systemctl is-active firewalld per confermare che firewalld sia attivo.
Usa firewall-cmd --get-active-zones per trovare la zona associata all'interfaccia o alla sorgente rilevante.
Confronta l'output runtime e permanente di --list-all per quella zona.
Esegui ss -lntup per confermare che l'applicazione stia ascoltando sull'indirizzo, porta e protocollo previsti.
Controlla i gruppi di sicurezza cloud, i firewall del provider, le liste di controllo accessi del router e le regole NAT.
Rivedi i rifiuti SELinux e i log dell'applicazione.

Una porta firewalld aperta non garantisce una connessione riuscita. L'applicazione deve essere in esecuzione e in ascolto su un indirizzo raggiungibile, e ogni altro strato di firewall o di instradamento nel percorso deve anche permettere il traffico.

Domande frequenti

Perché una regola aggiunta con --permanent non ha avuto effetto immediato?

Le modifiche fatte con --permanent normalmente richiedono reload, riavvio del servizio o riavvio del sistema per entrare nel runtime. Su un server remoto prova prima la regola runtime equivalente. --runtime-to-permanent è adatto solo dopo aver verificato l’intera configurazione attiva: sovrascrive quella permanente, non un singolo elemento.

Perché un servizio è irraggiungibile anche se la sua porta è aperta?

Controlla la zona attiva, l'indirizzo e il protocollo di ascolto dell'applicazione, i firewall cloud o di rete a monte, NAT e SELinux. Firewalld controlla solo un livello del percorso di connessione.

Dovrei usare una regola per il servizio o una regola per la porta?

Usa un servizio predefinito quando rappresenta accuratamente l'applicazione perché la regola è più facile da comprendere e può includere tutti i protocolli necessari. Usa una porta e un protocollo espliciti per un'applicazione personalizzata o una porta non standard.

È sicuro fermare firewalld per la risoluzione dei problemi?

Arrestare l'intero firewall può esporre ogni servizio in ascolto ed è pericoloso su un server di produzione. Ispeziona la zona attiva, i log e le regole correnti, quindi effettua la modifica temporanea al runtime più piccola necessaria per un test controllato.

Riepilogo

Identifica la zona corretta, applica la modifica minima nel runtime e verifica nuove connessioni prima di salvarla. Preferisci definizioni di servizio coerenti con l’applicazione, specifica il protocollo delle porte personalizzate e confronta runtime e permanente, soprattutto prima di --runtime-to-permanent.

Durante le modifiche SSH conserva sessione corrente e console alternativa. Dopo aver ristretto le autorizzazioni, verifica nuovamente un accesso dalla sorgente ammessa e il rifiuto delle sorgenti escluse prima di rendere persistente il risultato.

Riferimenti ufficiali

Rocky Linux