一、TCP/IP协议栈安全：IP欺骗与源地址验证、TCP会话劫持、SYN Flood攻击原理与防御、ICMP重定向攻击
1.1 IP欺骗与源地址验证
IP欺骗，说白了就是伪造IP地址。攻击者把数据包的源IP改成别人的地址，然后发出去。你想想看，这就像有人拿着别人的身份证去办坏事，最后查监控还查错了人。
我记得刚入行那会儿，帮一家游戏公司排查DDoS攻击。流量分析一看，源IP全是五花八门的地址，有国内的、有国外的，甚至还有保留地址段的。我当时就判断——这八成是IP欺骗攻击。后来证实，攻击者用的就是伪造源IP的UDP Flood。
为什么IP欺骗能得逞？因为TCP/IP协议在设计时，压根没想过要验证源IP的真实性。路由器只看目的IP，不管源IP是不是编出来的。这就给了攻击者可乘之机。
核心问题：IP协议本身不提供源地址验证机制。每个数据包的源IP字段，完全由发送方填写，接收方默认信任。
1.2 源地址验证的防御手段
防御IP欺骗，最有效的手段就是——在网络边界做源地址验证。我建议你记住下面这几种方法：
- 入口过滤（Ingress Filtering）：在路由器入口处，检查数据包的源IP是否属于该接口对应的网段。不是就丢弃。说白了就是——从哪个门进来的，就得带哪个门的钥匙。
- 出口过滤（Egress Filtering）：从内部网络出去的包，源IP必须是内部合法地址。防止内网用户伪造源IP对外攻击。
- uRPF（单播反向路径转发）：路由器检查数据包的源IP，看回程路由是否指向收到该包的接口。如果不一致，说明源IP是伪造的。
实战建议：我曾经帮一家云厂商做安全加固，他们内部网络被用来发起反射放大攻击。问题就出在没做出口过滤。我给他们配了uRPF严格模式，配合ACL做源地址白名单，效果立竿见影。
1.3 TCP会话劫持
TCP会话劫持，比IP欺骗更狠。攻击者不光伪造IP，还要猜对TCP的序列号，然后插入恶意数据，接管已经建立的连接。
为什么会这样？因为TCP协议用序列号来保证数据的有序性和完整性。如果攻击者能猜对正确的序列号，就能伪造合法的TCP报文，让接收方以为是正常通信。
我记得有一次做渗透测试，客户的内网部署了一台老旧的文件服务器，用的还是Telnet协议。我抓包分析了一下，发现序列号增长很有规律——每次增加固定值。嗯，这种场景下，会话劫持简直不要太容易。
注意：TCP会话劫持的前提条件：
- 攻击者必须能嗅探到通信双方的流量（通常在同一个广播域内）
- 需要准确预测或获取TCP序列号
- 攻击者需要伪造源IP，同时保证自己也能收到响应
1.4 TCP会话劫持的防御
防御TCP会话劫持，核心思路就两条：加密通信和随机化序列号。
| 防御手段 | 原理 | 我个人的评价 |
|---|---|---|
| 使用加密协议（SSH/TLS） | 加密整个会话内容，即使劫持也无法解析 | 最彻底，推荐首选 |
| 随机化TCP序列号 | 让攻击者无法预测下一个序列号 | 基础防御，必须做 |
| 会话绑定（IP+端口） | 检测会话的源IP和端口是否发生变化 | 辅助手段，防君子不防小人 |
| 使用IPsec | 在网络层提供认证和加密 | 配置复杂，性能开销大 |
避坑指南：我曾经见过一个项目，开发人员觉得用了HTTPS就万事大吉了，结果忽略了WebSocket连接没有加密。攻击者通过劫持WebSocket会话，成功篡改了实时数据。记住——加密要覆盖所有通信通道，不能有遗漏。
1.5 SYN Flood攻击原理
SYN Flood，这是最经典的DDoS攻击方式之一。原理很简单——利用TCP三次握手的漏洞。
正常的三次握手是这样的：客户端发SYN，服务器回SYN+ACK，客户端再回ACK，连接建立。但攻击者只发SYN，不回最后的ACK。服务器等啊等，资源就被耗光了。
你想想看，服务器为每个半连接都要分配内存、维护状态。如果短时间内收到海量伪造的SYN包，服务器的连接表很快就满了。新的合法连接进不来，服务就挂了。
攻击特征：
- 源IP通常是伪造的，无法追踪
- SYN包速率极高，每秒可达数百万
- 服务器出现大量SYN_RECV状态的连接
- 正常用户无法建立新连接
1.6 SYN Flood的防御策略
防御SYN Flood，我总结了几种主流方案，各有优劣：
- SYN Cookie：服务器收到SYN后，不分配资源，而是根据连接信息计算一个Cookie值作为初始序列号。等收到ACK时再验证Cookie，验证通过才分配资源。说白了就是——不见兔子不撒鹰。
- SYN Proxy：防火墙或负载均衡器代替服务器完成三次握手。只有握手成功，才把连接转发给后端服务器。攻击流量在代理层就被过滤掉了。
- 增大半连接队列：调大系统的tcp_max_syn_backlog参数。但这只是治标不治本，只能延缓被攻陷的时间。
- 缩短超时时间：减少SYN_RECV状态的等待时间，让半连接尽快释放。
实战提醒：我曾经帮一家电商平台做抗DDoS方案。他们之前只用了SYN Cookie，但遇到大流量攻击时，CPU直接飙到100%。因为计算Cookie本身也要消耗CPU。后来我们加了SYN Proxy，配合硬件加速卡，才把性能扛住。所以——没有银弹，要根据业务场景组合使用。
1.7 ICMP重定向攻击
ICMP重定向，这个攻击手法现在不太常见了，但一旦碰上就很麻烦。它的原理是——攻击者伪造ICMP重定向报文，告诉受害者「去某个目标走另一条路更近」，从而把流量引到攻击者控制的设备上。
为什么会这样？因为ICMP重定向机制本身是为了优化路由效率设计的。当路由器发现主机走了一条非最优路径时，会发送ICMP重定向报文，建议主机更新路由表。但问题是——这个报文没有认证机制，谁都可以伪造。
我记得早年做内网渗透测试时，就利用过这个漏洞。在同一个网段里，发送伪造的ICMP重定向报文，把目标主机的默认网关改成我的机器。然后所有外发流量都经过我这里，抓包分析密码什么的，简直不要太轻松。
1.8 ICMP重定向的防御
防御ICMP重定向，其实很简单：
- 禁用ICMP重定向：在主机和路由器上关闭ICMP重定向功能。Linux下设置net.ipv4.conf.all.accept_redirects=0，Windows下在注册表中禁用。
- 使用静态路由：对于关键网络，配置静态路由，不依赖动态路由协议和ICMP重定向。
- 启用IP源路由验证：检查收到的ICMP重定向报文是否来自当前使用的网关。
我的习惯：每次做服务器安全基线配置时，我都会把ICMP重定向关掉。虽然99%的场景用不到，但万一被利用，后果很严重。安全配置就是这样——宁可多关一个功能，也不要留一个隐患。
1.9 本章知识体系
下面这张图，是我梳理的本章知识体系。你可以把它当作一个快速索引：
这张图把四种攻击和对应的防御策略放在一起对比。你可以看到，虽然攻击手法不同，但防御思路有共通之处——核心就是「不信任」和「最小化」。不信任任何未经验证的源信息，关闭不必要的协议功能。
好了，这一章的内容就到这里。TCP/IP协议栈的安全问题远不止这些，但这四个是最经典、最常遇到的。理解了它们的原理和防御方法，你就能应对大部分网络层的攻击场景。