2017年5月，端口漏洞WannaCry勒索病毒横扫全球，端口漏洞超过150个国家的端口漏洞20多万台电脑被锁死，医院手术被迫取消，端口漏洞工厂生产线停摆。端口漏洞事后溯源，端口漏洞攻击者用的端口漏洞就是1433端口——准确地说，是端口漏洞微软SQL Server在1433端口上暴露的弱点，配合NSA泄露的端口漏洞永恒之蓝工具，打出了一记组合拳。端口漏洞很多人第一次听说这个端口号，端口漏洞而运维圈的端口漏洞老手只会叹口气：又是它。

1433是端口漏洞SQL Server的默认监听端口。装完数据库，端口漏洞如果不做额外配置，端口漏洞它就老老实实蹲在这个端口上等着连接请求。问题在于，很多服务器直接暴露在公网，1433端口对外敞开，密码设得跟闹着玩似的——sa账号配123456，这种组合在扫描器眼里约等于没锁门。Shodan上随手一搜，全球暴露在公网的1433端口数量常年维持在百万级别，国内也不在少数。

攻击者到底怎么利用它

最粗暴的路子是爆破。sa是SQL Server的超级管理员账号，很多老系统从来没改过这个名字。攻击者拿字典跑一遍，密码稍微弱一点就直接进去了。进去之后能干什么？开启xp_cmdshell存储过程，直接执行系统命令。这意味着什么——数据库权限瞬间变成操作系统权限，想装后门装后门，想传马传马，整台服务器就是案板上的肉。

另一条路更隐蔽：利用SQL Server的注入漏洞或者已知CVE提权。比如CVE-2020-0618，SQL Server Reporting Services里的远程代码执行漏洞，攻击者通过1433端口发精心构造的请求就能触发。这类漏洞补丁出来之前，窗口期就是攻击者的黄金时间。

还有一种情况容易被忽略——内网渗透。外网1433封了？没关系。攻击者先通过钓鱼或者Web漏洞拿下一台内网机器，然后从内网横向扫描1433端口。内网环境里，数据库服务器之间的信任关系往往很宽松，一台失守，连带着一串数据库跟着遭殃。

为什么这个问题反复出现

说白了，方便和安全的矛盾。开发阶段图省事，连接字符串写死公网IP加默认端口，上线了也没人改。有些老旧业务系统跑了十几年，当初的开发和运维早就不在了，没人敢动。云服务商默认安全组规则有时候也宽松，开个1433跟开个80端口一样随意。

我见过一个案例：某中型企业的ERP数据库直接挂在公网上，1433端口开放，sa密码是公司电话号码。扫描器扫到之后，攻击者没急着加密数据，先在里面潜伏了两周，把客户表和财务表全拖走了。等到发现的时候，数据已经在暗网上挂牌出售。企业后来花了大力气做应急响应，但泄露的数据泼出去的水，收不回来。

能做的事情其实不复杂

第一，别让1433直接面对公网。需要远程连接就走VPN或者SSH隧道，这是最基本的。第二，sa账号改名或者禁用，用强密码，别用生日、电话、公司名这类能猜到的组合。第三，打补丁。微软每个月发安全更新，SQL Server的漏洞补丁别跳过。第四，如果实在要暴露，上防火墙规则限制来源IP，只放行可信地址。

还有个细节：SQL Server Browser服务监听在1434端口，UDP协议，会泄露数据库实例信息。不需要的话直接关掉。攻击者拿到实例名，爆破的针对性会强很多。

1433端口本身没有罪，它只是个通道。问题出在通道两端的人——一端是偷懒的配置，一端是贪婪的攻击者。WannaCry过去好几年了，但每天仍有大量扫描器在互联网上不知疲倦地敲着1433的门。你的服务器，门锁好了吗？