it-swarm.dev

Configurazione sicura di Cipher / MAC / Kex disponibile in SSH

Seguendo la domanda postata qui di seguito, Tassonomia di Ciphers/MAC/Kex disponibile in SSH? , ho bisogno di aiuto per ottenere i seguenti obiettivi di progettazione:

  • Disabilita qualsiasi algoritmo HMAC a 96 bit.
  • Disabilita qualsiasi algoritmo HMAC basato su MD5.
  • Disabilita i Cipher Mode CBC e usa i Cipher Mode CTR.

A tal fine, il seguente è l'elenco predefinito per le cifre supportate:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour

Stavo cercando di cambiarlo in questo:

Ciphers aes256-ctr,aes192-ctr,aes128-ctr,[email protected],[email protected],arcfour256

Successivamente, per l'HMAC, supporta quanto segue:

[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96

E stavo cercando di cambiarlo in questo:

[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected],hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-ripemd160

Ciò fornirà il massimo beneficio in termini di sicurezza, mitigando al contempo le debolezze e gli attacchi noti contro le configurazioni SSH comuni? Si noti che questa domanda non riguarda 0 giorni o altri difetti correlati nel codice SSH e riguarda in particolare la migliore disposizione e configurazione possibile di cifre, algoritmi Kex e MAC. Se l'ordine è errato, suggerisci un metodo migliore per organizzarli. Questo vale anche per il file sshd_config e non per le connessioni client.

27
John

In questo momento, non sono noti punti deboli con la crittografia MD5 o CBC o MAC a 96 bit come sono utilizzati in SSH. Quindi, rigorosamente sensu, non ci sono benefici per la sicurezza nell'attuare le modifiche alla configurazione che stai proponendo. Si potrebbe sostenere che la rimozione del supporto per alcuni algoritmi potrebbe porta a problemi di sicurezza perché potrebbe impedire ad alcuni client di connettersi, costringendo così l'utente a trovare soluzioni alternative che potrebbero essere meno sicure (ad es. Se scp non è più possibile, invia il file tramite e-mail ...).

Il meno irrazionale dei tuoi obiettivi di progettazione è il divieto contro CBC. La sicurezza CBC richiede una corretta gestione dei vettori di inizializzazione; nel caso di SSH, l'IV viene estratto dall'ultimo blocco del pacchetto precedente (vedi lo standard ), che va bene fintanto che l'attaccante non si trova in una situazione di "attacco in chiaro" scelto. In pratica, i dati che entrano nel tunnel SSH non sono ostili, contrariamente a quanto avviene nei contesti HTTPS in cui il codice client dannoso (in Javascript) è una possibilità definita. Allo stesso modo, il riempimento degli attacchi Oracle su SSH è difficile da sfruttare (supponendo che il codice client o server non sia adeguatamente protetto), poiché SSH è orientato alla connessione e ha vinto 'riapri automaticamente la connessione fallita (di nuovo lì, contrariamente a quanto accade con HTTPS).

Allo stesso modo, HMAC/MD5 è, per quanto ne sappiamo, solido come non mai. Gli attacchi di collisione noti su MD5 non influiscono sulla sicurezza dell'HMAC, tranne nei sensi più vividi (che possono essere riassunti come: "MD5 puzza"). Per quanto riguarda il troncamento dei valori HMAC a 96 bit, non vi è ancora motivo di discriminare: un utente malintenzionato ignorerà con successo un valore MAC a 96 bit con probabilità 2-96, che è estremamente basso e impossibile da sfruttare in pratica perché any L'errore MAC su una singola connessione SSH viene segnalato con un messaggio di errore abbastanza visibile. Questo è ancora il modo in cui viene utilizzato SSH che lo protegge dal livello di automazione degli attacchi che può essere applicato a HTTPS.

Pertanto, si potrebbe dire che, poiché l'eliminazione degli algoritmi dall'elenco è a beneficio dei tuoi sentimenti di sicurezza, l'elenco giusto è quello che ti farà sentire più sicuro. Questo è soggettivo, per definizione, quindi sei l'unico che può definire questo elenco "migliore". Per quanto mi riguarda, sono abbastanza contento delle impostazioni predefinite.


Per quanto riguarda ordina, considera questo estratto da sezione 7.1 di RFC 425 :

  encryption_algorithms
     A name-list of acceptable symmetric encryption algorithms (also
     known as ciphers) in order of preference.  The chosen
     encryption algorithm to each direction MUST be the first
     algorithm on the client's name-list that is also on the
     server's name-list.

Quindi l'algoritmo scelto sarà l'algoritmo preferito del client . L'ordine di preferenza del server è solo un commento glorificato; non inciderà sull'algoritmo effettivamente scelto. Pertanto, l'ordine in /etc/sshd_config non è importante.

32
Tom Leek

Chiunque sia davvero preoccupato per la sicurezza di SSH probabilmente vuole leggere questa pagina:

https://stribika.github.io/2015/01/04/secure-secure-Shell.html

Passa attraverso tutti gli scambi di chiavi, le autenticazioni dei server, le cifre e i MAC supportati da OpenSSH e quindi butta via tutto ciò che non può più essere considerato sicuro, fornendo una valida giustificazione per tutto ciò che elimina. Con questa configurazione, sei solido come una roccia!

TL; DR? I vincitori per la massima sicurezza sono:

Scambio chiave: curve25519-sha256
(ricaderci: diffie-hellman-group-exchange-sha256)

Autenticazione del server: Ed25519 with SHA512
(ricaderci: RSA with SHA1 4096 Bits)

Cifra: chacha20-poly1305
(ricaderci: aes256-ctr)

MAC: hmac-sha2-512-etm
(ricaderci: hmac-sha2-512)

Il fallback è ciò che troverai sulla maggior parte dei server SSH, non altrettanto sicuro, ma comunque abbastanza sicuro dagli standard di oggi.

Un solo commento da parte mia: se usi SSH anche per copiare dati (scp o rsync) o per il port forwarding X11 o VNC, le prestazioni e la latenza non sono irrilevanti. In quel caso, aes128-ctr offrirà le migliori prestazioni (al di fuori delle cifre che sono note per essere sicure ad oggi) e potresti prendere in considerazione l'utilizzo di [email protected], dato che anche MD5 è stato rotto, HMAC-MD5 non ha funzionato fino ad oggi e MD5 batte SHA-1 in velocità e SHA-2 anche di gran lunga. Per avere un'idea della velocità dell'algoritmo, vedi quella pagina:

https://www.cryptopp.com/benchmarks.html

IMHO è un compromesso accettabile: scambiare un po 'di sicurezza per molta più velocità.

Che dire chacha20-poly1305? Né ho benchmark per chacha20-poly1305 finora, né posso dire che si sia dimostrato sicuro. Dovrebbe essere un sostituto di RC4 (aka arcfour), quindi probabilmente è anche più veloce di aes128-ctr nel software, ma le moderne CPU Intel sono in grado di calcolare AES128 nell'hardware, quindi se l'implementazione di SSH lo utilizza, puoi aspettarti che AES128 sia molto veloce. Tuttavia ChaCha potrebbe essere più veloce ma è la sicurezza non ancora provata che mi preoccupa un po '; troppi piccoli attacchi sono stati tentati su di esso e anche se esiste dal 2008, solo recentemente ChaCha è diventato popolare quando è stato rivelato che il NSA può interrompere le connessioni SSL/TLS RC4 in tempo reale. ChaCha deve risolvilo e sostituisci RC4 in TLS ma non è una prova della sua sicurezza.

Non preoccuparti mai dello scambio di chiavi o dell'autenticazione del server, la loro velocità gioca un ruolo solo alla connessione iniziale e ogni volta che la chiave deve essere rinnovata (quando ciò accade dipende dalla cifra scelta e dalla quantità di dati che trasferisci ... ogni cifra ha un limite di dati e una volta raggiunta, una nuova chiave viene scambiata perché stare con quella esistente indebolirebbe la crittografia da quel momento in poi), ma i rinnovi non avvengono frequentemente, quindi per questi due andrei sempre per massima sicurezza e ignora del tutto la velocità.

E non usare mai gli hash troncati (-96) per MD5 o SHA-1. Non offrono alcun vantaggio reale oltre al salvataggio di un paio di byte per pacchetto (4 per MD5, 8 per SHA-1). L'hash impiegherà altrettanto tempo a calcolare/verificare (nessun vantaggio di velocità) e il troncamento indebolisce solo la sicurezza (nessun vantaggio di sicurezza). Il troncamento pagherebbe per SHA-2 poiché questi sono molto più grandi (32, 48, 64 byte per pacchetto) e hash così grandi non hanno senso considerando la dimensione massima di un pacchetto di trasmissione, ma per questi troncamenti non è un'opzione.

9
Mecki

Per rimuovere le cifre cbc, aggiungi o modifica la riga "Ciphers" in/etc/ssh/sshd_config come di seguito: Ciphers aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, arcfour

Per rimuovere HMAC MD5 Aggiungere o modificare la riga MAC in/etc/ssh/sshd_config come di seguito: MAC hmac-sha1, hmac-ripemd160

Riavvia SSHD per applicare le modifiche: servizio sshd restart

2