跳到内容跳到页面导航:上一页 [access key p]/下一页 [access key n]
documentation.suse.com / SUSE Linux Enterprise Desktop 文档 / 安全和强化指南 / 身份验证 / 使用 Kerberos 进行网络身份验证
适用范围 SUSE Linux Enterprise Desktop 15 SP6

6 使用 Kerberos 进行网络身份验证

Kerberos 是一个网络身份验证协议,同时还提供加密。本章介绍如何设置 Kerberos 以及集成 LDAP 和 NFS 等服务。

6.1 概念概述

除了通常的口令机制外,开放网络没有提供任何其他方法来确保工作站能够正确识别其用户。在一般的安装中,用户每次访问网络中的服务时都必须输入口令。Kerberos 提供了一种身份验证方法,采用这种方法,用户只要注册一次,就可在整个网络中获得信任以完成会话的剩余操作。要拥有安全的网络,必须满足以下要求:

  • 使所有用户可以对每个所需服务证明他们自己的身份,并确保任何用户都不能使用其他用户的身份。

  • 确保每个网络服务器也能证明其身份。否则攻击者就可能冒充服务器并获取传送给服务器的敏感信息。这种概念被称为相互身份验证,因为在客户端和服务器之间进行了相互身份验证。

Kerberos 通过提供严格加密的认证来帮助您满足这些要求。这里仅讨论 Kerberos 的基本原理。有关详细技术说明,请参见 Kerberos 文档。

6.2 Kerberos 术语

以下词汇表定义了 Kerberos 术语。

身份凭证

用户或客户端需要提供身份凭证才能获得授权来请求服务。Kerberos 支持两种身份凭证 - 票据和身份验证器。

票据

票据是随服务器而不同的身份凭证,客户端使用票据向它请求提供服务的服务器进行身份验证。它包含服务器的名称、客户端的名称、客户端的互联网地址、时戳、有效期和随机会话密钥。所有这些数据都使用服务器的密钥进行了加密。

身份验证器

身份验证器与票据结合使用,可用于证明提供票据的客户端确实与其声称的身份相符。身份验证器使用客户端的名称、工作站的 IP 地址和当前工作站的时间构建而成。所有这些信息都会通过只有客户端和相关服务器知道的会话密钥加密。与票据不同,身份验证器只能使用一次。客户端可以自己构建身份验证器。

主体

Kerberos 主体是可以对其分配票据的独特实体(用户或服务)。主体包含以下部分:

USER/INSTANCE@REALM
  • primary: 主体的第一个部分。对于用户而言,此部分与用户名相同。

  • instance(可选):: 描述 primary 特征的附加信息。此字符串与 primary 之间通过一个 / 分隔。

    tux@example.orgtux/admin@example.org 可以存在于同一个 Kerberos 系统上,它们被视为不同的主体。

  • realm:: 指定 Kerberos 领域。通常情况下,领域就是您的大写域名。

相互身份验证

Kerberos 确保客户端和服务器都可以确认对方的身份。它们共享一个可用来安全通讯的会话密钥。

会话密钥

会话密钥是由 Kerberos 生成的临时私用密钥。客户端知道这些密钥。当客户端向服务器请求并收到票据后,将使用这些密钥来加密客户端和服务器之间的通讯。

重放

几乎所有在网络中发送的消息都可能会被窃听、盗取和重发送。在使用 Kerberos 的情况下,如果攻击者获取了包含您的票据和身份验证器的服务请求,则会非常危险。攻击者随后可能会试图重新发送此请求(重放)来冒充您。然而,Kerberos 实施了多种机制来应对此问题。

服务器或服务

服务用来指要执行的特定操作。此操作幕后的进程称为服务器

6.3 Kerberos 的工作原理

Kerberos 常常被称为第三方可信身份验证服务,这意味着其所有客户端都信任 Kerberos 对另一个客户端身份的判断。Kerberos 保存着一个包含它的所有用户及其私用密钥的数据库。

为确保 Kerberos 正常工作,请在专用计算机上运行身份验证和票据授权服务器。确保只有管理员能直接或通过网络访问此计算机。将此计算机上运行的(网络)服务数目降到最低 — 甚至不要运行 sshd

6.3.1 首次联系

