☰

如何修复 Apache（httpd）中的“logjam”漏洞

tag-icon • tag-icon apache-2.2 ssl apache-2.4 httpd vulnerability
如何修复 Apache（httpd）中的“logjam”漏洞

最近，Diffie-Hellman 中出现了一个新漏洞，非正式地称为“logjam”，该漏洞这一页已经提出了如何应对这一漏洞的建议：

我们对正确部署 Diffie-Hellman TLS 有三条建议：

  1. 禁用导出密码套件。尽管现代浏览器不再支持导出套件，但 FREAK 和 Logjam 攻击允许中间人攻击者诱骗浏览器使用导出级加密，之后 TLS 连接即可解密。导出密码是 1990 年代政策的遗留，该政策阻止强加密协议从美国导出。没有现代客户端依赖导出套件，禁用它们几乎没有坏处。
  2. 部署（短暂的）椭圆曲线 Diffie-Hellman（ECDHE）。椭圆曲线 Diffie-Hellman (ECDH) 密钥交换可避免所有已知的可行密码分析攻击，现代网络浏览器现在更倾向于使用 ECDHE，而不是原始的有限域 Diffie-Hellman。我们用来攻击标准 Diffie-Hellman 组的离散对数算法不会从预计算中获得那么大的优势，并且各个服务器不需要生成唯一的椭圆曲线。
  3. 建立强大、独特的 Diffie Hellman 组. 数以百万计的服务器使用一些固定组，这使它们成为预计算和潜在窃听的最佳目标。管理员应使用“安全”素数为每个网站或服务器生成唯一的 2048 位或更强大的 Diffie-Hellman 组。

根据上述建议，我应该采取哪些最佳实践步骤来保护我的服务器？

答案1

来自您链接的文章，有三个建议步骤来保护您自己免受此漏洞的侵害。原则上，这些步骤适用于您可能使用 SSL/TLS 的任何软件，但在这里我们将讨论将它们应用于 Apache (httpd) 的具体步骤，因为这是所讨论的软件。

  1. 禁用导出密码套件

在下面 2 中我们将进行的配置更改中处理（!EXPORT行末SSLCipherSuite是我们将如何禁用导出密码套件）

  1. 部署（临时）椭圆曲线 Diffie-Hellman (ECDHE)

为此，您需要编辑 Apache 配置文件中的几个设置 - 即SSLProtocol，，SSLCipherSuite以SSLHonorCipherOrder获得“最佳实践”设置。类似以下内容就足够了：

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

注意：至于SSLCipherSuite使用哪种设置，这总是在变化，最好查阅以下资源：这个检查最新的推荐配置。

3. 生成强大、独特的 Diffie Hellman 组

为此，您可以运行

openssl dhparam -out dhparams.pem 2048。

请注意，这会在生成参数时对服务器施加很大的负载 - 您可以随时通过在另一台机器上生成参数并使用scp或类似方式将它们传输到相关服务器上以供使用来解决这个潜在问题。

要在 Apache 中使用这些新生成的dhparams，请从Apache 文档：

要生成自定义 DH 参数，请使用 openssl dhparam 命令。或者，您也可以附加以下内容RFC 2409 第 6.2 节中的标准 1024 位 DH 参数到相应的 SSLCertificateFile 文件：

（重点是我的）

后面跟着一个标准的 1024 位 DH 参数。由此我们可以推断，自定义生成的 DH 参数可以简单地附加到相关参数中SSLCertificateFile。

为此，请运行类似以下命令：

cat /path/to/custom/dhparam >> /path/to/sslcertfile

或者，按照Apache 子部分您最初链接的文章，如果您不想更改证书文件本身，您还可以指定您创建的自定义 dhparams 文件，因此：

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

在与您的特定 SSL/TLS 实现相关的任何 Apache 配置中 - 通常在conf.d/ssl.conf或conf.d/vhosts.conf中，但这将根据您配置 Apache 的方式而有所不同。

值得注意的是，根据此链接，

在 Apache 2.4.7 之前，DH 参数始终设置为 1024 位，并且用户无法配置。mod_ssl 2.4.7 中已修复此问题，Red Hat 已将其移植到其 RHEL 6 Apache 2.2 发行版中，并附带 httpd-2.2.15-32.el6

在 Debian Wheezy 上，将 apache2 升级到 2.2.22-13+deb7u4 或更高版本，并将 openssl 升级到 1.0.1e-2+deb7u17。上述 SSLCipherSuite 无法完美运行，请按照以下方法使用这个博客：

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

您应该根据您的发行版检查您的 Apache 版本是否晚于这些版本号，如果不是，请尽可能更新它。

执行上述步骤更新配置并重新启动 Apache 服务以应用更改后，您应该通过运行测试来检查配置是否符合要求SSL实验室以及文章与此特定漏洞相关。

答案2

基于 Winni Neessen 的补丁，我发布了针对 Apache/2.2.22 (Debian Wheezy，也许也可以在 Ubuntu 上使用) 的修复程序：https://flo.sh/debian-wheezy-apache2-logjam-fix/- 感谢您的反馈。

答案3

不要采用上述复杂的“黑客”方法，而是考虑切换到 nginx作为您的主要 Web 服务器软件（而不仅仅是缓存或代理）。从安全角度来看，它显然比旧的 apache 引擎更符合当前标准。通过使用 nginx 存储库，它为您提供了比 apache 更稳定、更新的 Web 服务器引擎。

我完全改用了它。它为我节省了大量有关 TLS 的耗时问题解决时间，而且 - 对于我们的配置 - 它还释放了大量的 RAM。事实上，我发现使用 nginx 非常简单直接，与我习惯的 httpd/apache 的无数配置复杂性相比。这可能是个人喜好问题，在我改用之前，我已经非常熟悉 httpd/apache 的重写/配置/维护，它比我担心的要容易。网上有关于 nginx 配置的最新信息，它的用户群庞大，非常活跃，支持友好。 https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png

相关内容