Certificado assinado: Utilizando certificado EV SSL Site Seguro Pro

Olá ! Nesse post gostaria de compartilhar os procedimentos necessários para utilização de um certificado EV SSL Site Seguro Pro adquirido pela Certsign, especialmente em servidores WEB (Apache/Nginx) e soluções de groupware como Zimbra.

Assim que for efetuado o download do certificado, as orientações da Certsign são para efetuar o download das cadeias de certificados do produto EV SSL Site Seguro Pro, mas é justamente aí que está o problema. Ao analisar o arquivo, pode-se observar que o “caminho de certificação” é esse:

cert2

Portanto, para utilização deste certificado, será necessário efetuar o Bundle das cadeias de certificado Verisign e Symantec Class 3 EV SSL CA – G3. Ao clicar em qualquer item do caminho de certificação, no botão “detalhes“, é possível obter mais informações sobre a cadeia que necessita ser utilizada:

cert3

Seguem os links para Download da cadeia de certificados necessária para utilização deste certificado:

http://www.symantec.com/content/en/us/enterprise/verisign/roots/VeriSign-Class%203-Public-Primary-Certification-Authority-G5.pem

https://knowledge.symantec.com/library/VERISIGN/ALL_OTHER/KB_IMAGES/SO26896/Cert_Files/SHA2/Symantec%20Class%203%20EV%20SSL%20CA%20-%20G3.cer

Uma vez que for efetuado o download dos dois arquivos, o bundle é feito unindo ambos, como o comando ‘cat’, por exemplo, no Linux. No caso do procedimento ser efetuado no Windows, o comando ‘copy’ pode ser utilizado.

Anúncios

Zimbra 8.x: Patch para vulnerabilidades XSS

zimbra-no-lettermark - Copydownload

Olá ! Recentemente, a Fortinet’s FortiGuard Lab divulgou duas vulnerabilidades de segurança (cross-site scripting) no Zimbra, portanto é imprescindível que quem está utilizando as versões 8.0, 8.5 e 8.6 aplique as correções para estas vulnerabilidades.

Captura de tela de 2016-02-23 17:25:02

Quem possui a versão 8.6 implementada, o procedimento é instalar o Patch 6, que está disponível na página de Downloads da Zimbra.

Quem possui a versão 8.0 ou 8.5 implementada, o procedimento é instalar o Patch enviado por Frederic Maussion (reconhecido pela Zimbra) no github: https://github.com/wolfyzvf/Zimbra-Collaboration-CWE-79

 

Esse tópico é abordado no treinamento oficial Zimbra System administration: http://www.bktech.com.br/treinazimbra

Linux e Logs: A necessidade de auditar – Parte 2

O que, quando e onde logar.

A quantidade de logs nas redes e sistemas computacionais cresce exponencialmente, o que cria uma desafio sobre quais tipos de eventos registrar, além de onde armazena-los. O gerenciamento dos logs se faz necessário para assegurar que as informações registradas estejam armazenadas de forma segura e pelo período apropriado.

Além da complexidade do alto volume de logs que serão gerados pelos sistemas computacionais, existe a preocupação quanto ao armazenamento e segurança destes registros, para assegurar a eficácia do gerenciamento de logs a organização deve estabelecer políticas e procedimento para armazenamento, controle de acesso e rotatividade desses registros (tópicos que serão abordados nos capítulos seguintes). Ao definir as políticas para gerenciamento de logs a organização precisa ter o entendimento que cada sistema computacional gera esses registros de forma diferente, apesar de existirem padrões, convenções e RFCs estabelecidos.

Um ótimo de exemplo de armazenamento de logs é caixa preta presente nas aeronaves, onde podemos estabelecer uma analogia para definir o que deve ser registrado nos sistemas computacionais. A implementação desse sistema aprimorou de forma significante a identificação de falhas (sejam elas em processos, técnicas ou humanas) tornando o negócio (aviação) mais seguro. A caixa preta também armazena os logs em local apropriado, permitindo que em caso de falhas ou desastres se consiga recuperar as informações necessárias para auditorias ou investigações.

Feita essa analogia com a caixa preta, podemos assumir regras básicas para o armazenamento de logs em sistemas computacionais:

  • É preciso estabelecer quais registros devem ser gerenciados e definir o período e locais apropriados para armazenamento.
    O armazenamento de logs deve estar ligado aos interesses da organização e de acordo com o “Plano de continuidade de negócios”.

Algumas das principais atribuições dos profissionais responsáveis pelo gerenciamento de logs:

  • Monitorar os logs e “saúde” dos mesmos.
    Monitorar a rotatividade e armazenamento e e encriptação dos registros (se aplicável).
    Checar, testar e aplicar atualizações e correções para os software de log.
    Certificar que os relógios de todos os sistemas computacionais estejam alinhados.
    Reconfigurar os logs de acordo com mudanças nas políticas, tecnologias ou outros fatores.
    Documentar e reportar anomalias nas configurações de logs e processos.

Níveis de logging.

Tendo conhecimento que os logs nas redes e sistemas computacionais crescem de forma exponencial, é necessário entender a “classificação” destes registros para estabelecer políticas do que deve ser registrado e posteriormente armazenado.

Os níveis de log do Linux e outros sistemas operacionais estão padronizados e são classificados através da gravidade dos registros, que são identificados com uma numeração e abreviação comum do inglês, conforme tabela abaixo:

NUMERAÇÃO

