Como corrigir a vulnerabilidade 'logjam' no Apache (httpd)

56

Recentemente, foi publicada uma nova vulnerabilidade em Diffie-Hellman, informalmente chamada de 'logjam', para a qual esta página foi montada sugerindo como combater a vulnerabilidade:

Temos três recomendações para implantar corretamente o Diffie-Hellman for TLS:

  1. Desative Exportar conjuntos de criptografia. Embora os navegadores modernos não suportem mais pacotes de exportação, os ataques FREAK e Logjam permitem que um invasor intermediário induza os navegadores a usar criptografia de nível de exportação, após o qual a conexão TLS pode ser descriptografada. As cifras de exportação são um remanescente da política da década de 90 que impedia a exportação de fortes protocolos criptográficos dos Estados Unidos. Nenhum cliente moderno depende de suítes de exportação e há pouca desvantagem em desativá-los.
  2. Implante (efêmero) curva elíptica Diffie-Hellman (ECDHE). A troca de chaves Elliptic-Curve Diffie-Hellman (ECDH) evita todos os ataques criptoanalíticos conhecidos e os navegadores modernos agora preferem o ECDHE do que o campo finito original, Diffie-Hellman. Os algoritmos de log discretos que usamos para atacar os grupos Diffie-Hellman padrão não obtêm uma vantagem tão forte da pré-computação, e os servidores individuais não precisam gerar curvas elípticas exclusivas.
  3. Gere um grupo Diffie Hellman forte e exclusivo . Alguns grupos fixos são usados ​​por milhões de servidores, o que os torna um alvo ideal para pré-computação e possível interceptação. Os administradores devem gerar grupos Diffie-Hellman exclusivos, com 2048 bits ou mais fortes, usando números primos "seguros" para cada site ou servidor.

Quais são as etapas de práticas recomendadas que devo seguir para proteger meu servidor de acordo com as recomendações acima?

Christophe De Troyer
fonte
4
Relacionado: O que é o Logjam e como evito isso?
Reponha Monica - M. Schröder

Respostas:

82

No artigo que você vinculou , há três etapas recomendadas para se proteger contra essa vulnerabilidade. Em princípio, essas etapas se aplicam a qualquer software que você possa usar com SSL / TLS, mas aqui trataremos das etapas específicas para aplicá-las ao Apache (httpd), pois esse é o software em questão.

  1. Desativar conjuntos de criptografia de exportação

Lidamos com as alterações de configuração que faremos em 2. abaixo ( !EXPORTpróximo ao final da SSLCipherSuitelinha é como desabilitaremos os conjuntos de cifras de exportação)

  1. Implantar (efêmero) curva elíptica Diffie-Hellman (ECDHE)

Para isso, você precisa editar algumas configurações em seus arquivos de configuração do Apache - ou seja SSLProtocol, SSLCipherSuite, SSLHonorCipherOrderter uma configuração de "melhores práticas". Algo como o seguinte será suficiente:

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: quanto a qual SSLCipherSuiteconfiguração usar, isso está sempre mudando e é uma boa ideia consultar recursos como este para verificar a configuração recomendada mais recente.

3. Gere um grupo Diffie Hellman forte e exclusivo

Para fazer isso, você pode executar

openssl dhparam -out dhparams.pem 2048.

Observe que isso sobrecarregará significativamente o servidor enquanto os parâmetros são gerados - você sempre pode contornar esse problema em potencial gerando os parâmetros em outra máquina e usando scpou semelhante para transferi-los para o servidor em questão para uso.

Para usar estes recém-gerados dhparamsno Apache, na documentação do Apache :

Para gerar parâmetros DH personalizados, use o comando openssl dhparam. Como alternativa, você pode anexar os seguintes parâmetros DH de 1024 bits padrão do RFC 2409, seção 6.2 ao respectivo arquivo SSLCertificateFile :

(ênfase minha)

que é seguido por um parâmetro DH padrão de 1024 bits. A partir disso, podemos inferir que os parâmetros DH gerados sob encomenda podem ser simplesmente anexados ao relevante SSLCertificateFileem questão.

Para fazer isso, execute algo semelhante ao seguinte:

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

Como alternativa, de acordo com a subseção Apache do artigo que você vinculou originalmente, você também pode especificar o arquivo dhparams personalizado que você criou, se preferir não alterar o arquivo de certificado, assim:

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

nas configurações do Apache que sejam relevantes para sua implementação específica de SSL / TLS - geralmente em conf.d/ssl.confou conf.d/vhosts.confmas isso será diferente dependendo de como você configurou o Apache.

Vale ressaltar que, conforme este link ,

Antes do Apache 2.4.7, o parâmetro DH sempre é definido como 1024 bits e não é configurável pelo usuário. Isso foi corrigido no mod_ssl 2.4.7 que a Red Hat fez o backport em sua distribuição do RHEL 6 Apache 2.2 com httpd-2.2.15-32.el6

No Debian Wheezy, atualize o apache2 para 2.2.22-13 + deb7u4 ou posterior e o openssl para 1.0.1e-2 + deb7u17. O SSLCipherSuite acima não funciona perfeitamente. Em vez disso, use o seguinte conforme este 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

Você deve verificar se a sua versão do Apache é posterior a esses números de versão, dependendo da sua distribuição e, se não estiver, atualize-a, se possível.

Depois de executar as etapas acima para atualizar sua configuração e reiniciar o serviço Apache para aplicar as alterações, verifique se a configuração é desejada, executando os testes no SSLLabs e no artigo relacionado a essa vulnerabilidade específica.

