nftables精细化控制业务端口核心是状态识别、端源组合约束与规则顺序设计：首放established/related，再限new连接；用匿名集合高效匹配多端口；按来源分级限制并默认drop，出站同样白名单管控。
用 nftables 精细化控制业务端口，核心不是“多开几个端口”，而是“让每个端口只服务该服务、只响应合法连接、只允许可信来源”。它靠三件事落地：连接状态精准识别、端口与源的组合约束、以及规则执行顺序的严格设计。
先保连接状态，再放新入口
不加连接状态的端口放行等于敞开大门。nftables 必须区分“已建立的通信”和“新发起的请求”：
- 首条规则应放行 established,related 流量，保障 SSH 回包、HTTP 响应、DNS 返回等正常通行
- 后续规则才处理 new 连接，且必须显式加上 ct state new
- 错误写法：
nft add rule inet filter input tcp dport 443 accept（无状态，易被伪造 SYN 包触发） - 正确写法：
nft add rule inet filter input ct state established,related accept，再跟nft add rule inet filter input tcp dport 443 ct state new accept
用匿名集合统一管控高频变更端口
当 Web、API、监控、日志等多个服务共存时，避免为每个端口单独写一条规则。匿名集合让一条规则覆盖多个端口，同时提升内核匹配效率：
- 写法简洁：
nft add rule inet filter input iifname "eth0" tcp dport { 443, 3000, 9090, 5044 } ct state new accept - 内核只需一次哈希查找，而非逐条比对 4 次；规则越靠前，收益越明显
- 支持 IPv4/IPv6 双栈（用 inet 地址簇），无需重复配置
- 注意：{ } 内只能同协议同字段，比如不能混写
tcp dport {80} udp dport {53}，需拆成两条
按来源分级放行，拒绝裸奔式开放
业务端口从来不是“谁连都行”，而是“谁在什么条件下能连”。结合源地址、接口、连接频率做叠加限制：
- 管理端口（如 22、9001）只允许可信运维 IP：
nft add rule inet filter input ip saddr { 203.0.113.10, 203.0.113.11 } tcp dport { 22, 9001 } ct state new accept - 对外 API 端口（如 3000）加连接数限制，防扫描与慢速攻击：
nft add rule inet filter input tcp dport 3000 ct state new limit rate 5/minute burst 10 packet counter accept - 敏感后台（如 9090）绑定特定网卡：
iifname "eth0"，避免从 Docker 或桥接网卡误入 - 所有未匹配规则默认 drop，确保策略闭环：
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }
出站也需白名单，堵住反向渗透链路
攻击者常通过被黑服务主动外连 C2 服务器。OUTPUT 链同样要执行“默认拒绝 + 显式白名单”：
- 设 OUTPUT 默认策略为 drop：
nft add chain inet filter output { type filter hook output priority 0 \; policy drop \; } - 仅放行必要出站：DNS（53/udp）、NTP（123/udp）、HTTPS 更新（443/tcp）、监控上报（如 9091/tcp）
- 记录异常外连便于溯源：
nft add rule inet filter output meta l4proto tcp th dport != { 443, 53, 123 } log prefix "OUT_BLOCK: " drop - 避免用
-d 0.0.0.0/0粗放放行，改用 ipset 或动态集合管理可信目标 IP 段
