crittografia — Cyberdyne Systems

fwknop: proteggere servizi con Single Packet Authorization (SPA)

Sun, 15 Dec 2024 11:44:33 +0000

Cos'è fwknop

fwknop è un software di port knocking che usa uno schema di autenticazione chiamato “Single Packet Authorization” ipotizzato e formalizzato dallo stesso autore per risolvere le debolezze più comuni del classico port-knocking.

Cos'è fwknop
Installazione client e server
Configurazione client
1. Generazione della sola chiave
2. Generazione chiave + configurazione complessa
Configurazione server
Scenari
E se volessi usare la crittografia asimmetrica?
Osservazioni su access.conf

fwknop, come il port knocking, unisce la comunicazione passiva di informazioni di autenticazione al filtraggio di tutti i pacchetti che non rispettano le sequenze di knock.

Il classico approccio di port-knocking sfrutta le intestazioni dei pacchetti (2 byte) e non il loro payload, per cui è necessario mandare un certo numero di pacchetti per mappare una porta senza generare falsi positivi. Questo però comporta inevitabilmente almeno due problemi:

suscettibilità ad attacchi di spoofing
se le sequenze di knocking sono eccessivamente articolate (magari per inviare più informazioni), data l'imprevedibilità della rete e l'assenza di costrutti che garantiscano lo stesso ordine d'arrivo dei pacchetti, c'è la possibilità che il server non riesca a ricostruire la sequenza corretta.

Il client fwknop (SPA Client) invia al server (SPA Server) un singolo pacchetto di dimensioni relativamente maggiori (possibile sfruttando il payload) per comunicare informazioni di accesso e interi comandi destinati al filtraggio dei pacchetti.

Il tutto viene protetto da una cifratura simmetrica con autenticazione (aes256-cbc + hmac-sha256, che sarà quella usata nel prosieguo perché più semplice da gestire) o asimmetrica che, al costo di una maggiore complessità di gestione, aggiunge la caratteristica di non ripudio alle caratteristiche di confidenzialità, integrità e autenticazione possedute anche dal primo schema di cifratura.

Installazione client e server

fwknop client e server sono pacchettizzati per ogni distro linux (su Mac OS è possibile ricorrere a brew). Sistemi rpm-based

# Installa il client (fwknop) e il server (fwknopd)
dfn install fwknop

Sistemi debian-based

# Installa il client (fwknop)
apt install fwknop-client

# Installa il server (fwknopd)
apt install fwknop-server

Configurazione client

La configurazione lato client viene conservata nel file .fwknoprc che può essere editato a a mano oppure attraverso il client fwknop salvando nel file .fwknoprc quelle che vengono definite “stanze”.

Nella configurazione è molto importante la generazione della chiave. Se la chiave è simmetrica, la si può generare con fwknop.

Di seguito, due esempi di creazione di stanze con fwknop, una minimale (che useremo nel resto del documento) e una più complessa.

Generazione della sola chiave

Genero la chiave usando il default: aes256-cbc + hmac-sha256.

fwknop -n test -k --use-hmac --save-rc-stanza

E in .fwknoprc troverò una nuova sezione [test]

[test]
KEY_BASE64                  dRYAH2O9FCUpNz1aMmlke9/AkGVdcLrnWxDy7jZC1wg=
HMAC_KEY_BASE64             0xRNOSrVTy6B7PmBHiZG5jzTLwxsPrOd6kUb5/p45VjFfWp3eXMG8hVz4JRjoP89JbtMDhghghco7pV9cdQzdw==
USE_HMAC                    Y

Generazione chiave + configurazione complessa

fwknop -n test -k -A tcp/80 -R -w /usr/bin/wget -D 107.23.186.49 -N 10.0.0.132:3306 --save-rc-stanza

che ha il corrispondente .fwknoprc:

[test]
ACCESS                      tcp/80
SPA_SERVER                  107.23.186.49
KEY_BASE64                  0d/VcRXnf2si7hvfDsPN3YIG4Q7aPLU9Ndd5Pe+eMIQ=
HMAC_KEY_BASE64             EEXu0VCPQKPGp8FC8tYS6I/p56nWlot93BV3CPVf3De9FkM04z1SBWTUEJejHpq45+at7VQirgTYvSxeLoZkKQ==
NAT_ACCESS                  10.0.0.132:3306
RESOLVE_IP_HTTPS            Y
WGET_CMD                    /usr/bin/wget

La spiegazione di questa configurazione specifica la troveremo più avanti nel par. 4. SPA Ghost Service. È solo per far vedere che il file di configurazione .fwknoprc può essere rimpiazzato in toto dall'invocazione via cli del client. Chiave compresa, se è il caso.

Affinché la “stanza” venga creata, deve necessariamente essere presente almeno uno fra valori dei flag -D e -n. Quest'ultimo costituirà anche il nome alla sezione corrispondente, altrimenti sarà il valore di -D .

Per usare il cient con le preimpostazioni di .fwinoprc, basterà indicare il nome della sezione:

fwknop -n test

Ne consegue che i nomi di sezione devono essere univoci.

Da ricordare che quando si usa il client quello che è importante specificare nel file .fwknoprc o nei parametri è:

ALLOW_IP (-a): che indica l'ip da cui sto facendo la richiesta e che deve rientrare nel SOURCE specificato nel server. Se l'ip non è noto magari perché lo spaclient viene nattato, si può ricorrere alla risoluzione dell'ip che viene instradato esternamente (chiamando un servizio esterno):
- RESOLVE_IP_HTTPS (-R): booleano [Y|N] per abilitare lo spaclient a richiedere la risoluzione del proprio ip;
- WGET_CMD (-w): path del comando wget che chiamerà lo script di risoluzione
ACCESS (-A): benché non sia obbligatorio per il server, il client deve necessariamente specificare a quali porte/protocolli intende accedere. Se specificati anche nel server, devono appartenere alla sua lista
SPA_SERVER (-D): indica l'ip o l'url dello spaserver
KEY: la chiave simmetrica per AES-CBC (default: aes256);
HMAC_KEY: la chiave per HMAC (default: sha256)

Configurazione server

Il server si compone di due file:

fwknopd.conf: configura il servizio. È il punto in cui si imposta la porta su cui il servizio sarò in ascolto per ricevere il pacchetto, l'interfaccia, le configurazioni, anche complesse, dei firewall da manipolare in seguito al port-knocking (iptables, firewalld, ipf);
access.conf: regola gli accessi degli utenti. È il punto in cui si indicano quegli elementi necessari ad autenticare ed autorizzare gli utenti, elementi che dovranno coincidere con ciò che contiene il pacchetto. È possibile creare una cartella, da indicare in fwknopd.conf, contenente singole configurazioni di accesso, per utente o per policy, piuttosto che creare un unico, lungo elenco in access.conf.

Anche access.conf è un elenco di “stanze”, i punti d'accesso per i client contenenti come minimo la rete abilitata all'accesso e la chiave con cui si presenta l'utente, come visto in Configurazione client:

SOURCE: gli ip o le subnet del client da abilitare all'accesso
KEY: la chiave simmetrica per AES-CBC (default: aes256)
HMAC_KEY: la chiave per HMAC (default: sha256)

Altri parametri utili a rafforzare ulteriormente il legame con le richieste client, ma non obbligatori per l'avvio del servizio, sono:

OPEN_PORTS: specifica quali porte e quali protocolli abilitare
REQUIRE_USERNAME: specifica un nome utente col quale il client si deve presentare
REQUIRE_SOURCE_ADDRESS: impone che il client specifichi l'ip da cui sta facendo la richiesta in modo da mitigare la possibilità di attacchi MITM

Quando queste opzioni sono presenti sul server, dovranno essere obbligatoriamente specificate anche nel client. Dopo aver visto le configurazioni di client e server, vedremo fwknop in azione in alcuni casi “reali”.

Scenari

Grazie alla sua capacità sia di manipolare, anche in maniera piuttosto articolata, i firewall che concedono l'accesso alle risorse che ad eseguire interi comandi che fwknop mostra tutta la sua versatilità.

In particolare è col NAT che riesce ad andare oltre la sua natura di port knocking dove, grazie ad una combinazione di DNAT e SNAT, riesce a:

girare richieste su server, che normalmente non sarebbero raggiungibili, posti nel backend insieme allo stesso spaserver o dietro di esso
presentare un servizio su una porta diversa rispetto a quella su cui è in ascolto

diventando a tutti gli effetti un bastion host per l'esposizione autenticata e sicura di servizi critici.

Riassumendo, fwknop può:

essere messo direttamente sul server a protezione di uno o più servizi (caso classico);
può nattare un servizio sullo stesso spaverser con un inoltro delle porte locali e, contestualmente, ghostare un servizio con un altro
può nattare un servizio posto nel backend;
come prima, traslare porte e/o “ghostare” servizi

Gli scenari che andrò a mostrare, copriranno i casi più comuni:

Protezione di un servizio con SPA
Ghost locale sullo spaserver
SPA attraverso Gateway NAT
SPA Ghost Service

Lato client, fwknop si baserà sempre sulla configurazione minimale vista prima nel paragrafo “Configurazione client“. Il resto delle configurazioni verrà passato via cli.

1. Protezione di un servizio con SPA

La cosa più semplice da fare è mettere lo spaserver a protezione diretta del servizio insieme ad un firewall che implementa una policy default-drop. Ipotizziamo ad es. di proteggere l'accesso in ssh sul nodo centrale (192.168.100.10) di una rete a stella.

Configurazione lato server

fwknopd.conf:

PCAP_INTF                   eth1;
PCAP_FILTER                 udp port 62201;

access.conf:

%include_folder /etc/fwknop/access.conf.d

test.conf:

SOURCE                      192.168.100.0/24
REQUIRE_SOURCE              Y
KEY_BASE64                  dRYAH2O9FCUpNz1aMmlke9/AkGVdcLrnWxDy7jZC1wg=
HMAC_KEY_BASE64             0xRNOSrVTy6B7PmBHiZG5jzTLwxsPrOd6kUb5/p45VjFfWp3eXMG8hVz4JRjoP89JbtMDhghghco7pV9cdQzdw==

Configurazione lato client

.fwknoprc:

[test]
KEY_BASE64                  dRYAH2O9FCUpNz1aMmlke9/AkGVdcLrnWxDy7jZC1wg=
HMAC_KEY_BASE64             0xRNOSrVTy6B7PmBHiZG5jzTLwxsPrOd6kUb5/p45VjFfWp3eXMG8hVz4JRjoP89JbtMDhghghco7pV9cdQzdw==
USE_HMAC                    Y

fwknop:

fwknop -n test -a 192.168.100.15 -A tcp/22 -D 192.168.100.10
ssh 192.168.100.10

Supponiamo adesso di voler proteggere l'accesso ssh di una macchina dove però il client , caso molto frequente, sia in una rete privata e nattato con un ip pubblico (rete domestica o rete mobile per es.).

Non possiamo sapere con certezza quale sarà l'ip del client per cui, lato server, dovrò essere disposto ad accettare qualunque sorgente e lato client lascerò che l'ip venga risolto dinamicamente.

fwknop -n test -R -w /usr/bin/wget -A tcp/22 -D 107.23.186.49
ssh 107.23.186.49

L'opzione:

-R permette di risolvere il proprio ip pubblico usando wget ( di cui va dato il path) che richiamerà uno script posto di default in https://www.cipherdyne.org/cgi-bin/myip, altrimenti se ne può specificare un altro analogo con --resolve-url . Questo perché l'ip reale del client viene nattato con l'ip pubblico 154.23.162.98, quindi il pacchetto inviato allo spaserver deve contenere questo IP come richiedente, non quello privato (che altrimenti non riceverebbe mai risposta)
-D serve sempre per specificare l'ip, stavolta pubblico, dello spaserver (107.23.186.49)

N.B. Non sapendo quale sarà l'ip richiedente, la clausola SOURCE nel file test.conf non potrà contenere un ip o una subnet, quanto piuttosto:

...
SOURCE                      ANY
...

2. Ghost locale sullo spaserver