在首次接触 Kerberos 时,您的操作与在常规网络系统进行的任何登录过程类似。输入您的用户名。这一信息和票据授权服务的名称被发送到身份验证服务器 (Kerberos)。如果身份验证服务器知道您的身份,它会生成一个随机会话密钥,供以后在客户端和票据授权服务器之间使用。身份验证服务器现在将为票据授权服务器准备一个票据。该票据包含以下信息 - 仅认证服务器和票据授权服务器知道的、由会话密钥加密的所有信息:

  • 客户端和票据授权服务器的名称

  • 当前时间

  • 为此票据分配的有效期

  • 客户端的 IP 地址

  • 新生成的会话密钥

随后,还是以加密形式将此票据与会话密钥一起发送回客户端,但这次使用的是客户端的私用密钥。只有 Kerberos 和客户端知道此私用密钥,因为它是从您的用户口令派生的。由于客户端已经收到了此响应,计算机将提示您输入口令。此口令被转换为一个密钥,利用它可解密身份验证服务器所发送的包。然后拆封此包,并将口令和密钥从工作站的内存中删除。只要没有超过为用于获取其他票据的那个票据指定的有效期,工作站就能证明您的身份。

6.3.2 请求服务

要从网络中的任何服务器请求服务,客户端应用程序都需要向服务器证明其身份。因此,此应用程序生成一个身份验证器。身份验证器包含以下部分:

  • 客户端的主体

  • 客户端的 IP 地址

  • 当前时间

  • 校验和(由客户端选择)

所有这些信息都使用客户端为这个特殊服务器接收到的会话密钥进行了加密。用于服务器的身份验证器和票据会被发送到该服务器。该服务器使用自身的会话密钥副本来解密身份验证器,而身份验证器为它提供与请求其服务的客户端相关的全部所需信息,然后服务器将这些信息与票据中包含的信息进行对比。服务器将检查票据和身份验证器是否来自同一客户端。

如果在服务器端没有采取任何安全措施,则这个阶段的过程将成为重放攻击的理想目标。某些人可能试图重发先前从网络上窃取的请求。为防止出现这种情况,服务器将不接受具有先前已收到过的时间戳和票据的任何请求。忽略时间戳与接收请求时的时间相差太大的请求。

6.3.3 相互身份验证

Kerberos 身份验证可以双向使用。它不仅可以验证客户端是否为它所声称的客户端,服务器本身也应能够向请求其服务的客户端身份验证自己。因此,它本身会发送身份验证器。它将在客户端的身份验证器中接收的校验和加 1,然后使用它和客户端共享的会话密钥对其加密。客户端将此响应作为对服务器的真实性的校验,然后它们开始协作。

6.3.4 票据授权 - 联系所有服务器

票据每次仅供一个服务器使用。因此,每当您请求另一个服务时,就需要获取一个新票据。Kerberos 实施了一种机制来获取用于各个服务器的票据。这种服务被称为票据授权服务。票据授权服务与前面提到的任何服务一样,也使用已介绍过的那些访问协议。当应用程序需要一个尚未请求过的票据时,就会联系票据授权服务器。此请求包含以下部分:

  • 被请求的主体

  • 票据授权票据

  • 认证器

与任何其他服务器一样,票据授权服务器现在将检查票据授权票据和身份验证器。如果确定它们有效,票据授权服务器将构建一个将在原始客户端和新服务器之间使用的新会话密钥。然后构建用于新服务器的票据,其中包含以下信息:

  • 客户端的主体

  • 服务器的主体

  • 当前时间

  • 客户端的 IP 地址

  • 新生成的会话密钥

新票据具有一个有效期,该有效期是票据授权票据的剩余有效期,或服务的默认有效期。系统将分配这两个值中较小的一个。客户端会接收票据授权服务发送的此票据和会话密钥。但这一次,响应已通过原始票据授权票据附带的会话密钥加密。当联系新服务时,客户端可以解密此响应而不需要用户的口令。因此,Kerberos 无需烦扰用户就能获取客户端的一个又一个票据。

6.4 Kerberos 的用户视图

理想情况下,用户与 Kerberos 的唯一接触是在工作站登录时发生的。登录进程包括获得一个票据授权票据。注销时,用户的 Kerberos 票据会自动损坏,这样其他人就不能模仿该用户。

当用户的登录会话持续时间超过为票据授权票据指定的最长时间限制(合理的设置是 10 小时)时,票据的自动失效可能会造成某种不便。但用户可以通过运行 kinit 来获得一个新的票据授权票据。再次输入口令,Kerberos 无需附加身份验证即可获得对所需服务的访问。要获得由 Kerberos 为您静默获取的所有票据的列表,请运行 klist

