Cosa si intende per 2FA

Attivare la 2FA è sempre una buona pratica per mitigare attacchi di tipo brute-force. Perché non farlo pure per ssh, soprattutto se lo si usa nel bastion host per accedere alla nostra lan? Da letteratura, la 2FA consiste nel fornire 2 fattori di autenticazione fra:

1. qualcosa che sai (ad es. una password o un pin)
2. qualcosa che hai (ad es. un otp)
3. qualcosa che sei (ad es. un rilievo biometrico)

Se i fattori sono più di due, si parla di Multi Factor Authentication (MFA).

Non entro nel merito della configurazione di un servizio ssh , che non è banale. La diamo per scontata, ci concentriamo sulla parte di autenticazione.

Metodi di autenticazione

La buona norma vorrebbe che un'autenticazione su un server openssh si limitasse all'autenticazione con chiave pubblica. Su alcune distro ad es. è l'unica disponibile di default. Ma non basta una buona autenticazione per garantire la sicurezza di un servizio come SSH. Occorrerebbe intervenire su ben altri aspetti perché altrimenti sarebbe come preoccuparsi della bontà della porta blindata per la nostra casa dalle pareti di cartone.

I parametri del file di configurazione che andrò a trattare riguardano le modalità di autenticazione di ssh. La versione che sto usando su debian bullseye è la 8.4p1. Queste sono:

• password
• publickey
• keyboard-interactive
• gssapi-with-mic
• hostbased
• none

Le prime 3 sono quelle che ci interessano sul serio.

Con ssh posso avere:

1. una 2FA (ad es. publickey + password)
2. una MFA (ad es. publickey (qualcosa che sei) + password (qualcosa che sai) + OTP (qualcosa che hai) , se ipotizziamo publickey, in quanto certificato digitale, assimilabile al rilievo biometrico).

Per realizzare i due scenari c'è bisogno di settare con attenzione ssh per non rischiare di lasciare voragini invece che mettere in sicurezza il servizio.

Suppongo che ssh sia già settato come si deve, ciò che andrò a toccare sarà:

• UsePAM Abilita o meno l'uso di PAM
• ChallengeResponseAuthentication (KbdInteractiveAuthentication dalla 8.8) Permette di applicare lo schema Challenge-Response per l'autenticazione
• PublicKeyAuthentication Abilita o meno l'autenticazione con chiave pubblica
• PasswordAutentication Abilita o meno l'autenticazione con password
• AuthenticationMethods È la lista (l'elenco precedente) dei metodi di autenticazione che vogliamo permettere. Se gli elementi sono separati da una virgola, vuol dire che sono tutti obbligatori (per avere un'autenticazione multipla per es.). Se sono separati da uno spazio, vuol dire che sono facoltativi. Es. publickey,password password publickey,password,keyboard-interactive. Vuol dire che mi posso autenticare fornendo chiave e password oppure password oppure chiave+password+otp È abbastanza chiaro che una configurazione del genere può essere molto pericolosa perché il suo livello di robustezza dipende dal suo anello più debole (la password in questo caso) che può vanificare tutti gli altri.

Ogni modifica del file di configurazione richiederà il restart del servizio ssh.

systemctl restart sshd.service

PAM

Com'è noto, e banalizzando molto, PAM è un sottosistema gnu/linux che fornisce un livello di astrazione a quelle applicazioni, come ssh, che richiedono autenticazione. In questo modo le applicazioni non hanno bisogno di implementarle esplicitamente e, volendo, possono estendere i propri schemi di autenticazione aumentandone la complessità in maniera relativamente semplice.

PAM, insieme ad una autenticazione di tipo challenge-response, ci permetterà di ottenere un'autenticazione multipla.

Scenario 1: Configurazione sicura (chiave pubblica)

In molti contesti si preferisce abilitare la sola autenticazione con chiave pubblica, proprio per evitare possibili falle. Niente PAM in questo caso ma solo configurazione ssh:

...
UsePAM=no
ChallengeResponseAuthentication=no
PublicKeyAuthentication=yes
PasswordAuthentication=no
AuthenticationMethods=publickey
...

PAM viene disabilitato perché scegliamo di non affidarci a librerie di autenticazione esterne. Inoltre, in casi estremi, si può pensare che un aggiornamento di PAM possa rompere la compatibilità con qualche libreria invalidando o indebolendo il processo di autenticazione.

Di conseguenza, niente autenticazione di tipo challenge-response, niente autenticazione con password.

Attiviamo solo la PublicKeyAuthentication rafforzando la scelta in AuthenticationMethods dove impostiamo come unico metodo valido publickey. Infine, riavviamo il servizio.

