☰

Trustwave PCI Complaince 扫描对已完全修补的 CentOS 5.5 失败

tag-icon • tag-icon centos ssh openssl pci-dss
Trustwave PCI Complaince 扫描对已完全修补的 CentOS 5.5 失败

我有一台已完全修补的 CentOS 5.5 服务器，但未能通过 Trustwave PCI 合规性扫描。它抱怨的项目是 openssl < 0.9.8.o。rpm
-q openssl 显示：openssl-0.9.8e-12.el5_5.7

apache 标题横幅显示：服务器：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

（注意：Apache 横幅甚至没有显示已安装的版本）

openssh 和 php 有类似的情况（报告的版本低于 PCI 合规性的最低要求）。

我是否需要从源代码构建所有这些库才能获得最新版本？或者有没有办法告诉 CentOS yum 安装新版本而不是其反向移植的修补版本？如果可能的话，我宁愿不去 yum 之外的地方，这样将来的维护就会简化

答案1

所有 PCI 扫描都会根据标头进行版本检查，然后它们会抱怨您遇到的三十多个问题。它们没有考虑到安全修复程序已反向移植到 RHEL 软件包。只要您运行的是最新的软件包，就应该没问题。扫描失败后，您需要做的是打开一张票来对结果提出异议。然后您必须显示实际安装的版本

rpm -q httpd

然后您必须深入研究 rpm changelog 来查找他们提到的每个 CVE 实例。

rpm -q --changelog httpd

在哪里你可以找到这样的东西：

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

最后，您应该链接到 Redhat 网站上的相关链接以表明该问题已得到解决，因为 PCI 扫描方面实际上没有人会查看 RPM。

https://www.redhat.com/security/data/cve/CVE-2009-3555.html

您可能需要来回检查几次，最后如果您确实进行了更新，您将获得一份健康证明。完成后，请确保将所有支持文档放在您的 wiki 上，因为 PCI 扫描将每季度左右重置一次并删除您提供的任何信息，您需要再次执行此操作。

答案2

反向移植修复似乎是许多发行版的首选方法。这不是解决方案，但您应该通过在 httpd.conf 中设置“ServerTokens Prod”和“ServerSignature Off”来抑制服务器身份。

我这样说可能会引起争议，但我认为抓取横幅不算作漏洞扫描，因为它经常会导致很多误报。我认为扫描器实际上应该尝试查看特定版本的库的已知漏洞是否确实存在，而不是做出简单的假设。在某些情况下，他们确实会努力查看是否存在漏洞。一个例子是扫描的 SSL 密码和协议部分。

当然，在抑制服务器身份时遇到的问题是，许多以前报告的漏洞不再被报告，管理员面临着修补工作松懈的风险。然而，这有点自相矛盾，因为当未将 ServerTokens 设置为 Prod 时，其他类型的漏洞扫描会抱怨信息泄露问题。

您应该从源代码编译所有内容，本质上创建您自己的自定义 Apache 发行版，但随着更新频率，您将频繁编译新版本，并不是每个人都有时间这样做。

答案3

这不是对你问题的回答，但我怀疑 apache 报告的是编译时所针对的 openssl 版本，而不是它实际使用的版本。在 Fedora 上更清楚：

[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

相关内容