BE77Y
fonte
11
Quanto à carga colocada no servidor, gerando os parâmetros, você sempre pode gerá-los em outra máquina e simplesmente scp ou até copiar e colar o arquivo no servidor de destino. Não há necessidade de gerar os parâmetros no servidor de produção.
Erathiel
2
Depois de alterar sua configuração, você pode executar uma verificação no SSLLabs.com também para ter certeza.
User2428118
2
Existe uma maneira de corrigir esta vulnerabilidade no Apache / 2.2.22 (Ubuntu 12.04)? I anexa dhparams.pem para certificate.crt mas weakdh.org/sysadmin.html ainda reclama
tersmitten
2
@tersmitten Essa é uma pergunta completamente separada para esta.
Michael Hampton
3
você sempre pode executar a geração de chaves pelo comando 'nice'. então, você pode colocar como: nice 19 openssl dhparam -out dhparams.pem 2048. Isso funcionará por mais tempo, mas consumirá apenas tempo de CPU não utilizado.
Znik
1

Com base em um patch do Winni Neessen, publiquei uma correção para o Apache / 2.2.22 (Debian Wheezy, talvez também utilizável no Ubuntu): https://flo.sh/debian-wheezy-apache2-logjam-fix/ - thx . pelo seu feedback.

Flo
fonte
3
isso é mais um hack do que uma solução. Colocar um nginx recente na frente do seu apache como proxy reverso seria muito mais fácil, e não se depende de um apache de terceiros.
aquele cara de lá
6
Por que devemos confiar nesses binários?
um CVn
2
Você não precisa confiar nos binários; você pode recompilar o apache2.2.x com muita facilidade, seguindo as etapas explicadas se demorar algum tempo. Isso aumentaria ainda mais sua segurança, pois sua configuração possui chaves primárias exclusivas.
Flo
Sugere que as pessoas não se queixem de patches que corrigem um problema em um software de código aberto.
Florian Heigl
@FlorianHeigl eu nem tenho certeza do que fazer com que o comentário ...
BE77Y
-7

Em vez de seguir a rota complexa dos 'hacks' acima, considere mudar para o nginx como seu principal servidor de software (não apenas cache ou proxy). Obviamente, parece mais com os padrões atuais, em termos de segurança, do que os antigos mecanismos apache. Ao usar o repositório nginx, ele oferece a você um mecanismo de servidor da web estável mais atualizado que o apache.

Eu mudei completamente. Economizei muito tempo na solução de problemas com relação ao TLS e - para nossas configurações - ele também liberou muita RAM ao mesmo tempo. De fato, achei o emprego do nginx agradável e simples, comparado à miríade de complicações de configuração do httpd / apache com as quais me acostumei. Pode ser uma questão de gosto, eu me tornei bastante fluente em httpd / apache rewrite / config / maintenance antes de virar, e era mais fácil do que eu pensava que seria. Há informações recentes apropriadas sobre a configuração do nginx disponíveis on-line, e sua base de usuários é enorme, muito ativa e amigável ao suporte. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png

Julius
fonte
3
O nginx configurado para permitir cifras de exportação seria exatamente tão vulnerável ao ataque do Logjam quanto um servidor Apache configurado para permitir cifras de exportação. Além disso, a pergunta pede soluções no Apache.
um CVn
2
Na verdade, solução: mude para uma distribuição que ofereça pacotes mais atualizados para o software em que você absolutamente precisa de uma versão mais recente (não apenas correções de bugs de backport, como é o caso do Debian ou CentOS), ou construa você mesmo os pacotes do código-fonte (não é difícil) e instale-os usando o gerenciador de pacotes ou uma instalação antiga simples do código-fonte (também não é difícil, mas exige um pouco mais de trabalho para gerenciar). Para uma pergunta que pergunta "como mitigar a vulnerabilidade X no software Y?", Uma resposta que declara "substituir o software Y pelo software Z" geralmente não é uma resposta útil.
um CVn
11
O Apache para Nginx não é uma atualização, é uma substituição. Backporting é uma possibilidade. Se você tem muito trabalho investido na solução Apache, jogá-lo completamente fora e substituí-lo por algo mais também exige muito trabalho. E essa pergunta ainda é sobre soluções centradas no Apache , não no Nginx. Não vou gastar mais tempo discutindo sobre isso; quando você postar respostas, verifique se elas respondem à pergunta, conforme solicitado na parte superior da página. Se você quiser postar uma resposta incentivando as pessoas a mudarem do Apache para o Nginx, faça isso de qualquer maneira, mas para uma pergunta que permita o Nginx.
um CVn
11
Então, configurar corretamente um software para se proteger contra ataques conhecidos é "uma rota complexa de hacks"? Recebo A + no ssllabs.com com uma configuração simples do apache, você só precisa de um tempo e fazer algumas pesquisas para entender como configurar corretamente o software que está usando, sem hacks por aqui ...
Chazy Chaz
11
@ Julius - os votos negativos provavelmente têm mais a ver com a falta de valor em sua resposta em relação à pergunta feita, do que qualquer "agenda" oculta que as pessoas aparentemente possam ter contra nginx vs apache. Por acaso, uso exclusivamente o nginx devido à minha preferência - mas fui eu quem respondeu a essa pergunta. "Mudar para outro software" não é uma resposta aceitável para "como corrigir (qualquer problema)". Para não mencionar, você também completamente perdido o ponto da vulnerabilidade real - estava em Diffie-Hellman, não apache (ou nginx, ou sshd, ou ...)
BE77Y