PLC与DCS工控安全防护实战：从脆弱性到纵深防御

1. 警报来源：PLC和DCS为什么天生就“不安全”

1.1 协议的设计年代：那个没想过要防人的时代

搞工控的朋友都知道，PLC和DCS本质上是实时控制系统，核心任务是保证生产连续性。我们天天跟Modbus TCP、PROFINET、S7comm、EtherNet/IP这些协议打交道，用起来顺手，逻辑也简单粗暴——主站轮询、从站应答，谁发指令谁就说了算。可问题恰恰就出在这个“谁发指令谁就说了算”上。

这些主流工业协议诞生于七八十年代甚至更早，设计者当时的核心诉求是可靠、实时、易用，压根没考虑过“认证”和“加密”。比如Modbus TCP，报文里连最基本的身份验证都没有，只要IP能通，你发一个写线圈指令，PLC就老老实实执行。哪怕到了今天，不少新项目里Modbus TCP仍然在裸奔，一个普通程序员抓包抓两天，就能模拟出合法的上位机指令把现场设备停了。

真实情况比很多人想的还要朴素：工业现场的设备是“能通信就不设防”，协议层没有加密、没有签名、没有限速，全靠网络边界来兜底。一旦边界被穿透，底层设备就是透明的。这也是为什么我一直跟同行强调，别把安全希望寄托在“别人进不来”，而是要想清楚“别人进来了以后，你花多久才能发现”。

1.2 气隙隔离的幻象：物理隔离不是保险柜

早些年很多老工程师笃信“物理隔离就是绝对安全”，觉得生产网和办公网是两张网，中间没有连接，外网攻击根本打不进来。这个思路在十年前确实能挡住绝大多数威胁，但放到今天，已经越来越难成立了。

第一个现实问题是运维便利性倒逼网络打通。工厂要做MES、要做设备远程监控、要上云做数据分析，生产数据终究要往上层传；厂家远程调试、售后诊断也需要远程通道。很多改造项目为了省事，直接在防火墙上面开了个口子，或者用USB拷贝程序、用笔记本电脑在办公网和生产网之间来回插拔，物理隔离实际上变成了“半隔离”甚至“名义隔离”。

第二个问题是内部威胁。工控安全事件里，真正影响最大、最难防的往往不是外部黑客，而是内部误操作或有意为之。一个工程师把旧程序的U盘插到PLC上，一台维护笔记本因为接入了染毒网络又把病毒带到了控制网，这类事件在全国范围内隔三差五就会发生一次。物理隔离能防住外面的“箭”，却防不住从里面打出来的“枪”。

1.3 从震网到恶意软件：PLC和DCS被盯上的真实剧本

说到PLC和DCS的安全风险，必须提历史上几次典型的攻击事件，它们基本代表了这门攻防战的演进路径。

最早的经典案例是震网病毒，它是全球第一个专门针对工业控制系统的“定制化武器”，通过U盘摆渡进入隔离的工厂网络，利用西门子WinCC和Step 7软件的漏洞，篡改离心机转速指令。那个年代大家的认知是“PLC藏在最底层，攻击者够不着”，震网直接把这个神话击碎了——只要攻击者掌握了协议逻辑，设备离得再深也能被精准打击。

后来的Industroyer更是直接把矛头对准了变电站的IEC 60870-5-104通信规约，能够直接远程控制断路器的开合。Triton恶意软件则把攻击目标指向了安全仪表系统，也就是SIS——这是比DCS更高一级的安全保护层，一旦被篡改，后果就是连锁性的物理灾难。

这些案例说明一个趋势：攻击者已经从“蹭热点”、“顺手黑一把”变成了“定向研究工控协议”、“精准打击关键设备”。PLC和DCS作为连接数字世界与物理世界的执行末端，天然成为了高价值目标。咱们再不重视自我防护，下一次警报就不是新闻里的个案，而是自己车间里的停机事故。

2. 自我防护第一课：先把“神经末梢”管起来

2.1 资产清点：你连自己有多少个CPU都不知道，谈什么安全

我跑过不少工厂，第一件事不是看防火墙，而是问一个问题：你们车间里一共有多少台PLC、多少套DCS控制器、多少台上位机操作站、交换机端口都插了什么设备？