NÍVEL

ABREVIAÇÃO

0

EMERGÊNCIA

EMERG

1

ALERTA

ALERT

2

CRÍTICO

CRIT

3

ERRO

ERR

4

AVISO

WARN

5

NOTIFICAÇÃO

NOTICE

6

INFORMAÇÃO

INFO

7

DEBUG

DEBUG

O nível debug, com identificador 7, registra todas as informações geradas pelo sistema, sendo útil para análise de problemas ou testes de serviços e aplicações.
Log em texto e log em memória

A memoria interna do sistema operacional gerencia e manipula processos sendo executados, arquivo abertos, portas e conexões abertas, e tudo isso e perdido ao desligarmos o computador.

Sabendo disso, precisamos entender o que são dados voláteis e não voláteis, para entendermos o que pode ser perdido ou recuperado durante o processo de desligamento do computador.

Dados voláteis

Os dados voláteis são informações que ficam armazenados na memoria principal do computador. Isso quer dizer que elas possuem um ciclo de vida curto, se comparadas com informações armazenadas na memoria auxiliar de um sistema.

Dados não voláteis

Os dados não voláteis são dados que podem permanecer na maquina durante longos períodos de tempo e podem ser recuperados mesmo apos a mesma ser desligada. Nada mais são do que conteúdo de arquivos, logs em texto e MACtimes.
O pecado pelo excesso

Segundo Claude Shannon, autor do livro “A teoria matemática da comunicação”, informação é tudo aquilo que reduz a incerteza. Esse conceito se aplica perfeitamente na decisão do que devemos registrar a armazenar, para que através da coleta destes dados os mesmos sejam transformados em informação útil e aplicável, aulixiando na tomada de decisões.

Na prática, é necessário estabelecer o nível de log necessário para cada sistema para o que os registros não conduzam a uma “enxurrada de informação”, para que a atividade de análise e auditoria de logs não se torne uma árdua tarefa de interpretação, aumente a incerteza, não facilite a tomada de decisões ou gere conclusões erroneamente fundamentadas que levam a decisões equivocadas.

Linux e Logs: A necessidade de auditar – Parte 1

Por que auditar?

Auditar se faz necessário para certificar que as atividades dos usuários e administradores, falhas, exceções e eventos de segurança da informação estejam em conformidade com as regras de negócio e políticas (incluindo segurança da informação) estabelecidas pela empresa, além de certificar a eficácia das normas estabelecidas.

A análise de logs muitas vezes é tratada como uma tarefa de baixa prioridade pelas organizações e administradores de redes e sistemas, em muitos casos, os administradores sequer possuem recursos e treinamento para análises proativas, ou não os utilizam, por considerarem essa atividade “entediante” e menos importante que a resolução de problemas operacionais. A análise de logs acaba sendo uma atividade simplesmente reativa e improdutiva, onde se espera por uma falha ou desastre (as vezes levando a parada do total de um negócio) para solucionar um problema que em muitos casos estava sendo anunciado e “embaixo dos nossos olhos”.

O que é um log

Seguindo a definição da Wikipedia (http://pt.wikipedia.org/wiki/Log_de_dados):

log de dados é uma expressão utilizada para descrever o processo de registro de eventos relevantes em um sistema computacional. Esse registro pode ser utilizado para restabelecer o estado original de um sistema ou para que um administrador conheça o seu comportamento no passado. Um arquivo de log pode ser utilizado para auditoria e diagnóstico de problemas em sistemas computacionais.

Portanto, através do armazenamento dos “logs”, os eventos que ocorrem nas redes e sistemas de uma organização, sendo que cada entrada contém informações sobre um evento específico, são registrados e mantidos por um período de tempo acordado para auxiliar em futuras auditorias (isso inclui também possíveis investigações), recuperação de falhas na rede ou em sistemas, e certificar o cumprimento das normas estabelecidas pelos usuários e administradores do ambiente.

Os logs asseguram, após a ocorrência de um desastre, falha ou violação de acesso, a estabelecer a situação normal de funcionamento dos sistemas, portanto, o registro de eventos em sistemas computacionais está ligado diretamente ao “Plano de continuidade de negócios”.

Conforme o “Código de prática para gestão de segurança da informação – ABNT NBR ISO/IEC 27002:2005”, é estabelecido no Item 10.10 e subitens, que os sistemas sejam monitorados e eventos de segurança da informação sejam registrados, tendo como principais objetivos:

  • Detectar atividades não autorizadas de processamento da informação;
  • Checar a eficácia dos controles adotados e para verificar a conformidade com o modelo de política de acesso;
  • Auxiliar as organizações a estarem de acordo com todos os requisitos legais relevantes aplicáveis para suas atividades.

Spamassassin: Portas para o mecanismo Razor

zimbra-no-lettermark - Copy download (2)

Olá ! Na última turma que ministrei do curso EAD de Zimbra nos deparamos com um problema ao habilitar o mecanismo Razor através de um Firewall, o mesmo não consegui se conectar no pool de servidores deste mecanismo.

Após pesquisas (gostaria de agradecer ao aluno Rickifer pelo empenho na pesquisa) foi constatado que as seguintes portas (Output) devem ser liberadas para o funcionamento deste mecanismo:

2703/tcp e 7/tcp

O mecanismo não necessita de nenhuma porta para conectar no seu servidor.

Referências:

http://wiki.apache.org/spamassassin/NetTestFirewallIssues

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