1. 从一次车间瘫掉的排故说起PLC、DCS的“先天免疫缺陷”上个月普能电控接了一个老车间的改造项目现场调试刚开始两天就出事了某条产线的几十台PLC同时报超时触摸屏全部花屏现场看到的现象是控制网交换机指示灯疯狂乱闪整个网段像中风一样。排查到最后问题出在一位调试工程师的工程笔记本上——那台电脑前一天刚在办公室连过外网第二天插进控制网交换机一段时间广播风暴就起来了。车间没停产多久但是从那天起甲方信息部门的人反复问我们一个问题你们的PLC和DCS自己在网络攻击面前到底能不能扛得住这个问题放在五年前大部分搞电气的同事会觉得是IT部门的事。但今天站在控制系统的角度PLC、DCS就是整个工厂的“工业神经”它们一旦被干扰掉线、误动作、程序被篡改哪一样都比电脑中毒要命。这篇文章不打算讲厂商PPT式的安全理念我想用我们实际调试和整改的经验把PLC、DCS“自我防护”这件事拆开来说清楚它们为什么容易中招、边界网络怎么布置、控制器本身能做哪些加固、出事了怎么发现和响应以及一套可以直接拿回去用的落地清单。先说结论工控安全不是买几台防火墙就能解决的也不是给PLC设个密码就算完事。它是一套从控制器、网络、上位机到人员管理都参与进来的系统工程。下面从问题根源开始。1.1 为什么说PLC和DCS天生是“裸奔”的很多人第一次接触工控网络时第一反应是“这不就是普通局域网吗”确实现在的S7-1500、汇川H5U、三菱FX5U都带以太网口组态软件走TCP/IP太普遍了。但OT网络和IT网络的安全目标从根上就不一样。IT系统讲究保密性、完整性、可用性但工控系统把可用性放在第一位。产线不能停这是铁律。补丁不能随便打因为打了可能重启杀毒软件不能随便装因为扫描可能占用CPU导致扫描周期抖动防火墙策略不能随便加因为多一跳转发就可能让一个实时指令超时。这就是为什么很多工厂宁可顶着风险也不做升级——不是安全意识差是业务连续性在压着。更麻烦的是设备生命周期。写字楼里的电脑三五年换代现场的PLC、DCS控制器一用就是十几年甚至二十年。S7-300那个年代的设计根本没有考虑网络对抗CPU算力连跑个加密算法都费劲更别说安装什么安全代理。这就导致很多工控设备对网络攻击几乎是“敞开大门”。1.2 协议裸奔改一个寄存器就能让产线变脸工控圈里最常用的Modbus TCP、S7comm、EtherNet/IP、PROFINET设计初衷都是“在可信环境里可靠传输”没有加密、没有身份认证。什么意思呢只要攻击者能蹭进控制网络就能直接构造协议报文和PLC通信。我做过一次内部安全测试用一台普通电脑装个Modbus调试工具扫描到一台老PLC的IP后直接发一个写保持寄存器的请求把PID设定值改掉。结果现场的温度曲线肉眼可见地开始往下掉把所有盯着监控的人都吓了一跳。在真实生产环境里一个0x10功能码的写请求就能改变变频器频率、电机转速、阀门开度。这不是跟黑客比赛高深技术而是工控协议天生就缺一把锁。DCS也一样。很多DCS系统的组态下载口、工程师站和操作员站之间的通信通道认证机制非常薄弱有些老系统的私有协议甚至没有加密。像上海新华DCS这类国产老系统ICAN协议在工控现场用了很多年数据链路基本处于“看得见就能连得上”的状态。一旦有人能物理接触到工程师站或者控制网线缆整个控制策略都有被下载、被篡改的风险。1.3 组态软件和工程笔记本移动的传染源我们在多个项目里统计过一个数据绝大多数工控网络被“污染”不是被外部黑客远距离打进来的而是被U盘、笔记本电脑、第三方调试设备带进去的。现场工程师的习惯往往是这样的电脑在办公室上过网、收过邮件、插过陌生U盘到了现场直接往控制交换机上一插。要是这台电脑带病毒第一步感染的就是工程师站和操作员站然后通过广播或者扫描横向移动波及整条生产线的PLC。当年全球范围内勒索软件爆发很多制造业工厂就是这么中招的——办公网先沦陷再通过调试笔记本、共享文件夹、打印机端口等途径横向渗入OT网。这就引出一个很容易被忽视的点PLC和DCS的“自我防护”必须包含对组态环境的管理。WinCC关联PLC变量时如果工程师站本身已经不可信那变量上下载的过程就是在往控制系统里投毒。2. 边界怎么划才不拖累实时性OT网络分区与工业防火墙选型以前很多工厂只有一个“大内网”办公区、车间、监控全通着。现在做安全整改第一件事就是分区。但分区不是简单买几台防火墙就能完事划得不好反而会让产线天天抖。2.1 区域和管道先画出“哪里是危险区”做过信息安全的人应该都听过IEC 62443里的区域和管道Zone and Conduit概念。放到工厂现场我的理解就是把整个工控网络按风险等级切成几个区域区域之间用明确的“通道”连接。最常见的分法是三层办公网、生产执行网、控制网。办公网是研发、行政、ERP用的生产执行网是MES、数据采集服务器所在的地方控制网才是PLC、DCS、HMI、变频器这些真正的“工业神经”。按我的经验边界隔离至少要解决两个问题。第一办公网到控制网必须经过DMZ区所有跨区访问在DMZ里做数据摆渡禁止直接点对点打通。第二控制网内部还要按工艺段再细分比如一条线是焊接段另一条线是总装段两段之间的PLC如果不需要互相通信就应该在网络层断开。实际干活的时候会发现很多老系统改造的难点不是技术而是“业务上到底谁跟谁要通信”。我建议前期花一两天做一次现场访谈把每台PLC、每台上位机的通信关系画成一张表再决定分区策略。不要拍脑袋划VLAN否则现场三天两头出通信故障。2.2 工业防火墙和普通防火墙的最大区别很多甲方说“我们已经有防火墙了”点开一看是办公网用的下一代防火墙。放在控制网前面它最大的问题是看不懂工业协议。普通IT防火墙只会管IP、端口、协议类型它不知道Modbus TCP里面哪个是读请求、哪个是写请求也不知道S7comm的哪些功能码允许通过。这意味着只要放行了502端口攻击者就能在允许的端口上为所欲为。工业防火墙不一样它带应用层识别能力能做功能码级白名单。比如规定某台上位机只能对某台PLC的指定寄存器区做读操作写操作一律拒绝或者PROFINET实时报文只允许在特定设备之间传输。这种颗粒度才是工控场景真正需要的。但选工业防火墙时也要留个心眼不要只看宣传参数要实际测试性能。我们在一个项目里遇到过标称“线速转发”的盒子实际部署后Modbus请求多了就延迟上位机直接报警。最后换成更高端口的设备问题才解决。控制网里实时性大于一切防火墙的转发延迟和吞吐余量必须留足。2.3 安全策略上线前先在VMware环境里做验证很多调试工程师喜欢用VMware跑TIA或是组态软件连PLC做实验这其实是验证安全策略的好办法。但有个细节很关键虚拟机的网络模式选不对连PLC就会出怪问题。VMware Workstation的NAT模式下虚拟机是经过宿主机NAT转换后才访问外部网络的而很多组态软件做设备发现时走的是二层广播NAT模式会把广播包丢掉导致“扫描不到PLC”。连不上PLC的时候先把网络模式改成桥接并且确保虚拟网卡和物理网卡桥接到同一块网卡上或用VMnet自定义网段把笔记本的物理网口直连进去。这个坑我们团队自己踩过不止一次。用虚拟化环境还有一个好处可以在一个隔离的虚拟网络里模拟办公网、DMZ、控制网三段把工业防火墙的规则先在虚拟机之间验证一遍确认不影响组态下载和在线监视再去现场套用真实策略。尤其是PROFINET和EtherNet/IP这类带实时调度的协议规则配置错误轻则报警重则丢站必须先在测试环境里“压”过才敢上产线。2.4 边界防护挡不住的东西物理隔离和U盘管理网络边界做得再严密如果任何人都能拿U盘插到操作员站上边界就等于白做。我见过某工厂操作员站的USB口全开放操作工用U盘拷音乐、拷贝个人文件迟早有一天会带进来一个“惊喜”。物理隔离和端口管控是网络边界缺失时的底线手段。没条件上工业防火墙的小车间至少要做到控制网交换机与办公网交换机物理断开需要交换数据时用单向网闸或人工拷贝所有工程师站的USB口做权限管控操作员站禁用光驱和蓝牙。这些手段不花大钱但能把最大的传染路径堵住。3. 不靠外设也能自保PLC、DCS控制器的加固配置清单网络边界是外部的“城墙”但PLC和DCS自己也得有“铠甲”。我之前跟同行交流时发现很多工程师压根不知道自己的控制器还有这么多安全选项或者知道但从来没配置过。3.1 控制器访问控制与口令策略先说西门子。S7-1200/1500在CPU属性里提供了防护等级设置从“完全访问保护”“读访问保护”“写访问保护”到“HMI访问保护”每一档限制的内容不一样。用TIA Portal下载硬件配置时可以在“防护与安全”里设置密码和证书。很多项目组为了调试方便CPU配置一直是完全访问无保护项目交付后也没人改这就等于把控制器的门敞开着。三菱的FX5U、Q系列则支持远程密码和序列号保护。远程密码是指上位机访问PLC时要求输入密码序列号保护可以限制只有特定序列号的GX Works3工程才能连接CPU。这个功能对于防止陌生软件直接连上PLC非常有用。汇川、信捷这些国产PLC这些年也陆续补齐了访问密码、程序上载保护等功能做项目时值得仔细翻一下手册把这些默认关闭的开关打开。实际操作中我要提醒一点设密码不是设了就完事要建立密码台账。我们接过一个改造项目前任工程师给CPU设了密码但没留下记录结果甲方自己都连不上控制器最后只能联系原厂做恢复。所以密码策略要配套“信封制度”密码由甲方设备科保管调试期结束后封存修改要有审批记录。3.2 程序读写保护设了保护之后别把自己锁死控制器里有几类保护要分清因为很多人搞混。第一类是读保护防止别人用组态软件上载程序保护知识产权。第二类是写保护防止在线修改程序这对生产安全尤为重要——它保证产线上的程序版本是受控的。第三类是专有技术保护用于防止程序块被打开查看内部逻辑。我在实际项目里发现很多人把读保护打开了但写保护没开理由是“以后还要在线修改”。这很危险。写保护恰恰是防止“误改”和“被改”的最有效手段。如果你想保留调试灵活性至少在做完验收、生产线正式投运后再开启写保护。另外开启保护前一定要验证“恢复流程”用受信任的上位机、正确的工程文件确认能正常上下载。不要等出了故障才发现密码策略把自己和应急响应都锁在门外。3.3 安全逻辑设计联锁、心跳、状态机与降级策略网络层面的防护做得再好内部逻辑也不能出现“单点依赖”。这是我们团队做电控系统设计时最强调的一条原则关键安全联锁不要只靠通信变量。举例来说一台变频器由PLC通过PROFINET控制启停如果PLC和变频器之间的网络被干扰通信中断变频器是继续按原速跑还是安全停车很多事故恰恰就是“通信断了但设备还在动”造成的。正确的做法是在PLC程序里做心跳检测超过设定周期没收到变频器反馈就触发安全联锁更严格的场合安全停车回路要走硬接线不依赖通信。横河DCS、和利时DCS里做联锁逻辑时也是同样的套路SIS安全仪表系统的核心逻辑必须建立在硬逻辑和故障安全模式上而不是建立在以太网报文上。再说到程序写法。梯形图越复杂越容易埋漏洞。我建议用状态机的方式组织控制流程每个状态之间做严密的转换条件非法跳转直接回到安全状态。这不仅是编程规范问题也是安全习惯。包括输入滤波消抖很多工程师觉得这是小问题但在干扰环境下一个抖动信号可能导致错误的启停指令。PLC数字量输入滤波、模拟量滤波的参数设置本质上是把“假信号”挡在逻辑之外。另外关于程序里加“定期锁机”这类时间判断逻辑我只想说一点如果合同明确约定了授权期限那这是合法的使用权控制技术如果是为了要挟客户付款而留后门那是给自己埋雷。正规项目里要处理类似需求应该通过正规授权管理和验收流程解决而不是在PLC程序里暗藏时间炸弹。网络安全是保护系统不是制造风险。3.4 DCS组态的权限、版本与可靠性设计DCS比PLC更强调系统整体安全。像横河CENTUM、新华DCS这类系统工程师站、操作员站、历史站、控制站之间是成体系的。做加固时我关注几个点一是组态下载权限必须严格分层。操作员只能看趋势、调参数工程师才能下装控制策略而且下装操作要记录到操作日志里。很多DCS系统都有“在线修改”“下装”的审核审计功能问题是有些项目根本没打开。二是版本管理。每次组态修改都要留底修改内容要有变更记录。网络安全事件出来后定位问题第一件事就是对比“现在跑的组态”和“备份的组态”到底差在哪里。如果连基线版本都没有恢复都无从谈起。三是控制器冗余。DCS控制器、电源、网络都需要冗余设计单点故障不能导致整套系统失灵。网络攻击经常导致的后果是流量异常导致控制器CPU过载如果主控制器被攻击宕机冗余控制器是否能保持干净的程序版本正常工作这需要专门验证。我们在做安全整改时会专门安排一次冗余切换测试模拟主控制器故障和网络风暴两种情况观察从站切换是否正常。4. 病毒进来以后怎么发现检测、隔离与应急恢复流程防护不是百分之百所以要考虑“已经出事怎么快速发现和处理”。很多工厂依赖操作员肉眼发现异常等看到PLC批量报警时往往已经晚了。这里分享一套我们实践过的检测与响应思路。4.1 先把“家底”摸清资产管理是一切检测的前提安全的起点是资产盘点。你连网络上有几台PLC都数不清楚怎么判断哪台设备异常我们做过一个资产盘点项目光一条车间就扫出几十台设备其中好几台上位机的IP地址都没有登记甚至有一台“幽灵设备”挂在控制网里跑了两年没人知道——后来发现是某台老旧工控机系统早就没人维护。这种设备就是天然的后门。资产盘点有两条路线一是人工登记拿着网线走向图核对每台设备的IP、MAC、型号、系统版本二是用扫描工具做被动探测通过监听流量识别设备指纹。建议两条线结合最终形成一张资产清单字段包括设备类型、IP、MAC、所在区域、负责人、固件版本、开放端口、安装的软件以及是否需要持续联网。这张表是所有后续检测和防护策略的基础。4.2 流量基线建立不靠玄学靠抓包和日志工控网络的流量特征是高度规律的。正常生产时上位机周期性轮询PLC数据报文大小、请求频率、目标寄存器地址基本稳定。一旦出现异常比如某台设备突然大量广播、某个IP持续扫描端口、Modbus写请求次数暴增这种偏离基线的行为就是最明显的入侵信号。实现上不需要太高深的技术。核心交换机开端口镜像用装有Wireshark的电脑分析一段时间流量重点看三件事谁在跟谁说话、用什么协议、说得多频繁。比如一条S7comm会话如果出现大量CPU读写操作而业务上完全不必要就要立刻查它。更完善的做法是部署工控安全监测审计设备这类设备能识别Modbus TCP、S7comm、CIP、PROFINET、OPC UA协议并记录操作日志。最后形成“谁、在什么时间、对哪台控制器、做了什么操作”的审计记录。发生安全事件后这些记录能快速还原攻击路径。预算有限的工厂至少要做到控制网核心交换机日志留存这个成本很低。4.3 应急响应不要一上来就拔控制器网线遇到病毒爆发或者现场出现大规模异常时很多人的第一反应是把网线拔掉。但控制网和办公网不一样——直接拔控制器网线可能导致整个DCS系统失去上位机监视触发一系列联锁动作造成更严重的停车事故。我们建议的应急响应顺序是先核实异常影响面再考虑隔离。第一步确认异常流量源IP和物理位置在交换机上把这个端口断开或划入孤立VLAN第二步确认受影响的PLC、DCS是否运行正常组态程序是否被篡改过必要时把控制器切到停止状态但保持电源第三步保留现场日志和流量包别急着重启设备日志是事后分析的唯一证据第四步从异地备份恢复程序或系统。整个过程要有一个明确的事件响应负责人不能大家都在操作台上乱点。备份这件事我再强调一次PLC程序、DCS组态、上位机项目、防火墙配置全部要定期备份并且至少保留一个异地副本。很多工厂只在项目验收时备份过一次后面改程序从来不更新备份出事后恢复出来的还是三年前的旧版本等于白背。4.4 离线补丁与白名单机制工控设备补丁是个老大难。老系统不敢打补丁新系统又没时间打补丁。我的思路是核心控制器不追新补丁但工程师站、操作员站必须做两项基本工作——离线补丁更新和应用白名单。离线补丁的意思是不让操作系统直接连互联网更新而是由维护人员从可信渠道下载补丁包在停机窗口内统一安装验证。应用白名单则是给上位机装一个白名单软件只有预设的组态软件、通信程序、必要系统服务才能运行其他陌生程序一律拦截。这样即使病毒文件进入了系统只要它不在白名单里就执行不了。这条措施对勒索软件的防御效果非常明显因为勒索病毒总要落地一个exe才能开始干活。有一类“杀毒软件误杀组态软件”的问题我放在后面单独说因为这是很多工厂不敢在上位机装防护软件的直接原因。我的建议是宁可不用传统杀毒软件的实时监控也要把应用白名单跑起来误杀率低很多而且白名单策略对现场实时性的影响更小。5. 按这个顺序落地资产盘点、基线加固、管理与演练讲完原理讲讲怎么落地。很多工厂想做安全整改但不知道怎么开始或者直接找安全厂商堆了一堆设备最后效果很差。我的建议是分三个阶段走每个阶段的产出都看得见。5.1 一张可直接用的安全自查清单我把日常最容易做的检查项整理成一张表适合电气工程师或设备科直接拿去用检查项常见问题处理建议优先级控制器访问密码未设置或使用默认密码设置强密码并由专人保管做好台账高CPU读写保护完全开放可任意上载下载验收后开启写保护控制变更加载高上位机USB管控操作员站USB口全部开放启用组策略禁用U盘需用登记高控制网与办公网边界共用交换机或直连至少做到物理隔离有条件的上工业防火墙高组态软件登录权限共用账户无审计建立独立账户操作日志留存中工程笔记本安全电脑随意接入控制网专用调试笔记本上白名单加离线补丁中关键联锁硬接线过于依赖通信变量梳理安全联锁清单硬接线冗余中备份与恢复只在验收时备份一次定期备份异地保存每年演练恢复高固件与补丁长期不更新停机窗口离线补丁测试后上线低弱口令与共享账户多个工程师共用admin一人一账户权限最小化中这十项覆盖了控制器、上位机、网络、管理和备份五个维度。大多数工厂做完高优先级那几项安全水平就能上一个台阶。5.2 分阶段实施第一个月做什么、第三个月做到什么程度第一个月摸清家底。完成资产盘点画出网络拓扑图关闭控制网里所有不需要的未用端口清理“幽灵设备”把所有控制器的访问密码改成强密码并登记。这个月不追求高大上的设备先把基础卫生搞干净。第二到第三个月边界隔离和设备加固。打通办公网到控制网的所有直连通道改走DMZ部署工业防火墙并调试白名单规则给工程师站、操作员站装应用白名单启用PLC、DCS的读写保护和审计日志。这个阶段要协调停机窗口建议每次停机不超过一个班次分批完成。第四到第六个月检测响应与管理制度。部署流量监测审计系统并建立流量基线制定应急响应流程和备份制度安排一次全员安全意识培训最后组织一次内部攻防演练——请一位懂网络的人模拟攻击路径实际检验防护策略是否有效。到这一步整改闭环就基本形成了。5.3 管理与运维习惯比技术更值钱做了这么多年项目我越来越觉得工控安全的最大瓶颈不是技术是“人”。操作员觉得U盘管控烦工程师觉得密码机制耽误调试时间领导觉得安全投入看不到产出这些心态如果扭转不过来再好的设备也会被绕过。管理措施里效益最高的是这三条U盘和调试笔记本专管专用组态软件高权限账户分人管理外包调试人员进场必须走审批并全程有人陪同。这三条不用花一分钱买设备但能挡住绝大多数由“人”引起的风险。安全培训不要搞成念PPT。我建议用真实场景做演练假装有人往操作员站插了一个U盘看现场人员会不会上报或者模拟一台PLC离线看维护人员能不能按流程在一小时内恢复。演练比培训有用得多。5.4 攻防演练自己“黑”自己一次如果条件允许每年至少做一次工控安全演练场景可以参考这些攻击者从办公网渗透到控制网恶意程序通过U盘进入操作员站后向PLC写入异常参数DCS工程师站被勒索软件加密。演练的目的不是证明“我们被攻破了”而是检验应急处置流程是否顺畅、备份恢复是否真的可用。我们的经验是第一次演练一定会暴露出大量问题比如没有资产清单、密码不统一、备份找不到、应急联系人失联。这些问题在真出事之前暴露出来都是赚到的。演练结束后把发现的问题列成整改清单定责任人、定完成时间下次演练再验证。做到这一点安全体系才是活着的而不只是墙上挂一份制度文件。6. 几个把安全整改做成“事故”的教训最后讲讲我们见过的翻车现场。安全整改本意是保护生产但如果操作不当反而会制造事故。这几个坑值得所有准备做工控安全的人提前知道。6.1 防火墙规则把正常通讯也拦了有个项目给控制网部署了工业防火墙规则写得不够细把PLC和变频器之间的PROFINET实时报文也过滤了。结果产线运行没几分钟变频器就报丢站停机。当时现场急得团团转最后发现是防火墙的默认策略把未知协议丢掉了。这告诉我们两件事第一工业防火墙策略必须按“最小开放”原则逐条梳理每条规则都要有业务依据第二上线前必须做流量抓包分析确认业务流量包含哪些协议、哪些端口再针对性地放行。宁可在测试环境多花两天也不能在产线上试错。6.2 杀毒软件和白名单误杀组态软件很多工厂给上位机装了普通办公用的杀毒软件结果实时监控把WinCC、TIA、组态软件的关键进程当作可疑程序隔离了。操作员正监视着画面呢突然所有变量全红以为现场出大事了。传统杀毒软件的病毒库更新快、误杀率高这在IT环境问题不大但OT环境里一次误杀影响的就是整条产线。我的建议是工控上位机优先用应用白名单产品而不是传统杀毒软件即使要用杀毒软件也不要开实时监控只在维护窗口做全盘扫描。关键是测试环境先验证兼容性再大规模部署。6.3 过度追求“绝对隔离”带来的隐性成本还有一个极端是领导一听网络安全拍板把所有工控设备全部物理隔离谁也不许接外网。结果MES数据要人工拿U盘倒生产报表不能自动生成远程诊断全部停摆工程师每改一次程序都要跑现场效率下降一大截。网络安全不是把所有口子都堵死而是在风险和控制之间找平衡。比如远程维护需求可以通过堡垒机加白名单加操作审计来实现不需要完全断开连接数据采集可以通过OPC UA加证书加密传输不需要靠U盘拷贝。安全整改的最高境界是“该通的通、不该通的不通”生产和管理两头都不误。真正实现这一点不会让现场工程师天天骂娘。6.4 做完这轮整改我的真实体会普能电控这些年做过的DCS和PLC项目里从汽车零部件车间到化工流程控制越来越深刻的感受是工控网络安全绝对不是安全厂商的独角戏。PLC、DCS的“自我防护”核心其实是一句话——让控制系统的每一层都有“最小权限”每一根“工业神经”都知道自己该接收谁的指令、不该接收谁的指令。从控制器密码、CPU读写保护、关键联锁硬接线到网络分区、工业防火墙、应用白名单再到资产盘点、应急响应、攻防演练每一个环节单独看不复杂但它们合在一起才构成一套完整的防御体系。我的切身体会是安全整改最怕的不是技术难题而是“觉得差不多了”的心态——只要有一次演练把备份恢复流程真正跑通你就会发现之前觉得“差不多了”的地方漏洞比想象中多得多。把这个思路带进项目里别把安全当成最后验收时才想起来补的“装饰工程”而是像设计一套联锁逻辑一样从一开始就要验证、测试、维护。这样等哪天真出事了车间才不至于乱成一锅粥。
1. 从一次车间瘫掉的排故说起PLC、DCS的“先天免疫缺陷”上个月普能电控接了一个老车间的改造项目现场调试刚开始两天就出事了某条产线的几十台PLC同时报超时触摸屏全部花屏现场看到的现象是控制网交换机指示灯疯狂乱闪整个网段像中风一样。排查到最后问题出在一位调试工程师的工程笔记本上——那台电脑前一天刚在办公室连过外网第二天插进控制网交换机一段时间广播风暴就起来了。车间没停产多久但是从那天起甲方信息部门的人反复问我们一个问题你们的PLC和DCS自己在网络攻击面前到底能不能扛得住这个问题放在五年前大部分搞电气的同事会觉得是IT部门的事。但今天站在控制系统的角度PLC、DCS就是整个工厂的“工业神经”它们一旦被干扰掉线、误动作、程序被篡改哪一样都比电脑中毒要命。这篇文章不打算讲厂商PPT式的安全理念我想用我们实际调试和整改的经验把PLC、DCS“自我防护”这件事拆开来说清楚它们为什么容易中招、边界网络怎么布置、控制器本身能做哪些加固、出事了怎么发现和响应以及一套可以直接拿回去用的落地清单。先说结论工控安全不是买几台防火墙就能解决的也不是给PLC设个密码就算完事。它是一套从控制器、网络、上位机到人员管理都参与进来的系统工程。下面从问题根源开始。1.1 为什么说PLC和DCS天生是“裸奔”的很多人第一次接触工控网络时第一反应是“这不就是普通局域网吗”确实现在的S7-1500、汇川H5U、三菱FX5U都带以太网口组态软件走TCP/IP太普遍了。但OT网络和IT网络的安全目标从根上就不一样。IT系统讲究保密性、完整性、可用性但工控系统把可用性放在第一位。产线不能停这是铁律。补丁不能随便打因为打了可能重启杀毒软件不能随便装因为扫描可能占用CPU导致扫描周期抖动防火墙策略不能随便加因为多一跳转发就可能让一个实时指令超时。这就是为什么很多工厂宁可顶着风险也不做升级——不是安全意识差是业务连续性在压着。更麻烦的是设备生命周期。写字楼里的电脑三五年换代现场的PLC、DCS控制器一用就是十几年甚至二十年。S7-300那个年代的设计根本没有考虑网络对抗CPU算力连跑个加密算法都费劲更别说安装什么安全代理。这就导致很多工控设备对网络攻击几乎是“敞开大门”。1.2 协议裸奔改一个寄存器就能让产线变脸工控圈里最常用的Modbus TCP、S7comm、EtherNet/IP、PROFINET设计初衷都是“在可信环境里可靠传输”没有加密、没有身份认证。什么意思呢只要攻击者能蹭进控制网络就能直接构造协议报文和PLC通信。我做过一次内部安全测试用一台普通电脑装个Modbus调试工具扫描到一台老PLC的IP后直接发一个写保持寄存器的请求把PID设定值改掉。结果现场的温度曲线肉眼可见地开始往下掉把所有盯着监控的人都吓了一跳。在真实生产环境里一个0x10功能码的写请求就能改变变频器频率、电机转速、阀门开度。这不是跟黑客比赛高深技术而是工控协议天生就缺一把锁。DCS也一样。很多DCS系统的组态下载口、工程师站和操作员站之间的通信通道认证机制非常薄弱有些老系统的私有协议甚至没有加密。像上海新华DCS这类国产老系统ICAN协议在工控现场用了很多年数据链路基本处于“看得见就能连得上”的状态。一旦有人能物理接触到工程师站或者控制网线缆整个控制策略都有被下载、被篡改的风险。1.3 组态软件和工程笔记本移动的传染源我们在多个项目里统计过一个数据绝大多数工控网络被“污染”不是被外部黑客远距离打进来的而是被U盘、笔记本电脑、第三方调试设备带进去的。现场工程师的习惯往往是这样的电脑在办公室上过网、收过邮件、插过陌生U盘到了现场直接往控制交换机上一插。要是这台电脑带病毒第一步感染的就是工程师站和操作员站然后通过广播或者扫描横向移动波及整条生产线的PLC。当年全球范围内勒索软件爆发很多制造业工厂就是这么中招的——办公网先沦陷再通过调试笔记本、共享文件夹、打印机端口等途径横向渗入OT网。这就引出一个很容易被忽视的点PLC和DCS的“自我防护”必须包含对组态环境的管理。WinCC关联PLC变量时如果工程师站本身已经不可信那变量上下载的过程就是在往控制系统里投毒。2. 边界怎么划才不拖累实时性OT网络分区与工业防火墙选型以前很多工厂只有一个“大内网”办公区、车间、监控全通着。现在做安全整改第一件事就是分区。但分区不是简单买几台防火墙就能完事划得不好反而会让产线天天抖。2.1 区域和管道先画出“哪里是危险区”做过信息安全的人应该都听过IEC 62443里的区域和管道Zone and Conduit概念。放到工厂现场我的理解就是把整个工控网络按风险等级切成几个区域区域之间用明确的“通道”连接。最常见的分法是三层办公网、生产执行网、控制网。办公网是研发、行政、ERP用的生产执行网是MES、数据采集服务器所在的地方控制网才是PLC、DCS、HMI、变频器这些真正的“工业神经”。按我的经验边界隔离至少要解决两个问题。第一办公网到控制网必须经过DMZ区所有跨区访问在DMZ里做数据摆渡禁止直接点对点打通。第二控制网内部还要按工艺段再细分比如一条线是焊接段另一条线是总装段两段之间的PLC如果不需要互相通信就应该在网络层断开。实际干活的时候会发现很多老系统改造的难点不是技术而是“业务上到底谁跟谁要通信”。我建议前期花一两天做一次现场访谈把每台PLC、每台上位机的通信关系画成一张表再决定分区策略。不要拍脑袋划VLAN否则现场三天两头出通信故障。2.2 工业防火墙和普通防火墙的最大区别很多甲方说“我们已经有防火墙了”点开一看是办公网用的下一代防火墙。放在控制网前面它最大的问题是看不懂工业协议。普通IT防火墙只会管IP、端口、协议类型它不知道Modbus TCP里面哪个是读请求、哪个是写请求也不知道S7comm的哪些功能码允许通过。这意味着只要放行了502端口攻击者就能在允许的端口上为所欲为。工业防火墙不一样它带应用层识别能力能做功能码级白名单。比如规定某台上位机只能对某台PLC的指定寄存器区做读操作写操作一律拒绝或者PROFINET实时报文只允许在特定设备之间传输。这种颗粒度才是工控场景真正需要的。但选工业防火墙时也要留个心眼不要只看宣传参数要实际测试性能。我们在一个项目里遇到过标称“线速转发”的盒子实际部署后Modbus请求多了就延迟上位机直接报警。最后换成更高端口的设备问题才解决。控制网里实时性大于一切防火墙的转发延迟和吞吐余量必须留足。2.3 安全策略上线前先在VMware环境里做验证很多调试工程师喜欢用VMware跑TIA或是组态软件连PLC做实验这其实是验证安全策略的好办法。但有个细节很关键虚拟机的网络模式选不对连PLC就会出怪问题。VMware Workstation的NAT模式下虚拟机是经过宿主机NAT转换后才访问外部网络的而很多组态软件做设备发现时走的是二层广播NAT模式会把广播包丢掉导致“扫描不到PLC”。连不上PLC的时候先把网络模式改成桥接并且确保虚拟网卡和物理网卡桥接到同一块网卡上或用VMnet自定义网段把笔记本的物理网口直连进去。这个坑我们团队自己踩过不止一次。用虚拟化环境还有一个好处可以在一个隔离的虚拟网络里模拟办公网、DMZ、控制网三段把工业防火墙的规则先在虚拟机之间验证一遍确认不影响组态下载和在线监视再去现场套用真实策略。尤其是PROFINET和EtherNet/IP这类带实时调度的协议规则配置错误轻则报警重则丢站必须先在测试环境里“压”过才敢上产线。2.4 边界防护挡不住的东西物理隔离和U盘管理网络边界做得再严密如果任何人都能拿U盘插到操作员站上边界就等于白做。我见过某工厂操作员站的USB口全开放操作工用U盘拷音乐、拷贝个人文件迟早有一天会带进来一个“惊喜”。物理隔离和端口管控是网络边界缺失时的底线手段。没条件上工业防火墙的小车间至少要做到控制网交换机与办公网交换机物理断开需要交换数据时用单向网闸或人工拷贝所有工程师站的USB口做权限管控操作员站禁用光驱和蓝牙。这些手段不花大钱但能把最大的传染路径堵住。3. 不靠外设也能自保PLC、DCS控制器的加固配置清单网络边界是外部的“城墙”但PLC和DCS自己也得有“铠甲”。我之前跟同行交流时发现很多工程师压根不知道自己的控制器还有这么多安全选项或者知道但从来没配置过。3.1 控制器访问控制与口令策略先说西门子。S7-1200/1500在CPU属性里提供了防护等级设置从“完全访问保护”“读访问保护”“写访问保护”到“HMI访问保护”每一档限制的内容不一样。用TIA Portal下载硬件配置时可以在“防护与安全”里设置密码和证书。很多项目组为了调试方便CPU配置一直是完全访问无保护项目交付后也没人改这就等于把控制器的门敞开着。三菱的FX5U、Q系列则支持远程密码和序列号保护。远程密码是指上位机访问PLC时要求输入密码序列号保护可以限制只有特定序列号的GX Works3工程才能连接CPU。这个功能对于防止陌生软件直接连上PLC非常有用。汇川、信捷这些国产PLC这些年也陆续补齐了访问密码、程序上载保护等功能做项目时值得仔细翻一下手册把这些默认关闭的开关打开。实际操作中我要提醒一点设密码不是设了就完事要建立密码台账。我们接过一个改造项目前任工程师给CPU设了密码但没留下记录结果甲方自己都连不上控制器最后只能联系原厂做恢复。所以密码策略要配套“信封制度”密码由甲方设备科保管调试期结束后封存修改要有审批记录。3.2 程序读写保护设了保护之后别把自己锁死控制器里有几类保护要分清因为很多人搞混。第一类是读保护防止别人用组态软件上载程序保护知识产权。第二类是写保护防止在线修改程序这对生产安全尤为重要——它保证产线上的程序版本是受控的。第三类是专有技术保护用于防止程序块被打开查看内部逻辑。我在实际项目里发现很多人把读保护打开了但写保护没开理由是“以后还要在线修改”。这很危险。写保护恰恰是防止“误改”和“被改”的最有效手段。如果你想保留调试灵活性至少在做完验收、生产线正式投运后再开启写保护。另外开启保护前一定要验证“恢复流程”用受信任的上位机、正确的工程文件确认能正常上下载。不要等出了故障才发现密码策略把自己和应急响应都锁在门外。3.3 安全逻辑设计联锁、心跳、状态机与降级策略网络层面的防护做得再好内部逻辑也不能出现“单点依赖”。这是我们团队做电控系统设计时最强调的一条原则关键安全联锁不要只靠通信变量。举例来说一台变频器由PLC通过PROFINET控制启停如果PLC和变频器之间的网络被干扰通信中断变频器是继续按原速跑还是安全停车很多事故恰恰就是“通信断了但设备还在动”造成的。正确的做法是在PLC程序里做心跳检测超过设定周期没收到变频器反馈就触发安全联锁更严格的场合安全停车回路要走硬接线不依赖通信。横河DCS、和利时DCS里做联锁逻辑时也是同样的套路SIS安全仪表系统的核心逻辑必须建立在硬逻辑和故障安全模式上而不是建立在以太网报文上。再说到程序写法。梯形图越复杂越容易埋漏洞。我建议用状态机的方式组织控制流程每个状态之间做严密的转换条件非法跳转直接回到安全状态。这不仅是编程规范问题也是安全习惯。包括输入滤波消抖很多工程师觉得这是小问题但在干扰环境下一个抖动信号可能导致错误的启停指令。PLC数字量输入滤波、模拟量滤波的参数设置本质上是把“假信号”挡在逻辑之外。另外关于程序里加“定期锁机”这类时间判断逻辑我只想说一点如果合同明确约定了授权期限那这是合法的使用权控制技术如果是为了要挟客户付款而留后门那是给自己埋雷。正规项目里要处理类似需求应该通过正规授权管理和验收流程解决而不是在PLC程序里暗藏时间炸弹。网络安全是保护系统不是制造风险。3.4 DCS组态的权限、版本与可靠性设计DCS比PLC更强调系统整体安全。像横河CENTUM、新华DCS这类系统工程师站、操作员站、历史站、控制站之间是成体系的。做加固时我关注几个点一是组态下载权限必须严格分层。操作员只能看趋势、调参数工程师才能下装控制策略而且下装操作要记录到操作日志里。很多DCS系统都有“在线修改”“下装”的审核审计功能问题是有些项目根本没打开。二是版本管理。每次组态修改都要留底修改内容要有变更记录。网络安全事件出来后定位问题第一件事就是对比“现在跑的组态”和“备份的组态”到底差在哪里。如果连基线版本都没有恢复都无从谈起。三是控制器冗余。DCS控制器、电源、网络都需要冗余设计单点故障不能导致整套系统失灵。网络攻击经常导致的后果是流量异常导致控制器CPU过载如果主控制器被攻击宕机冗余控制器是否能保持干净的程序版本正常工作这需要专门验证。我们在做安全整改时会专门安排一次冗余切换测试模拟主控制器故障和网络风暴两种情况观察从站切换是否正常。4. 病毒进来以后怎么发现检测、隔离与应急恢复流程防护不是百分之百所以要考虑“已经出事怎么快速发现和处理”。很多工厂依赖操作员肉眼发现异常等看到PLC批量报警时往往已经晚了。这里分享一套我们实践过的检测与响应思路。4.1 先把“家底”摸清资产管理是一切检测的前提安全的起点是资产盘点。你连网络上有几台PLC都数不清楚怎么判断哪台设备异常我们做过一个资产盘点项目光一条车间就扫出几十台设备其中好几台上位机的IP地址都没有登记甚至有一台“幽灵设备”挂在控制网里跑了两年没人知道——后来发现是某台老旧工控机系统早就没人维护。这种设备就是天然的后门。资产盘点有两条路线一是人工登记拿着网线走向图核对每台设备的IP、MAC、型号、系统版本二是用扫描工具做被动探测通过监听流量识别设备指纹。建议两条线结合最终形成一张资产清单字段包括设备类型、IP、MAC、所在区域、负责人、固件版本、开放端口、安装的软件以及是否需要持续联网。这张表是所有后续检测和防护策略的基础。4.2 流量基线建立不靠玄学靠抓包和日志工控网络的流量特征是高度规律的。正常生产时上位机周期性轮询PLC数据报文大小、请求频率、目标寄存器地址基本稳定。一旦出现异常比如某台设备突然大量广播、某个IP持续扫描端口、Modbus写请求次数暴增这种偏离基线的行为就是最明显的入侵信号。实现上不需要太高深的技术。核心交换机开端口镜像用装有Wireshark的电脑分析一段时间流量重点看三件事谁在跟谁说话、用什么协议、说得多频繁。比如一条S7comm会话如果出现大量CPU读写操作而业务上完全不必要就要立刻查它。更完善的做法是部署工控安全监测审计设备这类设备能识别Modbus TCP、S7comm、CIP、PROFINET、OPC UA协议并记录操作日志。最后形成“谁、在什么时间、对哪台控制器、做了什么操作”的审计记录。发生安全事件后这些记录能快速还原攻击路径。预算有限的工厂至少要做到控制网核心交换机日志留存这个成本很低。4.3 应急响应不要一上来就拔控制器网线遇到病毒爆发或者现场出现大规模异常时很多人的第一反应是把网线拔掉。但控制网和办公网不一样——直接拔控制器网线可能导致整个DCS系统失去上位机监视触发一系列联锁动作造成更严重的停车事故。我们建议的应急响应顺序是先核实异常影响面再考虑隔离。第一步确认异常流量源IP和物理位置在交换机上把这个端口断开或划入孤立VLAN第二步确认受影响的PLC、DCS是否运行正常组态程序是否被篡改过必要时把控制器切到停止状态但保持电源第三步保留现场日志和流量包别急着重启设备日志是事后分析的唯一证据第四步从异地备份恢复程序或系统。整个过程要有一个明确的事件响应负责人不能大家都在操作台上乱点。备份这件事我再强调一次PLC程序、DCS组态、上位机项目、防火墙配置全部要定期备份并且至少保留一个异地副本。很多工厂只在项目验收时备份过一次后面改程序从来不更新备份出事后恢复出来的还是三年前的旧版本等于白背。4.4 离线补丁与白名单机制工控设备补丁是个老大难。老系统不敢打补丁新系统又没时间打补丁。我的思路是核心控制器不追新补丁但工程师站、操作员站必须做两项基本工作——离线补丁更新和应用白名单。离线补丁的意思是不让操作系统直接连互联网更新而是由维护人员从可信渠道下载补丁包在停机窗口内统一安装验证。应用白名单则是给上位机装一个白名单软件只有预设的组态软件、通信程序、必要系统服务才能运行其他陌生程序一律拦截。这样即使病毒文件进入了系统只要它不在白名单里就执行不了。这条措施对勒索软件的防御效果非常明显因为勒索病毒总要落地一个exe才能开始干活。有一类“杀毒软件误杀组态软件”的问题我放在后面单独说因为这是很多工厂不敢在上位机装防护软件的直接原因。我的建议是宁可不用传统杀毒软件的实时监控也要把应用白名单跑起来误杀率低很多而且白名单策略对现场实时性的影响更小。5. 按这个顺序落地资产盘点、基线加固、管理与演练讲完原理讲讲怎么落地。很多工厂想做安全整改但不知道怎么开始或者直接找安全厂商堆了一堆设备最后效果很差。我的建议是分三个阶段走每个阶段的产出都看得见。5.1 一张可直接用的安全自查清单我把日常最容易做的检查项整理成一张表适合电气工程师或设备科直接拿去用检查项常见问题处理建议优先级控制器访问密码未设置或使用默认密码设置强密码并由专人保管做好台账高CPU读写保护完全开放可任意上载下载验收后开启写保护控制变更加载高上位机USB管控操作员站USB口全部开放启用组策略禁用U盘需用登记高控制网与办公网边界共用交换机或直连至少做到物理隔离有条件的上工业防火墙高组态软件登录权限共用账户无审计建立独立账户操作日志留存中工程笔记本安全电脑随意接入控制网专用调试笔记本上白名单加离线补丁中关键联锁硬接线过于依赖通信变量梳理安全联锁清单硬接线冗余中备份与恢复只在验收时备份一次定期备份异地保存每年演练恢复高固件与补丁长期不更新停机窗口离线补丁测试后上线低弱口令与共享账户多个工程师共用admin一人一账户权限最小化中这十项覆盖了控制器、上位机、网络、管理和备份五个维度。大多数工厂做完高优先级那几项安全水平就能上一个台阶。5.2 分阶段实施第一个月做什么、第三个月做到什么程度第一个月摸清家底。完成资产盘点画出网络拓扑图关闭控制网里所有不需要的未用端口清理“幽灵设备”把所有控制器的访问密码改成强密码并登记。这个月不追求高大上的设备先把基础卫生搞干净。第二到第三个月边界隔离和设备加固。打通办公网到控制网的所有直连通道改走DMZ部署工业防火墙并调试白名单规则给工程师站、操作员站装应用白名单启用PLC、DCS的读写保护和审计日志。这个阶段要协调停机窗口建议每次停机不超过一个班次分批完成。第四到第六个月检测响应与管理制度。部署流量监测审计系统并建立流量基线制定应急响应流程和备份制度安排一次全员安全意识培训最后组织一次内部攻防演练——请一位懂网络的人模拟攻击路径实际检验防护策略是否有效。到这一步整改闭环就基本形成了。5.3 管理与运维习惯比技术更值钱做了这么多年项目我越来越觉得工控安全的最大瓶颈不是技术是“人”。操作员觉得U盘管控烦工程师觉得密码机制耽误调试时间领导觉得安全投入看不到产出这些心态如果扭转不过来再好的设备也会被绕过。管理措施里效益最高的是这三条U盘和调试笔记本专管专用组态软件高权限账户分人管理外包调试人员进场必须走审批并全程有人陪同。这三条不用花一分钱买设备但能挡住绝大多数由“人”引起的风险。安全培训不要搞成念PPT。我建议用真实场景做演练假装有人往操作员站插了一个U盘看现场人员会不会上报或者模拟一台PLC离线看维护人员能不能按流程在一小时内恢复。演练比培训有用得多。5.4 攻防演练自己“黑”自己一次如果条件允许每年至少做一次工控安全演练场景可以参考这些攻击者从办公网渗透到控制网恶意程序通过U盘进入操作员站后向PLC写入异常参数DCS工程师站被勒索软件加密。演练的目的不是证明“我们被攻破了”而是检验应急处置流程是否顺畅、备份恢复是否真的可用。我们的经验是第一次演练一定会暴露出大量问题比如没有资产清单、密码不统一、备份找不到、应急联系人失联。这些问题在真出事之前暴露出来都是赚到的。演练结束后把发现的问题列成整改清单定责任人、定完成时间下次演练再验证。做到这一点安全体系才是活着的而不只是墙上挂一份制度文件。6. 几个把安全整改做成“事故”的教训最后讲讲我们见过的翻车现场。安全整改本意是保护生产但如果操作不当反而会制造事故。这几个坑值得所有准备做工控安全的人提前知道。6.1 防火墙规则把正常通讯也拦了有个项目给控制网部署了工业防火墙规则写得不够细把PLC和变频器之间的PROFINET实时报文也过滤了。结果产线运行没几分钟变频器就报丢站停机。当时现场急得团团转最后发现是防火墙的默认策略把未知协议丢掉了。这告诉我们两件事第一工业防火墙策略必须按“最小开放”原则逐条梳理每条规则都要有业务依据第二上线前必须做流量抓包分析确认业务流量包含哪些协议、哪些端口再针对性地放行。宁可在测试环境多花两天也不能在产线上试错。6.2 杀毒软件和白名单误杀组态软件很多工厂给上位机装了普通办公用的杀毒软件结果实时监控把WinCC、TIA、组态软件的关键进程当作可疑程序隔离了。操作员正监视着画面呢突然所有变量全红以为现场出大事了。传统杀毒软件的病毒库更新快、误杀率高这在IT环境问题不大但OT环境里一次误杀影响的就是整条产线。我的建议是工控上位机优先用应用白名单产品而不是传统杀毒软件即使要用杀毒软件也不要开实时监控只在维护窗口做全盘扫描。关键是测试环境先验证兼容性再大规模部署。6.3 过度追求“绝对隔离”带来的隐性成本还有一个极端是领导一听网络安全拍板把所有工控设备全部物理隔离谁也不许接外网。结果MES数据要人工拿U盘倒生产报表不能自动生成远程诊断全部停摆工程师每改一次程序都要跑现场效率下降一大截。网络安全不是把所有口子都堵死而是在风险和控制之间找平衡。比如远程维护需求可以通过堡垒机加白名单加操作审计来实现不需要完全断开连接数据采集可以通过OPC UA加证书加密传输不需要靠U盘拷贝。安全整改的最高境界是“该通的通、不该通的不通”生产和管理两头都不误。真正实现这一点不会让现场工程师天天骂娘。6.4 做完这轮整改我的真实体会普能电控这些年做过的DCS和PLC项目里从汽车零部件车间到化工流程控制越来越深刻的感受是工控网络安全绝对不是安全厂商的独角戏。PLC、DCS的“自我防护”核心其实是一句话——让控制系统的每一层都有“最小权限”每一根“工业神经”都知道自己该接收谁的指令、不该接收谁的指令。从控制器密码、CPU读写保护、关键联锁硬接线到网络分区、工业防火墙、应用白名单再到资产盘点、应急响应、攻防演练每一个环节单独看不复杂但它们合在一起才构成一套完整的防御体系。我的切身体会是安全整改最怕的不是技术难题而是“觉得差不多了”的心态——只要有一次演练把备份恢复流程真正跑通你就会发现之前觉得“差不多了”的地方漏洞比想象中多得多。把这个思路带进项目里别把安全当成最后验收时才想起来补的“装饰工程”而是像设计一套联锁逻辑一样从一开始就要验证、测试、维护。这样等哪天真出事了车间才不至于乱成一锅粥。