绝大多数人答不出来。这很正常，很多项目经过多年改造扩容，硬件台账早就过期了。但做安全加固，第一步必须是资产清点。你连“家底”都不清楚，后续的端口白名单、访问控制、异常检测全都是空中楼阁。

实操时建议从三层入手梳理：

• 控制层设备：PLC的型号、固件版本、IP地址、机架位置、连接的下游IO模块。
• 监控层设备：操作员站、工程师站、历史服务器、OPC网关的IP和安装软件列表。
• 网络层设备：交换机端口对应的设备MAC、VLAN划分情况、防火墙策略清单。

我见过一个化工项目，清点完以后发现现场居然有三台早就不在用的老式PLC还挂在环网上运行，固件十年没升级，谁也不知道当初是干什么用的。这种设备就是典型的安全黑洞，应该立即在交换机层面隔离或下线处理。

2.2 补丁与固件：能打就打，不能打就“软隔离”

PLC和DCS系统的补丁管理，是安全加固里最让工程师头疼的环节。IT系统的补丁打完顶多重启一下，几天就完事了；工控系统不行，很多装置常年连轴转，一个停车窗口可能就是几百万的损失，没人敢拿生产开玩笑。

所以我给的建议分两种情况处理。

第一种情况是设备本身有安全修复版本，且现场有停车窗口。这种情况务必联系厂家确认补丁的兼容性，在仿真环境里先做回归测试，再安排停机窗口升级。比如西门子S7-1200和S7-1500的固件，新版本通常修复了已知的DOS漏洞和访问保护漏洞，TIA Portal里升级起来相对直接，但一定要确认程序使用的通信指令、运动控制功能在升级后仍然正常。

第二种情况是实在没法停机升级。这种情况可以采用补偿性措施，比如在交换机上做端口隔离，只允许工程师站与PLC通信，其他终端一律禁止访问；限制PLC的Web服务、FTP服务等非必要端口；把固件太老、无法修复的设备划分为“高危区”，配合上位机监控告警，实时关注有没有异常访问。原理很简单——打不了“疫苗”，就把它关进“隔离病房”。

2.3 密码与账号权限：别再用默认口令跑生产

前两年做等保测评的时候，有一次在现场扫描设备，发现一套大型DCS系统的操作员站账户竟然是默认的sa密码，工程师站干脆Administrator空口令。当时同行的信息部门同事脸都绿了，但现场运维的师傅也挺委屈：项目投运五六年了，厂家从来没要求改过密码，大家也不知道怎么改。

这就是工控安全的普遍痛点。PLC和DCS的密码体系远不如IT系统完善，很多老型号要么没有访问口令，要么口令以明文存储在项目中，改起来还容易把项目程序加密锁死。但再难也要做，重点从这几方面下手：

• 西门子PLC：在TIA Portal的设备属性中启用“防护与安全”，设置CPU访问密码，区分只读和读写权限。新固件支持更细粒度的功能访问控制，建议把写访问权限只给工程师站。
• 三菱PLC：在GX Works中设置远程密码，限制通过GX Works、以太网模块、Web服务器对CPU的访问。
• 罗克韦尔/AB：启用RSLogix/Studio 5000项目的代码签名和控制器密码。
• DCS系统：在工程师站、操作员站的操作系统层做账户分级，DCS软件内部按角色分配权限，操作员只能操作画面、查看趋势，工程师才具备下装和组态修改权限。

要特别提醒的是，改完密码一定要把密保资料交给专人归档，并且同步更新设备台账。我遇到过客户把PLC密码忘记，程序又没备份，只能把整个控制器恢复出厂重写的惨痛案例，代价比不设密码还大。

3. 网络架构层面的“自我防御”：区域隔离与纵深防御

3.1 区域和通道：工业防火墙该怎么接

工控网络安全圈子里有一句被反复提的话叫“纵深防御”，说白了就是别把安全寄托在任何单点上，而是像剥洋葱一样一层一层设防。落到实际项目里，最基础也最实用的模型就是IEC 62443标准里的“区域”和“通道”概念。

