RHEL 6.3 升级 OpenSSH 和 Apache

Question

我们刚刚针对 PCI 合规性从 403Labs 对我们的一台服务器 (RHEL 6.3 x86_64) 运行了外部安全扫描，结果似乎主要表明我们有一堆需要升级才能通过扫描的应用程序。

话虽如此，我遇到的问题是包管理器 (yum) 和 remi repo 的使用没有我需要的 Apache 和 OpenSSH 版本。我已经执行了以下操作：

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

这解决了我们的关键和高风险结果，但中等结果仍然表明我们需要进一步升级以下软件包。

我们需要的升级是：

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

因此，由于包管理器无法让我升级到这些版本，我该怎么做呢？我目前的前提是我需要从源代码安装。如果有更好的选择，请指出。

另外，如果我别无选择，只能从源代码安装，有人可以帮我确定正确的源包是什么，以便我知道我正在为我的操作系统安装正确的版本吗？

非常感谢您的帮助。

Answer 1

推回...

红帽企业 Linux 不是这样工作的。从源代码安装以满足审计要求会使您面临额外的安全问题和更多的管理开销。

红帽为其企业操作系统采用的方法是在操作系统的整个支持生命周期中创建一致的目标。较大的公司和企业应用程序需要在支持这些操作系统的 7 年以上保证二进制兼容性。Red Hat 不会更改软件包的次要版本号，而是会将更改和安全补丁从较新版本向后移植到旧软件包中。

例如，您永远不会在 RHEL 5 中看到 Apache 2.2.23，但您会看到从较新版本的 Apache 移植到 2.2.3 中的相关安全补丁（和某些功能）。

当我与审计员或关注安全的人打交道时，我坚持让他们通读包更改日志，看看他们的具体问题是否包含在现有的安全修复或错误修复中......

这是EL Apache 变更日志。

对照CERT/国家漏洞数据库交叉引用CVE-*编号。例如，CVE-2011-3368列出了一个影响 Apache 2.2.21 之前版本的漏洞。显然，RHEL 只有 2.2.3 作为主要版本，因此安全修复程序被开发、测试并移植到旧版本。

Answer 2

不要那样做！

在您走出操作系统供应商的支持结构之前，您应该确认这是正确的做法。

一些 PCI 合规性测试会报告应用程序存在漏洞，因为它报告的版本号太低。这并没有考虑到许多供应商采用的安全性和错误修复的向后移植。

例如（来自旧的 Nessus 扫描）它声明 CentOS 提供的 Apache 如果版本低于 2.2.14 则易受攻击。如果您深入了解漏洞的详细信息，就会发现CVE-2009-3095、CVE-2009-3094等。

查找它们，您会发现它们已在当前版本的 Apache 供应（购买 RH 和 CentOS）中得到修复。

Answer 3

我在 PCI 合规性实施中也遇到了这个问题，尽管我知道上面提到的补丁的向后移植。我们使用 apache 的解决方案是在 /etc/httpd/conf/httpd.conf 中将 ServerTokens 设置为“Prod”，将 ServerSignature 设置为“Off”。这个明智的设置告诉 apache 不要报告它的版本号并吐出它正在使用的所有模块。然后我们通过了扫描。

至于 SSH，理想的设置是防火墙关闭访问，以便只有您的办公室可以连接到端口。这样扫描就不会捡起来。

如果这是不可能的，PCI 审计员可以确信你是安全的，如果你证明你已经修补了（通常通过一些屏幕共享实用程序显示“yum update”显示没有可用更新）并且有一个程序进行定期测试. 我只是表明我订阅了 RedHat 的安全邮件列表，如果我们使用的组件易受攻击，我们会立即安排更新。

除此之外，您应该能够上诉并获得适当的渗透测试。