我们刚刚对我们的一台服务器（RHEL 6.3 x86_64）进行了 403Labs 的外部安全扫描，以确认其符合 PCI 规范，结果似乎主要表明我们有大量应用程序需要升级才能通过扫描。
话虽如此，我遇到的问题是包管理器 (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
那么，既然包管理器无法让我升级到这些版本，我该怎么做呢？我目前的前提是需要从源代码安装。如果有更好的选择，请指出。
另外，如果我别无选择，只能从源代码安装，有人可以帮我识别正确的源包是什么，以便我知道我正在为我的操作系统安装正确的版本吗？
非常感谢您的帮助。
答案1
不要这么做！
在走出操作系统供应商的支持结构之前，您应该验证这是否是正确的做法。
一些 PCI 合规性测试会报告应用程序存在漏洞，因为报告的版本号太低。这没有考虑到向后移植许多供应商都采用了这种安全性和错误修复方法。
例如（从旧的 Nessus 扫描中）它声明如果版本低于 2.2.14，CentOS 提供的 Apache 就存在漏洞。如果你深入了解漏洞的细节，你会发现CVE-2009-3095，CVE-2009-3094ETC。
通过查找它们，你会发现它们已经在 Apache 的当前版本中得到了修复，由 RH 和 CentOS 提供。
答案2
推回...
Red Hat Enterprise Linux 并非如此。从源代码安装以满足审计要求会给您带来更多安全问题和更多管理开销。
Red Hat 针对其企业操作系统采取的方法是在整个操作系统的支持生命周期内创建一致的目标。大型企业和企业应用程序需要保证这些操作系统在 7 年以上的支持期内的二进制兼容性。Red Hat 不会更改软件包的次要版本号，而是将较新版本的更改和安全补丁反向移植到较旧的软件包中。
例如，您永远不会在 RHEL 5 中看到 Apache 2.2.23，但您会看到从较新版本的 Apache 移植到 2.2.3 中的相关安全补丁（和一些功能）。
当我与审计员或关注安全的人员打交道时，我坚持让他们通读软件包更新日志，以了解他们所关注的具体问题是否包含在现有的安全修复或错误修复中……
交叉引用CVE-*数字反对CERT/国家漏洞数据库。 例如，CVE-2011-3368列出了影响 Apache 2.2.21 之前版本的漏洞。显然，RHEL 只有 2.2.3 作为主要版本，因此安全修复程序已开发、测试并移植到旧版本。
答案3
尽管我知道上面提到的补丁的反向移植，但我在实施 PCI 合规性时也遇到了这个问题。我们对 apache 的解决方案是在 /etc/httpd/conf/httpd.conf 中将 ServerTokens 设置为“Prod”，将 ServerSignature 设置为“Off”。这个明智的设置告诉 apache 不要报告其版本号并吐出它正在使用的所有模块。然后我们通过了扫描。
至于 SSH，理想的设置是关闭防火墙，以便只有您的办公室可以连接到该端口。这样扫描就不会发现它。
如果这不可能，那么如果您能证明自己已经打了补丁（通常通过一些屏幕共享实用程序显示“yum update”显示没有可用更新），并制定了定期测试程序，那么 PCI 审计员就可以确信您是安全的。我刚刚表明我订阅了 RedHat 的安全邮件列表，并且如果我们使用的组件存在漏洞，我们会立即安排更新。
除此之外，您应该能够上诉并得到适当的渗透测试。