下面的短列表列出了使用 Kerberos 身份验证的应用程序。在安装软件包 krb5-apps-clients 后,可以在 /usr/lib/mit/bin/usr/lib/mit/sbin 下找到这些应用程序。它们拥有普通 Unix 和 Linux 应用程序的所有功能,同时具有 Kerberos 所管理的透明身份验证的优势:

  • telnettelnetd

  • rlogin

  • rsh, rcp, rshd

  • ftpftpd

您不再需要输入口令即可使用这些应用程序,因为 Kerberos 已证明您的身份。如果为其编译了 Kerberos 支持,ssh 甚至可以将为一个工作站获取的所有票据转发到另一个工作站。如果您使用 ssh 登录到另一个工作站,ssh 将确保票据的加密内容会根据新情况而调整。仅在工作站之间复制票据是不够的,因为票据中包含工作站特定信息(IP 地址)。XDM 和 GDM 也提供 Kerberos 支持。https://web.mit.edu/kerberos 上的 Kerberos V5 UNIX User's Guide 中详细介绍了 Kerberos 网络应用程序。

6.5 Kerberos 和 NFS

大多数 NFS 服务器都可以使用默认信任网络形式的安全性(称为 sec=sys)和基于 Kerberos 的三个不同安全性级别(sec=krb5sec=krb5isec=krb5p)的任意组合来导出文件系统。sec 选项设置为客户端上的挂载选项。一种常见的情况是先配置 NFS 并将其与 sec=sys 配合使用,然后便可以实施 Kerberos。在这种情况下,服务器有可能会配置为同时支持 sec=sys 以及某种 Kerberos 级别,在转换所有客户端后,再去除 sec=sys 支持,从而实现真正的安全性。转换到 Kerberos 的过程应该透明(如果有序进行)。但是,如果使用了 Kerberos,NFS 的行为会出现细微的差别,您需要了解并解决这种差别造成的影响。请参见第 6.5.1 节 “组成员资格”

三种 Kerberos 级别表示不同的安全级别。安全性越高,加密和解密消息所需的处理器资源就越多。在计划对 NFS 实施 Kerberos 时,选择适当的平衡是一个重要考虑因素。

krb5 仅提供身份验证。服务器知道谁发送了请求,而客户端知道服务器发送了答复。它不会为请求或答复的内容提供安全性,因此获得物理网络访问权限的攻击者可能会以各种方式转换请求和/或答复,以欺骗服务器或客户端。他们不能直接读取或更改经过身份验证的用户所不能读取或更改的任何文件,但从理论上说,任何事情几乎都有可能发生。

krb5i 针对所有消息添加完整性检查。使用 krb5i 时,攻击者无法修改任何请求或答复,但可以查看所有交换的数据,因此可能会看到所读取的任何文件的内容。

krb5p 为协议添加隐私性。除了可靠的身份验证和完整性检查外,消息还会完全加密,这样攻击者只能知道在客户端与服务器之间交换了消息,但不能直接从消息中提取其他信息。能否从消息计时中提取信息是 Kerberos 无法解决的另一个问题。

6.5.1 组成员资格

sec=sys 与 Kerberos 安全性级别之间的一个行为差异(用户或许可以察觉到)与组成员资格相关。在 Unix 和 Linux 中,每个文件系统访问请求都来自某个进程,该进程由特定的用户拥有,并具有特定的组拥有者和多个补充组。对文件的访问权限因拥有者和组而异。

在每个请求中,使用 sec=sys 将 user-id、group-id 以及最多包含 16 个补充组的列表发送到服务器。

如果某个用户是 16 个以上的补充组的成员,超额的组将会丢失,并且在正常情况下用户本应可以访问的文件可能无法通过 NFS 访问。因此,使用 NFS 的大多数站点会通过某种方法将所有用户限制为最多 16 个补充组。

如果用户运行 newgrp 命令或运行 set-group-id 程序,并且该命令或程序可以更改用户所属的组列表,则这些更改会立即生效,并通过 NFS 提供不同的访问权限。

使用 Kerberos 时,请求中不会发送组信息,只会标识用户(使用 Kerberos 主体),服务器将执行查找来确定该主体的用户 ID 和组列表。这意味着,如果用户是 16 个以上的组的成员,则会使用这些组成员资格来确定文件访问权限。但也意味着,如果用户在客户端上更改 group-id,服务器将不会注意到这种更改,并且在确定访问权限时也不会将其纳入考量。

在提供对更多组的访问方面所做的改进能够带来真正的好处,而无法更改组所带来的损失不会被注意到,因为这种做法不太常用。考虑使用 Kerberos 的站点管理员应了解这种差异,并应确保它不会造成问题。

