Compatibilidade com PCI Versões do Apache [duplicadas]

Question

Estamos trabalhando com a versão atual do Apache 2.4. 6 disponíveis em reposições do Centos 7. Instalado com o yum.

e estamos lidando com a conformidade com o PCI e o relatório diz:

IP Address: x
Host: x
Path: 

THREAT REFERENCE

Summary: 
vulnerable Apache version: 2.4.6

Risk: High (3)
Port: 443/tcp
Protocol: tcp
Threat ID: web_server_apache_version

Details: Apache HTTP Server mod_proxy_fcgi Response Handling Vulnerability
11/21/14
CVE 2014-3583
Apache HTTP Server before 2.4.11 is prone to a vulnerability,
which can be exploited to cause a DoS (Denial of Service).
The vulnerability exists due to an overflow condition in mod_proxy_fcgi.
when handling responses from FastCGI servers. The vulnerability can be exploited by
sending a crafted response from a malicious FastCGI server, which could lead to a 
crash when reading past the end of a heap memory. 
Apache HTTP Server NULL Pointer Dereference Vulnerability
10/08/14
CVE 2014-3581
Apache HTTP Server 2.4.10 and earlier is prone to a vulnerability,
which can be exploited to cause a DoS (Denial of Service).
The vulnerability exists because the application contains flaw in
the cache_merge_headers_out() function which is 
triggered when handling an empty 'Content-Type' header value. 
Multiple Vulnerabilities Fixed in Apache HTTP Server 2.4.10
07/24/14
CVE 2014-0117
CVE 2014-0118
CVE 2014-0226
CVE 2014-0231
CVE 2014-3523
Apache HTTP Server before 2.4.10 is prone to multiple vulnerabilities,
which can be exploited to cause a DoS (Denial of Service).
The vulnerabilities exist because the application contains flaw in 
mod_proxy, mod_deflate, mod_status, and mod_cgid modules and
in the winnt_accept function of WinNT MPM. 
Note: the WinNT MPM denial of service vulnerability can only
be exploited when the default AcceptFilter is used.
Apache HTTP Server Two Denial of Service Vulnerabilities
03/19/14
CVE 2013-6438
CVE 2014-0098
Apache HTTP Server before 2.4.9 is prone to two vulnerabilities,
which can be exploited to cause a DoS (Denial of Service).
The first vulnerability exists due to an error in the mod_log_config module when logging 
with truncated cookies. The second vulnerability is due to a boundary error in the mod_dav 
module when removing leading spaces.
HTTP-Basic Authentication Bypass Vulnerability
08/14/09
Apache 2.2.2 and prior are prone to an authentication-bypass vulnerability 
because it fails to properly enforce access restrictions on certain requests to a site that requires authentication.
An attacker can exploit this issue to gain access to protected resources, 
which may allow the attacker to obtain sensitive information or launch further attacks.
Apache HTTP Server OS Fingerprinting Unspecified Security Vulnerability
11/03/08
Apache 2.2.9 and prior is prone an unspecified security vulnerability.

Information From Target:
Service: https
Received: Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.6.13

Atualizamos o servidor uma vez por semana "yum update"

mas quando eu faço: rpm -q --changelog httpd | grep CVE eu posso ver isso:

• core: corrija o defeito de análise do cabeçalho do fragmento (CVE-2015-3183) e gancho ap_force_authn (CVE-2015-3185)
• core: conserta o bypass das regras dos mod_headers por meio de solicitações em partes (CVE-2013-5704)
• mod_cache: correção de referência do ponteiro NULL no Content-Type vazio (CVE-2014-3581)
• mod_cgid: adicione a correção de segurança para CVE-2014-0231 (# 1120608)
• mod_proxy: adicione a correção de segurança para CVE-2014-0117 (# 1120608)
• mod_deflate: adicione a correção de segurança para CVE-2014-0118 (# 1120608)
• mod_status: adicione a correção de segurança para CVE-2014-0226 (# 1120608)
• mod_cache: adicione correção de segurança para CVE-2013-4352 (# 1120608)
• mod_dav: adicione a correção de segurança para CVE-2013-6438 (# 1077907)
• mod_log_config: adicione a correção de segurança para CVE-2014-0098 (# 1077907)

Como posso aplicar os patches solicitados pela verificação de segurança? Não consigo encontrar rpms para fazer isso.

obrigado antecipadamente.

Atenciosamente.

    

Answer 1

Este é um dos problemas (ou benefícios dependendo de como você o vê!) de usar gerenciadores de pacotes.

De um lado, elas são versões mais antigas de aplicativos, portanto, estão vulneráveis (além de não terem os recursos mais recentes), mas, por outro lado, são estáveis. No entanto, muitos fornecedores (incluindo a Red Hat e o CENTOS, que são baseados nisso) geralmente retornam as correções necessárias para essas versões, mas isso pode não ser óbvio para a varredura de vulnerabilidades.

Pode-se argumentar que um relatório como o seu é um pouco preguiçoso, pois supõe que você não aplicou patches exclusivamente com base no número da versão, quando poderia ser visto facilmente (ou perguntado se) você usa um gerenciador de pacotes e ser testado para ver se aplicou os patches. Então, novamente, depende de como a varredura foi feita e como eles determinaram as versões em que você estava. Se eles tivessem acesso aos seus servidores, eu diria que eles poderiam ter confirmado isso. Se eles fizeram isso de alguma outra maneira, como baseado nos seus Cabeçalhos HTTP, você retornou, então eu diria que eles não podem verificar se você corrigiu, então eles estão certos em criar (e por outro lado você provavelmente não deveria retornar números de versão específicos) nos seus cabeçalhos HTTP, se você for!).

Finalmente, você deve perceber que este relatório é muitas vezes uma lista de possíveis problemas e você está totalmente dentro do seu direito de voltar com evidências de como você acredita que esses problemas foram abordados ou mitigados - como o evidência que você deu em sua pergunta e o fato de você ter um cronograma regular de correções ... Etc. Ainda existe um risco aqui (por exemplo, por quaisquer riscos que surjam entre patches e / ou se você esquecer de corrigir por um longo tempo) e qualquer relatório tem razão em ressaltar esse risco, mas eles normalmente reduzem os erros a alertas em um relatório para destacar isso como um risco reduzido.