网络协议安全笔记（下）：应用层与安全视角

本篇承接《网络协议安全笔记（上）：链路层 → 传输层》，章号与上篇连续（五、六）。
上篇已经把以太网、ARP、IPv4、ICMP、TCP、UDP 逐层拆完，并附了 4 张本机实测抓包图（ARP、IP 分片、UDP 大包分片、DNS 一问一答）；本篇接着讲跑在它们上面的应用层协议，最后收口到「攻击面总表 + 明文与密文边界 + 抓包复现清单」。

⚠️ 本文只讨论协议原理与原生设计缺陷，用于学习、排障和防御，不包含可直接运行的攻击代码。

五、应用层

这一层的一句话：到了应用层，协议本身「怎么传」已经定了，能做安全的只剩下「自己加认证和加密」—— HTTPS 就是给 HTTP 套了个 TLS 壳。

5.1 HTTP（HyperText Transfer Protocol，超文本传输协议）

核心作用：应用层协议，用来在客户端和服务器之间传输网页等资源，基于 TCP，明文通信。

HTTP 请求报文由四部分组成：

1. 请求行（方法 + URI + 版本）
2. 请求头（多行键值对，Host、User-Agent…）
3. 空行（\r\n，分隔头和体，不能丢）
4. 请求体（POST 一般有，GET 通常为空）

