最小化开放端口的原则与实践

每一个对公网开放的端口，都是一条潜在的攻击路径，而其中很多路径根本没人需要。最小化开放端口的原则就一句话：不是必须的，一律不开。 先说为什么默认收着。服务每多开一个端口，就多一个组件在公网暴露，版本缺陷、配置失误、弱口令，任何一处都会成为入口。以 Redis 为例，默认监听 6379，历史上大量机器不设密码直接裸奔，被扫到后写入计划任务拿下服务器权限的案例多到数不清——而这些机器大多根本不需要把 Redis 开给公网。攻击者是全网扫描的，开放的面越小，被扫中的概率就越低，这是最朴素的比例关系。 实践按三步走。第一步盘点：用 ss -tulnp 列出当前所有监听端口，标清每个端口对应的服务与使用者，不漏过一个。第二步定级：分成三类——必须对公网开放的，如 Web 的 80、443；仅限内部访问的，如数据库、缓存、消息队列；完全无用的，比如装完系统顺手启动的示例服务。拿不准某个服务属于哪一类的，先按内部访问处理，出问题再放宽，反向操作的代价大得多。第三步收口：公网侧在云安全组配白名单，只放行 80、443 与指定来源的管理端口；内部服务绑定内网地址，数据库用 bind-address 限定内网；无用的服务直接禁用，systemctl disable --now 服务名。 防火墙策略配合默认拒绝：firewalld 或 iptables 的入站默认规则设为 drop，再逐条添加放行。云安全组与主机防火墙两层都做，互为冗余，单层配置失误时还有一层兜底。 定期审计让收口不回潮。每季度重跑一次 ss -tulnp 与上次的记录对比，新增监听逐个核实；再从公网侧对自家 IP 做一次端口扫描自查，站在攻击者的视角看自己暴露了什么。新服务上线时，把"申请开端口"并入发布流程，写明端口、来源、期限，端口管理才能长期维持最小化，而不是收一阵又松一阵。