Come configurare il firewall di SLES 15 con firewall-cmd

Un servizio può essere in esecuzione su un server SLES 15 e comunque andare in timeout per i client remoti perché il firewall blocca il nuovo traffico in entrata. La soluzione consiste solitamente nell'identificare la zona firewalld attiva e consentire solo il servizio o la porta necessari all'applicazione. Lo strumento da riga di comando SLES per questa operazione è firewall-cmd.

Questa guida si basa sulla Guida alla sicurezza e alla protezione di SLES 15 SP7 di SUSE e sul riferimento al comando firewalld, verificato il 7 ottobre 2026. I service pack precedenti e i sistemi SLES 12 aggiornati potrebbero presentare stati diversi o configurazioni firewall legacy. Le immagini del terminale mostrano esempi rappresentativi, non risultati acquisiti da un server reale; sostituire i nomi delle interfacce, le zone e i servizi con i valori presenti sul proprio host.

1. Verifica che firewalld sia in esecuzione

SUSE documenta firewalld come installato e abilitato di default su SLES 15. YaST normalmente lo avvia dopo l'installazione e inserisce le interfacce nella publiczona predefinita. Tuttavia, è consigliabile verificare la macchina anziché presumere che le impostazioni predefinite non siano cambiate. Eseguire questi comandi con un account autorizzato sudo:

sudo systemctl status firewalld
sudo firewall-cmd --state

Il gestore dei servizi dovrebbe segnalare che firewalldè attivo e firewall-cmd --statedovrebbe segnalare running. Se il servizio è installato ma arrestato, avvialo e abilitalo all'avvio:

sudo systemctl enable --now firewalld

Se firewall-cmdil pacchetto non è presente, verificare che firewalldsia installato e disponibile nei repository SUSE abilitati. Non installare o sostituire componenti firewall alla cieca su un server gestito.

2. Individua la zona che protegge l'interfaccia del server

Firewalld raggruppa le regole in zone , che rappresentano diversi livelli di attendibilità. La publiczona viene comunemente utilizzata per le reti non considerate attendibili. Un servizio aperto in una zona non si apre automaticamente in tutte le altre, quindi una regola corretta nella zona sbagliata può rendere l'applicazione irraggiungibile.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --zone=public --list-all

Utilizza l'output active-zone per trovare la zona associata all'interfaccia che trasporta il traffico client. Il nome dell'interfaccia potrebbe essere eth0, ens160, o un altro nome. Se devi controllare una singola interfaccia, esegui:

sudo firewall-cmd --get-zone-of-interface=eth0

Sostituire eth0con l'interfaccia effettiva. Un'interfaccia non esplicitamente assegnata a una zona viene gestita dalla zona predefinita. Evitare di modificare la zona predefinita in modo casuale: ciò potrebbe influire sulle interfacce che dipendono da essa. Su un server remoto, identificare la zona SSH o altra zona di gestione e confermare la relativa regola di accesso prima di ricaricare le impostazioni del firewall. Mantenere disponibile un percorso di ripristino tramite console o fuori banda, se presente.

3. Scegli un servizio denominato o una porta specifica

Un servizio firewalld è una definizione denominata che può includere una o più porte e protocolli. Di solito è più semplice consentire un servizio noto tramite il suo nome piuttosto che memorizzarne il numero di porta. Controlla l'elenco dei servizi installati e ispeziona una definizione prima di utilizzarla:

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

Per un server web, il httpservizio predefinito in genere copre la porta TCP 80; httpsesiste un servizio separato per il traffico web TLS. La documentazione SLES mostra lo stesso metodo basato sui servizi con esempi come DHCP. Utilizza il servizio effettivamente richiesto dalla tua applicazione e verifica la definizione del servizio localmente in caso di dubbi.

Se nessun servizio predefinito è adatto, apri solo la porta e il protocollo richiesti. Ad esempio, un'applicazione in ascolto sulla porta TCP 8443 può essere consentita con --add-port=8443/tcp. L'apertura di una porta nel firewall non avvia un'applicazione, non la collega alla rete né la rende sicura; verifica che il servizio stesso sia configurato per rimanere in ascolto sull'indirizzo previsto.

Prima di tutto, prova una regola temporanea.

Per un test breve, applica una regola alla configurazione di runtime. Le modifiche in fase di runtime hanno effetto immediato, ma vengono perse dopo il ricaricamento del firewall o il riavvio del servizio, a meno che non vengano salvate in modo permanente. Firewalld supporta una regola a tempo limitato, utile quando si desidera che un test scada automaticamente:

sudo firewall-cmd --zone=public --add-service=http --timeout=5m

Per un test della porta una tantum, utilizzare --add-port=8443/tcp --timeout=5mal posto di --add-service=http. Selezionare la zona che contiene effettivamente l'interfaccia del server; non copiare publicse l'host utilizza un'altra zona.

