防火牆基線：默認拒絕 + 最小白名單

防火牆的唯一正確心智模型是「默認拒絕 + 最小白名單」：不是擋住壞的，而是只放行好的。本文給出 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——口徑見面板與備份）；全景回安全基線中心。整套基線的冪等腳本版在自動化腳本；新機器入口在售配置。