L'unico modo per accedere al server ssh è possedere una chiave (o un certificato) valida.

Scenario 2: 2FA (chiave pubblica + password)

Facciamo un passo in più è facciamo in modo che l'accesso al server sia consentito solo a chi possiede sia chiave che password.

...
UsePAM=no
ChallengeResponseAuthentication=no
PublicKeyAuthentication=yes
PasswordAuthentication=yes
AuthenticationMethods=publickey,password
...

Oltre che specificare il tipo di autenticazione (PublickeyAutentication e PasswordAuthentication), imponiamo che il metodo sia quello di esibire entrambe le credenziali.

Non impostando AutenticationMethods, varrebbe il default che prevede uno fra password, publickey o keyboard-interactive.

L'ultimo sarebbe comunque inutile in questo caso, visto che pam e challenge-response sono disabilitati. Ma non avremmo ottenuto ciò che ci eravamo prefissati.

Una configurazione analoga è la seguente:

...
UsePAM=yes
ChallengeResponseAuthentication=yes
PublicKeyAuthentication=yes
PasswordAuthentication=no
AuthenticationMethods=publickey,keyboard-interactive
...

Riavviamo ssh e la nuova autenticazione sarà disponibile come al solito.

È un esempio di come posso usare PAM per rimpiazzare la PasswordAuthentication nativa. Con una combinazione di PAM e autenticazione challenge-response, attraverso il metodo esplicito keyboard-interactive, l'applicazione autenticherà con un'unica sfida che è la richiesta di password.

Con PAM posso aggiungere altro, ad es. l'otp, come vedremo nel 3° scenario.

Scenario 3: MFA (chiave pubblica + password + otp)

Lasciamo inalterata la configurazione ssh dello scenario 2, quella che fa uso di pam. Bisogna innanzittutto installare il plugin per l'otp.

Sistemi debian-based:

apt install libpam-google-authenticator

Sistemi rpm-based:

dnf install google-authenticator

Per completezza, giusto perché lo uso, MacOS (via brew):

brew install google-authenticator-libpam

Dopo l'installazione, il generatore otp va inizializzato lanciando l'eseguibile che porrà una serie di domande:

• generare i token su base temporale: Y/N (consigliato Y)
• creare un file di configurazione nella home dell'utente: Y/N (consigliato Y)
• disabilitare la possibilità che un token possa essere usato più volte: Y/N (consigliato Y)
• (semplificando) aumentare la finestra temporale di generazione dei token (default 30s): Y/N (consigliato N, a meno che la connessione fra client e server non sia ESTREMAMENTE lenta)
• abilitare il rate-limit per scoraggiare attacchi di brute-force: Y/N (consigliato Y)

