2. 网络协议安全面试题

在网络安全工程师面试中，协议安全类问题几乎不会只停留在“TCP三次握手是什么”这种记忆层面。面试官真正想判断的是：你是否理解协议设计假设与真实网络环境之间的落差，以及攻击者如何利用这些落差完成嗅探、篡改、劫持、放大或欺骗。本章围绕TCP/IP栈中几个高频协议，从漏洞成因、攻击面、可观察现象到防护验证，给出一条能直接用于面试作答和实际排查的思路。

一、TCP/IP协议栈的共性攻击面

TCP/IP的设计初衷是互联互通，而非默认安全。它的几个基础假设——源IP可信、路径可信、状态可维护——在现代开放网络中都不成立。由此衍生出四类通用攻击面：

• 无认证的源地址：IP层不验证源IP，导致IP欺骗、反射放大、SYN Flood等。
• 明文传输：HTTP、DNS、ARP等默认不加密，可被嗅探和中间人篡改。
• 状态资源有限：TCP半连接、DNS查询、ARP缓存表都可被耗尽或污染。
• 信任链薄弱：ARP信任局域网应答，DNS信任递归解析结果，HTTP信任传输通道。

面试中回答协议安全题，建议按“协议机制→设计缺陷→攻击手法→观察特征→防护与验证”这条链路展开，而不是孤立罗列攻击名称。

二、TCP层：SYN Flood与序列号攻击

TCP建立连接需要三次握手。服务端收到SYN后进入SYN_RECV状态并分配半连接资源，等待客户端ACK。攻击者伪造大量源IP发送SYN，服务端资源被占满，正常用户无法连接，这就是SYN Flood。

在实验环境中可以用hping3模拟（仅限授权测试）：

hping3 -S -p 80 --flood --rand-source 192.168.1.10

观察服务端ss -s或netstat -ant | grep SYN_RECV | wc -l，若SYN_RECV数量持续攀升且接近net.ipv4.tcp_max_syn_backlog，说明半连接队列被占满。防护上可启用SYN Cookie：

sysctl -w net.ipv4.tcp_syncookies=1

SYN Cookie不立即分配资源，而是把连接信息编码进序列号，收到ACK后再重建，从而抵御伪造源IP的洪泛。验证方式是再次压测，观察SYN_RECV不再堆积、正常连接仍可建立。

另一类是序列号预测攻击。若ISN生成可预测，攻击者可伪造RST或注入数据。现代操作系统已使用加密随机ISN，面试中应指出“该攻击在当代系统上已基本不可行，但理解它有助于理解TCP状态机信任模型的脆弱性”。

三、HTTP/HTTPS：从明文到降级

HTTP本身无状态、无加密，攻击面集中在请求走私、响应拆分、缓存投毒和会话劫持。以请求走私为例，当前端代理与后端服务器对Content-Length和Transfer-Encoding的解析不一致时，攻击者可构造歧义请求，把一段请求“夹带”到下一个用户的会话中。

POST / HTTP/1.1
Host: example.com
Content-Length: 13
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: example.com

若前端按Content-Length截断、后端按chunked解析，后端会把GET /admin当作下一个请求处理。判断依据是：同一TCP连接上第二个响应返回了非预期内容。防护要点是前后端统一解析规则、拒绝同时出现两种长度头、升级到HTTP/2。

HTTPS并非绝对安全。它的攻击面包括：证书校验缺失导致中间人、TLS版本降级、弱套件、以及SSL Stripping。SSL Stripping的原理是攻击者在中间人位置把用户的HTTPS请求降级为HTTP，再把服务端的HTTPS响应转回HTTP给用户。用户浏览器地址栏没有锁标志，但很多人不会注意。防护依赖HSTS：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

验证HSTS是否生效，可用curl -sI https://example.com | grep -i strict查看响应头，或在浏览器访问chrome://net-internals/#hsts查询域名是否在HSTS列表中。

四、DNS：缓存投毒与隧道

DNS查询默认走UDP 53端口，无认证。攻击面主要有三：缓存投毒、DNS劫持、DNS隧道。缓存投毒的核心是攻击者抢在合法响应前，向递归解析器注入伪造的A记录。经典Kaminsky攻击通过大量随机子域名查询，逼迫解析器发起新查询，再暴力猜测事务ID和源端口。防护手段包括：随机化事务ID与源端口、启用DNSSEC、限制递归解析器只对可信客户端开放。

DNS隧道则是把数据编码进域名查询，绕过防火墙外联。例如：

data1.attacker.com
data2.attacker.com
...

检测特征：单一域名下大量随机子域、TXT记录异常增长、查询频率远高于正常业务。可用tcpdump -i eth0 port 53 -w dns.pcap抓包后统计子域熵值。防护上应限制内网DNS只解析必要域名，并对异常查询做告警。

五、ARP：局域网信任的代价

ARP的工作机制是“问谁拥有某IP，请告诉我MAC”。它不验证应答来源，任何主机都可以声称自己是网关。攻击者持续发送伪造ARP应答，把网关IP映射到自己的MAC，即可实现中间人。

arpspoof -i eth0 -t 192.168.1.100 192.168.1.1
arpspoof -i eth0 -t 192.168.1.1 192.168.1.100

受害主机执行arp -a会看到网关IP对应的MAC变成了攻击者MAC。判断依据是：同一MAC对应多个IP，或网关MAC与已知基线不符。防护手段包括静态ARP绑定、DHCP Snooping、动态ARP检测（DAI）和端口安全。验证DAI是否生效，可在交换机上查看show ip arp inspection statistics，观察被丢弃的ARP包数量。

六、面试作答与实战排查的通用框架

面对“某协议有什么漏洞”这类问题，可按以下结构组织答案，既体现深度又便于面试官跟随：

层次	要回答的内容	示例
协议机制	该协议如何工作、依赖什么假设	ARP无认证，信任应答
设计缺陷	假设在什么场景下失效	局域网内任意主机可伪造应答
攻击手法	具体如何利用	ARP欺骗实现中间人
观察特征	日志、流量、状态表上看到什么	arp -a中MAC异常、重复IP
防护与验证	怎么防、怎么确认防住了	DAI+静态绑定，查看丢弃计数

在实际排查中，建议先建立基线：正常情况下的ARP表、DNS查询模式、TCP连接状态分布。没有基线，就无法判断“异常”。例如某内网主机突然出现大量到53端口的UDP流，且子域长度接近上限，就应优先怀疑DNS隧道而非普通上网行为。

最后提醒一点：协议安全面试题往往没有唯一标准答案，面试官更看重你能否把“协议原理”和“攻击可行性”连起来，并给出可验证的防护措施。平时可在授权实验环境中用Wireshark观察一次完整的ARP欺骗或SYN Flood过程，把抓包结果和状态变化记录下来，这比背诵攻击名称更有说服力。