iptables/nftables 防火墙实战：从入门到企业规则集

写在前面：主机防火墙不是“可选配件”

云安全组、WAF、零信任网关很重要，但它们替代不了主机防火墙。

原因很现实：

1. 云安全组管不到“同安全组内横向移动”；
2. 容器/虚拟机逃逸、误配、后门监听，最终仍落在主机协议栈；
3. 应急时，你往往需要立刻在失陷机上切断端口，等不到改完所有云平台策略。

在 Linux 上，这条防线长期由Netfilter框架承载，用户态工具经历了：

ipchains → iptables → nftables

今天企业环境里常见三种并存：

• 仍在维护的iptables规则集；
• 新系统默认的nftables；
• 上层封装：firewalld、ufw、云厂商安全组（底层仍可能落到 nft/iptables）。

本文目标不是背参数，而是帮你建立一套可落地的能力：

看得懂包怎么走 → 写得出最小开放规则 → 组织得起企业级规则集 → 迁得动 iptables 到 nftables。

一、先建立心智模型：包在内核里怎么被“审判”

1.1 Netfilter 钩子（理解比记命令重要）

一个简化的 IPv4 入站故事：

1. 网卡收包；
2. 进入 Netfilter 若干钩子（PREROUTING / INPUT / FORWARD / OUTPUT / POSTROUTING）；
3. 若目的是本机，主要在INPUT链被允许或丢掉；
4. 若需转发，走FORWARD；
5. 本机发出的包走OUTPUT。

你可以先记住实战三问：

很多人只会改 INPUT，却忘了：

• 开启 IP 转发的机器，FORWARD 才是横向关键；
• 严格企业可能限制 OUTPUT（防反弹 shell、防挖矿回连）。

1.2 默认策略：安全的第一开关

链有默认策略（policy）：ACCEPT或DROP。

入门阶段最重要的安全结论：

生产主机 INPUT 默认 DROP（或 REJECT），再显式放行必要端口。
默认 ACCEPT + 只写几条 DROP，几乎必然漏网。

1.3 iptables 与 nftables 的关系（别被名字绕晕）

• iptables：传统工具，规则按 table/chain 组织（filter/nat/mangle/raw…）。
• nftables：新一代框架与工具（nft），语法统一，集合（set）更强，更易做原子替换。
• 新内核上，iptables-nft可能是兼容层：你敲 iptables，底层映射到 nft。

检查：

iptables-Vnft--version# 看是 iptables-legacy 还是 iptables-nftupdate-alternatives--displayiptables2>/dev/null||true

企业建议：

• 新项目直接nftables 原生规则；
• 老系统可继续 iptables，但要有迁移计划；
• 避免同一台机上 firewalld / ufw / 手写 iptables / 手写 nft混治。

二、iptables 入门：用最小规则集活下来

2.1 五分钟看懂 filter 表

日常主机防火墙主要用filter表的三条链：

sudoiptables-L-n-v--line-numbers

常用目标（target）：

2.2 最小“能 SSH 管理 + Web 服务”规则（教学示例）

警告：锁 SSH 前必须确保有控制台/VNC/云厂商串口，否则可能把自己锁在门外。

#!/usr/bin/env bash# min_iptables.sh — 仅示例，请改管理网段set-euopipefailADMIN_NET="10.0.0.0/8"# 改成你的堡垒机网段PUB_IF="eth0"iptables-Fiptables-Xiptables-PINPUT DROP iptables-PFORWARD DROP iptables-POUTPUT ACCEPT# 本机回环必须放行iptables-AINPUT-ilo-jACCEPT# 已建立/相关连接iptables-AINPUT-mconntrack--ctstateESTABLISHED,RELATED-jACCEPT# 管理网段 SSHiptables-AINPUT-i"$PUB_IF"-ptcp-s"$ADMIN_NET"--dport22-jACCEPT# 公网 Web（按需）iptables-AINPUT-i"$PUB_IF"-ptcp-mmultiport--dports80,443-jACCEPT# 可选：ICMP 限速（按策略）iptables-AINPUT-picmp-mlimit--limit5/s --limit-burst10-jACCEPT# 其他入站丢弃（默认策略已 DROP）

持久化（发行版不同）：

# Debian/Ubuntu 常见iptables-save|sudotee/etc/iptables/rules.v4# RHEL 系常见serviceiptables save2>/dev/null||true# 或用 firewalld，不要混着用

2.3 两条最容易救命/害命的规则

1）ESTABLISHED,RELATED 要靠前

没有它，你放行 22 的“新连接”后，回程包也可能被自己挡死（视状态与方向而定）。状态防火墙的核心就是 conntrack。

2）先放行 SSH，再改默认 DROP

错误顺序：先INPUT DROP，再慢慢写 SSH——远程会话可能立刻断。
正确顺序：先确保管理通道规则存在，再收紧 policy，或用脚本原子应用并保留控制台。

