Secure your Secure Shell

Perfect forward secrecy è una proprietà dei protocolli di negoziazione delle chiavi che assicura che se una chiave di cifratura a lungo termine viene compromessa, le chiavi di sessione generate a partire da essa rimangono riservate.

Scambio chiavi
Con SSH abbiamo due modi per scambiare chiavi in modo sicuro tra server e client, uno è il Diffie-Hellman, l’altro è Elliptic Curve Diffie-Hellman.
Entrambi offrono PFS ed entrambi sono odiati dall’ NSA proprio per questa ragione.

OpenSSH supporta 11 protocolli di scambio di chiavi:

  1. curve25519-sha256 : ECDH su Curve25519 con SHA2
  2. diffie-hellman-group1-sha1 : 1024 bit DH con SHA1
  3. diffie-hellman-group14-sha1 : 2048 bit DH con SHA1
  4. diffie-hellman-group14-sha256 : 2048 bit DH con SHA2
  5. diffie-hellman-group16-sha512 : 4096 bit DH con SHA2
  6. diffie-hellman-group18-sha512 : 8192 bit DH con SHA2
  7. diffie-hellman-group-exchange-sha1 : Custom DH con SHA1
  8. diffie-hellman-group-exchange-sha256 : Custom DH con SHA2
  9. ecdh-sha2-nistp256: ECDH su NIST P-256 con SHA2
  10. ecdh-sha2-nistp384: ECDH su NIST P-384 con SHA2
  11. ecdh-sha2-nistp521: ECDH su NIST P-521 con SHA2

Per la scelta della curva ECDH da questo listato dobbiamo osservare tre cose:
Da questa lista eliminiamo subito le ultime tre curve in quanto di proprieta’ del NIST e a noi il NIST non piace in quanto progetta di proposito algoritmi vulnerabili.

1024bit è una dimensione troppo piccola per il modulo DH quindi scartiamo anche il 2 e il 7.

Il modulo sha1 è un modulo pieno di bug, per la funzione hash useremo sha2. Quindi dal di sopra listato scarteremo anche il 3 oltre a quelli gia precedentemente messi da parte.

Curve25519 è il migliore e basterebbe anche da solo ma c’è il rischio di non essere compatibili con clients tipo winscp ed eclipse quindi includiamo anche 4,6 e 8.
Possiamo aggiungerli al file di configurazione di SSH in questo modo:

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Autenticazione
Lo scambio di chiavi garantisce che il server e il client condividano un segreto che nessun altro conosce. Dobbiamo anche assicurarci che condividano questo segreto l’uno con l’altro e non con un analista dell’NSA.
Per l’autenticazione esistono 4 algoritmi a chiave pubblica:

  1. DSA con SHA1
  2. ECDSA con SHA256, SHA384 o SHA512
  3. Ed25519 con SHA512
  4. RSA con SHA1

Le chiavi DSA non sono mai piu grandi di 1024bit, troppo poco, le scartiamo.
ECDSA sono del NIST e anche loro vanno disabilitate. Esse utilizzano la casualita’ per ogni firma quindi se la casualita’ non è il pezzo forte di questo algoritmo, loscartiamo.
RSA anche se utilizza sha1 non è un problema, quindi andremo ad aggiungere questa riga al nostro file di configurazione di ssh:

Protocol 2 HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key

Questo disabiliterà anche il protocollo v1 terribilmente rotto che non dovresti aver abilitato in primo luogo. Dovremmo rimuovere le chiavi non utilizzate e generare solo una grande chiave RSA e una chiave Ed25519. Gli script di init possono ricreare le chiavi non utilizzate. Se non lo desideri, rimuovi i comandi ssh-keygen dallo script di init.

cd /etc/ssh rm ssh_host_*key* ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null

Autenticazione client
Il client deve dimostrare la propria identità anche al server. Ci sono vari metodi per farlo.

La più semplice è l'autenticazione della password. Questo dovrebbe essere disabilitato immediatamente dopo aver impostato un metodo più sicuro perché consente ai server compromessi di rubare le password. L'autenticazione tramite password è anche più vulnerabile agli attacchi bruteforce online.
Disabilitiamola sia sul server che sul client:

PasswordAuthentication no ChallengeResponseAuthentication no

Il metodo più comune e sicuro è l'autenticazione a chiave pubblica, sul server aggiungiamo:

PubkeyAuthentication yes

Genera chiavi client usando i seguenti comandi:

ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100