Assumiamo che la topologia di rete sia semplice come quella del caso precedente ma ipotizziamo che il client che si autentichi con SPA, acceda ad un servizio protetto la cui porta sia associata contemporaneamente ad un altro servizio esposto pubblicamente.

In questo modo qualunque un altro client (anche attori malevoli) che volesse connettersi a quella porta, continuerebbe a vedere solo il servizio pubblico e non quello protetto.

Questa magia viene resa possibile grazie ad un DNAT locale che mappa temporaneamente, e solo per quell'ip, la porta pubblica con quella del servizio da proteggere.

Nel nostro esempio vogliamo accedere in ssh alla macchina ma sulla porta 80, corrispondente ad un servizio web esposto pubblicamente.

Configurazione lato server

fwknopd.conf:

PCAP_INTF                   enp0s8;
ENABLE_IPT_FORWARDING       Y;
ENABLE_IPT_LOCAL_NAT        Y;

access.conf: Rimane invariato.

Invocazione client

fwknop:

fwknop -n test -R -w /usr/bin/wget -A tcp/22 -D 107.23.186.49 --nat-local --nat-port 80
ssh 107.23.186.49 -p80

3. SPA attraverso gateway NAT

In questo caso lo spa server verrà usato come gateway per accedere a servizi posti sulla rete interna. ad es. un db mybsql su una macchina (10.0.0.132) posta dietro lo spa server.

Per ottenere tutto questo, bisogna abilitare il port forwarding e il SNAT nel file fwknopd.conf in modo che vengano create le regole DNAT e MASQUERADE su iptables affinché le richieste vengano inoltrate rispettivamente verso la macchina che eroga il servizio (mysql) e che i pacchetti di ritorno viaggino correttamente verso lo spa server e quindi verso il client. Il file access.conf rimane invariato

Configurazione lato server

fwknopd.conf:

PCAP_INTF                   enp0s8;
ENABLE_IPT_FORWARDING       Y;
ENABLE_IPT_SNAT             Y;

Invocazione client

fwknop:

fwknop -n test -R -w /usr/bin/wget -A tcp/3306 -D 107.23.186.49 -N 10.0.0.132
mysql -h 107.23.186.49 -u  -p

4. SPA Ghost Service

Adesso vogliamo che l'accesso a mysql venga “nascosto” da un servizio legittimo esposto pubblicamente (un servizio http sulla porta 80).

La configurazione lato server (fwknopd.conf, access.conf) rimane invariata rispetto a prima.

Invocazione client

fwknop:

fwknop -n test -A tcp/80 -R -w /usr/bin/wget -D 107.23.186.49 -N 10.0.0.132:3306
mysql -h 107.23.186.49:80 -u  -p

E se volessi usare la crittografia asimmetrica?

La crittografia asimmetrica usata con hmac costituisce un ulteriore enhancement di sicurezza.

Mentre con la crittografia simmetrica+hmac si ha una sorta di implicito mutuo riconoscimento, con la crittografia asimmetrica è sufficiente che il client sia riconosciuto dal server.

Affinché ciò avvenga, il client inva il pacchetto spa firmato con la sua chiave privata e lo cifra con la chiave pubblica dello spaserver. Lo spaserver riceve il pacchetto, verifica la firma con la chiave pubblica del client, lo decifra con la sua chiave privata, proseguendo poi col resto del processo di autorizzazione e accesso.

È consigliata la creazione di chiavi apposite per fwknop, non quelle personali. Per il client creeremo una chiave di sola firma e per il server una chiave completa. Le corrispondenti chiavi private possono anche essere lasciate prive di password. Se non lo fossero, dovranno essere inserite nel file di configurazione in mancanza delle quali, soprattutto lato server, finirebbero per richiedere a runtime una poco gestibile interazione con l'utente.

