去年年底帮一个朋友看他的高危云服务器，发现SSH端口从22改成了2222，端口数据库端口却还大大方方开着3306。高危我问他为什么只改一个，端口他说“22太出名了，高危3306应该没人注意吧”。端口这种想法挺典型的高危——挑自己觉得危险的改，剩下的端口听天由命。结果那台机器上跑了三个月，高危MySQL的端口error log里堆了几万条来自不同IP的认证失败记录。高危端口这事，高危不是端口看你改了哪个，而是高危看攻击者手里那份扫描清单上有没有你。

先说几个真正意义上的端口“重灾区”。

22（SSH）排第一没什么争议。高危全球每天针对22端口的暴力破解尝试量级在亿次以上，随便一台暴露在公网、密码强度一般的机器，撑不过48小时就会被撞开。我自己的几台VPS做过测试，22端口开放且允许密码登录的情况下，平均每小时收到约200次爆破尝试。改成密钥登录之后，日志立刻干净了。

3389（RDP）是另一个狠角色。2020年疫情期间远程办公需求暴涨，RDP暴露面跟着爆炸。那段时间勒索软件团伙专门扫描3389，用弱口令进去之后手动投毒。国内不少中小企业的财务机器中招，就是因为远程桌面直接映射到了公网。后来工信部专门发过通知要求排查，但到现在还有大量机器挂着3389裸奔。

445（SMB）这个端口的故事更长。2017年WannaCry用的就是445上的EternalBlue漏洞，三天之内感染了150个国家的20多万台机器。英国NHS的医院系统直接瘫痪，手术排期全部打乱。445的危险在于它不只是“被爆破”的问题，而是协议本身存在过严重的远程代码执行漏洞。即便打了补丁，内网里开着445也容易成为横向移动的跳板。

然后是数据库那一类。3306（MySQL）、1433（SQL Server）、6379（Redis）、27017（MongoDB），这四个几乎是“裸奔界”的常客。Redis尤其离谱——默认配置不设密码，绑定0.0.0.0，攻击者连上去可以直接写SSH公钥或者往crontab里塞反弹shell。2018年到2020年间，大量Redis实例被入侵后植入了挖矿程序，有的还被清了库勒索。MongoDB也差不多，早期版本默认无认证，被批量扫走数据的事情隔三差五就出一次。

还有一些端口容易被忽略。9200（Elasticsearch），默认无认证，数据随便读，2019年泄露的Elasticsearch实例数以万计。11211（Memcached），被利用做DDoS放大攻击，反射倍率能到五万倍，2018年GitHub遭遇的那次1.35Tbps攻击就是走的Memcached。5900（VNC），很多运维图省事用VNC远程管理，密码设个六位数就觉得安全了，实际上VNC的认证协议本身就不够强。

我个人的判断标准很简单：如果一个端口对应的服务，默认配置下不需要认证就能读取或写入数据，那它就不该出现在公网上。数据库、缓存、消息队列，这些都应该只监听内网地址，需要外部访问就走VPN或者跳板机。SSH和RDP如果必须开放，至少做到密钥认证加fail2ban，RDP再加个网络层认证。

端口本身没有“高危”的属性，高危的是“暴露在公网且缺乏防护”这个组合。把22改成2222，把3306改成13306，只是减少了被自动化脚本扫到的概率，挡不住有针对性的扫描。真正有效的做法是：能不开公网就不开，必须开的就上认证和限制来源IP。扫描器不会累，但你的防护得比它勤快。