14.5.Kerberos

Kerberos 是一个网络认证协议，最初由麻省理工学院（MIT）创建，作为一种在潜在的敌对网络中安全地提供认证的方式。Kerberos 协议使用了强大的加密技术，因此客户和服务器都可以证明他们的身份，而无需在网络上发送任何未加密的秘密。Kerberos 可以被描述为一个身份验证代理系统和一个可信的第三方认证系统。在用户通过 Kerberos 认证后，他们的通信会被加密以保证隐私和数据的完整性。

Kerberos 的唯一功能是为网络上的用户和服务器提供安全认证。它并不提供授权或审计功能。建议将 Kerberos 与其他提供授权和审计服务的安全方法一起使用。

该协议的当前版本是版本 5，如 RFC 4120 中所述。该协议的几种免费实现可用，涵盖广泛的操作系统。麻省理工学院继续开发他们的 Kerberos 软件包。它在美国通常用作加密产品，并且历来受美国出口法规的约束。在 FreeBSD 中，MITKerberos 可用作 security/krb5 包或端口。Heimdal Kerberos的实施是在美国境外明确开发的，以避免出口法规。Heimdal Kerberos 发行版包含在基本的 FreeBSD 安装中。而另一个具有更多可配置选项的发行版在 Ports Collection 中作为 security/heimdal 提供。

在 Kerberos 中，用户和服务被标识为“主体”，这些主体包含在称为“域”的管理分组中。典型的用户主体是这种形式（域传统上是大写的）。user@REALM

本节提供了如何使用 FreeBSD 中包含的 Heimdal 发行版来设置 Kerberos 的指南。

为了演示 Kerberos 安装，命名空间将如下所示：

  • DNS 域（区域）将是 example.org。
  • Kerberos 领域将是 EXAMPLE.ORG。
注意
设置 Kerberos 时使用真实域名，即使它将在内部运行。这样可以避免 DNS 问题，并确保与其他 Kerberos 域进行交互。

14.5.1. 建立一个Heimdal KDC

密钥分发中心 （KDC） 是 Kerberos 提供的集中式身份验证服务，是系统的“受信任的第三方”。是计算机发出 Kerberos 票证，这些票证用于客户端向服务器进行身份验证。由于 KDC 被 Kerberos 领域的所有其他计算机视为信任，因此它加剧了安全问题。应限制对 KDC 的直接访问。

虽然运行 KDC 只需要很少的计算资源。但出于安全考虑。建议使用一台只充当 KDC 的专用机器。

首先，请按如下方式安装 security/heimdal 软件包：

  1. # pkg install heimdal

接下来，使用 sysrc 更新 /etc/rc.conf，如下所示:

  1. # sysrc kdc_enable=yes
  2. # sysrc kadmind_enable=yes

接下来，编辑 /etc/krb5.conf，如下所示：

  1. [libdefaults]
  2.     default_realm = EXAMPLE.ORG
  3. [realms]
  4.     EXAMPLE.ORG = {
  5.     kdc = kerberos.example.org
  6.     admin_server = kerberos.example.org
  7.     }
  8. [domain_realm]
  9.     .example.org = EXAMPLE.ORG

在此示例中，KDC 将使用完全限定的主机名 kerberos.example.org 。KDC 的主机名必须在 DNS 中可解析。

Kerberos 也可以使用 DNS 来定位 KDC。而不是在 /etc/krb5.conf 中的 [realms] 部分。对于拥有自己的 DNS 服务器的大型组织来说。上面的例子可以修改为：

  1. [libdefaults]
  2.       default_realm = EXAMPLE.ORG
  3. [domain_realm]
  4.     .example.org = EXAMPLE.ORG

在 example.org 区域文件中加入以下几行：

  1. _kerberos._udp      IN  SRV     01 00 88 kerberos.example.org.
  2. _kerberos._tcp      IN  SRV     01 00 88 kerberos.example.org.
  3. _kpasswd._udp       IN  SRV     01 00 464 kerberos.example.org.
  4. _kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.example.org.
  5. _kerberos           IN  TXT     EXAMPLE.ORG
注意
为了使客户端能够找到 Kerberos 服务，它们必须具有完全配置的 /etc/krb5.conf 或最低配置的 /etc/krb5.conf 以及 正确配置的 DNS 服务器。

