防火墙基线：默认拒绝 + 最小白名单

防火墙的唯一正确心智模型是「默认拒绝 + 最小白名单」：不是挡住坏的，而是只放行好的。本文给出 ufw/nftables 两套基线配置、端口审计方法与三条常见翻车，全部可复制。

2026-10-01 · AxionServe 编辑部 · 云安全

防火墙配置有两种心智模型：「列出要挡的」和「列出要放的」——前者永远列不完，后者只需要想清楚业务到底需要哪几个门。默认拒绝入站 + 最小白名单是安全行业的共识基线，本篇给出可直接复制的两套实现（ufw 简易版 / nftables 标准版）与维护纪律。本文属于安全基线中心系列；与 SSH 加固清单配套执行（动作 6 的完整版）。

第一步：端口审计——白名单的依据

配防火墙前先回答「这台机器对外提供什么」——审计命令把答案摆出来：

# ① 当前所有监听端口与对应进程（审计的起点）
ss -tlnp
# ② 逐个问三个问题：这是什么服务？必须公网可达吗？谁在用它？
#    127.0.0.1:xxxx 的监听是本地服务（数据库/缓存的正确姿势），不需要白名单
#    0.0.0.0:xxxx 的监听对全网开放——每个都要有存在理由
# ③ 典型最小集：22(SSH) + 80/443(Web)；数据库/Redis/面板端口全部不该出现在 0.0.0.0 上

审计的常见发现：数据库默认监听 0.0.0.0（装完就裸奔）、管理面板端口对全网开放、开发时起的临时服务忘了关——防火墙是最后一道网，服务本身的监听地址是第一道：能改 127.0.0.1 的先改监听，改不了的才进白名单讨论。

ufw 基线：五分钟版

# 默认策略：入站拒绝、出站放行（出站收紧是进阶话题，先不搞）
ufw default deny incoming
ufw default allow outgoing
# 最小白名单（按你的审计结果增删）：
ufw allow 22/tcp comment 'ssh'
ufw allow 80/tcp comment 'http'
ufw allow 443/tcp comment 'https'
# 办公网固定 IP 才能访问面板类端口（比全网开放安全一个量级）：
ufw allow from 你的办公IP to any port 8888 proto tcp comment 'panel-office-only'
# 启用（⚠ 确认 22 已放行且你的 SSH 会话还活着再执行；改过端口的先 allow 新端口）
ufw --force enable
# 验证：编号规则清单 + 从外部实测非白名单端口不通
ufw status numbered
nc -zv -w3 服务器IP 3306 || echo "3306 不通（预期）"

nftables 基线：标准版（无 ufw 的发行版/容器宿主）

# /etc/nftables.conf —— 默认拒绝 + 状态跟踪 + 最小白名单
flush ruleset
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;      # 默认拒绝
    ct state established,related accept                    # 已建连接的回程流量
    ct state invalid drop
    iif "lo" accept                                        # 本地回环
    tcp dport { 22, 80, 443 } accept                       # 白名单（按审计结果改）
    icmp type echo-request limit rate 5/second accept      # ping 限速放行（诊断需要）
    log prefix "nft-drop: " limit rate 3/minute            # 被拒流量采样进日志
  }
  chain forward { type filter hook forward priority 0; policy drop; }
  chain output  { type filter hook output  priority 0; policy accept; }
}
# 加载与开机自启：
nft -c -f /etc/nftables.conf && systemctl enable --now nftables   # -c 先校验再加载，防手滑断网

三条维护纪律

规则带注释——每条白名单写清「为什么开、谁要求的、什么时候可以关」；半年后没人记得的端口就是攻击面。ufw 的 comment 与 nft 的行内注释都是干这个的；
变更走「先校验后加载」——nft -c 校验语法、云防火墙先在控制台预览 diff；远程改防火墙把自己锁外面是运维经典事故，改之前确认恢复通道（IPMI/云控制台 VNC）可用；
季度复审——对照当季的 ss -tlnp 输出重跑一遍端口审计：业务下线了的端口从白名单摘掉，新服务先审计再放行。白名单只增不减的防火墙，三年后就是一份攻击面清单。

常见翻车对照表

翻车	症状	修复
改端口顺序错	SSH 非标准端口，先 deny 后想起没 allow 新端口 → 锁门外	恢复通道进单用户模式；规则顺序：先 allow 新端口再动旧的
只配了 IPv4	v6 流量绕过全部规则（双栈机器高发）	ufw 默认双栈（确认 /etc/default/ufw 的 IPV6=yes）；nft 用 inet 族天然双栈
Docker 打穿	容器端口绕过主机防火墙直接暴露	Docker 会自写 iptables/nft 规则——容器端口映射本身就是「放行」，别指望 ufw 拦它；用 --ip 绑内网地址或宿主防火墙管 DOCKER 链

出站策略：进阶但值得规划

基线版放行了全部出站（allow outgoing），这是务实起点——收紧出站的收益与运维成本都更高，适合两类场景再上：①被入侵后的外联阻断——恶意程序的回连（C2 通道）依赖出站，白名单化出站（只放行更新源、你的管理端点、业务依赖的 API）能把「进了门」的损失截断在「出不去」；②数据外流管控——合规要求数据不出境的场景，出站规则是技术抓手之一。实施口径：先跑两周日志模式（记录会被拒绝的出站目标），把业务真实依赖列全再切白名单——直接收紧的出站策略断业务的速度比断攻击快。

与云防火墙的分工

云/机房侧的网络防火墙（安全组类）与主机防火墙是两层独立的门：安全组在网络边界挡，主机防火墙在系统边界挡——两层都按「默认拒绝 + 最小放行」配置，任何一层的配置失误都有另一层兜底。优先级口径：能进安全组的规则先进安全组（离攻击者更远），主机层保留完整基线（防安全组误配）。

下一步：防火墙是SSH 加固清单动作 6 的完整版，两篇配套执行；防火墙之后的下一层是服务自身配置（数据库绑 127.0.0.1、面板限源 IP——口径见面板与备份）；全景回安全基线中心。整套基线的幂等脚本版在自动化脚本；新机器入口在售配置。