为什么在 chroot 中运行 named(bind) 对安全性如此重要？或者可能不是？

Question

我正在玩 bind，开始疑惑为什么这个软件在 CentOS 中以 chroot 运行。不要误会我的意思，我知道 bind 是什么，chroot（监狱）是干什么用的。但我的主要问题是，bind 在没有 chroot 的情况下运行是否非常不安全？

在没有 jail 的情况下进行设置真的有害吗（比任何其他服务或软件都有害）。系统中有许多进程在未使用 chroot 的情况下运行，我认为其中任何一个进程的入侵都是非常危险的，但是什么让 named 比其他未使用 chroot 运行的软件更危险呢？

Answer 1

正如@Some Guy 提到的，你必须从历史的角度来思考这个问题。

从历史上看，一个硬件就是一个操作系统下的十几个不同的服务。如果一个服务被攻破，那么该硬件上的所有服务都会被攻破。

有了虚拟化，这个问题就小多了。虽然逃离虚拟机并非不可能，但绝非易事。逃离虚拟机肯定比以 root 权限运行的进程逃离 chroot 更困难。所以我的绑定服务器在自己的虚拟机上运行。在这种情况下，chroot 真的没什么意义，因为损害已经因为它是虚拟机而受到限制。

chroot 是一种非常弱的尝试，用于创建类似 VM 的东西。任何具有 root 权限的进程都可以从 chroot 中逃脱。chroot 并非旨在作为一种安全机制，也不能作为一种安全机制。带有 BSD jail 或 LXC 的 chroot 为您提供操作系统级虚拟化，并提供安全功能。但是，如今启动整个机器的新 VM 如此容易，因此可能不值得为此目的而设置或学习如何使用操作系统级虚拟化工具。

早期版本的 bind 不会放弃特权。在 Unix 上，只有 root 帐户可以打开 1024 以下的端口，而众所周知，Bind 需要监听 udp/53 和 tcp/53。由于 Bind 以 root 身份启动，并且不会放弃特权，因此任何入侵都意味着整个系统都可能受到威胁。如今，几乎所有软件都会打开套接字并执行任何其他需要 root 特权的操作，然后它们会将正在运行的用户更改为非特权帐户。一旦放弃特权，入侵对主机系统的影响就会小得多。

Answer 2

其他答案都很好，但都没有提到分层安全的概念。你给系统添加的每一层安全都是对手必须克服的另一层。将 BIND 置于 chroot 中又增加了一个障碍。

假设 BIND 中存在可利用的漏洞，有人能够执行任意代码。如果他们处于 chroot 中，他们需要先摆脱 chroot 才能进入系统的其他任何状态。如前所述，chroot 突破需要 root 权限。BIND 不以 root 身份运行，并且 chroot 中可用的工具应该很少，这进一步限制了选项，并且基本上只留下系统调用。如果没有系统调用来提升权限，那么对手就只能查看您的 DNS 记录。

SomeGuy 提到，上述情况不太可能发生，BIND 目前的漏洞很少，而且大多仅限于 DoS 类型的场景，而不是远程执行。话虽如此，在 chroot 中运行是相当多操作系统的默认配置，因此您不太可能需要付出任何努力来保持略微增强的安全性。

Answer 3

前言

我不断听到人们在互联网上重申错误观念。因此，我将尝试做出一些澄清

首先；有多少偶然的发现，仅仅是由于……因果，最终被用来做某事其他比其预期目的？

Chroot jail 过去和现在是什么

Chroot 最初设计用于更改进程或用户的根目录（非常适合从未知来源编译软件）。这提供了安全到基础系统，以及快速测试平台设备，包括简单的清理。很多年过去了，它的概念和隐含的用途也发生了变化。

已使用 chroot有效地，并且直接位于代码库中一些程序和库（即 openSSHd、apache2 + mod_security2/mod_chroot、dovecot、sendmail、openVPN、pam_chroot、以及更多）假设所有这些主流应用程序都实施了错误的安全解决方案，这只是不对

chroot 是文件系统虚拟化的一个解决方案：仅此而已。认为您可以轻松摆脱 chroot 的假设也是不正确的……只要您遵守在 chroot jail 内运行进程的准则。