区域可以理解为“信任等级相同的设备集合”，比如办公网是一个区域，生产执行层MES是一个区域，控制层DCS/PLC是一个区域，现场仪表又是一个区域。不同区域之间的信任等级不同，必须通过“通道”来通信——这个通道就是带访问控制的工业防火墙。

具体接法上，我现在比较推荐的做法是：在办公网与控制网之间部署工业防火墙，策略默认全部拒绝，只放行MES系统与历史数据库服务器交互所需的最小化端口和IP。各生产车间的PLC之间如果确实需要横向通信，也在核心交换机上做VLAN隔离，在汇聚交换机上再做一轮ACL控制。

有人问我为什么不用传统IT防火墙替代工业防火墙，原因很简单：工控协议的特点和IT协议差别太大。传统防火墙对Modbus TCP、PROFINET这类深度协议做不了应用层识别，而且高实时性的通信往往会因为状态检测机制导致延迟抖动。专业工业防火墙支持协议白名单、功能码过滤、甚至能识别“写寄存器”这种具体指令类型，更贴合工控场景。

3.2 单向隔离：让数据只出不会进

如果是涉及保密性极高的数据采集场景，我特别推荐一种被低估的部署模式——单向隔离网关，也就是俗称的“数据二极管”。

听着神秘，原理其实很简单：物理上只允许数据从控制网流向管理网，反方向没有任何回传通道，即使管理网被完全攻陷，攻击者也碰不到控制网里的任何设备。这套方案非常适合那些“只要采集生产数据、不需要远程下行控制”的场合，比如设备OEE统计、能耗监测、工艺参数记录等。

为什么说它被低估？因为很多场景其实不需要双向操作，但项目一启动，各方默认就要“双向通道”。实际梳理一遍业务需求后你会发现，车间采集数据的下行指令少之又少，真要用单向网关把下行全掐了，不仅安全隐患没了，运维也变得清爽很多。当然，单向隔离也有代价，部署成本偏高、带宽有限，而且无法支持远程组态下装这类双向业务，所以它适合当纵深防御里的重要一环，而不是万能药。

3.3 远程维护通道的安全策略

远程维护是另一个绕不开的话题。这几年设备联网需求爆发式增长，厂家远程调试、PLC程序远程更新变成了刚需。但远程通道如果不做管控，等于在生产网墙上开了一扇不知道什么时候会有人敲的门。

我经手过不少安全项目，远程维护方面比较靠谱的落地方案是“跳板机+白名单”的组合。具体做法是：在工业防火墙或堡垒机上设置远程接入服务，所有远程连接必须先通过身份认证，再跳转访问指定的工程师站，由工程师站发起对PLC/DCS的通信，外网不能直接触达控制器。

身份认证层面，建议采用双因素认证，密钥或动态口令都行，单纯的口令认证我已经不太信任了。同时要给每个远程维护人员分配独立账号，做到操作可追溯——哪个人在什么时间通过远程通道访问了哪台PLC、执行了什么命令，全部记录留存。

我记得有个玻璃厂客户，远程维护通道常年开着，用的还是厂家出厂时的默认端口和默认口令。安全评估完以后，我们帮着收口了访问来源、改了认证机制、加了会话超时，后来厂家远程调试的时候还在抱怨“怎么多了这么多步骤”，但真出过一次安全事故之后再回想，这套流程救了他大命。

4. 车间一线的可见性：流量监测与异常发现

4.1 建立工控网络流量基线

很多工厂的安全策略是“防得住就好”，但真正等到攻击发生时，你才会意识到“看得见”比“防得住”更重要。攻击者进入控制网以后，不可能完全隐形——他会扫描、会发起异常连接、会尝试非预期的协议指令，这些行为都会在网络流量里留下痕迹。

那怎么发现呢？核心方法是先在正常工况下持续采集一段时间的网络流量，形成“基线画像”。比如某条生产线正常工作时，工程师站与PLC之间每分钟通信多少次、平均流量多大、访问了哪些IP和端口、用了哪些功能码，这些数据稳定下来以后，就是这台设备的标准行为模型。

