Ubuntu 24.04 UFW防火墙配置实战指南

云服务器的安全防护，往往从「控制网络流量」这一步开始。一台暴露在公网的主机，每一个开放端口都可能成为自动化扫描和漏洞利用的入口。iptables 和 nftables 功能强大，但规则语法复杂，对刚接手服务器的开发者并不友好。UFW（Uncomplicated Firewall）正是为解决这个问题而生——它在底层网络过滤能力之上提供了一层简洁的命令行接口，让防火墙配置变成几条易读易记的指令。

本文基于一篇面向 Ubuntu 24.04 LTS 的 UFW 配置教程，梳理五个关键环节：默认策略、SSH 防锁死、Web 服务端口、IP 白名单限制以及规则清理。这些环节构成了一套完整的服务器入门安全基线。

默认策略：先拒绝，再按需放行

UFW 配置的核心思路是「默认拒绝入站、允许出站」。这一策略意味着，除非你明确开放某个端口，否则所有外部主动发起的连接都会被丢弃。对于面向公网的服务器，这是最稳妥的起点。

实际操作中，绝大多数问题都源于顺序错误：先启用防火墙、后配置 SSH 规则，结果远程连接被直接切断。教程特别强调，在开启 UFW 之前必须先放行 SSH，否则一旦断开就只能通过云服务商的控制台（VNC 或串口）介入修复。这个细节看似基础，却是新手最容易踩的坑。

UFW 的默认策略通过 ufw default 命令设置，常见组合是 ufw default deny incoming 与 ufw default allow outgoing。这里的“拒绝”并非静默丢弃（DROP），而是返回 ICMP 端口不可达（REJECT），两者在行为上有细微差异：DROP 让扫描器难以判断端口状态，REJECT 则更明确地告知连接被拒。对大多数场景而言，REJECT 足够且更符合直觉；若希望进一步隐藏主机存在，可在 /etc/ufw/before.rules 中调整策略为 DROP。此外，UFW 还支持 deny 与 reject 两种动作关键字，分别对应静默丢弃和主动拒绝，配置时可按安全需求选择。

SSH 防锁死：启用前的关键一步

在 Ubuntu 24.04 LTS 上，SSH 默认走 22 端口。配置流程应当是：先执行 ufw allow ssh（或显式指定 22/tcp），确认规则已生效，再执行 ufw enable。如果服务器改过 SSH 端口，就要放行对应的自定义端口号，而不是机械地照搬 22。

启用之后，建议保持当前 SSH 会话不要关闭，另开一个终端测试新连接是否正常。这个「双会话验证」的做法能有效避免把自己锁在门外的尴尬。放行 SSH 之后，再依次添加其他业务规则，整个过程中服务不会中断。

ufw allow ssh 之所以能生效，是因为 UFW 在 /etc/services 中查找 ssh 对应的端口（默认 22/tcp），并将其展开为一条端口规则。这意味着如果系统服务文件被修改，或使用了非标准端口，就必须显式写出端口号，例如 ufw allow 2222/tcp。另外，UFW 的规则在启用前处于“待生效”状态，ufw show added 可以查看尚未应用的规则列表，ufw status 在未启用时则显示 inactive。理解这一状态差异，有助于在启用前反复核对规则，避免遗漏关键放行条目。

Web 服务：放行 80 与 443

对于运行网站或 API 的服务器，需要开放 HTTP（80）和 HTTPS（443）两个端口。UFW 内置了应用配置档案（application profiles），可以直接用 ufw allow 'Nginx Full' 或 ufw allow 'Apache Full' 这样的语义化命令，一次放行两个端口，比逐条指定端口号更清晰。

这里有一个值得注意的设计取舍：UFW 的应用档案来自 /etc/ufw/applications.d/ 目录，安装 Nginx 或 Apache 时会自动注册。使用应用档案的好处是规则可读性强，运维交接时一眼就能看出这条规则服务于哪个服务；缺点则是依赖应用安装状态，在精简系统上可能不存在对应档案，此时仍需回退到端口号写法。

UFW 的应用档案本质上是预定义的端口与协议组合，存放在 /etc/ufw/applications.d/ 下的 INI 格式文件中。每个档案包含标题、描述和端口列表，ufw app list 可列出当前可用的档案，ufw app info 'Nginx Full' 则能查看该档案具体开放了哪些端口。除了 Nginx 和 Apache，常见的 OpenSSH、CUPS 等服务也自带档案。如果自行部署的服务没有现成档案，可以手动创建同名文件并写入端口定义，再执行 ufw app update 刷新，这样就能像内置服务一样用语义化名称管理规则。

IP 限制：把管理端口关进白名单

数据库端口、管理后台、内部 API 这类服务不应向全网开放。UFW 支持在规则中指定来源 IP，例如只允许某个固定地址访问 3306 端口。写法上可以用 ufw allow from 203.0.113.10 to any port 3306，也可以配合 proto tcp 进一步收窄范围。

这种基于来源地址的限制，是把「攻击面」从整个互联网缩小到少数可信网络的直接手段。对于需要固定出口 IP 的办公网络或跳板机场景，效果尤其明显。需要注意的是，如果管理端使用动态 IP，白名单会频繁失效，此时更适合叠加 VPN 或堡垒机方案，而不是单纯依赖 IP 规则。

规则清理：编号、查看与删除

规则积累多了之后，难免要删除过时条目。UFW 的删除方式有两种：按规则内容删除（ufw delete allow 80），或按编号删除。后者需要先执行 ufw status numbered 查看带序号的规则列表，再用 ufw delete <编号> 精确移除。

按编号删除时有一个容易忽略的细节：每删除一条规则，后续规则的编号会重新排列。因此连续删除多条规则时，应当从大编号往小编号操作，或者每次删除后重新查看列表，避免误删。这个行为在各版本 UFW 中保持一致，属于使用习惯层面的经验。

ufw status numbered 输出的编号是 UFW 根据当前规则顺序动态生成的，并非持久化标识。UFW 内部按规则添加顺序维护链表，删除操作会改变后续节点的索引，因此编号重排是必然行为。除了按编号删除，ufw delete 也接受完整的规则描述（如 ufw delete allow from 203.0.113.10 to any port 3306 proto tcp），这种方式不受编号变化影响，适合脚本化批量清理。若规则数量较多，还可以直接编辑 /etc/ufw/user.rules 文件后执行 ufw reload，但手动编辑需谨慎，语法错误可能导致防火墙行为异常。

小结

UFW 的价值不在于功能比 iptables 更强，而在于把「默认拒绝、按需放行」这套安全思路变成几条低门槛的命令。Ubuntu 24.04 LTS 上的配置流程可以概括为：先放行 SSH，再启用防火墙，然后按业务开放 Web 端口，对敏感服务叠加 IP 限制，最后定期用编号视图清理冗余规则。把这五步走完，一台云服务器的基础网络防护就算立起来了。