2.4 日志怎么打才不淹磁盘

iptables-AINPUT-mlimit--limit5/min-jLOG --log-prefix"IPTables-Drop: "--log-level4iptables-AINPUT-jDROP

要点：

• 务必 limit，否则被扫端口时日志打爆；
• 前缀方便grep；
• 与《auth.log 入侵痕迹》联动：认证失败 + 端口扫描日志一起看。

三、nftables 入门：同样的策略，更干净的表达

3.1 基本对象

nftables 核心概念：

• table：如inet filter（同时覆盖 ip/ip6 很方便）
• chain：hook + priority + policy
• rule：匹配与动作
• set/map：企业规则集的灵魂（地址组、端口组）

3.2 等价最小规则（nft 原生）

#!/usr/sbin/nft -f# min_nftables.nftflush ruleset table inet filter{setadmin_v4{typeipv4_addr flags interval elements={10.0.0.0/8}}chain input{typefilter hook input priority filter;policy drop;iif"lo"accept ct state established,related accept tcp dport22ipsaddr @admin_v4 accept tcp dport{80,443}accept icmptypeecho-request limit rate5/second acceptipprotocol icmp drop# 或按策略细化}chain forward{typefilter hook forward priority filter;policy drop;}chain output{typefilter hook output priority filter;policy accept;}}

加载：

sudonft-fmin_nftables.nftsudonft list ruleset

3.3 为什么企业更爱 nftables

1. 一套语法管 filter/nat；
2. 原子替换整个 ruleset，避免“改到一半”；
3. set动态增删 IP，不必生成一千条规则；
4. 对 ip/ip6 可用inet家族统一处理。

迁移策略建议：先用iptables-translate辅助理解，再逐步重写成原生 nft，而不是长期依赖兼容层“假装还在用 iptables”。

四、从“能用”到“像企业”：规则集设计方法

企业规则集不是堆端口，而是按角色分层。

4.1 先做资产与角色分类

一句话原则：

信任边界画在网段，放行写在白名单，默认全部拒绝。

4.2 企业规则集的推荐分层（逻辑）

无论 iptables 还是 nft，建议逻辑顺序固定：

1. drop invalid（可选但有用）
2. accept lo
3. accept established,related
4. anti-spoof / bogon（按环境）
5. 管理面放行（SSH/堡垒机）
6. 业务面放行（服务端口 + 源网段）
7. 可观测（限速 LOG）
8. policy drop

顺序错了，轻则难排障，重则绕过。

4.3 用“集合”表达企业策略（nft 示例）