接下来，创建 Kerberos 数据库，它包含了所有委托人（用户和主机）的密钥，并以主密码加密。不需要记住这个密码，因为它将被保存在 /var/heimdal/m-key 中；为此，使用一个 45 个字符的随机密码是合理的。要创建主密钥，请运行 kstash 并输入一个密码。

  1. # kstash
  2. Master key: xxxxxxxxxxxxxxxxxxxxxxx
  3. Verifying password - Master key: xxxxxxxxxxxxxxxxxxxxxxx

一旦主密钥被创建。数据库就应该被初始化。Kerberos 管理工具 kadmin（8） 可以在 KDC 上以 kadmin -l 的模式直接操作数据库。而不必使用 kadmind（8） 网网络服务。这就解决了在数据库创建之前试图连接到数据库的鸡生蛋蛋生鸡的问题。在 kadmin 提示下，使用 init 来创建领域的初始数据库。

  1. # kadmin -l
  2. kadmin> init EXAMPLE.ORG
  3. Realm max ticket life [unlimited]:

最后，在 kadmin 中，使用 add 创建第一个 主体。现在坚持使用主体的默认选项，因为这些选项可以在以后用 modify 修改。在提示符下输入 ? 来查看可用的选项。

  1. kadmin> add tillman
  2. Max ticket life [unlimited]:
  3. Max renewable life [unlimited]:
  4. Principal expiration time [never]:
  5. Password expiration time [never]:
  6. Attributes []:
  7. Password: xxxxxxxx
  8. Verifying password - Password: xxxxxxxx

接下来，通过运行以下命令启动 KDC 服务：

  1. # service kdc start
  2. # service kadmind start

虽然此时不会运行任何 kerberized 守护程序，但可以通过获取刚刚创建的主体的票证来确认 KDC 是否正在运行：

  1. % kinit tillman
  2. tillman@EXAMPLE.ORG's Password:

使用 kilist 命令确认已成功获取票证：

  1. % klist
  2. Credentials cache: FILE:/tmp/krb5cc_1001
  3.     Principal: tillman@EXAMPLE.ORG
  5.   Issued                Expires               Principal
  6. Aug 27 15:37:58 2013  Aug 28 01:37:58 2013  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG

测试完成后，可以销毁临时票证：

  1. % kdestroy

14.5.2. 配置服务器以使用 Kerberos

将服务器配置为使用 Kerberos 身份验证的第一步是确保它在 /etc/krb5.conf 中具有正确的配置。KDC 中的版本可以按原样使用，也可以在新系统上重新生成。

接下来。在服务器上创建 /etc/krb5.keytab。。这是 “Kerberizing” 服务的主要部分 - 它相当于生成一个在服务和 KDC 之间共享的秘密。这个秘密是存储在 “keytab” 中的一个加密密钥。keytab 包含服务器的主机密钥，它允许服务器和 KDC 互相验证对方的身份。它必须以安全的方式传送给服务器，因为如果钥匙被公开，服务器的安全就会被破坏。通常，keytab 是在管理员的信任机器上使用 kadmin 生成的，然后安全传输到服务器，例如使用 scp（1）； 如果符合所需的安全策略。也可以直接在服务器上创建。以安全的方式将密钥表传输到服务器是非常重要的：如果密钥被其他方知道，该方可以冒充任何用户到服务器上! 在服务器上直接使用 kadmin 是很方便的。因为 KDC 数据库中的主机负责人条目也是用 kadmin 创建的。

当然，kadmin是一个 kerberized 服务； 需要一个 Kerberos 票来验证网络服务。但为了确保运行 kadmin 的用户确实存在 (并且他们的会话没有被劫持)。kadmin 会提示密码以获得一个新的票。验证 kadmin 服务的委托人必须被允许使用 kadmin 接口，正如在 /var/heimdal/kadmind.acl 中指定的那样。关于设计访问控制列表的细节，请参见 info heimdal 中题为 “远程管理 “的章节。管理员可以通过本地控制台或 ssh（1） 安全地连接到 KDC。并使用 kadmin -l 进行本地管理。而不是启用远程 kadmin 访问。