The last but not the least, bisogna tenere presente che, come riportato dalla documentazione (https://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#fwknop-gpg) la scelta delle chiavi è un'operazione critica.

La cifratura asimmetrica, a differenza di quella simmetrica, tende a produrre dei payload decisamente più cicciotti. Quindi, per non correre il rischio di avere un payload che superi il default dell'MTU ethernet (1500 byte), bisogna “vincolare” la scelta della chiave del server (di cifratura) a quella del client (di firma).

Le chiavi a curva ellittica sarebbero una buona soluzione. Purtroppo funzionano solo per la firma, non per la cifratura. Quindi vanno bene per il client e non per il server.

Se client e server usassero chiavi rsa, sarebbe meglio per il server usare chiavi non superiori a 3072 bit (caso limite), consigliati 2048 bit. In questo modo un'eventuale chiave client di 4096 bit sarebbe tollerata. Altrimenti si rischierebbe un fault: fwknop: fko_spa_data_final: Error 59 - Args contain invalid data: FKO_ERROR_INVALID_DATA_ENCRYPT_GPG_RESULT_MSGLEN_VALIDFAIL

Nell'esempio che segue, prenderemo in esame lo scenario 4, ma con autenticazione GPG, con una chiave ECC per il client e una chiave rsa 3072 bit per il server (ma sarebbe tollerata anche una chiave a 4096 bit).

Creazioni delle chiavi su server e client

spa client

# Creazione chiave di sola firma
gpg --batch --passphrase '' --quick-gen-key "fwknop client (chiave del client fwknop) " ed25519 cert,sign never`

# esporta chiave pubblica e invio a spaserver
gpg -o fwknop@spaclient.gpg --export fwknop@spaclient
scp fwknop@spaclient.gpg 107.23.186.49:

spa server

# Creazione chiave di firma e cifratura. Quella di cifratura è una rsa 3072 bit
gpg --batch --passphrase '' --quick-gen-key "fwknopd server (chiave del server fwknopd) " ed25519 cert,sign never
gpg --batch --passphrase '' --quick-add-key '2BCD6BEF564A54362F8242017C17EC045408C7DB' rsa3072 encr never

# esporta chiave pubblica e invio al client
gpg -o fwknopd@spaserver.gpg --export fwknopd@spaserver
scp fwknopd@spaserver.gpg 107.23.186.160:

Importazioni e firma delle chiavi

# importazione e firma della chiave
gpg --import fwknopd@spaserver.gpg
gpg --sign-key fwknopd@spaserver

# importazione e firma della chiave
gpg --import fwknop@spaclient.gpg
gpg --sign-key fwknop@spaclient

Configurazione `access.conf.d/test.conf e .fwknoprc`

Analogamente a quanto fatto con la cifratura simmetrica:

access.conf.d/test_gpg.conf

SOURCE                      ANY
REQUIRE_SOURCE              Y
HMAC_KEY_BASE64             0xRNOSrVTy6B7PmBHiZG5jzTLwxsPrOd6kUb5/p45VjFfWp3eXMG8hVz4JRjoP89JbtMDhghghco7pV9cdQzdw==
GPG_ALLOW_NO_PW             Y  
GPG_REMOTE_ID               1B0D9549
GPG_DECRYPT_ID              5408C7DB

.fwknoprc

[test_gpg]
USE_GPG                     Y
GPG_RECIPIENT               5408C7DB
GPG_SIGNER                  1B0D9549
HMAC_KEY_BASE64             0xRNOSrVTy6B7PmBHiZG5jzTLwxsPrOd6kUb5/p45VjFfWp3eXMG8hVz4JRjoP89JbtMDhghghco7pV9cdQzdw==
USE_HMAC                    Y

Test client

fwknop --verbose -n test_gpg -A tcp/80 -R -w /usr/bin/wget -D 107.23.186.49 -N 10.0.0.132:3306
mysql -h 107.23.186.49:80 -u  -p

N.B.: Gli scenari 2, 3 e 4 sono le riproposizioni di ciò che viene presentato da Michael Rash durante lo ShmooCon del 2013 in https://www.youtube.com/watch?v=GCGiI6DJuIc (scenario 2) e nel suo blog (https://www.cipherdyne.org/blog/categories/port-knocking-and-spa.html) in https://www.youtube.com/watch?v=tz-xK1BarKk (scenario 3 e 4)

Ghost Service e SPA across gateway NAT non sono chiarissimi negli esempi forniti, mancano alcuni dettagli per me, che non sono un esperto di reti, fondamentali come la giusta evidenza e l'importanza sull'uso corretto del local nat nel primo caso e di SNAT negli altri due.

Tutti gli esempi, in particolare 3 e 4, sono stati testati con un'infrastruttura speculare a quella usata nel 2° video, ottenuta non già attraverso AWS ma con il più modesto VirtualBox che ha comunque svolto egregiamente il suo compito.

Per chi volesse effettuare delle prove sul campo, spero, in futuro, di mettere a disposizione questo piccolo laboratorio attraverso Vagrant e di dare indicazioni sulle configurazioni degli apparati che si occupano di routing e nat.

Osservazioni su access.conf

access.conf permette di stabilire chi accede e su quali risorse.

Le porte specificate nella clausola ACCESS permetteranno al clent di accedere con la stessa chiave:

a tutti i servizi relativi, se lo spaserver è installato sulla stessa macchina che li eroga;
a tutti i server relativi (eroganti i servizi indicati in ACCESS) nattati dallo spaserver;
ad uno solo dei servizi, e solo fra quelli “nattabili”, se nell'access.conf uso le clausole FORCE_NAT/SNAT, per quanto siano larghe le maglie della clausola ACCESS. Inoltre posso usare ACCESS per concedere o meno la possibilità di ghostare un servizio

Vediamo con un po' di esempi cosa possiamo fare

Questo scenario riprende ed estende quello visto finora, dove si evidenzia il natting sia dei client che dei server, entrambi nelle loro lan private.

A differenza degli scenari precedenti, lo spaserver non è direttamente esposto ma è anch'esso nel backend. Gli altri server espongono un server web sulla porta 8080, un remote-desktop sulla 3389 e un db mysql sulla 3306.

Per mostrare quanto fwknop possa essere flessibile, supponiamo di avere 3 utenti, Alice, Bob e Carol, ognuno con privilegi differenti. fwknop sarà configurato come bastion host.

Supponiamo sempre che lo spaserver esponga pubblicamente un sito web sulla porta 80 (utile per un eventuale ghosting dei servizi) .

Configurazione stanze con spa server come bastion host

La configurazione delle stanze richiederà al client anche di specificare l'utente.

access.conf.d/alice.conf

# alice
SOURCE                      ANY
REQUIRE_SOURCE              Y
SPOOF_USER                  
HMAC_KEY_BASE64             0xRNOSrVTy6B7PmBHiZG5jzTLwxsPrOd6kUb5/p45VjFfWp3eXMG8hVz4JRjoP89JbtMDhghghco7pV9cdQzdw==
GPG_ALLOW_NO_PW             Y  
GPG_REMOTE_ID               1B0D9549
GPG_DECRYPT_ID              5408C7DB

access.conf.d/bob.conf

# bob
SOURCE                      ANY
OPEN_PORTS                  tcp/3306, tcp/3389
SPOOF_USER                  
REQUIRE_SOURCE              Y
KEY_BASE64                  /bUdrMWFbc754iitBPAm2iwpzJ9CeetVxKXJOY0b9yI=
HMAC_KEY_BASE64             K22gfP5eq8Hveg58NeCWbXJEL/S/R74wGhxG3S6Gv+hl/bbqOZhExsRuLRrIvyZmW7iseEN8E48wHRQsUMozgA==

access.conf.d/carol.conf

# carol
SOURCE                      154.23.162.32/27, 154.23.162.96/27
OPEN_PORTS                  tcp/3306
SPOOF_USER                  
REQUIRE_SOURCE              Y
KEY_BASE64                  GK1CE1BE+ItAfZCMH9NPUkAd+rQv2mTm5df1wjN1w6w=
HMAC_KEY_BASE64             ewbyRRz2B7mqQnXRa7Mm67Qa4xIzr1/oyKAhHSQ7+rwtNcEZrZbXeHb97drG8ebZ06F7OOLjp1i9Fy+DtN3F7Q==

Alice

Con le stanze configurate in questo modo, alice, che ha una chiave gpg, può usare la stessa chiave da qualunque ip, per raggiungere uno qualunque fra i 3 server in backend. Es.

#webserver
fwknop -n alice -A tcp/8080 -R -w /usr/bin/wget -D 5.112.84.211 -U  -N 192.168.100.112

# remote-desktop
fwknop -n alice -A tcp/3389 -R -w /usr/bin/wget -D 5.112.84.211 -U  -N 192.168.100.25

# mysql
fwknop -n alice -A tcp/3306 -R -w /usr/bin/wget -D 5.112.84.211 -U  -N 192.168.100.109

Alice può anche “ghostare” il servizio, ad es. mysql

# mysql
fwknop -n alice -A tcp/80 -R -w /usr/bin/wget -D 5.112.84.211 -U  -N 192.168.100.109:3306

Bob

Bob può raggiungere il db o il server windows in remote desktop, non il webserver. Ad es.

# mysql
fwknop -n bob -A tcp/3306 -R -w /usr/bin/wget -D 5.112.84.211 -U  -N 192.168.100.109

Carol

A Carol invece è consentito solo l'accesso al db mysql e solo da due subnet specifiche.

Ad es.

# mysql
fwknop -n carol -A tcp/3306 -a 154.23.162.99 -D 5.112.84.211 -U  -N 192.168.100.109

Né Bob, né Carol possono ghostare servizi.

Riferimenti:

https://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html

#fwknop #spa #crittografia

Gestire la tua chiave GPG

Mon, 25 Nov 2024 15:00:37 +0000

Esistono numerose gui che semplificano la gestione di una chiave gpg.

Questo articolo ha lo scopo di semplificare la creazione di una chiave gpg attraverso la cli di GnuPG, senza entrare nel suo mare magnum di opzioni.

Premessa

Cosa NON è una chiave gpg? Una coppia di chiavi, una pubblica e una privata basate sulla crittografia asimmetrica.

Cos'è una chiave gpg? Non è solo una coppia di chiavi asimmetriche ma è un certificato. Dal punto di vista delle informazioni, una chiave gpg contiene:

informazioni identificative (nome, commento, email, foto, ecc)
informazioni non identificative (dati tecnici che fanno parte delle chiavi: scadenza, keyserver, algoritmi di hash e cifratura, revoker ecc.)

Una chiave gpg, in definitiva, è costituita da:

una chiave primaria (detta anche secret key o master key)
da una o più sottochiavi
da una serie di informazioni personali.

Ognuna di queste “chiavi” è in realtà una coppia di chiavi asimmetriche dotate delle seguenti autorizzazioni:

Certificazione: capacità della chiave di firmare, e quindi validare, le chiavi gpg di altri utenti.
Firma: capacità di firmare documenti.
Cifratura: capacità di cifrare documenti.
Autenticazione: capacità di autenticare l'utente su alcuni protocolli come TLS o SSH.

La certificazione, ossia la capacità di validare altre chiavi oltre la propria, è esclusiva della master key. Le altre autorizzazioni possono essere delegate alle sottochiavi.

Certificazioni e firma, garantiscono autenticazione, integrità e non ripudio del mittente. La cifratura garantisce confidenzialità. Le prime due sono da considerarsi più critiche e normalmente assegnate alla master key.

Una chiave può avere una o più proprietà. Di default, gpg crea una master key con autorizzazioni per firma e certificazione e una sottochiave con autorizzazioni per cifratura.

Gestione della chiave

Per la creazione e la gestione della chiave nei suoi elementi principali, vedremo:

come creare la chiave primaria
come aggiungere sottochiavi, uid
come modificare password o scadenza
come si certifica un'altra chiave con la nostra (firma di chiave)
come si cancellano localmente uid, sottochiavi e firme
come si revoca un certificato, una sottochiave, un uid o una certificazione
come si usa un keyserver per la pubblicazione e la ricerca delle chiavi

Creazione della chiave primaria

# gpg --quick-gen-key    , dove
# - : "uid_name (comment) "
# - : uno fra 'gpg --with-colons --list-config'
# - : cert|encr|sign
# - : 0 => illimitato, ny|nm|nd => n anni|mesi|giorni
gpg --quick-gen-key gandalf ed25519 cert 0

Crea una chiave gpg la cui secret key può solo certificare, l'uid è composto dal solo nome gandalf e ha scadenza illimitata.

gpg -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec   ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
	  8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid                   [ultimate] gandalf

Ecco la chiave appena creata, nella prima riga distinguiamo:

“sec”, sta per secret key
algoritmo/KeyID
data di creazione
capability ([C]=certify).

Nella riga successiva è visibile il fingerprint e nella terza, l'uid (gandalf). Questi elementi, come il KeyID, servono per indirizzare la chiave.

Una sintassi più completa sarebbe:

gpg --quick-gen-key "nome (commento) " algo cert|sign|encr

Per avere una lista degli algo:

gpg --with-colons --list-config

Aggiungere una sottochiave

Aggiungiamo le chiavi di firma e di cifratura con scadenza 5 anni e 1 anno rispettivamente

# gpg --quick-addgen-key    
gpg --quick-add-key 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B ed25519 sign 5y
gpg --quick-add-key 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B cv25519 encr 1y

Come prima, oltre alla secret key, ora sono visibili le sottochiavi (ssb, Secret SubKey) di firma e cifratura con le evidenze per: algoritmo, KeyID, creazione, capability ([S] per sign e [E] per encrypt) e scadenza.

gpg -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec   ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
	  8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid                   [ultimo] gandalf
ssb   ed25519/0xA391F0548FB542DB 2024-11-05 [S] [scadenza: 2029-11-04]
ssb   cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [scadenza: 2025-11-05]

Meccanismi di indirizzamento per una chiave

Una chiave può essere riferita attraverso l'uid, il key ID o il fingerprint. Il riferimento è importante nelle operazioni di manipolazione della chiave.

gpg --with-subkey-fingerprint -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec   ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
	  8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid                   [ultimate] gandalf
uid                   [ultimate] Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) 
ssb   ed25519/0xA391F0548FB542DB 2024-11-05 [S] [expires: 2029-11-04]
	  87EF9CF3D5A4D78ADA80E364A391F0548FB542DB
ssb   cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [expires: 2025-11-04]
	  4DD33D36C54E2247486C9DC7AAEF649D51D832E8

0xE01BDCB6A3C6778B è il key ID della master key
8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B è il fingerprint della master key
gandalf è uno degli uid

Aggiungere un uid

Aggiunge un nuovo uid in termini di nome-commento-email e lo battezza come primario.

# gpg --quick-add-uid  
gpg --quick-add-uid gandalf "Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) "

# gpg --quick-set-primary-uid  
gpg --quick-set-primary-uid "gandalf" "Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) "

Firmare una chiave

Ossia riconoscere una chiave gpg come valida attraverso la certificazione. Pubblicare questa chiave sul keyserver, comunica al mondo che riconosciamo quella chiave come valida.

Convalida tutti gli uid della chiave identificata da

# gpg --quick-sign-key 
gpg --quick-sign-key AD59879E1CB5D63E98F05FB9204621DACB1296E0

Convalida un uid specifico della chiave identificata da

# gpg --quick-sign-key  
gpg --quick-sign-key AD59879E1CB5D63E98F05FB9204621DACB1296E0 frodo

Modificare la password

Inserisce la password con cui tutte le chiavi private (master key e subkey) relative all'uid indicato, vengono cifrate. Se la password viene lasciata vuota, la chiave non viene cifrata.

# gpg --passwd 
gpg --passwd gandalf

Modificare la scadenza

Modifico le scadenze delle chiavi come segue:

la master key da illimitata a 10 anni
la sottochiave di firma da 5 anni a 4 anni
la sottochiave di cifratura da 1 anno a 2 anni

# gpg --quick-set-expire  
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 10y
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 4y 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB
gpg --quick-set-expire 8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B 2y 4DD33D36C54E2247486C9DC7AAEF649D51D832E8

gpg --with-subkey-fingerprint -K
/home/gandalf/.gnupg/pubring.kbx
--------------------------------
sec   ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C] [expires: 2034-11-04]
	  8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid                   [ultimate] gandalf
uid                   [ultimate] Gandalf Il Bianco (Questa è la chiave di Gandalf Il Bianco) 
ssb   ed25519/0xA391F0548FB542DB 2024-11-05 [S] [expires: 2028-11-04]
	  87EF9CF3D5A4D78ADA80E364A391F0548FB542DB
ssb   cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [expires: 2026-11-04]
	  4DD33D36C54E2247486C9DC7AAEF649D51D832E8

Cancellazione di elementi dal keyring

La cancellazione di elementi come uid, firme o sottochiavi ha effetto solo sul keyring locale. Se la chiave è stata pubblicata su un repository, le cancellazioni non avranno alcun effetto. Se si vuole inibire uno di questi elementi, si deve ricorrere alla revoca che è esportabile sui keyserver.

Cancellare una sottochiave

Cancella la sottochiave di firma

# gpg --delete-secret-and-public-keys 
gpg --delete-secret-and-public-keys 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB!
# o, equivalentemente
gpg --delete-secret-and-public-keys 0xA391F0548FB542DB!

Cancellare un uid

Cancella la seconda identità della chiave gandalf (0xA391F0548FB542DB)

# gpg --edit-key [KeyID|fpr|uid]
gpg --edit-key gandalf
    uid 2
    deluid
    save

Cancellare una firma

Cancella tutte le firme del 2° uid che non siano self-signature.

# gpg --edit-key [KeyID|fpr|uid]
gpg --edit-key gandalf
    uid 2
    delsig
    save

Operazioni di revoca

Per quel che riguarda le chiavi gpg (i certificati) di cui si possiede la chiave privata, l'operazione di revoca può avvenire su uno degli elementi della chiave o sull'intero certificato.

Revocare un uid

Revoco l'uid (gandalf il grigio),

# gpg --quick-revuid   
gpg --quick-revuid gandalf "gandalf il grigio"

Revocare una sottochiave

# gpg --edit-key [KeyID|fpr|uid]
gpg --edit-key 0xA391F0548FB542DB
    key 1
    revkey
    save

Revocare una nostra certificazione

Così come validiamo le chiavi altrui con la nostra firma di certificazione, allo stesso modo possiamo revocarla.

Revoco la mia firma su tutti gli uid di una chiave pubblica

# gpg --quick-revoke-sig   
gpg --quick-revoke-sig 0x204621DACB1296E0 0xE01BDCB6A3C6778B

Posso anche revocare la mia firma su un uid specifico

# gpg --quick-revoke-sig   
gpg --quick-revoke-sig 0x204621DACB1296E0 0xE01BDCB6A3C6778B frodo_uid2

Revocare l'intero certificato

Va a revocare non solo tutti gli uid e tutte le sottochiavi, ma anche la masterkey.

gpg --import 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB.rev

Il certificato di revoca viene generato all'atto della creazione della chiave. Se non ci fosse, conviene sempre crearlo così che, se la master key venisse compromessa, saremmo almeno in grado di revocare l'intero certificato.

# gpg -o  --gen-rev 
gpg -o 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB.rev --gen-rev 87EF9CF3D5A4D78ADA80E364A391F0548FB542DB

Le operazioni di revoca, nel mondo gpg, corrispondono alle maledizioni senza perdono, nel mondo di Harry Potter. Non si torna indietro a meno di un backup, e se le revoche vengono pubblicate su un keyserver, diventano irreversibili.

Operazioni sul keyserver

Il caricamento delle chiavi su un keyserver costituisce la finalizzazione delle operazioni svolte finora.

Il keyserver pubblica al mondo le nostre chiavi, la configurazione avviene nel file dirmngr.conf aggiungendo una riga (ad es. per keys.openpgp.org):

vi dirmngr.conf

...
keyserver hkps://keys.openpgp.org
...

e ricaricando la configurazione:

gpgconf --reload dirmngr

Cerca

Cerca nel keyserver le chiavi con uid specificato. In caso di successo, chiede se possono essere aggiunte al keyring.

# gpg --search-keys 
gpg --search-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0

Per gli utilizzatori di keys.openpgp.org:

gpg --auto-key-locate keyserver --locate-keys

Invia

Invia una lista di chiavi al keyserver

# gpg --send-keys 
gpg --send-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0

Per gli utilizzatori di keys.openpgp.org: Il classico send non è sufficiente perché non sarebbe possibile validare la mail di conferma. Si consiglia, non volendo usare l'interfaccia web, di usare il seguente comando:

# gpg --export  | curl -T - https://keys.openpgp.org
gpg --export 0xE01BDCB6A3C6778B | curl -T - https://keys.openpgp.org

che restituisce un link diretto alla pagina di verifica.

Ricevi

Scarica dal keyserver le chiavi

# gpg --keyserver-options honor-keyserver-url --receive-keys 
gpg --keyserver-options honor-keyserver-url --receive-keys 0xE01BDCB6A3C6778B 0x204621DACB1296E0

Scarica dal keyserver la chiave indicata dall'uri

# gpg --fetch-keys 
gpg --fetch-keys https://keyserver.ubuntu.com/pks/lookup?search=0xE01BDCB6A3C6778B&fingerprint=on&op=index

Aggiorna

Per rinnovare tutte le chiavi pubbliche del keyring.

gpg --keyserver-options honor-keyserver-url --refresh-keys

Come proteggere il nostro keyring

Come visto in precedenza, suggerisco di creare la master key per la sola certificazione e le due sottochiavi per firma e cifratura (anche quando la chiave primaria dovesse contenere altre autorizzazioni).

Questo permetterebbe, volendo ma non è necessario, di ruotare più agevolmente le chiavi di firma e cifratura svincolandole dalla certificazione.

Inoltre, così è più semplice rendere le chiavi gpg “partially stripped”, chiavi la cui sola secret key sia mancante della chiave privata, cosicché, se queste venissero smarrite o trafugate, la secret key in nostro possesso ci permetterebbe immediatamente di generare un certificato di revoca per le sottochiavi compromesse, generare delle nuove sottochiavi di firma e cifratura e di distribuire il tutto ad un keyserver.

Chiavi gpg siffatte permetterebbero di svolgere le consuete operazioni di firma e cifratura documentale (quello che potremmo definire “utilizzo giornaliero”) ma impedirebbero qualunque operazione critica sulla propria chiave gpg (impossibilità di aggiungere, revocare sottochiavi o uid, di alterare scadenza o password ecc.) e su quelle altrui (certificare e quindi validare altre chiavi) poichè è la chiave privata della master key a sigillare self-signed le informazioni della chiave gpg.

In generale, posso estrarre la chiave privata da qualunque coppia di chiavi, siano esse sottochiavi o master key, ma non è uno scenario molto comune. Per estensione, eliminandole tutte otterremo un insieme di chiavi pubbliche (quella che otterrei anche con gpg —export ).

Quello che invece ci interessa è eliminare la chiave privata della sola master key. L'eliminazione della chiave privata dalla master key, di per sè, non è un'operazione particolarmente onerosa.

La vera “difficoltà” risiede nel cambio di paradigma per l'utente che l'utilizzo di master key stripped comporta, perché avremo a che fare con un keyring da proteggere accuratamente e dei keyring da “trincea” da usare liberamente sui nostri device.

Realizzare un keyring per l'uso quotidiano

Per farlo dobbiamo eliminare le chiavi private di tutte le master key del nostro keyring e per farlo dobbiamo fare un po' di assunzioni.

Come primo passo, bisogna spostare, se non è stato già fatto, il keryring dal pc/laptop/device ad un luogo sicuro (ad es. pendrive cifrata)
quindi si devono estrarre le chiavi private dalle master key e distribuirle dove possano servire
in caso di emergenza o se vi è necessità di modificare le chiavi, importare le chiavi gpg dal dispositivo sicuro, effettuare le modifiche, rigenerare e ridistribuire le nuove chiavi stripped

Eliminazione della chiave privata dalla master key

La cancellazione della chiave privata impedisce alla master key o alla sottochiave di esercitare pienamente le funzioni indicate dalle proprie autorizzazioni ossia certificazione, firma o decifratura.

Per intervenire sulla singola chiave privata, occorre individuare il suo fingerprint o il suo keyid e usarlo per cancellare postponendo il carattere “!”.

Ad es. sulla master key di gandalf:

gpg --delete-secret-keys 0x055D271BD85313D0!

Il carattere “#” (accanto a sec) vuol dire che la chiave privata è stata eliminata

gpg -K
/home/gandalf/ramfs_gpg/pubring.kbx
-----------------------------------
sec#  ed25519/0xE01BDCB6A3C6778B 2024-11-05 [C]
	  8C8EC405954D4ABB32CFA431E01BDCB6A3C6778B
uid                   [ultimo] gandalf
ssb   ed25519/0xA391F0548FB542DB 2024-11-05 [S] [scadenza: 2029-11-04]
ssb   cv25519/0xAAEF649D51D832E8 2024-11-05 [E] [scadenza: 2025-11-05]

Generalizzando, per realizzare il nostro keyring di lavoro si può agire, una tantum, in questo modo:

1. spostiamo il keyring di lavoro sul dispositivo sicuro

KEYRING_RAMFS=
KEYRING_VAULT=
KEYRING_WORK=
export GNUPGHOME=${KEYRING_WORK}; cd $GNUPGHOME

rsync -avp ${KEYRING_WORK}/ ${KEYRING_VAULT}/

2. rendiamo il keyring stripped cancellando le chiavi private di tutte le master key.

for FPR in $(gpg --with-colons -K|grep sec -A 1|grep fpr|cut -d ":" -f 10); do 
    gpg --batch --yes --delete-secret-keys "${FPR}!"
done

In seguito, come detto in precedenza, per lavorare sul keyring occorrerà ripristinarlo dal dispositivo sicuro, ad es. una pendrive cifrata.

Per non lasciare tracce su altri device che non sia la pendrive cifrata, si possono seguire due strade.

usare una distribuzione live (più sicura)
montare una partizione in ram su ramfs (non usa lo swap) su cui caricare il keyring.

La prima via è certamente preferibile. Non c'è alcun uso dei dispositivi di storage fisici della macchine, solo quelli volatili, ma presuppone che si possa avviare un SO da pendrive. La seconda è più accessibile per certi versi ma presuppone che si possiedano i privilegi per montare una partizione su ram.

Mostrerò la seconda via che è più articolata.

Lavorare con un keyring effimero

La strategia è quella di avere un keyring effimero montato su ramfs che farà da tramite fra il keyring master (su pendrive cifrata) e il keyring di lavoro.

L'obiettivo finale è quello di rendere strutturale il fatto di riuscire a compiere operazioni sul keyring usando il meno possibile i dispositivi di storage.

0. Init

KEYRING_RAMFS=
KEYRING_VAULT=
KEYRING_WORK=

1. Monto la partizione effimera

mkdir -p ${KEYRING_RAMFS}
sudo mount -t ramfs -o size=10M ramfs ${KEYRING_RAMFS}
sudo chown $(logname):$(logname) ${KEYRING_RAMFS}

2. Esporto chiavi pubbliche e trust dal keyring di lavoro

gpg -o ${KEYRING_RAMFS}/keyring_pubkeys.gpg --export
gpg --export-ownertrust > ${KEYRING_RAMFS}/keyring_ownertrust.txt

3. Copio il keyring master sulla partizione effimera, modifico GNUPGHOME in modo che gpg lavori direttamente sulla partizione effimera. Su questo keyring effimero, completo l'allineamento importando le chiavi pubbliche e il trust provenienti dal keyring di lavoro.

rsync -avp ${KEYRING_VAULT}/ ${KEYRING_RAMFS}/
export GNUPGHOME=${KEYRING_RAMFS}; cd $GNUPGHOME
gpg --import keyring_pubkeys.gpg
gpg --import-ownertrust keyring_ownertrust.txt

4. Eseguo le mie manipolazioni sul keyring effimero: uid, key, passwd, firme, revoche ecc.

...
[operazioni gpg]
...

5. Copio il keyring master dalla partizione effimera alla pendrive cifrata

rsync -avp ${KEYRING_RAMFS}/ ${KEYRING_VAULT}/

6. Rendo il keyring effimero di nuovo stripped

for FPR in $(gpg --with-colons -K|grep sec -A 1|grep fpr|cut -d ":" -f 10); do 
    gpg --batch --yes --delete-secret-keys "${FPR}!"
done

7. Ripristino il keyring di lavoro escludendo i certificati di revoca e cancellando la partizione effimera

rsync -avp --exclude openpgp-revocs.d ${KEYRING_RAMFS}/ ${KEYRING_WORK}/
export GNUPGHOME=${KEYRING_WORK}/
sudo umount ${KEYRING_RAMFS}; rmdir ${KEYRING_RAMFS}

La complessità di questa gestione può essere ridotta rendendo scriptabili i due blocchi (1,2,3) e (5,6,7), ad es. immaginando di avere a disposizione delle funzioni come gpg-vault [open|close|status], avendo la consapevolezza che, se usate male, possono essere delle operazioni distruttive.

Cos'è un keyerver

Il keyserver è il luogo in cui pubblichiamo le nostre chiavi per renderle disponibili agli altri utenti.

Inizialmente i keyserver avevano una logica p2p, distribuita e decentralizzata ottenuta con un'implementazione chiamata SKS (Synchronizing Key Server) basata sulla rapida diffusione delle chiavi fra keyserver.

I keyserver inizialmente servivano anche a realizzare il WOT (Web Of Trust) per la convalida delle chiavi.

Col tempo, la mancanza di aggiornamenti del protocollo sks e la suscettibilità ad attacchi di tipo “key poisoning”, che possono rendere indisponibili interi certificati (ad es. riempiendo la chiave con innumerevoli firme contenenti tonnellate di dati tali da far crashare i client) o gli stessi keyserver (pubblicando quantitivi enormi di certificati non validi), amplificata dalle caratteristiche di sincronizzazione dei server, ne hanno decretato la fine.

La realizzazione del WOT, tra l'altro, offriva pubblicamente una tale quantità di chiavi che permetteva, da un lato, di tracciare interi social network basati sulle firme che vi venivano apposte, dall'altro, di essere un formidabile serbatoio di email e altri dati sensibili a disposizione di attori malevoli, spammer e altro.

Inoltre leggi recenti sulla privacy come GDPR, cozzavano contro la natura immutabile dei keyserver che, by design, aggiungono chiavi e non permettono la cancellazione.

Modelli recenti

I modelli di keyserver successivi mitigano (ma non risolvono completamente) queste debolezze:

rinunciando alla federazione e alla distribuzione
sposando un modello basato sul controllo dell'email prima dell'accettazione della chiave
ricorrendo a limitazioni, filtri e valutazioni sulla bontà delle chiavi prima che queste vengano accettate.

I principali modelli di keyserver sono:

Hagrid
Mailvelope
HockeyPuck

Sono stati tutti creati per sopperire ai limiti dei server SKS.

Hagrid

Il primo, basato su SequoiaPGP, ha una natura centralizzata (non sarà mai federato), è GDPR compliant ed ha dato luogo a keys.openpgp.org.

I keyserver di questo tipo non aderiscono al modello WOT per ragioni di privacy e di efficienza. Sono quindi rifiutate le chiavi di terze parti, essenziali nel modello WOT, l'accettazione della chiave pubblica è vincolata dalla verifica dell'email, è possibile rimuovere le chiavi. Sono più resistenti agli attacchi di key poisoning.

Mailvelope

Ha dato luogo al keyserver keys.mailvelope.com, molto simile al primo e ne condivide la politica: no federazione, niente firme di terze parti e verifica dell'email vincolante per l'accettazione della chiave.

A differenza di altri keyserver, il focus di Mailvelope è la semplificazione dell'utilizzo della crittografia sull'e-mail, che sia webmail, con i provider e i browser che supportano Mailvelope, o client, quando si integrino con le sue api.

Hockeypuck

È un ritorno alle origini, ha una natura federata ed è considerato l'alternativa robusta ai server SKS. Uno fra i più noti server hockeypuck è certamente:

keyserver.ubuntu.com

il keyserver gestito dalla comunità Ubuntu che contiene le chiavi per i suoi pacchetti ma è anche aperto al pubblico.

Un altro keyserver hockeypuck più di nicchia perché legato ad una specifica realtà tecnologica olandese è:

pgp.surf.nl

Sebbene possa essere meno aggiornato del primo, può essere usato liberamente per pubblicare le proprie chiavi.

I keyserver di questo tipo, come il pool di server sks, anche se con un filtraggio più stringente, abbracciano il modello WOT con tutto quello che ne consegue.

Altri keyserver

Infine, per dovere di cronaca, bisogna citare due decani dei keyserver apparsi all'alba di pgp e ormai non più utilizzabili per motivi di obsolescenza e di abbandono.

pgp.mit.edu: uno dei primi repository a permettere la pubblicazione e la distribuzione di chiavi pubbliche, facente anche parte della rete SKS.

global.pgp.com: l'alternativa proprietaria, appartenente a PGP Corporation prima e Symantec dopo, era il repository centralizzato per la distribuzione di chiavi usato dall'applicazione pgp.

In conclusione, se la necessità è di utilizzare il WOT, allora la scelta è senza dubbio Hockeypuck quindi keyserver.ubuntu.com. Se invece la privacy è prioritaria, Hagrid quindi keys.openpgp.org diventa la scelta obbligatoria, tanto che è il default sia di GPG che di OpenKeyChain

#gpg #gnupg #crittografia #keyserver #hagrid #hockeypuck #mailvelope

Script per la gestione della configurazione di una vpn wireguard

Sun, 22 Sep 2024 13:27:09 +0000

Cos'è wireguard e come si configura, lo sappiamo ma mi serviva qualcosa che mi permettesse di fare provisioning e deprovisioning dei certificati in maniera più semplice di quanto già si faccia con i tool disponibili nella userland, wg e wg-quick.

E questo è il motivo principale per cui è nato questo script. Prende come riferimento una configurazione road warrior, il primo scenario di una topologia point-to-site, quella più comune.

Alcune considerazioni

Lo script definisce una workdir dove deposita tutte le configurazioni e i certificati. Le precondizioni sono legate alla presenza dei tool userland wg-tools (ovviamente) e di ufw. Vengono comunque verificate nello script.
Altra semplificazione è data dal fatto di allocare una /24 come rete wireguard. 254 host per una rete domestica sono più che sufficienti.
L'allocazione degli ip viene fatta con un progressivo memorizzato nel file 'ip_renew'. Gli ip dei certificati revocati vengono mantenuti in un file, 'ip_release'. Quando si crea un nuovo certificato, si controlla prima che ci sia un ip da recuperare in ip_release. Se la lista è vuota si ricorre al progressivo.
La creazione della configurazione lato server passa da due file di configurazione: una configurazione globale ottenuta tracciando l'evoluzione iniziale in termini di aggiunta o rimozione dei client peer e destinata al rilascio in esecuzione. L'altra contenente la sola configurazione del server e usata unicamente per la rigenerazione della configurazione globale a partire dai peer esistenti.
L'operazione di init è propedeutica per addclient, removeclient, rebuild, deploy, share.

Le operazioni a disposizione sono:

init: inizializza la configurazione di un server wireguard
addclient: crea il certificato lato client e aggiunge il relativo peer sulla configurazione del server
removeclient: cancella il certificato lato client e rimuove il relativo peer sulla configurazione del server
rebuild: rigenera la configurazione del server usando i certificati client esistenti
deploy: finalizza la configurazione riavviando il servizio con le nuove impostazioni
share: crea i qr-code per i certificati client da utilizzare nelle configurazioni

Per tutto il resto, i commenti nel codice sono abbastanza esplicativi.

Lo script

#!/bin/bash

# Questo è il file di configurazione globale, i dati sono fittizi.
# Può essere mantenuto nello script o nella home dell'utente 
# (es. $HOME/.config/wg_man.conf) e importato 
# con 'source' all'inizio.
WG_INTERFACE=wg0
PHYSICAL_INTERFACE=eth0
NETWORK="192.168.15.0"
SUBNET_MASK="24"
SERVER_IP_ADDRESS="192.168.15.1"
DNS="1.1.1.1"
LISTEN_PORT="51820"
ENDPOINT=wireguard.nodns.net:51820"
WORKDIR="$HOME/wireguard"



check_dependency() {
    if test -e /usr/sbin/ufw; then
        if test -e /usr/bin/wg; then
            return 0
        else
            return 2
        fi
    else
        return 1
    fi
}



is_init() {
    test -e ${WORKDIR}/conf.d/server_wg.conf && return 0 || return 1
}



# Genera la chiave privata
gen_priv_key() {
    wg genkey | tee ${WORKDIR}/keys/$1_privkey
}



# Genera la pre-shared key
gen_client_psk() {
    # Evita il warning sui permessi del file che devono essere 600
    umask 077
    wg genpsk | tee ${WORKDIR}/psk/$1_psk
}



# Rilascio di un nuovo indirizzo ip. Questa funziona viene invocata da
# addclient().
#
# I primi 3 ottetti li ottengo dalla variabile globale NETWORK.
# L'ultimo ottetto, relativo all'host, lo ricavo dalla lista degli ip
# riutilizzabili ("ip_release").
#
# Se non è vuota, prelevo il primo e lo rimuovo dalla lista. Se è vuota,
# prelevo l'ultimo ottetto da "ip_renew" e lo incremento per il successivo
# assegnamento.
ip_renew() {
    # Selezioni i primi 3 ottetti del network
    SUB_IP=$(echo ${NETWORK}|awk -F "." '{print $1"."$2"."$3}')

    if [[ ! -e ${WORKDIR}/conf.d/ip_release || ! -s ${WORKDIR}/conf.d/ip_release ]]; then
        # Genero il nuovo ip (Incremento di 1 l'ultimo ottetto)
        IP=$(cat ${WORKDIR}/conf.d/ip_renew)
        echo $((++IP)) > ${WORKDIR}/conf.d/ip_renew

        # Restituisco i 3 ottetti + il quarto
        #echo -n ${SUB_IP};cat ${WORKDIR}/conf.d/ip_renew
    else
        IP=$(head -n 1 ${WORKDIR}/conf.d/ip_release)
        sed -i "1d" ${WORKDIR}/conf.d/ip_release
    fi
    echo -n ${SUB_IP}"."${IP}
}



# Riallocazione di un indirizzo ip. Questa funzione viene invocata da
# removeclient().
# Aggiungo l'ultimo ottetto alla lista degli ip riallocabili.
# @par 1: ultimo ottetto.
ip_release() {
    echo $1|cut -d"." -f 4 >> ${WORKDIR}/conf.d/ip_release
}



# Aggiunge il nuovo peer al file di configurazione del server
# @par 1: CLIENT_PUBLIC_KEY
# @par 2: CLIENT_PSK
# @par 3: CLIENT_IP_ADDRESS
# @par 4: CLIENT_NAME
add_peer_to_server() {
    cat >> ${WORKDIR}/conf.d/server_wg.conf << EOF
# $4
[Peer]
PublicKey = $1
PresharedKey = $2
AllowedIPs = $3/32
PersistentKeepalive = 25

EOF
}



# Inizializza la configurazione del server wireguard.
#
# Questa operazione può essere fatta una sola volta a meno che non si
# cancelli tutta la workdir.
#
# Verranno creati due file  di configurazione: server_wg.conf e 
# server_wg_raw.conf
#
# Il primo conterrà la configurazione completa del server e dei peer,
# verrà aggiornato ad ogni modifica dei client (aggiunta o rimozione) e
# verrà usato per il deploy della configurazione.
#
# Il secondo conterrà la configurazione del solo server e verrà usato
# solo per rigenerare il primo file di configurazione.
init() {
    # Controllo che wireguard sia almeno abilitato
    echo -n "Inserire la password di Amministratore: "; read -s PASSWORD
    sudo -k
    if echo $PASSWORD|sudo -S echo "got a root" > /dev/null; then
        if ! sudo systemctl is-enabled --quiet wg-quick@${WG_INTERFACE}; then
            echo -en "\nAttivazione servizio wireguard... "
            #sudo systemctl enable --quiet wg-quick@${WG_INTERFACE}
            echo "fatto."
        fi
        sudo -k 
        
        #Verifico che queste cartelle esistano. Se lo sono, non faccio nulla, se no le creo.
        echo -n "Creazione workdir... "
        [[ ! -e ${WORKDIR}/conf.d || ! -e ${WORKDIR}/psk  || ! -e ${WORKDIR}/keys ]] \
            && { mkdir -p ${WORKDIR}/{conf.d,keys,psk}; } \
            || { echo "inizializzazione già effettuata."; exit; }
        echo "fatto."
        
        # Genero la chiave privata per il server
        echo -n "Creazione chiave private del server..."
        SERVER_PRIV_KEY=$(gen_priv_key "server_wg")
        echo "fatto."

        # Genero il file di configurazione
        echo -n "Inizializzazione del server... "
        cat > ${WORKDIR}/conf.d/server_wg.conf << EOF
[Interface]
Address = ${SERVER_IP_ADDRESS}/${SUBNET_MASK}
# SaveConfig = true

PreUp = ufw route allow in on ${WG_INTERFACE} out on ${PHYSICAL_INTERFACE} log from ${NETWORK}/${SUBNET_MASK} to 0.0.0.0/0
PostDown = ufw route delete allow in on ${WG_INTERFACE} out on ${PHYSICAL_INTERFACE} log from ${NETWORK}/${SUBNET_MASK} to 0.0.0.0/0

# IP masquerading
PreUp = iptables -t nat -A POSTROUTING -o ${PHYSICAL_INTERFACE} -s ${NETWORK}/${SUBNET_MASK} -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o ${PHYSICAL_INTERFACE} -s ${NETWORK}/${SUBNET_MASK} -j MASQUERADE

# IP filtering
PreUp = ufw allow in on ${PHYSICAL_INTERFACE} log to 0.0.0.0/0 app Wireguard
PostDown = ufw delete allow in on ${PHYSICAL_INTERFACE} log to 0.0.0.0/0 app Wireguard

ListenPort = ${LISTEN_PORT}
PrivateKey = ${SERVER_PRIV_KEY}

EOF
        echo "fatto."
        cp ${WORKDIR}/conf.d/server_wg.conf ${WORKDIR}/conf.d/server_wg_raw.conf
        # Inizializza l'erogatore di ip
        echo 1 > ${WORKDIR}/conf.d/ip_renew
    else
        echo "Sono necessarie le credenziali di amministrazione per eseguire questo comando."
        exit 1
    fi
}



# Genera un certificato per il client composto da:
# * chiave privata del client
# * chiave pre-condivisa
# * client ip
# * chiave pubblica del server
# * nome simbolico del client
#
# Dopo la creazione e il salvataggio in /conf.d, verrà aggiunto
# il relativo peer nella configurazione del server (server_wg.conf).
# @par_1 @par_2 @par_3...: lista di nomi relativi ai certificati da creare.
add_client() {
    if is_init; then
        # Se non c'è alcun input, esco.
        if [[ $# -lt 1 ]]; then
            echo -e "Devi inserire almeno un nome."
            exit 1
        else
            # Per ogni nome presente in input, creo una configurazione 
            # client e l'aggiungo alla configurazione del server.
            for CLIENT_NAME in "$@"; do
                echo -n "Creazione certificato per il client \"${CLIENT_NAME}\"... "
                
                # Controllo se la configurazione esista già discriminando
                # in base al nome del file.
                if [[ -e ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf ]]; then
                    echo "già esistente."
                else
                    # Creo la configurazione del client
                    CLIENT_PRIV_KEY=$(gen_priv_key ${CLIENT_NAME})
                    CLIENT_PUBLIC_KEY=$(echo ${CLIENT_PRIV_KEY} | wg pubkey)
                    CLIENT_PSK=$(gen_client_psk ${CLIENT_NAME})
                    CLIENT_IP_ADDRESS=$(ip_renew)
                    SERVER_PUBLIC_KEY=$(grep PrivateKey ${WORKDIR}/conf.d/server_wg.conf | cut -d " " -f 3 | tr -d " " | wg pubkey)
                    CLIENT_NAME_UPPER=$(echo ${CLIENT_NAME} | tr '[:lower:]' '[:upper:]')
                    cat > ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf << EOF
    # ${CLIENT_NAME_UPPER}
    [Interface]
    Address = ${CLIENT_IP_ADDRESS}/${SUBNET_MASK}
    DNS = ${DNS}
    PrivateKey = ${CLIENT_PRIV_KEY}

    [Peer]
    PublicKey = ${SERVER_PUBLIC_KEY}
    PresharedKey = ${CLIENT_PSK}
    AllowedIPs = 0.0.0.0/0
    Endpoint = ${ENDPOINT}
    PersistentKeepalive = 25
EOF
                    echo "fatto."
                    echo -n "Aggiunta peer \"${CLIENT_NAME}\" al file di configurazione del server... "
                    
                    # Aggiungo il peer alla configurazione del server.
                    add_peer_to_server ${CLIENT_PUBLIC_KEY} ${CLIENT_PSK} ${CLIENT_IP_ADDRESS} ${CLIENT_NAME_UPPER}
                    echo -e "fatto.\n"                
                fi
            done
        fi
    else
        echo "È necessario inizializzare il server con 'wg_init.sh init'."
        echo "L'operazione richiesta non sarà completata"
    fi
}



# Rimuove file di configurazioni, chiavi e pre-shared key realtive a file
# dati in input.
# Rimuove inoltre il peer dal file di configurazione server_wg.conf.
# @par_1 @par_2 @par_3...: lista di nomi relativi ai certificati da rimuovere.
remove_client() {
    if is_init; then
        if [[ $# -lt 1 ]]; then
            echo -e "Devi inserire almeno un nome."
            exit 1
        else
            for CLIENT_NAME in "$@"; do
                echo -n "Rimozione client \"${CLIENT_NAME}\"... "
                if [[ ! -e ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf ]]; then
                    echo "non esistente."
                else
                    # Estraggo l'ultimo ottetto dell'ip del client.
                    IP=$(grep "Address" ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf|cut -d " " -f 3|tr -d " "|cut -d "/" -f 1)
                    
                    # Lo inserisco nella lista degli ip riallocabili.
                    ip_release ${IP}
                    
                    # Cancello file di configurazione, chiave e psk del client.
                    rm ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf ${WORKDIR}/keys/${CLIENT_NAME}_privkey ${WORKDIR}/psk/${CLIENT_NAME}_psk
                    echo "terminata con successo."
                    echo -n "Rimozione peer \"${CLIENT_NAME}\" dal file di configurazione del server... "
                    
                    # Rimuovo il peer dalla configurazione del server.
                    CLIENT_NAME_UPPER=$(echo ${CLIENT_NAME} | tr '[:lower:]' '[:upper:]')
                    sed -i "/# ${CLIENT_NAME_UPPER}/,+6d" ${WORKDIR}/conf.d/server_wg.conf
                    echo -e "terminata con successo.\n"   
                fi
            done
        fi
    else
        echo "È necessario inizializzare il server con 'wg_init.sh init'."
        echo "L'operazione richiesta non sarà completata"
    fi
}



rebuild() {
    if is_init; then
        # Rigenero il file di configurazione del server da server_wg_raw.conf.
        echo -n "Ripristino del file di configurazione del server... "
        cat ${WORKDIR}/conf.d/server_wg_raw.conf > ${WORKDIR}/conf.d/server_wg.conf
        echo "fatto."
        
        # Per ogni file di configurazione client, aggiungo il relativo peer
        # nel file di configurazione server_wg.conf.
        for FILE_CONF in ${WORKDIR}/conf.d/client_*.conf; do
            CLIENT_PUBLIC_KEY=$(grep "PrivateKey" ${FILE_CONF}|cut -d " " -f 3|tr -d " " | wg pubkey)
            CLIENT_PSK=$(grep "PresharedKey" ${FILE_CONF}|cut -d " " -f 3|tr -d " ")
            CLIENT_IP_ADDRESS=$(grep "Address" ${FILE_CONF}|cut -d " " -f 3|tr -d " "|cut -d "/" -f 1)
            CLIENT_NAME_UPPER=$(grep "#" ${FILE_CONF} | cut -d " " -f 2)
            echo -n "Aggiunta peer \"$(echo ${CLIENT_NAME_UPPER} | tr '[:upper:]' '[:lower:]')\"... "
            add_peer_to_server ${CLIENT_PUBLIC_KEY} ${CLIENT_PSK} ${CLIENT_IP_ADDRESS} ${CLIENT_NAME_UPPER}
            echo -e "fatto."
        done
    else
        echo "È necessario inizializzare il server con 'wg_init.sh init'."
        echo "L'operazione richiesta non sarà completata"
    fi
}



# Avvia il server wireguard con la nuova configurazione
deploy() {
    if is_init; then
        echo -n "Inserire la password di Amministratore: "; read -s PASSWORD
        sudo -k
        if echo $PASSWORD|sudo -S echo "got a root" > /dev/null; then
   
            # Stoppo il servizio wireguard
            echo -ne "\nStop wireguard... "
            sudo systemctl stop wg-quick@${WG_INTERFACE}
            echo "fatto."
            
            # Aggiorno la configurazione
            echo -n "Copia della nuova configurazione... "
            sudo cp ${WORKDIR}/conf.d/server_wg.conf /etc/wireguard/${WG_INTERFACE}
            echo "fatto."
            
            # Riavvio il servizio wireguard
            echo -n "Riavvio wireguard... "
            sudo systemctl start wg-quick@${WG_INTERFACE}
            echo "fatto."
            
            # Revoco i privilegi di amministrazione
            sudo -k
        else
            echo "Sono necessarie le credenziali di amministrazione per eseguire questo comando."
            exit 1
        fi
    else
        echo "È necessario inizializzare il server con 'wg_init.sh init'."
        echo "L'operazione richiesta non sarà completata"
    fi
}



# Crea il qr-code della configurazione del client nella cartella corrente.
share() {
    if is_init; then
        if [[ $# -lt 1 ]]; then
            echo -e "Devi inserire almeno un nome."
            exit 1
        else
            for CLIENT_NAME in "$@"; do
                echo -n "Creazione qr-code per il client \"${CLIENT_NAME}\"... "
                qrencode -r ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf -o qrcode_client_${CLIENT_NAME}.jpg
                echo "fatto."
            done
        fi
    else
        echo "È necessario inizializzare il server con 'wg_init.sh init'."
        echo "L'operazione richiesta non sarà completata"
    fi
}



help() {

[[ $1 != "" && $1 != "help" ]] && echo -e "Comando inesistente."

    cat<   : Aggiunge i client indicati in .
        removeclient : Rimuove i client indicati in .
        rebuild                  : Ricostruisce il file di configurazione
                                   del server partendo dalle configurazioni
                                   di tutti i client registrati.
        deploy                   : Riavvia il server wireguard con l'ultima
                                   configurazione disponibile.
        share        : Genera i qr-code relativi ai client indicati in .
        help                     : Stampa questa pagina di help.

ESEMPI:
    INiZIALIZZA IL SERVER WIREGUARD
    wg_man.sh init

    AGGIUNGE I CLIENT 'macbook_pro', 'mobile'
    wg_man.sh addclient macbook_pro mobile

    RIMUOVE I CLIENT 'iphone_luca', 'workstation'
    wg_man.sh removeclient iphone_luca workstation

    RICOSTRUISCE LA CONFIGURAZIONE DEL SERVER WIREGUARD
    wg_man.sh rebuild
    
    ATTIVA LA NUOVA CONFIGURAZIONE
    wg_man.sh deploy

    GENERA I QRCODE PER 'pc_ufficio', 'laptop'
    wg_man.sh share pc_ufficio laptop
EOF
}



main() {
    case $1 in
        init         ) init ;;
        addclient    ) shift; add_client "$@" ;;
        removeclient ) shift; remove_client "$@" ;;
        rebuild      ) rebuild ;;
        deploy       ) deploy ;;
        share        ) shift; share "$@" ;;
        *            ) help ;;
    esac
}



check_dependency
case $? in
    "0" ) main $* ;;
    "1" ) echo -e "UFW non presente. Installare UFW."; exit 1 ;;
    "2" ) echo -e "wireguard-tools non presenti. È necessario installarli."; exit 1 ;;
esac

#bash #wireguard #psk #chiavi #certificati #crittografia

VPN con Wireguard: semplice e veloce

Thu, 16 Mar 2023 15:02:34 +0000

Fonte: Photo by Stefan Coders on Pexels.com

Perché wireguard?

È più semplice di OpenVPN.
Fa parte del kernel dalla versione 5.6 in poi (ci sono anche versioni in userspaces). Vanno installati solo i software di gestione del tunnel
Si basa su uno strato di crittografia all'avanguardia per quel che riguarda efficienza e robustezza
Il suo codice, estremamente compatto, viene revisionato con molta più facilità.
Non si basa su un modello client-server ma P2P
Il traffico è UDP piuttosto che TCP (ci sono modi per fare un wrapping TCP delle connessioni UDP)

Perché wireguard?
Crittografia di Wireguard
Un po' di teoria
Installazione
1. Generazione chiavi
Attivazione del nodo
1. PC/Laptop
2. Mobile
Debug
Topologie
Point-To-Site

Crittografia di Wireguard

Le primitive crittografiche di Wireguard si basano su:

Curve25519, per autenticazione e key exchange (ECDH)
ChaCha20 e Poly1305, per la cifratura simmetrica con autenticazione (AEAD)
BLAKE2, come hash crittografico
SipHash-2-4, come funzione di hash crittografico con chiave (tipo HMAC)
HKDF, come funzione di derivazione della chiave basata su HMAC
Noise Framework, è un protocollo crittografico. Stabilisce il modo con cui tutte queste operazioni crittografiche vengono fatte lavorare.

Un po' di teoria

Wireguard implementa una vpn L3 solo tunneling, incapsulando pacchetti IP all'interno di pacchetti UDP per il trasporto. Ciò implica che funzioni come dhcp, essendo L2, non possono trovare spazio all'interno di wireguard, ergo l'indirizzamento (ip, subnet, dns) deve essere fatto staticamente.

Avendo un'anima P2P, ogni nodo (peer) wireguard è sia client che server. Ciò permette di realizzare topologie anche piuttosto complesse con uno sforzo relativamente ridotto.

Un peer wireguard è composto da due tipi di sezioni:

una sezione “interface”, relativa al peer stesso, contenente:
- il proprio IP, nello spazio di indirizzamento privato usato dalla vpn.
- una porta, su cui il peer può essere in ascolto per accettare richieste da altri nodi wireguard
- la parte privata della chiave asimmetrica con cui decifra e autentica
una o più sezioni “peer”, relative ai nodi a cui può connettersi, contenenti:
- la parte pubblica della chiave asimmetrica del peer, con cui cifra e verifica
- AllowedIPs, che descrive l'ip o le reti da ruotare nel tunnel, a cui è consentito il traffico in entrata e a cui è diretto il traffico in uscita
- l'endpoint del peer, necessario solo se altri peer devono avviare connessioni verso di lui

I nodi si autenticano a vicenda scambiandosi e convalidando le chiavi pubbliche. Ogni chiave pubblica è associata all'IP di un peer.

Quando un peer deve inviare dei pacchetti, AllowedIPs si comporta come una tabella di instradamento. Il peer esamina l'IP di destinazione di quel pacchetto e lo cerca negli AllowedIPs dei suoi peer per capire a chi inviarlo. Se lo trova, ruota il pacchetto nel tunnel, altrimenti no.

Quando si ricevono pacchetti, AllowedIPs si comporta come una lista di controllo degli accessi. Il peer esamina l'IP di origine e se rientra nell'AllowedIPs di uno dei suoi peer, accetterà il pacchetto altrimenti lo scarterà.

Per esperienza personale, il 99% degli errori di configurazione su wireguard viene fatto proprio sul campo AllowedIPs perché non se ne comprende bene il funzionamento.

Uno degli errori più comuni è quello di definire dei peer in cui gli ip contenuti nei campi AllowedIPs si sovrappongono. In base al funzionamento di wireguard infatti, non posso avere chiavi pubbliche diverse per uno stesso ip perché il peer, pur essendo in grado di ricevere pacchetti, non riuscirebbe a inviarli, non sapendo come ruotarli dovendo scegliere fra più peer.

Installazione

Come già detto, wireguard è presente di base nel kernel linux. Bisogna installare solo gli strumenti di interfacciamento per la configurazione su ogni host.

Per sistemi debian-based:

apt install wireguard wireguard-tools

Generazione chiavi

Per semplicità, suppongo di generare tutte le chiavi che mi occorrono, del server (host B) e del client (Endpoint A) in questo caso. Oltre alle chiavi, userò anche una pre-shared key per il client. Non è obbligatorio ma mi costa zero e aumenta la resistenza post-quantistica.

#server
wg genkey > server_wg.key
wg pubkey < server_wg.key > server_wg.pub

#client
wg genkey > endpoint-a_wg.key
wg pubkey < endpoint-a_wg.key > endpoint-a_wg.pub

# Creazione psk
wg genpsk > endpoint-a.psk

Attivazione del nodo

Una volta che la configurazione del nodo è pronta, va attivato il servizio se ci troviamo su un pc. Altrimenti bisognerà importare la configurazione sul device.

PC/Laptop

Sia esso un client o un server, una volta configurato il peer, salva il file file sotto /etc/wireguard/ col nome dell'interfaccia virtuale che hai scelto, nel mio caso, wg0.conf

Attivazione/Disattivazione vpn on-demand:

wg-quick up wg0 #attiva la vpn
wg-quick down wg0 #disattiva la vpn

Attivazione/Disattivazione vpn come servizio:

systemctl enable wg-quick@wg0
systemctl start/stop wg-quick@wg0.service

Mobile

Se il provisioning delle configurazioni si fa attraverso un pc, per portare facilmente la configurazione su un device mobile, si può generare un qrcode del file (supponiamo sia mobile.conf) e importarlo.

# Installazione qrencode (debian-based)
apt install qrencode

#Crea il qr-code e dallo in pasto a al client
qrencode -t ansiutf8 < mobile.conf

Debug

Wireguard è un modulo del kernel e quindi la sua attività viene raccolta dai log del kernel (/var/log/kern.log o /var/log/messages).

Bisogna verificare che sul kernel si possa abilitare il dynamic_debug_control, controllando se è presente:

ls /sys/kernel/debug/dynamic_debug

Se lo è, si carica il modulo, si setta il dynamic debug e si potrà esaminare log del kernel ad es. con journalctl -fk

modprobe wireguard
echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control

Potresti dover installare resolvconf sul server.

Quando wireguard fa salire l'interfaccia, la registra su systemd-resolve attraverso resolvconf e se non è installato potrebbe verificarsi un malfunzionamento.

Topologie

Le principali topologie che possono essere realizzate con wireguard sono:

point-to-point
point-to-site
site-to-site
hub-and-spoke (a stella)

Il canale sicuro fra i nodi wireguard viene creato attraverso le primitive crittografiche di cui sopra, ogni peer viene identificato da una chiave asimmetrica.

Non è necessario approfondire la parte di crittografia per capire come configurare wireguard. Ci fidiamo che faccia un buon lavoro.

Ciò su cui invece vale la pena soffermarsi, è la parte di instradamento, essenziale per l'implementazione delle topologie di cui sopra.

Io mi soffermerò sulla topologia più comune, point-to-site, che permette di unire un endpoint che esegue wireguard, con un altro endpoint situato all'interno di una LAN in cui c'è un host wireguard.

Tanto per fissare le idee indicherò:

col termine peer, uno dei punti logici di una vpn wireguard
col termine endpoint, uno dei punti di arrivo della tratta interessata dal tunnel vpn
col termine host wireguard, l'host che esegue wireguard.

Osservazioni banali: – In una topologia point-to-point, host wireguard ed endpoint coincidono su entrambi gli estremi della tratta. – In una topologia point-to-site, host wireguard ed endpoint coincidono solo sul “point” (l'altro endpoint è dietro ad un host wireguard). – In una topologia site-to-site, gli endpoint sono sempre dietro gli host wireguard.

Point-To-Site

Avrò un Sito A che comprende il solo endpoint dove non ho la possibilità di gestire routing e filtering e un Sito B dove, al contrario, potrò impostare le mie policy di instradamento e filtraggio e dove sarà presente l'host wireguard (indicato come Host B, di solito) che fungerà da server.

La configurazione di un peer si divide in 3 tronconi:

il listener
l'instradamento dei pacchetti fra gli host wireguard e gli endpoint
gli altri peers della VPN Wireguard

Gli scenari che andremo a considerare riguarderanno la direzione delle comunicazioni e le strategie adottate per realizzarle:

da Endpoint A a Endpoint B (punto-sito)
da Endpoint B a Endpoint A (sito-punto)
bidirezionale (punto-sito-punto)

Prendendo uno scenario reale come riferimento, suppongo che la parte “point” sia dietro un NAT che nasconde l'ip privato dell'endpoint e permette solo connessioni già stabilite. Nella parte “site”, la lan è protetta da un firewall-router-nat che espone il solo ip pubblico.

Nella configurazione di filtering/routing sul firewall (ufw nel mio caso) di Host B, ci sarà da tenere conto delle politiche di inoltro. Per semplificarci la vita si potrebbe abilitare qualunque inoltro di default ma sarebbe un po' pericoloso quindi, a meno di casi particolari, anche gli inoltri saranno filtrati.

Primo scenario

Nel primo scenario, considererò il caso punto-sito, in cui un endpoint (con wireguard) si collega, nella LAN attraverso un host wireguard, all'endpoint che eroga un servizio.

Point-To-Site

Obiettivo: L'endpoint del sito B (192.168.1.3) ha un servizio web https sulla porta 443, che non è raggiungibile dall'esterno. Possiamo usare wireguard per permettere all'Endpoint A di raggiungere il servizio sugli endpoint del sito B, per mezzo dell'host wireguard B. Affinché l'host B possa inoltrare i pacchetti dall'Endpoint A all'Endpoint B si ricorre al SNAT (MASQUERADING).

Point-To-Site: Masquerading

Configurazione wireguard Endpoint A

[Interface]
Address = 10.0.0.2/32
SaveConfig = true
PrivateKey = 

[Peer]
PublicKey = 
PresharedKey = 
Endpoint = 200.76.182.23:51820
AllowedIPs = 192.168.1.0/24

Dettagli:

Interface.Address: IP dell'Endpoint A nella rete virtuale definita da wireguard
Interface.SaveConfig: se è true, qualunque modifica fatta al file di configurazione prima dello spegnimento dell'interfaccia verrà ignorato.
Interface.PrivateKey: la chiave privata dell'Endpoint A
Peer.PublicKey: La chiave pubblica dell'host B wireguard
Peer.PresharedKey: La preshared key dell'Endpoint A
Peer.Endpoint: L'ip esposto dell'host B wireguard. Potrebbe trovarsi dietro un firewall/nat ma tanto sappiamo che sul sito B ho libertà d'azione
Peer.AllowedIPs: Sono le reti che voglio ruotare nel tunnel. Possono essere singoli ip o subnet separati da “ , “. 0.0.0.0/0 equivale a ruotare tutto il traffico del peer nella VPN wireguard. Nel caso in esame, ruoto nel tunnel solo la lan del sito B. Il resto del traffico è al di fuori della VPN wireguard (split tunnel)

Configurazione wireguard Host B

[Interface]
Address = 10.0.0.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = 

# endpoint A
[Peer]
PublicKey = 
PresharedKey = 
AllowedIPs = 10.0.0.2/32

Dettagli:

Interface.Address: ip dell'host B nella rete virtuale definita da wireguard
Interface.SaveConfig: se è true, qualunque modifica fatta al file di configurazione prima dello spegnimento dell'interfaccia verrà ignorato.
Interface.PrivateKey: la chiave privata dell'host B
Peer.PublicKey: La chiave pubblica dell'Endpoint A
Peer.PresharedKey: La preshared key dell'Endpoint A
Peer.AllowedIPs: Dovendo contattare il singolo endpoint, AllowedIPs definito nel peer è l'ip del peer stesso all'interno della rete virtuale definita da wireguard.

Non poteva essere altrimenti. In una topologia point-to-site,

da point verso site, AllowedIPs della sezione [Peer] del point indirizza una o più subnet.
da site verso point, AllowedIPs della sezione [Peer] nell'host wireguard indirizza puntualmente l'Endpoint A.

Inoltre, sempre in una topologia point-to-site, è sempre il point ad iniziare la connessione per cui:

nel point:
- si deve specificare l'Endpoint () nella sezione [Peer] relativa al server wireguard.
- non importa specificare la ListenPort nella sezione Interface che può essere scelta casualmente, perché l'Endpoint A non verrà mai contattato direttamente
nel site:
- non importa specificare l'Endpoint () nella sezione [Peer] relativa all'Endpoint A, perché non sarà mai in attesa di una connessione
- si deve specificare la ListenPort nella sezione [Interface] perché le connessioni sono sempre iniziate dagli endpoint verso di lui

Configurazione routing/filtering Host B

Il resto della configurazione non riguarda più wireguard direttamente ma riguarda l'insieme di policy di routing e filtering da fare sull'host B per permettere ai pacchetti dell'Endpoint A di essere inoltrati all'Endpoint B attraverso l'host B.

Affinchè i pacchetti possano viaggiare dall'Endpoint A all'Endpoint B:

i pacchetti arriveranno all'host B sull'interfaccia virtuale della VPN (wg0)
poi verranno inoltrati dall'interfaccia virtuale della vpn (wg0) all'interfaccia reale di host B (eth0),
prima di essere inviati a Endpoint B, una regola di post-routing riscriverà i pacchetti cambiandone l'ip sorgente in modo che risultino inviati da host B piuttosto che da Endpoint A, così da permettere ad Endpoint B di rispondere.

Quindi:

va configurato un inoltro (eventualmente filtrato) dall'interfaccia virtuale wireguard (wg0) a quella reale dell'host B (eth0)
deve essere configurato il SNAT affinché l'Endpoint B possa rispondere all'Endpoint A

# abilita il forward
sysctl -w net.ipv4.ip_forward=1
# inoltra tutto il traffico in arrivo da wg0 verso il solo Endpoint B
ufw route allow in on wg0 out on eth0 proto tcp to 192.168.1.3 port 443;
# masquerading
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

N.B. potrei ancora raffinare queste regole ricorrendo alla tabella Mangle per marcare i pacchetti ai quali applicare il masquerading.

Questi comandi possono far parte della configurazione. Nella sezione [Interface] si possono usare i costrutti PreUp, PreDown, PostUp e PostDown per rendere dinamici alcuni passi di configurazione prima/dopo l'apertura/chiusura del tunnel. E così, la configurazione del server diventa:

[Interface]
Address = 10.0.0.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = 

# IP forwarding
PreUp = sysctl -w net.ipv4.ip_forward=1
PreUp = ufw route allow in on wg0 out on eth0 proto tcp to 192.168.1.3 port 443
PostDown = ufw route delete allow in on wg0 out on eth0 proto tcp to 192.168.1.3 port 443

# IP masquerading
PreUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# IP filtering
PreUp = ufw allow in on eth0 proto udp from 0.0.0.0/0 to 192.168.1.2 port 51820;
PostDown = ufw delete allow in on eth0 proto udp from 0.0.0.0/0 to 192.168.1.2 port 51820;

# endpoint A
[Peer]
PublicKey = 
PresharedKey = 
AllowedIPs = 10.0.0.2/32

Test

Da Endpoint A (192.168.10.10) possiamo raggiungere il servizio come se fossimo nella lan del sito B, quindi:

curl https://192.168.1.3

risponderà al browsing.

Tips

La combinazione AllowedIPs / routing è la chiave per gestire qualunque instradamento. Nell'esempio visto finora abbiamo fatto in modo che:

l'Endpoint A ruotasse nella VPN wireguard solo la subnet relativa al sito B, 192.168.1.0/24, facendo split tunnel per il resto.
l'host B avesse delle regole di inoltro per l'Endpoint B per i soli pacchetti destinati al servizio che eroga, https. Qualuque altro host del sito B non può essere raggiunto.

In questo modello, qualunque altro endpoint abilitato alla VPN wireguard potrebbe accedere al servizio dell'Endpoint B. Vale la pena dare un'occhiata ad un altro paio di combinazioni che si trovano agli opposti del nostro esempio. In un caso, ruoteremo tutto il traffico verso la vpn, in un altro consentiremo solo a determinati peer, non a tutti, di fruire di determinati servizi.

1. Inoltro di tutto il traffico nella vpn In questo modo, l'Endpoint A lavora come se facesse parte della lan del sito B. È una modalità totalmente anonimizzante. Da usare solo con dispositivi trusted perché un eventuale traffico malevolo verrebbe ruotato nel tunnel e risulterebbe proveniente dal sito B

Su Endpoint A:

...
AllowedIPs = 0.0.0.0/0
...

Su host B:

...
ufw route allow in on wg0 out on eth0;`
...

2. Indirizzamento puntuale su servizi specifici È il caso in cui alcuni peer debbano raggiungere solo determinati servizi e non altri. Supponiamo di avere altri due endpoint, Endpoint A₁ e Endpoint A₂.

Su Endpoint A₁ e A₂ (in realtà AllowedIPs potrebbe essere puntuale):

...
AllowedIPs = 192.168.1.0/24
...

...
PreUp = ufw route allow in on wg0 out on eth0 proto tcp from 10.0.0.3 to 192.168.1.4 port 3306
PreUp = ufw route allow in on wg0 out on eth0 proto tcp from 10.0.0.4 to 192.168.1.5 port 22
PostDown = ufw route delete allow in on wg0 out on eth0 proto tcp from 10.0.0.3 to 192.168.1.4 port 3306
PostDown = ufw route delete allow in on wg0 out on eth0 proto tcp from 10.0.0.4 to 192.168.1.5 port 22
...

Secondo scenario

Nel secondo scenario, ribalterò il punto di vista e prenderò in esame il caso in cui sia un host del sito B a contattare un endpoint esterno con wireguard (sito-punto). Non il classico scenario road-warrior in cui un endpoint deve raggiungere la rete aziendale o domestica, ma il suo opposto.

Site-To-Point

Obiettivo: L'host del sito A (192.168.10.10) ha un servizio web https sulla porta 1443, che non è raggiungibile dall'esterno ma vogliamo che lo sia dal sito B. Con wireguard, possiamo usare l'interfaccia virtuale per esporre il servizio su 10.0.0.2, verso gli endpoint del sito B, per mezzo dell'host wireguard B. Affinché l'host B possa inoltrare i pacchetti dall'Endpoint B all'Endpoint A si ricorre al DNAT (PORT FORWARDING).

Site-To-Point: Port-Forwarding

La configurazione di wireguard su host B rimane sostanzialmente identica rispetto a prima. A cambiare sarà soprattutto la parte di filtering e routing.

Configurazione wireguard Endpoint A

[Interface]
Address = 10.0.0.2/32
SaveConfig = true
PrivateKey = 

[Peer]
PublicKey = 
PresharedKey = 
Endpoint = 200.76.182.23:51820
AllowedIPs = 192.168.1.0/24
PersistentKeepalive = 25

Su Endpoint A c'è una piccola modifica.

Dettagli:

PersistentKeepalive: Il NAT davanti all'Endpoint A potrebbe troncare la connessione dopo un po' visto che non è lui ad avviarla. Dal momento che è Endpoint A a dare servizio, si ricorre al keepalive per mantenere la connessione persistente.

Configurazione wireguard Host B

[Interface]
Address = 10.0.0.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = 

# endpoint A
[Peer]
PublicKey = 
PresharedKey = 
AllowedIPs = 10.0.0.2/32

La configurazione di Host B rimane sostanzialmente invariata.

Configurazione routing/filtering Host B

Affinchè i pacchetti possano viaggiare dall'Endpoint B all'Endpoint A:

i pacchetti arriveranno sull'interfaccia reale di host B (eth0),
una regola di pre-routing riscriverà i pacchetti cambiandone l'ip di destinazione con quello virtuale dell'Endpoint A
poi verranno inoltrati dall'interfaccia reale di host B (eth0) all'interfaccia virtuale della VPN (wg0) che li recapiterà ad Endpoint A

Quindi

va configurato un inoltro (eventualmente filtrato) dall'interfaccia reale dell'host B (eth0) a quella virtuale wireguard (wg0)
deve essere configurato il DNAT affinché l'Endpoint B possa contattare l'Endpoint A.

...
# IP forwarding
# abilita il forward
PreUp = sysctl -w net.ipv4.ip_forward=1
# inoltra tutto il traffico in arrivo da eth0 verso l'Endpoint A
PreUp = ufw route allow in on eth0 out on wg0 proto tcp to 10.0.0.2 port 443
PostDown = ufw route delete allow in on eth0 out on wg0 proto tcp to 10.0.0.2 port 443

# IP port forwarding
# inoltro della porta 1443 dall'interfaccia lan verso la porta 443 dell'Endpoint A
PreUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.0.0.2:1443
PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.0.0.2:1443

# IP filtering
PreUp = ufw allow in on eth0 proto udp from 0.0.0.0/0 to 192.168.1.2 port 51820;
PostDown = ufw delete allow in on eth0 proto udp from 0.0.0.0/0 to 192.168.1.2 port 51820;
...

Test

Da Endpoint B (192.168.1.3) possiamo raggiungere il servizio sull'interfaccia virtuale dell'Endpoint A passando dalla porta dell'host B, quindi:

curl https://192.168.1.2

risponderà al browsing.

Tips

In questa rappresentazione, ogni host del sito B viene indirizzato solo verso la vpn wireguard. L'host B inoltra:

la porta 443 di ogni host del sito B verso l'Endpoint A
tutto il traffico della lan verso la vpn wireguard.

Se volessimo che solo determinati endpoint del sito B potessero inoltrare il loro traffico, si dovrebbero rendere le regole di inoltro più puntuali. Supponiamo che Endpoint A (10.0.0.2) esponga un servzio httpd sulla porta 10080 e vogliamo che solo gli host 192.168.1.9-192.168.1.14 del sito B lo possano raggiungere sulla canonica porta 80.

Port Forwarding di un solo endpoint

ufw route allow from 192.168.1.4 to 10.0.0.2 port 10080 proto tcp
iptables -t nat -A PREROUTING -s 192.168.1.4 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.2:10080

Port Forwarding di una subnet

ufw route allow from 192.168.1.8/29 to 10.0.0.2 port 10080 proto tcp
iptables -t nat -A PREROUTING -s 192.168.1.9-192.168.1.14 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.2:10080

Terzo scenario

Il terzo scenario può essere considerato un'unione dei primi due.

Point-To-Site-To-Point

Obiettivo: L'host del sito A (192.168.10.10) espone un servizio di remote desktop (porta 3389), l'endpoint del sito B (192.168.1.3) espone un servizio web https sulla porta 443. Vogliamo che l'Endpoint A raggiunga il servizio web e che l'Endpoint B acceda al desktop remoto dell'Endpoint A.

Point-To-Site: Gateway

Se viene configurato il routing sul gateway per indirizzare wireguard, il traffico potrà essere bidirezionale. Non ci sarà bisogno di manipolare i pacchetti perché:

Da Endpoint A a Endpoint B, i pacchetti inoltrati da host B avranno come sorgente l'ip della rete wireguard di Endpoint A.
Attraverso il gateway, Endpoint B potrà rispondere/contattare direttamente l'indirizzo sorgente wireguard di Endpoint A.

La configurazione di wireguard su Endpoint A e Endpoint B è assimilabile allo scenario 2 con l'impostazione del PersistentKeepAlive su Endpoint A

Configurazione routing/filtering Host B

Al solito va configurato l'inoltro su Host B da Endpoint A a B e viceversa

...
PreUp = ufw route allow in on wg0 out on eth0 to 192.168.1.3 port 443 proto tcp
PostDown = ufw route delete allow in on wg0 out on eth0 to 192.168.1.3 port 443 proto tcp
PreUp = ufw route allow in on eth0 out on wg0 from 192.168.1.3 port 3389 proto tcp
PostDown = ufw route delete allow in on eth0 out on wg0 from 192.168.1.3 port 3389 proto tcp
...

Configurazione gateway host del Sito B

A parte attivare il solito inoltro su host B, bisognerà avere la possibilità di configurare il routing anche sul nostro router (192.168.1.1), in maniera che Endpoint B, che presumbilmente ha proprio 192.168.1.1 come gateway di default, indirizzando Endpoint A, venga rediretto verso Host B. Ad es.

ip route add 10.0.0.2/32 via 192.168.1.2 dev eth0

In alternativa, se non si ha la possibilità/voglia di configurare il router, bisognerà configurare Endpoint B con la rotta statica indicata prima.

Test

Da Endpoint A (192.168.10.10) possiamo raggiungere il servizio come se fossimo nella lan del sito B, quindi:

curl https://192.168.1.3

Da Endpoint B (192.168.1.3) raggiungiamo il desktop remoto dell'Endpoint A attraverso la sua interfaccia virtuale (10.0.0.2)

rdesktop 10.0.0.2

Tips

Si potrebbe pensare di aggregare le potenziali rotte statiche considerando l'intera subnet wireguard per avere un'unica rotta statica su tutti gli host del sito B configurando sul nostro router (oppure su tutti gli host del sito B):

ip route add 10.0.0.0/24 via 192.168.1.2 dev eth0

In questo modo, ogni host del sito B può indirizzare vicendevolmente il suo traffico verso endpoint esterni purché le regole wireguard lo consentano (AllowedIPs)

Differenze fra i 3 approcci

Primo scenario: l'Endpoint A contatta l'Endpoint B sul suo indirizzo reale ma l'Endpoint B non ha idea di chi siano gli endpoint, lato “punto”, che lo contattano (per effetto del masquerading, le connessioni agli Endpoint B partono da host B).

Secondo scenario: l'Endpoint B non può contattare direttamente gli endpoint lato “punto” ma contatterà l'host B e sarà il DNAT a veicolare i pacchetti agli endpoint lato “punto”.

Terzo scenario: potendo configurare il router (o gli host del sito B), è l'approccio più semplice e garantisce bidirezionalità senza manipolazione dei pacchetti.

Riferimenti:

https://www.wireguard.com/

#vpn #openvpn #wireguard #CryptokeyRouting

crittografia — Cyberdyne Systems

fwknop: proteggere servizi con Single Packet Authorization (SPA)

Cos'è fwknop

Installazione client e server

Configurazione client

Generazione della sola chiave

Generazione chiave + configurazione complessa

Configurazione server

Scenari

1. Protezione di un servizio con SPA

Configurazione lato server

Configurazione lato client

2. Ghost locale sullo spaserver

Configurazione lato server

Invocazione client

3. SPA attraverso gateway NAT

Configurazione lato server

Invocazione client

4. SPA Ghost Service

Invocazione client

E se volessi usare la crittografia asimmetrica?

Creazioni delle chiavi su server e client

Importazioni e firma delle chiavi

Configurazione access.conf.d/test.conf e .fwknoprc

Test client

Osservazioni su access.conf

Configurazione stanze con spa server come bastion host

Alice

Bob

Carol

Gestire la tua chiave GPG

Indice

Creazione della chiave primaria

Aggiungere una sottochiave

Meccanismi di indirizzamento per una chiave

Aggiungere un uid

Firmare una chiave

Modificare la password

Modificare la scadenza

Cancellazione di elementi dal keyring

Cancellare una sottochiave

Cancellare un uid

Cancellare una firma

Operazioni di revoca

Revocare un uid

Revocare una sottochiave

Revocare una nostra certificazione

Revocare l'intero certificato

Operazioni sul keyserver

Cerca

Invia

Ricevi

Aggiorna

Realizzare un keyring per l'uso quotidiano

Eliminazione della chiave privata dalla master key

Lavorare con un keyring effimero

Modelli recenti

Hagrid

Mailvelope

Hockeypuck

Altri keyserver

Script per la gestione della configurazione di una vpn wireguard

Alcune considerazioni

Lo script

VPN con Wireguard: semplice e veloce

Configurazione `access.conf.d/test.conf e .fwknoprc`