Linode Cloud Firewall 配置：最小权限规则与防锁死流程
Cloud Firewall 是 Akamai Cloud 提供的有状态网络防火墙，可在流量进入或离开关联资源时按协议、端口和 CIDR 地址执行规则。官方当前将其列为免费服务，实际可用范围和界面以账户与资源页面为准。
一个防火墙可以关联多个服务，但一个服务同一时间只能关联一个云防火墙（Cloud Firewall）。为不同信任边界复用规则前，应确认这些资源确实需要相同端口和来源。
本文主要讨论 Linode 实例和网络接口。NodeBalancer 也可关联 Cloud Firewall，但只应用入站规则；出站规则对 NodeBalancer 不生效。
Cloud Firewall 不会替你维护操作系统、修复应用漏洞或配置用户权限。它应与主机防火墙、SSH 密钥和应用认证共同使用。
配置前准备
- 通过 Cloud Manager 打开并验证 Lish Console，保留不依赖公网 SSH 的恢复入口。
- 记录服务器实际监听端口、当前 Cloud Firewall 关联和主机防火墙规则。
- 确认管理员出口 IPv4/IPv6。单个 IPv4 使用
/32，单个 IPv6 使用/128；动态地址需要预先设计可靠的管理网络或回退方法。 - 保留当前 SSH 会话，并打开第二个终端用于变更后的全新连接测试。
- 列出必须公开的业务端口和实际来源，不要从“常见端口大全”直接复制规则。
服务器端可先核对监听状态：
sudo ss -lntup监听端口存在不代表应该向公网开放；应根据调用方和数据敏感度决定来源范围。
1. 创建防火墙并设置默认策略
登录 Cloud Manager，进入 Firewalls 创建规则集。建议先完成并复核规则，再关联生产资源。
常见安全基线：
- 默认入站（Inbound Policy）：
Drop - 默认出站（Outbound Policy）：
Accept
Inbound Drop 会拒绝没有被具体规则允许的入站流量；Outbound Accept 可避免在没有完整依赖清单时意外中断 DNS、更新、监控或第三方 API。
2. 添加管理入口
SSH 应使用服务器当前实际端口，并把来源限制到可信管理网络。例如管理员固定 IPv4 为文档保留地址 198.51.100.25 时：
Action: Accept
Protocol: TCP
Ports: 22
Sources: 198.51.100.25/32如果同时使用 IPv6，应单独加入实际管理 IPv6 的 /128 或经过评估的网段。不要为了省事长期把 SSH 暴露给全部 IPv4/IPv6。
管理员网络经常变化时，可以考虑固定出口的公司网络、受控跳板机或其他可审计入口。任何方案都应先验证回退，不要把“临时全网开放”变成永久规则。
3. 添加业务端口
公开 Web 服务器通常需要：
| 用途 | 协议 | 端口 | 来源 |
|---|---|---|---|
| HTTP | TCP | 80 | 仅在需要公网 HTTP 时允许所需来源 |
| HTTPS | TCP | 443 | 面向公网网站时可允许公网来源 |
| SSH | TCP | 实际端口 | 可信管理 CIDR |
数据库、缓存、运维面板和内部 API 通常不应直接暴露公网。它们应限制为实际应用服务器、VPC/私有网络或受控管理入口，并同时保留应用层认证和主机防火墙。
IPv4 与 IPv6 是两套可达路径。只添加 IPv4 限制但保留宽泛 IPv6 规则，仍可能暴露服务。
4. 检查规则顺序
Cloud Firewall 规则按页面顺序从上到下处理，具体规则的 Action 优先于默认策略。较窄、较明确的规则应放在能正确表达意图的位置。
例如需要先拒绝一个地址、再允许其余受控管理网段时：
1. Drop TCP 管理端口 from 198.51.100.66/32
2. Accept TCP 管理端口 from 198.51.100.0/24
默认入站: Drop如果把宽泛 Accept 放在前面，后续更具体的 Drop 可能永远不会匹配。保存前应从上到下逐条模拟目标流量会命中哪一条。
5. 关联资源并验证
保存规则后，将防火墙关联到目标 Linode、网络接口或其他受支持资源。一次只处理可控范围，并立即验证：
- 保留原 SSH 会话。
- 在第二个终端建立全新的 SSH 连接并执行只读命令。
- 从实际用户网络测试必须开放的 Web/API 端口。
- 从不受信任网络确认管理端口和内部端口不可达。
- 同时测试 IPv4 与 IPv6。
如果新连接失败，使用 Lish 查看地址、监听服务和主机防火墙，再修改 Cloud Firewall 规则或暂时解除错误关联。不要通过长期开放所有来源来掩盖配置问题。
6. 谨慎限制出站流量
NodeBalancer 例外：Cloud Firewall 的出站规则对 NodeBalancer 不生效；不要把本节当作 NodeBalancer 的出站控制。
大多数普通服务器保持默认出站 Accept 更易维护。若合规或威胁模型要求默认出站拒绝，应先制作完整依赖清单，包括：
- DNS 的 UDP/TCP 查询；
- 时间同步；
- 系统和语言包仓库；
- 证书签发与吊销检查；
- 监控、日志、备份和告警；
- 业务使用的数据库、邮件及第三方 API。
在测试实例或维护窗口分阶段验证，再收紧生产出站规则。仅放行几个“常见端口”可能造成难以定位的间歇故障。
故障排查顺序
- 资源是否关联到预期的 Cloud Firewall；一个服务不能同时挂载两套规则。
- 入站/出站默认策略是否符合设计。
- 流量从上到下首先命中哪条规则，Action 是否正确。
- Source/Destination 是否使用正确 CIDR，IPv4 与 IPv6 是否都覆盖。
- 服务是否监听目标地址与端口。
- 主机防火墙、应用访问控制和反向代理是否仍在拒绝流量。
- 通过 Lish 检查系统状态，不要直接清空所有防火墙规则。
变更检查清单
- Lish 和现有 SSH 会话可用。
- 默认入站为 Drop，默认出站为 Accept，除非已有经过测试的出站模型。
- SSH 只允许可信来源，且端口与实例实际配置一致。
- 数据库、缓存和面板未暴露公网。
- 规则顺序经过逐条检查。
- 关联后使用第二个终端及真实用户网络完成 IPv4/IPv6 测试。
- 变更时间、操作者、规则内容和回滚结果已记录。
通过 iVPSer 自助开通 Linode
iVPSer 提供中文服务器控制台，并支持支付宝、微信和账户余额付款。机房、套餐、操作系统和库存以实时结算页为准；服务器防火墙、安全策略和业务软件维护由客户负责。