1 19/10/2026 9 min

Firewalld “con interfaccia grafica”: la strada realistica è Cockpit

Se l’obiettivo è gestire Firewalld da browser su Linux, il punto da chiarire subito è questo: Firewalld non offre una GUI ufficiale autonoma paragonabile a un pannello classico. Nella pratica, la soluzione più pulita è usare Cockpit, che integra la gestione del firewall tramite il modulo dedicato e ti evita di installare strumenti pesanti o desktop completi su server che devono restare minimali.

Questa scelta è sensata soprattutto su host remoti, VPS e server dedicati: hai un’interfaccia web, lavori con privilegi amministrativi controllati, e mantieni il sistema in uno stato coerente con un ambiente server. Se invece stai cercando un desktop manager grafico per amministrare una macchina locale, il ragionamento cambia; ma per la maggior parte dei casi operativi, Cockpit è il compromesso corretto.

Prima di installare: verifica cosa hai già in macchina

Prima di aggiungere pacchetti, conviene verificare tre cose: che Firewalld sia presente e attivo, che il sistema usi systemd, e che tu abbia un accesso SSH di emergenza aperto. La GUI non deve diventare il solo canale di amministrazione del server.

Esegui questi controlli:

sudo systemctl status firewalld --no-pager
sudo firewall-cmd --state
ss -tulpn | grep -E ':(22|9090)\b' || true

Atteso: firewalld risulta active (running) e la porta SSH è già raggiungibile. Se stai amministrando da remoto, assicurati che la porta del pannello sia aperta solo dopo aver controllato il resto del percorso, perché il rischio classico è bloccarsi fuori dal server con una regola troppo stretta.

Pacchetto giusto: Cockpit e modulo firewall

Su molte distribuzioni recenti la gestione grafica del firewall arriva tramite il pacchetto Cockpit e, in alcuni casi, un modulo aggiuntivo già incluso nei repository ufficiali. La nomenclatura cambia tra famiglie distro, ma il principio è sempre lo stesso: installi il pannello web e poi abiliti il servizio.

Su sistemi basati su RHEL, Rocky, AlmaLinux, Fedora e derivate, il flusso tipico è questo:

sudo dnf install cockpit firewalld
sudo systemctl enable --now cockpit.socket
sudo systemctl enable --now firewalld

Su Debian e Ubuntu il nome del pacchetto può essere identico, ma dipende dai repository abilitati e dalla versione. In caso di dubbio, verifica prima la disponibilità:

apt-cache policy cockpit firewalld
sudo apt install cockpit firewalld

Se il pacchetto non è presente, il gap non va aggirato con repository casuali: chiudilo consultando i repository ufficiali della distro o la documentazione del vendor. Installare un pannello web da sorgenti non verificati su un server esposto non è una scorciatoia accettabile.

Abilitare l’accesso web senza aprire troppo la superficie d’attacco

Per accedere a Cockpit di solito usi la porta 9090/TCP. Aprirla in Firewalld è semplice, ma va fatto con criterio. Il punto non è “aprire la porta”, è limitare chi può usarla.

Se il server è in produzione, preferisci una di queste strategie:

  1. Aprire 9090 solo sulla zona usata per l’amministrazione, non su tutte le interfacce.
  2. Consentire l’accesso solo da una subnet di management o da un jump host.
  3. Esporre Cockpit solo su rete interna, dietro VPN o tunnel SSH.

Comando base per aprire la porta nella zona corrente:

sudo firewall-cmd --permanent --add-service=cockpit
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

Se il servizio cockpit non è definito nella tua versione, puoi usare la porta esplicita:

sudo firewall-cmd --permanent --add-port=9090/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

Verifica immediatamente con un controllo locale e remoto:

curl -kI https://127.0.0.1:9090
ss -lntp | grep ':9090\b'

Atteso: il socket ascolta e la risposta HTTPS è presente. Se il servizio non risponde, non forzare ulteriori aperture: controlla prima stato del socket, certificati locali e log di sistema.

Accesso all’interfaccia: cosa vedrai e dove intervenire

