🌟想系统化学习内网渗透？看看这个：[内网安全] 内网渗透 - 学习手册-CSDN博客

0x01：Kerberos 协议简介

Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下，Kerberos 作为一种可信任的第三方认证服务，通过采用传统密码技术（如：共享密钥）来执行认证服务。

打一个浅显的例子，A 想要到 B 那里买东西，但是怕 B 收了钱不办事。此时，我们需要一个第三方机构 C 做担保，A 把钱给了 C，B 办完事后去 C 那里拿钱。Kerberos 协议就完成了这么一个操作。

0x02：Kerberos 协议的组成角色

在古希腊神话故事中，Kerberos 是一只具有三颗头颅的地狱恶犬，它守护在地狱之外，能够识别所有路过的亡灵，防止活着的入侵者闯入地狱：

Kerberos 协议中也存在三个角色，分别是：

• 客户端（Client）： 发送请求的一方。

• 服务端（Server）： 接收请求的乙方。

• 密钥分发中心（Key Distribution Center，KDC）： 该部分由两 AS 与 TGS 构成：

  • AS（Authentication Server）： 认证服务器，专门用来认证客户端的身份并发放客户端用于访问 TGS 的 TGT（允许买票的票据 — 票据授予票据）

  • TGS（Ticket Granting Ticket）： 票据授予服务器，用来执行整个认证过程以及发放客户端访问服务端时所需的服务授予票据（Ticket）

0x03：Kerberos 认证的类比流程

Kerberos 协议还是有些复杂的，所以本部分中，笔者将通过两个现实中的例子，让读者对 Kerberos 协议有一个大概的认识，为我们后面介绍 Kerberos 认证的完整流程打一个基础。

0x0301：Kerberos 类比流程 — 第三方购物

假设现在 A 要买 “电脑”，它知道 B 在卖（通过电视宣传啊），但是 AB 两人都没有见过面，现在 A 就在担心，我要是把钱直接给 B 了，B 翻脸不认人了怎么办，此时，A 就陷入了信任危机。

于是，A 想到了一个办法，它找到第三方机构 C（某东），C 机构认识 A 和 B，那么 A 就将钱交给了 C 机构，C 机构转告给 B 机构发货，等到 A 确认收货后，C 机构再把钱给 B。

上面这个例子，体现的是 Kerberos 的第三方认证特性，Kerberos 中的 KDC 在上面那里例子中就是充当 C 角色，A 就是 Client，B 就是 Server。但是上面这个例子并没有体现 KDC 中 “AS” 和 ”TGS“ 的用处，我们来看看下面这个例子。

0x0302：Kerberos 类比流程 — 乘坐过山车

假设你带着一家去做过山车，你不能直接去乘过山车，你得去售票处买票吧：

来到了售票处，你不光得有钱，你还得符合乘坐的标准吧（身高啥的），只有你都满足要求了，你才能花钱买到过山车的票，然后乘坐过山车：

在上面的那个流程中 ”你“ 就是 Client 端，”过山车“ 就是你申请的服务 Server。售票处（测量身高的阿姨 + 售票）构成了 KDC，你来到了 KDC，KDC 中的 AS 首先得校验你有没有购票资格，你有资格购票后，售票处（TGS）才能给你发放票据（Ticket）。

0x0303：Kerberos 认证流程简单概述

通过上面两个例子，相信读者对 Kerberos 已经有一个大致的认识了，这里笔者简单描述一下它的整体认证流程：客户端在访问每个想要访问的服务时，需要携带一个专门用于访问该服务并且能够证明自己身份的票据，当服务端收到了该票据他才能认定客户端身份正确，向客户端提供服务。

整个 Kerberos 认证流程可以简化为两大步：

1. 客户端向 KDC 请求获取想要访问的目标服务的服务授予票据（Ticket）。

2. 客户端拿着从 KDC 获取的服务授予票据（Ticket）访问相应的网络服务。

0x04：Kerberos 认证的完整流程

在前面类比流程中，笔者并没有详细讲 KDC 中 AS 和 TGS 的具体作用，那么在这里，笔者将详细讲解 Kerberos 认证的完整流程，并顺带介绍 AS 与 TGS 的作用。

0x0401：第一步 — 客户端与 AS 进行通信

为了获得能用来访问服务端服务的票据，客户端首先需要来到 KDC 获得服务授予票据（Ticket）。由于客户端是第一次访问 KDC，此时 KDC 也不能确认该客户端的身份，所以在第一次通信的时候 KDC 需要对客户端身份进行认证，确认客户端是一个可靠且拥有访问 KDC 权限的客户端。

第一步：Client 首先向 KDC 以明文方式发起请求，并在该次请求中携带了自己的用户名，主机 IP 和当前时间戳。

第二步：KDC 中的 AS （AS 是 KDC 中专门用来认证客户端身份的认证服务器）接收请求后去 Kerberos 认证数据库中根据用户名查找是否存在该用户（注意：此时只会查找是否有相同用户名的用户，并不会判断身份的可靠性）。

第三步：如果没有该用户名，则认证失败，服务结束；如果存在用户名，则 AS 认证中心便认为用户存在，此时便会返回相应给客户端，响应中包含两部分内容：

