Cyberdyne Systems

sshaudit.com di nuovo online!!!

Mon, 13 Jul 2026 03:57:06 +0000

Oh, gaudio!

Oh, giubilo!

ssh–audit è di nuovo fra noi. Il 4 luglio 2026 Joe Testa porta la sua creatura dalla versione 3.3.0, risalente ormai a due anni fa, alla versione 3.9.0, un aggiornamento corposo che riguarda:

aggiornamento supporto python 3.14, eliminazione python 3.8 e python 3.9
preparazione alla crittografia post-quantistica (warning se gli algoritmi di exchange non lo sono) rimozione supporto sshv1
Modifica della policy built-in per Debian 12
Aggiunta delle policy built-in per OpenSSH 10.0, 10.1, 10.2, 10.3, and 10.4.
Aggiunta delle guide all’hardenizzazione di Debian 13, Rocky Linux 10, Ubuntu 26.04.
**Avendo sempre come riferimento la resistenza post quantistica, sono stati aggiunti due nuovi algoritmi di key exchange e 11 nuove host_keys
ecc.

Anche sshaudit.com è di nuovo online anche se le guide non hanno ancora recepito gli aggiornamenti presenti nella cli.

Ma la notizia più rincuorante è che pare che Joe Testa stia bene e che abbia trovato uno sponsor che sta finanziando il suo sviluppo.

Mi riservo di approfondire a breve.

Intanto ben ritornato, Joe Testa ❤️.

#ssh #sshaudit

Sveliamo i misteri di Firewalld (Parte 2 di 2)

Fri, 10 Jul 2026 14:14:03 +0000

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
6. Tips

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.

Se c'è una sorgente associata esplicitamente ad una zona, il pacchetto viene assegnato a quella zona.
Se non c'è alcuna sorgente, si controlla l'interfaccia fisica da cui è entrato il pacchetto e si assegna alla zona che trusta quell'interfaccia.
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:

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
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.

come prima cosa si valutano le rich-rules con priorità negativa;
in seguito si prende in esame il dnat in modo che i filtri successivi lavorino sull'indirizzo e sulla porta di destinazione corretti;
successivamente si valutano i servizi e le porte standard, quelli aggiunti con --add-service e --add-port per capirci
dopo i servizi, vengono valutate le rich-rule tradizionali, quelle con priorità 0
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:

nei servizi (--add-service o --add-port): accettazione (o rifiuto) implicita
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.

192.168.1.10 bussa alla porta 3306
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.
Step 2: Verifica interfacce
1. Non ci sono interfacce associate
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=""

Individuare la zona dal sorgente:

firewall-cmd --permanent --get-zone-of-source=ip | MAC | 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=""
firewall-cmd --permanent --info-policy=""

Elenco di tutti i servizi di una zona/policy:

firewall-cmd --zone="" --list-services
firewall-cmd --policy="" --list-services

Elenco di tutte le porte di una zona/policy:

firewall-cmd --permanent --zone="" --list-ports
firewall-cmd --permanent --policy="" --list-ports

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

firewall-cmd --permanent --zone="" --list-rich-rules
firewall-cmd --permanent --policy="" --list-rich-rules

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

firewall-cmd --permanent --zone="" --list-forward-ports
firewall-cmd --permanent --policy="" --list-forward-ports

Dettaglio della configurazione di un servizio:

firewall-cmd --permanent --info-service=""

Elenco di tutte le porte di un servizio:

firewall-cmd --permanent --service="" --get-ports

Dettaglio della configurazione di un ipset:

firewall-cmd --permanent --info-ipset=""

Elenco di tutte le entry di un ipset:

firewall-cmd --permanent --ipset="" --get-entries

6.3. Considerazioni di contorno

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

Aspetti comuni:

Configurare i servizi ove possibile è sempre da preferire rispetto a porte/protocolli sparati direttamente nella zona o nella policy.
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

Sveliamo i misteri di Firewalld (Parte 1 di 2)

Mon, 08 Jun 2026 13:10:26 +0000

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

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:

Se l'esigenza è quella di configurare un firewall personale, è sufficiente configurare opportunamente zone e servizi.
Se bisogna tenere in considerazione traffico inter-zona (in presenza di più interfacce per es.) ci vengono in aiuto i policy objects.
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:

creo la zona
se non sono presenti nel default perché magari le porte dei servizi sono custom, creo anche i servizi (descrizione, porta/e e protocollo/i)
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=""

# dichiaro un nuovo helper
firewall-cmd --permanent --new-helper="" --module=nf_conntrack_

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

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

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

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

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

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

# rimuove un helper da sistema
--permanent --delete-helper=""

4.2. Servizi

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