4. Salva la regola e ricarica firewalld

Quando sei pronto a rendere definitiva una regola, aggiungila alla configurazione permanente. L'esempio seguente consente l'utilizzo di HTTP nella zona pubblica:

sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --reload

Per HTTPS, ripetere il comando permanente con --add-service=https. Per una porta applicativa personalizzata, utilizzare un comando come:

sudo firewall-cmd --permanent --zone=public --add-port=8443/tcp
sudo firewall-cmd --reload

Questi esempi modificano prima la configurazione permanente, quindi la ricaricano in modo che la nuova regola diventi attiva. Un ricaricamento sostituisce anche le impostazioni di runtime con la configurazione permanente. Eventuali modifiche apportate solo in fase di runtime potrebbero quindi essere scartate. Prima di ricaricare un sistema di produzione, è necessario esaminare le regole di runtime e permanenti importanti, in particolare l'accesso all'amministrazione remota.

Esiste anche un flusso di lavoro che privilegia l'esecuzione in fase di runtime: testa una regola in fase di runtime, verifica che il servizio funzioni, quindi aggiungi la stessa regola --permanente ricarica. Evita di usare questa opzione --runtime-to-permanentcome scorciatoia a meno che tu non intenda salvare tutte le regole di runtime correnti, incluse le modifiche temporanee apportate da altri amministratori o software.

Come si può verificare che la modifica abbia funzionato?

Verifica sia la regola di runtime attiva che quella salvata. Per un servizio HTTP nella zona pubblica, esegui:

sudo firewall-cmd --zone=public --query-service=http
sudo firewall-cmd --permanent --zone=public --list-services
sudo firewall-cmd --check-config

La query dovrebbe restituire yes, l'elenco dei servizi permanenti dovrebbe includere http, e il controllo della configurazione dovrebbe essere completato correttamente. Per una regola di porta, utilizzare --query-port=8443/tcpe --list-portsnei comandi equivalenti. Eseguire anche un test da un client separato in grado di raggiungere il server; una query del firewall locale conferma la presenza della regola, non che DNS, routing, firewall a monte o il listener dell'applicazione siano corretti.

Problemi comuni e soluzioni sicure

• La regola è presente, ma le connessioni continuano ad andare in timeout: assicurati che sia stata aggiunta alla zona associata all'interfaccia lato client. Quindi verifica che l'applicazione sia in ascolto sull'indirizzo e sulla porta previsti e controlla eventuali firewall di rete a monte.
• La regola ha funzionato fino al ricaricamento: probabilmente è stata aggiunta solo in fase di esecuzione. Aggiungila --permanente ricarica, quindi interroga entrambe le configurazioni.
• L'accesso SSH è a rischio: verifica i servizi della zona attiva e i servizi permanenti prima di ricaricare. Se SSH è necessario e non è presente, aggiungi il sshservizio alla zona corretta in modo permanente prima di ricaricare. Non chiudere la sessione remota corrente finché non hai testato una seconda connessione.
• Stai eseguendo la migrazione da una versione precedente di SUSE: SLES 15 ha sostituito SuSEfirewall2 con firewalld. SUSE avverte che i profili firewall legacy hanno una compatibilità limitata con le versioni precedenti; consulta la guida alla migrazione anziché presumere che ogni regola precedente sia stata convertita.
• Sembra esserci un conflitto tra le regole: firewalld è progettato per gestire le regole del firewall dell'host. SUSE sconsiglia di modificare le stesse regole separatamente con strumenti come iptables, poiché ciò può confondere la configurazione attiva.

Per rimuovere un servizio o una porta permanenti non necessari, utilizzare l'opzione corrispondente --remove-serviceo --remove-portcon --permanent, quindi ricaricare e verificare nuovamente. Ad esempio, rimuovere HTTP dalla zona pubblica con sudo firewall-cmd --permanent --zone=public --remove-service=httpseguito da sudo firewall-cmd --reload.

Verifica prima di terminare

• firewalldè in esecuzione e si avvia all'avvio del server.
• Hai identificato la zona attiva per l'interfaccia che riceve il traffico.
• In quella zona è consentito solo il servizio o la porta necessari all'applicazione.
• L'amministrazione remota rimane consentita prima e dopo il riavvio.
• La regola compare nelle query di runtime e permanenti e il controllo di configurazione ha esito positivo.
• Un test di connessione da un altro host conferma che l'applicazione è raggiungibile.

Per dettagli specifici sulla versione, consultare la guida del firewall di SUSE SLES 15 SP7 , il manuale di firewall-cmd e le note di firewalld sulla configurazione runtime e permanente e sull'apertura di una porta o di un servizio .