如何為您的雲端伺服器設定輕量級防火牆（UFW 配置指南）

新買的 Linux VPS 剛裝好系統，公網 IP 立刻暴露在掃描器視野裡。我們監控過一台剛開機的 Ubuntu 22.04：上線不到四小時，/var/log/auth.log 裡就出現了上千條來自全球的 SSH 暴力破解嘗試。雲端廠商的安全群組能擋一部分，但系統內的防火牆才是你真正可控的第二道防線。

對 Ubuntu / Debian 系伺服器來說，UFW（Uncomplicated Firewall） 幾乎是預設首選：語法簡潔、與 iptables 無縫銜接、文件齊全。本文不講 iptables 的幾十條鏈式規則，而是把我們在生產環境裡反覆驗證過的一套 UFW 設定流程整理成清單——從安裝、放行 SSH，到網站連接埠、Docker 共存、與雲端安全群組協同，以及最重要的：怎樣設定防火牆而不把自己鎖在門外。

前提：你已透過 SSH 或雲端主控台 VNC 登入伺服器，且具備 sudo 權限。若 SSH 已經連不上，請先參考我們的 Linux 伺服器 SSH 連線被拒排查指南，確認是網路問題還是防火牆問題，再回來繼續閱讀。

為什麼雲端伺服器必須設定防火牆？

很多人以為「買了雲端主機就有安全群組，系統裡不用再管」。實際上兩層職責不同：雲端安全群組在虛擬網卡外側過濾流量，由主控台管理；UFW在作業系統核心的 netfilter 層過濾，由你透過命令列管理。只開一層，等於只鎖了大門沒鎖臥室門——內網橫向移動、誤暴露的服務、被入侵後的反彈 shell，都需要系統層級規則兜底。

UFW 底層仍是 Ubuntu 官方 UFW 文件 所描述的 iptables 前端：你寫 ufw allow 22，它會翻譯成對應的 ACCEPT 規則。好處是語法接近自然語言，ufw status numbered 能一眼看清目前策略，修改規則也不容易把自己繞暈。

第一步：安裝與檢查 UFW

Ubuntu 桌面版和多數 Server 映像檔已預裝 UFW，但最小化映像檔可能沒有。先確認：

sudo apt update
                sudo apt install ufw -y

                # 查看目前狀態（inactive 表示尚未啟用）
                sudo ufw status verbose

                # 開機自啟（建議在 enable 之前先配好規則）
                sudo systemctl enable ufw

若輸出 Status: inactive，表示規則可以安全地一條條新增，還不會生效——這是最好的設定窗口。千萬不要在還沒放行 SSH 的情況下直接 ufw enable，否則你會立刻失去遠端連線。

第二步：放行 SSH（最重要的一條規則）

SSH 是管理通道，必須第一個放行。如果你已把 sshd 改到非標準連接埠（例如 2222），規則裡的連接埠要與 sshd_config 一致，安全群組也要同步修改。

# 預設 22 連接埠
                sudo ufw allow 22/tcp comment 'SSH'

                # 自訂連接埠
                sudo ufw allow 2222/tcp comment 'SSH custom'

                # 只允許辦公室出口 IP（建議生產環境）
                sudo ufw allow from 203.0.113.50 to any port 22 proto tcp

                # 依服務名稱（/etc/services 有定義時可用）
                sudo ufw allow OpenSSH

驗證 sshd 確實在監聽：sudo ss -tlnp | grep ssh。若看到 0.0.0.0:22 或 [::]:22，表示服務正常。若 ListenAddress 被設成 127.0.0.1，UFW 放行也沒用——那是 sshd 設定問題，不是防火牆問題。

關於 SSH 連接埠與安全群組如何配合，可參考 Linux 雲端主機最小暴露面防火牆決策 FAQ，裡面有一張 SSH/HTTPS 取捨矩陣，適合規劃長期策略。

第三步：設定預設策略

UFW 的建議基線是：拒絕所有入站，允許所有出站。出站放開，伺服器才能拉 apt 套件、存取 API、做 DNS 查詢；入站收緊，只開你明確需要的服務連接埠。

sudo ufw default deny incoming
                sudo ufw default allow outgoing

                # 查看目前規則（帶編號，方便刪除）
                sudo ufw status numbered

有人想把出站也收緊（例如合規要求），可以 ufw default deny outgoing 再逐條 allow out DNS（53）、HTTPS（443）等。但對大多數 Web / API 伺服器來說，出站全放、入站按需開，是性價比最高的方案。

第四步：開放業務連接埠

依你實際執行的服務新增規則。常見組合如下：

# HTTP / HTTPS（Nginx、Caddy、Apache）
                sudo ufw allow 80/tcp
                sudo ufw allow 443/tcp

                # 或用服務名稱簡寫
                sudo ufw allow 'Nginx Full'

                # 開發環境臨時開放 Node / 其他連接埠
                sudo ufw allow 3000/tcp comment 'dev API'

                # 指定來源 IP 存取管理面板
                sudo ufw allow from 198.51.100.0/24 to any port 8080 proto tcp