È possibile distribuire le nuove chiavi pubbliche del client utilizzando ssh-copy-id.
È anche possibile utilizzare l'autenticazione OTP per ridurre le conseguenze delle password perse. Google Authenticator è una buona implementazione di TOTP o password One Time Timeed . Puoi anche utilizzare un elenco stampato di password singole o qualsiasi altro modulo PAM , in realtà, se abiliti ChallengeResponseAuthentication.

Cifrari simmetrici
I cifrari simmetrici vengono utilizzati per crittografare i dati dopo il primo scambio di chiavi e l'autenticazione è completa.
Qui abbiamo alcuni algoritmi (10-14 sono stati rimossi in OpenSSH 7.6 ):

  1. 3des-cbc
  2. AES128-CBC
  3. AES192-CBC
  4. AES256-CBC
  5. AES128-ctr
  6. AES192-ctr
  7. AES256-ctr
  8. aes128-gcm@openssh.com
  9. aes256-gcm@openssh.com
  10. arcfour
  11. arcfour128
  12. arcfour256
  13. blowfish-cbc
  14. CAST128-CBC
  15. chacha20-poly1305@openssh.com

Dobbiamo considerare quanto segue.
Per la Sicurezza dell'algoritmo, essendo sia DES che RC4 completamente bacati li escludiamo, quindi 1,10 e 12 via!
Le dimensioni della chiave almeno 128bit.
Le dimensioni del blocco devono anche esse essere di almeno 128bit quindi eliminiamo 13 e 14 perchè di 64.
Per la modalita' di cifratura preferiamo quelli che supportano AE, authenticated encryption.

La crittografia autenticata ( AE ) o la crittografia autenticata con i dati associati ( AEAD ) è una forma di crittografia che fornisce simultaneamente garanzie di riservatezza , integrità e autenticità sui dati. Questi attributi sono forniti in un'unica interfaccia di programmazione facile da usare.

Facoltivamente consentiremo CTR per questioni di retro compatibilita'. CTR con Encrypt-then-MAC è provabilmente sicuro.

Chacha20-poly1305 è preferito su AES-GCM perché il protocollo SSH non crittografa le dimensioni dei messaggi quando GCM è in uso. Ciò consente alcune analisi del traffico anche senza decifrare i dati. Ci occuperemo presto di questo.

Aggiungiamo quanto segue sia sul server che sul client:
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Codici di autenticazione dei messaggi
La crittografia fornisce riservatezza , il codice di autenticazione dei messaggi garantisce l' integrità . Abbiamo bisogno di entrambi. Se è selezionata una modalità di cifratura AE, non vengono utilizzati MAC aggiuntivi, l'integrità è già fornita. Se è selezionato CTR, allora abbiamo bisogno di un MAC per calcolare e allegare un tag ad ogni messaggio.
Esistono diversi modi per combinare cifrari e MAC: non tutti sono utili. I 3 più comuni:

  1. Encrypt-then-MAC : crittografa il messaggio, quindi collega il MAC del testo cifrato.
  2. MAC-then-encrypt : collega il MAC del testo in chiaro, quindi crittografa tutto.
  3. Encrypt-and-MAC : crittografa il messaggio, quindi collega il MAC del testo in chiaro.

Utilizzare solo Encrypt-then-MAC.
In caso di Encrypt-then-MAC, il MAC è verificato e, se errato, scartato. In caso di MAC-then-encrypt, prima il messaggio fornito dall'hacker deve essere decodificato e solo dopo puoi verificarlo. L'errore di decrittografia richiede meno tempo rispetto a un errore di verifica.
Ecco le scelte MAC disponibili:

  1. HMAC-MD5
  2. hmac-MD5-96
  3. HMAC-SHA1
  4. hmac-sha1-96
  5. hmac-sha2-256
  6. hmac-sha2-512
  7. UMAC-64
  8. UMAC-128
  9. hmac-md5-etm@openssh.com
  10. hmac-md5-96-etm@openssh.com
  11. hmac-sha1-etm@openssh.com
  12. hmac-sha1-96-etm@openssh.com
  13. hmac-sha2-256-etm@openssh.com
  14. hmac-sha2-512-etm@openssh.com
  15. umac-64-etm@openssh.com
  16. umac-128-etm@openssh.com

Sicurezza dell'algoritmo hash : No MD5 e SHA1.
Encrypt-then-MAC : non sono a conoscenza di una prova di sicurezza per CTR-and-HMAC. Dato che non ci sono su CTR attacchi di downgrade possiamo aggiungerli alla fine della lista per retrocompatibilita'.
Dimensione tag : almeno 128 bit. Questo elimina umac-64-etm.
Dimensione della chiave almeno 128 bit.

Aggiungiamo al file di configurazione di SSH quanto segue sia per il client che per il server:
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

Lascia un commento