N.B. Sono stato costretto a spezzare l'articolo perché, quello originale di 8836 parole (per un totale di 76309 bytes effettivi), veniva troncato dopo il salvataggio a 7533 parole (65.356 bytes), cosa che mi fa sospettare che la grandezza del body non possa superare i 64k.

Nel capitolo precedente (Sveliamo i misteri di firewalld (Parte 1 di 2), abbiamo esaminato abbastanza nel dettaglio la cli di firewalld (firewall-cmd) con un focus particolare sul suo man, fatto molto bene.

Nel seguito ci concentreremo soprattutto su casi d'uso per vedere firewalld in azione, analizzando alcuni possibili cortocircuiti logici e approfondendo quanto già enunciato nei capitoli 1, 2, 4 della parte 1.

• 5. Esempi
  • 5.1. Caso 1: host con una sola interfaccia
    • 5.1.2. Esposizione di servizi custom con restrizioni
    • 5.1.3. Esposizione con port forwarding statico
  • 5.2. Caso 2: Configurazione di un fw personale su un host con 3 interfacce
  • 5.3. Caso 3: Router Firewall-Gateway
  • 5.4. Trappole nascoste
    • 5.4.1. Caso 1. Restrizioni con solo --add-source
    • 5.4.2. Caso 2: Combinazione di --add-source e --add-interface
    • 5.4.3. Remediation per la zone “hijacking”
• 6. Tips
  • 6.1. Le azioni di firewall-cmd
  • 6.2. Comandi utili
  • 6.3. Considerazioni di contorno

5. Esempi

Nel configurare firewalld, da utente, la difficoltà più grande per me consiste nel sapersi districare in mezzo alla ragnatela di zone, policy, servizi, nat, rich-rules ecc.

Come dicevo in precedenza per un firewall personale, bastano le zone con la dichiarazione dei servizi, così da filtrare il traffico in ingresso e finisce il gioco.

Quando invece lo scenario si complica, è necessario capire bene come funzioni il routing dei pacchetti fatto da firewalld e qual sia l'ordine di valutazione che firewalld fa dei vari oggetti che poi si traduce nell'accettazione o nel rifiuto del pacchetto.

Provo a tracciare una scaletta che però è frutto di esperienza nell'uso, di sperimentazione personale, nulla di ufficiale.

Fase 1: Associazione alle Zone firewalld per prima cosa deve capire quali siano le zone interessate controllando l'ip sorgente del pacchetto.

1. Se c'è una sorgente associata esplicitamente ad una zona, il pacchetto viene assegnato a quella zona.
2. Se non c'è alcuna sorgente, si controlla l'interfaccia fisica da cui è entrato il pacchetto e si assegna alla zona che trusta quell'interfaccia.
3. Se non c'è nessuna zona associata all'interfaccia, il pacchetto finisce alla zona impostata come default

Fase 2: Selezione del contesto (zone vs policy) Una volta identificate la zona di ingresso (e l'eventuale zona di uscita se il traffico è in transito/forwarding), firewalld decide quale “contenitore di regole” applicare:

1. Le policy vengono valutate prima delle singole regole delle zone. In base alle zone associate, firewalld verifica se esiste una Policy che le unisce e applica i filtri presenti nella policy
2. Se non ci sono policy object applicabili a quel flusso, il pacchetto viene processato direttamente all'interno della singola zona identificata nella Fase 1. Questo vuol dire che se ci sono filtri nella zona e c'è una policy del tipo zone-to-host, i filtri della policy vincono.

Fase 3: Valutazione delle regole interne (servizi, porte e NAT) Ora che abbiamo il contesto, è importante capire in che ordine firewalld applica i filtri.

1. come prima cosa si valutano le rich-rules con priorità negativa;
2. in seguito si prende in esame il dnat in modo che i filtri successivi lavorino sull'indirizzo e sulla porta di destinazione corretti;
3. successivamente si valutano i servizi e le porte standard, quelli aggiunti con --add-service e --add-port per capirci
4. dopo i servizi, vengono valutate le rich-rule tradizionali, quelle con priorità 0
5. come ultimo passo, se c'è, viene preso in carico il SNAT Masquerade

Fase 4: Il target di default Se un pacchetto è arrivato fino a questo punto significa che non ha trovato nessuna regola esplicita (nessun servizio o porta lo ha accettato o rifiutato prima) e viene applicato il target della zona (DROP/REJECT/ACCEPT/default) o della policy (DROP/REJECT/ACCEPT/CONTINUE)

La fase 3 è quella critica, quella che emette il verdetto di accettazione o rifiuto. E qui bisogna fare attenzione.

Le azioni di manipolazione dei pacchetti come il NAT non corrispondono ad un verdetto, che avviene invece:

1. nei servizi (--add-service o --add-port): accettazione (o rifiuto) implicita
2. nelle rich-rule se uno dei target viene esplicitato

Quindi, ad es. se nella zona o nella policy, c'è un add-service che accetta un determinato servizio e di seguito una rich rule che invece lo nega, add-service ha priorità e un pacchetto che richieda quel servizio verrebbe accettato e non scartato. Come pure, in una zona/policy default drop, se fosse presente un masquerade o un dnat senza alcuna accettazione esplicite, il pacchetto verrebbe rifiutato dalle politiche della zona/policy.

Alla luce di questa nuova consapevolezza, proverò a mostrare come risolvere alcuni tipici casi d'uso, partendo dalla configurazione di un semplice firewall personale che protegge l'esposizione di servizi standard, per proseguire in maniera incrementale arricchendo di volta in volta la configurazione iniziale.

5.1. Caso 1: host con una sola interfaccia

È il caso classico di un personal firewall.

Nel primo blocco di esempi mostrerò anche le configurazioni di un approccio full-policy.

Non ci sono vantaggi evidenti perché si tratta di casi semplici però concentrare la logica nelle policy piuttosto che nelle zone permette per es. di bloccare tutto il traffico in una zona default drop semplicemente disabilitando la policy.

Oppure posso usare la stessa logica di filtraggio su altre zone senza doverle replicare ma solo aggiungendo egress-zone e ingress-zone opportue.

5.1.1. Esposizione semplice

Ipotizziamo quindi di avere un host con una sola interfaccia e di voler configurare il firewall per filtrare i servizi ssh (22/tcp) e http(s) (80,443/tcp) che questo host espone su una lan.

Versione zone-oriented:

# creazione zona, binding su eth0, policy di default DROP (l'host non sarà nemmeno "pingabile")
firewall-cmd --permanent --new-zone=server-lan
firewall-cmd --permanent --zone="server-lan" --set-target=DROP
firewall-cmd --permanent --zone="server-lan" --add-interface=eth0

# abilitazione servizi ssh, http(s)
firewall-cmd --permanent --zone="server-lan" --add-service=ssh
firewall-cmd --permanent --zone="server-lan" --add-service=http
firewall-cmd --permanent --zone="server-lan" --add-service=https

Come si può vedere, la configurazione è pulita, lineare ed è veramente “parlante”. Chiunque bussi all'interfaccia eth0, accede ai servizi esposti dall'host.

Versione policy-oriented:

# creazione zona, binding su eth0, policy di default DROP (l'host non sarà nemmeno "pingabile")
firewall-cmd --permanent --new-zone="server-lan"
firewall-cmd --permanent --zone="server-lan" --set-target=DROP
firewall-cmd --permanent --zone="server-lan" --add-interface=eth0

# creazione policy
firewall-cmd --permanent --new-policy="lan-to-host"
firewall-cmd --permanent --policy="lan-to-host" --add-ingress-zone="server-lan"
firewall-cmd --permanent --policy="lan-to-host" --add-egress-zone=HOST
firewall-cmd --permanent --policy="lan-to-host" --set-target=REJECT

# binding dei servizi ssh, http(s)
firewall-cmd --permanent --policy=lan-to-host --add-service=ssh
firewall-cmd --permanent --policy=lan-to-host --add-service=http
firewall-cmd --permanent --policy=lan-to-host --add-service=https

Non cambia quasi nulla se non il fatto che il filtering ora avviene attraverso la policy mentre la zona contiene solo il trust delle sorgenti.

5.1.2. Esposizione di servizi custom con restrizioni

L'host stavolta esporrà i servizi su porte custom con questi vincoli:

• chiunque bussi a eth0 avrà accesso web
• mentre ssh sarà ristretto al solo ip 192.168.10.21

Versione zone-oriented:

# creazione zona, binding su eth0, policy di default DROP (l'host non sarà nemmeno "pingabile")
firewall-cmd --permanent --new-zone=server-lan
firewall-cmd --permanent --zone="server-lan" --set-target=DROP
firewall-cmd --permanent --zone="server-lan" --add-interface=eth0

# creazione servizio "web_custom"
firewall-cmd --permanent --new-service="web_custom"
firewall-cmd --permanent --service="web_custom" --set-description="My HTTP(S) service"
firewall-cmd --permanent --service="web_custom" --add-port=8080/tcp --add-port=8443/tcp

# creazione servizio "ssh_custom"
firewall-cmd --permanent --new-service="ssh_custom"
firewall-cmd --permanent --service="ssh_custom" --set-description="My SSH service"
firewall-cmd --permanent --service="ssh_custom" --add-port=2222/tcp

# chiunque bussi a eth0 sulle porte 8080 e 8443, verrà accettato 
firewall-cmd --permanent --zone="server-lan" --add-service=web_custom

# ssh_custom invece è ristretto con una rich-rule al solo ip 192.168.10.21
firewall-cmd --permanent --zone="server-lan" --add-rich-rule='rule family="ipv4" source address="192.168.10.21" service name="ssh_custom" accept'

Versione policy-oriented:

# creazione zona, binding su eth0, policy di default DROP (l'host non sarà nemmeno "pingabile")
firewall-cmd --permanent --new-zone="server-lan"
firewall-cmd --permanent --zone="server-lan" --set-target=DROP
firewall-cmd --permanent --zone="server-lan" --add-interface=eth0

# creazione servizio "web_custom"
firewall-cmd --permanent --new-service="web_custom"
firewall-cmd --permanent --service="web_custom" --set-description="My HTTP(S) service"
firewall-cmd --permanent --service="web_custom" --add-port=8080/tcp --add-port=8443/tcp

# creazione servizio "ssh_custom"
firewall-cmd --permanent --new-service="ssh_custom"
firewall-cmd --permanent --service="ssh_custom" --set-description="My SSH service"
firewall-cmd --permanent --service="ssh_custom" --add-port=2222/tcp

# creazione policy
firewall-cmd --permanent --new-policy="lan-to-host"
firewall-cmd --permanent --policy="lan-to-host" --add-ingress-zone="server-lan"
firewall-cmd --permanent --policy="lan-to-host" --add-egress-zone=HOST
firewall-cmd --permanent --policy="lan-to-host" --set-target=REJECT

# binding web_custom su tutta eth0
firewall-cmd --permanent --policy="lan-to-host" --add-service=web_custom

# ssh_custom invece è ristretto con una rich-rule al solo ip 192.168.10.21
firewall-cmd --permanent --policy="lan-to-host" --add-rich-rule='rule family="ipv4" source address="192.168.10.21" service name="ssh_custom" accept'

5.1.3. Esposizione con port forwarding statico

Facciamo il caso che i servizi ssh e web siano in ascolto sull'interfaccia di loopback. Vogliamo comunque esporli attraverso un port redirect facendo in modo che:

• HOST:22 → localhost:2222
• HOST:8080 → localhost:8080
• HOST:8443 → localhost:8443

In più vogliamo restringere l'accesso ssh a 3 soli ip: 192.168.10.20, 192.168.10.21, 192.168.10.22 e vogliamo bloccare tutto il traffico ICMP ad eccezione di echo-request.

Versione zone-oriented:

# creazione zona, binding su eth0, policy di default DROP
firewall-cmd --permanent --new-zone="server-lan"
firewall-cmd --permanent --zone="server-lan" --set-target=DROP
firewall-cmd --permanent --zone="server-lan" --add-interface=eth0

# icmp solo request
firewall-cmd --permanent --zone="server-lan" --add-icmp-block-inversion
firewall-cmd --permanent --zone="server-lan" --add-icmp-block=echo-request

# ipset per ssh
firewall-cmd --permanent --new-ipset="ssh-allowed" --type=hash:ip
firewall-cmd --permanent --ipset="ssh-allowed" --add-entry="192.168.10.20" 
firewall-cmd --permanent --ipset="ssh-allowed" --add-entry="192.168.10.21" 
firewall-cmd --permanent --ipset="ssh-allowed" --add-entry="192.168.10.22"

# Esposizione dei servizi
firewall-cmd --permanent --zone="server-lan" --add-service="http"
firewall-cmd --permanent --zone="server-lan" --add-service="https"
firewall-cmd --permanent --zone="server-lan" --add-service="ssh"

# Per il local forward è necessario abilitare il routing verso loopback
sysctl -w net.ipv4.conf.eth0.route_localnet=1

# local forward 80 → 8080, 443 → 8443
firewall-cmd --permanent --zone="server-lan" --add-forward-port=port=80:proto=tcp:to-port=8080:to-addr=127.0.0.1
firewall-cmd --permanent --zone="server-lan" --add-forward-port=port=443:proto=tcp:to-port=8443:to-addr=127.0.0.1

# rich-rule per l'accesso filtrato ssh con local forward 22 → 2222
firewall-cmd --permanent --zone="server-lan" --add-rich-rule='rule family="ipv4" source ipset="ssh-allowed" forward-port port="22" protocol="tcp" to-port="2222" to-addr="127.0.0.1"'

Anche qui la configurazione rimane molto pulita e lineare.

Versione policy-oriented:

# creazione zona, binding su eth0, policy di default DROP
firewall-cmd --permanent --new-zone="server-lan"
firewall-cmd --permanent --zone="server-lan" --set-target=DROP
firewall-cmd --permanent --zone="server-lan" --add-interface=eth0

# icmp solo request
firewall-cmd --permanent --zone="server-lan" --add-icmp-block-inversion
firewall-cmd --permanent --zone="server-lan" --add-icmp-block=echo-request

# ipset per ssh
firewall-cmd --permanent --new-ipset="ssh-allowed" --type=hash:ip
firewall-cmd --permanent --ipset="ssh-allowed" --add-entry="192.168.10.20"
firewall-cmd --permanent --ipset="ssh-allowed" --add-entry="192.168.10.21"
firewall-cmd --permanent --ipset="ssh-allowed" --add-entry="192.168.10.22"

firewall-cmd --permanent --new-policy="lan-to-host"
firewall-cmd --permanent --policy="lan-to-host" --add-ingress-zone="server-lan"
firewall-cmd --permanent --policy="lan-to-host" --add-egress-zone=HOST
firewall-cmd --permanent --policy="lan-to-host" --set-target=REJECTED

# Esposizione dei servizi
firewall-cmd --permanent --policy="lan-to-host" --add-service="http"
firewall-cmd --permanent --policy="lan-to-host" --add-service="https"
firewall-cmd --permanent --policy="lan-to-host" --add-service="ssh"

# Per il local forward è necessario abilitare il routing verso loopback
sysctl -w net.ipv4.conf.eth0.route_localnet=1

# local forward 80 → 8080, 443 → 8443
firewall-cmd --permanent --policy="lan-to-host" --add-forward-port=port=80:proto=tcp:to-port=8080:to-addr=127.0.0.1
firewall-cmd --permanent--policy="lan-to-host" --add-forward-port=port=443:proto=tcp:to-port=8443:to-addr=127.0.0.1

# rich-rule per l'accesso filtrato ssh con local forward 22 → 2222
firewall-cmd --permanent --policy="lan-to-host" --add-rich-rule='rule family="ipv4" source ipset="ssh-allowed" forward-port port="22" protocol="tcp" to-port="2222" to-addr="127.0.0.1"'

N.B. In realtà, casi di questo genere che non rientrano nella casistica più ampia del routing e del dnat che giustificherebbero l'uso di regole firewall, si risolverebbero più elegantemente con un reverse proxy (posto che i servizi siano reverse-proxabili), agire quindi a livello applicativo (L7) invece che a livello di indirizzamento e trasporto (L3 e L4 rispettivamente.)

Infine, ciliegina sulla torta, vogliamo che sia filtrato anche il traffico in uscita consentendo solo il traffico web per gli aggiornamenti di sistema (80,443/tcp) e quello dns (53/udp)

Sarà necessario un policy object per il flusso in uscita, sia nella versione zone-oriented che in quella policy-oriented

# creazione policy object, default policy REJECT
firewall-cmd --permanent --new-policy=host-to-any
firewall-cmd --permanent --policy=host-to-any --set-target=REJECT

# definizione della direzione del traffico: HOST → dmz (eth0)
firewall-cmd --permanent --policy="host-to-any" --add-ingress-zone=HOST
firewall-cmd --permanent --policy="host-to-any" --add-egress-zone=myZone

# traffico consentito: http(s), dns
firewall-cmd --permanent --policy="host-to-any" --add-service=http
firewall-cmd --permanent --policy="host-to-any" --add-service=https
firewall-cmd --permanent --policy="host-to-any" --add-service=dns

Per la configurazione di un firewall personale, esempi di questo tipo coprono il 95% dei casi ordinari, anche senza considerare il filtro del traffico in uscita.

5.2. Caso 2: Configurazione di un fw personale su un host con 3 interfacce

Proviamo a immaginare uno scenario leggermente più complesso, un host con 3 interfacce per segregare la rete in 3 flussi: management, ingresso, uscita.

• un'interfaccia per la rete di management (eth0: 192.168.0.0/24)
• un'interfaccia per il traffico in ingresso, la rete per il provisioning o per i servizi che l'host espone (eth1: 192.168.1.0/24)
• un'interfaccia per il data networking, la rete server-to server (eth2: 192.168.2.0/24)

L'host espone un servizio web, fa delle richieste ad un server mysql nel backend e consente di essere contattato via ssh per il management. Dall'interfaccia di backend invece l'host non può essere contattato.

Le policy invece riguarderanno la gestione del traffico in ingresso, dalle rispettive interfacce solo per ssh e web, e del traffico in uscita solo verso il backend mysql.

# ip che possono accedere al management dell'host
firewall-cmd --permanent --new-ipset="ssh_allowed" --type="hash:net"
firewall-cmd --permanent --ipset="ssh_allowed" --add-entry="192.168.5.32/27" --add-entry="192.168.6.32/27"

# per aggregare http/https in un unico servizio
firewall-cmd --permanent --new-service="web"
firewall-cmd --permanent --service="web" --add-include="http" --add-include="https"

# zona di management
firewall-cmd --permanent --new-zone="mgmt"
firewall-cmd --permanent --zone="mgmt" --add-interface=eth0
firewall-cmd --permanent --zone="mgmt" --set-target=DROP

# zona del servizio web
firewall-cmd --permanent --new-zone="webserver"
firewall-cmd --permanent --zone="webserver" --add-interface=eth1
firewall-cmd --permanent --zone="webserver" --set-target=DROP

# zona del backend
firewall-cmd --permanent --new-zone="backend"
firewall-cmd --permanent --zone="backend" --add-interface=eth2
firewall-cmd --permanent --zone="backend" --set-target=DROP

# policy per il traffico WEBSERVER → HOST (traffico IN ↑)
firewall-cmd --permanent --new-policy="any-to-webserver"
firewall-cmd --permanent --policy="any-to-webserver" --add-ingress-zone=webserver
firewall-cmd --permanent --policy="any-to-webserver" --add-egress-zone=HOST
firewall-cmd --permanent --policy="any-to-webserver" --set-target=DROP
firewall-cmd --permanent --policy="any-to-webserver" --add-service="web"

# policy per il traffico MGMT → HOST (traffico IN ↑)
firewall-cmd --permanent --new-policy="mgmt-host"
firewall-cmd --permanent --policy="mgmt-host" --add-ingress-zone=mgmt
firewall-cmd --permanent --policy="mgmt-host" --add-egress-zone=HOST
firewall-cmd --permanent --policy="mgmt-host" --set-target=DROP
firewall-cmd --permanent --policy="mgmt-host" --add-rich-rule='rule family="ipv4" source ipset="ssh_allowed" service name="ssh" accept'

# policy per il traffico HOST → backend (traffico OUT ↓)
firewall-cmd --permanent --new-policy="webserver-to-backend"
firewall-cmd --permanent --policy="webserver-to-backend" --add-ingress-zone=HOST
firewall-cmd --permanent --policy="webserver-to-backend" --add-egress-zone=backend
firewall-cmd --permanent --policy="webserver-to-backend" --set-target=DROP
firewall-cmd --permanent --policy="webserver-to-backend" --add-rich-rule='rule family="ipv4" service name="mysql" accept'

Il fatto che ci siano servizi con restrizioni sul sorgente, mi permetterà di porre l'attenzione su una particolarità di firewalld poco evidente ma responsabile di errori talmente gravi da invalidare le nostre policy di sicurezza.

In generale, i servizi con restrizioni si gestiscono SEMPRE con rich-rule per evitare spiacevoli effetti laterali.

Le rich-rules danno la granularità necessaria in questi casi accettando solo il traffico indicato in zone default drop.

Come negli esempi precedenti, alle definizioni di zona posso sostituire quelle di policy se voglio un approccio policy-oriented.

5.3. Caso 3: Router Firewall-Gateway

Ora facciamo l'esempio del classico router-firewall domestico.

L'host avrà quattro interfacce per altrettante reti. Una wan, una rete guest, una dmz e un backend che ospita servizi.

Condizioni

• In DMZ c'è un reverse proxy, un server web e un client di file sharing (p2p).
• Il Backend ospita un server mysql ad uso del server web, un servizio di file sharing solo per la rete di Backend (nfs).
• La rete pubblica non accetta connessioni in ingresso, salvo che quelle destinate al reverse proxy e al client di file sharing via port forwarding.
• Il reverseproxy media il contatto col server web che gira in localhost.
• Il Backend è inaccessibile da qualunque rete. La DMZ può contattare il Backend esclusivamente per i transiti:
  • server web → server mysql
  • client p2p → server nfs
• La rete guest ha accesso pieno a internet ma deve essere isolata sia da DMZ che da Backend. Anche i servizi esposti in DMZ possono essere contattati solo da rete pubblica.

Piano di indirizzamento

• wan0: 151.22.44.88, è l'indirizzo ip della zona pubblica
• eth0: 192.168.1.1 (192.168.1.0/24), gateway per la DMZ
• wlan0: 192.168.2.1 (192.168.2.0/24), gateway per il Backend
• wlan1: 192.168.3.1 (192.168.3.0/24), gateway per il guest.

Host in DMZ

• 192.168.1.2: server reverse-proxy (port 8080,8443) / web (localhost)
• 192.168.1.3: client p2p (port 36119)

Host in Backend

• 192.168.2.2: server mysql (port 3306)
• 192.168.2.3: server nfs (port 2049)

###########
# Servizi #
###########
firewall-cmd --permanent --new-service="web"
firewall-cmd --permanent --service="web" --add-include="http" --add-include="https"

firewall-cmd --permanent --new-service="p2p"
firewall-cmd --permanent --service="p2p" --add-port="36119/tcp" --add-port="36119/udp"

########
# Zone #
########
firewall-cmd --permanent --new-zone="pubblica"
firewall-cmd --permanent --zone="pubblica" --add-interface="wan0"
firewall-cmd --permanent --zone="pubblica" --set-target=DROP

firewall-cmd --permanent --new-zone="dmz"
firewall-cmd --permanent --zone="dmz" --add-interface="eth0"
firewall-cmd --permanent --zone="dmz" --set-target=DROP

firewall-cmd --permanent --new-zone="p2p"
firewall-cmd --permanent --zone="p2p" --add-interface="eth1"
firewall-cmd --permanent --zone="p2p" --set-target=DROP

firewall-cmd --permanent --new-zone="backend"
firewall-cmd --permanent --zone="backend" --add-interface="wlan0"
firewall-cmd --permanent --zone="backend" --set-target=DROP

firewall-cmd --permanent --new-zone="guest"
firewall-cmd --permanent --zone="guest" --add-interface="wlan1"
firewall-cmd --permanent --zone="guest" --set-target=DROP


##########
# Policy #
##########
##############################
# pubblica-dmz (wan0 → eth0) #
##############################
# Dalla rete pubblica arrivano le richieste da inoltrare sui
# server interni (DMZ).
# Definizione policy con default target DROP.
firewall-cmd --permanent --new-policy="pubblica-to-dmz"
firewall-cmd --permanent --policy="pubblica-to-dmz" --add-ingress-zone="pubblica"
firewall-cmd --permanent --policy="pubblica-to-dmz" --add-egress-zone="dmz"
firewall-cmd --permanent --policy="pubblica-to-dmz" --set-target=DROP
# Inoltri consentiti verso il reverse proxy.
firewall-cmd --permanent --policy="pubblica-to-dmz" --add-rich-rule='rule family="ipv4" forward-port port="80" protocol="tcp" to-port="8080" to-addr="192.168.1.2" accept'
firewall-cmd --permanent --policy="pubblica-to-dmz" --add-rich-rule='rule family="ipv4" forward-port port="443" protocol="tcp" to-port="8443" to-addr="192.168.1.2" accept'
firewall-cmd --permanent --policy="pubblica-to-dmz" --add-rich-rule='rule family="ipv4" forward-port port="36119" protocol="tcp" to-port="36119" to-addr="192.168.1.3" accept'
firewall-cmd --permanent --policy="pubblica-to-dmz" --add-rich-rule='rule family="ipv4" forward-port port="36119" protocol="udp" to-port="36119" to-addr="192.168.1.3" accept'

##############################
# dmz-backend (eth0 → wlan0) #
##############################
# Solo il reverse proxy (DMZ) può contattare mysql e nfs (Backend).
# Definizione policy con default target DROP.
firewall-cmd --permanent --new-policy="dmz-to-backend"
firewall-cmd --permanent --policy="dmz-to-backend" --add-ingress-zone="dmz"
firewall-cmd --permanent --policy="dmz-to-backend" --add-egress-zone="backend"
firewall-cmd --permanent --policy="dmz-to-backend" --set-target=DROP
# Transito consentito solo per rp verso mysql e per p2p verso nfs.
firewall-cmd --permanent --policy="dmz-to-backend" --add-rich-rule='rule family="ipv4" source address="192.168.1.2" destination address="192.168.2.2" service name="mysql" accept'
firewall-cmd --permanent --policy="dmz-to-backend" --add-rich-rule='rule family="ipv4" source address="192.168.1.3" destination address="192.168.2.3" service name="p2p" accept'

##############################
# dmz-pubblica (eth0 → wan0) #
##############################
# Abilitazione del solo browsing agli host (nattati) in DMZ.
# Abilitazione full all'host p2p (nattato) in DMZ.
# Definizione policy con default target DROP.
firewall-cmd --permanent --new-policy="dmz-to-pubblica"
firewall-cmd --permanent --policy="dmz-to-pubblica" --add-ingress-zone="dmz"
firewall-cmd --permanent --policy="dmz-to-pubblica" --add-egress-zone="pubblica"
firewall-cmd --permanent --policy="dmz-to-pubblica" --set-target=DROP
# Servizi
firewall-cmd --permanent --policy="dmz-to-pubblica" --add-rich-rule='rule family="ipv4" source address="192.168.1.2 service="web" masquerade accept'
firewall-cmd --permanent --policy="dmz-to-pubblica" --add-rich-rule='rule family="ipv4" source address="192.168.1.3 masquerade accept'

##################################
# backend-pubblica (eth0 → wan0) #
##################################
# Abilitazione del solo browsing degli host (nattati) in Backend.
# Qualunque altra richiesta verrà droppata dalle policy di zona.
# Definizione policy con default target DROP.
firewall-cmd --permanent --new-policy="backend-to-pubblica"
firewall-cmd --permanent --policy="backend-to-pubblica" --add-ingress-zone="backend"
firewall-cmd --permanent --policy="backend-to-pubblica" --add-egress-zone="pubblica"
firewall-cmd --permanent --policy="backend-to-pubblica" --set-target=DROP
# servizi
firewall-cmd --permanent --policy="backend-to-pubblica" --add-service="web"
firewall-cmd --permanent --policy="backend-to-pubblica" --add-service="dns"
# masquerade
firewall-cmd --permanent --policy="backend-to-pubblica" --add-masquerade

#################################
# guest-pubblica (wlan1 → wan0) #
#################################
# I client, nattati, hanno pieno accesso alla rete pubblica.
# Qualunque richiesta verso altre reti, verrà droppata
# dalle policy di zona.
# Definizione policy con default target ACCEPT.
firewall-cmd --permanent --new-policy="guest-to-pubblica"
firewall-cmd --permanent --policy="guest-to-pubblica" --add-ingress-zone="guest"
firewall-cmd --permanent --policy="guest-to-pubblica" --add-egress-zone="pubblica"
firewall-cmd --permanent --policy="guest-to-pubblica" --set-target=ACCEPT
# masquerade
firewall-cmd --permanent --policy="guest-to-pubblica" --add-masquerade

5.4. Trappole nascoste

Può capitare che definizioni di zone poco accorte aprano le maglie della gabbia che noi vorremmo cucire attorno all'esposizione dei servizi.

Vediamo un po' di scenari per analizzare le conseguenza delle scelte di design.

Per semplicità esaminerò il caso di un singolo host (192.168.1.2) che ospita un servizio web e un servizio mysql che vogliamo confinare con firewalld nel seguente modo:

• Il servizio web deve essere raggiungibile solo da 192.168.1.3
• Il servizio mysql deve essere raggiungibile solo da 192.168.1.4

5.4.1. Caso 1. Restrizioni con solo --add-source

firewall-cmd --permanent --new-zone=zone1
firewall-cmd --permanent --zone=zone1 --set-target=REJECT
firewall-cmd --permanent --zone=zone1 --add-source=192.168.1.3
firewall-cmd --permanent --zone=zone1 --add-service=http
firewall-cmd --permanent --zone=zone1 --add-service=https

firewall-cmd --permanent --new-zone=zone2
firewall-cmd --permanent --zone=zone2 --set-target=REJECT
firewall-cmd --permanent --zone=zone2 --add-source=192.168.1.4
firewall-cmd --permanent --zone=zone2 --add-service=mysql

firewall-cmd --set-default-zone=zone2

Questo tipo di configurazione è soggetto a quello che viene chiamato “zone hijacking” che permette a ip non autorizzati di accedere a risorse a cui non dovrebbero avere accesso situate nella zona di default o di fallback.

Nel caso specifico, un ip come 192.168.1.10, o qualunque altro a cui le policy di routing consentano di bussare lecitamente all'interfaccia, chiede di accedere a mysql, avrà il via libera vanificando tutte le nostre politiche di confinamento.

Vediamo perché succede questo.

1. 192.168.1.10 bussa alla porta 3306
2. Step 1: Verifica sorgenti
   1. 192.168.1.10 corrisponde a zone1 (192.168.1.3)? NO.
   2. 192.168.1.10 corrisponde a zone2 (192.168.1.4)? NO.
3. Step 2: Verifica interfacce
   1. Non ci sono interfacce associate
4. Il pacchetto viene consegnato alla zona di fallback, zone2, per l'elaboraziona finale, richiede lecitamente l'accesso a mysql che viene autorizzato → ❌ ERRORE!

5.4.2. Caso 2: Combinazione di --add-source e --add-interface

Quando l'ingresso alla zona viene mediato da una combinazione sorgenti e interfacce, non c'è il rischio di zone hijacking ma può essere ugualmente insidioso se non si capisce bene che fine facciano i pacchetti.

In generale basta ricordarsi sempre che la presenza di sorgenti e interfacce ha l'obiettivo opposto della restrizione perché va ad estendere l'insieme degli aventi diritto al servizio.

Facciamo sempre conto che 192.168.1.10 provi a bussare sulla 3306.

firewall-cmd --permanent --new-zone=zone1
firewall-cmd --permanent --zone=zone1 --set-target=REJECT
firewall-cmd --permanent --zone=zone1 --add-source=192.168.1.3
firewall-cmd --permanent --zone=zone1 --add-service=http
firewall-cmd --permanent --zone=zone1 --add-service=https

firewall-cmd --permanent --new-zone=zone2
firewall-cmd --permanent --zone=zone2 --set-target=REJECT
firewall-cmd --permanent --zone=zone2 --add-source=192.168.1.4
firewall-cmd --permanent --zone=zone2 --add-interface=eth0
firewall-cmd --permanent --zone=zone2 --add-service=mysql

firewall-cmd --set-default-zone=zone2

Anche facendo finta di non accorgersi che l'add-source della zona2 sia ridondante avendo la disponibilità dell'intera interfaccia che lo contiene, l'accesso in questo caso sarà consentito proprio perchè nello step2 della valutazione, la presenza dell'interfaccia fa ricadere il pacchetto nella zona 2 (accesso consentito) → ⚠️ ATTENZIONE!

Se invece spostassi il binding dell'interfaccia nella zona1,

firewall-cmd --permanent --new-zone=zone1
firewall-cmd --permanent --zone=zone1 --set-target=REJECT
firewall-cmd --permanent --zone=zone2 --add-interface=eth0
firewall-cmd --permanent --zone=zone1 --add-source=192.168.1.3
firewall-cmd --permanent --zone=zone1 --add-service=http
firewall-cmd --permanent --zone=zone1 --add-service=https

firewall-cmd --permanent --new-zone=zone2
firewall-cmd --permanent --zone=zone2 --set-target=REJECT
firewall-cmd --permanent --zone=zone2 --add-source=192.168.1.4
firewall-cmd --permanent --zone=zone2 --add-service=mysql

firewall-cmd --set-default-zone=zone2

il binding dell'interfaccia fa ricadere la richiesta nella zona1 che rifiuta l'accesso → ⚠️ ATTENZIONE!

5.4.3. Remediation per la “zone hijacking”

L'utilizzo delle sole sorgenti per restringere l'accesso non è sufficiente perché ip che transitano sull'host e non appartengano a nessuna sorgente di zona, possono richiedere lecitamente i servizi appartenenti alla zona di fallback

Ci sono un paio di modi per evitare questo tranello.

Uno consiste nell'usare le rich-rules come abbiamo fatto nella gestione delle zone di management e di backend del punto 5.2. Caso 2: Configurazione di un fw personale su un host con 3 interfacce. Accesso pieno alle sole interfacce e i sorgenti nelle rich-rules sono le white-list che consentono puntualmente chi può accedere a cosa.

Un altro metodo consiste nell'usare come zona di default, una zona senza alcun binding, con lo scopo di droppare tutto ciò che vi finisce dentro.

firewall-cmd --permanent --new-zone=default-drop
firewall-cmd --permanent --zone=default-drop --set-target=DROP
firewall-cmd --set-default-zone=default-drop

In questo modo la zona di default che riceverà il pacchetto sospeso non avrà alcun servizio associato a differenza di prima, ma dropperà tutto ciò che incontra.

6. Tips

6.1. Le azioni di firewall-cmd

Per districarsi rapidamente nella sintassi di firewall-cmd, mi viene comodo ricordare “le azioni” distintive principali in un'ottica CRUD:

• --get / --info / --list. recupera (legge) informazioni sulla configurazione
• --new / --add, crea nuovi oggetti / elementi
• --set, modifica gli elementi
• --remove / --delete, rimuove gli elementi / oggetti

E più precisamente:

• --get, restituisce un elenco di oggetti complessi a livello di sistema (ad es. icmptypes, servizi, zone o policy) o il valore di un suo campo ;
• --set, imposta il valore di un campo;
• --info, restituisce il recordset di un determinato oggetto complesso come un servizio, una policy, una zona, un ipset;
• --list, come --info ma più articolato;
• --new, crea nuovi oggetti complessi;
• --add, aggiunge un elemento ad un oggetto complesso;
• --remove, rimuove elementi da un oggetto complesso ad es. un servizio da una zona/policy, una entry da un servizio, una rule da una zona/policy ecc.
• --delete, rimuove un oggetto complesso come una zona, una policy, un ipset, un servizio ecc.

6.2. Comandi utili

Di seguito. un sottinsieme di comandi già visti, utili per catturare velocemente informazioni sulla configurazione del firewall.

Elenco di tutti gli ipset:

firewall-cmd --permanent --get-ipsets

Elenco di tutti i tipi di ipset:

firewall-cmd --get-ipset-types

Elenco di tutti tipi di icmp:

firewall-cmd --get-icmptypes

Elenco di tutti i servizi:

firewall-cmd --get-services

Individuare la zona dall'interfaccia:

firewall-cmd --permanent --get-zone-of-interface="<nome interfaccia>"

Individuare la zona dal sorgente:

firewall-cmd --permanent --get-zone-of-source=ip | MAC | ipset:"<nome_ipset>"

Zona di default:

firewall-cmd --get-default-zone

Zone attive:

firewall-cmd --get-active-zones

Elenco di tutte le zone/policies:

firewall-cmd --get-zones
firewall-cmd --get-policies

Dettaglio delle configurazione di tutte le zone/policy:

firewall-cmd --list-all-zone
firewall-cmd --list-all-policies

Dettaglio della configurazione di una zona/policy:

firewall-cmd --permanent --info-zone="<nome_zona>"
firewall-cmd --permanent --info-policy="<nome_policy>"

Elenco di tutti i servizi di una zona/policy:

firewall-cmd --zone="<nome_zona>" --list-services
firewall-cmd --policy="<nome_policy>" --list-services

Elenco di tutte le porte di una zona/policy:

firewall-cmd --permanent --zone="<nome_zona>" --list-ports
firewall-cmd --permanent --policy="<nome_policy>" --list-ports

Elenco di tutte le rich rules di una zona/policy:

firewall-cmd --permanent --zone="<nome_zona>" --list-rich-rules
firewall-cmd --permanent --policy="<nome_policy>" --list-rich-rules

Elenco di tutte le forward ports di una zona/policy:

firewall-cmd --permanent --zone="<nome_zona>" --list-forward-ports
firewall-cmd --permanent --policy="<nome_policy>" --list-forward-ports

Dettaglio della configurazione di un servizio:

firewall-cmd --permanent --info-service="<nome_servizio>"

Elenco di tutte le porte di un servizio:

firewall-cmd --permanent --service="<nome_servizio>" --get-ports

Dettaglio della configurazione di un ipset:

firewall-cmd --permanent --info-ipset="<nome_ipset>"

Elenco di tutte le entry di un ipset:

firewall-cmd --permanent --ipset="<nome_ipset>" --get-entries

6.3. Considerazioni di contorno

Concludendo, firewalld, in quanto frontend fedele di nftables, rappresenta il futuro del firewalling linux.

Aspetti comuni:

1. Configurare i servizi ove possibile è sempre da preferire rispetto a porte/protocolli sparati direttamente nella zona o nella policy.
2. Ricorrere alle rich-rules solo se si devono gestire flussi puntuali, altrimenti è sufficiente il bind dell'interfaccia alla zona.

Approccio conservativo: Per configurazioni semplici, bastano zone e servizi.

In presenza di più interfacce, obbligatorio anche il ricorso ai policy object, perché ci sarà da gestire di sicuro traffico interzona.

• Pro: curva d'apprendimento morbida, ideale se la necessità è di essere operativi nel breve. Ideali per firewall personali e configurazioni semplici.
• Contro: le configurazioni tendono ad irrigidirsi al crescere della complessità degli scenari e quindi a complicare le manutenzioni.

Approccio spregiudicato: Delegare alle zone solo il trust delle sorgenti e spostare la logica dei flussi interamente ai policy object.

• Pro: massima flessibilità, maggiore pulizia delle configurazioni. Ideale per scenari complessi.
• Contro: curva d'apprendimento più ripida, le configurazioni più semplici tendono ad apparire molto più verbose e di conseguenza meno chiare.

#firewall #firewallcmd #firewalld #iptables #netfilter #nftables #ufw

N.B. Sono stato costretto a spezzare l'articolo perché, quello originale di 8836 parole (per un totale di 76309 bytes effettivi), veniva troncato dopo il salvataggio a 7533 parole (65.356 bytes), cosa che mi fa sospettare che la grandezza del body non possa superare i 64k.

firewalld fornisce funzionalità firewall fungendo da frontend per netfilter.

Nell'interagire con netfilter, analogamente a ufw con iptables, firewalld usa come backend nftables, un tool nella user-space del kernel linux, che va a sostituire proprio iptables. Entrambi i backend forniscono filtraggio e classificazione dei pacchetti di rete /datagrammi/frame.

• 1. Come ragiona firewalld
• 2. Come procedo nella configurazione di Firewalld?
• 3. Il man di firewall-cmd
• 4. Come configurare firewalld
  • 4.1. Helpers
  • 4.2. Servizi
  • 4.3. Gestione ICMP
  • 4.4. Porte e protocolli
  • 4.5. IPset
  • 4.6. Rich-Rules
  • 4.7. Forwarding e Masquerade
  • 4.8. Zona
  • 4.9. Policy Objects
  • 4.10. Comandi di utilità generale

Attualmente ufw usa ancora iptables ma in modalità legacy, consistente in uno strato software che traduce i comandi iptables nei corrispondenti comandi nftables.

Firewalld supporta le zone di rete/firewall che definiscono il livello di fiducia delle connessioni o delle interfacce di rete.

C'è una separazione fra runtime e configurazione permanente che consente di testare una configurazione prima di renderla effettiva.

firewalld, con nftables, è certamente il frontend ideale per netfilter dal momento che recepisce tutte le sue innovazioni. La possibilità di usare, nella stessa cli, filtraggio, routing, snat e dnat per es. rende l'esperienza certamente più omogenea (con ufw, masquerade e port-forwarding richiedono una gestione aggiuntiva direttamente con iptables per ora).

Sebbene destinato ad essere rimpiazzato, iptables continua ad avere una sua specificità visto che viene ancora usato da docker per agire direttamente su netfilter bypassando eventuali firewall locali quano deve esporre una porta.

Con l'attuale versione di docker, la 29, è stato introdotto il supporto diretto su nftables in via sperimentale.

Ad ogni modo, chi approccia per la prima volta a firewalld (come è successo a me) all'inizio può essere sopraffatto dall'allegro affollamento di opzioni a disposizione.

• zone
• porte
• protocolli
• servizi
• policy objects
• rich-rules
• port forwarding
• masquerade
• ipset
• helper
• ....

La gui (firewall-config) mette certamente ordine ma non aiuta fino in fondo. Oltre a questo la gui non racchiude tutta la logica della cli (ad es. mancano i policy objects).

La cli di firewalld è il riferimento e come tutte le cli, può spaventare.

In realtà la cli, firewall-cmd nello specifico, è una delle più pulite e lineari che conosca, basta conoscere gli la logica a oggetti che governa firewalld.

1. Come ragiona firewalld

Se guardassi firewalld dall'alto, riconoscerei 7 oggetti principali:

• Zone
• Policy Objects
• Services
• IPSet
• ICMP Types
• Helper
• Direct Options (Deprecato)

Zone: è un po' il tratto distintivo di firewalld. Concettualmente rappresenta il livello di fiducia che si ha nei confronti di una rete connessa a una specifica interfaccia (es. eth0) o di un indirizzo IP. Ogni pacchetto dati che entra nel server viene catturato da una zona in base alla sua sorgente o all'interfaccia da cui arriva. È qui che avviene la configurazione del traffico in ingresso.

Policy Objects: è una delle novità di firewalld. I policy object nascono per gestire il traffico inter-zona. Inizialmente il filtraggio avveniva all'interno dell'oggetto (la zona) che accoglie il pacchetto, ora viene disaccoppiato e trasferito in un altro oggetto che gestisce il transito dei pacchetti tra una zona e l'altra (o se stessa). In questo modo cambia profondamente il paradigma di manipolazione dei pacchetti. La zona attiva il filtraggio quando il pacchetto entra da una delle sorgenti associate alla zone. La policy, attiva il filtraggio quando il pacchetto transita tra le zone specifiche definite dalla policy.

Services: rappresenta ciò che esponiamo (o che dobbiamo raggiungere, se filtriamo il traffico in uscita dal nostro host quando si comporta da client).

L'IPSet: permette di definire dei blocchi di ip a cui applicare regole massivamente invece che definirle puntalmente.

ICMP Types: è relativo ai pacchetti ICMP e permette di rendere disponibile il pacchetto scelto al traffico di tipo ipv4 e/o ipv6

Helper: torna comodo invece per quei protocolli che aprono una connessione su una porta e poi negoziano dinamicamente un'altra porta per il trasferimento dei dati (es. ftp, netbios-ns, sip, vecchi protocolli di gaming/streaming ecc.). Invece che aprire un intervallo ampio di porte, l'helper, che è un modulo del kernel, “ascolta” il flusso di controllo, capisce quale porta casuale sta per essere usata e la apre temporaneamente al volo solo per quel trasferimento.

Direct Options: le direct options (ormai deprecate e sostituite dai policy objects) sono la parte legacy di firewalld attraverso cui parla con iptables invece che con nftables.

Questi sono gli oggetti principali su cui si costruiscono le regole per il firewall attraverso una sintassi molto corposa ma ragionata e lineare.

La cli mette a disposizione delle istruzioni per fare praticamente qualunque cosa:

• visualizzare lo stato del firewall;
• istanziare gli oggetti;
• combinare gli oggetti istanziati al fine di creare la nostra logica di firewalling;
• effettuare delle query di verifica esistenziale sugli oggetti;
• effettuare il binding delle zone con interfacce o sorgenti;

Da tenere presente che la configurazione di firewalld, come iptables, può essere effimera. Se la configurazione a caldo non viene resa “permanente”, produce effetti fino a quando il servizio viene riavviato. Quando avviene, lo stato di firewalld ritorna ad essere quello che era prima delle modifiche.

2. Come procedo nella configurazione di Firewalld?

Come abbiamo visto, firewalld ha una logica di funzionamento molto più versatile di iptables, decisamente più rigido al confronto. Questa versatilità però può portare a rendere gli scenari più caotici potendo mescolare diverse tecniche di filtraggio. Come dire, il solito problema della scelta quando ce n'è troppa.

My two cents:

1. Se l'esigenza è quella di configurare un firewall personale, è sufficiente configurare opportunamente zone e servizi.
2. Se bisogna tenere in considerazione traffico inter-zona (in presenza di più interfacce per es.) ci vengono in aiuto i policy objects.
3. Se abbiamo ulteriori esigenze di granularità, la zona permette di definire delle rich-rules.

Un canovaccio del genere aiuta a mantenere la configurazione pulita, altrimenti potrei sporcarla in mille modi differenti rendendo però complicata la manutenzione futura.

Cercando di mettere a fattor comune quello che faccio con firewall-cmd la maggior parte delle volte, se volessi configurare un firewall personale secondo il canovaccio di cui sopra, i passi da fare sono i seguenti:

1. creo la zona
2. se non sono presenti nel default perché magari le porte dei servizi sono custom, creo anche i servizi (descrizione, porta/e e protocollo/i)
3. nella configurazione della zona, faccio il binding con l'interfaccia e con i servizi (eventualmente custom) che ho definito.

Stop.

Non occorre altro.

Ma firewalld permette anche configurazioni molto più borderline.

Nella mia zona potrei non avere alcun oggetto di tipo servizio ma potrei semplicemente assegnare direttamente una sbrodolata di porte e protocolli.

Oppure potrei lavorare direttamente con le rich-rules (approccio simil-ufw).

Oppure potrei affidare la logica direttamente ai policy objects.

Personalmente, tutte queste alternative (a parte l'ultima) le vedo più come un esercizio accademico senza una reale utilità pratica perché in scenari complessi questi approcci possono dar luogo a configurazioni estremamente caoitche.

3. Il man di firewall-cmd

Il man di firewall-cmd è molto chiaro e lineare e sarebbe bene tenerlo presente quando ci si lavora per le prime volte.

È strutturato in 3 grossi blocchi:

Sezioni di carattere generale. Stato firewall, verbosity log, salvataggio configurazioni, ecc

• General Options
• Status Options
• Log Denied Options
• Permanent Options
• Panic Options

Sezioni per la configurazione delle componenti core. Zone , Policy Objects, IPSet, Service, ecc.

• Zone Options
• Policy Options
• IPSet Options
• Service Options
• Helper Options
• ICMP type Options
• Direct Options (deprecato)

Sezioni per l'interrogazione e la configurazione delle combinazioni fra zone, policy objects, interfacce e sorgenti

• Options to Adapt and Query Zones and Policies
• Options to Adapt and Query Zones
• Options to Adapt and Query Policies
• Options to Handle Bindings of Interfaces
• Options to Handle Bindings of Sources

4. Come configurare firewalld

Come anticipato, la configurazione della zona con associati servizi, interfaccia e sorgenti, è tutto ciò che serve.

Se le mie policy sono complesse e ho necessità di centralizzarle, posso usare i policy objects.

Se si deve intervenire chirurgicamente per impedire o abilitare del traffico, ci sono le rich-rules.

In sostanza, tutto ruota attorno a due grossi item, le zone e i policy objects, che, forse in maniera un po' ridondante, combinano una serie di componenti che concorrono a formare la logica di firewalling.

Per entrare nel merito della configurazione partirò da quelle che per me sono le “foglie” di un ipotetico albero che, attraverso una serie di inclusioni, termina con 2 grosse radici: zone o police objects.

Fra gli elementi terminali nella gerarchia di firewalld, per me, ci sono gli helpers che poi concorrono a formare i servizi che insieme a porte e protocolli, IPset, forwarding, masquerade finiranno in zone, policy objects e rich-rules.

4.1. Helpers

Gli helpers sono degli oggetti basati sul modulo nf_conntrack del kernel Netfilter, che permettono di tracciare le connessioni, per la precisione sono delle interfacce che permettono a firewalld di caricare e configurare il relativo modulo nf_conntrack del kernel.

Ci sono protocolli come ftp, tftp, alcuni protocolli di gaming, voip ecc. che, oltre che esporre la porta per essere contattati, in un secondo momento devono negoziare dinamicamente con il client un'altra porta per lo scambio dei dati.

Questo tipo di servizi non è facilmente controllabile senza gli helpers perché la negoziazione dinamica imporrebbe di aprire un set molto ampio di porte.

Con gli helpers le connessioni di questi servizi “anomali” verranno tracciate in modo che, quando dal cliente arriva un pacchetto che richiede l'apertura di una porta random per lo scambio dati, quella connessione verrà marchiata come RELATED, che come tutto il traffico RELATED viene accettata nativamente, invece che come NEW che sarebbe destinata ad essere scartata.

Gli helpers, lista dei quali disponibile con:

firewall-cmd --get-helpers

corrispondono all'incirca ai moduli nf_conntrack presenti nel kernel Netfilter e si trovano in /lib/modules/$(uname -r)/kernel/net/netfilter.

Andranno aggiunti ai servizi, qualora servissero, in modo che firewalld accetti, e solo per quei servizi, connessioni da porte dinamiche.

Un po' di storia In passato, il kernel linux abilitava (con qualcosa tipo nf_conntrack_helper=1) gli helpers per default su tutto il traffico favorendo attacchi basati sullo spoofing dei pacchetti con cui farsi aprire porte a caso.

Poi quest'opzione è stata prima disabilitata di defautl con nf_conntrack_helper=0 permettendo un'attivazione prudente solo da file di configurazione con AutomaticHelpers=yes/no/system, poi è stata definitivamente rimossa sia dal kernel che dal file di configurazione.

Oggi, per attivare gli helper, basta dichiararli e associarli ad un servizio. Firewalld provvederà a caricare dinamicamente solo i moduli del kernel Netfilter necessari gestendo sia la porta dalla quale il servizio verrà contattato sia le porte dinamiche che verranno negoziate per lo scambio dei dati.

# restituisce tutte le informazioni di un helper
firewall-cmd --permanent --info-helper="<nome_helper>"

# dichiaro un nuovo helper
firewall-cmd --permanent --new-helper="<nome_helper>" --module=nf_conntrack_<nome_modulo>

# restituisce tutti gli helper presenti
firewall-cmd --permanent --get-helpers

# imposta / restituisce una descrizione
firewall-cmd --permanent --helper="<nome_helper>" --set-description="<descrizione>"
firewall-cmd --permanent --helper="<nome_helper>" --get-description

# imposta / restituisce una descrizione breve
firewall-cmd --permanent --helper="<nome_helper>" --set-short="<descrizione>"
firewall-cmd --permanent --helper="<nome_helper>" --get-short

# aggiunge/rimuove la porta o il range di porte dall'helper
firewall-cmd --permanent --helper="<nome_helper>" --add-port=<port>[-<port>]/<protocol>
firewall-cmd --permanent --helper="<nome_helper>" --remove-port=<port>[-<port>]/<protocol>

# restituisce tutte le porte associate all'helper
firewall-cmd --permanent --helper="<nome_helper>" --get-ports

# imposta / restituisce un modulo per l'helper
firewall-cmd --permanent --helper="<nome_helper>" --set-module=nf_conntrack_<nome_modulo>
firewall-cmd --permanent --helper="<nome_helper>" --get-module

# rimuove un helper da sistema
--permanent --delete-helper="<nome_helper>"

4.2. Servizi

Per creare un servizio, si assegna un nome e un insieme di porte e protocolli.

firewall-cmd --permanent --new-service="<nome_servizio>"
firewall-cmd --permanent --service="<nome_servizio>" --set-description="Descrizione del servizio"
firewall-cmd --permanent --service="<nome_servizio>" [--add-port=<port>/tcp | udp | sctp | dccp]+

Di seguito una lista di comandi utili:

# elenco di tutti i servizi
firewall-cmd --get-services
# elenco dei servizi della zona attiva
firewall-cmd --list-services
# elenco dei servizi di una determinata zona
firewall-cmd --permanent --zone="<nome_zona>" --list-services
# restituisce le info di un servizio
firewall-cmd --permanent --info-service="<nome_servizio>"

# imposta / restituisce una descrizione
firewall-cmd --permanent --service="<nome_servizio>" --get-description
firewall-cmd --permanent --service="<nome_servizio>" --set-description="<descrizione>"

# imposta / restituisce una descrizione breve
firewall-cmd --permanent --service="<nome_servizio>" --get-short-description
firewall-cmd --permanent --service="<nome_servizio>" --set-short-description="<descrizione>"

# restituisce tutte le porte del servizio
firewall-cmd --permanent --service="<nome_servizio>" --get-ports

# imposta / restituisce un (o più) protocollo di un servizio
firewall-cmd --permanent --service="<nome_servizio>" --get-protocols
firewall-cmd --permanent --service="<nome_servizio>" [--add-protocol=tcp | udp | sctp | dccp]+

# rimozione (porta, protocollo) / protocollo
firewall-cmd --permanent --service="<nome_servizio>" [--remove-port=<port>/tcp | udp | sctp | dccp]+
firewall-cmd --permanent --service="<nome_servizio>" [--remove-protocol=tcp | udp | sctp | dccp]+

# aggiunge / rimuove un helper da un servizio
firewall-cmd --permanent --service="<nome_servizio>" --add-helper="<nome_helper>"
firewall-cmd --permanent --service="<nome_servizio>" --remove-helper="<nome_helper>"

# restituisce gli helper collegati al servizio
firewall-cmd --permanent --service="<nome_servizio>" --get-service-helpers

# elimina un servizio
firewall-cmd --permanent --delete-service=="<nome_servizio>"

(rif. man service)

4.3. Gestione ICMP

Il traffico ICMP viene impostato a livello di zona o a livello di policy object.

Al solito, agire a livello di zona è più semplice, usare i policy objects permette di guadagnare in modularità e scalabilità.

Di default, ICMP lavora su blacklist. È tutto consentito tranne ciò che viene esplicitamente vietato con le istruzioni --add-icmp-block per aggiungere il tipo icmp che si vuole bloccare o --remove-icmp-block per rimuovere il blocco.

È possibile invertire la logica di funzionamento, a livello globale o di singola zona, passando ad una whitelist. È tutto vietato tranne cio che è consentito con --add-icmp-block (un po' fuorviante, ne convengo). --remove-icmp-block rimuove il consenso.

Di seguito, un elenco dei comandi di utilità disponibili per gli icmptype:

# Elenca tutti gli icmptype
firewall-cmd --get-icmptypes

# inverte / disattiva globalmente la logica del blocco icmp (attiva / disattiva whitelist)
firewall-cmd --permanent --add-icmp-block-inversion
firewall-cmd --permanent --remove-icmp-block-inversion

# Creazione e cancellazione di un icmptype
firewall-cmd  --permanent --new-icmptype="<nome icmptype>"
firewall-cmd  --permanent --delete-icmptype="<nome icmptype>"

# imposta / restituisce la descrizione di un icmptype
firewall-cmd  --permanent --icmptype="<nome icmptype>" --set-description="<descrizione>"
firewall-cmd  --permanent --icmptype="<nome icmptype>" --get-description

# imposta / restituisce la descrizione breve di un icmptype
firewall-cmd  --permanent --icmptype="<nome icmptype>" --set-short="<descrizione>"
firewall-cmd  --permanent --icmptype="<nome icmptype>" --get-short

# imposta/cancella/restituisce la destinazione (ipv4 o ipv6) di un icmptype
firewall-cmd  --permanent --icmptype="<nome icmptype>" --add-destination="[ipv4 | ipv6]"
firewall-cmd  --permanent --icmptype="<nome icmptype>" --remove-destination="[ipv4 | ipv6]"
firewall-cmd  --permanent --icmptype="<nome icmptype>" --get-destinations

(rif. man icmp type)

4.4. Porte e protocolli

Zone e policy objects permettono di fare binding diretto su porte e protocolli.

Non è generalmente una cosa che mi faccia impazzire perché si bypassano i servizi.

Si fa tutto più velocemente, è vero, ma quando le regole sono numerose e si usano porte non canoniche, la probabilità che, al tendere, non si capisca più su quale servizio si stia agendo, è elevatissima. (cfr. 4.8. Zona e 4.9. Policy objects)

4.5. IPset

Gli ipset sono liste di subnet o di ip che definiscono le sorgenti nelle zone, nei policy object o nelle rich-rules. La centralizzazione della dichiarazione delle sorgenti disaccoppia la dichiarazione dal suo utilizzo.

Per gli ipset basta indicarre, nome, tipo e una lista di entry.

firewall-cmd --permanent --new-ipset="<nome_ipset>" --type=<type>
firewall-cmd --permanent --ipset="<nome_ipset>" [--add-entry= subnet | ip]+

Di seguito, un elenco dei comandi di utilità disponibili per gli ipsets:

# Restituisce tutti gli ipsets
firewall-cmd --permanent --get-ipsets

# Restituisce tutte le info di un ipset
firewall-cmd --permanent --info-ipset="<nome_ipset>"

# Restituisce la lista dei tipi di ipset:
firewall-cmd --get-ipset-types

# Restituisce tutte le entry di un ipset
firewall-cmd --permanent --ipset="<nome_ipset>" --get-entries

# Cancella un ipset
firewall-cmd --permanent --ipset="<nome_ipset>" --remove-entry=subnet | ip

# Cancella una (o più) entry da un ipset
firewall-cmd --permanent --ipset="<nome_ipset>" [--delete-entry=subnet | ip]+

# imposta / restituisce la descrizione di un ipset
firewall-cmd --permanent --ipset="<nome_ipset>" --set-description="<descrizione>"
firewall-cmd --permanent --ipset="<nome_ipset>" --get-description

# imposta / restituisce la descrizione breve di un ipset
firewall-cmd --permanent --ipset="<nome_ipset>" --set-short="<descrizione_breve>"
firewall-cmd --permanent --ipset="<nome_ipset>" --get-short-description

(rif. man ipset)

4.6. Rich-Rules

Le rich rules danno quel controllo granulare alle zone che è essenziale se si deve intervenire chirurgicamente per accettare o negare del traffico specifico.

Le rich-rules hanno una sintassi leggermente più corposa dello standard firewalld, è un approccio simil-iptables, o meglio, simil-ufw, e vanno aggiunte o alle zone o alle policy. O a entrambe.

Con le rich-rules possiamo abilitare o negare puntualmente il traffico (a seconda della action scelta),

firewall-cmd --permanent --zone="<nome_zona>" --add-rich-rule='rule family="ipv4 | ipv6" \
  source address="<nome_ipset>" | subnet | ip \
  destination address="<nome_ipset>" | subnet | ip \
  # traffico indicato come servizio o come port:protocol
  service name="<nome_servizio>" | port=<port> protocol=tcp|udp|sctp|dccp \
  log prefix="<prefix>" \
  level="emerg | alert | crit | error | warning | notice | info | debug" \
  limit value="rate/duration" \
  # azioni
  accept | reject | drop | mark'

configurare il masquerade,

firewall-cmd --permanent --zone="<nome_zona>" --add-rich-rule='rule family="ipv4 | ipv6" \
  source address="<nome_ipset>" | "subnet" | "ip" \
  destination address="<nome_ipset>" | "subnet" | "ip" \
  masquerade'

agire di fino sul NAT,

firewall-cmd --permanent --zone="<nome_zona>" --add-rich-rule='rule family="ipv4 | ipv6" \
  source address="<nome_ipset>" | "subnet" | "ip" \
  destination address="<nome_ipset>" | "subnet" | "ip" \
  forward-port port="[port]+" protocol="tcp|udp|sctp|dccp" \
  to-port="[port]+" to-addr="<ip>"'

bloccare traffico ICMP.

firewall-cmd --permanent --zone="<nome_zona>" --add-rich-rule='rule family="ipv4 | ipv6" \ 
  source address="<nome_ipset>" | "subnet" | "ip" \
  destination address="<nome_ipset>" | "subnet" | "ip" \
  [icmp-block name="<nome_icmptype>" [drop | reject]]+

Di seguito una lista di comandi utili:

# Rimozione di una rich-rule
firewall-cmd --permanent [--zone="<nome_zona>" | --policy="<nome_policy>"] --remove-rich-rule='rule'

# Elenca tutte le rich-rules di una policy
firewall-cmd --permanent [--zone="<nome_zona>" | --policy="<nome_policy>"] --list-rich-rules

(rif. man rich-rules)

4.7. Forwarding e Masquerade

Firewalld gestisce il nat attraverso dei costrutti all'interno delle zone, dei policy objects o delle rich-rules.

In particolare, zone e policy consentono di configurare velocemente casi particolari di DNAT e SNAT, port forwarding e masquerade nello specifico, mentre per una gestione del DNAT più granulare si ricorre alle rich-rules, a livello di zona o di policy a seconda che si vogliano, al solito, manipolare i pacchetti quando entrano nella zona o quando il pacchetto transita tra le zone specifiche definite dalla policy.

Esempio Port forwarding statico:

# inoltra a 192.168.2.10:22, tutto ciò che la zona riceve sulla 
# porta 2222
firewall-cmd --permanent --zone=esterna --add-forward-port=port=2222:proto=tcp:to-port=22:to-addr=192.168.2.10

In questo modo inoltro tutto il traffico relativo alla zona.

Se voglio un controllo più fine, devo ricorrere alla combo policy (o zona) + rich-rules. In questo modo posso arrivare a determinare quale sia l'ip (o il gruppo di ip) client per il quale è abilitato l'inoltro ed eventualmente verso quale ip pubblico server, potendone scegliere diversi, effettuare l'inoltro.

Esempio DNAT generico:

# inoltro di tutto il traffico proveniente da un ip fisso 
# verso un ip privato, con remapping delle porte.
firewall-cmd --permanent --policy="esterna-interna" \
--add-rich-rule='rule family="ipv4" \
  source address="93.12.34.56" \
  forward-port port="5001-6000" protocol="udp" to-port="15001-16000" to-addr="192.168.1.100"'

# stesso esempio di prima in cui il sorgente client è un gruppo 
# di ip (ipset) fissi 
firewall-cmd --permanent --policy="esterna-interna" \
--add-rich-rule='rule family="ipv4" \
  source ipset="my_ipset" \
  forward-port port="80" protocol="tcp" to-port="8080" to-addr="192.168.1.100"'

# In questo caso suppongo che il fw esponga più indirizzi pubblici.
# Solo un ip specifico può inoltrare il suo traffico 
# richiedendolo ad uno degli indirizzi pubblici del firewall
firewall-cmd --permanent --policy="esterna-interna" \
--add-rich-rule='rule family="ipv4" \
  source address="151.12.13.14"    # ip client \
  destination address="9.10.20.31" # ip pubblico fw \
  forward-port port="53947" protocol="tcp" to-port="3306" to-addr="192.168.1.100"'

Esempio Masquerade:

firewall-cmd --permanent --zone=esterna --add-masquerade

Come nell'esempio del port forwarding statico, il nat a livello di zona o di policy altera qualunque pacchetto che transita nella zona o nella policy.

Anche qui, per avere un controllo migliore l'approccio policy (o zona) + rich-rules risulta vincente. In questo modo posso arrivare a scegliere quali dei server interni deve essere nattato ed eventualmente verso quali ip (snat condizionale).

# nat di un singolo ip interno
firewall-cmd --permanent --policy="interna-esterna" \
--add-rich-rule='rule family="ipv4" \
  source address=192.168.10.10 masquerade'

# nat di un gruppo di ip interni (ipset)
firewall-cmd --permanent --policy="interna-esterna" \
--add-rich-rule='rule family="ipv4" \
  source ipset="my_ipset" masquerade'

# nat di tutta la zona interna quando la destinazione è un ip 
# (o gruppo di ip) specifico
firewall-cmd --permanent --policy="interna-esterna" \
--add-rich-rule='rule family="ipv4" \
  destination ipset="my_ipset" masquerade'

# o, al contrario, si vuole nattare tutta la rete interna, o un
# suo segmento, TRANNE il traffico destinato ad UN'ALTRA rete
# specifica (es. una vpn o altro).
firewall-cmd --permanent --policy="interna-esterna" \
--add-rich-rule='rule family="ipv4" \
  source address="my_ipset"
  destination not address="10.4.10.0/24" masquerade'

# nat di un gruppo di ip solo per il servizio web
firewall-cmd --permanent --new-service="navigazione_web"
firewall-cmd --permanent --service="navigazione_web" \
  --add-include="http" \
  --add-include="https" \
  --add-include="dns"

firewall-cmd --permanent --policy="interna-esterna" \
--add-rich-rule='rule family="ipv4" \
  source ipset="my_ipset" \
  service name="navigazione_web" masquerade'

4.8. Zona

Per creare una zona basta assegnarle un nome e associarle una o più interfacce e/o una o più sorgente di indirizzi ip.

Una zona senza alcun binding non è attiva.

firewall-cmd --permanent --new-zone="<nome_zona>"

# aggiunge un'interfaccia
firewall-cmd --permanent --zone="<nome_zona>" [--add-interface="<nome_interfaccia>"]+

# aggiunge sorgenti
firewall-cmd --permanent --zone="<nome_zona>" [--add-source=subnet | ip | "<nome_ipset>"]+

Se nella configurazione sono presenti sia l'interfaccia che le sorgenti di ip, sto dichiarando che tutto ciò che transita per l'interfaccia o che rientra nelle sorgenti indicate, ricadrà nelle regole della zona.

Faccio notare che Il binding (sorgenti o interfacce) funziona in aggiunta, non restringe ciò che ad es. transita dall'interfaccia. Tenete bene a mente che nella gestione del routing dei pacchetti verso le zone che fa firewalld, vengono valutate prima le sorgenti e dopo l'interfaccia.

Se avessi l'esigenza di restringere il traffico nella zona, si potrebbe pensare di limitare il binding alle sole sorgenti, escludendo l'interfaccia, in modo che qualunque pacchetto che non provenga dagli ip o dalle subnet, a prescindere dall'interfaccia, indicate venga respinto (in base alla politica della zona).

Va tenuto presente che configurazioni di questo tipo, per quanto pulite e semplici da realizzare, possono dare luogo ad errori estremamente subdoli e pericolosissimi (vedremo un esempio in seguito).

Tutti i pacchetti che, transitando per l'host, non vengono assorbiti da alcuna zona, saranno gestiti dalla zona di default.

Di seguito una lista di comandi utili:

# restituisce la zona di default
firewall-cmd --get-default-zone

# setta la zona di default
firewall-cmd --set-default-zone="<nome_zona>"

# restituisce tutte le zone attive (tutte quelle con un binding ad un'interfaccia e/o ad un sorgente)
firewall-cmd --get-active-zones

# restituisce tutte le zone accoppiate ad una specifica interfaccia/sorgente
firewall-cmd --permanent --get-zone-of-interface="<nome_interfaccia>"
firewall-cmd --permanent --get-zone-of-source=subnet | ip | "<nome_ipset>"

# restituisce info dettagliate sulla zone
firewall-cmd --permanent --info-zone="<nome_zona>"

# elenca tutte le zone
firewall-cmd --permanent --list-all-zones

# cancella una zona
firewall-cmd --permanent --delete-zone="<nome_zona>"


###########
# Servizi #
###########
# aggiungi / cancella servizi da una zona o dalla zona attiva (se il nome zona non è specificato)
firewall-cmd --permanent --zone="<nome_zona>" [--add-service="<nome_servizio>"]+
firewall-cmd --permanent --zone="<nome_zona>" [--remove-service="<nome_servizio>"]+


######################
# porte e protocolli #
######################
# elencare tutte le porte e i protocolli della zona
firewall-cmd --permanent --zone="<nome_zona>" --list-ports
firewall-cmd --permanent --zone="<nome_zona>" --list-protocols

# aggiungere/cancellare una porta alla zona
firewall-cmd --permanent --zone="<nome_zona>" [--add-port=<port>/tcp | udp | sctp | dccp]+
firewall-cmd --permanent --zone="<nome_zona>" [--remove-port=<port>/tcp | udp | sctp | dccp]+

# aggiungere/cancellare un protocollo alla zona
firewall-cmd --permanent --zone="<nome_zona>" --add-protocol=<protocol>
firewall-cmd --permanent --zone="<nome_zona>" --remove-protocol=<protocol>


##############
# Rich-rules #
##############
# aggiungere/cancellare un protocollo alla zona
firewall-cmd --permanent --zone="<nome_zona>" --add-rich-rule="<nome_rich-rule>"
firewall-cmd --permanent --zone="<nome_zona>" --remove-rich-rule="<nome_rich-rule>"


#############
# ICMP Type #
#############
# inverte / disattiva la logica del blocco icmp nella zona (attiva / disattiva whitelist)
firewall-cmd --permanent --zone="<nome_zona>" --add-imcp-block-inversion
firewall-cmd --permanent --zone="<nome_zona>" --remove-imcp-block-inversion

# aggiunge un tipo icmp alla whitelist/blacklist
firewall-cmd --permanent --zone="<nome_zona>" [--add-imcp-block="<tipo_icmp>"]+

# rimuove un tipo icmp dalla whitelist/blacklist
firewall-cmd --permanent --zone="<nome_zona>" [--remove-imcp-block="<tipo_icmp>"]+


##############
# Masquerade #
##############
# aggiunge / rimuove il masquerade
firewall-cmd --permanent --zone="<nome_zona>" --add-masquerade
firewall-cmd --permanent --zone="<nome_zona>" --remove-masquerade


###########################
# Port forwarding statico #
###########################
# aggiunge / rimuove il port forwarding
firewall-cmd --permanent --zone="<nome_zona>" --add-forward-port=port=<port>[-<port>]:proto=[tcp|udp|sctp|dccp]:to-port=<port>[-<port>][:to-addr=<ip>[/<mask>]
firewall-cmd --permanent --zone="<nome_zona>" --remove-forward-port=port=<port>[-<port>]:proto=[tcp|udp|sctp|dccp]:to-port=<port>[-<port>][:to-addr=<ip>[/<mask>]

# es. di inoltro veerso un ip interno di un range di porte con offset deterministico
firewall-cmd --permanent --zone="esterna" --add-forward-port=port=2501-3000:proto=tcp:to-port=5001-5500:to-addr=192.168.10.20
firewall-cmd --permanent --zone="esterna" --remove-forward-port=port=2501-3000:proto=tcp:to-port=5001-5500:to-addr=192.168.10.20

(rif. man zone)

4.9. Policy Objects

I policy objects, presenti dall'ormai lontano 2020 con la versione 0.9.0, hanno posto le basi per il futuro di firewalld. È il posto in cui si concentrano le policy di filtraggio sia per il traffico intra-zona che, soprattutto, per il traffico inter-zona.

I policy objects cambiano radicalmente il disegno delle regole che, come detto in precedenza, vengono disaccoppiate dalla dichiarazione della zona che rimane il luogo in cui viene effettuato principalmente il trust delle sorgenti.

Conseguenza immediata è una notevole flessibilità perché ho la possibilità di variare dinamicamente le regole da applicare alle zone semplicemente aggiungendo le policy opportune.

Lavorare sulle zone è più immediato ma più lo scenario diventa articolato, più le configurazioni si complicano, oltre al fatto che alcune cose come il routing e l'inoltro, con le sole zone non sono proprio realizzabili

Le policy, al contrario, richiedono una maggiore complessità iniziale ma ha il vantaggio di mantenere il disegno generale più pulito nei casi in cui le configurazioni cambino con una certa frequenza o tendano a diventare via via più articolate.

Nel seguito mostrerò degli esempi di configurazioni fatte in modalità zone-oriented e policy-oriented.

Gli elementi costitutivi del policy object sono il nome, il target policy (di base, “default”), la specifica della direzione del traffico, uno o più servizi da abilitare.

firewall-cmd --permanent --new-policy="<nome_policy>"
firewall-cmd --permanent --policy="<nome_policy>" --set-target=DROP | REJECT | ACCEPT | CONTINUE

# definizione della direzione del traffico
firewall-cmd --permanent --policy="<nome_policy>" [--add-ingress-zone=HOST | "<nome_zona>" | ANY]+
firewall-cmd --permanent --policy="<nome_policy>" [--add-egress-zone=HOST | "<nome_zona>" | ANY]+

# traffico consentito
firewall-cmd per --permanent --policy="<nome_policy>" [--add-service="<nome_servizio>"]+

Di seguito, una lista di comandi utili:

# elenco, sintetico o dettagliato, di tutti i policy objects
firewall-cmd --get-policies
firewall-cmd --permanent --list-all-policies

# estrae tutti i componenti della policy
firewall-cmd --permanent --policy="<nome_policy>" --list-all

# restituisce le ingress / egress zone
firewall-cmd --permanent --policy="<nome_policy>" --list-egress-zones
firewall-cmd --permanent --policy="<nome_policy>" --list-ingress-zones

# restituisce i servizi
firewall-cmd --permanent --policy="<nome_policy>" --list-services

# restituisce le rich-rules
firewall-cmd --permanent --policy="<nome_policy>" --list-rich-rules

# info di un policy object
firewall-cmd --permanent --info-policy="<nome_policy>"

# cambiare target di un policy object
firewall-cmd --permanent --policy="<nome_policy>" --set-target=DROP | REJECT | ACCEPT | CONTINUE

# eliminare un policy object
firewall-cmd --permanent --delete-policy="<nome_policy>"


###########
# Servizi #
###########
# aggiungi / cancella servizi dal policy object specificato
firewall-cmd --permanent --policy="<nome_policy>" [--add-service="<nome_servizio>"]+
firewall-cmd --permanent --policy="<nome_policy>" [--remove-service="<nome_servizio>"]+


######################
# Porte e protocolli #
######################
# elencare tutte le porte e i protocolli del policy object specificato
firewall-cmd --permanent --policy="<nome_policy>" --list-ports
firewall-cmd --permanent --policy="<nome_policy>" --list-protocols

# aggiungere/cancellare una porta dal policy object specificato
firewall-cmd --permanent --policy="<nome_policy>" [--add-port=<port>/tcp | udp | sctp | dccp]+
firewall-cmd --permanent --policy="<nome_policy>" [--remove-port=<port>/tcp | udp | sctp | dccp]+

# aggiungere/cancellare un protocollo dal policy object specificato
firewall-cmd --permanent --policy="<nome_policy>" --add-protocol=[tcp | udp | sctp | dccp]
firewall-cmd --permanent --policy="<nome_policy>" --remove-protocol=[tcp | udp | sctp | dccp]


##############
# Rich-rules #
##############
# aggiungere/cancellare una (o più) rich-rule dal policy object specificato
firewall-cmd --permanent --policy="<nome_policy>" [--add-rich-rule="<nome_rich-rule>"]+
firewall-cmd --permanent --policy="<nome_policy>" [--remove-rich-rule="<nome_rich-rule>"]+


##############
# ICMP Types #
##############
# Aggiunge un tipo icmp alla whitelist/blacklist
firewall-cmd --permanent --policy="<nome_policy>" [--add-imcp-block="<tipo_icmp>"]+

# Rimuove un tipo icmp dalla whitelist/blacklist
firewall-cmd --permanent --policy="<nome_policy>" [--remove-imcp-block="<tipo_icmp>"]+


##############
# Masquerade #
##############
# aggiunge / rimuove il masquerade
firewall-cmd --permanent --policy="<nome_policy>" --add-masquerade
firewall-cmd --permanent --policy="<nome_policy>" --remove-masquerade


###########################
# Port forwarding statico #
###########################
# aggiunge / rimuove il port forwarding
firewall-cmd --permanent --policy="<nome_policy>" --add-forward-port=port=<port>[-<port>]:proto=[tcp | udp | sctp | dccp]:to-port=<port>[-<port>][:to-addr=<ip>[/<mask>]
firewall-cmd --permanent --policy="<nome_policy>" --remove-forward-port=port=<port>[-<port>]:proto=[tcp | udp | sctp | dccp]:to-port=<port>[-<port>][:to-addr=<ip>[/<mask>]

# es. di inoltro veerso un ip interno di un range di porte con offset deterministico
firewall-cmd --permanent --policy="wan-to-lan" --add-forward-port=port=2501-3000:proto=tcp:to-port=5001-5500:to-addr=192.168.10.20
firewall-cmd --permanent --zone="wan-to-lan" --remove-forward-port=port=2501-3000:proto=tcp:to-port=5001-5500:to-addr=192.168.10.20

(rif. man policy, man policies)

4.10. Comandi di utilità generale

Di seguito, un elenco dei comandi di utilità generale disponibili per firewalld:

# Restituisce lo stato di firewalld
firewall-cmd --state

# Riavvia firewalld
firewall-cmd --reload

# Riavvia firewalld ricaricando anche i moduli netfilter del kernel
firewall-cmd --complete-reload

# Restituisce il log level di firewalld
firewall-cmd --get-log-denied

# Imposta il log level di firewalld
firewall-cmd --set-log-denied=all | unicast | broadcast | multicast | off

# Rende permanente tutte le configurazioni effimere di firewalld. Necessario il reload.
firewall-cmd --runtime-to-permanent

# Kill switch ON /OFF
firewalld --panic-on
firewalld --panic-off

# Stato Kill switch [0 | 1]
firewalld --query-panic

#firewall #firewallcmd #firewalld #iptables #netfilter #nftables #ufw