我见过比较高效的落地方式是采用旁路部署的工业安全监测系统，把交换机的镜像端口接到安全设备上，被动监听网络流，不改变网络结构，不影响生产通信。系统内置工控协议深度解析能力，能识别Modbus TCP、PROFINET、OPC UA等主流协议的内容级行为，发现异常指令、非法写操作、非预期组态变更时自动告警。

4.2 白名单机制：把合法指令之外的东西全忽略

传统IT安全工具依赖的是“黑名单”思路，病毒库、特征库、攻击指纹——只要不在库里的威胁，默认就是“看似安全”。但工控环境恰恰相反，网络里的设备和通信行为都非常固定，生产线一旦稳定，通信关系基本几年不变。这时用“白名单”思路更合适：凡是没经过审批的通信行为，一律视为可疑。

具体到现场，可以做三层白名单：

• IP和MAC白名单：只允许已知设备接入控制网，新设备或未知MAC地址出现时触发告警。
• 端口和服务白名单：PLC只开放生产必需的端口，非必要的HTTP、FTP、SNMP服务全部关闭或过滤。
• 工控协议功能码白名单：监控系统只允许特定功能码的读操作，比如Modbus的03读保持寄存器，写操作必须限定在特定地址范围内。

白名单机制的优点在于误报率极低，因为工业通信太规律了。这套方案做扎实以后，很多原本需要依赖安全专家才能发现的异常，系统直接就能拦下来。代价是初始梳理工作量比较大，每个区域都要做一次通信关系摸排，说白了又是台账和资产管理工作。

4.3 与DCS/PLC联动的告警处置

流量监测系统发现异常以后，下一步怎么处置？这是很多项目的短板。很多工厂上了安全监测设备，结果每天告警几百条，运维人员看不过来，最后干脆把告警关了，等于白装。

我建议告警分级处理：

低级别告警（比如非授权IP扫描），只记录、不干预，留作事后溯源。 中级别告警（比如某一台PLC出现异常连接），通知值班工程师确认，重点排查是不是有人违规接入了维护终端。 高级别告警（比如发现PLC程序正在被非法上载或下装），要能联动工业防火墙阻断通信，并自动给安全管理员发短信。

想要做到“监测与阻断联动”，前提是安全设备与网络设备要打通接口。现在主流的工业防火墙和工控安全监测平台，基本上都支持与交换机的联动，收到高级别告警后自动拉黑源IP或切换交换机端口。这套闭环是我比较推荐大家优先落地的能力，比单纯堆设备有意义得多。

5. 攻击发生了怎么办：PLC和DCS的应急与恢复

5.1 千万不要急着重启：证据与排障

不管防护措施做得多到位，总会有万一。真遇到PLC或DCS疑似被入侵的时候，最容易犯的错误就是“慌不择路”地重启设备。重启固然能让问题暂时消失，但也把现场的证据全毁了——攻击者的IP、恶意指令、进程痕迹全都没了，后面想复盘原因、想追责、想防第二次，全都无从谈起。

正确的处置顺序应该是：

先断网，在交换机上把疑似受感染的控制器与上位机、外网的连接断开。注意是断网，不是断电；控制器断电会导致现场设备失控，风险极高。 接着拍照、录屏、抓取CPU诊断缓冲区和事件日志，把报警信息保存下来。 再联系厂家或安全服务商，调取安全监测系统的告警记录和流量包，还原攻击路径。 最后才是考虑恢复生产，也尽量用备份配置而不是重新编程。

我自己参与应急处置时，衡量成败的标准往往不是“恢复得有多快”，而是“能讲清楚发生了什么”。一次说不清来源的安全事件，后面极大概率会再次发生。

5.2 配置备份与还原：让“神经回路”快速复位

PLC和DCS的配置备份，是应急恢复里的第二条命。

很多工程师对备份的态度是“项目投运以后就没再动过”，这是一个非常危险的盲区。生产线的程序是要持续优化迭代的，今天的程序和投运时已经完全不同，如果拿旧备份去恢复，等于把几个月的调试成果全废了。

规范的备份策略应该是“每次组态变更后立即备份，且至少保留最近三个版本的完整备份”。备份文件不仅要存到本机，还要离线拷贝一份放到安全位置，防止车间感染病毒以后连备份一起被加密或删除。

