第 11 章 使用 Kerberos
在网络中维护系统安全性和完整性至关重要,它包括网络基础架构中的每个用户、应用程序、服务和服务器。需要了解在网络上运行的所有内容以及使用这些服务的方式。保持这种安全性的核心在于维护对这些应用和服务 的访问 并强制实施该访问。
Kerberos 是一种身份验证协议,明显比基于密码的普通身份验证更加安全。借助 Kerberos,密码绝不会通过网络发送,即使在其他计算机上访问服务也是如此。
Kerberos 提供了一种机制,允许用户和计算机向网络表明自己身份并接收对管理员配置的区域和服务进行定义的有限访问权限。Kerberos 通过验证其身份 来验证实体,Kerberos 还可保护此数据的身份验证,使其不能被外部人员访问和使用和使用。
11.1. 关于 Kerberos
Kerberos 使用对称密钥加密[3] 要验证用户到网络服务的身份验证,这意味着密码实际上不会通过网络发送。
因此,当用户使用 Kerberos 向网络服务进行身份验证时,试图通过监控网络流量来收集密码的未授权用户实际上会被阻止。
11.1.1. Kerberos 工作方式的基础知识
大多数传统网络服务使用基于密码的身份验证方案,即用户提供密码以访问给定的网络服务。但是,许多服务的身份验证信息的传输是不加密的。为了使这种方案安全,网络必须不可被外部人员访问,并且网络上的所有计算机和用户都必须信任和信赖。
通过基于密码的简单身份验证,无法认为连接到互联网的网络是安全的。任何获得网络访问权限的攻击者都可以使用简单的数据包分析器或 数据包嗅探器 来拦截用户名和密码,威胁用户帐户,从而影响整个安全基础架构的完整性。
Kerberos 消除了网络上未加密密码的传输,并消除了攻击者窃听网络的潜在威胁。
Kerberos 使用对称加密和可信第三方(一个 密钥分发中心 或 KDC)对用户进行身份验证,而不是像简单密码身份验证一样单独向每个网络服务验证用户。由该 KDC 和任何辅助 KDC 管理的计算机组成一个 域。
当用户向 KDC 进行身份验证时,KDC 会为该会话发送一组特定于该会话的凭据( 票据)回用户的计算机,而任何 Kerberos 感知服务都会查找用户机器上的票据,而不是要求用户使用密码进行身份验证。
如 图 11.1 “Kerberos 身份验证” 所示,每个用户都标识到带有唯一身份的 KDC,称为 主体。当 Kerberos 感知网络中的用户登录到其工作站时,作为来自身份验证服务器的 票据 (或 TGT)请求的一部分,他的主体会被发送到 KDC。此请求可由登录程序发送,使其对用户透明,也可以在用户登录后通过 kinit 程序手动发送。
然后,KDC 会检查数据库中的主体。如果找到主体,KDC 会创建一个 TGT,使用用户的密钥对其进行加密,并将 TGT 发送到该用户。
图 11.1. Kerberos 身份验证
然后,客户端上的 login 或 kinit 程序使用用户的密钥解密 TGT,该密钥从用户的密码计算。用户的密钥仅在客户端计算机上使用,不会 通过网络传输。KDC 发送的票据(或凭证)存储在本地存储中,凭据缓存(ccache) 可以被 Kerberos 感知服务检查。Red Hat Enterprise Linux 7 支持以下类型的凭证缓存:
- 持久性 KEYRING ccache 类型,Red Hat Enterprise Linux 7 中的默认缓存
- 系统安全服务守护进程(SSSD)Kerberos 凭据管理器(KCM),这是 Red Hat Enterprise Linux 7.4 起的替代选项
- FILE
- DIR
- MEMORY
使用 SSSD KCM 时,Kerberos 缓存不存储在被动存储中,而是由守护进程管理。在这个设置中,Kerberos 库通常由
kinit
等应用程序使用,是一个 KCM 客户端,守护进程被称为 KCM 服务器。
使用由 SSSD KCM 守护进程管理的 Kerberos 凭证缓存有几个优点:
- 守护进程有状态,可以执行 Kerberos 凭据缓存续订或恢复旧 ccache 等任务。续订和跟踪不仅可能适用于 SSSD 本身获取的票据,通常是通过
pam_sss.so
登录,也适用于获取票据,例如 kinit。 - 由于进程在用户空间中运行,因此它受到 UID 命名空间的限制,这与内核 KEYRING 不同。
- 基于 Kernel KEYRING 的缓存(完全依赖于调用者的 UID),以及容器化环境中在所有容器中共享的基于 Kernel KEYRING 的缓存不同,KCM 服务器的入口点是只能绑定到所选容器的 UNIX 套接字。
身份验证后,服务器可以检查可识别主体及其密钥的未加密的列表,而不是检查 kinit; 这保存在 keytab 中。
TGT 设置为在特定时间段(通常为 10 小时至 24 小时)后过期,并存储在客户端计算机的凭证缓存中。设定了一个过期时间,以便一个被入侵的 TGT 仅在短时间内被攻击者使用。在 TGT 发出后,用户不必再次输入密码,直到 TGT 过期或直到他们注销并再次登录为止。
每当用户需要访问网络服务时,客户端软件使用 TGT 从票据授权服务器(TGS)请求该特定服务的新票据。服务票据随后用于以透明的方式向该服务验证用户。
11.1.2. 关于 Kerberos 主体名称
主体不仅标识用户或服务,也标识该实体所属的域。主体名称包含两个部分:标识符和域:
identifier@REALM
对于用户,标识符 只是 Kerberos 用户名。对于服务,标识符 是服务名称和其运行机器的主机名的组合:
service/FQDN@REALM
服务名称 是一个特定于服务类型的区分大小写的字符串,如 host、ldap、http 和 DNS。并非所有服务都有明显的主体标识符;例如,
sshd
守护进程都使用主机服务主体。
主机主体通常存储在
/etc/krb5.keytab
中。
当 Kerberos 请求一个票据时,它会始终将域名别名(DNS CNAME 记录)解析为对应的 DNS 地址(A 或 AAAA 记录)。然后,在创建服务或主机主体时使用地址记录的主机名。
例如:
www.example.com CNAME web-01.example.com web-01.example.com A 192.0.2.145
服务尝试使用其 CNAME 别名连接到主机:
$ ssh www.example.com
Kerberos 服务器为解析的主机名 web-01.example.com@EXAMPLE.COM 请求一个 ticket,因此主机主体必须是 host/web-01.example.com@EXAMPLE.COM。
11.1.3. 关于 Domain-to-Realm 映射
客户端尝试访问特定服务器上运行的服务时,它知道服务的名称(host)和服务器的名称(foo.example.com),但由于可以在网络上部署多个域,因此它必须猜测该服务所在的 Kerberos 域的名称。
默认情况下,realm 的名称取为服务器在所有大写字母中的 DNS 域名。
foo.example.orgEXAMPLE.ORG foo.example.com EXAMPLE.COM foo.hq.example.com HQ.EXAMPLE.COM
在某些配置中,这已经足够了,但在其他配置中,派生的域名将是不存在的域的名称。在这些情况下,必须在客户端系统
/etc/krb5.conf
文件的 domain_realm 部分中指定从服务器的 DNS 域名到其域名的映射。例如:
[domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
配置指定了两个映射:第一个映射指定 example.com DNS 域中的任何系统都属于 EXAMPLE.COM 域。第二个命令指定名称为 example.com 的系统也位于 realm 中。域和特定主机之间的区别由存在或缺少初始句点字符来标记。映射还可使用 "_kerberos TXT" 记录直接存储在 DNS 中,例如:
$ORIGIN example.com _kerberos TXT "EXAMPLE.COM"
11.1.4. 环境要求
Kerberos 依赖于能够解析机器名称。因此,它需要一个有效的域名服务(DNS)。必须正确配置网络上的 DNS 条目和主机,这包括在
/usr/share/doc/krb5-server-
version-number 的 Kerberos 文档中。
接受 Kerberos 身份验证的应用程序需要时间同步。您可以使用 ntpd 等服务在网络上的机器间设置大约时钟同步。有关
ntpd
服务的详情,请查看 /usr/share/doc/ntp-
version-number/html/index.html
或 ntpd(8) man page 中的文档。
注意
运行红帽企业 Linux 7 的 Kerberos 客户端支持使用 KDC 自动调整时间,并且没有严格的计时要求。这样,在使用红帽企业 Linux 7 部署 IdM 客户端时,可以更好地容忍调整差异。
11.1.5. 部署 Kerberos 的注意事项
尽管 Kerberos 消除了常见且严重的安全威胁,但出于各种原因很难实施:
- Kerberos 假定每个用户都是受信任的,但在不可信网络上使用不受信任的主机。其主要目标是防止未加密密码在这个网络中传输。但是,如果除正确用户之外的任何人都有权访问一个主机,发行用于身份验证的票据 - KDC - 整个 Kerberos 身份验证系统都处于风险之中。
- 若要让应用使用 Kerberos,必须修改其源才能对 Kerberos 库进行适当的调用。以这种方式修改的应用程序被视为可 识别 Kerberos。对于某些应用,由于应用或设计的大小,这可能会非常有问题。对于其他不兼容的应用,必须对服务器和客户端的通信方式进行更改。再强调一下,这可能需要进行大量的编程。默认情况下没有 Kerberos 支持的闭源应用程序通常是最令人烦恼的问题。
- 要通过 Kerberos 保护网络,必须使用 所有 客户端和服务器应用的 Kerberos 感知版本,这些客户端和服务器应用程序必须传输未加密的密码,或者根本不使用该客户端和服务器应用程序。
- 将用户密码从标准 UNIX 密码数据库(如
/etc/passwd
或/etc/shadow
)迁移到 Kerberos 密码数据库可能非常小心。没有可执行此任务的自动机制。迁移方法可能会有很大差异,具体取决于 Kerberos 的部署方式。这就是建议您使用身份管理功能的原因;它有专门的迁移工具和方法。
警告
如果网络上的用户通过以纯文本形式传输密码,对非 Kerberos 识别服务进行身份验证,则 Kerberos 系统可能会受到威胁。强烈建议使用非 Kerberos 感知服务(包括 telnet 和 FTP)。其他加密协议(如 SSH 或 SSL 保护的服务)优先于未加密的服务,但这仍然不理想。
11.1.6. Kerberos 的其他资源
Kerberos 可能是一项要实施的复杂服务,在部署方式上具有很大的灵活性。表 11.1 “外部 Kerberos 文档” 表 11.2 “重要的 Kerberos man page” 列出了一些最重要的或最有用的源,以了解有关使用 Kerberos 的更多信息。
Documentation | 位置 |
---|---|
Kerberos V5 安装指南(在 PostScript 和 HTML 中) | /usr/share/doc/krb5-server-version-number |
Kerberos V5 系统管理员指南(在 PostScript 和 HTML 中) | /usr/share/doc/krb5-server-version-number |
Kerberos V5 UNIX 用户指南(在 PostScript 和 HTML 中) | /usr/share/doc/krb5-workstation-version-number |
"Kerberos:网络身份验证协议"网页来自 MIT | http://web.mit.edu/kerberos/www/ |
设计身份验证系统:在四个 Scenes 中,最初由 44 年的 Bill Bryant 组成,于 2001 年由 Theodore Tso 修改。本文档是两个开发人员之间的对话,他们正考虑创建 Kerberos 风格的身份验证系统。对于完全不熟悉 Kerberos 的人而言,讨论方式使这一点是一个不错的起点。 | http://web.mit.edu/kerberos/www/dialogue.html |
使网络 Kerberos 感知的文章. | http://www.ornl.gov/~jar/HowToKerb.html |
任何手册页文件都可以通过运行 man command_name 打开。
manpage | Description |
---|---|
客户端应用程序 | |
kerberos | Kerberos 系统简介,该系统描述了凭据的工作原理,并提供获取和销毁 Kerberos 票据的建议。man page 的底部引用了多个相关的 man page。 |
kinit | 描述如何使用这个命令来获取和缓存一个票据获取和缓存。 |
kdestroy | 描述如何使用这个命令销毁 Kerberos 凭证。 |
klist | 描述如何使用这个命令列出缓存的 Kerberos 凭证。 |
管理应用程序 | |
kadmin | 描述如何使用这个命令来管理 Kerberos V5 数据库。 |
kdb5_util | 描述如何使用此命令在 Kerberos V5 数据库中创建和执行低级别管理功能。 |
服务器应用程序 | |
krb5kdc | 描述 Kerberos V5 KDC 的可用命令行选项。 |
kadmind | 描述 Kerberos V5 管理服务器可用的命令行选项。 |
配置文件 | |
krb5.conf | 描述在 Kerberos V5 库配置文件中提供的格式和选项。 |
kdc.conf | 描述 Kerberos V5 AS 和 KDC 配置文件中提供的格式和选项。 |