firewall-cmd --permanent --new-service=""
firewall-cmd --permanent --service="" --set-description="Descrizione del servizio"
firewall-cmd --permanent --service="" [--add-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="" --list-services
# restituisce le info di un servizio
firewall-cmd --permanent --info-service=""

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

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

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

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

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

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

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

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

(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=""
firewall-cmd  --permanent --delete-icmptype=""

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

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

# imposta/cancella/restituisce la destinazione (ipv4 o ipv6) di un icmptype
firewall-cmd  --permanent --icmptype="" --add-destination="[ipv4 | ipv6]"
firewall-cmd  --permanent --icmptype="" --remove-destination="[ipv4 | ipv6]"
firewall-cmd  --permanent --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="" --type=
firewall-cmd --permanent --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=""

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

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

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

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

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

# imposta / restituisce la descrizione breve di un ipset
firewall-cmd --permanent --ipset="" --set-short=""
firewall-cmd --permanent --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="" --add-rich-rule='rule family="ipv4 | ipv6" \
  source address="" | subnet | ip \
  destination address="" | subnet | ip \
  # traffico indicato come servizio o come port:protocol
  service name="" | port= protocol=tcp|udp|sctp|dccp \
  log 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="" --add-rich-rule='rule family="ipv4 | ipv6" \
  source address="" | "subnet" | "ip" \
  destination address="" | "subnet" | "ip" \
  masquerade'

agire di fino sul NAT,

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

bloccare traffico ICMP.

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

Di seguito una lista di comandi utili:

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

# Elenca tutte le rich-rules di una policy
firewall-cmd --permanent [--zone="" | --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=""

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

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

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=""

# 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=""
firewall-cmd --permanent --get-zone-of-source=subnet | ip | ""

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

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

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


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


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

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

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


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


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

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

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


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


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

# 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=""
firewall-cmd --permanent --policy="" --set-target=DROP | REJECT | ACCEPT | CONTINUE

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

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

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="" --list-all

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

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

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

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

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

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


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


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

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

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


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


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

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


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


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

# 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

Cose molto notevoli su LVM

Mon, 25 May 2026 06:08:02 +0000

Oltre che alla grande flessibilità nella gestione dei volumi, LVM attraverso device mapper, aggiunge tutta una serie di ulteriori capacità che rendono questa tecnologia estremamente versatile.

La possibilità di disporre di meccanismi per la gestione di snapshot, cache pool. thin provisioning e raid, rendono LVM qualcosa di più di un gestore di volumi.

1. Snapshot
- 1.1. Attenzione: Dimensione della snapshot
- 1.2. Esempio
2. Thin Pool
3. Thin Pool e snapshot
4. Cache Pool
5. LVM Stripe
6. LVM Mirror
7. LVM Raid

1. Snapshot

Le snapshot LVM usano la tecnica del Copy-on-Write (CoW) allo scopo di ridurre la duplicazione.

La snapshot dovrà essre la fotografia del volume prima all'origine.

Ad ogni modifica / cancellazione, il file originale verrà portato sulla snapshot prima dell'operazione. Sul volume originale verranno scritti tutti i dati nuovi e quelli modificati.

Per il ripristino, si effettua quello che si chiama merge, dove i dati vecchi vengono ripristinati dalla snapshot e quelli nuovi cancellati dal volume.

Per il consolidamento delle modifiche, basterò rimuovere la snapshot,

1.1. Attenzione: Dimensione della snapshot

Se la snapshot ha la stessa dimensione del volume logico non ci sono problemi.

Se è più piccola, occorre prestare attenzione a che la quantità dei dati modificati sul volume logico non superino la dimensione della snapshot.

In questo caso infatti la snapshot risulterà inutilizzabile e non potrà più essere usata per il ripristino ma potrà essree solo rimossa.

1.2. Esempio

Supponiamo di avere un gruppo di volumi, my_vg, composto da 3 volumi logici:

lv_root (30 GiB)
lv_home (200 GiB)
lv_dati (500 GiB)

e di voler creare una snapshot precauzionale sulla root (supponendo di avere spazio a sufficienza altrimenti dovrò fare bene i miei conti per non riempire oltremisura la snapshot rendendola inservibile).

Creazione snapshot

lvcreate -s -L 30G -n  lv_root_snap my_vg/snap

Ripristino

umount /dev/my_vg/lv_root
lvconvert --merge my_vg/snap

Consolidamento

lvremove snap

2. Thin Pool

Il thin provisioning di LVM è l'alternativa dinamica alla classica gestione di volumi, thick, che prevede l'assegnazione statica delle dimensioni dei volumi.

Se è vero che il thick provisioning risulta comunque abbastastanza agevole per via della flessibilità intrinseca dei volumi in caso di riduzione o aumento della superficie allocabile, il thin provisioning può aumentare i vantaggi derivanti da LVM in alcuni scenari.

Il thin provisioning si basa sul principio che lo spazio assegnato ai volumi non viene usato mai completamente e mai tutto in una volta.

Ecco perché un'allocazione dinamica ci permetterebbe di definire volumi che si riempiono solo man mano che lo spazio viene occupato.

Se si opta per un thin provisioning sarebbe opportuno non usare tutto il gruppo di volumi ma lasciarne un 20% in previsione di future espansioni.

Con i thin pool non solo abbiamo la stessa flessibilità della gestione thick, ma possiamo lavorare anche in over provisioning ossia creare pool di volumi la cui somma potenziale sia superiore allo spazio realmente allocabile.

Es. Supponiamo avere un device da 100 GiB, /dev/sdb, su cui definisco un volume group e creare un thin pool di 50 GiB. Su questo thin pool creeremo 3 volumi “virtuali” da 20, 30 e 20 GiB.

# creazione volume group di 100 GiB
vgcreate vg_lab /dev/sdb

# creazione thin pool da 50 GiB
lvcreate -L 50G --thinpool vg_lab/lv_tp

# creazione dei 3 volumi virtuali in "over provisioning" 
lvcreate -V 20G --thin -n vol1_virt --thinpool vg_lab/lv_tp
lvcreate -V 30G --thin -n vol2_virt --thinpool vg_lab/lv_tp
lvcreate -V 20G --thin -n vol3_virt --thinpool vg_lab/lv_tp

Una volta creati i volumi possono essere formattati e montati come di consueto.

Lo spazio effettivamente occupato è quasi nullo, il sistema solleverà solo un warning per avvertirci che i volumi virtuali rischiano di saturare lo spazio disponibile.

Ecco perché bisogna prestare attenzione al raggiungimento della soglia critica. Bisognerà estendere subito il thin pool ed i volumi virtuali nel modo consueto.

⚠️⚠️⚠️ ATTENZIONE ⚠️⚠️⚠️ L'estensione di un volume virtuale non differisce molto da quello di un volume “classico”. Se lo spazio per le fette si sta esaurendo, si estendono nell'ordine:

il gruppo di volumi (se necessario)
il thin pool (se nel volume group c'è spazio a sufficienza)
i volumi virtuali
i filesystem

Se non siamo con l'acqua alla gola, i punti 3 e 4 sono sufficienti. L'estensione del volume virtuale è più rapida di quella classica perché non viene allocato spazio. L'estensione di un volume logico classico corrisponde all'estensione del thin pool.

Nel caso di riduzione, la situazione cambia parecchio perché la riduzione di un volume virtuale non fa guadagnare spazio allocabile visto che l'ampiezza del volume è solo teorica, ciò avviene solo con fstrim. Inoltre accorciando il volume virtuale al di sotto dei dati effettivamente scritti, si rischia di corrompere l'intero filesystem. Consiglio spassionato: ESTENDI SEMPRE E NON RIDURRE MAI!!!

Altra considerazione va fatta anche per i metadati.

A differenza dell'LVM classico dove la creazione di un volume logico necessitava di un extent per i metadati, il thin provisioning di LVM riserva un volume logico per i dati e un volume logico per i metadati.

L'estensione continua di piccole fette, può riempire il volume dei metadati col rischio di corrompere l'intero thin pool e prima che succeda, anche il volume dei metadati può dover essere esteso.

lvextend --poolmetadatasize +1G vg_lab/lv_tp

3. Thin Pool e snapshot

Un altro bel vantaggio della modalità thin pool è quello di facilitare l'uso delle snapshot.

Trattandosi di volumi virtuali, la dimensione della snapshot non ha bisogno di essere dichiarata. La creazione di snapshot è estremamente semplice.

# creazione di una snapshot
lvcreate -s -n lv_snap vg_lab/vol_virt

Come pure sia la creazione di snapshot annidate che il rollback risultano molto più semplici ed efficienti.

# creazione di una snapshot
lvcreate -s -n lv_snap1 vg_lab/vol_virt

# creazione di una snapshot annidata
lvcreate -s -n lv_snap2 vg_lab/lv_snap1

# rollback
umount vol_1
lvconvert --merge vg_lab/lv_snap2
mount -t ext4 -o defaults /dev/vg_lab/vol_virt vol_1

E a proposito di snapshot, occorre fare qualche osservazione.

Una serie di snapshot thin annidate, non è una catena di patch incrementali esposte al filesystem come si potrebbe pensare. In virtù del CoW, la snapshot annidate fotograferanno sempre lo stesso istante: quello del file system all'origine.

Facciamo un esempio:

lvcreate -V 10g -T vgtest/thinpool -n vmroot
mkfs.ext4 /dev/vgtest/vmroot
mount /dev/vgtest/vmroot /mnt/test
echo ORIGINAL > /mnt/test/file.txt
umount test

lvcreate -s -n snap1 vgtest/vmroot

mount /dev/vgtest/vmroot /mnt/test
echo MOD1 > /mnt/test/file.txt
umount /mnt/test

lvcreate -s -n snap2 vgtest/snap1

mount /dev/vgtest/vmroot /mnt/test
echo MOD2 > /mnt/test/file.txt
umount /mnt/test

lvcreate -s -n snap3 vgtest/snap2

mount /dev/vgtest/vmroot /mnt/test
echo MOD3 > /mnt/test/file.txt
umount /mnt/test

In questo esempio creo un volume virtuale, vmroot, e 3 snap annidate.

Monto il volume virtuale.
La prima snapshot, snap1, fotografa il file system del volume virtuale che contiene il file con “ORIGINAL”.
Il volume virtuale viene montato e il file viene modificato.
La seconda snapshot, snap2, fotografa snap1 che a sua volta conteneva il file system del volume virtuale che contiene il file con “ORIGINAL”.
Il volume virtuale viene montato e il file viene modificato.
La terza snapshot, snap3, fotografa snap2 che a sua volta conteneva snap1.. ecc.

Quindi snapshot siffatte non realizzano un versioning del file system come si potrebbe pensare, piuttosto possono essere utili per creare alberi di cloni/read-only, ambienti temporanei derivati da uno stato consistente, ecc.

In sostanza tornano utili quando ho una base da cui faccio derivare n snapshot che condividono i blocchi comune e con CoW minimizzo lo spazio.

Il merge di una qualunque snapshot ricondurrà il file system allo stato originario.

origin
 ├── snap1
 ├── snap2
 ├── snap3

Per lavorare sul delta come immaginiamo, si dovranno montare via via le snapshop, non il volume virtuale, e modificare quelle.

lvcreate -V 10g -T vgtest/thinpool -n vmroot
mkfs.ext4 /dev/vgtest/vmroot
mount /dev/vgtest/vmroot /mnt/test
echo ORIGINAL > /mnt/test/file.txt
umount /mnt/test

lvcreate -s -n snap1 vgtest/vmroot

lvchange -ay -K vgtest/snap1
mount /dev/vgtest/snap1 /mnt/test
echo MOD1 > /mnt/test/file.txt
umount /mnt/test

lvcreate -s -n snap2 vgtest/snap1

lvchange -ay -K vgtest/snap2
mount /dev/vgtest/snap2 /mnt/test
echo MOD2 > /mnt/test/file.txt
umount /mnt/test

lvcreate -s -n snap3 vgtest/snap2

lvchange -ay -K vgtest/snap3
mount /dev/vgtest/snap3 /mnt/test
echo MOD3 > /mnt/test/file.txt
umount /mnt/test

In questo modo si “inverte” la logica del merge che, prima riconduceva il file system allo stato inizale, ora invece consolida le modifiche delle snapshot

origin
 └── snap1
      └── snap2
           └── snap3

Il merge va fatto in ordine se si vogliono acquisire correttamente i delta. Tuttavia questo approccio

è raro
è difficile da gestire
complica i merge
può creare dependency tree intricati

Per questo quasi tutti:

snapshot sempre dell’origin
mai snapshot di snapshot
rollback lineare

4. Cache Pool

Il cache pool di LVM serve a migliorare l'accesso a dispositivi tradizionalmente lenti e lo fa combinando dischi HDD con SSD/NVMe.

In sostanza avremo un gruppo di volumi costituito dai dischi HDD e un altro gruppo di volumi costituito dai dischi SDD/NVMe, la nostra cache.

Il Logical Volume Cache sul disco veloce migliora l'accesso ad uno specifico volume logico del disco lento e prevede il ricorso a tutta una serie di tipi di volumi logici abbastanza variegata:

Origin LV: volume logico orignale costituito dai dischi lenti
Cache pool LV: volume logico composto a sua volta da altri due voumi logici: dati della cache e metadati della cache
- Cache data LV: volume logico contenente i blocchi di dati per il Cache pool LV.
- Cache metadata LV: volume logico contenente i metadatati per il Cache pool LV.
Cache LV: volume logico contenente l'Origin LV e Il Cache pool LV. È il volume realemente utilizzabile
Spare metadata LV: volume logico correlato ad una funzione di recovery data failure

Quando si crea una cache ho due possibilità a seconda che si voglia massimizzare velocità o affidabilità:

writethrough: Le operazioni di scrittura vengono inviate sia alla cache SSD che all'Origin HDD. La lettura avviene preferibilmente dalla cache. È la modalità più sicura. Se l'SSD muore, nessun dato va perso ma è meno efficiente in scrittura perché Origin HDD diventa il collo di bottiglia,
writeback: più veloce ma meno sicuro. Le scritture vengono salvate immediatamente sulla cache veloce e sincronizzate sull'HDD in background in un secondo momento. Se si dovesse rompere il disco di cache, c'è il rischio di una perdita di dati.

Il dimensionamento della cache è proporzionale alla dimensione del disco origin. Di solito si aggira in un range del 2-10%

2%: archiviazione sequenziale, file di grandi dimensioni;
5%: standard consigliato. File server generico, utilizzo desktop/workstation;
10%: carichi di lavoro intensivi e casuali come database SQL/NoSQL attivi, nodi di virtualizzazione densi (molte VM), ecc.

Non è necessario prevedere da subito Il disco di cache (se c'è stata la possibilità tanto meglio), ma si può aggiungere in un secondo momento estendendo il gruppo di volumi contenente l'HDD e battezzando l'LV di cache.

Perpariamo il nostro laboratorio in cui abbiamo un HD lento con un unico volume logico a cui applichiamo una cache.

disco lento: 2 GiB
disco veloce: 500 MiB
cache: 5% di 2 GiB (~100 MiB)

# creazione del device fisico per il laboratorio
fallocate -l 2GiB slow_disk.img

# attach del device e creazione del gruppo di volumi
vgcreate vg_lab $(losetup -Pf --show slow_disk.img)

# creazione e formattazione dell'unico volume logico
lvcreate -n lv_origin vg_lab -l 100%FREE
mkfs.ext4 /dev/vg_lab/lv_origin

Ora aggiungiamo il disco che farà da cache estendendo il gruppo di volumi:

# creazione del device fisico di cache per il laboratorio
fallocate -l 500MiB fast_disk.img

# attach del dispositivo e estensione del gruppo di volumi
DEV_FAST=$(losetup -Pf --show fast_disk.img)
vgextend vg_lab "${DEV_FAST}"

Il cache pool lv può essere configurato automaticamente oppure manualente.

4.1. Caso 1: configurazione automatica del cache pool lv

In un unico passaggio, convertiamo il volume logico attuale in un volume logico con cache.

lvcreate \
  --type cache \
  --cachemode writethrough \
  -l 5%FREE \
  -n cache_pool vg_lab/lv_origin "${DEV_FAST}"

Dopo questo comando vedremo che il volume logico lv_origin incapsula il cache pool (lv_origincache_cpool) e il volume logico dei dati (lv_origin_corig).

Il cache pool è composto da due volumi logici per i dati (lv_origincache_cpool_cdata) e i metadati (lv_origincache_cpool_cmeta).

Infine distinguiamo anche il volume logico di metadati spare da utilizzare per un eventuale data recovery failure (lvol0_pmspare).

lvs -a
  LV                           VG        Attr       LSize   Pool                   Origin            Data%  Meta%  Move Log Cpy%Sync Convert
  home                         vg_fedora -wi-ao---- 409,81g                                                           
  root                         vg_fedora -wi-ao----  50,00g                                                           
  swap                         vg_fedora -wi-ao----  16,00g                                                           
  lv_origin                    vg_lab    Cwi-a-C---  <2,00g [lv_origincache_cpool] [lv_origin_corig] 0,00   0,59            0,00
  [lv_origin_corig]            vg_lab    owi-aoC---  <2,00g                                                           
  [lv_origincache_cpool]       vg_lab    Cwi---C---   8,00m                                          0,00   0,59            0,00
  [lv_origincache_cpool_cdata] vg_lab    Cwi-ao----   8,00m                                                           
  [lv_origincache_cpool_cmeta] vg_lab    ewi-ao----   8,00m                                                           
  [lvol0_pmspare]              vg_lab    ewi-------   8,00m

4.2. Caso 2: configurazione manuale del cache pool lv

Se invece vogliamo intervenire su ogni singolo passaggio della creazione del cache pool:

# creazione dei volumi logici meta e dati per il cache pool
lvcreate -n cache_pool_meta -L 10M vg_lab "${DEV_FAST}"
lvcreate -n cache_pool -l 5%FREE vg_lab "${DEV_FAST}"

# creazione del cache pool assemblando meta e data
lvconvert \
  --type cache-pool \
  --cachemode writethrough \
  --poolmetadata vg_lab/cache_pool_meta vg_lab/cache_pool

# conversione del volume logico origin nel nuovo volume logico con cache
lvconvert \
  --type cache \
  --cachepool vg_lab/cache_pool vg_lab/lv_origin

In realtà è meglio lasciare a LVM il compito di dimensionare correttamente il volume per i metadati.

# creazione della cache pool
lvcreate --type cache-pool -l 5%FREE -n cache_cpool vg_lab "${DEV_FAST}"

# conversione del volume logico originale in un volume logico con cache
lvconvert \
  --type cache \
  --cachepool vg_lab/cache_cpool vg_lab/lv_origin

4.3. Switch della modalità

Per cambiare modalità fra writetrough e writeback (se non specificato nella definizione della cache pool, il default è writethrough).

lvchange --cachemode writeback vg_lab/lv_origin

4.4. Rimozione della cache

Se volessi levare il disco di cache e ritornare al volume logico di partenza:

lvconvert --uncache vg_lab/lv_origin
  Logical volume "lv_origincache_cpool" successfully removed.
  Logical volume vg_lab/lv_origin is not cached.
```https://noblogo.org/ebdpsbxxid/edit#publish
e `lvs -a` mostra il volume logico in queste condizioni:
```bash
lvs -a
  LV        VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_origin vg_lab    -wi-a-----  <2,00g

4.5. Monitoraggio

lvs -a -o lv_name,lv_size,cache_mode,data_percent,metadata_percent vg_lab

5. LVM Stripe

Analogo a Raid 0, l'uso diretto di stripe in lvm attraverso il mappatore interno dm-stripe, permette di definire su quali e quanti dischi va frammentata l'informazione da memorizzare allo scopo di aumentare le prestazioni.

Considerazioni:

Il gruppo di volumi deve contenere almeno due dischi fisici.
È preferibile che i dischi fisici abbiano tutti la stessa velocità altrimenti quello più lento diventerà il collo di bottiglia.
È possibile che i < n, dove i è il numero di dischi per lo stripe e n è il numero totale di dischi del gruppo di volumi
È anche possibile specificare i dischi va applicato lo stripe.
La dimensione dello stripe è di 64K come default. Ma per file molto grandi, video o database, la dimensione può essere anche di 128K o 256K

# creazione di un gruppo di volumi con 3 dischi
vgcreate vg_lab /dev/sdb /dev/sdc /dev/sdd

# stripe su due dischi a caso di vg_lab
lvcreate -i 2 -I 64k -L 10G -n lv_stripe vg_lab

# stripe su tutti i dischi di vg_lab
lvcreate -i 3 -I 64k -L 10G -n lv_stripe vg_lab

# stripe sui dischi sdc e sdd con uno stripe size di 128K
lvcreate -i 2 -I 128k -L 10G -n lv_stripe vg_lab /dev/sdc /dev/sdd

Come ogni raid 0, massime prestazioni e sicurezza 0. Se un disco si rompe, addio ai dati.

6. LVM Mirror

Come per lvm stripe analogo a raid 0, il mirror in lvm tramite il mappatore interno dm-mirror, è assimiliabile a raid 1.

Come ogni raid 1 che si rispetti, il chiaro vantaggio di questo approccio è proprio la ridondanza dei dati che, al costo del sacrificio di un disco, permette di correre ai ripari se uno dei dischi si danneggia.

# creazione di un gruppo di volumi con 2 dischi
vgcreate vg_lab /dev/sdb /dev/sdc

# creazione del volume logico "mirror"
lvcreate -m 1 -L 10G -n lv_mirror vg_lab

Il mirror diretto attraverso LVM in realtà è considerato legacy. Si consiglia di usare l'approccio più moderno che prevede di specificare il tipo, raid x, nell'invocazione di lvcreate perché userà il modulo specializzato del kernel per il raid software.

LVM mirror infatti pur essendo funzionalmente equivalente ad un raid 1 non è altrettanto efficace perché si basa su un log di sincronizzazione dove lvm tiene traccia degli elementi allineati.

Tale log deve stare su un altro disco (che diventa un altro punto di vulnerabilità) e quando c'è bisogno di ricostruire l'array in caso di rottura di un disco, l'operazione è molto lenta.

7. LVM Raid

Il raid lvm è un modo per prendere il meglio dei due mondi.

Non è che LVM abbia una sua implementazione del raid. Il raid “tradizionale” si basa sul sottosistema Multiple Devices del kernel e lavora direttamente sui dispositivi a blocchi.

LVM si interfaccia direttamente con il modulo md del kernel per attingere alle funzioni di raid così da offrire, attraverso device mapper, un'interfaccia unica per la gestione dei volumi e del raid.

7.1. Raid 0 (Stripe)

lvcreate --type raid0 -i 2 -I 64k -L 10G -n lv_raid0 vg_lab

A differenza del mirror, non ci sono gli stessi problemi per stripe. Il mappatore nativo di LVM, dm-stripe, fa bene il suo lavoro.

Usare lvmraid in questo caso resta vantaggioso per ragioni di coerenza. L'uso del modulo md rende possibile un'eventuale evoluzione verso livelli superiori (come RAID 1 o RAID 5).

7.2. Raid 1 (Mirroring)

L'alternativa moderna al vecchio lvm mirror che risolve i suoi problemi di efficienza usando il modulo md.

Basandoci sull'esempio di prima:

lvcreate --type raid1 -m 1 -L 10G -n lv_raid1 vg_lab

7.3. Raid 5 (Stripe con parità singola)

Creiamo un volume logico con RAID 5 basato su 4 dischi (stripe su 3 dischi e uno per la parità):

# creazione di un gruppo di volumi con 4 dischi
vgcreate vg_lab /dev/sdb /dev/sdc /dev/sdd /dev/sde

# creazione del volume logico con RAID 5
lvcreate --type raid5 -i 3 -L 10G -n lv_raid5 vg_lab

7.4. Raid 6 (Stripe con parità doppia)

Se vogliamo una parità doppia su 4 dischi (2 stripe e due di parità);

# creazione di un gruppo di volumi con 4 dischi
vgcreate vg_lab /dev/sdb /dev/sdc /dev/sdd /dev/sde

# creazione del volume logico con RAID 5
lvcreate --type raid6 -i 2 -L 10G -n lv_raid6 vg_lab

7.5. Raid 10

E veniamo al RAID 1+0, uno stripe su n array in mirror per combinare l'efficienza dello stripe con la sicurezza del mirror:

# creazione di un gruppo di volumi con 4 dischi
vgcreate vg_lab /dev/sdb /dev/sdc /dev/sdd /dev/sde

# creazione del volume logico con RAID 5
lvcreate --type raid10 -i 2 -m 1 -L 10G -n lv_raid10 vg_lab

7.6. Come monitorare il raid

Metodo rapido:

lvs -o name,vg_name,copy_percent,lv_attr,raid_health_status,devices vg_lab

# Combinandolo con watch posso vedere per es. la percentuale 
# di completamento della copia in caso di sostituzione del disco
watch -n 1 lvs -o name,vg_name,copy_percent,lv_attr,raid_health_status,devices vg_lab

Metodo dettagliato:

lvdisplay vg_lab/lv_raid5

Monitoraggio a basso livello: Balamente, visto che viene usato il modulo md:

cat /proc/mdstat

7.7. Come intervenire in caso di guasto

Con lvs vedremo che lo stato del volume è diventato degraded. Con pvpdisplay possiamo individuare il device danneggiato che comparirà come unknown device o con un sacco di errori I/O .

Dopo aver estratto il disco e messo quello nuovo, supponendo sia /dev/sdc, procediamo con la ricostruzione dell'array:

# inizializzazione nuovo disco
pvcreate /dev/sdc

# aggiunta del nuovo disco al gruppo
vgextend vg_lab /dev/sdc

# array rebuild
lvconvert --repair vg_lab/lv_raid5

# rimozione disco danneggiato dal gruppo di volumi
vgreduce --removemissing vg_lab

#lvm #dm #devicemapper #md #multipledevices #snapshot #thinpool #thinprovisioning #cachepool #raid #lvmraid

Ridimensionare volumi LVM

Mon, 20 Apr 2026 21:13:18 +0000

Supponiamo di avere 3 volumi logici, ad es. vol1, vol2, vol3 e di voler aumentare il secondo a discapito degli altri due.

Un’esigenza analoga, su un filesystem partizionato in 3 parti in maniera canonica, è un mezzo incubo perché il ridimensionamento della partizione centrale prevede un discreto numero di salti mortali per manenere la contiguità e per non rischiare di lasciare buchetti inutilizzabili fra una partizione e l’altra.

1. Cose che è bene ricordare quando si manipolano i volumi logici
2. Scenario 1: Estensione e riduzione di volumi logici
3. Scenario 2: Estensione e riduzione di gruppi di volume
4. Conclusione

Provo a buttare giù due righe su quello che mi verrebbe di fare:

riduco la prima partizione
riduco la terza partizione
sposto la terza partizione fino alla fine del disco
sposto la seconda partizione fino alla fine della prima partizione
estendo la seconda partizione fino alla fine della prima

Tutto questo tenendo presente che l’unità minima allocabile è il blocco (512 bytes) e che l’operazione che mi fa più paura è il move della partizione. parted non ha un comando “move” diretto. La procedura richiede di calcolare i nuovi settori, spostare i dati e aggiornare la tabella delle partizioni.

Senza una GUI come quella di gparted, bisogna farsi letteralmente i conti con carta e penna prima di agire e c’è il rischio, comunque molto alto, di commettere errori che sarebbero disastrosi.

LVM, al confronto, è una boccata d’ossigeno.

LVM dà la possibilità di ridimensionare volumi in maniera più semplice rispetto al partizionamento più tradizionale perché la dimensione della partizione è disaccoppiata da concetti di contiguità e dalla geometria del disco.

Nel caso del partizionamento tradizionale infatti le partizioni sono dei blocchi di settori consecutivi in cui ogni partizione inizia in un settore finisce in un altro.

Con LVM invece l’approccio è radicalmente diverso. La minima unità allocabile è l’extent (default 4 MiB) che serve per mappare un volume fisico in un volume logico.

Se immaginiamo che il volume fisico possa essere spezzettato in altrettanti extents in una sorta di “paniere”, il volume group, il volume logico non è altro che un insieme di questi extents pescati dal volume group (senza alcuna pretesa d’ordinamento) a cui posso:

aggiungere extents prelevandoli dal volume group
levare extents riponendoli nel volume group (o assegnandoli ad altri volumi logici).

Queste proprietà conferiscono una grande flessibilità alle operazioni di riduzione ed estensione dei volumi.

1. Cose che è bene ricordare quando si manipolano i volumi logici.

Partizioni Quando si riduce o aumenta un filesystem, è bene smontare le partizioni e volumi logici.

Ridurre un volume logico Quando si riduce un volume logico, si deve:

fare un check del filesystem
ridurre il filesystem
ridurre il volume logico

Estendere un volume logico Quando si aumenta un volume logico, al contrario, si deve:

estendere il volume logico
estendere il filesystem
fare un check del filesystem

Calcolare lo spazio allocabile Un volume logico è composto da un insieme di extents, blocchi grandi di default 4 MiB, che sono la minima unità allocabile. Un volume logico è quindi sempre corrispondente ad un multiplo di 4 MiB, n extents di cui n-1 allocabili, il rimanente per i metadati. Ad es. un volume logico di 2 GiB è composta da 512 extents di cui 511 allocabili.

La potenza di due Si deve tenere sempre presente che, nella matematica del calcolo dello spazio, si considerano le potenze di 2. Non di 10. Quindi un GiB equivale a 1024 MiB, non a 1000. Di conseguenza, se dividessi un GiB in due parti uguali avrei 2 blocchi da 512 MiB non da 500.

Estensione e riduzione Nelle istruzioni di estensione (lvextend) e riduzione (lvreduce) possiamo scegliere ciò che va specificato fra 4 modalità:

il numero totale di extents
il delta in aggiunta o in diminuzione degli extents (a seconde che l’operazione sia rispettivamente di estensione o di riduzione)
la dimensione totale espressa in KiB-MiB-GiB-TiB
come prima, il delta in aggiunta o in diminuzione della dimensione espresso in KiB-MiB-GiB-TiB

2. Scenario 1: Estensione e riduzione di volumi logici

Supponiamo di avere un disco da 2 GiB (2048 MiB) diviso in 3 volumi logici da 550 MiB, 350 MiB e 1148 MiB di e di volerne ridurre due per ampliare il terzo.

Vogliamo ridurre il primo di 150 MiB, il terzo di 330 MiB e aumentare corrispondentemente il secondo volume di 480 MiB.

Prepariamo il laboratorio col solito file appiccicato ad un loop device. Su quello definirò il volume group, il mio “paniere” di extents.

# creazione device
fallocate -l 2GiB disk_1.img

# creazione device e volum group
vgcreate vg_lab $(losetup -Pf --show disk_1.img)

# creazione volumi logici
lvcreate -n lv_lab_1 vg_lab -L 550M
lvcreate -n lv_lab_2 vg_lab -L 350M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

# formattazione volumi logici
mkfs.ext4 /dev/vg_lab/lv_lab_1
mkfs.ext4 /dev/vg_lab/lv_lab_2
mkfs.ext4 /dev/vg_lab/lv_lab_3

# mount dei volumi
mkdir vol_1 vol_2 vol_3
mount -t ext4 -o defaults /dev/vg_lab/lv_lab_1 vol_1
mount -t ext4 -o defaults /dev/vg_lab/lv_lab_2 vol_2
mount -t ext4 -o defaults /dev/vg_lab/lv_lab_3 vol_3

2.1. Step 0: curiosità

Prima di cominciare esaminiamo un po’ di dati, ad es. di quanti extents sono composti i nostri oggetti.

pvdisplay /dev/loop9
  --- Physical volume ---
  PV Name               /dev/loop9
  VG Name               vg_lab
  PV Size               2,00 GiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              511
  Free PE               0
  Allocated PE          511
  PV UUID               YmLOru-bIdL-iqGb-vJfI-RsTk-yhv7-vSJhkX

pvdisplay mi dà informazioni sul disco fisico che andrò ad aggiungere nel volume group. Fra queste:

PV Name: il nome del device, /dev/loop9
VG Name: è il nome del gruppo di volume, vg_lab, visibile solo perché abbiamo creato il gruppo di volume direttamente sul dispositivo invece che passare prima da pvcreate.
PV Size: 2 GiB, la dimensione del nostro “disco”
PE Size: dove PE sta Physical Extent, è di 4 MiB
Total PE sono i PE totali e sono 511, come previsto.

vgdisplay vg_lab
  --- Volume group ---
  VG Name               vg_lab
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <2,00 GiB
  PE Size               4,00 MiB
  Total PE              511
  Alloc PE / Size       0 / 0
  Free  PE / Size       511 / <2,00 GiB
  VG UUID               6D89ck-c2Ni-XlMN-5Was-rh5j-vi2t-5juCXt

vgdisplay mi dà informazioni sul gruppo di volumi. Fra queste, disitnguiamo

VG Name: il nome del volume group, già visto in pvdisplay, vg_lab
VG Size: la dimensione del volume group, minore di 2 GiB perché ci sono i metadati da considerari
PE Size: la dimensione di un extent, 4 MiB
Total PE / Size: Il numero totale di extent allocabili, che conferma VG Size, pari a 511 invece che 512.
Alloc PE: il numero totale di extent allocati, momento della creazione del volume group è 0
Free PE / Size: il numero totale di extent liberi, prima della creazione dei volumi logici è 511

Cosa succede quando creerò i volumi logici? Che cambia il numero di PE liberi e allocati. Siccome userò tutti gli extent disponibili, i valori per Alloc PE e Free PE si invertiranno rispetto a prima.

Infatti dopo la creazione dei volumi logici, vgdisplay mi dirà:

vgdisplay vg_lab
  --- Volume group ---
  VG Name               vg_lab
  ...
  Alloc PE / Size       511 / <2,00 GiB
  Free  PE / Size       0 / 0
  ...

511 extents allocati come confermato dai dati desumibili dei 3 volumi logici

lvdisplay vg_lab
 --- Logical volume ---
  LV Path                /dev/vg_lab/lv_lab_1
  LV Name                lv_lab_1
  VG Name                vg_lab
...
  LV Size                552,00 MiB
  Current LE             138
...
 --- Logical volume ---
  LV Path                /dev/vg_lab/lv_lab_2
  LV Name                lv_lab_2
  VG Name                vg_lab
...
  LV Size                352,00 MiB
  Current LE             88
...
 --- Logical volume ---
  LV Path                /dev/vg_lab/lv_lab_3
  LV Name                lv_lab_2
  VG Name                vg_lab
...
  LV Size                1,11 GiB
  Current LE             285
...

Per il primo, il secondo e il terzo volume logico abbiamo rispettivamente:

138, 88, 285 extents corrispondenti a
552 MiB, 352 MiB e 1140 MiB (1,11 GiB)
per un totale di 2044 MiB, al netto dei metadati.

Possiamo notare subito che le dimensioni non corrispondono a quanto indicato in lvcreate.

lvcreate -n lv_lab_1 vg_lab -L 550M
lvcreate -n lv_lab_2 vg_lab -L 350M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

Questo succede perché vengono sempre approssimate all’extent più vicino. Ecco perché il primo e il secondo volume sono diventati di 552 (138 extents) e 352 MiB (88 extents).

Sempre ricordando la particolarità dei multipli di 4 MiB legati a LVM, anche la riduzione di 150 MiB e di 330 MiB dei due volumi saranno approssimate sempre all’extent più vicino (152 MiB=38 extents e 332=83 extents). Questo dettaglio si rivelerà fondamentale quando dovremo ridimensionare il filesystem.

Con questa rinnovata consapevolezza cominciamo a ridimensionare.

2.2. Step 1: Smontare i dischi

umount /dev/vg_lab/lv_lab_1
umount /dev/vg_lab/lv_lab_2
umount /dev/vg_lab/lv_lab_3

2.3. Step 2: Riduzione del filesystem

Se dovessi ridimensionare solo il filesystem, sarebbe sufficiente considerare dimensioni che siano potenze di 2 e non di 10.

Ma sapendo che sotto c’è un LVM, sappiamo che per mantenere l’allineamento fra filesystem e volumi logici, oltre che potenze di due le dimensioni devono essere anche multipli di 4MiB.

Ecco perché anche nel resize reale del filesystem non dovrò levare 150 MiB e 330 MiB ma 148 MiB (37 PE) e 328 (82 PE) (è buona norma approssimare per difetto all’extent più vicino per maggior prudenza) per un totale effettivo di 476 MiB (119 PE)

Il filesystem del primo volume sarà dunque di 552 MiB – 148 MiB = 404 MiB. Il filesystem del terzo volume sarà di 1140 MiB – 328 MiB = 812 MiB.

# check dei filesystem
e2fsck -f /dev/vg_lab/lv_lab_1
e2fsck -f /dev/vg_lab/lv_lab_2
e2fsck -f /dev/vg_lab/lv_lab_3

# Riduco il primo filesystem di 148 MiB
resize2fs /dev/vg_lab/lv_lab_1 404M

# Riduco il terzo filesystem di 328 MiB
resize2fs /dev/vg_lab/lv_lab_3 812M

2.4. Step 3: Ridimensionare i volumi logici

La riduzione del volume logico può essere fatta in 4 modi come sappiamo, ad es. sul primo volume:

# il numero totale di extents, 138 PE - 37 PE = 101 PE
lvreduce -l 101 /dev/vg_lab/lv_lab_1 #oppure

# il numero di exrtents da sottrarre, 38 PE
lvreduce -l -37 /dev/vg_lab/lv_lab_1 #oppure

# la dimensione totale da ottenere, 404 MiB
lvreduce -L 404M /dev/vg_lab/lv_lab_1 #oppure

# il numero di MiB da sottrarre, 148 MiB
lvreduce -L -148M /dev/vg_lab/lv_lab_1 #oppure

Per maggior chiarezza userò il size assoluto in modo da farlo corrispondere a resize2fs

# Riduco il primo volume logico di 148 Mib
lvreduce -L 404M /dev/vg_lab/lv_lab_1

# Riduco il terzo volume logico di 328 Mib
lvreduce -L 812M /dev/vg_lab/lv_lab_3

Verifichiamo quanti siano i PE residui

vgdisplay vg_lab | grep "Free  PE"
 Free  PE / Size       119 / 476,00 MiB

119 extents, come previsto.

2.5. Step 4: Estendere il volume logico

Dopo aver ridotto il primo e il terzo volume, non ci rimane che estendere il secondo in base alla scaletta indicata prima:

si estende il secondo volume logico
si estende il filesystem
si esegue il check fnale del filesystem

L’estensione del volume, come ormai ben sappiamo, non sarà di 480 MiB ma di 476 MiB (37 PE + 82 PE = 119 PE) per via degli arrotondamenti effettuati nella riduzione degli altri volumi logici.

# specifico gli extent che so essere residui
lvextend -l +119 /dev/vg_lab/lv_lab_2
# o, equivalentemente
# lvextend -L +476M /dev/vg_lab/lv_lab_2

# estendo il filesystem
resize2fs /dev/vg_lab/lv_lab_2 828M

# check filesystem
e2fsck -f /dev/vg_lab/lv_lab_2

2.6. Step 5: Bonus

Come premio per essere arrivato in fondo, posso rivelare come fare in un colpo solo tutte le operazioni descritte sopra.

È vero che c'è poco da considerare, giusto tenere a mente che su LVM ogni oggetto è multiplo di 4 MiB e che bisogna ridimensionare filesystem e volumi logici in ugual modo per non generare pericolose anomalie, ma tutte le operazioni che ho descritto nei passi 2-4 possono essere fatte con un unico comando che provvederà ad eseguire nell'ordine corretto e con le giuste approssimazioni:

il check del filesystem
il ridimensionamento del filesystem
il ridimensionamento dei volumi logici

Dunque, tutto il pippone atomico precedente può essere condensato in un unico, solido comando:

# Riduce il primo volume logico e il filesystem
lvreduce -r -L -150M /dev/vg_lab/lv_lab_1

# Riduce il terzo volume logico e il filesystem
lvreduce -r -L -330M /dev/vg_lab/lv_lab_3

# Estende il secondo volume logico e il filesystem
lvextend -r -l +119 /dev/vg_lab/lv_lab_2

Ora spieghiamo il perché soprattutto dell'extend, che è interessante.

Diciamo che è tutto molto guidato e le eventuali correzioni da apportare, senza spaccarsi troppo il cervello, sono suggerite con estrema chiarezza, basta leggere.

lvreduce -r -L -150M /dev/vg_lab/lv_lab_1
 Rounding size to boundary between physical extents: 148.00 MiB.
  File system ext4 found on vg_lab/lv_lab_1.
  File system size (552.00 MiB) is larger than the requested size (404.00 MiB).
  File system reduce is required using resize2fs.
...
  Size of logical volume vg_lab/lv_lab_1 changed from 552.00 MiB (138 extents) to 404.00 MiB (101 extents).
  Logical volume vg_lab/lv_lab_1 successfully resized.

Ci dice innanzitutto che:

c'è stato un arrotondamento a 148 MiB (37 extents);
il filesystem è più grande del volume richiesto pertanto va subito ridimensionato;
infine si ridimensiona il volume logico da 552 MiB (138 extents) a 404 MiB (101 extents).

Anche il secondo lvreduce ha un risultato analogo

lvreduce -r -L -330M /dev/vg_lab/lv_lab_3
  Rounding size to boundary between physical extents: 328.00 MiB.
  File system ext4 found on vg_lab/lv_lab_3.
  File system size (1.11 GiB) is larger than the requested size (812.00 MiB).
  File system reduce is required using resize2fs.
...
  Size of logical volume vg_lab/lv_lab_3 changed from 1.11 GiB (285 extents) to 812.00 MiB (203 extents).
  Logical volume vg_lab/lv_lab_3 successfully resized.

anche qui abbiamo un arrotondamento a 328 MiB (82 extents);
il filesystem è più grande del volume richiesto pertanto va subito ridimensionato;
infine si ridimensiona il volume logico da 1140 MiB (285 extents) a 812 MiB (203 extents).

È facilissimo desumere che la massima dimensione dell'estensione sia 148 MiB + 328 MiB = 476 MiB (119 extents), basta fare una somma.

Ma supponiamo di essere particolarmente distratti e proviamo ad estendere considerando le quantità iniziali: 150 MiB + 330 MiB = 480 MiB

lvextend -r -L +480M /dev/vg_lab/lv_lab_2
  File system ext4 found on vg_lab/lv_lab_2.
  File system fsck will be run before extend.
  Insufficient free space: 120 extents needed, but only 119 available

Nonostante la mia distrazione, come si può vedere, non si producono danni perché l'ouput è categorico: “non faccio nulla. Se vuoi, puoi aumentare al max di 476 MiB (119 extents)”. Non ci sono danni e anzi c'è pure il suggerimento risolutivo.

Ed ecco spiegato il mio extend di prima.

3. Scenario 2: Estensione e riduzione di gruppi di volume

Esaminiamo le possibilità di aggiungere o rimuovere dispositivi ad un volume group esistente.

Ricreiamo il laboratorio partendo da 3 dischi, poi aggiungeremo due nuovi dischi e ne rimuoveremo altrettanti, il tutto senza intaccare l'integrità dei dati.

# creazione di 5 device
for i in {1..5}: do fallocate -l 1GiB disk_${i}.img; done

# creazione del gruppo di volumi con 3 device
vgcreate vg_lab \
  $(losetup -Pf --show disk_1.img) \
  $(losetup -Pf --show disk_2.img) \
  $(losetup -Pf --show disk_3.img)

# crezione di 3 volumi logici
lvcreate -n lv_lab_1 vg_lab -l 300
lvcreate -n lv_lab_2 vg_lab -l 250
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

# formattazione dei 3 dispositivi
mkfs.ext4 /dev/vg_lab/lv_lab_1
mkfs.ext4 /dev/vg_lab/lv_lab_2
mkfs.ext4 /dev/vg_lab/lv_lab_3

Ecco come sono distribuiti i volumi logici all'interno dei dischi fisici

lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9              LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop10             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvm

Il gruppo di volumi è composto da 3 volumi fisici tutti attivi

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                3
  Act PV                3

Andiamo ad estendere il nostro gurppo di volumi con altri due device

vgextend vg_lab $(losetup -Pf --show disk_4.img) $(losetup -Pf --show disk_5.img)

I nuovi dischi sono visibili in fondo, come si può vedere anche da vgdisplay che mostra i 5 dischi tutti attivi.

lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9              LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop10             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvmchan
  loop12             LVM2_member     1G      loop
  loop13             LVM2_member     1G      loop

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                5
  Act PV                5

Potremo usare i nuovi dischi per estendere i volumi logici esistenti ma li impiegheremo invece per rimpiazzare i primi due dischi.

pvmove distribuisce tutti gli extents del disco fra tutti i volumi fisici che hanno spazio a sufficienza. Se non dovesse essercene, restituirà un messaggio d'errore.

pvmove /dev/loop9
  /dev/loop9: Moved: 3,14%
  /dev/loop9: Moved: 100,00%

Alla fine dell'operazione il disco s'è liberato di tutti i suoi extents e può essere rimosso

lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9              LVM2_member     1G      loop
  loop10             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop12             LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop13             LVM2_member     1G      loop

Prima si estrae il volume fisico dal gruppo di volumi e poi si rimuove il volume fisico e così può essere scollegato.

vgreduce vg_lab /dev/loop9
pvremove /dev/loop9

Verifichiamo che il volume fisico non sia più presente.

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                4
  Act PV                4

Procediamo allo stesso modo col secondo disco.

pvmove /dev/loop10
  /dev/loop10: Moved: 9,80%
  /dev/loop10: Moved: 17,65%
  /dev/loop10: Moved: 100,00%

vgreduce vg_lab /dev/loop10
  Removed "/dev/loop10" from volume group "vg_lab"

pvremove /dev/loop10
  Labels on physical volume "/dev/loop10" successfully wiped.

In conclusione possiamo vedere il gruppo di volumi con solo 3 dischi, gli altri due completamente disimpegnati col gruppo di volumi ricostituitosi attorno ai 3 dischi rimanenti. E tutto spostando semplicemente gli extents dove c'era disponibilità in maniera totalmente trasparente per il filesystem.

vgdisplay vg_lab |grep PV
  Max PV                0
  Cur PV                3
  Act PV                3


lsblk -o NAME,FSTYPE,SIZE,TYPE
  NAME               FSTYPE        SIZE      TYPE
  loop9                              1G      loop
  loop10                             1G      loop
  loop11             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_2               1000M      lvm
  └─vg_lab-lv_lab_3                860M      lvm
  loop12             LVM2_member     1G      loop
  └─vg_lab-lv_lab_1                1,2G      lvm
  loop13             LVM2_member     1G      loop
  ├─vg_lab-lv_lab_1                1,2G      lvm
  └─vg_lab-lv_lab_3                860M      lvm

4. Conclusione

Ho solo sfiorato la complessità e le capacità offerte da LVM.

L'estensione e la riduzione di volumi logici e di gruppi di volumi sono scenari di base. Tuttavia sono sufficienti per mostrare come sia semplice, con i volumi logici, compiere operazioni che con un filesystem partizionato in maniera classica sarebbero complicatissime.

#lvm #volumegroup #logicalvolume #filesystem #devicemapper

Come aumentare il volume di una traccia audio

Mon, 13 Apr 2026 15:03:39 +0000

Quando si deve aumentare il volume di una traccia audio, si deve ricorrere a ad un'operazione di “normalizzazione”.

1. Cos’è la normalizzazione
2. Come misurare il “picco”?
3. Come leggere correttamente questa misura
- 3.1. Perché usare il loudness invece di RMS?
4. Come ti normalizzo il file
- 4.1. Peak normalization
- 4.2. Loudness Normalization

1. Cos'è la normalizzazione

La normalizzazione è un'operazione lineare che consiste nell'analisi del file audio, nel calcolare la differenza (offset) fra il volume attuale ed un volume target, nell'applicare una correzione di guadagno (Gain).

La normalizzazione può essere distinta in base al “come” e al “dove”.

Il “come” La normalizzazione classica si basa sui picchi. Cerca il punto più alto della forma d'onda e lo porta a un valore massimo (es. 0 dB). Ignora la percezione umana; un brano con un singolo “click” molto forte risulterà comunque silenzioso perché quel picco blocca l'aumento del volume.

La normalizzazione più moderna si basa sui LUFS, ossia su come, mediamente, l'audio viene effettivamente percepito dall'orecchio umano (psicoacustica). Porta l'intero brano a un livello di pressione sonora media costante, rendendo l'ascolto uniforme tra diverse tracce.

Il “dove” Quando si normalizza una traccia audio si può scegliere di farla modificando ogni singolo sample della traccia audio oppure di agire sui metadati.

Nel primo caso il file originale viene modificato (ricodifica quasi sempre lossy), nel secondo viene lasciato inalterato.

Altro fattore di cui tenere conto è che una normalizzazione lossy funziona su ogni player, una normalizzazione che agisce sui metadati funziona solo se il player è in grado di leggerli.

Possiamo fare quindi una prima distinzione:

normalizzazione di picco (RMS) o Peak Normalization: applicazione di un guadagno statico (RMS) in modalità lossy: non altera la dinamica del brano, richiede una ricodifica;
normalizzazione della sonorità (LUFS) o Loudness Normalization:
1. applicazione di un guadagno statico (LUFS) in modalità lossy: non altera la dinamica del brano, richiede una ricodifica;
2. applicazione di un guadagno statico (LUFS) basato su tag: non altera la dinamica del brano, lascia il file inalterato (rsgain);
3. agisce con un compressore / limiter in modalità lossy: altera la dinamica del brano, richiede una ricodifica.

A questo punto la domanda diventa: quale scegliere?

Per quel che mi riguarda, la salomonica risposta è: dipende.

Come si può immaginare, non c'è una risposta definitiva ma dipende dalla qualità della traccia, dal contesto ecc.

2. Come misurare il “picco”?

C'è bisogno di un elemento misurabile che mi permetta di capire come agire con la normalizzazione.

RMS (Root Mean Square): è un calcolo matematico asciutto su quanto sia potente elettricamente/digitalmente il segnale audio. È utile per capire l'energia costante, ma non tiene conto del fatto che l'orecchio umano è più sensibile ad alcune frequenze rispetto ad altre.

LUFS (Loudness Units Full Scale): È lo standard moderno (EBU R128). Simula l'udito umano applicando dei filtri che pesano maggiormente le frequenze medie.

Per misurare il picco RMS posso ricorrere ad ffmpeg

ffmpeg -hide_banner -i "audio.m4a" -filter:a "volumedetect" -f null -
...
[...] n_samples: 18522112
[...] mean_volume: -20.3 dB
[...] max_volume: -5.4 dB
[...] histogram_5db: 40
[...] histogram_6db: 1436
[...] histogram_7db: 6443
[...] histogram_8db: 18606
...

che mi mostrerà:

il numero dei samples di cui si compone la traccia
il volume medio (mean_volume)
il picco (max_volume)

Il picco mi dice di quanto possa alzare il volume (fino al limite fisico di 0dB) staticamente senza causare distorsioni.

La differenza fra volume medio e picco mi dà informazioni sulla dinamica del brano. Maggiore è la differenza, maggiore è la dinamica. Tipicamente:

valori < 5 sono tipici della musica dance, forte, uniforme, e molto compressa.
valori fra 5 e 15 sono tipici di brani pop-rock, ben bilanciati
valori > 15 sono attribuibili a brani di musica classica, jazz, con una dinamica ricca.

Per misurare il loudness, sempre con ffmpeg:

ffmpeg -hide_banner -i "audio.m4a" -filter:a "ebur128=peak=true" -f null - 
...
 Integrated loudness:
    I:         -18.1 LUFS
    Threshold: -28.4 LUFS

  Loudness range:
    LRA:         4.1 LU
    Threshold: -38.3 LUFS
    LRA low:   -21.2 LUFS
    LRA high:  -17.1 LUFS

  True peak:
    Peak:       -5.4 dBFS

La misurazione è più articolata rispetto alla precedente.

FFmpeg innanzitutto mostra due sezioni: Integrated Loudness, rappresentante il volume medio complessivo del file e la Loudness Range che mi descrive la dinamica del brano come differenza di volume fra le parti più silenziose e quelle più rumorose.

Sezione Integrated loudness:
- I: è il valore più importante. È il volume medio percepito dell'intero brano (come si può vedere, diverso rispetto all'RMS di prima. Il primo è pura potenza digitale, il secondo è volume percepito).
- Threshold: è la soglia usata per evitare che i silenzi abbassino artificialmente la media del volume. L'algoritmo ignora tutto ciò che sta sotto questa soglia nel calcolo dell'Integrated Loudness.
Sezione Loudness range:
- LRA: è un indice della variazione dinamica del brano. Più è basso, più il suono tende ad essere uniforme e probabilmente compresso
- Threshold: come prima, è la soglia oltre la quale i suoni vengono ignorati nel calcolo del range dinamico.
- LRA Low: indica il limite inferiore del loudness
- LRA High: indica il limite superiore
  quindi LRA = LRA High – LRA Low
Sezione True peak:
- Peak: Simile al max_volume dell'RMS, indica il picco reale del brano in termini di sonorità.

Un altro modo, forse meno pratico ma decisamente più scenografico, per analizzare un file audio è questo:

ffplay -f lavfi -i "amovie=audio.m4a,ebur128=video=1:meter=18 [out0][out1]"

Disegna un grafico dell'onda sonora in tempo reale.

3. Come leggere correttamente questa misura

L'integrated loudness mi dice qual è il volume medio del brano. True peak mi dice di quanto posso alzare prima di distorcere. Queste sono le due informazioni cruciali sufficienti per applicare un guadagno statico senza fare danni.

I valori High e Low del Loudness Range, che racchiudono asintoticamente il brano, tornano utili quando bisogna agire sulla dinamica.

Notare che Integrated loudness è sempre compreso fra LRA Low e LRA High.

3.1. Perché usare il loudness invece di RMS?

L'RMS è un calcolo puramente matematico che non tiene conto del fatto che l'orecchio umano è molto più sensibile alle frequenze medie che non ai bassi estemi e agli acuti altissimi.

A questo provvede il LUFS che è un'evoluzione dell'RMS perché include dei filtri di ponderazione che, prima di calcolare la media, esaltano le frequenze medie attenuando quelle basse.

La conseguenza è che se agisco sul volume dei brani prendendo LUFS come riferimento, questi suoneranno tutti allo stesso volume. Se considerassi un adeguamento basato su RMS, i brani con più bassi sembreranno avere meno volume di quelli con frequenze medie più marcate.

4. Come ti normalizzo il file

La scelta fra una normalizzazione di picco e una di volume (loudness) è abbastanza semplice in realtà.

A parte poche eccezioni in cui può avere senso avere RMS come riferimento, è sempre preferibile una normalizzazione della sonorità.

Quest'ultima può essere fatta modificando solo i metadati o agendo chirurgicamente sul file ricodificandolo.

4.1. Peak normalization

Una volta noti i dati di Max Volume e Mean Volume visti in precedenza, la normalizzazione è piuttosto semplice.

Supponendo Max Volume = 6dB

ffmpeg -i audio.m4a -filter:a "volume=6dB" -c:a aac -b:a 192k audio_normalized.m4a

Dovendo ricodificare, scelgo un bitrate piuttosto alto per limitare la perdita fisiologica di una ricodifica lossy.

Come si può immaginare, è una aggiunta lineare secca a tutta la traccia a cui aumento solo la potenza digitale senza tenere conto della percezione sonora.

Piccola nota: Conviene scegliere un valore che si avvicini, ma non equivalga, al limite di 0 dB perché altrimenti FFmpeg taglierà brutalmente le creste dell'onda sonora che superano lo zero, creando quella tipica distorsione metallica grattata chiamata clipping.

4.2. Loudness Normalization

La normalizzazione di volume, in base alla nostra scelta di alterare o meno la dinamica del brano, può essere fatta come detto applicando:

un guadagno statico LUFS (lossy)
un guadagno statico LUFS sui metadati (non lossy)
compressore / limiter (sempre lossy)

Il guadagno statico, quello con i metadati, avverrà con rsgain.

La normalizzazione con perdita di qualità (lossy) avverrà con ffmpeg usando il filtro loudnorm che dispone di un compressore/limiter piuttosto efficace.

Questo filtro è un processore dinamico (dual-pass o single-pass). Non si limita ad alzare il volume; se trova una parte troppo forte, può comprimere leggermente solo quella parte per permettere al resto della canzone di suonare più forte.

loudnorm porta il loudness di default a -24 LUFS che è lo standard per il broadcast televisivo.

I colossi dello streaming applicano automaticamente un loudness decisamente più marcato, salvo poche eccezioni, non si discostano da -14 LUFS. Ad es. Youtube, Amazon Music, Spotify, Soundcloud viaggiano mediamente su -14 LUFS, Deezer -15, Apple Music -16.

Si può verificare facilmente, come sappiamo fare, come un audio presente su una di queste piattaforme, abbia uno dei loudness indicati.

4.2.1. Loudness Normalization statica (ffmpeg)

Riprendiamo l'esempio di prima.

ffmpeg -hide_banner -i "audio.m4a" -filter:a "ebur128=peak=true" -f null - 
...
 Integrated loudness:
    I:         -18.1 LUFS
    Threshold: -28.4 LUFS

  Loudness range:
    LRA:         4.1 LU
    Threshold: -38.3 LUFS
    LRA low:   -21.2 LUFS
    LRA high:  -17.1 LUFS

  True peak:
    Peak:       -5.4 dBFS

Con ffmpeg e loudnorm in modalità single-pass, posso applicare un guadagno statico 5.4 dBFS, con un true peak di -1 (Il default è -2), per arrivare, da -18.1 LUFS, a -13.0 LUFS senza distorsioni.

ffmpeg -i audio.m4a -filter:a "loudnorm=I=-12.7:TP=-1.0" -c:a aac -b:a 160k -vn audio_norm.m4a

Verifichiamo:

ffmpeg -hide_banner -i "audio.m4a" -filter:a "ebur128=peak=true" -f null - 
...
   Integrated loudness:
    I:         -12.5 LUFS
    Threshold: -22.6 LUFS

  Loudness range:
    LRA:         4.0 LU
    Threshold: -32.6 LUFS
    LRA low:   -15.1 LUFS
    LRA high:  -11.1 LUFS

  True peak:
    Peak:       -0.4 dBFS
...

Come si vede, sono arrivato al limite, forse un po' troppo, del guadagno che potevo ottenere. Probabimente su dispositivi economici, l'analogico di un brano così potrebbe gracchiare un po'.

Se avessi applicato il default di loudnorm, la sonorità sarebbe stata livellata sui -24 LUFS con una soglia true peak pari a -2 dBFS.

4.2.2. Loudness Normalization dinamica

Nei casi in cui:

si vuole enfatizzare l'audio di un podcast, di un parlato in generale;
la dinamica del brano è composta da picchi altissimi e una sonorità media molto bassa (un guadagno statico farebbe cambiare poco o nulla)

con ffmpeg e loudnorm possiamo correggere ogni singolo sample del brano per rendere la dinamica più uniforme.

Per ottenere un risultato ottimale, si deve procedere col dual-pass, in cui ffmpeg nel primo passaggio analizza il file e raccoglie i dati, nel secondo passaggio applica le correzioni puntualmente avendo già conoscenza della dinamica e dei picchi presenti nel file.

ffmpeg -i "audio.m4a" -filter:a "loudnorm=I=-14:TP=-1.0:print_format=json" -f null -

Ecco il json risultante dall'analisi. I valori di input sono quelli che forniremo a ffmepg affinché possa impostare il loudness scelto da noi nel miglior modo possibile

{
	"input_i" : "-18.17",
	"input_tp" : "-5.41",
	"input_lra" : "4.20",
	"input_thresh" : "-28.47",
	"output_i" : "-13.36",
	"output_tp" : "-1.00",
	"output_lra" : "4.30",
	"output_thresh" : "-23.50",
	"normalization_type" : "dynamic",
	"target_offset" : "-0.64"
}

Configurazione ffmpeg.

ffmpeg -i "audio.m4a" -filter:a "loudnorm=I=-14:TP=-1.0:measured_I=-18.17:measured_TP=-5.41:measured_LRA=4.20:measured_thresh=-23.50:linear=true" -c:a aac -b:a 160k -vn "audio_norm.m4a"

Il compressore/limiter del filtro loudnorm è abbastanza intelligente da schiacciare i picchi affinche il guadagno di volume non produca clipping e alzerà le parti più “deboli”, livellando il suono e alterando la dinamica.

4.2.3. Loudness Normalization statica (rsgain)

Rsgain permette di applicare un guadagno statico loseless, senza ricodifica, agendo sui metadati del brano con l'applicazione dei tag.

Se da un lato questo metodo ha l'indubbio vantaggio di non alterare fisicamente il file, dall'altro è necessario che il player che eseguirà il brano dovra essere capace di leggere e interpretare i tag. Nel caso precedente, la ricodifica rende il file disponibile per chiunque.

Trattandosi di un guadagno statico, il campo d'applicazione è quello visto per la Peak Normalization, cioè quando si vuole preservare la dinamica del brano, Ma nei casi particolari cui accennavo in precedenza, presenza di picchi altissimi e maggioranza sonorità medie molto basse, anche rsgain non è sufficiente.

Come avevo detto all'inizio, rsgain è una normalizzaziome della sonorità ottenuta agendo sui metadati del brano, applicando dei tag, che così non viene alternato in alcun modo.

Rsgain è l'evoluzione del vecchio mp3gain e come il suo predecessore ha due modalità di lavoro

sul singolo brano (detta é custom)
su collezioni di brani (detta easy)

La modalità custom è considerato un approccio legacy fatta per intervenire puntualmente sul brano con configurazioni ad-hoc ideali per lo scripting, quella easy, basata su presets, permette di normalizzare intere collezioni di brani che è lo scopo principale di rsgain.

Analisi del file

rsgain custom -t audio.m4a
[✔] Scanning 'audio.m4a'
[✔] Container: QuickTime / MOV [mov,mp4,m4a,3gp,3g2,mj2]
[✔] Stream #0: AAC (Advanced Audio Coding), 44.100 Hz, 2 ch
 100% [====================================================]

Track: audio.m4a
  Loudness:   -18.12 LUFS
  Peak:     0.536630 (-5.41 dB)
  Gain:         0.12 dB

il flag -t individua il true peak

Loudness: è la sonorità del brano in LUFS
Peak: è il true peak, esprime il guadagno che posso ottenere prima di distorcere
Gain: è il guadagno per arrivare allo standard LUFS di rsgain che è -18

Nel nostro caso, Gain ci dice di diminuire di 0.12 LUFS mentre Peak ci dice che potrei aumentare di 5.41 LUFS

Gain

rsgain custom -s i -l -13 -c p audio.m4a
Track: audio.m4a
  Loudness:   -18.12 LUFS
  Peak:     0.534149 (-5.45 dB)
  Gain:         5.12 dB

-s i: scrive il tag
-l -13: imposta il loudness
-c p: protezione clipping

Portando il loudness a -13 è come se avessi aumentato il volume di 5,12 dB mantenendo un cuscinetto di -0.33 dB (differenza fra peak e gain).

Se provassi a spingere di più, il flag -c p impedisce al suono di distorcere.

rsgain custom -s i -l -10 -c p audio.m4a
Track: audio.m4a
  Loudness:   -18.12 LUFS
  Peak:     0.534149 (-5.45 dB)
  Gain:         5.45 dB  (adjusted to prevent clipping)

“(adjusted to prevent clipping)” è la conferma che la protezione anti-clipping è entrata in azione.

Se non ci fosse stata:

rsgain custom -s i -l -10 audio.m4a
Track: audio.m4a
  Loudness:   -18.12 LUFS
  Peak:     0.534149 (-5.45 dB)
  Gain:         8.12 dB

La differenza fra peak e gain indica un'evidente distorsione.

Esempio di esecuzione del brano sfruttando il replaygain:

mpv --replaygain=track audio.m4a

Senza il flag --replaygain=track, il brano verrebbe letto normalmente.

Cancellazione del tag Basta cancellare il tag per riportare tutto alla normalità

# verifico la presenza del tag prima
ffprobe -hide_banner -i "audio.m4a" 2>&1 | grep -i "replaygain"
REPLAYGAIN_TRACK_GAIN: 8.12 dB
REPLAYGAIN_TRACK_PEAK: 0.534149
replaygain: track gain - 8.120000, track peak - 0.000012, album gain - unknown, album peak - unknown,

# cancello il tag
rsgain custom -s d audio.m4a

# verifico che il tag non si ci sia più
ffprobe -hide_banner -i "audio.m4a" 2>&1 | grep -i "replaygain"
**

Un altro modo più compatto per verificare la presenza del tag:

ffprobe -i "audio.m4a" -show_entries format_tags=REPLAYGAIN_TRACK_GAIN -v quiet -of csv="p=0"

Se c'è il tag, mostra solo il gain.

Easy mode I flag impostati nella modalità custom nella modalitò easy sono affidati ad un file di configurazione.

Su Gnu/Linux i file di default si trovano in /usr/share/rsgain/presets e sono 4

default.ini
ebur128.ini
loudgain.ini
no_album.ini

C'è una sezione globla e delle sezioni specifiche per tipo di file.

L'override di queste configurazioni o la creazione di nuove, si fa in:

~/.config/rsgain/presets

e per la corrispondenza campi – flag custom vi rimando alla documentazione: https://github.com/complexlogic/rsgain?tab=readme-ov-file#scan-presets

Una volta deciso il preset che fa per noi, basta chiamare rsgain su una directory in questo modo:

rsgain easy -s

rsgain farà la scansione e applicherà massivamente le configurazioni che potranno consistere per es.:

nell'applicazione di un loudness a tutti i brani per uniformare la sonorità;
nella cancellazione di tutti i tag;
nell'analisi dei brani;
ecc.

Esempio di file di configurazione per una scansione

[Global]
TagMode=s
Album=true
TargetLoudness=-18
ClipMode=p
MaxPeakLevel=-1.0
TruePeak=true
Lowercase=false
ID3v2Version=keep
OpusMode=d
PreserveMtimes=false
DualMono=false

In questo modo rsgain produrrà un'analisi in modalità “album” per tutta la collezione, il gain da applicare all'album e una sintesi sulla media dei valori di picco ottenuti.

rsgain easy -p scan  
...
Track: /track_1
  Loudness:   -17.80 LUFS
  Peak:     0.743221 (-2.58 dB)
  Gain:        -0.20 dB


Track: /track_2
  Loudness:   -17.81 LUFS
  Peak:     0.790007 (-2.05 dB)
  Gain:        -0.19 dB


Track: /track_3
  Loudness:   -17.47 LUFS
  Peak:     0.834655 (-1.57 dB)
  Gain:        -0.53 dB

...

Album:
  Loudness:   -16.51 LUFS
  Peak:     0.991804 (-0.07 dB)
  Gain:        -1.49 dB


Scanning Complete
Time Elapsed:      00:00:27
Files Scanned:     18
Clip Adjustments:  0 (0.0% of files)
Average Loudness:  -16.61 LUFS
Average Gain:      -1.39 dB
Average Peak:      0.823503 (-1.69 dB)
Negative Gains:    16 (88.9% of files)
Positive Gains:    2 (11.1% of files)

L'ultima sezione, “Album”, mi dà le informazioni sul guadagno da applicare, in questo caso poco o nulla perché sono brani già normalizzati,.

Con un altro presets, ad es. myGain.ini, posso normalizzare tutto l'album in colpo solo.

rsgain easy -p myGain

In altre parole, tutto ciò che la modalità custom affida allo scripting, ora viene automatizzata dalla modalità easy.

Riferimenti:

https://ffmpeg.org/ffmpeg-filters.html#loudnorm

https://ffmpeg.org/ffmpeg-filters.html#toc-volumedetect

https://github.com/complexlogic/rsgain

#ffmpeg #rsgain #loudness #loudnorm

Installazione di Cloudflare WARP su OSMC

Fri, 03 Apr 2026 22:33:32 +0000

È noto come l'uso dei resolver Cloudflare sia uno dei modi per anonimizzare il proprio IP all'ISP.

Cloudflare offre anche altre modalità di risoluzione ancora più efficaci:

DNS over HTTPS (DoH)
DNS over TCP (DoT)
DNS over WARP (DoW)

I primi due sono relativi a richieste dns crittografate e incapsulate, in una richiesta https (porta 443) la prima, e in una connessione TLS (porta 853) la seconda.

La terza modalità è una richiesta dns in chiaro ma all'interno di un tunnel Wireguard o MASQUE (QUIC + HTTP/3 – rif. https://datatracker.ietf.org/meeting/interim-2021-masque-03/materials/slides-interim-2021-masque-03-sessa-masque-interim-2021-04-h3-dgram-00). Molto interessante ed è quella che approfondirò in seguito.

Senza entrare nel merito, tutte le soluzioni anonimizzano le query dns. L'ultima, quella che mi ha stutzzicato, è in realtà un tunnel vpn che crittografa TUTTO il traffico, non solo le richieste DNS.

DoT è una cifratura TLS che lascia intatto il pacchetto UDP iniziale, è quindi più efficiente di DoH che converte una richieste DNS in una HTTP cifrata dal layer TLS.

DoT di solito viene fatta a livello di dispositivo, DoH per singole applicazioni.

DoT, basandosi su una porta specifica, 853, è facilmente identificabile (e bloccabile) come traffico DNS (benché cifrato), DoH è una richiesta HTTPS e si mescola col traffico che viaggia sulla porta 443 (difficilmente si invaliderà tutto quel tipo di traffico).

DoT, DoH, DoW, mitigano notevolmente il cache poisoning dei resolver perché rendono quasi impossibilie per un attaccante alterare una richiesta che viene protetta per l'intero percorso. Va detto che la soluzione ideale in questo contesto è la combinazione con DNSSEC, che fornisce autenticità e integrità alla riservatezza fornita da DoH/DoT.

Anche se l'obiettivo rimane l'approfondimento di CLoudflare WARP, vale la pena di spendere due parole anche sulle altre modalità di risoluzione, DoT/DoH

Configurare risoluzioni DNS DoH

Configurare DoH è molto semplice perché è qualcosa legato all'applicazione, il browser tipicamente. Se l'applicazione lo supporta, di solito è poco di più di un flag da abilitare.

Ad es. Firefox o Chrome permettono di attivare una sorte di “protezione avanzata del DNS” indicando semplicemente un resolver che la supporti (es. Cloudflare, NextDNS o Quad9).

Configurare risoluzioni DNS DoT

DoT, come detto, è una configurazione che avviene a livello di dispositivo, l'anonimizzazione delle query DNS si ottiene quindi per ogni applicazione. Sul come farlo, dipende dal dispositivo.

Ad es. su una linux box basta aggiungere due righe su systemd-resolved e riavviare il relativo servizio.

sudo vi /etc/systemd/resolved.conf
...
DNS=1.1.1.1
DNSOverTLS=yes

# dopo aver salvato il file
systemctl restart systemd-resolved

Un veloce test su https://1.1.1.1/help (da qualunque browser) ci mostrerà qualcosa del tipo:

Connected to 1.1.1.1        Yes
Using DNS over HTTPS (DoH)  No
Using DNS over TLS (DoT)    Yes
Using DNS over WARP         No
AS Name                     Cloudflare, Inc.
AS Number                   13335
Cloudflare Data Center      MXP

indice che DoT è attivo e funzionante. Lo stesso test poteva essere fatto anche per DoH.

Cloudflare WARP

E poi c'è DoW, che è qualcosa di ancora più estremo perché, all'occorrenza, anonimizza non solo le richieste DNS ma tutto il nostro traffico (e infatti diversi servizi di streaming non lo consentono).

Cloudflare Warp attiva diverse modalità di risoluzione dns fra cui DoH e DoT.

Dal momento che Cloudflare Warp agisce su tutta la connessione, è il modo più semplice per avere risoluzione dns di tipo DoH o DoT, su qualunque dispositivo su cui è presente Cloudflare Warp senza gli sbattimenti di systemd o altro.

Cloudflare Warp in modalità tunnel è un client che instaura un collegamento cifrato punto-punto (un tunnel) fra il nostro host e un endpoint Cloudflare. In questo modo ogni bit che esce dal nostro dispositivo viene cifrato prima della comunicazione, che diventa così totalmente schermata.

La vpn di Coudflare si basa su wireguard o su MASQUE. Nel primo caso è una normale vpn con un setup roadwarrior, il secondo caso offre in più la possibilità di associare al tunnel anche le modalità DoH/DoT per le richieste dns.

Anonimato sì/no?

Cloudflare WARP è uno strumento incentrato sulla sicurezza, progettato per crittografare il traffico internet e proteggere la privacy dagli ISP, piuttosto che per garantire l'anonimato completo o nascondere la posizione dell'utente.

Sostituisce l'IP dell'utente con un IP di Cloudflare che generalmente corrisponde alla sua reale area geografica, rendendolo inadatto a eludere le restrizioni basate sulla posizione.

Non è una VPN tradizionale. WARP non maschera la nostra posizione ai siti web, che spesso possono visualizzare la tua posizione approssimativa.

Per migliorare la privacy, si dovrebbe utilizzare il protocollo MASQUE, che offre anche una maggiore efficienza.

In sintesi, WARP fornisce un “tunnel sicuro” per proteggere la privacy dei dati da amministratori di rete indiscreti, protegge il traffico perché eccelle nella crittografia del traffico su reti non sicure (ad esempio, Wi-Fi pubbliche), ma non offre le funzionalità di anonimato dei tradizionali servizi VPN incentrati sulla privacy.

Fatta questa doverosa premessa, vediamo come può essere usato.

Configurare Cloudflare WARP

L'installazione del client è molto semplice. Per Gnu/Linux c'è la versione cli, per android un app, per altri sistemi, Win /MacOS, un installer. La parte applicativa prima di tutto registra il dispositivo sulla rete Cloudflare generando degli ID e una chiave di licenza. In un secondo momento si generano le chiavi di cifratura.

Per fissare le idee, una volta fatte le operazioni di inizializzazione, sulla linux box per tunnellizzare ogni nostra comunicazione con una risoluzione DoT, basta:

# facoltativo
warp-cli mode warp+dot

#connessione
warp-cli connect

Per terminare:

warp-cli disconnect

Questo approccio torna molto comodo quando per es. vogliamo usare wifi pubbliche, in città o in aeroporto. A meno di non avere un'installazione personale di una nostra vpn, questa è una soluzione immediata. Certo, bisogna fidarsi di Cloudflare ma è certamente meglio che fidarsi delle wifi free.

E arriviamo al caso d'uso che volevo approfondire riguardante l'“anonimizzazione” di un mediacenter casalingo per il quale non vogliamo rendere noto il suo utilizzo.

L'esperienza che ho avuto al proposito è stata interessante, visto che uso da anni OSMC su una RasbPi 3 e ho deciso di metterla dietro Cloudflare.

OSMC insieme a LibreELEC sono ottime soluzioni di mediacenter per SBC. La prima più “general”, essendo una debian customizzata per ospitare un mediacenter, la seconda invece meno elastica ma più essenziale ed efficiente.

Nonostante la Raspberry Pi 3 sia dotata di un processore ARM64, la versione di OSMC che ho installato a suo tempo è a 32 bit e per quella non c'è disponibilità per il client cloudflare (solo ARM64).

Ho dovuto ricorrere ad un client “unofficial”, wgcf, che permette di registrare il dispositivo e di generare le chiavi ma solo per la modalità Wireguard, non MASQUE, quindi niente Warp+DoT/DoH (per inciso, wgcf rappresenta un'ottima alternativa anche per chi non vuole usare il client Cloudflare su Gnu/Linux).

A questo aggiungo che, sebbebe OSMC sia una Debian su cui posso installare e configurare tanta roba, l'installazione di Wireguard, e penso di qualunque cosa che vada a toccare lo stack di rete, diventa qualcosa di estremamente complicato da fare, dal momento che OSMC si rifiuta categoricamente di eseguire operazione che metterebbero a rischio il suo essere un mediacenter, fondamentalmente.

Tradotto in soldoni, il client wireguard si installa, sale su correttamente ma non c'è verso di far funzionare la risoluzione. L'unica via d'usicta è stata configurare Wireguard attraverso il gestore di rete di OSMC che è connman.

Una volta fatto questo, sono stati necessari solo un paio di piccoli accorgimenti per far si che, in seguito all'avvio del mediacenter, la configurazione vpn venisse caricata automaticamente da connman, contestualmente alla connessione vpn.

Configurazione wgcf

# Account cloudflare
curl -L https://github.com/ViRb3/wgcf/releases/latest/download/wgcf_2.2.30_linux_armv7 -o /usr/local/bin/wgcf
chmod u+x /usr/local/bin/wgcf
wgcf register
wgcf generate

# status & trace
wgcf status
curl https://www.cloudflare.com/cdn-cgi/trace

Configurazione connman

Su OSMC connman ha i suoi file di configurazione in /var/lib/connman e /var/lib/connman-vpn

Nel file di configurazione, l'host va indicato con l'ip non con l'fqdn (engage.cloudflareclients.com)

# Configurazione wireguard cloudflare
# La configurazione della vpn deve essere un file .config sotto /var/lib/connman-vpn

vi /var/lib/connman-vpn/cloudflare_warp.config
[provider_*]
Type = WireGuard
Name = Cloudflare_WARP
Host = 162.159.192.1
AutoConnect = true
WireGuard.Address = 172.16.0.2/24
WireGuard.ListenPort = 51280
WireGuard.PrivateKey = 
WireGuard.PublicKey = 
WireGuard.DNS = 1.1.1.1, 1.0.0.1
WireGuard.AllowedIPs = 0.0.0.0/0
WireGuard.EndpointPort = 2408
WireGuard.PersistentKeepalive = 25

Dopo aver creato il file di configurazione, possiamo vedere il nuovo servizio pronto per essere richiamato da comman-vpnd

# elenco servizi attivi
connmanctl services
* AO            wifi__managed_psk
* R Cloudflare_WARP      vpn_162_159_192_1

Affinché la connessione alla vpn parta all'avvio di OSMC, è necessario disporre di un servizio che:

esegua common-vpnd per caricare il file di configurazione
effettui la connessione vpn

# Creazione nuovo servizio in /lib/systemd/system/connman-vpn.service
[Unit]
Description=ConnMan VPN service
After=network-online.target
Wants=network-online.target

[Service]
Type=dbus
BusName=net.connman.vpn
ExecStart=/usr/sbin/connman-vpnd -n
ExecStop=/usr/local/bin/vpn-autoconnect.sh
StandardOutput=null
Restart=on-failure

[Install]
WantedBy=multi-user.target

Script richiamato dal servizio per la connessione alla vpn:

# connessione vpn
vi /usr/local/bin/vpn-autoconnect.sh
#!/bin/bash
# Attende che il demone VPN sia pronto
sleep 5
# Tenta la connessione (usa il nome esatto che vedi in connmanctl services)
connmanctl connect vpn_162_159_192_1

Inifine si rende il file eseguibile e si avvia il servizio

chmod +x /usr/local/bin/vpn-autoconnect.sh

# avvio servizio
systemctl daemon-reload
systemctl enable connman-vpn.service
systemctl start connman-vpn.service

E il gioco è fatto.

Da questo momento in poi, OSMC tunnellizza tutto il suo traffico verso Cloudflare.

Come detto, in questo modo ho “solo” la configurazione di un tunnel wireguard verso l'endpoint Cloudflare, non dispongo delle altre funzionalità che warp-cli offre.

Tuttavia è un procedimento abbastanza trasparente che non prevede la convivenza con ulteriori servizi come nel caso di warp-cli e che può essere un'alternativa anonimizzante valida anche su una linux box normale.

#dns #doh #dot #warp #vpn #tunnel #cloudflare #wireguard #masque #osmc

Device Mapper: LUKS + LVM

Mon, 23 Feb 2026 10:58:17 +0000

(segue da “Cenni sulla creazione di pool di storage con LVM“) ...anche se è la base per una serie di sviluppi interessanti.

Come ormai sappiamo, device mapper è il framework del kernel Linux col quale mappare dispositivi a blocchi fisici su dispositivi a blocchi logici, che costituisce la base per fornire funzionalità ulteriori quali:

volumi logici
raid
cifratura (Full Disk Encryption)
snapshot di volumi

Scenario 1

È molto comune per es. cifrare l'intero disco e “affettarlo” con volumi logici in base alle proprie esigenze di partizionamento .

Il doppio vantaggio è dato da:

offuscamento totale dello schema di partizionamento
estrema versatilità / flessibilità del partizionamento grazie ai volumi logici

Come si agisce?

si cifra il dispositivo fisico
si crea un gruppo di volumi avente come volume fisico il volume cifrato
si creano i volumi logici in base allo schema di partizionamento desiderato.

Passo 1 – Inizializzazione

Simulo il mio dispositivo fisico ricorrendo ai loop device.

Il “disco” avrà una grandezza simbolica di 2 GiB, non avrà header detachable. L'algoritmo di hash sarà sha512 e la chiave sarà da 512 bit. Il resto è il default di luks2 (argon2id come pbkdf, per maggiori dettagli vedi cryptsetup --help)

# 1. Preparazione disco "fisico"
fallocate -l 2g cipher_disk.img

# 2. loop device che simula l'attach del dispositivo
DEV=$(losetup -Pf --show cipher_disk.img)

# 3. Inizializzazione cifratura
cryptsetup luksFormat  \
    --type luks2 \
    --hash sha512 \
    --key-size 512 \
    $DEV

Passo 2

Il passo successivo consiste nell'apertura del dispositivo cifrato e nella definizione dello schema di partizionamento in volumi logici

# 1. apertura del disco cifrato
cryptsetup open \
    --type luks2 \
    $DEV cipher_disk

Nell'apertura, device mapper fa la sua prima magia.

Infatti, se osserviamo lo stato dei dispositivi, vedremo una situazione simile:

lsblk
...
loop9                7:9    Kib0     2G  0 loop  
└─cipher_disk      252:3    0     2G  0 crypt 
...

Cio vuol dire che sopra il dispositivo fisico, /dev/loop9in questo caso, device mapper ha “poggiato” cipher_disk (/dev/mapper/cipher_disk).

Questo sarà il nostro volume fisico per definire gruppi di volume e, conseguentemente, i volumi logici.

# 2. creazione gruppo di volumi
vgcreate vg_lab /dev/mapper/cipher_disk

# 3. creazione volumi logici
lvcreate -n lv_lab_1 vg_lab -L 700M
lvcreate -n lv_lab_2 vg_lab -L 600M
lvcreate -n lv_lab_3 vg_lab -l 100%FREE

La situazione dei dispositivi è ora questa:

lsblk
...
loop9                7:9    0     2G  0 loop  
└─cipher_disk      252:3    0     2G  0 crypt
  ├─vg_lab-lv_lab_1 252:4    0   700M  0 lvm
  ├─vg_lab-lv_lab_2 252:5    0   600M  0 lvm
  └─vg_lab-lv_lab_3 252:6    0   728M  0 lvm
...

Sopra /dev/loop9 c'è cipher_disk (/dev/mapper/cipher_disk) e sopra di esso, i 3 volumi logici

lv_lab_1 (/dev/mapper/vg_lab-lv_lab_1)
lv_lab_2 (/dev/mapper/vg_lab-lv_lab_2)
lv_lab_3 (/dev/mapper/vg_lab-lv_lab_3)

Formatto e monto i volumi logici

# 4. formattazione dei 3 volumi logici
mkfs.ext4 /dev/mapper/vg_lab-lv_lab_1
mkfs.ext4 /dev/mapper/vg_lab-lv_lab_2
mkfs.ext4 /dev/mapper/vg_lab-lv_lab_3

# 5. creo e preparo i punti di mmontaggio
mkdir disk_1 disk_2 disk_3
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_1 disk_1
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_2 disk_2
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_3 disk_3
chown $USER disk_1 disk_2 disk_3

# 6. unmount di tutti i dispositivi
umount disk_1 disk_2 disk_3
vgchange -an vg_lab
cryptsetup close cipher_disk
losetup -d $DEV

Passo 3

Infine, per completezza, gli script di mount e unmount del dispositivo. mount

# 1. attach del dispositivo
DEV=$(losetup -Pf --show cipher_disk.img)

# 2. Apre il disco cifrato 
cryptsetup open \
    --type luks2 \
    $DEV cipher_disk

# 3. monta il gruppo di volume
# (opzionale. L'apertura del disco cifrato dovrebbe montare 
# automaticamente il gruppo di volumi)
vgchange -ay vg_lab

# 4. monta i volumi logici
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_1 disk_1
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_2 disk_2
mount -t ext4 -o user,noauto,rw  /dev/mapper/vg_lab-lv_lab_3 disk_3

unmount

# 1. smonta i 3 dischi
umount disk_1 disk_2 disk_3

# 2. smonta il gruppo di volumi
vgchange -an vg_lab

# 3. chiude il disco cifrato
cryptsetup close cipher_disk

# 4. "stacca" il dispositivo fisico
losetup -d $DEV

Questo è ciò che si farebbe normalmente quando si vuole il full disk encryption sul proprio pc. Ma con una piccola eccezione.

In realtà ciò che viene cifrata è una partizione quasi completa del disco, perché almeno una piccola partizione, quella contenente il boot, /BOOT, deve essere in chiaro per consentire:

a UEFI di avviare GRUB che conosce le partizioni,
GRUB provvederà all'avvio del kernel,
l'avvio del kernel con initramfs chiederà la password per sbloccare la partizione cifrata.

La cifratura totale (che proprio totale non sarà perché /boot/efi deve rimanere in chiaro) eleva di molto la complessità del setup iniziale.

Affidare a GRUB la gestione della cifratura potrebbe voler dire, oltre alla complessità della configurazione iniziale che dovrà far ricorso a moduli come cryptodisk, che bisognerà rinunciare ad Argon2 perché GRUB ancora non lo supporta pienamente e, a differenza del kernel, non ha sufficiente potenza per farlo lavorare come si deve.

Un buon compromesso potrebbe essere il ricorso ad un dispositivo esterno, es. una pendrive, che contenga tutta la partizione /boot in chiaro, anche l'header del disco cifrato. GRUB dovrà solo sapere dove si trovi il boot, il resto dell'avvio viene affidato come di consueto al kernel.

Scenario 2

Rimanendo nell'ambito dell'esplorazione di device mapper e della cifratura di dispositivi esterni non avviabili, immaginiamo qualcosa di più estremo.

Supponiamo di dover custodire un segreto in qualcosa che non sia un semplice vault cifrato.

Per diminuire il rischio di compromettere un unico vault, decido di dividerlo in varie parti, come gli horcrux ma con 0 malignità. Ogni parte sarà cifrata con una sua chiave che affiderò ad una persona diversa, di mia fiducia. Solo io, titolare ultimo del segreto, avrò accesso ai dati e solo la mia chiave (come l'Anello che li domina tutti) aprirà il vault.

Supponiamo di avere 3 dispositivi fisici (che nel laboratoro saranno simulati da loop device come al solito) per altrettanti “custodi”, ognuno dei quali verrà cifrato con la chiave e con dei parametri da consegnare al “custode” specifico.

I 3 dispositivi cifrati costituiranno un gruppo di volumi con un volume logico (dai requisiti posti non c'è necessità di sfruttare la flessibilità di partizionamento dei volumi logici) che verrà cifrato con la mia chiave master.

Ogni dispositivo, volume logico finale compreso, prima della cifratura, verrà inizializzato con del rumore casuale. Questo per impedire ad un'analisi forense di risalire ad un qualunque pattern sul dispositivo raw.

Caratteristiche di ogni cifratura:

dispositivi inizializzati con rumore casuale
header detachable
offset custom
key-file
default di argon2id (controlla il tuo default con cryptsetup benchmark)

Quando vorrò aprire il vault, sarà necessario che i 3 “custodi” aprano il loro “pezzo” e solo io potrò ricostruire e decifrare il volume con la mia chiave.

L'inzializzazione con rumore casuale dei dispositivo, tralasciando l'uso di dd su /dev/urandom che sappiamo essere CPU-intensive, può essere fatta ricorrendo:

ad openssl rand, come sappiamo da “Come generare una password o un keyfile sicuri (Trilogia Della Password – 1 di 3“
oppure usando furbescamente cryptsetup, con cui apriamo il dispositivo in modalità plain, senza header, e riempiendolo di zeri (da /dev/zero con dd) che, attraversando il motore di cifratura, verranno scritti sul dispositivo come dati casuali ad alta velocità.

################################
# Emulazione dei device fisici #
################################
fallocate -l 512M cipher_disk_1.img
fallocate -l 512M cipher_disk_2.img
fallocate -l 512M cipher_disk_3.img



###########################
# creazione dei 3 keyfile #
###########################
# keyfile del custode n° 1
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o cipher_disk_1.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

# keyfile del custode n° 2
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o cipher_disk_2.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

# keyfile del custode n° 3
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o cipher_disk_3.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -

# keyfile master
dd if=/dev/urandom bs=1024 count=4 | \
    gpg --yes -o master.key.gpg -c \
        --s2k-mode 3 \
        --s2k-count 32505856 \
        --s2k-cipher-algo aes256 \
        --s2k-digest-algo sha512 \
        --force-mdc -



##########################
# cifratura dei 3 device #
##########################
# attach dispositivo
DEV_1=$(losetup -Pf --show cipher_disk_1.img)

# inizializzazione dev_1 con rumore casuale
cryptsetup open --type plain ${DEV_1} container --key-file /dev/urandom
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# cifratura dispositivo n° 1
gpg -d cipher_disk_1.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_1.img \
        --offset 32768 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        ${DEV_1}

# attach dispositivo
DEV_2=$(losetup -Pf --show cipher_disk_2.img)

# inizializzazione dev_2 con rumore casuale
cryptsetup open --type plain ${DEV_2} container --key-file /dev/urandom
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# cifratura dispositivo n° 2
gpg -d cipher_disk_2.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_2.img \
        --offset 36864 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        ${DEV_2}

# attach dispositivo
DEV_3=$(losetup -Pf --show cipher_disk_3.img)

# inizializzazione dev_3 con rumore casuale
cryptsetup open --type plain ${DEV_3} container --key-file /dev/urandom
dd if=/dev/zero of=/dev/mapper/container status=progress
cryptsetup close container

# cifratura dispositivo n° 3
gpg -d cipher_disk_3.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_3.img \
        --offset 40960 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        ${DEV_3}



##############################
# Creazione gruppo di volumi #
##############################
# "apro" il volume 1
gpg -d cipher_disk_1.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_1.img \
         --key-file - \
         ${DEV_1} cipher_disk_1

# "apro" il volume 2
gpg -d cipher_disk_2.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_2.img \
         --key-file - \
         ${DEV_2} cipher_disk_2

# "apro" il volume 3
gpg -d cipher_disk_3.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_3.img \
         --key-file - \
         ${DEV_3} cipher_disk_3

# Creo il mio gruppo di volumi con i 3 volumi "fisici":
# 1. /dev/mapper/cipher_disk_1
# 2. /dev/mapper/cipher_disk_2
# 3. /dev/mapper/cipher_disk_3
vgcreate vg_master /dev/mapper/cipher_disk_1  /dev/mapper/cipher_disk_2  /dev/mapper/cipher_disk_3

# creazione dell'unico volume logico
lvcreate -n lv_master vg_master -l 100%FREE



################################
# cifratura e mount del master #
################################
# cifratura dispositivo master
dd if=/dev/urandom of=/dev/mapper/vg_master-lv_master bs=1M count=32 status=progress
gpg -d master.key.gpg | \
    cryptsetup luksFormat  \
        --type luks2 \
        --key-file - \
        --header header_master.img \
		--offset 65536 \
        --hash sha512 \
        --key-size 512 \
        --cipher aes-xts-plain64 \
        /dev/mapper/vg_master-lv_master

# apriamo il dispositivo master
gpg -d master.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_master.img \
         --key-file - \
         /dev/mapper/vg_master-lv_master cipher_disk_master

# e finalmente lo formattiamo
mkfs.ext4 /dev/mapper/cipher_disk_master

# Test: montiamo il disco
mkdir -p /run/media/master/disk_master
chown -R ${USER}:${USER} /run/media/master/disk_master
mount -t auto /dev/mapper/cipher_disk_master /run/media/master/disk_master

# Infine chiudiamo tutto
umount /run/media/master/disk_master
cryptsetup close cipher_disk_master
vgchange -an vg_master
cryptsetup close cipher_disk_1
cryptsetup close cipher_disk_2
cryptsetup close cipher_disk_3
losetup -d ${DEV_1} ${DEV_2} ${DEV_3}

Dopo aver appurato che tutto funzioni, consegno ad ogni “custode” dispositivo, keyfile e header.

Se un attaccante dovesse entrare in possesso di uno o più dispositivi, troverebbe solo un mucchio di dati incomprensibili.

Posto che riuscisse a decifrare il dispositivo, troverebbe un pezzo di un gruppo di volumi, cifrato e inutilizzabile.

Il master a questo punto non dovrà fare altro che aprire e chiudere il vault, dopo aver riunito tutti i pezzi, come segue:

Apertura del vault

# Attach dei dispositivi
DEV_1=$(losetup -Pf --show cipher_disk_1.img)
DEV_2=$(losetup -Pf --show cipher_disk_2.img)
DEV_3=$(losetup -Pf --show cipher_disk_3.img)

# "apro" il volume 1
gpg -d cipher_disk_1.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_1.img \
         --key-file - \
         ${DEV_1} cipher_disk_1

# "apro" il volume 2
gpg -d cipher_disk_2.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_2.img \
         --key-file - \
         ${DEV_2} cipher_disk_2

# "apro" il volume 3
gpg -d cipher_disk_3.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_3.img \
         --key-file - \
         ${DEV_3} cipher_disk_3

# (facoltativo) apre il gruppo di volumi
vgchange -ay vg_master

# "apre" il master volume
gpg -d master.key.gpg | \
    cryptsetup open \
         --type luks2 \
         --header header_master.img \
         --key-file - \
         /dev/mapper/vg_master-lv_master cipher_disk_master

# Monta il volume
mount -t auto /dev/mapper/cipher_disk_master /run/media/master/disk_master

Chiusura del vault

# smonta il volume cifrato
umount /run/media/master/disk_master

# chiusura del vault master
cryptsetup close cipher_disk_master

# chiusura del gruppo di volumi
vgchange -an vg_master

# chiusura dei singoli vault cifrati
cryptsetup close cipher_disk_1
cryptsetup close cipher_disk_2
cryptsetup close cipher_disk_3

# deattach dei dispositivi
losetup -d ${DEV_1} ${DEV_2} ${DEV_3}

#cryptsetup #devicemapper #dmcrypt #gpg #loseup #luks #lvm #loopdevice #storage

Archiviare le password in sicurezza con KDF/password-hashing (Trilogia Della Password - 3 di 3)

Thu, 29 Jan 2026 17:49:50 +0000

Dopo aver capito come creare password inviolabili anche avendo a disposizione tutta l'energia termica dell'universo, pensiamo al modo migliore per archiviarle.

Pensare di lasciare la password raw in un database, rappresenta un grosso rischio in virtù di un possibile attacco offline.

Rainbow Table
Come ti blocco la Rainbow Table: Il “Salt” (sale)
Il livello successivo: Il Pepper
Final step: L’hashing
- PBKDF2
- Bcrypt
- Scrypt
- yescrypt
- Argon2
Un piccolo esempio: hashing di una password con Argon2
Gestione del pepper
HSM
Key / Algo Rotation
- Caso A: Algo rotation
- Caso B: Pepper rotation

Una prima linea di difesa consiste nel memorizzare il digest della password, una stringa alfanumerica univoca generata da un apposito algoritmo, così da lasciare nelle mani dell'attaccante degli oggetti che, per la loro non invertibilità, non permettono di risalire alle password.

La scelta dell'algoritmo di hashing diventa critica al fine di scongiurare altri tipi di attacchi. Ad es. SHA-256, pur essendo ottimo e molto efficiente per il digest e la firma anche di file di grandi dimensioni, mostra il fianco, proprio in virtù della sua velocità, nel caso di attacchi con:

brute-force: si calcola l’hash di password casuali fino a trovare una corrispondenza,
dizionario: un'alternativa intelligente alla forza bruta. Si punta alle password più comuni, si calcola l'hash e si controlla se c'è corrispondenza.
Rainbow Table: l'attacco al dizionario più insidioso di tutti

Oltre al fatto che, la funzione di hashing , essendo deterministica, permette di capire chi sono gli utenti che hanno la stessa password, dal momento che avranno lo stesso digest.

Rainbow Table

Una Rainbow Table è un enorme dizionario pre-calcolato che contiene:

Milioni di password comuni.
Il relativo hash corrispondente.

Invece di calcolare l’entropia di ogni tentativo, l’attaccante ruba il database degli hash e fa un semplice “Cerca e Trova”. Se l’hash della tua password è nella tabella, la tua password è violata in millisecondi, indipendentemente da quanto fosse alta la sua entropia teorica.

Oss.: Una password totalmente casuale, generata da un CSPRNG affidabile, con un'alta entropia (>120), rimarrebbe comunque inviolabile anche dalla rainbow table perché la probabilità che quella password si trovi nel dizionario, sarebbe equivalente ad indovinarla.

Come ti blocco la Rainbow Table: Il “Salt” (sale)

Per rendere inutili le Rainbow Table, i sistemi sicuri utilizzano il Salt. Il salt è una stringa di dati casuali (generati da una sorgente d’entropia affidabile ovviamente) che viene aggiunta alla password prima di calcolarne il digest.

In questo modo le rainbow table vengono vanificate perché gli hash precalcolati sulle password raccolte, mancando il salt, non valgono più. Anche se due utenti avessero la stessa password, avrebbero degli hash completamente diversi.

Anche per questo motivo non è un problema che il salt sia pubblico, perché il suo obiettivo non è nascondere quello che è un pezzetto di password a tutti gli effetti, ma di impedire economie di scala degli attacchi perché, pur potendo disporre offline di un database di decine di milioni di utenti, gli hash della mia Rainbow Table (che può arrivare a pesare anche decine di GB) andrebbero tutti ricalcolati per ogni utente, con un costo computazionale e di archiviazione inimmaginabile.

Per riassumere, gli ingredienti di base sono:

una buona sorgente d’entropia: una fonte di casualità certificata per generare un salt unico;
entropia della password: sempre buona norma, ove possibile, come sappiamo ormai fare (https://noblogo.org/aytin/come-generare-una-password-o-un-keyfile-sicuri-trilogia-della-password-1-di). Evita attacchi brute-force o al dizionario in cui l’attaccante prova a indovinare;
salt: protegge la password dagli attacchi basati su database pre-calcolati (Rainbow Table).

Il livello successivo: Il Pepper

È vero che col salt andiamo a complicare lo sfruttamento di un attacco offline ma possiamo fare di meglio.

Il punto d'attenzione è che il salt protegge le password di tutti gli utenti. Ma un attaccante potrebbe non essere affatto interessato a violare ogni singolo utente (niente economia di scala) ma solo alcuni. E allora l'attacco attraverso Ranbow Table potrebbe essere di nuovo praticabile.

Ma gli informatici sono dei gran giocherelloni, si sa. Visto che abbiamo già il “sale”, perché non finire aggiustando con un po’ di “pepe”? Detto, fatto!

Il pepper, come il salt, è un'altra password generata con gli stessi criteri del salt ma le analogie finiscono qua perché:

a differenza del salt che si trova nel database, il pepper è separato da ques'ultimo. L'ideale sarebbe un HSM;
Il salt è visibile a tutti, attaccante compreso. Il pepper è segreto. Un eventuale data breach che permette all'attaccante di disporre offline di tutto il database degli utenti, “vedrà” certamente gli eventuali salt ma sarà ignaro del fatto che gli mancherà sempre un pezzo di chiave;
il salt è diverso per ogni utente, il pepper, di solito, è unico;
il salt serve a rendere uniche la password degli utenti, il pepper protegge l'intero database da attacchi offline.

Il pepper è la chiave di un HMAC, o di un meccanismo di cifratura simmetrica, applicato al digest della password (che ricordo essere salt+password in realtà), che sarà ciò che verrà archiviato.

Va detto che l'uso del “pepper” complica ulteriormente lo scenario di archiviazione. Nella stragrande maggioranza dei casi è sufficiente scegliere un buon algoritmo di password hashing (vedi paragrafo successivo) per scoraggiare gli attaccanti. “Pepare” le password prevederebbe, come detto sopra, l'uso di un HSM per es, e tutta una serie di riflessioni di contorno che evidenzierò più avanti.

Final step: L'hashing

L'ultimo punto da dettagliare è l'hash della password.

L'hash crittografico, in uso in questi casi, deve soddisfare le seguenti proprietà:

resistenza alla pre-immagine: dato un hash h, deve essere impossibile trovare una password p t.c. H(p) = h (non invertibilità della funzione hash)
resistenza alla pre-immagine secondaria: dato una password p₁, deve essere impossibile trovare un'altra password p₂ t.c. H(p₁) = H(p₂) (resistenza debole alle collisioni)
resistenza alle collisioni: è impossibile trovare due password diverse, p₁ e p₂, t.c. H(p₁) = H(p₂) (resistenza forte alle collisioni)
effetto valanga: il cambio di un solo bit della password deve cambiare radicalmente l'intero hash

In un sistema moderno, l'hash non può essere delegato a funzioni di tipo SHA perché nascono per altri compiti,

SHA-2 e SHA-3 nascono per il digest veloce, per verificare l'integrità di file anche molto grossi o firmare documenti. La loro eccellente velocità diventa il loro più grosso difetto quando si parla di password. Negli scenari precedenti di attachi offline, l'hacker che dispone di una grossa potenza di calcolo, può ricostituire velocemente le rainbow table per n utenti. Magari non di tutti ma di quelli attenzionati.

Le funzioni di derivazione della chiave (KDF) come pbkdf2 e quelle ancora più estreme come B/Scrypt, Argon2, oltre che soddisfare tutti i punti precedentemente elencati tipici di funzioni di password hashing, sono progettate per essere computazionalmente pesantissime da calcolare perché il loro scopo non è il digest ma la protezione di un segreto contro il brute-force. E mentre le vecchie KDF come pbdfk2 sono CPU bound, ma non GPU bound, le KDF più moderne come Bcrypt, Scrypt ma soprattutto Argon2, agiscono pesantemente su tempo, memoria e parallelismo e l'attacco offline di cui sopra diventa impraticabile.

PBKDF2

È il decano delle KDF. Applica iterativamente una funzione pseudorandomica, come HMAC con uno SHA, con salt alla password. Il conteggio delle iterazioni è un parametro configurabile.

PBDKF2 è uno standard di lunga data ampiamente adottato. Se non ci sono necessità stringenti di sicurezza o requisiti legacy, è una buona scelta.

Il fatto di essere solo CPU bound però non la rende la scelta ideale in scenari dove gli attaccanti possono attingere a risorse di calcolo considerevoli

Bcrypt

Basato su Blowfish, anche Bcrypt usa un hash crittografico sulla password con parametri il salt e un fattore di costo.

Il fattore di costo aumenta esponenzialmente il numero di iterazioni per adattarsi all'aumento di potenza di calcolo dell'hardware.

Bcrypt è stato progetto per essere lento e resistente a semplici attacchi di forzat bruta. Tuttavia, il basso utilizzo di ram richiesto dal calcolo lo rendono poco resistente ad attacchi sferrati usando hardware specializzato.

Bcrypt ha dalla sua una storia solidissima in ragione della quale da 20 anni a questa parte non sono state trovate vulnerabilità critiche nel suo design.

Per questo motivo Bcrypt cifra le password di sistema di OpenBSD dal 1999, come pure ha cifrato quelle di tante distro Linux per anni, prima che passassero ad Argon2 o yescrypt (default di Fedora).

Domina nei framework web ([Python] Django, [Ruby] Ruby on Rails, [PHP] Laravel), [Java] Spring, Node.js), nelle applicazioni (Ansible / Terraform, Docker), nel web (la cifratura in .htpasswd di Apache e Nginx) visto che la sua semplcitià di implementazione gli ha permesso di trovarsi praticamente in ogni linguaggio.

È presente come alternativa anche nei password manager benché molti di essi abbiano spostato il default verso Argon2 o PBKDF2 per conformità agli standard FIPS.

È molto semplice implementare e anche da usare perché bisogna agire solo sul fattore di costo (consigliato almeno 10-12, altrimenti diventa troppo vulnerabile ad attacchi sferrati attraverso la GPU)

Scrypt

Rilasciato nel 2009, Scrypt è stato il primo algoritmo a introdurre il concetto di Memory Hardness ed è stato progettato per rendere economicamente poco conveniente il ricorso ad hardware specializzato come gli ASIC o i FPGA e incidere pesantemente su CPU, ram e parallelismo.

Il suo alveo principale sono state le cripto-valute, molte monete lo usano per il mining.

Scrypt lo troviamo in quasi tutti i linguaggi di programmazione, in Tarsnap, servizio di baclup online creato dallo stesso autore di Scrypt, è stato usato da LastPass ed è presente come opzione in VeraCrypt per derivare la chiave dalla password. Fino ad Android 9 era l'algoritmo usato per la FDE del dispositvio (passato poi al FBE) . Presente anche su FreeBSD come opzione per la cifratura delle password di sistema e come opzione su LUKS per la cifratura degli slot delle chiavi.

Su Scrypt i parametri da configurare sono:

Costro CPU/Memoria (N): un parametro che aumenta i costi computazionali di cpu e memoria
DImensione del blocco ®: influenza la larghezza di banda della memoria
Parallelizzazione (p): indica quanto deve incidere sul calcolo parallelo

In questo modo riesce ad essere sia CPU bound che GPU bound che, a differenza di Bcrypt, lo rende resistente anche ad attacchi facenti uso di hardware specializzato..

Di contro, in ambiente in cui siamo vincolati dalle risorse disponibili, la sua potenza diventa un fattore limitante. Quasi paragonabile ad Argon2 in quanto a robustezza, il suo unico tallone d'Achille è la permeabilità ad attacchi di tipo side-channel.

yescrypt

Piccola menzione per yescrypt, appartenente alla famiglia “Scrypt”, pensato per essere ancora più resistente di Scrypt agli attacchi GPU e FPGA ma con una gestione più intelligente delle risorse.

Grazie alle sue peculiarità, di fatto, è diventato il successore spirituale di Bcrypt nei sistemi operativi gnu/linux dove, a cominciare da Fedora, passando per Debian, Ubuntu, Arch, Kali, è il default per la cifratura delle password di sistema in /etc/shadow.

È talmente incardinato ormai nei sistemi operativi, che è la libreria libxcrypt di yescrypt a gestire la tipica funzione crypt() di C che è la base della crittografia su tutti i sistemi gnu/linux moderni.

La sua robustezza unita alla gestione intelligente delle risorse lo rende un coltellino svizzero di riferimento utile per es. per versione custom di LUKS su sistemi embedded, che magari fanno uso di cpu meno recenti, oppure come opzione per strumenti di backup specialistici

Di fatto, sui sistemi operativi, yescrypt s'è guadagnato un consenso amplissimo dovuto alla sua scalabilità, alla sua capacità di usare anche la ROM per rendere il cracking ancora più difficile e senza pesare sulla RAM e alla sua compatibilità potendosi inserire perfettamente nella storica funzione crypt() di C come detto prima.

Se Argon2 è il vincitore accademico avendo vinto il Password Hashing Competition del 2015, yescrypt per la sua robustezza, efficienza e flessibilità si ritaglia un profilo di indispensabilità nei sistemi operativi,

Argon2

E veniamo al dominatore indiscusso di questa che non è una llista esaustiva di KDF.

Argon2 è LO standard moderno per il password hashing raccomandato da OWASP e IETF.

È il riferimento per praticamente ogni password manager: Bitwarden, KeppasXC, 1Password, a cui assegnanp la protezione della Master Password

È la scelta principale per la cifratura degli hard disk anche con impostazioni molto aggressive, in ragione delle quali un ritardo di mezzo secondo (un tempo enorme se venisse scalato esponenzialmente) nell'apertura di un HD è assolutamente accettabile. È il default di LUKS2 (LUKS1 usava PBKDF2) e di VeraCrypt, con cui ha sostituito SHA-512.

Come Bcrypt, è implementato estensivamente su praticamente ogni frameword web e backend, da PHP, Django (Python), Laravel fino a Node.js.

Nei sistemi operativi, laddove yescrytpt domina nella gestione delle password utente, Argon2 è usato per compiti più critici. Dal kernel Linux per gestire internamente le chiavi crittografiche o da macOS / iOS, dove algoritmi proprietari ispirati fortemente ad Argon2, proteggono i dati nel Secure Enclave.

Argon2 setta 3 parametri principali per regolare la sua forza:

t: iterazioni, quante volte vengono rimescolati i dati (default Bitwarden = 3)
m: memoria, quanta ram deve occupare il calcolo. Questa è la misura anti-GPU (default Bitwarden = 16 (64MB))
p: parallelismo, quanti core della cpu usare. Questa è la misura anti-CPU (default Bitwarden = 4)

La variante id è anche resistente agli attacchi side-channel perché impediscono a un attaccante di capire la password osservando i tempi di accesso alla memoria.

Un piccolo esempio: hashing di una password con Argon2

Il grosso vantaggio degli algoritmi di kdf è che sono naturalmente resilienti rispetto all'evoluzione tecnologica che produce macchine con sempre maggiore potenza di calcolo. Da pbkdf2 in poi, il salt implicito che invalida le rainbow table precalcolate e la possibilità di calibrare il key stretching in moda da agire intensivamente su ram e cpu, permettono all'algoritmo di adeguarsi per conservare la sua robustezza.

Mini-script per l'hashing di una password fornita dall'utente con argon2 settato al default di Bitwarden:

echo -n "Password: "; read -s PASSWORD
# Genero un Salt casuale di 128 bit
SALT=$(openssl rand -base64 128)
PASSWORD_HASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e)

PASSWORD_HASH e SALT sono i dati che verranno archiviati e, poiché argon2 “frulla” la password con un salt, è praticamente impossibile risalire alla password originale.

La verifica è tuttavia banale perché, avendo il salt e la password da verificare, si ricrea l'hash con argon2 e si confronta con l'hash memorizzato.

Per maggior sicurezza salt e digest possono essere memorizzati in punti differenti. L'importante è che possano essere recuperate a partire dall'utente.

Gestione del pepper

Col pepper le cose cambiano un pochino perché:

deve essere archiviato con tutte le paranoie possibili in un punto diverso dal database degli utenti
il key rotation del pepper non è banale

Mini-script che mostra come applicare salt e pepper all'hashing di una password:

# L'utente inserisce la password
echo -n "Password: "; read -s PASSWORD

# Genero un Salt casuale di 128 bit unico per ogni utente
SALT=$(openssl rand -base64 128)

# Anche PEPPER sarà qualcosa del tipo "openssl rand -base64 128"
# e si troverà in un punto esterno al database degli utenti.
PEPPER=$(get_pepper_from_ext)

# Digest della password+salt
PASSWORD_HASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e)

# HMAC del digest con PEPPER come chiave
PASSWORD_PEPPER=$(echo "${PASSWORD_HASH}" | openssl dgst -sha256 -hmac "${PEPPER}" -binary | base64)

HSM

Quella vista prima è una versione molto edulcorata di ciò che avviene nella realtà. Il pepper, non può essere gestito con leggerezza visto che è un segreto che protegge non un singolo oggetto ma intere classi, come db di utenti.

L'apparato che gestisce chiavi di questo tipo e di questa importanza, deve essere robusto, praticamente inattaccabile, quasi completamente isolato dal resto dei sistemi a meno delle applicazioni, e solo di quelle, che hanno il permesso di richiedere una chiave,

Apparati hardware specializzati che assolvono a tutte queste funzioni e anche di più, sono gli HSM (Hardware Security Module) che garantiscono il ciclo di vita delle chiavi, dalla generazione alla distruzione, includendo versionamento, rotazione e backup. Sono concepiti per resistere anche a manipolazioni forzate che possono innescare un meccanismo di autodistruzione e, particolare rilevante, le operazioni crittografiche basate sulle chiavi protette vengono svolte dall'hsm che consegna al client il risultato delle operazioni, non le chiavi. Nel nostro caso, l'HSM dovrebbe restituirci l'hmac del digest della password che gli inviamo.

Key / Algo Rotation

Cosa succede se cambio pepper o algoritmo (anche la sua configurazione)? Non avendo disponibilità in alcun modo della password dovrò adottare una strategia ad-hoc. Fra tutti gli scenari possibili, il miglior compromesso fra sicurezza e comodità secondo me, è quello basato sul wrapping.

È necessario innanzitutto che vengano conservate le versioni delle chiavi per i servizi che le richiedono. E a questo dovrebbe pensarci l'HSM, se ce n'è uno o qualcosa di custom che abbia funzionalità analoghe. Inoltre dovrebbero esserci dei flag che indichino quali sono gli utenti a cui sono state applicate le nuove configurazioni.

Caso A: Algo rotation

Supponiamo che l'algoritmo di hashing venga cambiato o vengano cambiate le sue configurazioni.

Premessa: Nel mio DB degli utenti, in corrispondenza di ogni utente, avrò:

il digest della password “pepato”: HMAC ( pepper, HASH ( salt, password ) )
il salt

Il wrapping: La strategia sarà quello di “avvolgere” la password di ogni utente col nuovo algoritmo, settare un qualche flag che mi indichi l'operazione compiuta e archiviare il tutto.

Imponiamo il nuovo algoritmo a tutti gli utenti “imbustando” il digest attuale (in questo caso 'HMAC in realtà, visto che abbiamo a che fare anche col pepper) con il nuovo digest HASH_NEW: HASH_NEW ( salt_new, HMAC ( pepper, HASH ( salt, password ) ) ).
Per ogni utente averemo dunque:
1. il nuovo digest al posto di quello vecchio,
2. il nuovo salt
3. il vecchio salt
Settiamo il flag del cambio algoritmo a true (o quello che è)
Quando l'utente effettuerà il login con successo e il flag sarà a “true”, abbiamo la password che ci permetterà di eliminare il vecchio “involucro” e ripristinare l'HMAC del nuovo digest: HMAC ( pepper, HASH_NEW ( salt_new, password ) ) e il flag ritornerà a “false“

Considerazioni:

La sicurezza non viene compromessa perché il digest di un digest, con KDF configurate a dovere, non comporta alcun rischio.
La fase di verifica è quella che si complica di più perché in base al valore del flag, dovrà essere effettuata in maniera differente.
- Se il flag è “true” (nella nostra convenzione), dopo il login devo avere gli elementi per calcolare il digest in questo modo: HASH_NEW ( salt_new, HMAC ( pepper, HASH ( salt, password ) ) ).
- Se il flag è a false, calcolerò al solito: HMAC ( pepper, HASH_NEW ( salt_new, password ) )

Caso B: Pepper rotation

Supponiamo che a ruotare sia il pepper. Procediamo sempre con il wrapping massivo su tutti gli utenti incapsulando il digest :

HMAC ( pepper, HASH ( salt, password ) )

con quello nuovo:

HMAC ( pepper_new, HMAC ( pepper, HASH ( salt, password ) ) )

mettendo il flag a “true”.

Come prima, una volta che gli utenti cominceranno a fare il login, se il flag è “true” innanzitutto verificherò che:

HMAC ( pepper_new, HMAC ( pepper, HASH ( salt, password ) ) )

sia uguale a ciò che è stato archiviato. Se così fosse, ora che sono di nuovo in possesso della password, ripristinerò l'HMAC con:

HMAC ( pepper_new, HASH ( salt, password ) )

memorizzandolo al posto di quello vecchio e rimettendo il flag a false.

Considerazioni: La modifica massiva delle password degli utenti, stavolta passa dall'HSM e potrebbe essere un problema perché un HSM è progettato per scoraggiare flooding di richieste.

È vero che il pepper è sempre lo stesso per tutti gli utenti ma, come ricordavo prima, di solito un HSM non fornisce i suoi segreti ma solo i risultati crittografici delle loro applicazioni.

#kdf #pbkdf2 #bcrypt #scrypt #yescrypt #argon2 #luks #cryptography #aes #sha #digest #RainbowTable #BruteForce #salt #pepper #entropy #hsm #hmac #hash

Come valutare la resistenza di una password (Trilogia Della Password - 2 di 3)

Thu, 22 Jan 2026 19:04:39 +0000

In “Come generare una password o un keyfile sicuri” abbiamo visto come generare password e keyfile che si basassero su dati il più possibile casuali. La verifica matematica di una password si basa sulla determinazione del numero di tentativi necessari a un attaccante per indovinarla. Esistono due approcci: quello teorico (brute force) e quello realistico (pattern matching).

Calcolo teorico (Entropia di Shannon)
- Spiegazione dell’entropia di Shannon
- Esempi d’uso
Calcolo realistico (pattern matching)
- Ent
- zxcvbn
- Riassumendo
Metodo Diceware

Calcolo teorico (Entropia di Shannon)

Un primo strumento per la valutazione di una password è dato dall'entropia di Shannon, che chiunque abbia usato un password manager certamente conoscerà.

Questo calcolo assume che l'attaccante non sappia nulla della nostra password e debba provare ogni possibile combinazione (forza bruta).

Dato un alfabeto di R simboli e una password di lunghezza L, l'entropia E sarà pari a:

E = log₂ ( R^L ) = L * log₂ ( R )

L'entropia è un valore numerico espresso in bit (gli “Shannon”) che rappresenta una misura, non tanto della robustezza, quanto della “densità” della password, ossia di quanto lavoro richieda ad un calcolatore per essere indovinata. Più è alta, meglio è.

Spiegazione dell'entropia di Shannon

Innanzitutto notiamo che R^L è la dimensione dello spazio di possibilità in cui esiste la mia password e, per R e L sufficientemente grandi, è un numero talmente enorme da essere difficilmente comprensibile.

L'equivalente E, che non è altro che l'esponente della potenza di 2 tale per cui 2^E = R^L, risulta invece molto più gestibile e confrontabile.

Semplificando, se alla mia password lunga L corrisponde quindi un'analoga chiave in bit lunga E, un attaccante che voglia scoprire la mia password, invece che indovinare gli L simboli da un alfabeto R, compirà lo stesso sforzo rispondendo correttamente ad un numero di domande binarie (SI / NO) pari a E, per ricostruire la giusta sequenza binaria.

Quanto costa ricostruire la sequenza? O, in altre parole, qual è lo sforzo computazionale richiesto?

Si parla di caso medio ottimale corrispondente ad una ricerca binaria in cui ogni domanda dimezza lo spazio di possibilità fino ad azzerarlo completamente.

E = L * log₂ ( R ), è quel numero di bit che mi dice quant'è profondo l'albero delle decisioni che il calcolatore deve percorrere, albero in cui il numero dei possibili cammini radice-foglia (equivalenti a tutte le possibili password) è 2^E = R^L.

Nel caso migliore, rispondo correttamente a tutte le E domande al primo tentativo (trovo subito il mio cammino sull'albero).
Nel caso peggiore, mi occorreranno 2^E risposte (percorro tutti i cammini dell'albero) equivalente proprio a R^L.

Possiamo allora definire formalmente l'entropia come quella quantità minima di informazione necessaria ad azzerare l'incertezza legata all'identificazione della password. Per questo motivo è espressa in bit.

Una misurazione di questo tipo ha senso solo se ipotizziamo che i simboli siano tutti equiprobabili.

La formula di Shannon misura, sì, l'entropia, ma al suo massimo potenziale, quando la distribuzione dei simboli nella sequenza è omogenea e assolutamente casuale.

Esempi d'uso

Facciamo l'esempio di una password lunga 20, costruita su un alfabeto di 66 simboli (alfanumerico con maiuscole e minuscole più 4 simboli speciali). La dimensione di questo spazio di possibilità è pari a:

S_p = R^L = 66²⁰ = 2,46 * 10³⁶

Tentare un attacco di forza bruta su un oggetto del genere è semplicemente impensabile. Faccio un esempio.

Per forzare la nostra password, supponiamo di avere a disposizione il più potente supercomputer del mondo, El Capitan ad oggi, dotato di una potenza di calcolo spaventosa, in media 2.000 exaFLOPS con picchi di 2.746 exaFLOPS, dove 1 exaFLOPS è un quintilione (10¹⁸) di operazioni al secondo.

Il calcolo di una password si misura in Hash al secondo, H/s per usare una notazione compatta, che è più dispendiosa della singola operazione.

Approssimando per eccesso con molto ottimismo e nell'ipotesi di usare algoritmi estrememente deboli e poco costosi dal punto di vista computazionale come NTLM o MD5, possiamo pensare che il nostro sistema possa arrivare a calcolare, in queste condizioni, circa 1,5 quintilioni ( 1,5 * 10¹⁸ ) H/s. Per algoritmi come bcrypt o argon2, progettati per essere molto dispendiosi, tale potenza si riduce drasticamente di molti ordini di grandezza. Da 10¹⁸ a 10⁹ – 10⁶. Ma consideriamo il caso più favorevole perché sembra appunto una potenza enorme.

Ma anche questa tremenda esibizione di potenza annichilisce di fronte al numero di calcoli da compiere nel nosro spazio di possibilità. Dato S_p lo spazio di possibilità (il numero di possibili combinazioni), il tempo T espresso in secondi necessario ad eseguire tutte le operazioni sarà:

S_p = 66²⁰ = 2,46 * 10³⁶

T = 2,46 * ³⁶ / 1,5 * 10¹⁸ = 1,64 * 10¹⁸

Che equivale a circa 52 miliardi di anni.

Per avere un'idea di questa grandezza cosmica, si pensi che l'età del nostro universo è di circa 13,8 miliardi di anni. Quindi il calcolo della nostra password potrebbe richiedere un tempo che è grossomodo 3,8 volte l'età dell'universo.

I 120 bit di entropia, sono dunque la misura di questo sforzo potenziale, interpretabile equivalentemente in due modi differenti:

la probabilità di riuscire a trovare la password tirando a indovinare, probabilità che è 1 su 2¹²⁰

oppure

la capacità di rispondere correttamente e consecutivamente a 120 domande di tipo (SI / NO) (ricerca del giusto cammino in un albero decisionale binario profondo 120 livelli)

Allungando la nostra password di altri due caratteri, l'entropia arriva a circa 133 e il calcolo delle possibili combinazioni, posto che fosse possibile ignorando le leggi della termodinamica, richiederebbe circa 16.500 di volte l'età dell'universo.

Considerazione a margine: è la lunghezza della password ad incidere più che la complessità dell'alfabeto. E lo vediamo dalla formula dell'entropia, perché, in una funzione di elevamento a potenza R^L, aumentare l'esponente L fa crescere molto più rapidamente la funzione che non aumentando la base R.

Calcolo realistico (pattern matching)

L'entropia di Shannon fornisce un riscontro utilizzabile solo ipotizzando che:

le scelte siano indipendenti
la distribuzione sia uniforme

e in uno scenario di questo tipo, l'attacco di forza bruta non è una via percorribile.

Allo stesso tempo, se non vengono rispettati questi vincoli, l'entropia dà una falsa sicurezza perché la formula di Shannon “standard” non tiene conto della ridondanza:

Consideriamo questa password: Password12345678

teoria: la formula E = L * log2R direbbe che la sua entropia sia 95, ottima.
realtà: poiché è una sequenza ovvia, l'attaccante la proverà per prima. La sua entropia reale sarà vicina a 0 bit.

L'entropia quindi misura la “densità” della password, la sua imprevedibilità potenziale ma non dà nessuna informazione sulla presenza di schemi ripetuti e sul pattern matching.

Ent

L'essere umano come generatore di entropia fa schifo. Ecco perché, per un attaccante, prima ancora di provare tutte le possibili combinazioni di caratteri, un attacco a dizionario può far risparmiare un sacco di tempo. Infatti sempre Shannon ci dice che nelle parole dei linguaggi naturali alcune lettere ricorrono più di altre, non serve lo stesso numero di domanda ma molto meno e così l'entropia media diminuisce. Per prevenire questi effetti collaterali, il nostro metodo di generazione e quindi ciò che viene generato, deve essere testato con qualcos'altro che non sia la semplice entropia.

ent è un tool a linea di comando che fa 4 valutazioni differenti:

entropia
Chi-quadrato
Media aritmetica
Monte Carlo Pi

N.B. ent non è adatto alla valutazione della singola password perché ha bisogno di migliaia di dati (almeno 1K). Una singola password di 24 caratteri per es. (24 byte) non ha materiale casuale sufficiente affinché ent converga verso un giudizio oggettivo.

Entropia L'entropia misura la densità di informazione. In ent, viene calcolata in bit per carattere (byte).

Il valore: Si analizza il file byte per byte, il valore massimo è 8.0 (ogni byte è totalmente imprevedibile).
Interpretazione: Più il valore è vicino a 8, più la casualità è “densa” e difficile da indovinare tramite attacchi basati su dizionario. Se il valore è basso (es. 2.0 o 3.0), significa che ci sono molte ripetizioni o uno schema prevedibile.
Compressione: ent ti dice anche quanto il file potrebbe essere compresso. Un'entropia di 8.0 significa che il file è già “puro caos” e non può essere compresso ulteriormente.

Chi-quadrato Il test del chi-quadrato prova a capire se il disordine presente nel file sia veramente equo o se si preferiscono certi caratteri ad altri. Esamina la distribuzione dei caratteri e la confronta con una distribuzione uniforme teorica. Il risultato viene presentato come percentuale con questi scaglioni:

10% < chi² < 90%: La sequenza è considerata casuale. Il 50% è il valore “perfetto”.
chi² < 1% o chi² > 99%: È quasi certamente non casuale.
- chi² = 99.99%: i dati sono sospettosamente regolari;
- chi² = 0.01%: i dati sono “troppo” casuali per essere naturali (sospetta manipolazione)

Media aritmetica Per capire se la distribuzione è sufficientemente omogenea, si fa la somma dei valori dei byte del file e si fa una media.

Poiché i byte vanno da 0 a 255, il valore ideale della media sarebbe 127,5. Se è troppo lontano dalla media avvcinandosi ad uno dei due estremi (ad es. 50 o 190), vuol dire che si sta usando solo un piccola parte dei caratteri a disposizione e questo, a suo modo di vedere, rende le password più prevedibili.

Monte Carlo Pi È il metodo più fantasioso di tutti. I dati casuali vengono trasformati in una serie di “dardi” virtuali che vanno a colpire un bersaglio. L'obiettivo non è quello di colpire un ipotico centro ma di verificare che i “dardi” si distribuiscano uniformemente nel bersaglio.

Tutto ciò si realizza immaginando di avere un quadrato 1x1 e ¼ di cerchio al suo interno di raggio 1 e area π/4 I dati della sequenza casuale vengono prelevati a gruppi di n byte e supponiamo n = 3 per ora. Ogni gruppo di 3 byte sarà un numero compreso tra 0 e 2²⁴-1. Se normalizziamo questo numero dividendolo per 2²⁴, otteniamo un numero compreso fra 0 e 1. Calcolando le coordinate in questo modo, col teorema di Pitagora possiamo verificare se la coordinata (X,Y) “cada” nel quarto di cerchio oppure no e ciò succede se:

X² + Y² ≤ 1

Lanciando un migliaio di queste “frecce”, accumuliamo dati sufficiente per fare una stima.

Se indichiamo con In il numero di “lanci” con successo e con Total il numero totale di lanci effettuati:

4 * (ln/Total) si avvicinerà a π solo se la distribuzione dei caratteri sarà uniforme (indice di una casualità omogenea), altrimenti divergerà in maniera significativa (indice della presenza di pattern o di ripetizioni).

zxcvbn

ent fa un'analisi statistica della distribuzione dei bit in un generatore di casualità.

zxcvbn invece fa un'analisi di tipo euristico, è verticale sulla verifica delle password in particolare nel rilevare se vi sono schemi o ripetizioni di caratteri che renderebbero le password violabili.

Il suo algoritmo scompone le password in pezzi dei quali cerca corrispondenze in dizionari o schemi come:

dizionari: controlla la presenza di parole di uso comune
sequenze: controlla la presenza di serie di caratteri prevedibili come “123456”, “abcde”
pattern spaziali: controlla la presenza di percorsi sulla tastiera come “qwerty”, “asdfg”, “zcvbn” o sequenze diagonali
ripetizioni: ripetizione di caratteri come “kkkkkkkkkk” o “12121212”
l33t: una parola come “p4$$w0rd” viene subito riconosciuta come “password”
date: riconosce giorni, mesi, anni, anche composti come “15062026”

Il suo uso è molto semplice. Le si dà in pasto la password e zxcvbn restituisce diverse informazioni utili:

uno score da “0” (terribile) a “4 (ottima);
la stima di quanto tempo impiegherebbe un hacker a violarla in base a vari scenari di attacco;
suggerimenti su come migliorare eventualmente la password.

zxcvbn era una libreria javascript orginariamente sviluppata da Dropbox e ora disponibile in tante forme: go, python, c++.

L'originale Dropbox in javascript, non più manutenuto, può essere trovata qui: https://github.com/dropbox/zxcvbn.

Benché esistano diversi porting in python, se c'è l'esigenza di usare la versione legacy, gli stessi sviluppatori dell'originale zxcvbn consigliano questa versione: https://github.com/dwolfhub/zxcvbn-python, che può essere installata con pip.

In realtà la versione migliore è un fork in typescript, zxcvbn-ts che offre modularità (a differenza della versione python che è monolitica), maggior sicurezza, risoluzione di bug, aggiornamento continuo dizionari compresi.

Per capirci, mentre ent usa l'entropia di Shannon per valutare la probabilità statistica dei byte, zxcvbn cerca di calcolare una stima dei tempi necessari per indovinare la password.

Una passphrase su ent avrebbe un punteggio risibile perché le entropie di parole comuni sono molto basse. Su zxcvbn invece avrebbe un punteggio molto alto perché l'entropia di una parola viene calcolata sulla posizione del dizionario che la contiene per cui un hacker dovrebbe provare milioni di combinazioni prima di trovarla.

Allo stesso modo, password che per ent sarebbero ottime, per zxcvbn sarebbero da evitare perché legate a pattern o a ripetizioni.

Riassumendo

Se si deve testare una password / passphrase, sicuramente zxcvbn. Se si deve testare un generatore di casualità o un keyfile di almeno 2k, sicuramente ent.

Metodo Diceware

Visto che nell'ultima parte abbiamo evidenziato l'anomalia che sorge nel momento in cui si valuta un oggetto casuale o dal punto di vista puramente statistico o dal punto di vista euristico, vale la pena di spendere due parole sulla modalità di creazione delle passphrase usando il metodo Diceware.

Usando come password parole estratte dal linguaggio naturale bisogna fare i conti col problema della prevedibilità. Shannon ha dimostrato che la lingua italiana (o inglese) ha un'entropia molto bassa (circa 1-1.5 bit per lettera) perché dopo una “q” ci si aspetta quasi sempre una “u”, e dopo un soggetto ci si aspetta un verbo. E così via. Ecco perché, piuttosto che valutare l'entropia nel suo complesso e provare ogni possibile combinazione, un moderno calcolatore inzia col far ricorso a “pattern” umani per violare password in pochi minuti invece che millenni.

Per unire la sicurezza del calcolo casuale alla comodità di una password menmonica, si ricorre al metodo Diceware che consiste nel far uso di un dizionario di migliaia di parole.

Quello classico, di 7776 parole inglesi, curato dall EFF si può trovare qui:

curl -L https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt > dic_diceware.txt

Altrimenti Tarin Gamberini espone il suo dizionario diceware , aggiornato al 2019, qui: https://www.taringamberini.com/downloads/diceware_it_IT/lista-di-parole-diceware-in-italiano/4/word_list_diceware_it-IT-4.txt.

Questo dizionario contiene 6⁵ parole numerate da 11111 a 66666. La passphrase è composta da n di queste parole il cui indice è ricavato lanciando un dado (o un analogo virtuale) per 5 volte. In questo modo le parole non sono correlate fra di loro come si potrebbero trovare in una frase, vanificando ogni possibile speculazione sulla sua composizione.

Volendo fare un calcolo dell'entropia, supponendo di costruire una passphrase di 6 parole:

E = L * log₂ R = 6 * log₂ 7776 ~ 77,6

Nella password classiche basate su un alfabeto di R simboli, il mattoncino è rappresentato dal singolo carattere che ha una probabilità 1/R di essere estratto.

Con Diceware, il mattoncino è la parola che ha una probabilità su 7776 di essere estratta. Ogni parola in più, aggiunge una quantità enorme di incertezza.

Ecco perché con sole 6 parole abbiamo già una passphrase molto robusta e con 10 parole siamo di fronte ad una passphrase inattacabile, almeno dal punto di vista dell'analisi statistica (E > 129) e imperforabile anche ricorrendo ad analisi euristiche.

Regola aurea: la scelta delle parole deve essere realmente casuale e non seguire regole grammaticali o preferenze personali. Altrimenti sarà un gioco da ragazzi violarla con un approccio a-là zxcvbn.

#entropy #shannon #bruteforce #ent #zxcvbn #diceware #passphrase #PatternMatching