Come correggere la vulnerabilità 'logjam' in Apache (httpd)

Di recente è stata pubblicata una nuova vulnerabilità in Diffie-Hellman, informalmente denominata "logjam", per la quale questa pagina è stata messa insieme per suggerire come contrastare la vulnerabilità:

Abbiamo tre consigli per distribuire correttamente Diffie-Hellman per TLS:

Disabilita Export Cipher Suites. Anche se i browser moderni non supportano più le suite di esportazione, gli attacchi FREAK e Logjam consentono a un aggressore man-in-the-middle di indurre i browser a utilizzare la crittografia di livello di esportazione, dopo di che è possibile decrittografare la connessione TLS. Le cifre di esportazione sono un residuo della politica dell'era degli anni '90 che ha impedito l'esportazione dagli Stati Uniti di protocolli crittografici forti. Nessun cliente moderno si affida alle suite di esportazione e c'è un piccolo svantaggio nel disabilitarle.

Distribuisci (effimero) curva ellittica Diffie-Hellman (ECDHE). Lo scambio di chiavi Diffie-Hellman (ECDH) a curva ellittica evita tutti gli attacchi crittografici fattibili noti e i moderni browser Web ora preferiscono ECDHE rispetto al campo finito originale, Diffie-Hellman. Gli algoritmi di log discreti che abbiamo usato per attaccare i gruppi Diffie-Hellman standard non ottengono un forte vantaggio dal precomputazione e i singoli server non devono generare curve ellittiche uniche.

Genera un gruppo Hellman Diffie forte e unico . Alcuni gruppi fissi vengono utilizzati da milioni di server, il che li rende un obiettivo ottimale per il pre-calcolo e il potenziale intercettazione. Gli amministratori dovrebbero generare gruppi Diffie-Hellman unici, a 2048 bit o più potenti, utilizzando numeri primi "sicuri" per ogni sito Web o server.

Quali sono le procedure consigliate che dovrei adottare per proteggere il mio server secondo le raccomandazioni di cui sopra?

— Christophe De Troyer
fonte

Correlati: Cos'è Logjam e come posso impedirlo?

— Ripristina Monica - M. Schröder,

Risposte:

Dal articolo si è collegato , ci sono tre passaggi raccomanda di proteggere se stessi contro questa vulnerabilità. In linea di principio, questi passaggi si applicano a qualsiasi software che è possibile utilizzare con SSL / TLS, ma qui verranno trattati i passaggi specifici per applicarli ad Apache (httpd) poiché si tratta del software in questione.

Disabilita Export Cipher Suites

Di cui ci occuperemo nelle modifiche alla configurazione che faremo in 2. di seguito ( !EXPORTverso la fine della SSLCipherSuiteriga è come disabiliteremo le suite di crittografia di esportazione)

Distribuisci (effimero) curva ellittica Diffie-Hellman (ECDHE)

Per questo, è necessario modificare alcune impostazioni nei file di configurazione di Apache SSLProtocol, vale a dire SSLCipherSuite, SSLHonorCipherOrderper avere una configurazione "best practice". Qualcosa di simile al seguente sarà sufficiente:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Nota: per quanto riguarda l' SSLCipherSuiteimpostazione da utilizzare, questa è sempre in evoluzione ed è una buona idea consultare risorse come questa per verificare l'ultima configurazione consigliata.

3. Generare un gruppo Hellman Diffie forte e unico

Per fare ciò, puoi correre

openssl dhparam -out dhparams.pem 2048.

Si noti che ciò comporterà un carico significativo sul server durante la generazione dei parametri: è sempre possibile aggirare questo potenziale problema generando i parametri su un altro computer e utilizzando scpo simili per trasferirli sul server in questione per l'uso.

Per utilizzare questi appena generati dhparamsin Apache, dalla documentazione di Apache :

