nftables配合systemd和内核机制可构建透明可控的防护体系：通过systemd管理规则加载与热更新，结合cgroup实现服务级隔离，利用连接跟踪动态放行，并通过计数、日志与规则命名实现全链路审计。
直接用 nftables 配合 systemd 和内核机制，就能搭出比商业防火墙更透明、更可控的防护体系。它不靠图形界面堆功能，而是靠规则设计、服务感知和连接状态控制来堵住真实漏洞。
把防火墙规则变成系统服务的一部分
nftables 本身不是守护进程，但通过 systemd 单元可以做到开机加载、配置热更新、失败自动回滚。关键在于把规则文件纳入 systemd 管理：
- 把规则写进 /etc/nftables.conf（或拆成 /etc/nftables/ 下多个 .nft 文件），确保语法正确
- 启用 nftables.service：它会自动读取主配置并加载规则集
- 用 systemctl reload nftables 实现原子化更新——旧规则不停止，新规则全量替换，零丢包
- 加个 WantedBy=multi-user.target 到单元文件里，保证网络就绪后再加载防火墙
让每项服务拥有自己的网络边界
传统防火墙只看 IP 和端口，而现代服务混跑在同一主机上，必须区分“谁在通信”。nftables + cgroup v2 + systemd 可以实现服务级隔离：
- 给关键服务（如数据库、API 网关）分配独立 cgroup，例如 systemd.slice 或自定义 .scope
- 在 nftables 规则中用 @cgroup 匹配器识别流量来源：meta cgroup @mydb.slice accept
- 禁止 Prometheus exporter 访问 Kafka 的规则，不再依赖“只监听 127.0.0.1”，而是直接拦截该服务所属 cgroup 的 outbound 流量
- 配合 RestrictAddressFamilies= 和 IPAddressDeny= systemd 选项，形成策略叠加
用连接跟踪做动态放行，而不是静态端口开放
只写 tcp dport 22 accept 是危险的——它不管是谁连、连几次、有没有认证。真正可靠的放行要结合连接状态和行为限制：
- 优先用 ct state established, related accept，允许已有连接的返回包，避免重复匹配
- 对 SSH 增加连接频控：ip saddr @trusted_ips tcp dport 22 ct state new limit rate 3/minute burst 5 packets counter accept
- 用 ip protocol tcp ct state invalid drop 拦截伪造 TCP 标志的扫描包
- 把 ct timeout 和日志标记结合，比如对异常长连接打标签并记录到 journald
让每条规则都可审计、可追溯
防火墙不是设完就完的事。nftables 支持细粒度计数和日志注入，关键是要主动设计日志语义：
- 每条拒绝规则后加 counter log prefix "DROP_INPUT: "，再用 rsyslog 或 journald 过滤提取
- 用 numgen random mod 1000 给日志加随机 ID，方便关联同一攻击会话的多条日志
- 把规则名（comment "allow-nginx-to-backend"）和 systemd service 名对齐，排查时直接查服务单元
- 配合 nft monitor trace 抓实时匹配路径，验证规则是否真生效，而不是靠猜
