iptables规则运行于内核内存，需通过iptables-save备份、iptables-restore恢复，并结合diff比对、计数验证和日志联动开展全生命周期审计。
iptables规则是运行在内核内存中的，不重启不会丢失，但也不会自动落盘。备份与恢复不是“可选项”，而是防火墙运维的基线动作；审计则要围绕规则生命周期展开，而非只看最终快照。
备份必须明确范围和时机
规则备份本质是把内存中的当前状态导出为文本文件。关键点在于：
- 用 iptables-save 而非 service iptables save：前者是跨发行版通用命令，后者仅在RHEL/CentOS 6等旧系统中有效，且行为不可控；
-
指定表更安全：如只备份 filter 表，执行
iptables-save -t filter > /etc/iptables/filter.rules，避免 nat 或 mangle 表误操作影响转发逻辑； -
带计数器备份用于审计比对：加
-c参数（iptables-save -c > /backup/iptables-with-counters.bak），后续可用计数变化辅助判断规则是否被实际触发； -
定时+人工双触发：除每日凌晨自动备份外，每次修改规则前必须手动执行一次备份，并附带注释说明变更原因，例如：
# 2026-07-08 添加运维IP白名单：iptables -I INPUT -s 203.0.113.5 -j ACCEPT。
恢复需区分场景并规避覆盖风险
恢复不是简单执行 iptables-restore，而要根据当前状态选择策略：
-
紧急回滚（如误执行 -F）：直接使用最近备份文件还原，命令为
iptables-restore < /backup/iptables-last.bak。注意默认会清空现有规则，若已有部分恢复动作，可加-n参数追加加载； -
异机迁移或重装后部署：确保目标系统内核模块已加载（
modprobe ip_tables），再还原；nat 表涉及转发时，还需确认net.ipv4.ip_forward=1已启用； -
仅更新某条链（如只改 INPUT）：不建议全量恢复。应先导出当前 INPUT 链规则（
iptables -t filter -S INPUT），再用iptables -F INPUT清空该链，最后用iptables-restore -n加载新规则片段； -
测试配置有效性：先用
iptables-restore -t < rules.bak验证语法，无报错再执行真实还原，防止因格式错误导致防火墙失效。
审计要贯穿规则从生成到生效全过程
审计不是查“有没有备份”，而是验证“规则是否可信、是否可控、是否可追溯”：
-
比对差异是核心手段：用
diff对比前后两次iptables-save输出，重点关注跳转目标（-j ACCEPT/REJECT/DROP）、源地址（-s）、端口（--dport）等关键字段变动； -
检查默认策略是否被绕过：即使某条规则允许了 22 端口，也要确认
iptables -P INPUT DROP是否仍为默认策略，防止因策略缺失导致隐性放行； -
验证规则实际生效路径：用
iptables -L INPUT -v -n --line-numbers查看包计数是否增长，结合tcpdump抓包确认数据流是否真按预期路径匹配； -
日志联动分析：开启
LOG目标规则（如iptables -A INPUT -m state --state INVALID -j LOG --log-prefix "INVALID:"），将日志接入集中系统，与规则变更时间戳交叉分析异常访问模式。
备份是底线，恢复是能力，审计是习惯。三者缺一不可，否则所谓“防火墙”只是心理安慰。
