crittografie SSH, MAC e scambio di chiavi (e pen-test dello stesso)

Naviga le tue risposte
7

Al lavoro abbiamo cercato di spostare i nostri servizi rivolti all'esterno da una politica di inclusività (in cui abbiamo cercato di accogliere quante più persone possibile) in una configurazione più incentrata sulla sicurezza.

Il primo passo è stato il test delle penne di alcune delle nostre applicazioni web principali, dove l'attenzione tende a essere debole sul codice dell'applicazione, ma molto è stato detto delle suite e dei codici SSL / TLS. Dalla parte posteriore di questi risultati, sono riuscito ad ottenere almeno un numero sufficiente di persone interessate a raggiungere i "gradi" A-, A e A + nei test Qualys (gestione come gradi quantificabili - chi lo sapeva?!) .

Tuttavia, un altro componente chiave di alcuni dei nostri software è il caricamento / scaricamento di file in blocco tramite SFTP (ad esempio tramite SSH). Ho sempre cercato di applicare le buone pratiche che potevo determinare sui server SFTP, quindi utilizziamo abitualmente:

  • autenticazione solo tramite chiave
  • blacklist degli errori di autenticazione ripetuti
  • Tasti da 2.048 bit
  • disabilitazione di shell, exec e port forwarding

Ma devo ammettere che so ben poco delle implementazioni crittografiche, quindi le impostazioni predefinite sono state quasi sempre utilizzate. Tuttavia, presumo che, se un pen-tester contrassegna RC4, 3DES, MD5, et al. in una configurazione basata su TLS, avrebbero anche contrassegnato questi algoritmi in un server SFTP (erano inclusi nel loro ambito).

Principalmente sto lavorando su uno stack Windows e abbiamo utilizzato VanDyke VShell come server SFTP preferito da molti anni. Per impostazione predefinita, abilita tutte le opzioni di cifratura e MAC (ad eccezione di "Nessuna") e tutte le opzioni di scambio di chiavi ad eccezione di "Kerberos" e "Kerberos (Scambio di gruppo)".

Questo lascia i seguenti algoritmi, come indicato dall'applicazione VShell:

  • Scambio di chiavi: diffie-hellman-group14, diffie-hellman, diffie-hellman-group
  • Codice: AES-256-CTR, AES-192-CTR, AES-128-CTR, AES-256, AES-192, AES-128, Twofish, Blowfish, 3DES, RC4
  • MAC: SHA1, SHA1-96, MD5, MD5-96, UMAC-64 (e, nelle versioni più recenti) SHA2-512, SHA2-256

Per quanto riguarda le domande:

  1. Dove sono i riferimenti migliori per me per determinare quali di questi sono ora considerati troppo deboli da usare?
  2. Come posso determinare al meglio se la disattivazione di una di queste funzioni possa influire negativamente sui miei utenti finali?
  3. Ci sono test di tipo Qualys che posso usare per valutare regolarmente questi server, preferibilmente con prove convincenti con cui battere la gestione in sottomissione?
posta jimbobmcgee 04.12.2015 - 18:53
fonte

1 risposta

4

  1. Sfortunatamente gli organismi di normalizzazione non concordano pienamente su un unico elenco di cifrari per la sicurezza SSL / TLS o SSH. Il seguente documento e i suoi riferimenti interni aiuteranno molto e credo che in generale owasp.org sarebbe un ottimo posto per tenere il passo con cifre deboli, ma sfortunatamente non esiste un elenco universale in questo momento.

    link

    Per l'hardening SSH, guarda in particolare quanto segue:

    link

    In definitiva, un elenco aggiornato che mappava il cipher supportato con un motivo per cui ognuno era ammortizzato sarebbe stato utile per tutti, ma non ho ancora visto uno sforzo simile.

  2. Il modo migliore per sapere cosa stanno usando i tuoi utenti finali è monitorare il traffico effettivo sul tuo sito. Puoi abilitare la registrazione della suite di crittografia sul tuo server SFTP o server web o semplicemente utilizzare un analizzatore di protocollo come WireShark, in particolare tshark, per questo.

    link

    In generale, le suite di crittografia limitanti sono in realtà semplici perché la maggior parte dei client degli ultimi 5-10 anni supporta un'ampia gamma di crittografie.

  3. Per testare questo, ti consiglio vivamente di utilizzare lo script nNe ssl enumerate ciphers o SSH lo script degli algoritmi enumerati SSH2:

    link

    Il comando per testare un sito Web sarà simile al seguente: 

    nmap --script ssl-enum-ciphers -p 443 www.website.org

    Esistono script simili per altri protocolli, per SSH quanto segue potrebbe funzionare

    link

    Questa informazione può essere raccolta dalle informazioni di debug2 nell'opzione ssh -vvv ma nmap è molto più facile da automatizzare.

    Per testare siti web esternamente, ci sono siti come il seguente che ti diranno informazioni sui cifrari SSL / TLS deprezzati su servizi basati su HTTPS.

    link

Al momento non ci sono "Qualys like siti web di test che corrispondono al loro sito Web di test SSL per SSH" il modo più vicino per ottenere informazioni simili per SSH è usare l'opzione ssh -vvv o usare lo script NSE di nmap ssh2-enum-algos .html. Ci sono altre soluzioni a questo, ma nmap è probabilmente la più facile da implementare ed è molto scriptable, quindi puoi farlo testare un numero enorme di IP facilmente.

    
risposta data 08.12.2015 - 01:24
fonte

Leggi altre domande sui tag

Diffie Hellman Key Exchange in un'applicazione di messaggistica A cosa serve Bitlocker basato su TPM se l'unità viene decrittografata automaticamente?