A seguire, verrà mostrato sia il qr-code (per il caricamento automatico della chiave su un authenticator come FreeOtp+) che la chiave privata (se si vuole procedere con la configurazione manuale dell'authenticator o dello script visto tempo fa), necessari per la fornitura del primo codice che inizializza il processo.

Infine configuriamo PAM per sshd. In /etc/pam.d/sshd dobbiamo imporre che il processo di autorizzazione includa obbligatoriamente l'otp. Lo faremo aggiungendo una riga contenente il riferimento alla libreria che lo implementa:

auth required pam_google_authenticator.so

Il solito riavvio di ssh (alcuni consigliano anche di fare il reboot della macchina per inizializzare correttamente il generatore di otp ma non ho trovato una giustificazione convincente del perché) completa il lavoro.

Per autenticarsi sul server ssh ora serviranno:

• chiave pubblica
• password
• otp

Scenario 3bis: 2FA (chiave pubblica + otp)

Se invece volessi avere una 2FA come nello scenario 2, ma con otp invece che con password, posso procedere così. Si lascia inalterata la configurazione ssh e si commenta una riga dalla configurazione di PAM:

Su /etc/pam.d/sshd commentare la seguente riga così:

...
#@include common-auth
...

In questo modo, si elimina la richiesta della password utente dalle “sfide” della challenge-response e rimane la sola richiesta otp.

Tips

Attenzione quando si gioca con i metodi di autenticazione ssh. Ci sono buone possibilità che vi autoescludiate dal vostro server. Basta avere keyboard-interactive (che implica un'autenticazione di tipo challenge-response) fra i metodi di autenticazione obbligatori e pam disattivato. Ecco un esempio:

...
usePAM no 
ChallengeResponseAuthentication yes
PasswordAuthentication no
PubkeyAuthentication no
AuthenticationMethods keyboard-interactive
...

Oppure, ancora più subdolo, lo scenario 3 con pam disabilitato, ossia: configurazione ssh

...
usePAM no 
ChallengeResponseAuthentication yes
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
...

In questi casi, l'autenticazione fallirà con questo errore: “Permission denied (keyboard-interactive)” perché non sarà disponibile nessuna interazione da tastiera (es. una password) e noi rimarremmo chiusi irrimediabilmente fuori dal nostro server.

#ssh #otp

Introduzione

Da documentazione, Stunnel agisce come un proxy per aggiungere crittografia TLS a server e/o a client già esistenti.

Risulta quindi molto comodo quando si vuole aggiungere, attraverso un tunnel TLS, quella crittografia che manca alle nostre applicazioni per rendere le comunicazioni più sicure. Come in ssh, è possibile “tunnellizzare” solo connessioni TCP.

Di stunnel esaminerò in particolare la fase di autenticazione attraverso certificato o PSK.

Gli scenari possibili, in base alle combinazioni, sono tre:

• client tls – server in chiaro
• client in chiaro – server tls
• client e server in chiaro

Nel primo caso, occorre configurare stunnel in server mode, definendo un receiver ssl, a cui il client potrà connettersi. Scenario 1: stunnel server

Nel secondo caso, occorre configurare stunnel in client mode, definendo un sender ssl che il client userà per connettersi al server Scenario 2: stunnel client

Nel terzo caso, occorre configurare uno stunnel client e uno server Scenario 3: stunnel client e server

Come ulteriore evoluzione per quel che riguarda le tratte in chiaro (e non solo) di client-stunnel client, stunnel client-stunnel server, stunnel server-server, sarebbe buona norma limitarne l’accesso con un firewall. Stunnel e firewall

Se invece stunnel fosse locale (installato direttamente sul client e/o sul server), la richiesta del client o il listener del servizio, avverrebbero sull’interfaccia di loopback. Altrimenti, in assenza di firewall, sarebbe consigliabile accertare che la rete di collegamento fra i proxy stunnel e i rispettivi client/server, sia almeno di tipo “trusted”.

Stunnel consente un certo tuning sulla parte tls, potendo discriminare fra le cipher suites da abilitare, specificare comandi o configurazioni specifiche per openssl. Quando si deve incapsulare una connessione in chiaro in un tunnel ssl bisogna tenere presente gli scenari menzionati prima.

Convenzioni

• Per non perdere generalità, negli esempi che seguiranno, immaginiamo che stunnel non sia locale (anche se spesso lo è).
  • se stunnel in client mode è locale ⇒ accept avverrà sull’interfaccia di loopback, da dove avviene effettivamente la richiesta
  • se stunnel in server mode è locale ⇒ connect avverrà sull’interfaccia di loopback, dove viene erogato effettivamente il servizio
• Non faremo assunzioni sulla creazione dei certificati. Possono anche essere self-signed.

Configurazione stunnel

Verranno mostrate le configurazioni relative agli scenari mostrati nel modo più semplice possibile.

• accept: host e porta che ricevono la richiesta
• connect: host e porta a cui girare l’accept
• cert: normalmente conterrebbe il certificato pubblico che stunnel espone per autenticarsi (la parte privata viene specificata con key). Può però anche essere costituito da tutta i certificati della chain fino alla root CA, in formato pem o p12, iniziando dalla chiave privata, proseguendo con la chiave pubblica, fino a tutte le CA della chain.
• key: chiave privata del certificato
• client: stabilisce se stunnel funzioni in server mode oppure no

Primo scenario

Nel primo caso, una configurazione minimale lato server, ha bisogno:

1. host e porta dello stunnel server che riceve il traffico cifrato
2. host e porta del server su cui girare il traffico in chiaro
3. certificato pubblico e chiave privata necessari per la cifratura

Stunnel Server:

[myService]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
cert = /server_crt.pem<br>
key = /server_key.pem

Secondo scenario

Nel secondo caso, una configurazione minimale lato client, ha bisogno:

1. host e porta dello stunnel client da cui partirà la richiesta
2. host e porta del server da cui stunnel client avvierà la sessione tls

Stunnel Client:

[myService]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_server:port_server

Terzo Scenario

Il terzo caso, è una fusione dei primi due. Sono gli stunnel a gestire il grosso della comunicazione. E nei casi in cui lo stunnel viene installato sulle macchine di servizio, client e server reali usano solo l’interfaccia di loopback.

Una configurazione minimale per il client ha bisogno di:

1. host e porta dello stunnel client da cui partirà la richiesta
2. host e porta del server da cui stunnel client avvierà la sessione tls

Stunnel Client:

[myService]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server

Una configurazione minimale per il server ha bisogno:

1. host e porta dello stunnel server che riceve il traffico cifrato
2. host e porta del server su cui girare il traffico in chiaro certificato pubblicato e chiave privata necessari per la cifratura

Stunnel Server:

[myService]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
cert = /server_crt.pem
key = /server_key.pem

Piccola nota: se client e/o server dovessero supportare chiavi PSK, si potrebbe usare PSK in luogo dei certificati. Ci ritornerò più avanti.

Autenticazione dei client

Le impostazioni viste finora, mostrano come incapsulare un traffico in chiaro all’interno di un tunnel tls e si basano sulla sola autenticazione lato server.

Per migliorare la configurazione possiamo ricorrere alla mutua autenticazione facendo in modo che anche i client si autentichino.

Una mutua autenticazione, con tutte le verifiche del caso, aumenta il grado di sicurezza comunicazione TLS ed è un efficace deterrente contro eventuali attacchi MITM. L’autenticazione sul client si può ottenere sempre con i certificati oppure, più semplicemente, con chiavi PSK.

Autenticazione dei client con certificato

Ad una configurazione minimale per una mutua autenticazione, lato server, si richiede che i client esibiscano il certificato e i client (che sia stunnel in client mode, un browser o qualunque altra cosa) dovranno essere in grado di esibire i certificati nel momento in cui il server li richiederà.

Su stunnel server, alle configurazioni viste in precedenza, si aggiunge requireCert impostato a yes, che richiede ai client l’esibizione di un certificato. Se, durante l’handshake TLS, il client non esibisce un certificato, l’handshake fallisce e la connessione viene rifiutata.

Stunnel Server:

[myService]
…
requireCert = yes
…

È sufficiente questo se i client possono manipolare i propri certificati. Altrimenti, se c’è uno stunnel client che intermedia le richieste dei client effettivi, si deve aggiungere alla sua configurazione la chiave e il certificato del client

Stunnel Client:

[myService]
…
cert = /server_crt.pem
key = /server_key.pem
…

Autenticazione dei client con PSK

Per l’autenticazione PSK bisogna disporre della lista di utenti abilitati con relative chiavi esadecimali di almeno 16 bytes (ossia almeno 32 caratteri esadecimali visto che con un byte si rappresentano due esadecimali).

La creazione di una chiave esadecimale può essere fatta velocemente con openssl. Supponiamo di creare due utenze per Frodo e Gandalf con chiavi da 20 e 42 bytes.

echo -e "frodo:"$(openssl rand -hex 20) > frodo_psk.txt
echo -e "gandalf:"$(openssl rand -hex 42) > gandalf_psk.txt

Tutte le identità dovranno confluire nel file che, nella configurazione stunnel, sarà indicato da PSKsecrets. Ad es:

cat frodo_psk.txt gandalf_psk.txt > psksecrets.txt
…
frodo:84196825fab3389624dcc83eb61189e5b21099fe<br>gandalf:5daf128419855993a2d95ba0a337c51b3f373df88e594441f2979eba6461f25676f1f825b0c76df392f2
…

E, come detto, nella configurazione dello stunnel server dovrò indicare il file delle identità:

Stunnel Server

[myServer]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
PSKsecrets = <path_identity_file>/psksecrets.txt

Se il client supporta PSK, dovrà fornire identità e password. Ad es. facendo un test con openssl:

openssl s_client -port <porta> -psk_identity frodo -psk 84196825fab3389624dcc83eb61189e5b21099fe -tls1_2 -connect <host>

Altrimenti si configura stunnel client indicando sia l’identità, sia il file individuate da PSKsecrets.

Stunnel Client

[myClient]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server
PSKidentity = frodo
PSKsecrets = <path_identity_file>/psksecrets.txt

In alternativa, per non far viaggiare il file delle identità fra tutti i client, possiamo sfruttare a nostro vantaggio il default delle identità.

In assenza della direttiva PSKidentity, viene assunta come identità di default la prima riga del file indicato da PSKSecrets. Basta quindi creare un file con la sola identità che mi occorre, ad es. frodo_psk.txt

frodo:84196825fab3389624dcc83eb61189e5b21099fe

e indicare quello in PSKSecrets. La configurazione che segue è equivalente alla precedente.

Stunnel Client

[myClient]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server
PSKsecrets = <path_identity_file>/frodo_psk.txt

Ulteriori considerazioni di sicurezza

Autenticazione con certificato

La richiesta di autenticazione dei client mediante certificato è una buona misura preventiva ma può essere resa migliore.

Nelle configurazioni viste finora, stunnel server autorizza l’accesso al servizio solo se il client si presenta con un certificato ma non c’è nulla che vincoli il certificato al servizio. In altre parole, un client in possesso di un qualunque certificato, può accedere alla risorsa.

È possibile rafforzare il trusting fra le parti facendo in modo che stunnel autorizzi solo alcuni certificati invece che qualunque. Questo tipo di controllo può essere fatto sia su stunnel sia in client mode che in server mode.

• verifyChain = yes | no
• checkEmail = email del certificato
• checkHost = CN del certificato
• checkIP = IP del peer che presenta il certificato
• verifyPeer = yes | no
• CApath = < path CA >
• CAfile = < file pem contenente la fullchain del certificato presentato a stunnel >

verifyChain Impone che si possa verificare la fullchain del certificato presentato. Se uno degli issuer non viene trovato, la connessione fallisce. La fullchain viene indicata attraverso CAfile o CApath.

CAfile È il file contenente le CA con cui stunnel valida i certificati che gli vengono presentati. Se stunnel è in server mode, sarà la fullchain relativa ai client. Altrimenti sarà la fullchain relativa al server.

CApath È il path in cui si trovano le CA con cui stunnel valida i certificati che gli vengono presentati. Se lo stunnel è in server mode, sarà la fullchain realtiva ai client. Altrimenti sarà la fullchain relativa al server.

verifyPeer Se con CAfile e CApath si verifica la fullchain dei certificati presentati a stunnel, con verifyPeer = yes si verifica che questi certificati siano presenti anche nel suo keystore (CAfile o CApath). Permette di “legare” a stunnel i certificati che dovrà validare.

checkEmail, checkHost, checkIP Come per verifyPeer, sono direttive che permettono di stringere il legame fra il certificato che viene presentato e stunnel. Verifica che l’email, il CN o l’IP del certificato che viene presentato corrispondano a quelli presenti nella configurazione. In una configurazione lato server posso avere molteplici occorrenze di questi due campi relative ad altrettanti certificati. Il caso in cui ad es. si debbano autenticare n client.

Se i certificati sono self-signed, verifyChain perde di significato (coinciderebbe con verifyPeer). La possibilità di generare i certificati attraverso una CA, anche interna, renderebbe il processo più strutturato anche se più complesso (si dovrà trovare un modo per distribuire la CA, se interna). Si tratta di trovare il giusto compromesso fra ampiezza del servizio (quanti utenti coinvolge?) e complessità richiesta.

Se si tratta di realizzare un canale sicuro fra due apparati per una comunicazione server-2-server, vanno bene anche i certificati self-signed o un’autenticazione PSK. Altrimenti, soprattutto nel caso in cui l’autenticazione dei client è una fase critica, conviene valutare l’uso di una CA e una validazione il più possibile restrittiva sui client e sul server.

Autenticazione PSK

A differenza dell’autenticazione con certificato, l’autenticazione con PSK non prevede enhancement di sicurezza ulteriori a meno di specificare opportuni algoritmi di cifratura (cfr. paragrafo successivo).

Cifratura

Come sempre succede, negli scenari di cifratura asimmetrica orientatia alla connessione, l’autenticazione, per quanto possa essere accurata, costituisce solo uno degli aspetti di cui tenere conto nella fase di messa in sicurezza del servizio.

Avere un’autenticazione con certificato generato con tutti i crismi da una CA, è certamente una gran cosa ma mette in sicurezza solo l’aspetto dell’autenticazione, per l’appunto.

l transito dei dati è affidato alle suite di cifratura supportati da openssl e, volendo lavorare di fino, bisognerebbe stringere anche su quelli.

Altrimenti, paradossalmente, si avrà un’autenticazione robustissima ma con algoritmi colabrodo di cifratura dei dati che, ad attaccanti ben motivati, lascerebbero delle porte spalancate per sferrare attacchi MITM per intercettare direttamente i dati, piuttosto che provare il furto di identità.

Ad ogni modo, il default, per ragioni di compatibilità legacy, dei parametri di cifratura (da settare eventualmente su client e sul server) è il seguente:

ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK
ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256

dove ciphers raggruppa le suite di cifratura relativi a TLS1.2 in giù e ciphersuites riguarda invece TLS1.3.

Configurazione servizio

Ulteriori restrizioni possono essere aggiunte a livelllo di sistema:

1. regolando i bit di setuid e setgid se stunnel gira come root
2. delimitando l’esecuzione del processo in una gabbia chroot
3. disabilitando le regonetiation (se supportato dalla versione di openssl in uso) che mitiga in parte attacchi dos di tipo CPU-exhaustion
4. ecc..

Caso reale: tunnelizzare Transmission.

Transmission è un client bittorrent che può essere controllato da remoto via rpc attraverso un’interfaccia web o altri client.

Transmission, nelle sue varie declinazioni, non incapsula il traffico rpc in una connessione tls.

Se si vuole che il dato in transito sia cifrato e che la connessione sia autenticata, si può ricorrere:

1. ad un tunnel ssh;
2. all’intermediazione di un webserver come apache o nginx ;
3. ad uno stunnel server

Sugli ultimi due punti si può configurare una mutua autenticazione con certificato (complessa e articolata e, per tanti client, ha un impatto significativo). Scegliamo il 3° caso.

Esposizione dell’interfaccia web

Scenario: abbiamo una macchina (il nostro serverino di fiducia o un nas) con transmission a bordo, presumibilmente dietro un firewall che natta il suo indirizzo privato (192.168.70.15).

Esposizione transmission attraverso stunnel server

Obiettivo: Vogliamo poter raggiungere transmission e vogliamo che i client autentichino la loro connessione prima di accedere al servizio. In base allo scenario, sappiamo che dovremmo configurare un port forwarding dall’AP fino allo stunnel server. Il server transmission rimarrà confinato nella nostra rete locale.

Utilizzo di un client esterno

Supponiamo di utilizzare diversi client: il browser, transmission-remote-gtk o transmission-remote-gui (transgui), tremotesf (mobile).

La prima cosa da fare è configurare un port forwarding sul nostro AP

Rule₁: 9091 ⇒ 192.168.70.10:9091

Dopodichè, configureremo stunnel in server mode davanti a transmission

[transmission]
accept = 192.168.70.10:9091
connect = 192.168.70.15:9091
cert = <path stunnel conf>/ssl/server/certs/stunnel_crt.pem
key = <path stunnel conf>/ssl/server/private/stunnel_key.pem
requireCert = yes
verifyChain = yes
verifyPeer = yes
CApath = <path stunnel conf>/ssl/client/certs

Alcune note sulla configurazione:

• devo disporre di un certificato per stunnel
• devo disporre dei certificati per i client che si connetteranno, le cui fullchain dovranno essere localizzate nel path indicato da CApath

A questo punto basta che i web-client puntino all’host pubblico (151.25.77.205) sulla porta 9091 e il gioco è fatto.

Per gli altri client come transmission-remote-gtk, transgui o tremotesf, per i quali al massimo posso chiedere di usare TLS (ma non sono riuscito ad usare un’autenticazione lato client), conviene installare stunnel in client mode :

[transmission-client]
accept = localhost:9091
connect = 151.25.77.205:9091
client = yes
cert = <path stunnel conf>/ssl/client/laptop_crt.pem
key = <path stunnel conf>/ssl/client/laptop_key.pem
verifyChain = yes
verifyPeer = yes
CAPath = <path stunnel conf>/ssl/server/certs

Il client (ad es. sul laptop) si connetterà su localhost:9091 e dovrà disporre anche del certificato del server e della sua fullchain affinchè i check su verifyChain e verifyPeer non falliscano.

#ca #DigitalCertificate #AsymmetricEncryption #SymmetricEncryption #cryptography #fullchain #psk #ssh #ssl #stunnel #tls #x509 #openssl

I Tor Onion Service (hidden service) sono di tipo V3. I servizi di tipo V2 sono deprecati da luglio 2020 e da ottobre 2021 verranno completamente rimossi dalla rete onion (rif. https://blog.torproject.org/v2-deprecation-timeline)

1. Configurazione lato server

Tor ha il suo file di configurazione in /etc/tor/torrc mentre la sua workdir, normalmente è su /var/lib/tor

Ogni hidden service viene riferito nel file di configurazione di tor, /etc/tor/torrc, da almeno una coppia di direttive:

• HiddenServiceDir: è la cartella dove verranno creati gli oggetti necessari all’hidden service (per default su /var/lib/tor/hidden_service)
• HiddenServicePort: la porta su cui il servizio sarà in ascolto, di fatto è la porta di inoltro verso il servizio vero e proprio.

1.1. HiddenServiceDir

Gli oggetti presenti in questa cartella sono:

• hostname: il nome del servizio composto da 56 caratteri casuali + l’estensione “.onion”
• hs_ed25519_public_key, hs_ed25519_private_key: la chiave pubblica e privata lato server usati dal nodo tor
• authorized_clients: se prevediamo di avere anche un’autenticazione per i client, avremo anche questa cartella. Come per il file authorized_keys per ssh, è una cartella contenente le chiavi pubbliche dei client autorizzati all’utilizzo del servizio.

1.2. HiddenServicePort

È una tripla

<porta_tor> <hostname>:<listen_port>

hostname di norma non è altri che localhost.

Una volta esplicitato l’HiddenServiceDir (l’HiddenServicePort è meno rilevante. A Tor non interessa che ci sia un servizio in ascolto effettivo), il riavvio del servizio Tor, creerà gli oggetti menzionati prima.

Se non ci fosse autenticazione, il client che accede alla rete Tor potrebbe già contattare il servizio esposto senza alcuna altra configurazione.

Se invece i client devono essere riconosciuti, sono richiesti altri passi di configurazione.

2. Configurazione lato client

• Configurazione di /etc/tor/torrc
• Creazione delle chiavi di autenticazione

2.1. Configurazione di /etc/tor/torrc

Inserire la direttiva ClientOnionAuthDir col path contenente i file di autenticazione per l’accesso agli hidden service

2.2. Creazione delle chiavi di autenticazione

Per ogni hidden service, si deve creare una coppia di chiavi x25519 pubblica e privata necessarie per l’autenticazione di ogni utente.

Le chiavi, generate con openssl e basez, sono di tipo x25519 in base32.

2.2.1. Chiave pubblica

La chiave pubblica andrà posizionata sul server nella cartella [HiddenServiceDir]/authorized_clients.

La sintassi del file dovrà rispettare questa forma: descriptor:x25519:<chiave pubblica x25519 in base32>

e il nome file dovrà essere <nome file>.auth

2.2.2. Chiave privata

La chiave privata andrà posizionata nel client nella cartella indicata da [ClientOnionAuthDir].

La sintassi del file dovrà rispettare questa forma: <indirizzo servizio onion senza estensione>:descriptor:x25519:<chiave privata x25519 in base32>

e il nome file dovrà essere: <nome file>.auth_private

Per rendere effettive le modifiche sul file torrc, sia sui client che sul server, si deve riavviare il servizio Tor.

3. Configurazione reale di due hidden service: web e ssh

Supponiamo per esempio di voler creare due hidden service: web e ssh

3.1. Creazione delle chiavi

1. Generazione della chiave openssl x25519

# web
openssl genpkey -algorithm x25519 -out /tmp/web.prv.pem
# ssh
openssl genpkey -algorithm x25519 -out /tmp/ssh.prv.pem

2. Generazione della chiave privata base 32

# web
cat /tmp/web.prv.pem | grep -v " PRIVATE KEY" | base64pem -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/web.prv.key
# ssh
cat /tmp/ssh.prv.pem | grep -v " PRIVATE KEY" | base64pem -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/ssh.prv.key

3. Generazione della chiave pubblica base 32

# web
openssl pkey -in /tmp/web.prv.pem -pubout | grep -v " PUBLIC KEY" | base64pem -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/web.pub.key
# ssh
openssl pkey -in /tmp/ssh.prv.pem -pubout | grep -v " PUBLIC KEY" | base64pem -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/ssh.pub.key

3.2. Configurazione lato server

Convenzioni:

Le seguenti convenzioni hanno il solo scopo di dare uniformità e scalabilità alla configurazione del servizio.

1. Creazione di una cartella diversa per ogni servizio esposto così da avere autenticazioni distinte per servizio e per utente.
2. Nella cartella del servizio, all’interno di authorized_clients, dove andranno posizionate le chiavi pubbliche, il nome delle chiavi sarà nel formato: <nome utente>_<nome servizio>.auth

3.2.1. Creazione cartelle per gli hidden service

# HTTP
mkdir -p /var/lib/tor/hidden_service/web/authorized_clients
chown -R toranon:toranon /var/lib/tor/hidden_service/web
 
# SSH
mkdir -p /var/lib/tor/hidden_service/ssh/authorized_clients
chown -R toranon:toranon /var/lib/tor/hidden_service/ssh

3.2.2. Configurazione /etc/tor/torrc

vi /etc/tor/torrc

...
HiddenServiceDir /var/lib/tor/hidden_service/web
HiddenServicePort 1080 127.0.0.1:80
 
HiddenServiceDir /var/lib/tor/hidden_service/ssh
HiddenServicePort 2022 127.0.0.1:22
...

Una considerazione sull’esposizione dei servizi. In questo esempio, i servizi girano sull’interfaccia di loopback ed ho imposto che le porte di esposizione del servizio siano quelle canoniche mentre sui corrispettivi .onion, da utilizzare attraverso i client, le porte sono non standard.

# Inizializzazione del servizio Tor per creare gli oggetti necessari all'esposizione, in particolare dell'hostname .onion
systemctl restart tor

3.2.3. Creazione file .auth e riavvio tor

# web
echo "descriptor:x25519:" > /var/lib/tor/hidden_service/web/authorized_clients/utente1_web.auth
cat /tmp/web.pub.key >> /var/lib/tor/hidden_service/web/authorized_clients/utente1_web.auth
 
# ssh
echo "descriptor:x25519:" > /var/lib/tor/hidden_service/ssh/authorized_clients/utente1_ssh.auth
cat /tmp/ssh.pub.key >> /var/lib/tor/hidden_service/ssh/authorized_clients/utente1_ssh.auth
	
# reload delle configurazioni e delle chiavi
systemctl restart tor 

3.3. Configurazione lato client

3.3.1. Convenzioni

1. Creazione di una cartella in cui raccogliere le chiavi private dell’utente
2. Il nome della chiave sarà: <nome utente>_<nome servizio>.auth_private

3.3.2. Creazione cartella per l’autenticazione

# SSH
mkdir /var/lib/tor/hidden_service/client_onion_auth
chown toranon:toranon /var/lib/tor/hidden_service/client_onion_auth

3.3.3. Creazione file .auth_private

# web
cat /var/lib/tor/hidden_service/web/hostname | cut -d "." -f 1 > /var/lib/tor/hidden_service/client_onion_auth/utente1_web.auth_private
echo ":descriptor:x25519:" >> /var/lib/tor/hidden_service/client_onion_auth/utente1_web.auth_private
cat /tmp/web.priv.key >> /var/lib/tor/hidden_service/client_onion_auth/utente1_web.auth_private
 
# ssh
cat /var/lib/tor/hidden_service/ssh/hostname | cut -d "." -f 1 > /var/lib/tor/hidden_service/client_onion_auth/utente1_ssh.auth_private
echo ":descriptor:x25519:" >> /var/lib/tor/hidden_service/client_onion_auth/utente1_ssh.auth_private
cat /tmp/ssh.priv.key >> /var/lib/tor/hidden_service/client_onion_auth/utente1_ssh.auth_private

3.3.4. Configurazione /etc/tor/torrc e riavvio tor

Nel file /etc/tor/torrc si deve modificare la direttiva ClientOnionAuthDir:

...
ClientOnionAuthDir /var/lib/tor/hidden_service/client_onion_auth
...

Dopodiché si riavvia il servizio tor per rendere consistente la modifica:

# Reload del servizio e acquisizione delle chiavi
systemctl restart tor

4. Conclusione

I servizi ora sono pronti per essere fruiti.

Nel caso del servizio web, non è necessaria la configurazione lato client di tor se si usa Tor Browser.

Per accedere in ssh attraverso tor si può provare in paio di modi.

1) Usando l’utility torify, normalmente installata insieme a tor:

torify ssh -p2022 user1@ahl5pohtheefai4apho4aiy6ohwaengo6ooxoh3ijie9ohgiish4phai.onion

2) Direttamente in ssh usando ProxyCommand per veicolare la connessione ssh attraverso tor:

ssh -p2022 user1@ahl5pohtheefai4apho4aiy6ohwaengo6ooxoh3ijie9ohgiish4phai.onion  -o ProxyCommand="ncat --proxy 127.0.0.1:9050 --proxy-type socks5 ahl5pohtheefai4apho4aiy6ohwaengo6ooxoh3ijie9ohgiish4phai.onion 2022"

tips: Usando una configurazione opportuna in $HOME/.ssh/config, l’utilizzo del servizio si semplifica notevolmente.

In .ssh/config:

Host ssh_service.onion
    Hostname ahl5pohtheefai4apho4aiy6ohwaengo6ooxoh3ijie9ohgiish4phai.onion
    User user1
    Port 2022
    VerifyHostKeyDNS no
    ProxyCommand ncat --proxy 127.0.0.1:9050 --proxy-type socks5 %h %p

A questo punto per accedere in ssh basta: ssh ssh_service.onion

Note a margine:

1. Il sistema di riferimento è Fedora 34
2. A differenza di SO debian-based, sui repository di Fedora 34 basez non è disponibile e va compilato.
3. La configurazione e l’hardenizzazione dei servizi da “torificare” esula dallo scopo di questo articolo, così come il dettaglio della configurazione di Tor

Riferimenti:

• https://tb-manual.torproject.org/onion-services/
• https://community.torproject.org/onion-services/setup/
• https://community.torproject.org/onion-services/advanced/client-auth/

#clientauthorization #hiddenservice #ssh #tor #torify