GET /get HTTP/1.1\r\n        ← 请求行（方法 + URL路径 + 版本）
Host: 44.206.195.5\r\n       ← 请求头
User-Agent: curl/8.21.0\r\n  ← 请求头
Accept: */*\r\n              ← 请求头
\r\n                         ← 空行（分隔头和体，这里没有请求体）

HTTP 响应报文：

HTTP/1.1 200 OK\r\n                          ← 状态行（版本、状态码、描述）
Date: Sat, 24 Oct 2026 14:54:01 GMT\r\n      ← 响应头
Content-Type: application/json\r\n           ← 响应头，告诉客户端返回的是 JSON
Content-Length: 256\r\n                      ← 响应体长度
Connection: keep-alive\r\n
Server: gunicorn/19.9.0\r\n
Access-Control-Allow-Origin: *\r\n
Access-Control-Allow-Credentials: true\r\n
\r\n                                         ← 空行！分隔响应头和响应体
{"args": {}, "headers": {...}}               ← 响应体（JSON 数据）

补充要点：

点	说明
Host 头	HTTP/1.1 必需，一台服务器靠它区分虚拟主机（同一 IP 跑多个站点）
Connection: keep-alive	复用同一条 TCP 连接发多个请求，省握手开销
状态码分类	1xx 信息 / 2xx 成功 / 3xx 重定向 / 4xx 客户端错 / 5xx 服务端错
HTTP/2	二进制分帧 + 多路复用（解决应用层队头阻塞，TCP 层的还在）
HTTP/3	直接跑在 QUIC over UDP 443 上，彻底绕开 TCP 队头阻塞

缺陷

1. 全程明文传输：所有内容（Cookie、账号密码）抓包直接看。
2. 协议本身无身份校验、无防篡改。
3. 大量依赖头字段做安全控制，容易配置疏漏（Content-Type、X-Frame-Options、CSP 少一个就是一个洞）。

利用

1. 中间人抓包窃取账号 Cookie。
2. 中间人篡改页面内容（注入 JS 钓鱼）。
3. 请求走私（Request Smuggling）：Content-Length 与 Transfer-Encoding 解释不一致，让前后端对「一个请求到哪里结束」产生分歧。
4. Host 头注入：改 Host 让服务器生成指向攻击者的链接（密码重置邮件劫持）。
5. 配套 Web 层攻击：XSS、CSRF、文件上传（属于 Web 应用层，依托 HTTP 承载）。

防御：全站 HTTPS、CSP、SameSite Cookie、HSTS、严格的 Host 校验。

5.2 DNS（Domain Name System，域名系统）

核心作用：实现 域名 → IP。方便人记忆域名，计算机通信依靠 IP 地址。

端口规则：UDP 53 为主（查询报文短、一问一答）；超过 512 字节或者区域传输时用 TCP 53。

解析过程（递归 + 迭代）：

客户端 → 本地 DNS（递归查询，替你把活干完）
本地 DNS → 根服务器   （迭代：根只告诉你「去问 .com 的服务器」）
本地 DNS → .com 服务器（迭代：告诉你「去问 example.com 的权威服务器」）
本地 DNS → 权威服务器 （拿到最终 A 记录，缓存 TTL 秒）
本地 DNS → 客户端     （返回结果）

报文结构（DNS 报文，请求、响应共用同一套格式）：

事务ID(2B) | 标志位(2B) | 问题数(2B) | 回答数(2B) | 授权数(2B) | 附加信息数(2B)
【问题段】：查询域名、类型、类别
【回答段】：（响应才有）资源记录，解析结果（域名、TTL、类型、IP等）
【授权段】：授权域名服务器信息
【附加段】：额外辅助信息

关键字段：

字段	作用
Transaction ID	请求与响应必须一致，这是 UDP 上唯一的「配对」依据（也是投毒攻击要猜的目标）
QR / Opcode / RD / RA	查询还是响应、是否期望递归、是否支持递归
TC（Truncated）	响应被截断 → 客户端改用 TCP 重查
RCODE	0 成功 / 3 域名不存在（NXDOMAIN）等
TTL	缓存多久，越大投毒窗口越长

绝大多数情况：一条 DNS 查询 / 响应，单独占一个帧（一个以太网帧）。

缺陷（原始 DNS，走 UDP）

1. 无认证：收到 DNS 响应就采信，不验证是不是权威服务器返回的。
2. 早期 UDP 明文传输，链路上可直接看、直接改。
3. 事务 ID + 源端口只有 32 位熵：攻击者只要猜中就能抢先应答（Kaminsky 攻击后用随机源端口缓解）。
4. 缓存会「记住」错误答案 → 影响面比单次请求大得多。

利用

1. DNS 欺骗（DNS 缓存投毒）：伪造 DNS 应答，抢先返回虚假 IP，让用户访问钓鱼网站；投毒到递归服务器则影响所有下游用户。
2. DNS 隧道：把数据封装进 DNS 查询，向外隐蔽传输（内网渗透数据外传）。特征是超长域名、超高频查询、大量 TXT/NULL 记录。
3. DNS 放大 DDoS：向开放递归 DNS 服务器发送伪造源 IP 的查询，大流量反射打到目标（见 4.2.8）。
4. NXDOMAIN 洪水 / 随机子域攻击：耗尽递归服务器缓存。

防御：DNSSEC（给解析结果签名，形成信任链）、DoH（443）/ DoT（853）加密 DNS、限制开放递归 DNS、0x20 编码 + 随机源端口、出向 DNS 只允许走内部解析器。

5.3 TLS（Transport Layer Security，传输层安全协议）

核心作用：介于 TCP 和应用层之间，协商加密参数、交换密钥，给上层数据提供加密、完整性校验、证书身份认证。

报文结构：分为握手报文、告警报文、应用数据报文等；握手阶段交互证书、随机数、密钥材料；握手完成后上层业务数据放在应用数据类型的 TLS 记录里加密传输。

TLS 记录层结构（每个包都是这个壳）：

字段	长度	说明
Content Type	1B	20 变更密码规范 / 21 告警 / 22 握手 / 23 应用数据
Version	2B	0x0303 = TLS 1.2
Length	2B	载荷长度
Payload	变长	加密后的内容

与安全相关的四个点：

1. 证书是唯一的身份依据：客户端信任的不是「网站」，而是「能证明持有某私钥、且证书链能追到受信根 CA」。中间人只要让你装一个自签 CA，整套就破了（Burp/Fiddler 抓 HTTPS 就是这么干的）。
2. SNI 明文：TLS 握手里的 server_name 扩展是明文的，中间人能看到你访问哪个域名（看不到路径和内容）。ECH（Encrypted Client Hello）正在解决这个问题。
3. 前向保密（PFS）：TLS 1.3 强制使用临时密钥交换（ECDHE），私钥泄露也解不开历史流量。
4. TLS 1.3 只 1-RTT（甚至 0-RTT），比 1.2 的 2-RTT 快，且删掉了 RSA 密钥交换、RC4、CBC 等一堆历史包袱。

5.4 HTTPS（HTTP + TLS，HTTP Secure，安全超文本传输协议）

核心作用：在 HTTP 基础上增加 TLS 安全层，实现传输加密、防篡改、身份校验。

报文结构：HTTP 报文会被 TLS 封装成 TLS 记录报文，链路中抓包看到的是 TLS 密文包，内部承载 HTTP 报文，外部无法直接解析。

Wireshark 里看到的样子：Client Hello → Server Hello, Certificate, Server Key Exchange, Server Hello Done → Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message → Application Data（后面全是密文）。

实拍：Client Hello 里的 SNI 是明文

列表第 4 条直接写着 Client Hello (SNI=www.hust.edu.cn)；下方面板一层层展开：
Transport Layer Security → TLSv1.2 Record Layer: Handshake Protocol: Client Hello → Handshake Protocol: Client Hello → Extension: server_name (len=20) name=www.hust.edu.cn。

也就是说：握手阶段的域名是裸奔的，链路上任何设备都能看到你访问了哪个站（但看不到路径和内容）。这就是 SNI 嗅探、按域名封锁能生效的原因，也是 ECH（Encrypted Client Hello）想解决的问题。

典型攻击与防御：

攻击	原理	防御
证书中间人	让客户端信任攻击者的 CA	证书固定（pinning）、HSTS、关注证书告警
SSLStrip（降级）	把 HTTPS 链接改写成 HTTP，中间人拿明文	HSTS（浏览器强制 HTTPS）+ preload 列表
降级到旧版本	逼出 SSLv3/RC4 等弱套件	服务端只允许 TLS 1.2/1.3
SNI 嗅探	SNI 明文，可做域名级审查/封锁	ECH
流量分析	包长/时序泄露页面结构	填充、固定长度记录

记住一个判断：HTTPS 加密的是「应用层内容」，不是「整条链路」。MAC、IP、端口全部明文，这也是下一节「明文可见性」要讲清楚的。

5.5 DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）

核心作用：给主机自动下发 IP 地址、子网掩码、默认网关、DNS 服务器。走 UDP，服务端 67、客户端 68。

四步 DORA：

步骤	方向	说明
Discover	客户端 → 广播	「谁是 DHCP 服务器？」此时客户端还没有 IP，源 0.0.0.0，目的 255.255.255.255
Offer	服务器 → 客户端	「这个地址给你用」
Request	客户端 → 广播	「我要这个地址」（广播是为了告知其他服务器）
ACK	服务器 → 客户端	「确认，租期 N 秒」

实拍：一次完整的 DORA（ipconfig /release + ipconfig /renew 期间抓的，过滤器 bootp）

四条报文 Transaction ID 全是 0x159eeb42 —— 这就是 UDP 上「响应到底属于哪个请求」的唯一依据；Discover 和 Request 的源地址是 0.0.0.0、目的 255.255.255.255（此时客户端还没有 IP，只能广播）；ACK 里能看到 Your (client) IP address: 10.41.231.117、Next server IP address: 10.41.231.140，往下还有 Option (3) Router（网关）和 Option (6) Domain Name Server（DNS）。

这两项就是「伪造 DHCP 服务器能一次性劫持整个网段」的原因：改网关和改 DNS，都不需要碰任何一台主机，客户端自己会在下一次续租时把这两项写进路由表和解析器。

缺陷 → 利用：

1. 无认证 → 伪造 DHCP 服务器（Rogue DHCP）：抢在真服务器前应答，把默认网关和 DNS 全指到攻击者 → 一次性劫持整个网段的流量（比 ARP 欺骗更省事，考试爱考）。
2. DHCP 饿死（Starvation）：伪造大量 MAC 把地址池耗尽，让正常主机拿不到 IP。
3. 租期到期续租（REQUEST 单播）可被伪造 NAK 打断。

防御：DHCP Snooping（交换机区分信任口/非信任口）、端口安全限制每口 MAC 数、802.1X。

5.6 SSH / FTP / Telnet 一句话对比

协议	端口	加密	一句话
Telnet	23	❌ 明文	老式远程登录，抓包直接看账号密码，已淘汰
FTP	21（控制）/ 20（主动数据）	❌ 明文	控制连接和数据连接分离；被动模式（PASV）由客户端连服务端随机端口，穿 NAT 友好
SFTP / SCP	22	✅	跑在 SSH 之上，不是「FTP over SSH」
SSH	22	✅	版本交换 → 密钥交换（KEX）→ 用户认证 → 加密通道；支持端口转发（本地/远程/动态 SOCKS）

安全考点：FTP 明文 + 匿名登录、SSH 弱口令爆破、SSH 端口转发做隧道（和 DNS 隧道、ICMP 隧道是同一类「合法协议做非法通道」）。

---

六、安全视角总结

6.1 攻击面总表

协议	层	核心缺陷	典型攻击利用	主要防御
以太网	L2	MAC 可伪造，交换机只学地址	MAC 泛洪、VLAN 跳跃、STP 攻击	端口安全、BPDU Guard、显式 trunk
ARP	L2/3	无认证，收到应答直接更新缓存	ARP 欺骗、局域网中间人、断网	静态绑定、DAI + DHCP Snooping
IPv4	L3	源 IP 可伪造、只校验首部、不加密	IP 伪造、分片攻击、反射放大	uRPF/BCP38、分片策略、IPsec
ICMP	L3	无认证，报文容易伪造	ICMP 洪水、Smurf、重定向、隧道	限速、禁重定向、限制载荷
TCP	L4	握手耗资源、老系统序号可预测、无身份绑定	SYN Flood、会话劫持、RST 断连	SYN Cookie、随机 ISN、清洗
UDP	L4	无连接无状态 → 源 IP 伪造零成本；无速率控制	UDP Flood、Fraggle、反射放大、隧道、UDP 扫描	BCP38/uRPF、关公网暴露服务、限速
HTTP	L7	全明文，无防篡改	中间人窃密、页面篡改、请求走私	HTTPS、CSP、HSTS
DNS(UDP)	L7	原始无认证、明文、ID 熵低	缓存投毒、DNS 放大、DNS 隧道	DNSSEC、DoH/DoT、限开放递归
DHCP(UDP)	L7	无认证、靠广播	伪造服务器劫持网关/DNS、地址池饿死	DHCP Snooping、802.1X
TLS/HTTPS	L5/7	旧版本漏洞、证书信任体系、SNI 明文	降级、证书中间人、SNI 嗅探	只开 1.2/1.3、pinning、HSTS、ECH

6.2 明文与加密边界

普通场景

以太网 + IPv4 + TCP/UDP/ICMP

• L2：源 MAC、目的 MAC、以太网 Type → 明文
• L3：源 IP、目的 IP、Protocol 协议号、TTL、总长度等 → 明文
• L4：TCP/UDP 的源端口、目的端口 → 明文
• Payload：
  • HTTP、DNS、FTP、Telnet：明文
  • HTTPS、SSH、TLS：Payload 加密

例外 1：HTTPS / TLS —— 只加密应用层

TLS 在 TCP 之上、应用之下，所以：

[以太网头（明文）] [IP头（明文）] [TCP头（明文：端口 443）] [TLS 记录（密文：HTTP 报文）]

• 中间人看得见：你访问的服务器 IP、443 端口、SNI 里的域名、证书；
• 中间人看不见：URL 路径、Cookie、请求体、响应内容。

例外 2：IPSec VPN（隧道模式，最关键的反例）

隧道模式 ESP：

[外层MAC] [外层IP头（明文）] [ESP头] [内层完整IP包（加密）] [ESP尾]

• 外层的源 IP、目的 IP 是明文（路由器要靠它路由）；
• 内层整个原始 IP 包（内层源 IP、内层目的 IP、协议号、内层 L4 端口）全部被加密；
• 内层 MAC 不存在，因为内层 IP 包已经不再走二层转发了。

也就是说：VPN 隧道里面，你看不到真实通信双方的内网 IP 和端口，只能看到 VPN 网关之间的 IP。

例外 3：GRE / PPTP 等隧道 —— 加了头但没加密

[外层MAC] [外层IP头] [GRE头] [内层完整IP包（明文！）]

• 隧道只解决「封装」，不解决「加密」；
• 抓包照样能看到内层 IP 和端口 → GRE 隧道 + 明文内层 = 等于没有保护；
• PPTP 的 MPPE 虽然加密，但协议本身已被认为不安全。

三种情况放一起看：

场景	L2 MAC	L3 IP	L4 端口	Payload
普通明文	可见	可见	可见	明文
HTTPS	可见	可见	可见（443）	密文
IPSec 隧道	可见（网关 MAC）	只有网关 IP	不可见	密文（内层整包）
GRE 隧道	可见	外层可见，内层也可见	内层可见	明文

6.3 抓包排错清单

Wireshark 里看到	说明什么	和 IDS/流量分类的关系
TCP Retransmission	丢包后超时重传	重传率高是拥塞/丢包特征，也是某些扫描的特征
TCP Dup ACK / Fast Retransmission	快重传被触发	同上，可作为流级统计特征
TCP RST	连接被强制断开	可能是 RST 注入攻击，也可能是服务未监听
ICMP Destination unreachable (Port unreachable)	UDP 端口没开	UDP 扫描的判据
Fragmented IP protocol	出现 IP 分片	可能是正常大 UDP，也可能是分片攻击/IDS 绕过
TCP SYN 大量来自不同源 IP、无后续 ACK	SYN Flood 特征	半连接类攻击的典型流量形态
大量 UDP 短包发往同一目的端口	UDP Flood / 扫描	pps 型攻击最直接的特征
相同 Transaction ID 的多个 DNS 响应	DNS 投毒尝试	应用层欺骗
超长域名 / 大量 TXT 查询	DNS 隧道	数据渗出检测

由此可以得出一个对做流量检测的人有用的结论：同一类攻击的不同工具，在 flow 级统计量上可能几乎一样 —— 比如 HOIC 和 LOIC 都是 HTTP 洪泛，flow 特征高度重合，能区分它们的往往是工具指纹（包长分布、默认头字段）而不是流量「形状」。所以「按工具名分类」本身就有天花板，更现实的目标是「按攻击类型 + 行为异常」分类。

6.4 简答模板

拿到任何一个协议，按这三问准备，每题 2~3 句就够：

1. 它原本怎么工作？（调用 408 计网储备：报文结构 + 交互流程）
2. 它的缺陷是什么，攻击怎么利用？（一句话点出「缺什么」，再给攻击名）
3. 怎么防御？（分层说：协议层 / 网络设备层 / 应用层）

以 ARP 欺骗为例：

正常：ARP 广播查询 MAC，收到应答后写入缓存。
攻击：攻击者伪造 ARP 应答，篡改「网关 IP ↔ MAC」映射，流量经过攻击者主机，实现中间人。
防御：静态 ARP 绑定、DAI（交换机动态 ARP 检测）、ARP 防火墙、划分 VLAN。

以 UDP 反射放大为例：

正常：UDP 无连接，一问一答，服务端不维护状态。
攻击：伪造源 IP 为受害者，向开放服务发小请求，大响应全部打到受害者；因为 UDP 不用握手，伪造源 IP 零成本。
防御：入口过滤 BCP38/uRPF、关闭公网暴露的开放服务、限速。