当黑客让你的超市冷柜化冻：OT安全启示

想象你是里昂一家超市的夜班经理。凌晨3点，夜班员工发现冷冻柜上的霜开始融化。紧接着，压缩机报警此起彼伏，不是某一条货架，而是整家店。等有人弄清状况时，冷库已被远程下令进入除霜模式，价值数千欧元的冷冻商品正悄悄升温，逼近法定报废的临界点。今年法国几家连锁超市的制冷控制器遭攻击，大致就是这样的情景。对于还觉得运营技术（OT）安全与自己无关的人，这是一记很及时的警钟。

这次攻击并非什么好莱坞级别的漏洞利用链。据报道，攻击者触发了暴露在互联网上的制冷控制器的自动除霜周期，这些设备是某大型工业厂商的商用机型，影响迅速蔓延到多个国家的门店。与此同时，一起独立事件迫使一家比荷卢食品集团下线部分IT系统，配送与交付因此受阻。是巧合还是有组织的协同，结果都一样：物理世界通过数字世界被攻破了。

冷柜为什么要联网？

这个故事引发的最常见反应（评论区到处都是）大致是：“你为什么要把冰箱接入互联网？”这话听起来像是反问，但其实有现实的答案。如果我们一直假装没有答案，这场争论每隔几年就会重演一次。

商用制冷设备可不是一台冰箱。一家中型超市运行的是一套分布式热力系统：几十个展示柜、步入式冷藏库和冷冻库、压缩机机组、冷凝器，全部由控制器统一调度，在温度与能耗成本之间寻求平衡。远程联网的商业价值是实实在在的：

• 远程诊断。为数百家门店提供服务的制冷承包商，可以在压缩机故障之前几天就从数据中看出端倪。派技术人员上门按一下除霜按钮，成本不低；远程下发指令则几乎零成本。
• 能耗优化。超市是单位面积能耗最高的建筑之一。连锁企业可以在整个门店网络中统一调整柜体温度和除霜计划，部分企业还参与需求响应项目，在电网吃紧时由电力公司付费让其削减负荷。
• 合规记录。食品安全法规要求持续的温度记录。联网控制器能自动生成审计日志，不再需要手写记录表，也杜绝了伪造纸质记录的可能。
• 车队对比。如果你运营2000家门店，能发现某一家店的压缩机比同行多耗电15%，就能在小泄漏演变成五位数的维修账单之前把制冷剂泄漏找出来。

所以联网本身并不愚蠢。愚蠢的是实现方式。早期报道显示，许多控制器可以直接从互联网访问，有些还自带蜂窝调制解调器和SIM卡，挂在公网IP上，没有VPN、没有网关、没有白名单。据一篇广泛转载的文章称，认证形同虚设：用户名是admin，密码则由当天日期推导而来。这已经不是攻击面，而是一扇敞开的门，门口还摆着欢迎垫。

真正的OT攻击是什么样子

软件工程师通常把网络攻击想象成数据窃取：被导出的数据库、泄露的凭据、勒索软件的赎金通知。OT攻击在本质上就不同，而不只是程度的差异。攻击的目标不是信息，而是一个物理过程；攻击载荷也不是加密，而是发送给一台“谁来都信”的设备的、看起来合法的指令。

注意这次除霜攻击有多“优雅”。攻击者不需要编写恶意软件，不需要提权，甚至不需要完全理解协议。除霜周期是控制器的正常、授权功能，存在的原因是蒸发器盘管上会结霜，必须定期融化。攻击者只是在非计划时间、大规模地调用了它。没有任何安全联锁被触发，因为从控制器的角度看，并没有收到任何异常请求。这就是OT领域的“混淆代理人”问题：设备忠实地执行了它本不该接收的指令。

这种模式的普遍性令人沮丧。有人只是拖动了加药滑块，水处理厂就“被攻击”了；楼宇管理系统则通过暖通空调供应商的远程访问通道被接管。几乎每一次，危险的能力都不是漏洞，而是功能，只是被那些本不该触及它的人够到了。所以，解决之道不是更好的代码审查，而是架构。

最危险的OT漏洞往往不是内存破坏类缺陷，而是把合法功能暴露给了非法调用者。

没人打的那个补丁

这里有个细节，任何安全工程师听了都会心里一紧：这些控制器的底层漏洞早在几个月前就已通过与厂商协调的披露流程公开。安全研究人员发表了详细的分析文章，至少部分型号已经有补丁，但攻击还是发生了。

这是工业环境打补丁的内幕。企业IT其实很幸运：高危CVE一出，几天之内补丁管理工具就会提醒、分批、部署。OT可不是这样运作的。超市冷柜里的控制器可能要运行十五年。它归门店所有，由第三方制冷承包商维护，由厂商生产，又由一个六年前就离职的安装人员配置。那么，到底谁该负责在分布于九个国家的2400个站点上安装固件更新？实际上：没有人。

更糟的是，厂商似乎在发布修复时并没有明确标注其为安全关键更新。对于手头堆满真实故障设备的维修承包商来说，“有可用的固件更新”读起来就像一件可选的杂活。这既是技术问题，也是沟通问题。如果你发布的补丁修复的是一个让陌生人能让整个国家的食品化冻的漏洞，那发布说明就该用设施经理一眼就看得懂、不会漏看的话把它说清楚。规范与实现之间的鸿沟不仅会制造漏洞，还会造就整批未打补丁的设备，而运营者根本不知道它们存在风险。

故障安全默认值：为最糟糕的那一天做设计

