w网站制作和推广企业微信电脑版

当前位置： 首页 > news >正文

w网站制作和推广,企业微信电脑版,网站被黑后怎么补救,马鞍山做公司网站的#x1f31f;想系统化学习内网渗透#xff1f;看看这个#xff1a;[内网安全] 内网渗透 - 学习手册-CSDN博客 0x01#xff1a;Kerberos 协议简介 Kerberos 是一种网络认证协议#xff0c;其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过… 想系统化学习内网渗透看看这个[内网安全] 内网渗透 - 学习手册-CSDN博客 0x01Kerberos 协议简介 Kerberos 是一种网络认证协议其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证无需基于主机地址的信任不要求网络上所有主机的物理安全并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下Kerberos 作为一种可信任的第三方认证服务通过采用传统密码技术如共享密钥来执行认证服务。 打一个浅显的例子A 想要到 B 那里买东西但是怕 B 收了钱不办事。此时我们需要一个第三方机构 C 做担保A 把钱给了 CB 办完事后去 C 那里拿钱。Kerberos 协议就完成了这么一个操作。 0x02Kerberos 协议的组成角色 在古希腊神话故事中Kerberos 是一只具有三颗头颅的地狱恶犬它守护在地狱之外能够识别所有路过的亡灵防止活着的入侵者闯入地狱 Kerberos 协议中也存在三个角色分别是 客户端Client 发送请求的一方。 服务端Server 接收请求的乙方。 密钥分发中心Key Distribution CenterKDC 该部分由两 AS 与 TGS 构成 ASAuthentication Server 认证服务器专门用来认证客户端的身份并发放客户端用于访问 TGS 的 TGT允许买票的票据 — 票据授予票据 TGSTicket Granting Ticket 票据授予服务器用来执行整个认证过程以及发放客户端访问服务端时所需的服务授予票据Ticket
0x03Kerberos 认证的类比流程 Kerberos 协议还是有些复杂的所以本部分中笔者将通过两个现实中的例子让读者对 Kerberos 协议有一个大概的认识为我们后面介绍 Kerberos 认证的完整流程打一个基础。 0x0301Kerberos 类比流程 — 第三方购物 假设现在 A 要买 “电脑”它知道 B 在卖通过电视宣传啊但是 AB 两人都没有见过面现在 A 就在担心我要是把钱直接给 B 了B 翻脸不认人了怎么办此时A 就陷入了信任危机。 于是A 想到了一个办法它找到第三方机构 C某东C 机构认识 A 和 B那么 A 就将钱交给了 C 机构C 机构转告给 B 机构发货等到 A 确认收货后C 机构再把钱给 B。 上面这个例子体现的是 Kerberos 的第三方认证特性Kerberos 中的 KDC 在上面那里例子中就是充当 C 角色A 就是 ClientB 就是 Server。但是上面这个例子并没有体现 KDC 中 “AS” 和 ”TGS“ 的用处我们来看看下面这个例子。 0x0302Kerberos 类比流程 — 乘坐过山车 假设你带着一家去做过山车你不能直接去乘过山车你得去售票处买票吧 来到了售票处你不光得有钱你还得符合乘坐的标准吧身高啥的只有你都满足要求了你才能花钱买到过山车的票然后乘坐过山车 在上面的那个流程中 ”你“ 就是 Client 端”过山车“ 就是你申请的服务 Server。售票处测量身高的阿姨 售票构成了 KDC你来到了 KDCKDC 中的 AS 首先得校验你有没有购票资格你有资格购票后售票处TGS才能给你发放票据Ticket。 0x0303Kerberos 认证流程简单概述 通过上面两个例子相信读者对 Kerberos 已经有一个大致的认识了这里笔者简单描述一下它的整体认证流程客户端在访问每个想要访问的服务时需要携带一个专门用于访问该服务并且能够证明自己身份的票据当服务端收到了该票据他才能认定客户端身份正确向客户端提供服务。 整个 Kerberos 认证流程可以简化为两大步 客户端向 KDC 请求获取想要访问的目标服务的服务授予票据Ticket。 客户端拿着从 KDC 获取的服务授予票据Ticket访问相应的网络服务。 0x04Kerberos 认证的完整流程 在前面类比流程中笔者并没有详细讲 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 数据库中存在的该客户端的 NameIP当前的时间戳客户端即将访问的 TGS 的 NameTGT 的有效时间以及一把用于客户端和 TGS 间进行的 Session_KeyCT_SK。整个 TGT 使用 TGS 密钥加密客户端是解密不了的由于密钥从没有在网络中传输过所以也不存在密钥被劫持破解的情况。 第二部分内容是使用客户端密钥加密的其中包括用于客户端和 TGS 间通信的 Session_KeyCT_SK客户端即将访问的 TGS 的 Name 以及 TGT 的有效时间和一个当前的时间戳。该部分内容使用客户端加密所以客户端在拿到该部分内容时可以通过自己的密钥解密。如果是一个假的客户端那么他是不会拥有真正客户端的密钥的因为该密钥也没在网络中进行传输过。这也同时认证了客户端的身份如果是假客户端会由于解密失败而终止认证流程。
第一阶段的整体流程如下图所示 0x0402第二步 — 客户端和 TGS 进行通信 经过了第一步Client 收到了来自 KDC准确来说是 AS的响应并获取到了其中两部分的内容。此时客户端会用自己的密钥将第二部分内容解密获取时间戳、自己将要访问的 TGS 的信息以及用于与 TGS 通信的密钥 CT_SK。Client 在获取上述信息后会先根据时间戳判断该时间戳与自己发送请求时的时间之间的差值是否大于 5 分钟如果大于五分钟则认为该 AS 是伪造的认证失败。如果时间戳合理客户端就会准备向 TGS 发起请求。客户端和 TGS 通信流程如下 Client客户端行为 客户端使用 CT_SK 加密将自己的客户端信息发送给 KDC其中包括客户端名IP时间戳。 客户端将自己想要访问的 Server 服务以明文的方式发送给 KDC。 客户端将使用 TGS 密钥加密的 TGT 也原封不动的携带给 KDC。 KDC 中的 TGS票据授予服务器行为 TGS 收到了来自客户端的请求。首先根据客户端明文传输过来的 Server 服务 IP 查看当前 Kerberos 系统中是否存在可以被用户访问的对应服务。如果不存在认证失败如果存在继续下一步。 TGS 使用自己的密钥将 TGT 中的内容进行解密此时他看到了经过 AS 认证过后并记录的用户信息CT_SK 以及时间戳信息它会先根据时间戳判断此次通信是否真实可靠没有超出时延。 如果时延正常则 TGS 会使用 CT_SK 对客户端的第一部分内容进行解密使用 CT_SK 加密的客户端信息取出其中的用户信息和 TGT 中的用户信息进行比对如果全部相同则认为客户端身份正确可以进行下一步。 此时KDC准确来说是 TGS将返回一个 Ticket该 Ticket 由两个部分组成 第一部分用于客户端访问网络服务的使用 Server 密码加密的 STServer Ticket其中包括客户端的 NameIP需要访问的网络服务的地址 Server IPST 的有效时间时间戳以及用于客户端和服务端之间通信的 CS_SKSession Key。 第二部分使用 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 认证的完成通信的双方都确认了对方的身份此时便可以放心的进行整个网络通信了。第三阶段流程如下 0x0404Kerberos 认证完整流程图