Postfix: Aplicando configurações para inibir a vulnerabilidade LogJam

Security2

Olá ! Neste artigo irei abordar as configurações que devem ser feitas no Postfix para inibir a vulnerabilidade LogJam.

Segue um resumo sobre esta vulnerabilidade:

Captura de tela de 2015-05-27 13:59:48

 Fonte: http://cryptoid.com.br/arquivo-cryptoid/logjam-entenda-o-que-e/

Primeiramente, é necessário gerar um grupo Diffie-Hellman com 2048 bits, embora 1024 bits sejam suficientes conforme o relatório de vulnerabilidade (https://weakdh.org/logjam.html). Esse procedimento pode ser efetuado com o Openssl:

openssl dhparam -out dhparams.pem 2048

Agora, é necessário aplicar as seguintes configurações no arquivo de configuração do Postfix (main.cf):

smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA

smtpd_tls_dh1024_param_file = /caminho/dhparams.pem

Uma vez que o grupo DH foi criado e as configurações aplicadas, basta efetuar um reload no serviço do Postfix.

Referências:

http://cryptoid.com.br/arquivo-cryptoid/logjam-entenda-o-que-e/
https://weakdh.org/logjam.html

Zimbra 8.6: SSL handshake failed

Olá ! Conforme devem ter acompanhado, a partir da versão 8.6 do Zimbra o suporte ao SSLv3 foi desabilitado, devido à falha de segurança conhecida como Poodle (http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html).

Recentemente atualizei um ambiente para a versão 8.6 do Zimbra e alguns sistemas que fazem uso de conexões IMAP não conseguiam mais acessar as mensagens; o seguinte erro era apresentado nos logs:

javax.net.ssl.SSLHandshakeException: SSL handshake failed

Isso ocorre pois muitos sistemas exigem pelo menos um Handshake SSL para iniciar a comunicação e se consultarmos os protocolos suportados pelo servidor IMAP do Zimbra, apenas TLS é suportado:

Captura de tela de 2015-04-07 22:13:18

Para habilitar a comunicação com sistemas que necessitam de um Handshake SSL, o protocolo SSLv2Hello pode ser adicionado aos protocolos suportados (o que não significa que o protocolo SSL será utiizado, o Handshake será pelo SSLv2Hello porém a comunicação será com TLS):

Captura de tela de 2015-04-07 22:17:37

Conforme pode ser observado no procedimento acima, é necessário reiniciar o serviço Mailbox.

Referências:

http://community.zimbra.com/collaboration/f/1886/t/1137420

https://wiki.zimbra.com/wiki/How_to_disable_SSLv3

Zimbra: Exigindo autenticação para envio de mensagens

Olá ! Neste artigo irei falar sobre uma prática de segurança que muitos administradores Zimbra necessitam implementar (e devem de fato: http://antispam.br/porta25/), que é exigir autenticação para o envio de mensagens.

ANTISPAM.BR: anuncio_porta25

Fonte: http://antispam.br/porta25/

Por padrão, o Zimbra libera o relay no servidor SMTP para toda a faixa de rede, como pode ser confirmado com o comando abaixo:

zmprov gs `zmhostname` zimbraMtaMyNetworks

Será exibida a faixa de rede do servidor (ipv4 e ipv6), conforme o exemplo abaixo:

zimbraMtaMyNetworks: 127.0.0.0/8 192.168.56.0/24 [::1]/128 [fe80::]/64

Muitos ainda se confundem com este conceito, mas a liberação para relay no servidor SMTP deve ser somente para hosts que necessitam encaminhar mensagens através dele, como outro servidores MTA ou aplicações que não possuem recurso de autenticação, por exemplo. Destaco também que para servidores MTA é possível implementar autenticação, isto é, permitir o relay somente com credenciais.

Veja aqui:

https://respirandolinux.wordpress.com/2014/12/09/postfix-habilitando-autenticacao-via-smtp-centos-7/

https://respirandolinux.wordpress.com/2014/10/28/postfix-efetuando-relay-em-hosts-que-exigem-autenticacao-e-nas-portas-submission-ou-smtps/

Para fechar o relay para a faixa de rede do servidor, utilize o comando abaixo para modificar o valor do atributo zimbraMtaMyNetworks:

zmprov ms `zmhostname` zimbraMtaMyNetworks ‘127.0.0.0/8 192.168.56.101/32 ::1/128 fe80::a00:27ff:feb7:c2be/64′

Com o comando acima, somente a interface de rede local e o próprio servidor estão liberados para relay, qualquer conexão de outro endereço IP terá que ser autenticada para enviar a mensagem. É possível efetuar essas modificações pele console Web, porém há um bug que não permite salvar após remover a faixa de rede.

zimbra860_mynetwork.png-940x0

Segue o link para o bug que reportei , afeta as versões 8.X e será corrigido na versão 8.7:

https://bugzilla.zimbra.com/show_bug.cgi?id=98419

Obs.: Essa implementação não significa que seu servidor não irá receber mensagens externas. Quer entender melhor estes conceitos?

Veja:

http://www.bktech.com.br/bktrainner

Referências:

https://community.zimbra.com/collaboration/f/1886/p/1138585/1583882#1583882

https://bugzilla.zimbra.com/show_bug.cgi?id=98419

http://antispam.br/porta25/

Zimbra: Trabalho sobre gerenciamento de logs

Zimbra Log management contest

Olá ! Recentemente a Zimbra promoveu um concurso sobre gerenciamento de Logs:

https://community.zimbra.com/collaboration/f/1884/t/1137939

O Zimbra utiliza os registros do sistema (log) para registrar tudo o que ocorre com a solução e seus componentes, portanto é muito importante monitorar e compreender os logs para administrar, antecipar-se a problemas ou até mesmo procurar pontos de falha.

Tive a oportunidade de entregar um trabalho, em colaboração com dois colegas de trabalho, com a centralização de Logs sendo feita com a solução ElasticSearch + Logstash + Kibana.

6566765765876854342

Nosso trabalho pode ser baixado no endereço abaixo, porém compartilho aqui nossa arquitetura proposta para um centralização de Logs de ambientes Zimbra com integração com outras soluções de correio:

Link para Download:

http://goo.gl/us2o2M

Zimbra Contest 2

Zimbra: Instalando certificado comercial (StarSSL)

Olá ! Implementar certificados comerciais é uma operação muito comum para quem administra o Zimbra, porém muitos administradores têm dificuldades com esta operação. Neste artigo irei procurar esclarecer o procedimento para instalação do certificado comercial, utilizando uma experiência com certificados da StartSSL (https://www.startssl.com) como exemplo.

Nesta implementação, não foi necessário gerar a requisição de assinatura do certificado foi o mesmo foi entregue com Wildcard, isto é, o caractere coringa permitindo todos os hostnames do domínio utilizado (*.dominio.com.br).

Para os certificados da StartSSL, é necessário efetuar o Download da CA raiz e da classe do seu servidor no link https://www.startssl.com/certs. Nesta implementação o certificado é CLASS2:

StartSSL certificates

Portanto, efetuamos o download dos arquivos:

 https://www.startssl.com/certs/ca.pem 

 https://www.startssl.com/certs/sub.class2.server.ca.pem

Agora, precisamos concatenar os dois arquivos em único:

# cat ca.pem  sub.class2.server.ca.pem > ca_StartSSL_full.pem

A entidade certificadora também deve enviar o certificado e a chave protegida com uma palavra chave,  para gerar a chave sem a palavra chave, execute:

# openssl rsa -in chave_com_senha.key -out chave_sem_senha.key

Agora, ainda como usuário root, é necessário verificar a validade do certificado com o comando abaixo:

# /opt/zimbra/bin/zmcertmgr verifycrt comm chave_sem_senha.key certificado.crt ca_StartSSL_full.pem

Você deve inserir nesta seguinte ordem: chave – certificado – CA

Ele deve informar que o certificado e chave são compatíveis e que o certificado é válido. Desta forma, a entidade certificadora está reconhecida.

Copie a chave para o diretório /opt/zimbra/ssl/zimbra/commercial com o nome commercial.key

Aplique o certificado no Zimbra:

# /opt/zimbra/bin/zmcertmgr deploycrt comm certificado.crt ca_StartSSL_full.pem

Você deve inserir nesta seguinte ordem: certificado – CA

Exemplo da instalação bem sucedida:

zimbra_comm_cert_deploy

Insira o certificado na área de armazenamento de chaves do Zimbra:

keytool -import -alias new -keystore /opt/zimbra/common/lib/jvm/openjdk-1.8.0_92-zimbra/jre/lib/security/cacerts -storepass changeit -file /opt/zimbra/ssl/zimbra/commercial/commercial.crt

Você deve informar que confia neste certificado.

Para concluir,  reinicie o Zimbra e confirme se o certificado comercial está sendo apresentado na console do Zimbra.

Referências:
https://www.startssl.com/?app=0
http://www.anta.net/misc/telnet-troubleshooting/imap.shtml
http://mnx.io/blog/removing-a-passphrase-from-an-ssl-key/
http://wiki.zimbra.com/wiki/Installing_a_StartSSL_SSL_Certificate_with_zmcertmgr

Dovecot: Implementando auditoria para caixas postais e mensagens

Olá ! Certamente um recurso muito interessante para servidores IMAP ou POP é a possibilidade de auditar as operações que estão sendo efetuadas nas caixas postais e mensagens.

No Dovecot é possível implementar essa auditoria através do Plugin Mail Logger (http://wiki2.dovecot.org/Plugins/MailLog):

Captura de tela de 2015-03-06 10:17:45

Conforme a imagem acima, as seguintes operações podem ser auditadas:

  • Aplicando e removendo a flag \Deleted
  • Expunge
  • Copiando mensagens para outra pasta (também se aplica para mover)
  • Criação de pastas
  • Remoção de pastas
  • Renomear pastas
  • Qualquer modificação nas flags
  • Armazenamento

Você pode habilitar o plugin para todos os serviços ou em um serviço específico através da entrada abaixo:

mail_plugins = $mail_plugins mail_log notify

O plugin notify é requerido para se aplicar o plugin mail_log, portanto, certifique-se que também o habilitou.

Agora você pode configurar o que deve se logado e quais campos devem ser considerados:

plugin

{
# Operação para logar
mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename flag_change save mailbox_create

# Informações da mensagem que devem ser apresentadas no log
mail_log_fields = uid box msgid size from subject flags vsize

}

A sintaxe utilizada neste artigo é para versões 2.X do Dovecot.

Referências:

http://wiki2.dovecot.org/Plugins/MailLog

Postfix: Desabilitando SSLv3 (Poodle Vulnerability)

Olá ! Neste post irei tratar de uma correção nas configurações do Postfix para uma vulnerabilidade reportada sobre o SSLv3, conhecido como POODLE. Caso deseje mais informações sobre a vulnerabilidade acesse estas documentações:

https://www.openssl.org/~bodo/ssl-poodle.pdf

http://www.sempreupdate.com.br/2014/10/ssl-e-vulneravel-ao-ataque-poodle-veja.html

Primeiramente, para verificar se o seu servidor está utilizando o SSL v3 utilize os comandos abaixo:

openssl s_client -connect SERVIDOR:465 -ssl3
openssl s_client -connect SERVIDOR:25 -ssl3 -starttls smtp
 

Se a conexão falhar com o erro “ssl handshake failure” seu servidor não está utilizando o SSL3, portanto não está vulnerável a este ataque.

Caso o seu servidor esteja utilizando o SSL3, modifique os seguintes parâmetros no arquivo de configuração (main.cf) do Postfix:

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3

Efetue um RELOAD no serviço do Postfix e teste novamente.

Zimbra: Aplicando Patch de segurança para a vulnerabilidade de CCS Injection (CVE-2014-0224)

Em um post anterior eu tratei a atualização de segurança para o Heartbleed no Zimbra, agora no dia 05 de Junho de 2014, os mantenedores do OpenSSL divulgaram uma nova correção de segurança para uma vulnerabilidade de CCS Injection descoberta: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224

Todas as versões do Zimbra Collaboration  8 são vulneráveis, destacando que se você estiver utilizando versões anteriores a 8.3 há diversas outras correções de segurança, portanto é recomenda a atualização do ambiente. Assim como a falha Heartbleed, somente a versão 1.0.1 da biblioteca OpenSSL é vulnerável, por isso, as versões 6 e 7 do Zimbra não são vulneráveis a estas falhas.

Para aplicar a correção, efetue o Download do script disponibilizado pela equipe do Zimbra para atualizar a biblioteca utilizada pela solução:

http://files.zimbra.com/downloads/security/zmopenssl-updater.sh

Pare o serviço (zmcontrol stop) e execute o “zmopenssl-updater” como usuário root. Para confirmar que a correção foi aplicada, execute “openssl version” como usuário Zimbra e a  compilação do Openssl deve ser a partir de 05 de Junho, para a versão 8.0.7 será  1.0.1h de 05 de Junho de 2014, por exemplo. Lembrando que também é fundamental aplicar a correção para a biblioteca OpenSSL utilizado pelo SO.

Referências:

http://www.zimbra.com/forums/announcements/73677-20140606-zimbra-security-advisory-cve-2014-0224-ccs-injection-vulnerability.html

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224

 

Zimbra: Aplicando patch para a falha Heartbleed

Neste post irei tratar de uma atualização de segurança para o Zimbra 8, especificamente para o bug na biblioteca do OpenSSL versão 1.0.1, conhecido como Heartbleed (http://pt.wikipedia.org/wiki/Heartbleed).

Muitos administradores atualizam somente a versão do OpenSSL no SO, porém o Zimbra a biblioteca instalada em seu diretório. As seguintes versões são afetadas:

8.0.3

8.0.4

8.0.5

8.0.6

8.0.7 (builds até 6020)

Se você instalou o Zimbra 8.0.7 build 6021 o patch já está aplicado, para consultar se sua versão está vulnerável execute o comando abaixo como usuário zimbra:

$ strings /opt/zimbra/openssl/lib/libssl.so | grep dtls1_heartbeat

Se retornar a entrada dtls1_heartbeat então você deve aplicar o patch.

Para aplicar o patch, siga os passos abaixo como usuário root:

– Efetue o download do patch :
# wget http://files.zimbra.com/downloads/security/zmopenssl-updater.sh

– Conceda permissão para execução:

# chmod a+rx zmopenssl-updater.sh

– Execute o Patch:

# ./zmopenssl-updater.sh

O resultado deve ser parecido com estas entradas:

[Generates the following output]
Downloading patched openssl
Validating patched openssl: success
Backing up old openssl: complete
Installing patched openssl: complete
OpenSSL patch process complete.
Please restart Zimbra Collaboration Suite as the Zimbra user via zmcontrol restart

Agora como usuário Zimbra, reinicie o serviço:

$ zmcontrol restart

 

Seguindo esses passos, a biblioteca do OpenSSL irá estar atualizada com correção para a falha de segurança Heartbleed, porém não esqueça de atualizar a biblioteca do SO também.

 

Referências:

http://www.zimbra.com/forums/announcements/70921-critical-security-advisory-patch-openssl-heartbleed-vulnerability.html

https://www.zimbra.com/forums/announcements/71042-zcs-8-0-7-has-been-rebuilt-include-fix-openssl-heartbleed-vulnerability.html

 

Correção de vulnerabilidade para o Cyrus Imap

Quem utiliza versões do Cyrus Imap inferiores a 2.4.11 deve urgentemente atualizar a mesma ou aplicar o patch abaixo para correção de uma vulnerabilidade que pode ocasionar uma negação de serviço (DoS) no Cyrus:

http://git.cyrusimap.org/cyrus-imapd/commit/?id=6e776956a1a9dfa58eacdd0ddd52644009eac9e5

Segue  relato da vulnerabilidade conforme o site da CVE:

he index_get_ids function in index.c in imapd in Cyrus IMAP Server before 2.4.11, when server-side threading is enabled, allows remote attackers to cause a denial of service (NULL pointer dereference and daemon crash) via a crafted References header in an e-mail message.

Referência: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3481