• 第一部分内容被称为（TGT），即 ”票据授予票据“。客户端后续需要使用 TGT 去 TGS（票据授予中心）获取访问网络服务所需的 Ticket（服务授予票据），TGT 中包含 Kerberos 数据库中存在的该客户端的 Name，IP，当前的时间戳，客户端即将访问的 TGS 的 Name，TGT 的有效时间以及一把用于客户端和 TGS 间进行的 Session_Key（CT_SK）。整个 TGT 使用 TGS 密钥加密，客户端是解密不了的，由于密钥从没有在网络中传输过，所以也不存在密钥被劫持破解的情况。

• 第二部分内容是使用客户端密钥加密的，其中包括用于客户端和 TGS 间通信的 Session_Key（CT_SK），客户端即将访问的 TGS 的 Name 以及 TGT 的有效时间，和一个当前的时间戳。该部分内容使用客户端加密，所以客户端在拿到该部分内容时可以通过自己的密钥解密。如果是一个假的客户端，那么他是不会拥有真正客户端的密钥的，因为该密钥也没在网络中进行传输过。这也同时认证了客户端的身份，如果是假客户端会由于解密失败而终止认证流程。

第一阶段的整体流程如下图所示：

0x0402：第二步 — 客户端和 TGS 进行通信

经过了第一步，Client 收到了来自 KDC（准确来说是 AS）的响应，并获取到了其中两部分的内容。此时客户端会用自己的密钥将第二部分内容解密，获取时间戳、自己将要访问的 TGS 的信息以及用于与 TGS 通信的密钥 CT_SK。Client 在获取上述信息后，会先根据时间戳判断该时间戳与自己发送请求时的时间之间的差值是否大于 5 分钟，如果大于五分钟则认为该 AS 是伪造的，认证失败。如果时间戳合理，客户端就会准备向 TGS 发起请求。客户端和 TGS 通信流程如下：

Client（客户端）行为：

1. 客户端使用 CT_SK 加密将自己的客户端信息发送给 KDC，其中包括客户端名，IP，时间戳。

2. 客户端将自己想要访问的 Server 服务以明文的方式发送给 KDC。

3. 客户端将使用 TGS 密钥加密的 TGT 也原封不动的携带给 KDC。

KDC 中的 TGS（票据授予服务器）行为：

1. TGS 收到了来自客户端的请求。首先根据客户端明文传输过来的 Server 服务 IP 查看当前 Kerberos 系统中是否存在可以被用户访问的对应服务。如果不存在，认证失败，如果存在，继续下一步。

2. TGS 使用自己的密钥将 TGT 中的内容进行解密，此时他看到了经过 AS 认证过后并记录的用户信息，CT_SK 以及时间戳信息，它会先根据时间戳判断此次通信是否真实可靠没有超出时延。

3. 如果时延正常，则 TGS 会使用 CT_SK 对客户端的第一部分内容进行解密（使用 CT_SK 加密的客户端信息），取出其中的用户信息和 TGT 中的用户信息进行比对，如果全部相同则认为客户端身份正确，可以进行下一步。

4. 此时，KDC（准确来说是 TGS）将返回一个 Ticket，该 Ticket 由两个部分组成：

   1. 第一部分，用于客户端访问网络服务的使用 Server 密码加密的 ST（Server Ticket），其中包括客户端的 Name，IP，需要访问的网络服务的地址 Server IP，ST 的有效时间，时间戳以及用于客户端和服务端之间通信的 CS_SK（Session Key）。

   2. 第二部分，使用 CT_SK 加密的内容，其中包括 CS_SK 和时间戳，还有 ST 的有效时间。由于在第一次通信过程中，AS 已将 CT_SK 通过客户端密码加密交给了客户端，且客户端解密并缓存了 CT_SK，所以该部分内容在客户端接收到时是可以自己解密的。

第二阶段整体流程如下图所示：

0x0403：第三步 — 客户端和服务端进行通信

经过前面两步，此时客户端收到了来自 TGS 的响应，并使用缓存在本地的 CT_SK 解密出了第二部分的内容（第一部分内容中的 ST 是由 Server 密码加密，客户端无法解密）。客户端在检验第二部分时间戳无误后取出其中的 CS_SK 准备向服务端发起最后的请求：

Client（客户端）行为：

客户端使用 CS_SK 将自己的主机信息和时间戳进行加密作为交给服务端的第一部分内容，然后将 ST（服务授予票据）作为第二部分内容都发送给服务端。

 Server（服务端）行为：

服务端收到来自客户端的请求，使用自己的密钥，将客户端发送来的 ST 部分进行解密，核对时间戳后将其中的 CS_SK 取出，使用 CS_SK 将客户端发来的第一部分内容进行解密，从而获得经过 TGS 认证过后的客户端信息，此时他将这部分信息和客户端第二部分内容带来的信息进行比对，最终确认客户端就是经过了 KDC 认证的具有真实身份的客户端，是他可以提供服务的客户端。

此时服务端会返回一段使用 CT_SK 加密的表示接收请求的响应给客户端，在客户端收到请求后，使用缓存在本地的 CS_SK 解密后也确认了服务端的身份。（其实服务端在通信过程中还会使用数字证书证明自己身份）。

至此，第三次通信完成，此时也代表整个 Kerberos 认证的完成，通信的双方都确认了对方的身份，此时便可以放心的进行整个网络通信了。第三阶段流程如下：

0x0404：Kerberos 认证完整流程图