RHEL 6.3 Atualizando o OpenSSH e o Apache

Question

Acabamos de executar uma verificação de segurança externa do 403Labs em um de nossos servidores (RHEL 6.3 x86_64) para conformidade com PCI e os resultados parecem indicar que temos uma mão cheia de aplicativos que precisavam ser atualizados para passar a varredura.

Dito isto, o problema que estou encontrando é que o gerenciador de pacotes (yum) e o uso do remi repo não possuem as versões necessárias para o Apache e o OpenSSH. Eu já fiz o seguinte:

yum update
yum --enablerepo=remi,remi-test install httpd mysql mysql-server php php-common

Isso resolveu nossos resultados críticos e de alto risco, mas os resultados de nível médio ainda afirmam que precisamos atualizar ainda mais os seguintes pacotes.

As atualizações de que precisamos são:

   Current            Required
Apache 2.2.15 to >= Apache 2.2.23
OpenSSH 5.3   to >= 5.7

Então, como o gerenciador de pacotes não é capaz de me atualizar para essas versões, como devo fazer isso? Atualmente estou sob a premissa de que precisarei instalar a partir da fonte. Se houver uma alternativa melhor, indique isso.

Além disso, se eu não tiver outra opção a não ser instalar a partir do código-fonte, alguém pode me ajudar a identificar quais os pacotes de origem adequados para que eu saiba que estou instalando as versões corretas para o meu sistema operacional?

Muito obrigado por qualquer ajuda.

    

Answer 1

Não faça isso!

Antes de sair da estrutura de suporte do fornecedor do sistema operacional, verifique se essa é a coisa certa a fazer.

Alguns testes de conformidade com PCI relatam que um aplicativo tem vulnerabilidades porque o número da versão relatada é muito baixo. Isso não leva em conta backporting de segurança e correções de bugs que muitos fornecedores empregam.

Por exemplo (de uma verificação antiga do Nessus), declara que o Apache fornecido pelo CentOS é vulnerável se a versão for < 2.2.14. Se você pesquisar os detalhes sobre quais são as vulnerabilidades, descobrirá CVE-2009- 3095 , CVE-2009-3094 etc.

Pesquisando você descobre que eles foram corrigidos nas versões atuais dos suprimentos do Apache e, portanto, o CentOS.

    

Answer 2

Retroceda ...

O Red Hat Enterprise Linux não funciona dessa maneira. A instalação a partir do código-fonte para atender aos requisitos de auditoria abre para problemas de segurança adicionais e mais sobrecarga de gerenciamento.

A abordagem que a Red Hat adota para seus sistemas operacionais corporativos é criar um alvo consistente durante todo o ciclo de vida de suporte do sistema operacional. Corporações maiores e aplicativos corporativos precisam garantir a compatibilidade binária ao longo de mais de 7 anos para os quais esses sistemas operacionais são suportados. A Red Hat não alterará os números de versões menores de um pacote, mas em vez disso fará backport de alterações e patches de segurança de versões mais recentes para o pacote mais antigo.

Por exemplo, você nunca verá o Apache 2.2.23 no RHEL 5, mas verá as correções de segurança relevantes (e algumas funcionalidades) portadas de versões mais recentes do Apache para o 2.2.3.

Quando lidei com auditores ou pessoas com foco em segurança, insisto que eles leiam o changelog do pacote para ver se sua preocupação específica é coberta por correções de segurança ou correções de bugs existentes ...

Aqui está o Log de alterações do EL Apache .

Faça referência cruzada dos números CVE - * ao CERT / National Vulnerability Database . Por exemplo, CVE-2011-3368 lista uma vulnerabilidade que afeta as versões do Apache anteriores à 2.2.21. Obviamente, o RHEL tem apenas 2.2.3 como uma versão principal, então a correção de segurança foi desenvolvida, testada e portada para a versão antiga.

    

Answer 3

Eu me deparei com isso também com minha implementação de conformidade com PCI, embora eu soubesse sobre o back-porting dos patches mencionados acima. Nossa solução com o apache foi configurar o ServerTokens como 'Prod' e o ServerSignature como 'Off' no /etc/httpd/conf/httpd.conf. Essa configuração sábia diz ao apache para não informar seus números de versão e cuspir todos os módulos que está usando. Em seguida, passamos a varredura.

Quanto ao SSH, a configuração ideal é desativar o acesso ao firewall para que apenas o seu escritório possa se conectar à porta. Desta forma, o exame não vai buscá-lo.

Se isso não for possível, os auditores PCI podem estar convencidos de que você está seguro se provar que está corrigido (geralmente, através de algum utilitário de compartilhamento de tela você mostra que uma 'atualização yum' não exibe atualizações) e tem um procedimento em vigor para testes regulares. Acabei de mostrar que estava inscrito na lista de discussão de segurança da RedHat e que agendamos imediatamente uma atualização se um componente que estamos usando for vulnerável.

Exceto tudo isso, você deve ser capaz de apelar e fazer um teste de penetração adequado.