Per generare parametri DH personalizzati, utilizzare il comando openssl dhparam. In alternativa, è possibile aggiungere i seguenti parametri DH a 1024 bit standard da RFC 2409, sezione 6.2 al rispettivo file SSLCertificateFile :

(enfatizzare il mio)

a cui fa seguito un parametro DH standard a 1024 bit. Da ciò possiamo dedurre che i parametri DH personalizzati possono essere semplicemente aggiunti al pertinente SSLCertificateFilein questione.

Per fare ciò, eseguire qualcosa di simile al seguente:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

In alternativa, secondo la sottosezione Apache dell'articolo che hai originariamente collegato, puoi anche specificare il file dhparams personalizzato che hai creato se preferisci non modificare il file del certificato stesso, quindi:

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

in qualunque configurazione di Apache sia rilevante per la tua specifica implementazione SSL / TLS - generalmente in conf.d/ssl.confo conf.d/vhosts.confma questo differirà a seconda di come hai configurato Apache.

Vale la pena notare che, come da questo link ,

Prima di Apache 2.4.7, il parametro DH è sempre impostato su 1024 bit e non è configurabile dall'utente. Questo è stato corretto in mod_ssl 2.4.7 che Red Hat ha eseguito il backport nella sua distribuzione Apache 2.2 di RHEL 6 con httpd-2.2.15-32.el6

Su Debian Wheezy aggiorna apache2 a 2.2.22-13 + deb7u4 o successivo e si apre a 1.0.1e-2 + deb7u17. Il precedente SSLCipherSuite non funziona perfettamente, invece usa quanto segue come in questo blog :

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

Dovresti verificare se la tua versione di Apache è successiva a questi numeri di versione a seconda della tua distribuzione e, in caso contrario, aggiornarla se possibile.

Dopo aver eseguito i passaggi precedenti per aggiornare la configurazione e aver riavviato il servizio Apache per applicare le modifiche, è necessario verificare che la configurazione sia desiderata eseguendo i test su SSLLabs e sull'articolo relativo a questa particolare vulnerabilità.

— BE77Y
fonte

Per quanto riguarda il carico messo sul server generando i parametri, puoi sempre generarli su un altro computer e semplicemente scp o persino copiare e incollare il file sul server di destinazione. Non è necessario generare i parametri nel server di produzione.

— Erathiel,

Dopo aver modificato la configurazione, potresti voler eseguire un controllo su SSLLabs.com anche solo per essere sicuro.

— user2428118

Esiste un modo per correggere questa vulnerabilità in Apache / 2.2.22 (Ubuntu 12.04)? Ho aggiunto dhparams.pem a certificate.crt ma weakdh.org/sysadmin.html si lamenta ancora

— tersmitten,

@tersmitten Questa è una domanda completamente separata da questa.

— Michael Hampton

puoi sempre eseguire la generazione delle chiavi con il comando 'nice'. quindi, puoi metterlo come: nice 19 openssl dhparam -out dhparams.pem 2048. Funzionerà più a lungo, ma consumerà solo tempo inutilizzato della CPU.

— Znik,

Sulla base di una patch di Winni Neessen ho pubblicato una correzione per Apache / 2.2.22 (Debian Wheezy, forse utilizzabile anche su Ubuntu): https://flo.sh/debian-wheezy-apache2-logjam-fix/ - thx . per il tuo feedback.

— Flo
fonte

questo è più un trucco hacker che una soluzione. mettere un nginx recente davanti al tuo apache come proxy inverso sarebbe molto più semplice e non ci si affida a un apache di terze parti.

— quel tizio del

Perché dovremmo fidarci di questi binari?

— un CVn del

Non devi fidarti dei binari; puoi ricompilare apache2.2.x tu stesso molto facilmente seguendo i passaggi spiegati se prendi il tempo. Ciò aumenterebbe ulteriormente la sicurezza, poiché la configurazione prevede chiavi primarie univoche.

— Flo

