第 3 課 · 防火牆：默認拒絕與最小白名單

防火牆的正確心智模型只有一句話：不是擋住壞的，而是只放行好的——默認拒絕一切入站，業務需要什麼門就開什麼門，每個門有理由、有記錄。這一課用 ufw 走完最小基線（nftables 版與完整維護紀律見安全欄目《防火牆基線》），重點講清「白名單怎麼定」與「怎麼不把自己鎖外面」。

白名單的依據：先審計再配置

白名單不是拍腦袋，是對「這臺機器對外提供什麼」的如實回答：

# ① 當前監聽清單（每個 0.0.0.0/[::] 監聽都要過審）
ss -tlnp
# ② 三問每個監聽：什麼服務？必須公網可達嗎？誰在用？
#    127.0.0.1 監聽 = 本地服務，不用進白名單（數據庫/緩存的正確姿勢）
#    0.0.0.0 監聽 = 對全網開放，必須給出理由
# ③ 最小集的典型答案：22(SSH) + 80/443(Web)，沒了

審計中常見的「意外住客」：裝數據庫時默認監聽了 0.0.0.0、面板服務對全網開放、開發時的測試端口忘了關——防火牆是最後一道網，監聽地址是第一道：能改 127.0.0.1 的先改監聽（服務配置文件裏的 bind/listen 地址），改不了的才進白名單討論。

ufw 最小基線（五分鍾）

sudo ufw default deny incoming      # 默認拒絕入站——模型的地基
sudo ufw default allow outgoing     # 出站先全放（收緊是進階話題）
sudo ufw allow 22/tcp comment 'ssh'
sudo ufw allow 80/tcp comment 'http'
sudo ufw allow 443/tcp comment 'https'
# 辦公 IP 限定類端口（面板/數據庫管理口）：
sudo ufw allow from 你的辦公IP to any port 8888 proto tcp comment 'panel-office'
# ⚠ 啓用前三查：22 在名單裏嗎？SSH 會話還活着嗎？雲安全組不衝突嗎？
sudo ufw --force enable
sudo ufw status numbered            # 帶編號的規則清單（刪規則用編號）
# 外部驗證：
nc -zv -w3 服務器IP 22 && echo "ssh 通（預期）"
nc -zv -w3 服務器IP 3306 2>/dev/null || echo "3306 不通（預期）"

不鎖門外：遠程改防火牆的三條保險

• ①保持現有會話：ufw enable 不斷已建立的連接（狀態跟蹤放行 established）——當前 SSH 會話活着，改錯了還有挽救窗口，別急着退出；
• ②ufw limit 與 allow 順序：先 allow 必要端口再 enable，順序反了就是自鎖；改過 SSH 端口的先 allow 新端口；
• ③留後門通道：確認機房 IPMI/VNC/雲控制臺 VNC 可用（第一小時就該測）——所有軟件層鎖死時，帶外通道是唯一的門。

規則衛生：注釋、復審與只減不增的例外

每條規則帶 comment（爲什麼開、誰要的）；季度對照 ss -tlnp 復審一遍——業務下線的端口從白名單摘掉。白名單只增不減的防火牆，三年後就是一份攻擊面清單。雙棧注意：ufw 默認同時管 v4/v6（確認 /etc/default/ufw 的 IPV6=yes）；跑 Docker 的機器另有一條坑——Docker 會自寫轉發規則繞過 ufw，容器端口映射本身就是「放行」，宿主機防火牆管不住它，容器暴露面要在 docker 層面管（--ip 綁內網地址或發布到 127.0.0.1 再由反代轉發）。

與雲安全組的分工：兩層門都要管

雲/機房側的安全組與主機防火牆是兩層獨立的門：安全組在網絡邊界攔（流量到不了主機），主機防火牆在系統邊界攔。兩層都按「默認拒絕 + 最小放行」配置的理由是互爲兜底——安全組誤配（有人在控制臺順手開了 0.0.0.0/0 的 3306）時主機層還在，主機規則被腳本改壞時安全組還在。排查口徑也因此分兩層：外部連不上時，先分清是安全組擋的還是主機擋的（雲控制臺的安全組日志/主機防火牆的 log 前綴各看各的）。優先級紀律：能進安全組的規則先進安全組（離攻擊者更遠一層），主機層保留完整基線不偷懶。

本節小結

• 默認拒絕 + 最小白名單：先審計監聽（ss -tlnp）再定規則，每個放行端口有理由有注釋；
• 遠程改防火牆三保險：保持會話、先放 SSH 再啓用、確認帶外通道——順序錯了就是自鎖；
• 規則季度復審、只減不增是例外；Docker 會繞過宿主防火牆，容器暴露面單獨管。