安装 /etc/krb5.conf 后，在 kadmin 中使用 add --random-key。这将把服务器的主机主密钥添加到数据库中。但不会将主机主密钥的副本提取到钥匙串中。要生成钥匙串，请使用 ext 来提取服务器的主机主密钥到它自己的钥匙串中。

  1. # kadmin
  2. kadmin> add --random-key host/myserver.example.org
  3. Max ticket life [unlimited]:
  4. Max renewable life [unlimited]:
  5. Principal expiration time [never]:
  6. Password expiration time [never]:
  7. Attributes []:
  8. kadmin> ext_keytab host/myserver.example.org
  9. kadmin> exit

注意，ext_keytab 默认将提取的密钥存储在 /etc/krb5.keytab 中。当运行在支持 kerberos 的服务器上时，这很好，但是当在其他地方提取 keytab 时，应该使用 --keytab path/to/file 参数:

  1. # kadmin
  2. kadmin> ext_keytab --keytab=/tmp/example.keytab host/myserver.example.org
  3. kadmin> exit

然后，可以使用 scp（1） 或可移动介质将密钥表安全地复制到服务器。请务必指定非默认键表名称，以避免将不需要的键插入到系统的键表中。

此时，服务器可以使用存储在 krb5.keytab 中的共享密钥从 KDC 读取加密邮件。现在，它已准备好启用使用 Kerberos 的服务。最常见的此类服务之一是 sshd（8），它通过 GSS-API 支持 Kerberos。在 /etc/ssh/sshd_config 中，添加以下行：

  1. GSSAPIAuthentication yes

进行此更改后，必须重新启动 sshd（8） 才能使新配置生效： service sshd restart 。

14.5.3. 配置客户端以使用 Kerberos

与服务器的情况一样，客户端也需要在 /etc/krb5.conf 中进行配置。将该文件复制到原地 (安全地) 或根据需要重新输入。

通过在客户机上使用 kinit、klist 和 kdestroy 来获取、显示并删除现有委托人的 ticket 来测试客户机。Kerberos 应用程序也应该能够连接到支持 Kerberos 的服务器。如果这不起作用。而获取 ticket 却起作用。那么问题可能出在服务器上。而不是在客户机或 KDC 上。在使用 Kerberized ssh（1） 的情况下。GSS-API 默认是禁用的。所以请使用 ssh -o GSSAPIAuthentication=yes hostname 进行测试。

在测试 Kerberized 应用程序时。请尝试使用诸如 tcpdump 这样的数据包嗅探器来确认没有敏感信息是以透明方式发送的。

有各种 Kerberos 客户端应用程序可用。随着桥梁的出现。使用 SASL 进行认证的应用程序也可以使用 GSS-API 机制。大类客户应用程序可以使用 Kerberos 进行认证。从 Jabber 客户端到 IMAP 客户端。

领域内的用户通常将他们的 Kerberos principal 映射到一个本地用户帐户。偶尔，我们需要把对本地用户帐户的访问权授予那些没有相应 Kerberos principal 的人。例如，tillman@EXAMPLE.ORG 可能需要访问本地用户帐户 webdevelopers。其他委托人也可能需要访问该本地帐户。

放在用户主目录下的 .k5login 和 .k5users 文件可以用来解决这个问题。例如，如果将下面的 **.k5login** 放在 webdevelopers 的主目录中，那么列出的两个负责人都可以访问该帐户，而不需要共享密码。

  1. tillman@example.org
  2. jdoe@example.org

有关 .k5users 的更多信息，请参阅 ksu（1)。

14.5.4. 与MIT的差异

MIT 和 Heimdal 实现之间的主要区别在于 kadmin 有一套不同的、但又相当的命令，并使用不同的协议。如果 KDC 是 MIT 的，Heimdal 版本的 kadmin 就不能用来远程管理 KDC，反之亦然。

客户端应用程序也可能使用略有不同的命令行选项来完成同样的任务。建议遵循 http://web.mit.edu/Kerberos/www/ 上的说明。要注意路径问题： MIT port 默认会安装到 /usr/local/ 。如果 PATH 将系统目录列在前面。FreeBSD 的系统应用程序会代替 MIT 版本运行。

当在 FreeBSD 上使用 MIT Kerberos 作为 KDC 时。还应该对 rc.conf 进行以下编辑：

  1. kdc_program="/usr/local/sbin/kdc"
  2. kadmind_program="/usr/local/sbin/kadmind"
  3. kdc_flags=""
  4. kdc_enable="YES"
  5. kadmind_enable="YES"

