前面讲的 Web 漏洞都在应用层，但攻击可以发生在更底层。这一篇把网络层/传输层/应用层几个经典协议攻击过一遍：ARP 欺骗、SYN 泛洪、FTP 攻击、SSL 组件漏洞。理解它们，才能既懂”怎么被打”也懂”怎么防”。
以下仅在授权实验环境（如内网靶场、GNS3 模拟）练习；对他人网络发起此类攻击属违法，可能构成破坏计算机信息系统罪。
ARP 欺骗：局域网里的”假快递员”
原理：ARP 协议负责”IP → MAC”的映射，且默认信任广播答复、无认证。局域网里，攻击者不断告诉目标”我是网关”（骗目标把流量发给我），同时告诉网关”我是目标”。于是目标↔网关的流量都经过攻击者，可窃听、篡改（中间人）。
危害：
- 嗅探明文流量（FTP、HTTP 密码）；
- 会话劫持、注入；
- 结合 DNS 欺骗把用户引到假网站。
工具：arpspoof、ettercap、bettercap。
防御：
- 静态 ARP 绑定（网关 MAC 写死）；
- 交换机端口安全 / DHCP Snooping + 动态 ARP 检测（DAI）；
- 全网用 HTTPS（即使被嗅探也看不懂）；
- 网络分段、802.1X 认证。
SYN 泛洪：把连接队列打满
原理：TCP 三次握手，服务器收到 SYN 后要开半连接队列等 ACK。攻击者发大量伪造源 IP 的 SYN，不回 ACK，服务器的半连接队列被占满，正常用户连不上——这是典型的 DoS（拒绝服务）。
危害：服务器无法接受新连接，服务瘫痪。
防御：
- SYN Cookie（不在服务端存半连接，用算法验证 ACK 合法性）；
- 增大队列、限速、过滤伪造源；
- 上游清洗/抗 DDoS 设备、CDN。
延伸：UDP 泛洪、ICMP 泛洪、HTTP 慢速攻击（Slowloris）都是同类思路——用资源消耗让服务不可用。
FTP 攻击：明文协议的旧伤
原理：FTP 默认明文传输用户名密码和数据；且主动/被动模式涉及额外端口，配置不当易出问题。
危害与手法：
- 口令嗅探：局域网内抓包直接拿到 FTP 账号密码；
- 匿名登录：配置允许 anonymous，可下载/上传（若可写则传 webshell）；
- 反弹攻击（FTP Bounce）：利用 FTP 的 PORT 命令让服务器去连第三方，做跳板/端口扫描；
- 暴力破解：没限速的 FTP 可被爆破。
防御：
- 用 SFTP/FTPS（加密）替代明文 FTP；
- 禁匿名、强口令、失败锁定；
- 限制可访问 IP、用被动模式并限制端口范围；
- 上云存储替代自建 FTP。
SSL/TLS 组件漏洞：加密层的裂缝
HTTPS 不是绝对安全，历史上有多个 TLS 层漏洞：
- 心脏出血（Heartbleed, CVE-2014-0160）：OpenSSL 心跳扩展越界读内存，可泄露私钥、cookie、密码等敏感数据，无需认证；
- POODLE：SSL 3.0 设计缺陷，可降级攻击；
- BEAST / CRIME / BREACH：针对 TLS 的边信道攻击，泄露部分明文；
- 降级攻击：逼迫客户端用弱加密套件（如 RC4）或旧协议（SSLv3）；
- 证书问题：自签名/过期/被吊销证书、证书颁发机构被攻破。
防御：
- 升级 OpenSSL 等库（Heartbleed 已修复）；
- 禁用 SSLv2/v3、TLS 1.0/1.1，只用 TLS 1.2/1.3；
- 用强加密套件、启用 HSTS（强制 HTTPS）；
- 正确部署证书、启用 OCSP 装订；
- 用 SSL Labs 测试评级，争取 A 以上。
攻击视角的统一认知
这些底层攻击有个共同点：利用协议”为效率/兼容而留的信任”。ARP 信广播、TCP 信 SYN、FTP 信明文、TLS 老版本信弱算法。防御的核心思路也就两条：
- 去掉不必要的信任（ARP 绑定、禁用弱协议）；
- 加验证与加密（HTTPS 全覆盖、强算法、Cookie 验证）。
更多实战案例：HTTP 请求走私
请求走私利用前端（CDN/反向代理）和后端对 HTTP 消息边界解析不一致来”夹带”请求。最常见的是 Content-Length 与 Transfer-Encoding 冲突：前端按 CL 截断，后端按 TE 分块，于是前端眼里的一个请求，后端当成两个，第二个被”走私”到队列里，等到下一个正常用户请求到来时，走私的内容会和它拼接，造成任意前缀注入、绕过安全控制、甚至劫持其他用户的响应。经典复现：构造一个同时带 Content-Length 和 Transfer-Encoding: chunked 且让后端优先处理 chunked 的请求包，观察后端是否把多余字节当作新请求。
更多实战案例：缓存投毒与 DNS 重绑定
缓存投毒是让 CDN 把”带毒”的响应缓存下来发给所有用户：攻击者找一个未被缓存、但会影响页面的未签名头（如 X-Forwarded-Host），让服务器把它回显进页面（比如拼进 <script src=//evil>），再请求一次让 CDN 缓存这页，之后所有访客都拿到带毒页面。DNS 重绑定则利用 TTL 很短的域名，第一次解析到正常 IP 通过同源校验，第二次解析到内网 IP，浏览器因同源策略只看域名就放行，从而访问内网服务。
常见坑
- 以为 HTTPS 就防走私：走私发生在应用层解析，和是否加密无关。
- 只测一种解析顺序：CL.TE 和 TE.CL 两种都要测，不同服务器默认不同。
- 缓存投毒以为要改页面：只要能控制一个未签名头回显即可，未必改整页。
- DNS 重绑定只在内网靶场有效：真实利用需配合能读响应的接口。
进阶：修复
前后端统一使用同一种解析库与配置，禁止同时出现 CL 和 TE；反向代理对请求做规范化（归一化）后再转发；缓存键要包含影响响应的头；对 X-Forwarded-* 等头做白名单校验，不回显到页面。
小测验
- 问题1：请求走私的核心原因？答案：前后端对 HTTP 消息边界解析不一致（CL/TE 冲突）。
- 问题2：缓存投毒靠什么让毒页被很多人看到？答案：让 CDN 缓存带毒响应，后续访客都拿到。
- 问题3：DNS 重绑定为什么能打内网？答案：同源策略只看域名，第二次解析到内网 IP 被放行。
更多实战案例：CL.TE 与 TE.CL 两种走私
请求走私分两种主流类型。CL.TE：前端用 Content-Length、后端用 Transfer-Encoding。攻击者发一个同时带两者的包，前端按 CL 截断，只把”前半”当请求转发；后端按 TE 把 chunked 解析，把前端眼里”多余”的那段当成另一个完整请求。TE.CL 反之：前端按 TE、后端按 CL，前端把整个（含走私部分）转发，后端按 CL 截断，走私部分留在队列等下一个请求拼接。复现时，用 Burp 的 HTTP/1 请求改掉走私载荷，观察后端是否出现”两个响应合并”或下一个用户的请求被污染。
更多实战案例：走私带来的具体危害
走私能做的事很多：一是绕过前端安全控制，比如前端禁止访问 /admin，攻击者把 GET /admin HTTP/1.1 走私进请求，后端直接处理；二是注入到其他用户请求里，实现”网页劫持”，把别人的响应替换成你控制的页面或脚本；三是配合缓存投毒，让带毒响应被 CDN 缓存；四是探测内网，把走私请求指向内网服务。它往往是”无声”的，日志里看起来只是正常请求，所以危害隐蔽且大。
更多实战案例：缓存投毒的细节
缓存投毒要找到”未被缓存、但会影响页面输出、且未被纳入缓存键”的输入。常见是 X-Forwarded-Host 头被拼进页面里的绝对 URL（如 <a href="https://{host}/">），攻击者发一个带恶意 host 的请求让服务器把恶意 URL 写进响应，CDN 把这页缓存，之后所有访客拿到带恶意链接的页面，点击就被带到攻击者站点（钓鱼或偷 cookie）。修复是别把未签名头回显进页面，且缓存键要包含影响响应的头。
更多实战案例：DNS 重绑定实战
利用 TTL 为 0 的域名：第一次解析返回攻击者控制的公网 IP，浏览器同源策略校验通过、建立连接；攻击者立刻改 DNS 记录指向内网 IP（如 127.0.0.1 或 192.168.x.x），浏览器因同源只看域名，第二次请求仍认为同源，于是能访问内网服务。前提是有接口会”读响应内容”（如读返回的 JSON），否则只能盲打。现代浏览器有 DNS Pinning 缓解，但旧环境仍可利用。
常见坑（补充）
- 只测一种解析顺序：CL.TE 和 TE.CL 都要测，不同服务器默认不同。
- 以为 HTTPS 就防走私：走私在应用层，与加密无关。
- 缓存投毒以为要改整页：控制一个未签名头回显即可。
- DNS 重绑定只在内网靶场有效：真实利用需配合能读响应的接口。
进阶（补充）：修复要点
前后端统一解析库与配置，禁止同时出现 CL 和 TE（或统一按一种处理）；反向代理对请求做规范化（归一化）后再转发；缓存键包含影响响应的头；对 X-Forwarded-* 等头做白名单校验、不回显到页面；禁用过长 TTL 的域名做敏感操作。
小测验（补充）
- 问题1：CL.TE 是谁按 CL 谁按 TE？答案：前端按 CL、后端按 TE。
- 问题2：走私为什么能绕过 /admin 限制？答案：前端拦了但走私部分后端直接处理。
- 问题3：缓存投毒关键找什么输入？答案：未缓存、影响输出、不在缓存键里的头。
更多实战案例：用 Burp 实操走私
实操上，用 Burp Suite 的 Repeater 把请求改成 HTTP/1.1 并手动构造冲突头：例如同时写 Content-Length: 4 和 Transfer-Encoding: chunked，body 写成 0\r\n\r\nG 之类，让前端按 CL 截断、后端按 TE 把后面的 G 当新请求开头。观察响应是否出现”两个响应拼在一起”或后续请求被污染。成功的走私常表现为：你发的请求 A 拿到了请求 B 的响应。掌握这个手法，能复现大量真实走私漏洞。
常见坑（终补）
- 只测一种解析顺序：CL.TE 和 TE.CL 都要测。
- 以为 HTTPS 就防走私：走私在应用层，与加密无关。
- 缓存投毒以为要改整页：控制一个未签名头回显即可。
- DNS 重绑定只在内网靶场有效：真实需配合能读响应的接口。
进阶（终补）：修复要点
前后端统一解析库与配置，禁止同时出现 CL 和 TE；反向代理对请求做规范化后再转发；缓存键包含影响响应的头；对 X-Forwarded-* 等头做白名单校验、不回显到页面；禁用过长 TTL 域名做敏感操作。走私本质是解析不一致，统一了就无意义。
小测验（终补）
- 问题1：CL.TE 是谁按 CL 谁按 TE？答案：前端按 CL、后端按 TE。
- 问题2：走私为什么能绕过 /admin 限制？答案：前端拦了但走私部分后端直接处理。
- 问题3：缓存投毒关键找什么输入？答案：未缓存、影响输出、不在缓存键里的头。
实战要点：走私与投毒的排查清单
上线前自查：请求是否可能同时带 CL 和 TE？代理是否对请求做了规范化？缓存键是否包含影响响应的头？是否有未签名头被回显进页面？把这四个问题过一遍，能挡掉绝大多数走私与投毒。运维侧：统一前后端解析组件版本与配置；CDN 开启”请求规范化”；对 X-Forwarded-* 做白名单。开发侧：不把客户端头拼进页面 URL。三层都做，这类漏洞基本无生存空间。
易错提醒
很多人以为”用了 HTTPS 就安全”，但走私发生在应用层解析，加密管不到。也别以为”我只用 CL”就安全，前端用 CL 后端可能用 TE。最稳妥是显式统一：要么全站只用 CL 并拒绝带 TE 的请求，要么用支持统一解析的现代代理并做归一化。模糊地带就是漏洞温床。
自测
- 走私的核心原因？答：前后端对消息边界解析不一致。
- 缓存投毒靠什么让毒页被多人看到？答：让 CDN 缓存带毒响应。
- DNS 重绑定为什么能打内网？答：同源策略只看域名，第二次解析到内网被放行。
这一篇你该记住的
底层协议攻击利用”协议为兼容/效率留的信任”：ARP 欺骗靠无认证广播做局域网中间人（防御：静态绑定+DAI+HTTPS）；SYN 泛洪占满半连接队列搞 DoS（防御：SYN Cookie+清洗）；FTP 明文嗅探/匿名/爆破（防御：用 SFTP/FTPS、禁匿名、限速）；SSL 层 Heartbleed/POODLE/降级（防御：升级库、禁老协议、TLS1.2+、HSTS）。统一防御：去不必要信任+加验证加密。
底层攻击讲完，前面 17 篇都是”招式”。下一篇 渗透测试流程 把招式串成一场有标准、有边界、有交付的正规项目。