如何在 Checkmk 2.3 中监控 TLS 损坏的服务器

在 Checkmk 2.3.0 中，我们将 OpenSSL 的版本从 1.1 提升至 3.0。这意味着与安全相关的密码、握手和重新协商设置的默认值更加严格。因而可能会出现对各种服务的主动检查失败的情况，包括但不限于 check_http、check_smtp 和其他一些服务。以下是解决潜在问题的方法。

自 Checkmk 创立之初，OMD 就是一种打包监控系统所有组件的方式。这不仅包括监控核心、网络接口和数据库组件。它还意味一并打包特定版本的OpenSSL 或 Python 解释器，以与所有已支持操作系统保持一致性。这种组件一致性是必要的，以保证在支持新系统（如即将发布的 Ubuntu 24.04）的同时，确保在比较旧的系统上（如仍受支持的 RHEL 8）的行为一致性。

伴随 Checkmk 2.3.0 更新的一个重要更新是从 OpenSSL 1.1 升级到 3.0。OpenSSL 开发人员努力移除旧的密码、传统协议和扩展，转而使用更现代（读作：更安全）的默认设置。这不可避免地会破坏与旧版软件或硬件的兼容性，导致 Checkmk 中主动检查的失败。

一般来说，这些失败的检查应作为一个指标，表明受监控主机必须更新到更现代的 TLS 库，或至少 TLS 特定设置应调整到更安全的默认值。在 Checkmk 2.3.0 测试版的内部测试中，大多数情况下，这样做就可以解决问题了。

不过，并非在所有情况下都能更改 TLS 设置。确实存在一些无法更改设置的合理原因，比如要保持与其他旧系统的广泛兼容性。对于既不能更新也不能更改配置的系统，你可能想改变 OpenSSL 3.x 的行为，以便能与这些系统通信。具体做法是用一个更宽松的自定义配置覆盖 OpenSSL 默认配置，且该自定义配置只适用于受影响的主机。

模拟行为

这一步骤是选择性步骤，如果您无法持续访问受影响的系统，这一方法或许会有用。这可能适用于位于不同网络且只能从远程站点访问的主机。或者当您是 Checkmk 合作伙伴并试图解决客户的问题时。这时，https://badssl.com/ 上的 BadSSL 项目就派上用场了。它提供了各种过时或 “配置错误 ”的 SSL 端点，可用于测试。配置一条规则（此处用于对 HTTP 服务进行主动检查），使故障细节与监控主机遇到的故障相匹配。

“Setup > HTTP, TCP, Email, … > Check HTTP service”

此时检查输出应为 “CRIT - Cannot make SSL connection”：

变通方法的构建步骤

第一步 创建自定义 OpenSSL 配置文件

在网站用户的 etc/ 文件夹中创建一个配置文件。我们的示例使用的文件名是 unsafe_openssl.cnf。在更大的环境中，您可能需要多个不同的文件来解决多个不同的问题：

第二步： 复制失败检查的命令行

现在，您需要确定使用的是哪个插件。切换到检查的详细信息并确定插件名称——即介于 “check_mk_active-”和“！”之间的字符串。此外您还需要记下在第一个（通常也是唯一一个）“！”之后显示的参数。

在示例中，您需要复制的是以下内容：

Plugin: http

Arguments: -C 0,0 --sni -p 1010 -I tls-v1-0.badssl.com -H tls-v1-0.badssl.com

第三步 集成 Nagios 插件

变通方法的主要内容是在不同的环境中运行检查插件，使插件使用在第一步中创建的更具许可性的配置。导航至：

“Setup > [show more] > Other services > Integrate Nagios plugins”

现在需要构建新的命令行。在路径前加上环境变量，告诉 openssl 使用第一步创建的 unsafe_openssl.cnf 文件：

此时，您可以将整个命令粘贴到网站用户的 shell 中，运行命令并检查命令行输出和返回值（包含在变量$?中）。

最后，将整个命令粘贴到“Command line”的文本条目中，并保存规则：

带有自定义配置的 HTTPS BadSSL 示例 2 现在已正常运行，示例 1 可以删除了——在实际操作时，您可以先删除 HTTPS BadSSL 示例 1，然后给自定义检查起一个与之前失败的检查相同的名字。

更多想法

所提供的示例在大多数情况下都有效。如果无法正常工作，我们建议您尝试找出一种解决方案，来运行使用OpenSSL 3.0 的标准检查。这可能需要进一步修改配置文件，最终出现上述提到的针对不同问题的配置文件。如果您能在 Checkmk 论坛上公布您的解决方案，我们将不胜感激。请不要忘记说明您的配置所针对的软件或设备版本。

正如您所了解的，主动检查只是指运行一个符合监控插件项目规范的程序。如果为要检查的服务更改 OpenSSL 3 配置未果，可以尝试安装 Checkmk 以外其他来源的监控插件包。这些插件不会干扰 Checkmk 提供的插件。

但在这样做之前，请您考虑一下：
1.您可能会隐藏掉急需解决的安全问题。
2.选择省事的方法可能会导致我们无法为广泛使用的软件和设备创建合适的 OpenSSL 3 配置文件存档。

可能您已理解上述警示，但仍然想这么做？希望您明白在不同情况下所需要付出的努力也会有很大不同：安装可能与使用发行版提供的软件包一样简单。例如，Ubuntu 20.04 提供的监控插件 2.2 就是一个与 OpenSSL 1.1 相链接的二进制软件包。测试这种组合几乎不费吹灰之力，因此值得一试。但在较新的发行版中，可能需要同时编译 OpenSSL 1.1 和监控插件，这可能需要大量的编译器调整、源代码修补工作，因此需要进行乏味的试错。

结论

虽然有时可能需要打破少数受影响系统的兼容性，以提高大多数系统的安全性，但 Checkmk 的开放式方法及其对常用标准的坚持，使创建简单且直达目标的变通方法成为可能。