2017年5月12日，远程周五。漏洞英国NHS的补丁电脑屏幕上突然跳出一张红色窗口，要求支付300美元等值的远程比特币。医生们发现X光片打不开了，漏洞急诊室的补丁排班系统瘫了。同一天，远程全球150个国家的漏洞20多万台机器遭遇了同样的画面。这就是补丁WannaCry，它利用的远程漏洞编号是MS17-010，微软在两个月前——3月14日——已经发布了补丁。漏洞

问题出在哪？补丁大量Server 2012 R2还在裸奔。有些是远程IT管理员没当回事，觉得“我们内网隔离了”；有些是漏洞补丁管理流程太长，测试部门排期排到了夏天；还有些更离谱——系统跑着某个关键业务，补丁重启窗口要等季度停机。

补丁到底修了什么

MS17-010对应的是SMBv1协议里的远程代码执行漏洞。攻击者不需要认证，直接往445端口发个特制数据包，就能在目标机器上以SYSTEM权限跑代码。听起来很抽象？换个说法：你的服务器只要开着445端口、没打补丁，攻击者坐在星巴克连上WiFi就能把它变成肉鸡。

微软的补丁KB4012213（Server 2012）和KB4012216（Server 2012 R2）修复了SMBv1里三个内存破坏漏洞。装完补丁后，系统会拒绝那些畸形请求。但有个坑：补丁不自动禁用SMBv1，你仍然需要手动关掉它，或者至少限制445端口的访问来源。

为什么Server 2012用户特别危险

Server 2012和2012 R2的主流支持分别在2018年10月和2023年10月结束。WannaCry爆发时，2012 R2还在主流支持期内，补丁是免费推送的。但很多企业用的是OEM授权或者批量许可，WSUS服务器配置混乱，导致补丁根本没推下去。我见过一个案例：某制造企业的ERP跑在2012 R2上，IT主管说“我们买了防火墙”，结果防火墙规则里445端口对全网段开放，理由是“方便文件共享”。

更麻烦的是，Server 2012 R2默认启用SMBv1。这个协议诞生于1980年代，设计时压根没考虑安全。永恒之蓝利用的就是SMBv1处理畸形请求时的缓冲区溢出。你打了补丁，但SMBv1还在跑，攻击面依然存在。正确做法是：装KB4012216，重启，然后进注册表或PowerShell禁用SMBv1，最后用Get-SmbServerConfiguration | Select EnableSMB1Protocol确认状态。

实际操作中的几个坑

补丁装完要重启。生产环境里重启不是小事。有个客户跑了200多台2012 R2虚拟机，分批重启花了三天。期间业务降级运行，订单处理慢了40%。但比起被加密，这点代价算什么。

还有依赖关系问题。某些老版本SQL Server或者第三方备份软件依赖SMBv1，你一禁用，它们就报错。解决办法是先在测试环境验证，或者用SMBv2/3的兼容模式过渡。微软后来出了个SMBv1的“审核模式”，可以先记录谁在用，再决定怎么迁移。

补丁本身也有版本要求。Server 2012 R2必须先装KB2919355（Windows 8.1 Update的对应版本），否则KB4012216会安装失败。这个前置补丁2014年就发布了，但很多长期不更新的机器根本没见过它。

现在还能做什么

如果你手里还有Server 2012 R2在跑，先查补丁号：wmic qfe | findstr KB4012216。没有就赶紧装。装完重启后，用netstat -an | findstr :445看谁在监听。如果业务不需要文件共享，直接防火墙封掉445入站。需要的话，限制源IP。

微软后来把SMBv1的默认状态改成了“禁用”，但那是2017年秋天的事，只影响新装系统。老系统不会自动变。我自己的做法是：所有2012 R2服务器打全补丁后，用组策略推一个注册表项，把SMBv1关掉。重启后观察一周事件日志，有报错再单独处理。

WannaCry过去七年了，永恒之蓝的利用代码还在GitHub上挂着。没打补丁的2012 R2就像没锁的后门，平时没人注意，一旦被扫到就是灭顶之灾。补丁不大，几百KB，重启一次的事。别等屏幕变红再后悔。

(责任编辑：焦点)