确保 chroot jail 安全的一些步骤

即不是以 ROOT 身​​份运行进程。这可能会打开 root 升级向量（在 chroot 内部或外部也是如此）。不要运行进程里面chroot，使用与另一个进程相同的用户外部chroot。将每个进程和用户分离到他自己的 Chroot 中，以限制攻击面并提供隐私。仅安装必要的文件、库和设备。最后，chroot 不能替代基本系统安全性。确保整个系统的安全。

另一个重要注意事项：很多人认为 OpenVZ 已损坏，或者它与完整的系统虚拟化相比有所欠缺。他们之所以做出这种假设，是因为 OpenVZ 本质上是一个 Chroot，带有一个已被净化的进程表，并且在硬件和设备上采取了安全措施。最多您可以在 chroot 中实现它。

并非每个管理员都具备在专用服务器或完整系统虚拟化下保护所有必要内核参数所需的知识水平。这意味着部署 OpenVZ 意味着您的客户在部署其应用程序之前需要尝试覆盖和保护的攻击面要小得多。好的主机将很好地保护这些参数，反过来，这不仅对节点或数据中心的每个人都有好处，而且对整个互联网都有好处……

如上所述，chroot 提供文件系统虚拟化。您必须确保没有 setuid 可执行文件、不安全的应用程序、库、悬空的无主符号链接等。如果攻击者可以破坏 bind，他们将需要搜索虚拟文件系统以查找缓冲区溢出、玩弄文件描述符或以其他方式破坏 chroot 内部的某些内容，通常通过提升权限或将他或她的有效载荷注入基本系统来逃离监狱。

如果发生这种情况，通常是由于错误更新、零日漏洞或惯用的人为错误。

为什么仍然使用 chroot，而不是完整的系统虚拟化

考虑一下这种情况：你正在运行虚拟专用服务器，主机节点运行 OpenVZ。你只需不能运行在内核级别上运行的任何东西。这也意味着您不能使用操作系统虚拟化来分离进程，并提供额外的安全性。因此，您必须为此目的使用 chroot。

此外，无论有多少可用资源，chroot 在任何系统上都是可持续的。简而言之，它是所有虚拟化类型中开销最小的。这意味着它在许多低端机器上仍然很重要。

考虑另一种情况：您在虚拟化环境中运行 Apache。您想要分离每个用户。通过 Apache 的 chroot 插件（mod_chroot、mod_security 等）提供虚拟化文件系统将是确保最终用户之间最大程度隐私的最佳选择。这也有助于防止情报收集，并提供另一层安全性。

简而言之，重要的是在图层。Chroot 可能是其中之一。并不是每个人和每个系统都能够访问内核，因此，chroot仍然有其用途。在各种各样的应用程序中，完整的系统虚拟化本质上是过度的。

回答你的问题

我并不特别使用 CentOS，但我知道 Bind 现在会在操作之前放弃其权限。不过，我认为 bind 已经 chrooted，因为它存在攻击媒介和潜在漏洞的历史。

此外...自动 chroot 此应用程序比不自动 chroot 更有意义，因为不是每个人都可以访问完整的系统/操作系统级虚拟化。从理论上讲，这反过来有助于为 CentOS 用户群提供安全性：

操作系统提供商根本不会假设每个人都在运行相同的系统。这样，他们就可以帮助提供额外的安全保障……

有原因的很多应用程序都使用这个，以及为什么您的操作系统默认会这样做：因为它被用作安全功能，并且它确实有效。如前所述，经过精心准备，这是潜在攻击者必须克服的另一个障碍 - 大多数情况下，将损害限制在仅对 chroot jail 造成损害。

Answer 4

这部分是由于历史原因，当时旧版本的 Bind 存在严重且频繁的安全漏洞。我并没有真正关注过这个问题，但我敢打赌，自那段糟糕的时光以来，它已经有很大改进。

另一个更实际的原因是，它通常部署在面向互联网的角色中，因此，它更容易受到攻击、探测和一般恶作剧。

因此，正如安全问题上的经验法则：安全总比后悔好，尤其是当 chroot 的工作量相对较少时。