Falha na verificação de conformidade do Trustwave PCI para o CentOS 5.5 totalmente corrigido

Question

Eu tenho um servidor CentOS 5.5 totalmente atualizado que está falhando na verificação de conformidade PCI da Trustwave. Os itens que estão reclamando são openssl < 0.9.8.o.

rpm -q openssl mostra: openssl-0.9.8e-12.el5_5.7

A faixa do cabeçalho do apache mostra: Servidor: Apache / 1.3.41 (Unix) PHP / 5.2.14 mod_psoft_traffic / 0.2 mod_ssl / 2.8.31 OpenSSL / 0.9.8b mod_macro / 1.1.2

(nota: o banner do apache nem sequer mostra a versão instalada)

openssh e php têm uma situação semelhante (a versão reportada é menor que a mínima para conformidade com PCI).

Preciso criar todas essas bibliotecas a partir do código-fonte para obtê-las na versão mais recente? Ou existe uma maneira de dizer ao CentOS yum para instalar a nova versão em vez de sua versão com patches posteriores? Eu prefiro não ir fora do yum, se possível, para que a manutenção futura seja simplificada

    

Answer 1

Todas as varreduras PCI fazem uma verificação de versão com base nos cabeçalhos e, em seguida, eles reclamam dos trinta e poucos problemas que você tem. O que eles não levam em conta é que as correções de segurança são portadas para os pacotes do RHEL. Contanto que você esteja executando os pacotes mais recentes, você deve estar bem. O que você precisa fazer após uma falha na digitalização é abrir um ticket para contestar os resultados. Então você tem que mostrar qual versão está realmente instalada

rpm -q httpd

Então você tem que cavar através do changlog do rpm para encontrar cada instância CVE que eles mencionaram.

rpm -q --changelog httpd

Onde você encontra coisas como esta:

 * Thu Dec 03 2009 Joe Orton <[email protected]> - 2.2.14-1
 - add partial security fix for CVE-2009-3555 (#533125)

Finalmente, você deve se conectar ao link relevante no site da Redhat para mostrar que ele foi endereçado, já que ninguém no lado da varredura PCI vai realmente olhar para um RPM.

link

Você provavelmente vai e volta algumas vezes e, finalmente, você receberá um atestado de saúde se você estiver realmente atualizado. Assim que terminar, certifique-se de colocar todos os documentos de suporte em seu wiki, pois a varredura PCI será redefinida a cada trimestre e removerá qualquer menção às informações fornecidas e você precisará fazer isso novamente.

    

Answer 2

As correções de porta traseira parecem ser a rota preferida para muitas distribuições. Não é uma solução, mas você deve suprimir a identidade do servidor definindo "ServerTokens Prod" e "ServerSignature Off" em seu httpd.conf.

Pode ser controverso para mim dizer isso, mas eu não acho que o scraping do banner conte para uma varredura de vulnerabilidade, pois isso geralmente resulta em muitos falsos positivos. Eu acho que o scanner deve estar realmente tentando ver se as vulnerabilidades conhecidas de uma versão particular de uma biblioteca realmente existem e não fazer suposições simples. Em alguns casos, eles realmente fazem algum esforço para ver se existe uma vulnerabilidade. Um exemplo seria a parte de protocolo e cifra ssl das varreduras.

Naturalmente, o problema que se apresenta ao suprimir a identidade do servidor é que muitas vulnerabilidades relatadas anteriormente não são mais relatadas e o administrador corre o risco de se tornar negligente nas tarefas de atualização. É um paradoxo, no entanto, porque outros tipos de varreduras de vulnerabilidades reclamam dos problemas de Divulgação de Informações quando não estão definindo o ServerTokens como Prod.

Você deve compilar tudo a partir do código-fonte, essencialmente criando sua própria distribuição apache personalizada, mas com a frequência das atualizações, você estará compilando novas construções com frequência e nem todo mundo tem tempo para fazer isso.

    

Answer 3

Esta não é uma resposta para a sua pergunta, mas eu suspeito que o apache está relatando a versão do openssl que foi compilada, não a versão que realmente usa. No Fedora, é mais claro:

[Fri May 13 03:45:05 2011] [info] mod_ssl/2.2.17 compiled against Server: Apache/2.2.17, Library: OpenSSL/1.0.0a-fips
[Fri May 13 03:45:05 2011] [notice] Apache/2.2.17 (Unix) DAV/2 PHP/5.3.6 mod_ssl/2.2.17 OpenSSL/1.0.0d-fips configured -- resuming normal operations

$ rpm -q openssl.x86_64
openssl-1.0.0d-1.fc14.x86_64