TG咨询防火墙规则配置的重点，不是把端口全部关闭，而是明确谁能在什么时间、通过什么协议访问什么服务。以一个同时运行网站、GitLab Runner 和监控平台的网络为例，网站可能需要接收公网请求，构建节点只需访问代码仓库和制品存储，监控组件则应只读取指定指标接口。把这些需求写成独立规则，通常比一条“允许全部流量”的规则更容易审计和回滚。
一、采用默认拒绝，再逐项放行
默认拒绝适合边界防火墙、云安全组和服务器本机防火墙。它的核心是先阻断未被明确允许的连接，再根据业务清单增加例外。这样即使新部署的服务忘记登记，也不会自动暴露给整个网络。
- 列出必须提供的服务、访问来源、目标地址、协议和端口。
- 将入站和出站策略分别梳理，避免只关注外部访问。
- 先在测试区域应用规则，确认网页、任务队列和监控采集均正常。
- 分批切换生产流量，保留原规则备份和回退顺序。
二、把来源范围缩小到实际需要
来源地址应尽量使用具体主机、应用网段或经过认证的代理，而不是直接填写整个企业网或全部公网地址。例如，Grafana 访问 Prometheus 时，可以只允许监控管理网段到指标服务；外部用户访问企业门户时，则应仅开放反向代理节点到应用服务器的连接。
对于办公网络、访客网络和运维网络，应分别设置访问范围。若供应商只在周一至周五的维护窗口接入，可配合时间条件或临时启用规则，而不是长期保留宽泛白名单。
三、按服务和方向拆分规则
一条规则同时允许多个端口、多个协议和多个目标，排障时很难判断实际影响。更稳妥的防火墙规则配置是按业务动作拆分，例如“反向代理访问应用接口”“构建节点上传制品”“监控服务器读取指标”，并在备注中写清负责人、用途和复核日期。
入站与出站要分别判断
网站入站通常集中在网页服务所需协议；应用服务器出站则可能需要访问时间服务、代码仓库或对象存储。出站控制可以减少恶意程序向外连接的机会，但不能简单设置为全部禁止，否则软件更新、证书校验和告警通知可能中断。
四、正确处理规则优先级
多数防火墙按从上到下、从精确到宽泛的方式匹配规则，但不同厂商实现可能存在差异。应先查阅设备文档，确认是否支持首条命中、显式拒绝或策略组继承。通常，针对单个服务的允许规则应排在覆盖范围更大的拒绝规则之前，临时封禁规则则应放在相关允许规则之前。
修改前可导出当前策略，并记录规则编号、变更人、原因和失效时间。新增规则后，用实际业务请求验证，而不只是使用端口探测；例如检查登录、文件上传、任务执行和告警推送等完整链路。
五、限制管理入口并增加时间边界
管理面不应与普通业务入口使用相同的访问条件。可以要求管理员先进入企业 VPN，再从指定运维网段访问管理界面，同时结合多因素认证、最小权限账号和短时授权。临时维护结束后，立即停用临时规则，而不是依靠人工记忆。
如果设备支持对象组和时间计划，可为外部厂商建立独立地址组、独立服务组和到期时间。无法自动到期的平台，则应把失效日期写入工单与规则备注，并安排复核。
六、用日志审计验证规则效果
日志审计是防火墙规则配置闭环的重要部分。至少应记录命中时间、源地址、目标地址、协议、端口、动作和规则编号。上线后的前几天重点观察被拒绝连接是否来自合法业务，避免把正常依赖误判为攻击。
- 连续出现大量不同目标端口的拒绝记录，可能是扫描或配置错误。
- 同一应用突然出现出站目的地变化，应检查进程、凭据和部署任务。
- 允许规则长期没有命中，可评估是否删除或缩小范围。
- 拒绝日志暴增且伴随业务错误率上升，应先确认是否误封，再决定回退。
| 检查项目 | 建议做法 |
|---|---|
| 变更前 | 导出策略、标记依赖、准备回退方案 |
| 变更中 | 先小范围启用，观察连接、错误和延迟 |
| 变更后 | 复核日志，验证业务功能并删除无效规则 |
常见问题
规则越多是否越安全？
不一定。规则应足够精确且便于维护，重复、过期或互相覆盖的规则反而会增加误配风险。
只限制入站流量可以吗？
不建议。出站访问同样可能暴露敏感信息，应根据应用依赖设置必要的目的地和服务范围。
修改后多久复核一次？
关键业务建议在变更后立即复核，并在约一至三个月内重新检查长期规则；临时规则应在任务结束时复核。
发现误封时应怎么处理？
先依据日志定位规则和受影响业务，再临时恢复最小范围访问，同时补充更精确的允许条件，避免直接开放全部来源。
一套可靠的防火墙规则配置，应同时具备明确用途、最小来源、可追踪变更和可验证结果。完成六项检查后，还要随着服务、网络和人员变化持续清理规则，才能让访问安全性保持在可控水平。