对于DCS系统更复杂一点，因为除PLC逻辑外，还有操作站组态、历史数据库、报警配置、网络拓扑等。恢复的时候讲究顺序：先恢复网络配置，再恢复控制器逻辑，最后恢复上位机画面和历史数据。顺序乱了，轻则画面连不上数据，重则整个系统状态不一致，跑起来非常闹心。

5.3 演练：在真出事之前先排练几遍

应急响应方案写得再厚，如果从没演练过，等于废纸。这不是夸张话——我见过很多企业在安全事件发生时，连值班电话、应急联系人名单都找不到，更别提按照预案步骤执行了。

工控安全的应急演练可以从小规模开始，不需要上来就做全厂级别的红蓝对抗。建议分三步走：

第一步，桌面推演。拉上运维、仪表、电气、信息安全几个部门，对着预案把各个角色过一遍，看看谁负责断网、谁负责通知、谁负责联系厂家、谁负责对外汇报，把责任边界理顺。

第二步，模拟一次小范围攻击演练。在一套备用的PLC或虚拟仿真环境里，人为执行一个非法下装动作，观察监测系统能不能准确发现、告警，并检验应急处置流程是否顺畅。

第三步才是结合真实业务的深度演练。演练时要在非生产时段进行，提前通知所有相关人员，避免误将演练当真实攻击处理。

演练中发现的问题要及时复盘修正预案。我亲身经历过一次：演练时发现服务器备份恢复时间需要8个小时，而业务要求恢复时间不能超过2个小时，最后调整了备份策略，把恢复时间压缩到了40分钟。这种问题如果不演练，真出事那天就够哭一场了。

6. 现场排查高频问题实录：工控安全落地时的坑

6.1 常见问题与排查速查表

把我在各类现场碰到的典型问题整理成了一份速查表，希望对正在做安全加固的同行有帮助。

6.2 安全规则与工控协议冲突：误告警把运维搞崩溃

工控安全项目落地过程中，最常见的摩擦点就是安全规则与生产业务规则的冲突。

举一个实际案例：某汽车零部件产线部署了工控防火墙后，白名单策略严格按照“工程师站只允许访问PLC的102端口”来配置，结果第二天产线就出现偶发停机，查了半天才发现是PLC之间的PROFINET实时通信因为防火墙策略判断导致延迟抖动，超过了CPU的看门狗时间。最后把同一生产单元内PLC之间的通信链路移出防火墙监控范围，才彻底解决。

这个案例说明一个原则：安全策略必须与生产策略协同设计，而不是简单把安全设备串在所有的通信链路中间。工业控制通信讲究确定性和低时延，安全设备的部署位置和策略粒度一定要结合现场生产工艺来调整。

6.3 给自动化工程师的三个实操心得

做了这么多年的工控项目，最后分享三个我个人的实操心得。

心得一是B计划永远要提前准备。PLC程序升级、固件升级、安全策略调整之前，先把旧版本、旧配置完整备份好，并且验证过备份可恢复。保守一点不是坏事，现场生产高于一切，能回退才有底气去变更。

心得二是把安全要求融入到编程习惯里。写PLC程序的时候，用状态机而不是布满跳转的自由逻辑，程序结构越清晰，后续做安全审计、功能校验就越轻松；通信数据做滤波消抖，既能抗干扰，也能减少异常信号对设备动作的误触发；涉及设备安全的联锁逻辑，在PLC程序里和DCS逻辑图里都要有冗余互锁，哪怕上位机被篡改，底层还有最后一道保护。

心得三是安全不是一次性投入，而是一个持续循环。资产清单要定期更新，安全策略要随着产线改造同步修订，监测告警要有人真正盯。我见过太多项目在验收期一切正常，过了半年就彻底回到“裸奔”状态，说到底不是技术问题，是运维机制没有跟上。

说到底，PLC和DCS这些“工业神经”的自我防护，真正难的不是买几台安全设备，而是把“安全优先”的思维融进每一个项目设计、每一次程序变更、每一次日常巡检里去。这个道理，越早想明白，后面越省心。