★ FEATURED ARTICLE 简介这份资源围绕PPTP协议展开面向网络安全初学者与渗透测试入门者提供从环境搭建到抓包分析再到密码破解的完整实验链路适合作为课程实验或自学练手的参考材料。压缩包共12个文件约3.7MB包含6个Python脚本、2个pcapng抓包文件、2份docx实验文档和2份txt说明脚本用于辅助分析与破解流程抓包文件保留真实通信过程文档则记录实验步骤与结论。已有959人学习下载说明该实验在同类学习中具有一定参考价值。读者可据此复现PPTP服务端与客户端环境对照抓包理解PPTP控制连接与数据封装过程并借助脚本完成基于信息的密码破解验证同时从文档中获取实验组织思路与结果分析框架形成从原理到实操的闭环认识。1. PPTP 的握手为什么只有两步一个被误解了二十年的隧道协议很多人第一次抓 PPTP 的包都会愣一下整个隧道建立过程短得离谱TCP 1723 上几条控制消息来回一趟GRE 协议号 47 的隧道就通了。没有证书交换没有 DH 密钥协商没有加密套件谈判——这跟后来那些动辄十几个往返的隧道协议完全不是一个画风。于是「PPTP 不安全」成了一句口头禅但真正能说清它为什么不安全、不安全到什么程度、在什么场景下这个结论才成立的人并不多。这份资源把 PPTP 从协议字段、环境搭建、抓包分析一路拆到认证破解价值不在于教你配一个早已过时的服务而在于它提供了一个极小的完整样本一个隧道协议需要哪些最小构件这些构件各自承担什么职责以及当某个构件被刻意简化时整条信任链会从哪里开始塌。搞懂这个样本再去看任何现代隧道协议你都能一眼定位它的密钥协商在哪、完整性保护在哪、抗重放在哪。源码软件和实验报告两种形态并存意味着它既能跑起来看现象也能对着报文逐字段核对。2. 控制连接与数据连接为什么 PPTP 要拆成两条通道2.1 TCP 1723 只负责「说话」GRE 才负责「搬货」PPTP 最容易被忽略的设计是控制面与数据面分离。控制连接走 TCP 1723承载的是呼叫建立、链路控制、呼叫清除这几类消息真正的用户数据封装在 GREIP 协议号 47里传输。这个拆分不是随意的它对应两种完全不同的可靠性需求控制消息要求可靠有序丢了要重传所以用 TCP数据报文要求低开销每个包都带 TCP 头做确认会让隧道吞吐塌掉所以用 GRE 这种轻量封装。常见的实现思路是服务端在 1723 上监听收到 Start-Control-Connection-Request 后回 Response双方交换协议版本和承载能力随后客户端发 Outgoing-Call-Request指定 Call ID、最大接收窗口等参数服务端回 Connected 并分配自己的 Call ID。这两个 Call ID 之后会写进每一个 GRE 头里用来在多条隧道共存时区分归属。控制消息类型Message Type 字段 1 Start-Control-Connection-Request 2 Start-Control-Connection-Reply 7 Outgoing-Call-Request 8 Outgoing-Call-Reply 12 Call-Clear-Request 15 Stop-Control-Connection-Request关键在于控制连接建立完成并不等于隧道可用。真正决定数据能不能过的是 GRE 那条路而 GRE 本身是无连接、无确认的。所以你会看到一个现象TCP 1723 握手一切正常但 ping 不通内网——问题往往出在 GRE 被中间设备丢弃而不是认证失败。这个区分是排查的第一道分水岭。2.2 GRE 头里的 Call ID 与序号字段GRE 头在 PPTP 场景下有一个增强版本除了标准的标志位和协议类型还额外带了 Payload Length、Call ID、Sequence Number、Acknowledgment Number 四个字段。Call ID 是隧道的身份标识收发双方各持一个序号和确认号用于流控和丢包检测但因为 GRE 本身不重传它们只起到「告诉对端我收到哪了」的作用。这里有个血泪经验不少实现会把 Acknowledgment Number 当成可靠传输的凭据实际上它只是窗口管理的参考值。如果对端长时间不确认发送方可能降低发送速率但不会重发丢失的包。上层 TCP 会自己处理重传所以用户感知不到但如果跑的是 UDP 业务丢包就是实打实地丢了。理解这一点才能解释为什么同样的链路跑网页正常、跑实时音视频就卡。2.3 封装层次从 PPP 帧到外层 IP数据路径的封装顺序是用户 IP 包 → PPP 帧带协议字段和可选的加密/压缩→ GRE 头 → 外层 IP 头 → 链路层。PPP 层是 PPTP 名字的来源也是认证发生的地方。PAP、CHAP、MS-CHAPv2 都在 PPP 的链路控制协议LCP和认证协议阶段完成。这个层次结构决定了一个重要事实加密发生在 PPP 层而不是 GRE 层。也就是说GRE 头和外层 IP 头是明文可见的只有 PPP 载荷被保护。抓包时你能直接看到两端地址、Call ID、包长这些元数据不加密。很多「PPTP 泄露信息」的说法指的就是这部分元数据暴露而不是载荷被破。3. 认证协商MS-CHAPv2 的挑战应答是怎么被绕过的3.1 从 PAP 到 MS-CHAPv2 的演进动机PAP 是最朴素的方案客户端直接把用户名密码明文发给服务端。它的存在意义只有一个——兼容那些不支持挑战应答的老客户端。CHAP 引入挑战值服务端发随机数客户端用密码做哈希后回传避免明文传输。MS-CHAPv2 在此基础上做了双向认证不仅服务端验证客户端客户端也验证服务端理论上能防中间人。设计动机是合理的问题出在实现细节。MS-CHAPv2 的响应计算依赖 NT-HashMD4 对 Unicode 密码而 NT-Hash 本身没有加盐、没有迭代计算速度极快。更关键的是整个握手过程中传递的挑战值和响应值构成了一个可离线穷举的方程组。3.2 挑战应答的数学结构客户端收到的挑战是服务端生成的 16 字节 AuthenticatorChallenge加上自己生成的 16 字节 PeerChallenge拼成 24 字节的 Challenge。响应计算大致是NT-Hash MD4(UTF-16LE(password)) Hash1 MD4(NT-Hash 21字节零填充) Challenge MD4(PeerChallenge AuthenticatorChallenge username) Response DES-Encrypt(Hash1 拆成的三个 7 字节密钥, Challenge)注意最后一步24 字节的 Hash1 被拆成三段 7 字节每段作为 DES 密钥去加密同一个 8 字节 Challenge得到 24 字节响应。DES 的密钥空间是 56 位三段独立所以理论上可以分段穷举。这就是后来那些破解工具的核心思路——不是攻破 DES而是利用 NT-Hash 无盐、DES 密钥空间小、挑战值已知这三个条件叠加。3.3 为什么「双向认证」没有救回来MS-CHAPv2 的客户端验证服务端靠的是服务端回传的 AuthenticatorResponse它由服务端的 NT-Hash 和客户端挑战计算得出。问题在于攻击者只要拿到一次完整的握手挑战、响应、服务端响应就可以离线同时穷举两边的密码。双向认证在这里变成了「双向泄露」——它没有增加攻击成本反而多给了一份可验证的样本。我一般会这么理解任何依赖「密码哈希直接作为密钥材料」的挑战应答协议只要哈希函数快、无盐、密钥空间小就注定扛不住离线穷举。MS-CHAPv2 三个条件全占。这不是实现 bug是设计层面的取舍——当年为了兼容现有密码库和计算能力选择了低成本方案代价是安全边界被压到很低。4. 抓包分析从报文里读出隧道的完整生命周期4.1 抓包点的选择决定你能看到什么抓 PPTP 有个前提抓包位置必须在 GRE 封装之外。如果在隧道内部的虚拟网卡上抓你看到的是解封装后的原始 IP 包看不到 GRE 头和 PPP 层要分析协议行为得在物理网卡或外层接口上抓。这一点在实验报告里经常被写错导致抓到的包「看不出隧道」。推荐的做法是同时抓两个点外层接口看控制消息和 GRE 封装内层虚拟接口看业务流量。两边对照才能把「控制面动作」和「数据面效果」对应起来。比如你在外层看到 Call-Clear-Request内层流量随即中断这就验证了控制连接对数据通道的管理关系。4.2 用过滤器把三类流量分开PPTP 的流量可以按协议分成三类过滤表达式要分开写# 控制连接TCP 1723 tcp port 1723 # GRE 封装IP 协议号 47 ip proto 47 # PPP 层认证在解封装后可见需在内层接口抓 ppp # 组合过滤只看某对地址之间的隧道流量 host 192.0.2.10 and host 192.0.2.20 and (tcp port 1723 or ip proto 47)第一条看握手第二条看数据第三条看认证协商。分开抓的好处是每类流量的时序关系清晰不会被混杂的包淹没。实际排查时先确认 1723 有完整握手再确认 47 有双向流量最后才去看认证是否成功——顺序反了容易误判。4.3 从时序图读出失败点一个典型的失败场景是TCP 1723 三次握手成功Start-Control-Connection 交换正常Outgoing-Call 也回了 Connected但之后 GRE 方向没有任何包。这说明控制面通了、数据面没通。原因可能是中间设备过滤了协议号 47也可能是服务端 GRE 模块没加载。另一个场景是GRE 有包但 PPP 的 LCP 阶段反复重传 Configure-Request始终收不到 Configure-Ack。这通常指向 PPP 层参数不匹配比如 MRU 协商失败或认证协议不一致。抓包时看 LCP 包的 Options 字段能直接定位是哪一项没谈拢。提示分析 PPTP 抓包时先按「控制连接 → GRE 通道 → PPP 协商 → 认证 → 数据」五段拆时序任何一段缺失都对应一类明确的故障域比逐包看效率高得多。5. 环境搭建与破解实验把信任链的断点跑出来5.1 最小实验环境的构成搭建 PPTP 实验环境核心是三个角色客户端、服务端、中间观察点。服务端需要支持 PPP 和 GRE客户端需要能发起 PPTP 连接观察点负责抓包。在虚拟化环境里把三者放在同一网段最省事避免 NAT 对 GRE 的干扰——GRE 没有端口概念很多 NAT 实现处理不了这是搭建时最常见的翻车点。配置服务端时重点确认两件事GRE 模块是否可用PPP 的认证方式是否按预期配置。如果服务端同时开了 PAP 和 MS-CHAPv2客户端可能优先选 PAP导致你以为在测 MS-CHAPv2 实际测的是明文认证。实验报告里要明确记录协商结果而不是只看配置。5.2 破解实验的正确姿势破解实验的目的不是拿到某个密码而是验证「离线穷举可行」这个结论。流程是抓一次完整握手提取挑战值、响应值、用户名然后用字典对候选密码逐个计算 NT-Hash、走一遍响应算法、比对结果。整个过程不需要再和服务端交互这就是「离线」的含义。import hashlib def nt_hash(password: str) - bytes: # NT-Hash密码转 UTF-16LE 后做 MD4 return hashlib.new(md4, password.encode(utf-16-le)).digest() def challenge_hash(peer_chal: bytes, auth_chal: bytes, username: str) - bytes: # 拼接顺序固定PeerChallenge AuthenticatorChallenge 用户名 data peer_chal auth_chal username.encode(utf-8) return hashlib.new(md4, data).digest() def verify(password: str, peer_chal, auth_chal, username, expected_response) - bool: h nt_hash(password) # Hash1NT-Hash 补零到 21 字节后再哈希 hash1 hashlib.new(md4, h b\x00 * 21).digest() chal challenge_hash(peer_chal, auth_chal, username) # 三段 7 字节 DES 密钥分别加密同一挑战值此处省略 DES 调用 response des_encrypt_three_keys(hash1, chal) return response expected_response这段代码的关键不在 DES 实现而在三个输入全部来自抓包peer_chal、auth_chal、expected_response 都是明文可见的。字典里每个候选密码走一遍 verify命中即得。计算量取决于字典大小和单次哈希成本NT-Hash 是单次 MD4速度极快这就是为什么弱密码在这种结构下几乎没有抵抗力。5.3 实验报告该记录什么一份有价值的实验报告记录的不是「破解成功」这个结果而是成本曲线字典规模与耗时关系、密码复杂度对命中率的影响、以及同样条件下换成加盐迭代哈希后成本如何变化。最后一组对照最有说服力——它把「协议设计缺陷」和「密码强度不足」两个因素分离开让你看清哪一部分是协议该负责的、哪一部分是运维该负责的。6. 避坑与排查五个真实会踩的坑6.1 GRE 不通但 1723 正常现象控制连接握手完整Outgoing-Call 返回 Connected但隧道内无任何流量。原因中间设备或防火墙按协议号过滤了 47或者服务端 GRE 模块未加载。解决在两端分别抓包确认 GRE 包是否发出、是否到达检查防火墙规则是否放行 ip proto 47确认内核模块状态。6.2 NAT 环境下隧道时通时断现象同一客户端有时能连上有时卡在认证阶段。原因GRE 没有端口NAT 设备无法用端口区分多条隧道映射表项冲突或超时。解决实验环境尽量避免 NAT或使用支持 GRE 穿透的设备排查时对比 NAT 前后的抓包看 Call ID 是否被改写。6.3 认证方式被静默降级现象配置了 MS-CHAPv2但抓包看到的是 PAP 明文。原因客户端与服务端协商时选择了双方都支持的最低共同项或服务端配置顺序导致优先 PAP。解决抓 PPP 的 LCP 和认证阶段包确认实际协商的协议服务端显式禁用 PAP只保留目标认证方式。6.4 抓包位置错误导致「看不到隧道」现象抓包文件里全是普通 IP 包没有 GRE 头。原因抓包点选在了隧道内部的虚拟接口解封装已经完成。解决改到外层物理接口抓或同时抓内外两个点做对照确认接口的封装状态。6.5 破解脚本算不出结果现象字典里明明有正确密码verify 始终返回 False。原因挑战值拼接顺序错误、用户名大小写或编码不一致、NT-Hash 的 UTF-16LE 转换有误。解决用一组已知密码自测算法链路逐段比对中间值确认抓包提取的字段字节序和拼接顺序与协议一致。7. 设计取舍为什么这个协议注定只能当教学样本把 PPTP 拆完会发现它的每一个「弱点」背后都有一个当年的合理性。控制面用 TCP、数据面用 GRE是为了在拨号时代兼顾可靠信令和低开销转发认证选 MS-CHAPv2是为了兼容已有的密码体系和有限的计算能力加密放在 PPP 层是为了复用 PPP 的成熟框架。单看每一处都是工程妥协合起来看信任链的每一环都建立在「密码哈希即密钥」这个假设上而这个假设在离线穷举面前站不住。设计点当年的动机今天的代价无密钥协商密钥源自密码哈希兼容现有认证体系实现简单无前向保密密码泄露即全泄露MS-CHAPv2 挑战应答避免明文传输双向认证握手样本可离线穷举GRE 无连接无确认低开销转发丢包靠上层元数据明文暴露加密在 PPP 层复用 PPP 框架外层头信息不受保护验证一个隧道协议是否可靠我习惯看三件事密钥是不是经过独立协商、有没有前向保密、完整性保护覆盖到哪一层。PPTP 三项都不满足所以它的定位只能是教学样本——用最小的复杂度把「隧道协议需要什么」讲清楚再用它的失败反推现代协议为什么长成那样。从那以后我每次评估一个隧道或加密协议都强制走一遍「密钥从哪来、泄露后影响多大、完整性保护覆盖到哪」这三问而不是先看它用了什么算法。算法强度是最后一步密钥生命周期才是第一道防线。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
