网站开放端口检测

昨天半夜，网站隔壁运维老张在群里发了个截图，开放一个扫描器对着他负责的端口测试服务器跑了一圈，结果跳出来三个开放端口：22、检测8080、网站6379。开放他愣了一下——6379是端口Redis，这服务他明明上周就停掉了。检测查了半天，网站原来是开放某个同事在部署脚本里写死了启动命令，系统重启后又给拉起来了。端口就这一个端口，检测如果被扫到且没设密码，网站等于把服务器内裤脱了挂网上。开放

网站开放端口检测，端口说白了就是拿着钥匙串挨个试你家的门锁。不是每个门都要撬开，但至少得知道哪些门是虚掩的。这事不用整得多玄乎，一条命令就能开始：nmap -sT -p- 目标IP。全端口扫描听着吓人，实际跑起来也就几分钟的事。扫描结果里，凡是显示open的，都得问一句：这服务该开吗？该对全网开吗？还是只该对某个内网IP开？

我见过最典型的翻车现场，是某个创业公司的后台管理系统。他们图省事，把管理后台直接挂在80端口上，没做任何IP白名单。结果被某个扫描脚本撞上，后台登录页连个验证码都没有，密码还是admin/123456。整个用户数据库被拖走，挂在暗网论坛上标价0.5个比特币。事后复盘，他们连端口检测都没做过，压根不知道自己的后台长什么样。

检测这事情，别指望一劳永逸。服务器上跑的服务会变，配置会改，新上线的业务可能顺手就开个新端口。我自己的习惯是每周跑一次全端口扫描，重点看两个地方：一是有没有新增的开放端口，二是之前关掉的端口是不是又冒出来了。用crontab挂个脚本，扫描结果直接推送到钉钉群，比手动检查靠谱得多。

有个细节容易被忽略——端口检测不只是看TCP，UDP也得扫。很多运维只盯着TCP的22、3306这些常见端口，但UDP的53、123、161这些端口一旦开放，同样可能被利用。比如SNMP服务如果开着默认community string，攻击者能直接读取设备配置。用nmap -sU --top-ports 100扫一遍，成本不高，但能补上不少盲区。

说句掏心窝的话，端口检测不是安全工作的全部，但它是最便宜的体检项目。你不需要立刻把所有端口都关掉，只需要知道哪些门开着，然后判断这些门该不该开。就像家里装了个摄像头，不一定能防贼，但至少知道谁在门口晃悠过。做一次检测花不了半小时，省下的可能是整个数据库的命。