Suggerirebbe che le persone non si lamentino delle patch che risolvono un problema in un software opensource.

— Florian Heigl,

@FlorianHeigl Non sono nemmeno sicuro di cosa fare di quel commento ...

— BE77Y

-7

Invece di seguire la complessa strada degli "hack" sopra elencati, prendi in considerazione il passaggio a nginx come principale software per server web (non solo cache o proxy). Sembra ovviamente più all'altezza degli standard attuali, dal punto di vista della sicurezza, rispetto ai vecchi motori apache. Usando il repository nginx ti sta dando un motore web server stabile più aggiornato di apache.

Sono completamente passato. Mi ha risparmiato un sacco di tempo per la risoluzione dei problemi relativi a TLS e, per le nostre configurazioni, ha anche liberato molta RAM nello stesso processo. In effetti, ho trovato l'impiego di nginx piacevolmente semplice e diretto, rispetto alla miriade di complicazioni di configurazione di httpd / apache a cui mi ero abituato. Potrebbe essere una questione di gusti, ero diventato abbastanza fluente in httpd / apache rewrite / config / maintenance prima di girare, ed era più facile di quanto temessi. Ci sono informazioni recenti appropriate sulla configurazione di nginx disponibili online e la sua base di utenti è enorme, molto attiva e di supporto. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png

— Giulio
fonte

L'impostazione di nginx per consentire le cifre di esportazione sarebbe esattamente vulnerabile all'attacco Logjam come un server Apache impostato per consentire le cifre di esportazione. Inoltre, la domanda richiede soluzioni in Apache.

— un CVn

In realtà, soluzione: passare a una distribuzione che fornisce pacchetti più aggiornati per software in cui è assolutamente necessaria una versione più recente (non solo correzioni di bug backported, come ad esempio il caso di Debian o CentOS), oppure compilare pacchetti da soli dal sorgente (non è difficile) e installali usando il gestore dei pacchetti, o semplicemente la vecchia installazione dal codice sorgente (anche non difficile, ma richiede un po 'più di lavoro per la gestione). Per una domanda che pone "come posso mitigare la vulnerabilità X all'interno del software Y?", Una risposta che afferma "sostituire il software Y con il software Z" spesso non è una risposta utile.

— un CVn

Apache a Nginx non è un aggiornamento, è un rimpiazzo. Il backport è una possibilità. Se hai investito molto lavoro nella soluzione Apache, eliminarlo completamente e sostituirlo con qualcos'altro richiede anche molto lavoro. E questa domanda riguarda ancora le soluzioni incentrate su Apache , non su Nginx. Non passerò più tempo a discuterne; quando pubblichi risposte, assicurati che rispondano alla domanda come richiesto nella parte superiore della pagina. Se vuoi pubblicare una risposta che incoraggi le persone a passare da Apache a Nginx, fallo in ogni caso, ma a una domanda che consenta Nginx.

— un CVn

Quindi configurare correttamente un software per proteggerlo da attacchi noti è "un percorso complesso di hack"? Ottengo A + su ssllabs.com con una semplice configurazione di Apache, devi solo prenderti il tuo tempo e fare qualche ricerca per capire come configurare correttamente il software che stai utilizzando, senza hack qui ...

— Chazy Chaz

@Julius - i downvotes hanno probabilmente più a che fare con la mancanza di valore nella tua risposta riguardo alla domanda posta, di quanto qualsiasi "agenda" nascosta apparentemente potrebbe avere contro nginx vs apache. In effetti, utilizzo nginx esclusivamente per via delle mie preferenze, ma sono stato io a rispondere a questa domanda. "Passa ad altro software" non è una risposta accettabile a "come risolvere (qualsiasi problema)". Per non parlare, hai anche perso del tutto il punto dell'attuale vulnerabilità - era nello scambio di chiavi diffie-hellman, non apache (o nginx, o sshd, o ...)

— BE77Y