Una volta collegato a https://IP_o_hostname:9090, l’autenticazione avviene con un utente di sistema autorizzato. In ambienti Linux recenti questo significa, in genere, un utente con privilegi sudo o root. Non serve creare account separati solo per la GUI, a meno che la tua policy non lo richieda.

Nel pannello, la parte legata a Firewalld compare di solito nella sezione di rete o sicurezza. I dettagli cambiano leggermente tra release, ma la logica è costante: puoi vedere zone, servizi, porte, interfacce assegnate e regole attive. Questo è utile perché ti fa controllare la configurazione reale, non solo il file su disco.

Un errore frequente è confondere la zona predefinita con quella effettivamente usata dall’interfaccia. Se la GUI mostra una zona ma il traffico passa da un’altra, stai leggendo la configurazione giusta nel posto sbagliato. Prima di cambiare regole, verifica l’associazione tra interfaccia e zona:

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

Atteso: vedi quale interfaccia è agganciata a quale zona e quali servizi sono realmente consentiti. Se la GUI non riflette ciò che ti aspetti, il problema spesso non è il pannello ma la zona sbagliata o una modifica non ancora applicata.

Procedura pratica: installazione su una macchina server standard

La sequenza seguente è quella che userei su un host pulito, con accesso SSH e console disponibile. L’ordine conta: prima installi, poi abiliti il servizio, poi apri il firewall, infine verifichi dal browser.

  1. Installa Firewalld e Cockpit dai repository ufficiali della distro.
  2. Abilita Firewalld all’avvio se non è già attivo.
  3. Abilita il socket di Cockpit, non un daemon inventato a mano.
  4. Apri la porta 9090 solo nella zona corretta.
  5. Controlla che il servizio risponda in locale prima di tentare l’accesso remoto.
sudo systemctl enable --now firewalld
sudo systemctl enable --now cockpit.socket
sudo firewall-cmd --permanent --add-service=cockpit
sudo firewall-cmd --reload
sudo systemctl status cockpit.socket --no-pager

Se il sistema usa SELinux in enforcing, normalmente Cockpit funziona senza eccezioni manuali. Se incontri blocchi, non disattivare SELinux come scorciatoia: controlla gli audit log.

sudo ausearch -m AVC,USER_AVC -ts recent
sudo journalctl -u cockpit.socket -u firewalld --since '15 minutes ago' --no-pager

Se compaiono denial, il dato utile è il contesto, non il sintomo. Devi capire quale processo è stato bloccato, su quale porta e con quale etichetta SELinux. Solo così puoi correggere la causa senza allargare inutilmente i permessi.

Gestire le regole da GUI senza perdere tracciabilità

La comodità della GUI è reale, ma non deve cancellare la disciplina operativa. Ogni cambio fatto da browser dovrebbe restare tracciabile, e idealmente essere replicabile da CLI. Se modifichi una zona o aggiungi una porta, annota sempre cosa hai cambiato e perché.

Un buon metodo è questo: fai la modifica in GUI, poi esporta o verifica il risultato via CLI. In questo modo eviti il classico problema del “funziona nel pannello ma non so cosa è stato applicato davvero”.

Controlli utili dopo una modifica:

sudo firewall-cmd --list-all --zone=public
sudo firewall-cmd --runtime-to-permanent
sudo firewall-cmd --permanent --list-all --zone=public

Il primo comando ti mostra lo stato corrente, il secondo consolida le variazioni runtime in modo permanente, il terzo verifica la persistenza su disco. Se i due output non coincidono, hai trovato un punto da correggere prima del riavvio.

Scenario tipico: aprire solo SSH, HTTP e HTTPS, niente altro

In molti server web la configurazione minima è semplice: SSH per amministrazione, HTTP/HTTPS per il servizio esposto, e nient’altro. La GUI aiuta a visualizzarlo meglio, ma la logica resta quella di sempre: meno porte aperte, meno superficie d’attacco.

Configurazione essenziale in CLI, utile anche come verifica rispetto alla GUI:

sudo firewall-cmd --permanent --zone=public --add-service=ssh
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-services

Se usi la GUI per aggiungere servizi, l’output finale deve essere identico. Se vedi servizi inattesi, qualcuno ha ereditato una configurazione da un’altra zona oppure ha lasciato regole runtime non consolidate.

Troubleshooting: quando la GUI non parte o non mostra Firewalld

Qui la priorità è capire il layer rotto: socket del pannello, servizio firewall, rete, oppure browser e TLS locale. La sequenza di controllo più rapida è questa.

  1. Verifica che Cockpit sia in ascolto su 9090.
  2. Verifica che Firewalld sia attivo e non in errore.
  3. Controlla se la porta è aperta nella zona corretta.
  4. Leggi i log del servizio e del firewall.
sudo ss -lntp | grep ':9090\b'
sudo systemctl status firewalld cockpit.socket --no-pager
sudo journalctl -u firewalld -u cockpit.socket --since '30 minutes ago' --no-pager

Se il browser mostra errore di certificato, ricorda che Cockpit usa HTTPS e in certi contesti un certificato autofirmato. Non è un bug del firewall. Devi decidere se fidarti del certificato interno, sostituirlo con uno aziendale o usare un accesso protetto da rete privata.

Se invece il modulo firewall non compare nella GUI, il problema può essere banalmente un pacchetto non installato o una versione del pannello che non include quel plugin. In quel caso la chiusura del gap è semplice: controlla i repository, installa il componente corretto e verifica la presenza del menu relativo dopo il reload dell’interfaccia.

Comando utile per confermare i pacchetti installati:

rpm -qa | grep -E '^cockpit|firewalld' || true
# oppure
dpkg -l | grep -E 'cockpit|firewalld'

Rollback rapido se qualcosa va storto

Ogni modifica al firewall deve avere un piano di ritorno. La parte più delicata è l’apertura di nuove porte: se hai toccato una policy e hai perso l’accesso, il rollback deve essere immediato da console locale o da accesso out-of-band.

Rollback tipico di una porta aperta per Cockpit:

sudo firewall-cmd --permanent --remove-service=cockpit
sudo firewall-cmd --permanent --remove-port=9090/tcp
sudo firewall-cmd --reload

Se hai modificato una zona sbagliata, verifica prima quale zona è attiva e poi rimuovi la regola dal contesto corretto. Non fare pulizie a caso su tutte le zone, perché rischi di rompere servizi che non c’entrano nulla.

Quando usare davvero la GUI e quando restare su CLI

La GUI è utile quando devi fare verifiche visuali, formare operatori meno esperti, o gestire rapidamente poche regole su server remoti. La CLI resta preferibile quando vuoi automazione, audit ripetibile, provisioning o change management rigoroso.

In pratica: se stai lavorando su un singolo host e vuoi ridurre gli errori di digitazione, Cockpit aiuta. Se devi replicare la stessa policy su dieci server, il file di configurazione, un playbook o una pipeline sono più solidi. La GUI non sostituisce il metodo; al massimo lo rende più leggibile per operazioni puntuali.

La regola utile da tenere a mente è questa: usa la GUI per osservare e intervenire in modo rapido, usa la CLI per standardizzare e verificare. Se fai entrambe le cose nello stesso flusso, hai sia velocità sia controllo.

Checklist finale per un’installazione pulita

  1. Firewalld è attivo: systemctl status firewalld.
  2. Cockpit è in ascolto: ss -lntp | grep 9090.
  3. La porta 9090 è aperta solo nella zona corretta: firewall-cmd --get-active-zones.
  4. Il browser raggiunge la pagina HTTPS del pannello senza errori di rete.
  5. Le modifiche sono replicate o documentate anche via CLI.

Se uno di questi punti fallisce, non continuare a cliccare nella GUI sperando che si sistemi da sola. Fermati, identifica il layer rotto, leggi i log e correggi il minimo necessario. È il modo più veloce per non trasformare una semplice gestione firewall in un incidente di accesso al server.