内网渗透：域 Kerberos 认证机制

1. Kerberos 协议简介

Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户端/服务器应用程序提供强大的认证服务。

该协议具有以下特点：

去中心化：认证过程独立于主机操作系统，不依赖基于主机地址的信任。
安全传输：假定网络上数据包可能被任意读取、修改或插入，仍能保证通信安全。
第三方信任：通过可信第三方（即密钥分发中心，KDC）实现认证。

在 Kerberos 的场景中，客户端和服务端需要通过 KDC 来验证彼此身份，避免传统网络通信中“无法证明自己是自己”的问题。

2. Kerberos 协议角色组成

在古希腊神话中，Kerberos 是一只拥有三颗头颅的地狱恶犬，守护着冥界的入口。他能够识别所有经过的亡灵，并防止任何活着的入侵者进入地狱。

在这里插入图片描述
与其神话形象类似，在 Kerberos 协议中也有三个关键角色，共同协作完成认证与授权任务：

客户端（Client）：发起服务请求的一方，通常是用户或应用程序。
服务端（Server）：提供具体服务的一方，例如数据库或文件共享系统。
密钥分发中心（Key Distribution Center, KDC）：协议的核心组件，负责身份认证与票据分发，由以下两部分组成：
- 认证服务器（Authentication Server, AS）：负责验证客户端的身份，并颁发票据授予票据（Ticket Granting Ticket, TGT）。
- 票据授予服务器（Ticket Granting Server, TGS）：基于 TGT 为客户端生成访问服务端所需的服务票据（Service Ticket, ST）。

3. Kerberos 协议认证流程

在传统的网络认证机制中，仅依靠账号密码进行验证往往难以满足安全需求，设备之间容易陷入“无法证明自己身份”的困境。这种情况下，客户端与服务端都无法建立彼此的信任关系。为了解决这一问题，Kerberos 协议设计了一套以密钥分发中心为核心的认证机制，通过引入第三方信任机构，协调整个认证流程，确保客户端与服务端在通信中均能验证对方身份，从而建立起安全可靠的信任链路。认证流程分为以下三步：

客户端与 AS 通信
客户端向 AS 提供身份信息（例如用户名和加密时间戳），AS 验证身份后返回一张票据授予票据（TGT）。
客户端与 TGS 通信
客户端使用 TGT 向 TGS 申请服务票据（ST），以访问特定服务端。TGS 验证后颁发 ST。
客户端与服务端通信
客户端使用 ST 与服务端建立会话，完成最终的身份验证。

在这里插入图片描述

Kerberos 协议形象化解析

为了便于理解，可以将 Kerberos 的认证过程类比为去动物园游玩购票的场景：

第一步：验证身份

客户端就像游客，首先需要拿着身份证（用户名和密码）前往安检窗口（AS），验证自己的身份。

如果认证成功，AS 会颁发一张“购票资格票”（Ticket Granting Ticket, TGT），这张票证明你有权购买动物园的入场票，但不能直接用它进园。

第二步：获取服务票据

游客拿着 TGT 来到售票窗口（Ticket Granting Server, TGS），申请购买动物园的门票。

TGS 检查 TGT 的有效性后，为游客颁发一张“动物园入场票”（Service Ticket, ST）。

第三步：进入动物园

游客拿着 ST，来到动物园的入口。工作人员（服务端）验证 ST 的有效性后，允许游客入园游玩。

4. Kerberos 认证 - 客户端与 AS 通信原理

客户端向 AS 发送身份信息（AS-REQ 数据包），其中包括用户名和加密的时间戳。
AS 验证身份信息并返回 TGT（AS-REP 数据包）。TGT 包括以下内容：
- 客户端信息（用户名、IP、时间戳等）。
- 用用户的 HASH 值加密的部分。
- 用 KDC 秘钥（krbtgt 的 HASH）加密的部分。

客户端解密收到的 TGT 后，保存以供后续通信使用。

AS发过来的TGT：
在这里插入图片描述

用户解密后重新封装的TGT：

5. Kerberos 认证 - 客户端与 TGS 通信原理

客户端携带 TGT 向 TGS 发送请求（TGS-REQ 数据包），请求访问某个服务。
TGS 验证 TGT，并返回服务票据 ST（TGS-REP 数据包）。ST 的结构包括：
- 客户端信息（用户名、IP、时间戳等）。
- 用客户端与服务端共享密钥（CS_SK）加密的内容。
- 用服务端 HASH 值加密的内容。

客户端收到 ST 后解密并保存。

TGS发送过来的ST：

客户端重新封装的ST：