table inet prod { set bastion { type ipv4_addr flags interval elements = { 10.10.1.0/24 } } set app_tier { type ipv4_addr flags interval elements = { 10.20.0.0/16 } } set db_ports { type inet_service elements = { 5432, 3306 } } chain input { type filter hook input priority filter; policy drop; iif "lo" accept ct state invalid drop ct state established,related accept # 管理面 tcp dport 22 ip saddr @bastion accept # 仅应用层访问数据库端口（在 DB 主机上） tcp dport @db_ports ip saddr @app_tier accept # 记录并丢弃 limit rate 10/minute log prefix "nft-drop " drop } }

变更时，优先改 set 元素，而不是复制粘贴 200 行规则。

4.4 出站管控：企业与医院/金融更常见

默认OUTPUT ACCEPT对互联网暴露主机意味着：木马可以任意回连。

渐进策略：

1. 先只做入站加固（大多数团队从这里开始）；
2. 对高敏主机增加 OUTPUT 白名单：DNS、NTP、更新源、必要 API；
3. 日志记录被拒出站，观察一周再收紧。

示例（概念）：

# 仅允许 DNS/NTP/HTTPS 出站到已知网段（示例） tcp dport 443 ip daddr @allowed_egress accept udp dport 53 ip daddr @dns_servers accept

过严会弄挂监控与补丁，务必灰度。

五、NAT、发布与“别把防火墙当成路由器配置游戏”

5.1 常见 NAT 场景

• 主机做共享上网：MASQUERADE/snat
• 端口转发到内网：DNAT
• 容器/Kubernetes 节点：大量依赖 NAT 与转发

如果你的机器不是网关，生产上尽量：

• FORWARD policy drop；
• net.ipv4.ip_forward=0；
• 不做莫名 DNAT。

减少攻击面的同时，也减少排障复杂度。

5.2 Docker 与防火墙互相“打架”

经典坑：

• 你以为 iptables 已 DROP 某端口，Docker 却插入了自己的链把端口发布出去；
• firewalld 与 Docker 同时改规则，重启后行为怪异。

实战建议：

1. 明确“谁是唯一规则管理者”；
2. 容器暴露尽量走前置负载均衡，而不是每台节点随意-p 0.0.0.0:xxxx；
3. 查真实生效规则：nft list ruleset/iptables -L -n -v+ss -lntp。

端口监听与防火墙放行是两件事：服务没监听，放行也无；服务监听0.0.0.0但防火墙未放行，外网进不来。

六、企业规则集工程化：让防火墙可审计、可回滚

6.1 规则即代码

推荐结构：

firewall/ inventories/prod.yml nft/ base.nft roles/web.nft roles/db.nft sets/prod_nets.nft README.md CHANGELOG.md

用 Ansible/Salt 下发，变更走 MR 评审，禁止登录主机手改“永不回收的临时 ACCEPT”。

6.2 原子发布与回滚

nftables 优势动作：

sudonft-f/etc/nftables/prod.nft# 整体加载sudocpprod.nft prod.nft.bak.$(date+%F)

iptables 可用：

iptables-save>backup.rules# 出错iptables-restore<backup.rules

高阶玩法：先载入新链，确认 SSH 仍在，再切换跳转——类似“蓝绿发布”。

6.3 变更窗口与远程保险

远程改防火墙的黄金实践：

# 例：5 分钟后自动恢复旧规则（先备好 rollback）echo"nft -f /etc/nftables/backup.nft"|at now +5minutes# 确认没把自己锁死后，取消 at 任务

或使用screen/tmux+ 云控制台兜底。

6.4 观测指标

企业至少要能回答：

• 每秒 drop 多少；
• 哪些端口被扫最多；
• 管理端口是否出现非堡垒来源；
• 规则条数/集合大小是否异常膨胀。

把LOG前缀送入 SIEM，与 auth.log 的爆破事件关联，效果远好于孤立看防火墙。

七、从 iptables 迁到 nftables：可执行路线图

7.1 评估

iptables-save>/root/iptables.backup# 尝试翻译（辅助，不可盲信）iptables-restore-translate-f/root/iptables.backup2>/dev/null|head

检查是否使用：

• 复杂 multiport/u32；
• ipset（可对应 nft set）；
• 第三方脚本频繁iptables -I。

7.2 迁移步骤

1. 备份并文档化现网策略意图（不是只备份命令）；
2. 在测试机用 nft 重写“意图”；
3. 对比放行矩阵（管理/业务/健康检查）；
4. 业务低峰切换；
5. 观察一周，下线 iptables 兼容层依赖。

7.3 双栈

今天只写 IPv4 不够。优先用：

table inet filter { ... }

同时覆盖 ip/ip6，避免“IPv4 锁死、IPv6 敞开门”。
若暂时不用 IPv6，也应明确：是禁用协议栈，还是防火墙默认丢弃，并写进基线。

八、实战场景配方（可直接改网段复用）

场景 A：单机公网 Web + 堡垒机 SSH

• INPUT DROP
• 放行：lo、established
• 22 仅堡垒网段
• 80/443 任意或仅 CDN 回源网段
• 限速 LOG + DROP

场景 B：内网应用机（前置 SLB）

• 业务端口仅 SLB/前置网段
• SSH 仅堡垒
• 拒绝其它横向

场景 C：数据库机

• 仅应用网段访问 3306/5432
• SSH 仅堡垒
• 禁止其它入站
• 可选：禁止出公网（除补丁源）

场景 D：临时封禁攻击 IP（nft set）

sudonftaddelement inet filter blacklist{203.0.113.66}# 规则中：ip saddr @blacklist drop

比临时iptables -I INPUT -s ... -j DROP更可管理。

九、常见失误清单（血泪汇总）

1. 先 DROP 后加 SSH，把自己锁死；
2. 忘了 lo，本机服务异常；
3. Docker/Kubernetes 与手写规则混战；
4. 只挡 IPv4，不挡 IPv6；
5. 用 REJECT 对全网扫描狂回包，既吵又可能助长探测；
6. LOG 无限速，磁盘与费用爆掉；
7. 临时 ACCEPT 永久遗忘；
8. 把 OUTPUT 一刀切却不放 DNS，机器“假死”；
9. 云安全组已放行就以为主机也安全（或反过来）；
10. 规则意图不写文档，三年后无人敢动。

结语：企业规则集的本质是“默许权”管理

防火墙规则看起来是技术细节，本质是组织在问：

默认情况下，谁有权跟这台机器说话？

入门用 iptables 建立直觉；
进阶用 nftables 的 set 与原子加载做工程；
企业级则把规则变成可评审、可回滚、可观测的策略代码。

当你能随口说出某台 DB 机“只允许应用网段的 5432 + 堡垒机 22，其余 DROP，IPv6 同样如此，变更走仓库”，
你就已经从“会敲几条命令”，走到了“能守住企业边界”的实战水位。

附录 A：日常运维命令速查

# iptablesiptables-L-n-v--line-numbers iptables-Siptables-save# nftablesnft list ruleset nft list sets nftaddelement inet filter admin_v4{10.1.2.3}nft delete element inet filter admin_v4{10.1.2.3}# 对照真实监听ss-lntp