DigitalOcean Cloud Firewall 指南 2026 — 安全配置
DigitalOcean Cloud Firewall 是一个网络级防火墙，运行在 Droplets 外部。管理员可以通过控制面板、doctl 或 API 设置规则，系统在超级监管程序级别强制执行这些规则，然后流量才能到达实际机器。本文介绍实际的 Cloud Firewall 设置——入站/出站规则、使用标签将多个 Droplets 分组，以及在规则错误阻止流量时进行故障排除。这不是之前在其他文章中涵盖的一般安全概述。 ufw 或 iptables 的关键区别在于强制执行的位置。ufw 和 iptables 是运行在 Droplet 操作系统内部的软件。所有规则都由机器的内核存储和处理。如果 Droplet 被攻击者以 root 权限访问，或运行的服务存在漏洞，具有足够权限的攻击者可以修改或禁用 ufw 规则。相比之下，Cloud Firewall 完全从机器外部强制执行。获得 SSH 访问权限或利用服务漏洞无法改变 Cloud Firewall 规则——只有 DigitalOcean 账户才能这样做。这使其成为独立于实际 Droplet 的单独保护层。 另一个区别是管理多台机器。ufw 需要 SSH 访问来单独配置每台机器。使用 20 个 Droplets 需要相同的开放端口时，您要么重复该命令 20 次，要么编写自己的自动化脚本。Cloud Firewall 使用标签将单个规则一次性附加到整组 Droplets。编辑规则一次，它会立即对所有具有匹配标签的 Droplets 生效——无需接触每台机器。 从性能角度来看，Cloud Firewall 不会消耗 Droplet 的 CPU 或 RAM，因为它在机器外部处理流量。与 iptables 不同，它检查每个数据包但仍然使用 Droplet 的资源，在像 $4/月 512 MiB RAM 计划这样的小 Droplet 上，这个差异很重要。 推荐的方法是在纵深防御模型中同时使用这两个层，而不是选择其中之一。Cloud Firewall 作为第一个检查点过滤互联网流量，而机器内部的 ufw 作为备用方案，应对 Cloud Firewall 在某些情况下可能无法完全覆盖的连接。
目录
什么是 Cloud Firewall，它与 ufw/iptables 有何不同？
DigitalOcean Cloud Firewall 是一个网络级防火墙，运行在 Droplets 外部。管理员可以通过控制面板、doctl 或 API 设置规则，系统在超级监管程序级别强制执行这些规则，然后流量才能到达实际机器。本文重点介绍实际的 Cloud Firewall 设置——入站/出站规则、使用标签将多个 Droplets 分组，以及在规则错误阻止流量时进行故障排除。这不是一般性的安全概述。 ufw 或 iptables 的主要区别在于强制执行的位置。ufw 和 iptables 是运行在 Droplet 操作系统内部的软件。所有规则都由机器的内核存储和处理。如果 Droplet 被攻击者以 root 权限访问，或运行的服务存在漏洞，具有足够权限的攻击者可以修改或禁用 ufw 规则。Cloud Firewall 则完全从机器外部强制执行。获得 SSH 访问权限或利用服务漏洞无法改变 Cloud Firewall 规则——只有 DigitalOcean 账户可以修改它们。这使其成为独立于实际 Droplet 本身的单独保护层。 另一个区别是管理多台机器。ufw 需要 SSH 访问来单独配置每个 Droplet。使用 20 个 Droplets 需要相同的开放端口时，您要么重复该命令 20 次，要么编写自己的自动化脚本。Cloud Firewall 使用标签将单个规则同时绑定到整组 Droplets。编辑规则一次，它会立即对所有具有匹配标签的 Droplets 生效——无需单独接触每台机器。 从性能角度来看，Cloud Firewall 不消耗 Droplet 的 CPU 或 RAM，因为它在机器外部处理流量。与 iptables 不同，它检查每个数据包但仍然使用 Droplet 的资源，在像 $4/月 512 MiB RAM 计划这样的小 Droplet 上，这个差异很明显。 不过，推荐的方法是在纵深防御模型中同时使用这两个层，而不是用一个替代另一个。Cloud Firewall 作为第一个检查点过滤互联网流量，而机器内部的 ufw 作为辅助层，应对内部连接，这些连接 Cloud Firewall 可能无法完全覆盖。
- Cloud Firewall 在网络级别（网络边缘）运行，流量到达 Droplet 之前，不像 ufw/iptables 在 OS 内部作为软件运行。
- 不消耗 Droplet 的 CPU/RAM，因为数据包处理发生在机器外部。
- 使用标签一次管理单个规则并将其同步到多个 Droplets。
创建防火墙规则：入站和出站
创建 Cloud Firewall 首先要决定哪些 Droplet 组需要哪种规则类型。然后通过控制面板上的 Networking > Firewalls > Create Firewall 进行配置，或使用 doctl 进行自动化。入站规则定义谁可以连接到 Droplet。它们由三个主要部分组成：协议（TCP/UDP/ICMP）、端口或端口范围，以及您允许的源。源可以是特定的 IP/CIDR、另一个 Droplet 上的标签、负载均衡器，或对于整个互联网完全开放的 0.0.0.0/0 和 ::/0。
以下是使用 doctl 为 Web 服务器创建防火墙的示例：doctl compute firewall create --name web-firewall --inbound-rules "protocol:tcp,ports:22,address:203.0.113.10/32 protocol:tcp,ports:80,address:0.0.0.0/0,address:::0/0 protocol:tcp,ports:443,address:0.0.0.0/0,address:::0/0" --outbound-rules "protocol:tcp,ports:all,address:0.0.0.0/0,address:::0/0 protocol:udp,ports:all,address:0.0.0.0/0,address:::0/0 protocol:icmp,address:0.0.0.0/0,address:::0/0" --tag-names web
新手常犯的错误是处理出站规则。默认情况下，当您根本不设置防火墙规则时，DigitalOcean 允许所有出站流量。但一旦您定义自己的出站规则，系统就会切换到出站流量的默认拒绝模型。这意味着您必须明确打开 Droplet 需要连接的端口。最关键的是 DNS（UDP/TCP 端口 53）、NTP（UDP 端口 123）用于时间同步，以及 HTTP/HTTPS（80/443）用于 apt update 或其他包管理器。如果您忘记打开这些端口，Droplet 继续运行，但 apt update 会挂起或失败，域名解析变得不可能。
另一个关键原则是默认拒绝入站：您的规则中未列出的任何端口都会自动被阻止。与 iptables 不同，您不需要编写拒绝规则——DigitalOcean 默认阻止所有内容。这使得配置更容易理解，但您必须记住打开应用程序实际使用的端口。例如，如果您在端口 8080 上运行 Web 服务器并忘记打开它，即使 nginx 正常运行，用户也无法连接。
创建防火墙后，您可以稍后添加规则而无需删除和重新创建它。使用 doctl compute firewall add-rules FIREWALL_ID --inbound-rules "protocol:tcp,ports:8080,address:0.0.0.0/0" 或使用相同格式的 remove-rules 删除规则。这允许对运行中的 Droplets 进行增量规则调整而不影响它们。
- 入站规则定义协议 + 端口 + 源以允许。未列出的端口默认被阻止。
- 出站规则定义 Droplet 可以连接的位置。如果设置它们，您必须明确打开 DNS(53)/NTP(123)/HTTP(80)/HTTPS(443)，否则 apt update 会失败。
- 通过控制面板、doctl 或 API v2 创建。
使用标签对多个 Droplets 进行分组
标签是使 Cloud Firewall 对许多 Droplets 可管理而无需单独绑定每台机器的关键机制。想法很简单：首先创建一个标签，将该标签附加到您想要保护的 Droplets，然后将防火墙绑定到标签而不是特定的 Droplets。结果是：任何将来创建的具有相同标签的新 Droplet 会立即自动获得防火墙规则——无需手动绑定。这降低了新机器在没有适当保护的情况下被遗漏的风险。
首先使用 doctl compute tag create app-prod 创建一个标签。创建新 Droplet 时，指定标签：doctl compute droplet create web-01 --image ubuntu-24-04-x64 --size s-1vcpu-1gb --region sgp1 --tag-names app-prod。对于现有 Droplets，您可以通过控制面板在 Droplet 页面上稍后添加标签。标签就绪后，将它们绑定到防火墙：doctl compute firewall add-tags FIREWALL_ID --tag-names app-prod，并使用相同格式的 remove-tags 删除它们。
最常见的用例是频繁扩展的系统——例如，一个位于负载均衡器后面的 Web 服务器池会自动增长和缩小，或动态创建的工作节点。将规则绑定到标签而不是 Droplet ID 意味着每次出现新机器时，您都不需要额外的脚本来管理防火墙设置。这降低了您因为忘记手动绑定防火墙而意外使新 Droplet 不受保护的风险。
需要知道的一个细节是：单个 Droplet 可以同时属于多个防火墙。例如，您可能有一个每个 Droplet 都需要的 "base-security" 防火墙，加上仅添加到数据库机器的 "database-only" 防火墙。当多个防火墙重叠时，所有规则使用并集逻辑组合——如果任何规则允许，它就被允许。这意味着您必须谨慎设计标签和防火墙，以避免意外地打开比必要更多的端口。此外，标签跨越同一账户中的各个区域。这允许您在同一防火墙策略下对分散在多个数据中心（如 sgp1 和 blr1）的 Droplets 进行分组。
- 使用 doctl compute tag create 创建标签，并使用 doctl compute firewall add-tags 将其绑定到防火墙。
- 使用 --tag-names 创建的新 Droplets 无需手动绑定即可立即获得防火墙规则。
- 非常适合经常扩展的 Droplets 组，例如负载均衡器后面的 Web 服务器。
- 单个 Droplet 可以同时绑定到多个防火墙；规则使用并集逻辑组合。
- 标签在同一账户中跨区域工作，允许您在不同数据中心的 Droplets 下使用一个策略进行分组。
标准规则示例：Web 服务器 / SSH / 数据库
一旦您理解了入站/出站机制和标签，下一步是为典型的三层架构设计真实规则：Web 服务器、应用程序服务器和数据库。每一层应该有自己的防火墙或标签，而不是将所有规则组合在一个地方。
对于接收来自普通用户流量的 Web 服务器，将端口 80 和 443 对所有人（0.0.0.0/0 和 ::/0）打开，因为您提前不知道访问者的 IP 地址。对于端口 22（SSH），不要以相同的方式打开它。仅将其限制为您的办公 IP、VPN 或堡垒主机，例如：protocol:tcp,ports:22,address:203.0.113.10/32。将 SSH 打开给全世界是扫描和暴力破解攻击的主要原因。
对于中间层的应用程序服务器，如果它位于负载均衡器后面，根本不需要将其打开给互联网。仅打开负载均衡器或前端 Web 服务器调用的端口——例如端口 3000 或 8080——并将源限制为 Web 服务器的标签，而不是整个互联网。
对于数据库，要特别小心。永远不要将数据库端口（如 5432（PostgreSQL）或 3306（MySQL））打开到互联网。仅从应用程序服务器的标签打开它们。示例命令：doctl compute firewall create --name db-firewall --inbound-rules "protocol:tcp,ports:5432,tag:app-prod" --outbound-rules "protocol:tcp,ports:all,address:0.0.0.0/0,address:::0/0" --tag-names database
注意这个规则的源是 tag:app-prod 而不是特定的 IP。即使应用程序服务器获得了新的 Droplet 或其 IP 改变，规则仍然有效而无需修改。如果您使用 DigitalOcean Managed Database 而不是在 Droplet 上自主托管，通过 Managed Database 的 Trusted Sources 界面限制源，这遵循相同的原则。在将规则应用到生产之前，使用 doctl compute firewall get FIREWALL_ID 验证它们，确保您的配置符合您的意图。
- Web 服务器：将 80/443 打开给所有人；仅将 22 打开给办公 IP 或 VPN。
- 数据库：仅从应用程序服务器的标签打开数据库端口（5432、3306）——永远不要打开给互联网。
- 中间层应用程序服务器如果位于负载均衡器后面，不需要打开给互联网。
定价：完全免费，无额外成本
在实际使用中，DigitalOcean Cloud Firewall 的一个主要优势是它完全免费。无论您创建多少个防火墙、添加多少入站/出站规则或绑定多少 Droplets，都不需要额外费用。此功能包含在每个账户中，从最小的 $4/月（512 MiB RAM）Droplet 到拥有数百台机器的企业规模部署。您无需升级计划或购买任何附加组件来解锁它。这与某些云提供商分别收取安全组或高级防火墙管理费用的做法形成对比。 由于 Cloud Firewall 在网络边缘而不是作为单独的代理或网关运行，使用它不会消耗或从每个 Droplet 计划附带的 Transfer（带宽）配额中扣除。被阻止的流量首先从不到达机器，所以无论您的规则有多复杂，都不会影响您的带宽限制或 Droplet 性能。 在预算规划中，这意味着您的团队可以自由设计详细的网络分段（按环境 dev/staging/prod 或按层 web/app/db），而不用担心成本随着规则变得更复杂而增加。唯一的费用是设计和维护正确规则所需的时间，而不是 DigitalOcean 的额外费用。这与购买硬件防火墙或某些按规则数或吞吐量收费的 WAF 服务不同。 一个警告：虽然 Cloud Firewall 本身是免费的，但其他相关资源仍然正常计费。如果将其与负载均衡器配对，您仍需支付标准的 $12/月起价。如果连接 VPC（也是免费的），请注意它是一个单独的功能。计算完整的网络基础设施成本时，要仔细区分哪些是免费的，哪些要收费。
- Cloud Firewall 完全免费，无需额外成本，无论规则数或 Droplet 绑定数如何。
- 在所有 Droplet 计划上可用，从最小的 $4/月到企业部署。
- 不影响 Droplets 的 Transfer 配额，因为过滤发生在网络边缘而不是通过代理。
- 无需购买附加组件或升级计划来使用此功能。
- 相关资源如负载均衡器（$12/月）仍需正常付费。
故障排除：防火墙错误地阻止和连接检查
最常见的错误是配置错误的 SSH 规则并将自己锁定在 Droplet 之外——例如，指定错误的源 IP 或忘记包含 IPv6。好消息是：DigitalOcean 在控制面板中提供了恢复控制台（Droplet 控制台），它连接在带外，完全独立于 Droplet 的正常网络。访问它绕过 Cloud Firewall 完全，所以即使入站 SSH 规则阻止所有内容，它也能工作。在那里登录，通过控制面板修复防火墙规则，然后正常重新连接 SSH。
要验证您的规则是否符合您的意图，直接提取当前配置：doctl compute firewall get FIREWALL_ID。这会输出 JSON，包括每个入站/出站规则和绑定的标签，帮助您捕获由于错误记住您设置的内容而导致的错误。
另一个常见问题是忘记 IPv6 和 IPv4。某些客户端，特别是移动设备或某些地区网络，主要通过 IPv6 连接。如果规则仅指定 0.0.0.0/0 而不包括 ::/0，这些用户无法连接，即使您的 IPv4 机器测试成功。
当不确定连接问题是源于 Cloud Firewall 还是应用程序本身时，SSH 进入 Droplet 并在尝试外部连接时运行 tcpdump -i eth0 port 443。如果您没有看到入站数据包，Cloud Firewall 正在阻止数据包到达机器之前。回到那里并修复入站规则。如果数据包正常到达但连接仍然失败，问题可能是服务或应用程序本身，而不是防火墙。这种分离在真实情况下节省调试时间。
对于使用标签的团队，另一个常见问题是防火墙上的标签名称和实际应用于 Droplet 的标签之间的不匹配。一个字符的拼写错误——app-prod vs. app_prod——会导致无错误消息的无声失败。定期使用 doctl compute droplet list --format Name,Tags 针对绑定到您的防火墙的标签进行验证。
- 如果您意外地对自己阻止了 SSH，请使用 DigitalOcean 恢复控制台（带外，绕过 Cloud Firewall）立即修复规则。
- 使用 doctl compute firewall get 在进行进一步故障排除之前以 JSON 形式查看当前规则。
- 验证您同时打开 IPv4（0.0.0.0/0）和 IPv6（::/0）源，否则某些用户将无法连接。
- 在 Droplet 上运行 tcpdump 检查数据包是否到达；将防火墙问题与应用程序问题分开。
何时使用此功能（真实用例）
这一点很重要——Cloud Firewall 适合 DigitalOcean 上的几乎每个 Droplet 项目，但某些情况最能展示其价值。首先是多层系统，其中不同功能的 Droplets——Web 服务器、应用程序服务器、工作队列和数据库——需要内部通信但不暴露每一层到互联网。使用标签如 tier:web、tier:app、tier:worker、tier:db 并将单独的防火墙绑定到每一个，允许您精确控制层之间的连接。例如，tier:app 可以只在数据库端口上连接到 tier:db，但 tier:web 根本无法连接到 tier:db，即使在同一 VPC 中。
第二个场景是将数据库 Droplet 限制为仅接受来自应用程序服务器 IP 或标签的连接。这在自主托管 PostgreSQL 或 MySQL 的 Droplets 上很常见（不使用 Managed Database），因为数据库是主要的攻击目标。即使使用强密码，将端口 5432 或 3306 打开给互联网也会冒着扫描和利用尝试的风险。使用 Cloud Firewall 将源限制为 tag:app-server 仅消除了这个在网络层的风险，独立于任何数据库端设置。
第三个场景是用不同的防火墙集分离 staging 和生产环境。许多团队在 staging 上测试新功能，应仅供团队成员或 VPN 访问，而不是公众。创建单独的 staging-firewall 和 production-firewall 配置，分别绑定到 env:staging 和 env:prod 标签，使意外 staging 暴露的可能性较小。将 Droplet 从 staging 提升到生产就只是改变标签，这会立即应用正确的规则集而无需重新配置。
总之，Cloud Firewall 在拥有多个必须相互通信的 Droplets 的系统中大放光彩，或保护数据库等关键数据免受公共暴露的系统中。对于小型单一 Droplet 项目，单独的 ufw 可能就足够了。但从第一天起添加 Cloud Firewall 无需成本，并提供随着系统增长而扩展的保护。
- 多层应用（web/app/worker/db）：为每一层使用标签来精确控制层间连接。
- Droplet 上的自主托管数据库：将源限制为仅应用程序服务器的标签，在网络层消除扫描/暴力破解风险。
- 使用绑定到 env:staging 和 env:prod 标签的不同防火墙集来将 staging 与生产分开，防止意外的公众 staging 暴露。
- 通过改变标签将 Droplet 从 staging 提升到生产，立即应用正确的规则集而无需重新配置。
最佳实践
设计 Cloud Firewall 规则的核心原则是最小权限：仅打开真正必要的端口和源，而不是更多。每个打开比需要更宽的规则都是一个额外的攻击面，没有任何好处。在打开任何端口之前，问自己谁实际上需要连接。如果答案是 "仅另一台机器上的应用程序服务器"，指定该服务器的标签，而不是为了方便而使用 0.0.0.0/0。
接下来，尽可能优先使用标签而不是单个 IP。虽然直接指定 IP 最初看起来更容易，但随着您的系统增长，Droplets 被调整大小或重建，IPs 改变，与特定 IP 关联的规则需要不断维护。与标签绑定的规则无论 IP 如何变化都能正确工作。管理超过 5-10 个 Droplets 的团队应该从一开始计划清晰的标签结构——按层、环境和区域分离——以系统地将防火墙绑定。
定期审计防火墙规则，最好每季度一次。使用 doctl compute firewall list --format Name,InboundRules,OutboundRules 提取所有规则并检查是否有为临时测试打开但从未关闭的规则。示例包括仍然绑定的前员工 IP，或从前一次部署留下的调试端口。这些规则是无声的安全漏洞，通常不被注意直到真实事件发生。
最后，将 Cloud Firewall 与 VPC 结合以构建比任何一个单独更强的纵深防御。VPC 在网络层将 Droplets 与公共路由隔离。Cloud Firewall 按端口/协议/源过滤流量。VPC 本身不阻止同一 VPC 内的 Droplets 间连接。在顶部分层 Cloud Firewall 意味着即使 VPC 中的一个 Droplet 被攻击，攻击者在到达其他机器之前仍然面临防火墙规则。两个功能都是免费的，所以没有成本理由跳过组合使用。
- 最小权限：仅打开真正必要的端口和源，而不是为了方便而更宽。
- 尽可能使用标签而不是单个 IP——它们经受从调整大小/重建而改变的 IP。
- 通过 doctl compute firewall list 定期审计防火墙规则，至少每季度一次，寻找临时规则留下。
- 将 Cloud Firewall 与 VPC 结合以实现纵深防御，因为 VPC 单独不阻止同一 VPC 内的 Droplets 间连接。
- Cloud Firewall 和 VPC 都是免费的，所以没有成本理由不将它们一起使用。