6.5.2 性能和可伸缩性

利用 Kerberos 提高安全性需要使用额外的 CPU 资源来加密和解密消息。需要多少额外的 CPU 资源以及差异是否明显取决于所用的硬件和应用程序。如果服务器或客户端已用尽了可用的 CPU 资源,在从 sec=sys 切换到 Kerberos 时,可能会出现相当严重的性能下降。如果还有富余的 CPU 容量,则这种过渡可能不会导致任何吞吐量变化。确定使用 Kerberos 所造成的影响大小的唯一方式是在硬件上测试您的负载。

可以减轻负载的配置选项同时也会降低提供的保护质量。sec=krb5 产生的负载应该明显低于 sec=krb5p,但如前所述,它不能带来强大的安全性。类似地,您可以调整可供 Kerberos 从中选择的口令列表,而这可能会改变 CPU 的要求。但是,默认值是经过精心选择的,如未经过非常谨慎的考虑,不应更改这些值。

将 NFS 配置为使用 Kerberos 时可能存在的另一个性能问题涉及到 Kerberos 身份验证服务器(称为 KDC 或密钥分发中心)的可用性。

使用 NFS 会增大此类服务器的负载,程度与对任何其他服务使用 Kerberos 时所增大的负载相同。每当给定的用户(Kerberos 主体)与服务建立会话时(例如,通过访问特定 NFS 服务器导出的文件),客户端就需要与 KDC 协商。协商会话密钥后,客户端与服务器在许多个小时内(此时段取决于 Kerberos 配置的细节,具体而言取决于 ticket_lifetime 设置)无需进一步的帮助即可通讯。

最有可能影响 Kerberos KDC 服务器置备的因素是可用性和峰值用量。

与其他核心服务(例如 DNS、LDAP)或类似的名称查找服务一样,使用两个距离每个客户端都比较的服务器能够在资源有限时提供较佳的可用性。Kerberos 允许使用多个具有灵活模型的 KDC 服务器来进行数据库传播,因此,在校园、建筑物甚至机柜周围按需排布服务器的工作相当简单。确保每个客户端都查找附近的 Kerberos 服务器的最佳机制是对每个建筑物(或类似设施)使用水平分割 DNS 来从 DNS 服务器获取不同的细节。如果这种方法不可行,也可采用在不同的位置管理不同的 /etc/krb5.conf 文件这种替代做法。

由于对 Kerberos KDC 的访问并不频繁,只有在高峰时间,负载才可能会成为一个问题。如果数千人都在 9:00 到 9:05 登录,则服务器每分钟收到的请求数就会比在午夜收到的要多得多。Kerberos 服务器上的负载可能会超过 LDAP 服务器,但不会有数量级的差异。较为合理的准则是采用置备 LDAP 复本的相同方式来置备 Kerberos 复本,然后监控性能以确定需求是否超过容量。

6.5.3 主 KDC、多个域和信任关系

Kerberos KDC 的一项不容易分散运行的服务是更新处理,例如口令更改和新用户的创建。这些操作必须在单个主 KDC 上进行。

这些更新不太可能会以很高的频率发生,因而不会产生任何繁重负载,但可能出现可用性方面的问题。创建新用户或更改口令可能很麻烦,并且地球另一端的主 KDC 有时会暂时不可用。

如果组织分布于不同地理位置并且其政策规定在每个站点本地处理管理任务,创建多个 Kerberos 域(为每个管理中心创建一个)可能会是比较好的做法。这样每个域都会有位于本地的自己的主 KDC。通过在域之间设置信任关系,一个域中的用户仍可访问另一个域中的资源。

要安排多个域,最轻松的方法是使用一个全局域(例如 EXAMPLE.COM)和本地域(例如 ASIA.EXAMPLE.COM、EUROPE.EXAMPLE.COM)。如果全局域配置为信任每个本地域,并且每个本地域配置为信任全局域,则任何一对域之间都将具有完全可传递的信任,并且任何主体都可以与任何服务建立安全连接。如何确保对资源(例如该服务提供的文件)的适当访问权限取决于所用的用户名查找服务,以及 NFS 文件服务器的功能,这不在本文档的范畴内。

6.6 更多信息

MIT Kerberos 的官方网站是 https://web.mit.edu/kerberos。因此,找出任何有关 Kerberos(包括 Kerberos 安装、用户和管理指南)的任何其他相关资源的链接。

Brian Tung 编著的 Kerberos — 网络认证系统一书 (ISBN 0-201-37924-4) 提供了深入和全面的信息。