定期审查公网暴露端口需建立可重复、可验证、带反馈的机制，覆盖监听地址、防火墙规则、网络路由三环节，并结合敏感度分级、自动化基线比对与连接行为日志联动分析。
定期审查暴露在公网的服务端口，本质是主动发现“不该开却开了”的风险入口。不能只靠一次配置就放任不管，必须建立可重复、可验证、带反馈的审查机制。
识别真实公网暴露端口
很多管理员误以为“防火墙没放行=不暴露”，但实际暴露取决于三个环节同时生效：服务监听地址 + 防火墙规则 + 网络路由/NAT配置。缺一不可。
- 从服务器内部检查监听范围：
ss -tuln | grep ':'，重点看 Local Address 列——若显示0.0.0.0:22或*:3306，说明服务绑定在所有接口，已具备暴露条件 - 确认是否真被防火墙放行：
firewall-cmd --list-all --zone=public，检查 ports/services/rich-rules 三类中是否有对应条目 - 跳出服务器视角验证：用外部工具（如本地电脑或云上探测机）执行
nmap -sS -p 22,80,443,3306,5432 your-server-ip，结果为open才算真正暴露
建立自动化端口基线与比对脚本
人工逐条核对容易遗漏，应固化一套轻量级检查逻辑，每天或每周自动运行并告警异常变化。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 生成当前可信基线：
ss -tuln | awk '$5 ~ /:[0-9]+$/ {print $5}' | sort -u > /etc/firewall/port-baseline.txt - 编写简易比对脚本（保存为
/usr/local/bin/check-public-ports.sh）： - 提取当前监听端口（排除 127.0.0.1 和 ::1）：
ss -tuln | awk '$5 !~ /^127\.|^::1/ && $5 ~ /:[0-9]+$/ {print $5}' | cut -d':' -f2 | sort -u - 对比基线，输出新增或消失的端口：
comm -3 - 搭配 cron 每日执行：
0 3 * * * /usr/local/bin/check-public-ports.sh >> /var/log/port-audit.log 2>&1
按服务敏感度分级标记并审计
不是所有开放端口风险相同。审查时要结合业务上下文打标签，优先盯紧高危项。
-
高危端口：SSH（22）、数据库（3306/5432/27017）、管理后台（如 8080/9000），必须满足：仅限特定 IP 访问 + 绑定内网或回环地址（如 MySQL 设为
bind-address = 127.0.0.1）+ 富规则限制源地址 - 中危端口：HTTP/HTTPS（80/443）、API 服务（如 3000/8000），需确认启用 HTTPS、有 WAF 或反向代理前置、无调试接口残留（如 /phpinfo、/actuator）
- 低危端口：健康检查（/health）、Metrics（/metrics），应限制访问来源（如只允许监控系统 IP）且不返回敏感信息
- 每次审查后更新服务清单表，注明端口、服务名、绑定地址、防火墙区域、访问控制策略、上次审计时间
集成日志与行为联动验证
端口开着只是静态状态，真正危险的是谁在连、怎么连。审查必须延伸到连接行为层面。
- 开启 firewalld 日志：
firewall-cmd --set-log-denied=all，检查/var/log/firewalld中高频被拒的源 IP，判断是否遭扫描 - 对关键端口（如 22、5432）启用连接记录：
journalctl -u sshd --since "1 week ago" | grep "Accepted\|Failed"，统计失败登录次数，触发 fail2ban 封禁 - 用
tcpdump -i any port 22 -c 50 -w /tmp/ssh-sample.pcap抓包抽样，确认协议交互是否符合预期（如无明文密码、有密钥协商） - 将异常连接事件（如非运维时段大量 SSH 尝试）接入简单告警，例如通过 mail 或 webhook 发送通知