14.5.5. Kerberos 提示、技巧和故障排除

在配置 Kerberos 并进行故障排除时，请记住以下几点：

  • 当从端口使用 Heimdal 或 MITKerberos 时。确保 PATH 在系统版本之前列出端口的客户应用程序的版本。
  • 如果域中的所有计算机都没有同步时间设置，则身份验证可能会失败。“与 NTP 的时钟同步” 介绍了如何使用 NTP 同步时钟。
  • 如果更改了主机名，则必须更改 host/ 主体并更新 keytab。这也适用于特殊的 keytab 条目，如 HTTP/ 主体用于 Apache 的 www/mod_auth_kerb。
  • 域中的所有主机必须在 DNS 中可以正向和反向解析，或者至少在 /etc/hosts 中存在。CNAME 可以工作，但 A 和 PTR 记录必须是正确的。对于无法解析的主机，错误消息并不直观：Kerberos5 refuses authentication because Read req failed: Key table entry not found。
  • 一些作为 KDC 客户的操作系统没有将 ksu 的权限设置为 setuid root。这意味着 ksu 不能工作。这是一个权限问题，而不是 KDC 的错误。
  • 在 MITKerberos 中。要让一个委托人的票据寿命超过默认的 10 小时。可以在 kadmin（8） 提示下使用 modify_principal 来改变相关委托人和 krbtgt 委托人的最大寿命。然后。委托人可以使用 kinit -l 来请求一个寿命更长的 ticket。
  • 在工作站上运行 kinit 时。在 KDC 上运行数据包嗅探器以帮助排除故障时。Ticket Granting Ticket (TGT) 会立即发送。甚至在输入密码之前。这是因为 Kerberos 服务器会对任何未经授权的请求自由地发送 TGT。然而，每一个TGT都被加密在一个从用户的密码衍生出来的密钥中。当用户输入他们的密码时，它不会被发送到 KDC，而是被用来解密 kinit 已经获得的 TGT。如果解密过程的结果是带有有效时间戳的有效票据，那么该用户就拥有有效的 Kerberos 凭证。这些凭证包括一个会话密钥，用于在将来与 Kerberos 服务器建立安全通信，以及实际的 TGT，它是用 Kerberos 服务器自己的密钥加密的。这第二层加密允许 Kerberos 服务器验证每个 TGT 的真实性。
  • 主机主体可以具有更长的票证生存期。如果用户主体的生存期为一周，但要连接到的主机的生存期为 9 小时，则用户缓存将具有过期的主机主体，并且票证缓存将无法按预期工作。
  • 在设置 krb5.dict 以防止像 kadmind（8） 中所述使用特定的错误密码时，请记住，它仅适用于分配了密码策略的委托人。krb5.dict 中使用的格式是每行一个字符串。创建指向 /usr/share/dict/words 的符号链接可能很有用。

14.5.6. 缓解 Kerberos 限制

由于 Kerberos 是一种全有或全无的方法，因此必须修改网络上启用的每个服务才能与 Kerberos 配合使用，否则必须保护其免受网络攻击。这是为了防止用户凭据被盗和重复使用。例如，在所有远程 shell 上启用了 Kerberos，但非 Kerberized POP3 邮件服务器以纯文本形式发送密码。

KDC 是单点故障。根据设计，KDC 必须与其主密码数据库一样安全。KDC 上绝对不应运行其他服务，并且应该在物理上是安全的。危险很大，因为 Kerberos 存储了使用相同主密钥加密的所有密码，该主密钥作为文件存储在 KDC 上。

泄露的主密钥并不像人们担心的那么糟糕。主密钥仅用于加密 Kerberos 数据库，并用作随机数生成器的种子。只要对 KDC 的访问是安全的，攻击者就无法使用主密钥执行太多操作。

如果 KDC 不可用，则网络服务不可用，因为无法执行身份验证。这可以通过单个主 KDC 和一个或多个从站以及使用 PAM 仔细实现辅助或回退身份验证来缓解。

Kerberos 允许用户、主机和服务在它们之间进行认证。它没有一个机制可以让 KDC 对用户、主机或服务进行认证。这意味着一个被木马化的 kinit 可以记录所有的用户名和密码。像 security/tripwire 可以缓解这种情况。

14.5.7. 资源和更多信息