我们来谈谈什么才是好的做法，因为这里的原则并不新奇。它们与我们在安全关键软件中采用的防御性设计思路如出一辙，只是在OT领域很少被真正执行。我之前写过防范灾难的防御性工程，而制冷控制器正是这一理念的教科书式案例。

限制危险状态的变更频率

偶尔运行一次除霜在物理上是安全的，但持续运行就会造成破坏。因此应当在固件中强制执行物理规律：一次除霜完成后，无论收到什么远程指令，都要在最短间隔内拒绝再次执行。能发送一次除霜请求的攻击者，就能发送一千次；设备不应执行超出物理允许范围的操作。这只需几行代码和一个定时器，却能限制任何控制平面被攻陷后的影响范围。

本地联锁优先于远程权限

如果柜内温度已超过阈值，或产品传感器显示温度偏高，那么远程除霜指令就应当被拒绝，并且要留下醒目的日志。控制器手里有传感器数据，完全能判断一条指令是否荒谬，那就让它用上这些数据。会把系统推向已知危险状态的指令，根本不算指令，而是一个错误。

用签名的指令，而不是密码

嵌入式设备上的密码基本是注定失败的：它们会沿用默认值、被多台设备共用、被写在便利贴上，或者直接由日期推导出来。更可靠的模型是非对称的：控制器对每一条远程指令校验签名，公钥在部署时写入，对应厂商或运营方的私钥。这样一来，偷到密码已经没用，攻击者需要的是签名密钥，而它应该保存在运营中心的HSM里，而不是散落在2400台冷柜上。是的，这意味着需要密钥管理、轮换和吊销基础设施。也确实值得。软件更新的这个问题十年前就解决了，指令通道同样应该得到这样的对待。

假定网络是充满敌意的

只要设备出厂时带着蜂窝调制解调器和默认凭据，它很可能在部署后几周内就出现在暴露设备的搜索引擎里。唯一持久的解决办法，是按照“这种情况必然发生”来设计：默认拒绝入站连接，只允许出站遥测数据发往代理，管理平面只能通过双向认证的隧道访问。“不要把它暴露在互联网上”是一条建议；“让暴露也能扛得住”才是工程。

隔离不是可选项：正确的网络分段

每一个OT安全框架（IEC 62443、NIST的指导文件，以及经典的Purdue模型）说的都是同一件事：控制系统不要放在扁平网络里。然而冷柜上的蜂窝调制解调器恰恰是这种反模式的化身。它完全绕过了企业防火墙，制造出成千上万个无人监控、可单独寻址的入口，安全团队甚至可能根本不知道它们的存在。

真正可行的架构大致如下：

1. 控制器部署在专用的OT VLAN中，没有通往互联网的路由，也没有通往企业IT的路由。只有一个网关能与它们通信。
2. 网关执行协议白名单：控制器只与网关通过Modbus或厂商协议通信，不得使用其他协议。这里的异常流量是高价值告警，因为合法流量既枯燥又可预测。
3. 远程访问经由跳板机，配合MFA、会话录制和有时限的凭据。制冷承包商拿到的是访问某家特定门店的四小时窗口，而不是一条通往整个门店网络的常驻VPN。
4. 仅允许出站的遥测。如果厂商的云平台需要温度数据，由网关推送出去即可，内部不允许任何东西主动拉取。
5. 盘点所有资产。你无法分段你不知道存在的东西。冷柜上那个蜂窝调制解调器正是盘点时最容易遗漏的隐形连接，直到Shodan替你找了出来。

与另一种选择的代价相比，这些措施既不是假设，也不算昂贵。难点在于组织层面而非技术层面：它需要设施团队、IT安全团队和供应商就“谁负责什么”达成一致。在大多数零售企业中，OT恰好掉进了这些团队之间的缝隙里：对IT来说太偏物理，对设施部门来说又太偏网络。这种模糊性才是真正的漏洞，它与我们在云认证日志的盲区中看到的问题如出一辙，会把云认证的缺口变成隐形的入侵：如果没人负责遥测数据，也就没人能看见攻击。

软件工程师该从中学到什么

你或许从未碰过制冷控制器，但这里的故障模式，正是所有联网系统的故障模式，而它们正越来越多地成为你的问题。IT与OT之间的界线正在消融：你的仓库机器人、办公室暖通空调、实验室仪器、智能楼宇，全都运行着嵌入式Linux并与云端通信。如今一些医院的实验室设备，如果订阅账户余额不足，就拒绝运行检测，这意味着一次联网的计费故障或入侵就可能让医疗诊断停摆。这个世界是我们一个个“便利功能”堆出来的。

所以这些教训可以直接套用。盘点你的暴露面：如果你不知道什么在监听，别人会替你找到。即便是“正常功能”，也要把危险操作当作特权来对待，因为攻击者一旦摸到你的控制平面，就会把你的功能反过来对付你。对重要的东西签名，其他一切都设置过期。把故障状态设计成安全状态：失去连接的控制器应当继续制冷，而不是默认信任排队中的每条指令。发布安全修复时，要大声说出来，没人安装的补丁，和没有补丁几乎没有区别。

这次超市除霜攻击大概会因其荒诞而被记住，黑客对决冷冻豌豆。但下一次攻击未必会瞄准冰淇淋。它可能瞄准的是同一类暴露在外、未打补丁、认证薄弱的控制器，比如低温医药仓库、数据中心的冷却系统，或者市政供水系统。硬件是一样的，凭据同样糟糕。唯一的变量，是当有人敲入当天的密码时，什么东西会升温、溢出，或者停机。