端口扫描入门:自查你的服务器暴露了什么
服务器买来部署完服务,怎么确认对外暴露的端口和预期一致?讲清楚端口扫描的原理、三种结果状态的含义,以及管理员的正确自查姿势。
买了服务器、部署完服务,最重要的收尾动作不是庆祝,是自查:对公网暴露的端口,和你以为的一致吗?
端口:一台机器上的不同窗口
一个 IP 定位到一台机器,端口定位到机器上的具体服务。80 端口跑 Web、22 端口管 SSH、3306 是 MySQL——每项网络服务都在某个端口上监听。
"端口扫描"就是从外部逐个敲门,看哪些端口有人应答。它不是黑客专属技术,而是所有运维的基本功——你至少要知道自己的服务器对外开了哪些门。
三种结果,三个含义
TCP 连接探测的返回有三种状态,理解它们是解读结果的基础:
开放(open)——敲门有人应,目标端口上确实有服务在监听。80/443 开放是 Web 服务器的正常状态;3306/6379 开放则多半是配置失误。
关闭(closed)——机器明确回了"这里没服务"(TCP RST)。机器在线,这个端口没人用。
被过滤(filtered)——敲门声石沉大海。通常是防火墙把包静默丢弃了,你无法知道门后到底有没有服务。安全加固过的服务器,绝大多数端口都应该是这个状态。
数据库端口为什么危险
一个常见的事故模式:开发者在服务器上装了 Redis,默认监听 0.0.0.0:6379,也没设密码。结果全网扫描器几分钟内就能发现这个口子——Redis 未授权访问可以直接写文件、加 SSH key 拿下整台机器。MongoDB 被勒索删库的事件每年都在发生。
自查看到数据库端口开放时的正确操作:
# 看服务监听在哪个地址
ss -tlnp | grep 6379
# 配置文件改成只监听本地
bind 127.0.0.1
要么改成 bind 127.0.0.1(只允许本机访问),要么用防火墙限制来源 IP。云服务器还要检查厂商控制台的安全组——它和系统内防火墙(ufw/iptables)是两层独立的墙,漏一层都不算防护。
合法与非法的边界
端口扫描工具本身中性,但未经授权扫描他人资产在很多司法辖区处于违法边缘甚至明确违法。正当的用法只有一种:扫你自己的东西——自己的服务器、公司授权范围内的资产、渗透测试签了授权书的目标。
这也是为什么正规工具都会做限制:IPchase 的端口检测只探测常用服务端口组(不做全端口穷举)、对家宽地址做了保护、并且要求你只探测拥有或已授权的目标。
自查的完整流程
给新服务器做一次完整自查:
- 从外部扫:用端口检测工具跑一遍 Web / 数据库 / 邮件三组端口
- 对照预期:预期只开放 80/443/22,多出来的每一个都要有解释
- 系统内核对:
ss -tlnp列出所有监听服务,确认没有意外的绑定 - 查两层防火墙:云控制台安全组 + 系统内防火墙规则
- 定期复查:每次部署新服务后重扫一遍,配置漂移是常态
结果里的常见误判
拿到扫描结果先别下结论,以下情况都会造成"看起来不对劲"的假象:
- CDN 挡在前面:目标域名走了 Cloudflare 之类的代理,你扫到的是 CDN 边缘节点,不是源站。源站真实端口状态要用源站 IP 测(前提是你有权访问)
- DROP 和 REJECT 的区别:防火墙 REJECT 会回 RST,扫描器报"关闭";DROP 静默丢包,报"被过滤"。安全加固建议用 DROP——不暴露防火墙规则的存在
- 安全组放行了但服务没起:探测结果"关闭"意味着路径是通的、只是没人监听,说明云安全组放行了 3306 但 MySQL 没启动——这属于"运气好",重启服务后它就直接暴露公网了,要顺手把安全组规则收紧
- IPv6 与 IPv4 不一致:很多服务器 IPv4 防护做得很好,IPv6 却裸奔。自查时两个协议族都要扫一遍
从扫描结果反推服务指纹
开放端口之外,响应特征还能透露更多:对开放端口完成 TCP 握手后读取 banner(SMTP 报的软件名版本、SSH 的 SSH-2.0-OpenSSH_8.9),攻击者据此匹配已知漏洞。管理员的对策是隐藏或伪装 banner、及时升级版本,并遵循"默认不开放"原则——每多暴露一个端口,就多一份需要持续维护安全的面。
小结
- 端口扫描是运维自查基本功,不是黑客专属
- 三种状态:开放(有服务)、关闭(明确拒绝)、被过滤(防火墙拦截)
- 数据库端口对公网开放 = 高危配置失误,改 bind 或上防火墙
- 合法边界:只扫自己的和已授权的资产
检测你的网络环境:回到首页做一次完整检测,或试试 指纹检测。