生產環境建議：能走 443 反向代理的，就不要直接暴露 3000/8080。UFW 裡只開 22 + 80 + 443 三個連接埠，應用監聽 127.0.0.1，由 Nginx 或 Caddy 做 TLS 終止——攻擊面立刻小一圈。

第五步：啟用並驗證

規則加完後，正式啟用：

sudo ufw enable
                # 會提示可能中斷現有 SSH，輸入 y 確認

                sudo ufw status verbose
                sudo ufw status numbered

在另一台機器上測試：nc -zv your.server.ip 22 應回傳 open；未放行的連接埠（例如 3306）應逾時或被拒絕。若 SSH 斷線，立刻透過雲端主控台 VNC 執行 sudo ufw disable 回滾，查清缺了哪條規則再重來。

進階：限速、刪除與規則排序

UFW 支援比 allow 更細的操作，幾個高頻場景：

# 限速：防 SSH 暴力破解（6 次/30 秒）
                sudo ufw limit 22/tcp

                # 依編號刪除規則（先 status numbered 看序號）
                sudo ufw delete 3

                # 拒絕特定 IP
                sudo ufw deny from 192.0.2.100

                # 重置所有規則（慎用）
                sudo ufw reset

ufw limit 底層用 iptables 的 recent 模組做連線頻率限制，對 SSH 很有效，但不能取代金鑰登入和關閉密碼認證。規則是按新增順序比對的，更具體的規則應放在更前面——若你發現某條 allow 不生效，檢查是否被後面的 deny 覆蓋。

與 Docker / Kubernetes 共存時要注意什麼

這是 UFW 最容易「設了等於沒設」的場景。Docker 預設會往 iptables 裡插入自己的鏈，可能繞過 UFW 的規則，導致你以為 3306 沒開，實際上容器連接埠仍對公網可見。

因應方案（依推薦程度排序）：

• 容器只綁定 127.0.0.1——-p 127.0.0.1:3000:3000，由主機反向代理對外
• 在 docker-compose 裡不寫 ports，走內部網路 + 反向代理
• 修改 Docker 設定 "iptables": false（需自行維護轉發規則，進階使用者）
• 用雲端安全群組做最終兜底，即使 Docker 繞過 UFW，外側仍有過濾

跑 K8s 的節點更複雜，通常用 Calico/Cilium 自己的 NetworkPolicy，UFW 只作為節點層級補充。單機 VPS 跑 Docker Compose 的場景，第一條（綁定 loopback）就夠用。

雲端安全群組與 UFW 如何協同

兩層都要設定，而且策略應一致：安全群組放了 22，UFW 也要 allow 22；安全群組沒放 3306，UFW 就算 allow 了，外網也進不來——但內網其他被攻破的機器可能掃得到，所以 UFW 仍要 deny。

建議分工：

• 安全群組：粗粒度，只放 22/80/443，來源 IP 可收緊到辦公室或 CDN
• UFW：細粒度，依服務註解、limit SSH、封鎖惡意 IP
• fail2ban：動態層，讀日誌自動封禁

修改任一層後，用外部探測驗證：nmap -p 22,80,443,3306 your.server.ip（請只掃自己的機器）。看到 3306 open 而你沒有主動暴露資料庫，立刻排查 Docker 綁定或應用監聽位址。

排障：UFW 啟用後服務存取不了

依這個順序查，十分鐘內能定位大多數問題：

• sudo ufw status verbose——規則是否真的在？連接埠和協定（tcp/udp）對不對？
• sudo ss -tlnp——應用是否監聽 0.0.0.0 而非 127.0.0.1？
• 雲端安全群組入站規則是否同步？
• Docker 是否繞過了 UFW？
• 暫時 sudo ufw disable 做對比測試（測完記得 enable 回來）

若只有某個來源 IP 連不上，查是否有 deny from 或 fail2ban 封禁。UFW 日誌預設不詳細，需要時可在 /etc/ufw/ufw.conf 裡設 LOGLEVEL=medium，然後 sudo ufw reload，再到 /var/log/ufw.log 裡看被拒的封包。

上線檢查清單（可直接複製執行）

新機或重裝系統後，依順序跑一遍：

sudo apt install ufw -y
                sudo ufw default deny incoming
                sudo ufw default allow outgoing
                sudo ufw allow 22/tcp comment 'SSH'      # 或你的自訂連接埠
                sudo ufw allow 80/tcp
                sudo ufw allow 443/tcp
                sudo ufw limit 22/tcp                    # 可選：SSH 限速
                sudo ufw enable
                sudo ufw status verbose

最後別忘了系統側加固：SSH 金鑰登入、關閉 root 密碼登入、定期更新 unattended-upgrades。防火牆是邊界，不是萬能藥——但它能把 90% 的自動化掃描擋在門外，讓你有時間做更深的安全設定。