第202篇：防火墙包过滤与会话表
关键词：包过滤、会话表、Session Table、五元组、状态检测、首包处理、后续包处理、连接跟踪
一、引言
防火墙的安全策略决定了"什么流量应该被允许"，而真正执行这个决策的底层机制是包过滤引擎和会话表。理解防火墙如何处理每一个数据包的完整生命周期，是掌握防火墙性能调优和故障排查的关键。
在深入安全策略配置之前，我们必须搞清楚防火墙内部的数据包处理流水线：一个数据包从进入物理接口到最终被转发或丢弃，中间经历了哪些处理阶段？会话表在其中扮演了什么角色？为什么第一条数据包和后续数据包的处理路径完全不同？
二、核心概念
2.1 包过滤的两种模式
防火墙处理数据包时有两种截然不同的路径：
| 模式 | 处理对象 | 处理机制 | 性能特点 |
|---|---|---|---|
| 首包处理 | 每条新连接的第一条报文 | 完整匹配安全策略表，逐条规则比对 | CPU 处理，消耗较大 |
| 后续包处理 | 同一连接中已建会话的报文 | 直接查会话表，O(1) 哈希查找 | 硬件加速，性能极高 |
这种"首包慢、后续快"的设计是状态防火墙的核心优势：将昂贵的策略匹配代价分摊到连接的生命周期中，后续报文的处理几乎不产生额外开销。
2.2 会话表（Session Table）
会话表是状态防火墙的核心数据结构。每当首包处理流程决定放行一条新连接时，防火墙会在会话表中创建一条记录。后续属于该连接的所有报文只需在会话表中查找，无需再次执行完整的策略匹配。
一条会话表项包含以下关键字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| Protocol | 协议类型 | TCP/UDP/ICMP |
| Source IP | 源 IP 地址 | 10.1.1.50 |
| Source Port | 源端口 | 52341 |
| Destination IP | 目的 IP 地址 | 203.0.113.10 |
| Destination Port | 目的端口 | 443 |
| State | TCP 连接状态 | ESTABLISHED/SYN_SENT/CLOSE_WAIT |
| Creator | 创建方式 | Policy/NAT/ALG |
| Packets | 已传输报文数 | 1,234 |
| Bytes | 已传输字节数 | 987,654 |
| Age | 会话存活时间 | 00:05:23 |
| Timeout | 超时时间 | 1800s |
2.3 五元组与连接标识
五元组（源IP、目的IP、协议、源端口、目的端口）唯一标识一条网络连接。会话表的查找键就是五元组，这决定了：
- 同一源 IP 的不同端口发起的 HTTPS 连接是独立会话
- TCP 和 UDP 即使使用相同的 IP 和端口组合也是独立会话
- ICMP 报文没有端口，使用 ICMP 类型和 ID 字段替代端口信息
三、技术细节
3.1 首包处理完整流水线
第一条数据包到达防火墙时，需要经过完整的处理流水线：
3.2 会话状态机
不同协议的会话状态管理方式差异很大：
TCP 会话状态：TCP 是有连接协议，防火墙需要跟踪完整的 TCP 状态机：
| TCP 状态 | 含义 | 会话表行为 |
|---|---|---|
| SYN_SENT | 发送 SYN，等待确认 | 创建半开会话，短超时 |
| ESTABLISHED | 连接已建立 | 正常会话，长超时 |
| FIN_WAIT | 正在关闭连接 | 等待对端确认关闭 |
| TIME_WAIT | 连接关闭后的等待期 | 短超时后自动清除 |
| CLOSE_WAIT | 等待本地关闭 | 异常状态，可能泄露资源 |
UDP 会话：UDP 是无连接协议，防火墙采用"触发式会话创建"机制：
- 首包（请求）通过策略匹配后创建会话
- 响应包（Reply）到达时反向匹配会话表
- 超时时间较短（通常 180 秒），超时后自动清除
ICMP 会话：ICMP 会话跟踪使用类型/代码和查询 ID 标识：
- Echo Request 触发创建会话
- Echo Reply 匹配已有会话放行
- 超时时间极短（通常 30 秒）
3.3 会话超时与清理
会话表不是无限增长的，防火墙通过多种机制管理会话表的生命周期：
| 超时类型 | 适用场景 | 默认超时 |
|---|---|---|
| TCP Established | 已建立的 TCP 连接 | 120 分钟 |
| TCP Half-Open | 半开连接（仅 SYN） | 3 分钟 |
| TCP Close-Wait | 关闭等待 | 1 分钟 |
| UDP | UDP 会话 | 3 分钟 |
| ICMP | ICMP 会话 | 30 秒 |
| FTP Data | FTP 数据连接（ALG） | 5 分钟 |
当会话表项达到上限（如 USG6000E 的 500 万条）时，新的连接将无法建立，表现为网络断连。因此监控会话表使用率是防火墙运维的重要指标。
四、实战配置/案例分析
4.1 会话表查看与诊断
# 查看会话表摘要统计
display firewall session table
# 输出示例：
# Total session(s): 12,456
# TCP session(s): 8,230
# UDP session(s): 3,891
# ICMP session(s): 335
# 查看特定IP的会话
display firewall session table verbose source-ip 10.1.1.50
# 输出示例：
# * 0: 0x21694022 -- TCP
# TTL: 1795 Timeout: 120min Creator: Policy
# Policy/Direction: SecPol/Inbound
# Zone: Trust --> Untrust
# Protocol: 6(TCP)
# Source: 10.1.1.50:52341 MAC: xxxxxxxx
# Destination: 203.0.113.10:443 MAC: yyyyyyyy
# Current Next State: EstabOther Last Event: TcpOther
# Packet/Byte Sent: 1256/98432
# Packet/Byte Received: 3421/2567890
# Inbound Interface: GE0/0/2
# Outbound Interface: GE0/0/0
# 统计各协议会话数
display firewall session table statistics
# 清除特定会话（用于故障恢复）
reset firewall session table source-ip 10.1.1.50 destination-ip 203.0.113.10
# 清除所有会话（谨慎操作，会导致所有连接中断）
reset firewall session table
4.2 调整会话超时参数
# 调整TCP Established会话超时（默认120分钟）
firewall session tcp established-timeout 30
# 调整UDP会话超时（默认180秒）
firewall session udp timeout 60
# 调整ICMP会话超时
firewall session icmp timeout 10
# 调整半开连接超时（防御SYN Flood）
firewall session tcp syn-sent timeout 60
firewall session tcp syn-received timeout 30
# 配置会话表上限告警阈值（使用率达到80%时告警）
firewall session maximum 5000000
firewall session alarm-threshold 80
4.3 故障案例：会话表耗尽导致网络中断
故障现象：某企业内网用户批量反映互联网访问中断，ping 不通任何外部地址，但内网互访正常。
排查步骤：
- 检查防火墙 CPU 和会话表：
display firewall session table
# 输出：Total session(s): 4,998,721
# 接近会话表上限 5,000,000
- 分析会话分布：
display firewall session table statistics
# 发现 UDP 会话占比异常高，超过 80%
# 大量半开 UDP 会话指向同一目的地址 45.33.32.156
- 定位异常源：
display firewall session table verbose destination-ip 45.33.32.156
# 发现大量来自不同内网 IP 的 UDP 会话
# 目的端口均为 1900（UPnP 协议）
# 会话状态均为半开，持续 3 分钟超时
-
根因分析：内网存在一台感染 Mirai 变种蠕虫病毒的 IoT 摄像头，持续向外网广播 UPnP 探测包。由于 UDP 是无连接协议，每个探测包都创建了一条独立的会话表项，短时间内耗尽了会话表资源。
-
修复措施：
# 紧急措施：阻断恶意IP
security-policy
rule name Block_Malicious_IP
source-zone trust
destination-zone untrust
destination-address 45.33.32.156
action deny
log-action enable
quit
# 长期措施：调整UDP超时、扩大会话表、部署IPS
firewall session udp timeout 30
firewall session maximum 8000000
# 定位并隔离内网感染主机
- 经验总结：会话表耗尽是防火墙常见的性能故障，通常由以下原因引起：
- DDoS 攻击产生的大量半开连接
- 内网主机感染恶意软件后对外扫描
- 应用配置不当导致连接不释放
- UDP 会话超时设置过长
五、总结
| 知识点 | 核心要点 |
|---|---|
| 首包处理 | 完整匹配安全策略，CPU 处理，性能消耗大 |
| 后续包处理 | 查会话表，O(1) 哈希查找，硬件加速 |
| 会话表 | 记录五元组+状态+超时，是状态检测的核心 |
| TCP 会话 | 跟踪完整状态机，支持 ESTABLISHED/SYN_SENT 等状态 |
| UDP 会话 | 触发式创建，超时较短，易受攻击 |
| 会话超时 | TCP 120min/UDP 3min/ICMP 30s，可调优 |
| 会话表耗尽 | 表现为全网中断，需分析会话分布定位根因 |
| 排障命令 | display firewall session table / reset firewall session table |
思考
- 为什么防火墙对 TCP 和 UDP 的会话处理方式完全不同？这种差异会带来哪些安全风险？
- 当一个 TCP 连接在防火墙会话超时前正常断开（发送 FIN），会话表项是如何被清除的？如果客户端异常断电，会话表项又怎么处理？
- 会话表上限设置为 500 万条，但现网中正常业务只需要 10 万条会话，如何快速识别出异常的会话增长趋势？
下篇预告：第203篇：状态防火墙 vs 包过滤防火墙