1. 先搞清楚工控系统到底“工”在哪1.1 从普渡模型理解OT网络聊工控安全之前得先明白一件事我们保护的到底是一套什么东西。经常有人拿IT安全的思路直接往工控上套结果弄得鸡飞狗跳原因就是对OT系统的运行逻辑缺乏基本认知。工业控制系统ICS跟普通办公网络最本质的区别是它长在一个叫“普渡模型”Purdue Model的分层结构里。大致可以分为几层现场设备层传感器、执行器、变频器、控制层PLC、RTU、DCS控制器、监控层HMI、SCADA服务器、管理执行层MES、历史数据库再往上才连到企业的IT网络。这个分层不是随便画的每一层对实时性、可用性、数据流方向的要求都不一样攻击和防御的侧重点也因此完全不同。举个例子办公网里的服务器宕机员工可能只是刷不出OA页面但产线上的一台PLC如果因为异常重启整个工段可能直接就停了停一分钟可能就损失几万块停一天连交期都要往后延。所以在工控场景里可用性Availability永远是第一位保密性Confidentiality排在其后完整性和IT网络里同样重要但往往需要为连续生产让步。这个价值排序决定了后面几乎所有安全决策的方向。1.2 为什么IT安全经验直接照搬会翻车很多人第一次从IT转过来做工控安全的时候脑子里还是那套“装EDR、打补丁、封端口”的打法结果一进OT现场发现根本不是那么回事。普通办公网络里的一台Windows服务器装个杀毒软件扫一扫基本没毛病。但在工控环境里一台老旧的Windows XP工控机可能连着1998年的DCS系统一打补丁组态软件直接黑屏一套严格配置的防火墙把端口一封PLC之间的实时通信直接超时报警。IT安全强调的是“发现漏洞就尽快修复”OT强调的是“不能因为安全操作影响生产”这两句话在现实中经常互相打架。我从实际项目里总结的规律是这样的在OT环境做任何变更之前先问自己三个问题——这个变更会影响控制指令下发吗会导致控制器重启吗会改变现场设备的运行状态吗只要有一个“会”就必须走变更审批流程而不是像IT那样找个小窗口就顺手给办了。另外工控系统里大量使用私有协议和老的现场总线很多OT设备根本就谈不上有“认证机制”。很多工业交换机默认开启SNMP且口令是public很多老型号PLC没有密码保护或者密码空着这种环境里如果用IT那套漏洞扫描器一顿猛扫不仅扫出来的结果完全不是那么回事还可能因为触发了某些协议的异常报文直接把设备扫宕机。这不是危言耸听我自己就见过一次对一台老式PAC控制器做网络扫描结果某个探测器发出的畸形TCP报文直接把它CPU资源跑满设备进入watchdog重启产线停了半天。所以一定要记住工控安全的第一个原则不是“先扫一遍”而是“先了解清楚再决定动不动手”。2. 攻击面到底在哪里2.1 网络边界的“假安全”很多工厂的网络拓扑用一句话概括就是“远看有防火墙近看全是直连”。我在做现场调研时见过不少这样的情况从企业办公网到生产网之间确实有一台防火墙但管理口直接暴露在办公网段3号VLAN之间还插着私加的傻瓜交换机运维图更新到一半发现实际线缆跟文档完全对不上。这种“纸面分区”给人带来了心理安全感实际上跟裸奔区别不大。更麻烦的是OT网络中跨层直连的现象非常普遍。中控室的工程师站为了调试方便直接通过网线连到了PLC的以太网口历史数据服务器的双网卡一边连着办公网一边连着控制网等于给攻击者搭了一条“跨层高速路”。我自己在授权测试里就干过这种事从一条办公网的网线插进去ARP扫描发现旁边有个网关是通到车间网段的顺势就摸到了几十台PLC的资产列表。整个过程没有任何安全设备告警因为流量完全在内部转发防火墙根本看不到。这里我想强调一个很容易被忽视的细节工业环境里所谓“边界安全”不只是防火墙划分了网段就算数更要关注的是边界的“物理可达性”和“逻辑旁路”。车间里挂着“非授权勿入”牌子的电控柜门锁能不能正常锁上开放网口是否有闲置这些属于物理安全范畴但往往是整个攻击链的第一步。很多PLC的调试口就在现场如果物理上可控性很差网络层面做得再严密也白搭。2.2 协议层老协议欠下的“债”工控网络里跑得最多的协议往往是几十年前设计时压根没考虑安全问题的老家伙。比如Modbus/TCP承载在标准TCP/IP之上端口502帧结构极其简单事务标识符、协议标识符、长度、单元标识符、功能码、数据。它最大的“特色”就是没有认证、没有授权、没有加密只要网络可达任何人发一条功能码0x10的报文就能往远程寄存器里写一堆数据直接改变现场设备的设定值。这不是理论漏洞是实际每天都在发生的事情。前几年国际上曝出的多起针对关键基础设施的攻击事件里攻击者就是通过Modbus/TCP之类的明文协议下发恶意指令导致设备停机或失控的。现在很多国内厂商的设备也支持Modbus/TCP和S7comm西门子S7协议S7comm至少还有一点基本的会话验证但很多老版本里也存在已知问题。真正让人头疼的是这些协议承载的是生产核心业务不能说改就改、说换就换只能靠外围检测和访问控制去想办法兜底。所以在工控安全项目里协议识别和深度报文检测能力有多重要怎么说都不为过。判断一个工控安全产品好不好用很重要的一个指标就是它对Modbus/TCP、S7comm、EtherNet/IP、PROFINET、OPC UA这些主流工控协议的支持深度如何以及能不能根据合法行为模式建立基线然后识别异常的指令序列。大多数IT防火墙是不具备这种能力的它们最多做到五元组过滤根本没法区分一条合法写线圈和一条恶意写线圈。2.3 设备安全PLC和HMI的先天不足除了协议老旧工控设备本身的安全能力也比较弱。很多PLC固件升级周期以年计厂商自己都停止支持的型号仍在产线上服役是常态。有些PLC的CPU模块没有控制逻辑保护功能攻击者如果拿到HMI上的操作权限可以直接上载、修改、下载梯形图程序实现比单纯写寄存器更隐蔽的“业务逻辑篡改”——这种攻击造成的后果不是直观的停机而是让设备在特定条件触发时才出问题隐蔽性极强、破坏力极大。HMI/上位机这边的情况也不乐观。工控机上跑的多是Windows 7甚至Windows XP补丁长期不打很多设备直接通过U盘拷贝组态软件程序USB口成了病毒传播的重灾区。ICS环境里“震网”这类蠕虫的传播路径本质上就是利用U盘跨隔离网跳转的这套逻辑放到现在依然是很多攻击事件的真实路径。某些工厂的防病毒软件因为担心误杀组态软件进程索性不装或者禁用了实时监控于是整条生产线就成了一个无防护的毒窝。设备层还有一个容易被忽视的问题PLC的内存映像和嵌入式Web服务器的默认口令。很多设备出厂带默认口令或者空口令现场人员根本不会去改攻击者只要想办法网络可达登进去就跟回自己家一样。所以我给客户的第一个建议往往不是买防火墙而是先把所有设备的默认口令改掉把多余的服务关掉把不用的网口禁用掉——这些零成本动作做完了安全水位已经提升了一大截。3. 从攻击者视角看一遍测试流程安全提示下面所有内容均以合规的授权测试与安全研究为前提。未经授权对任何组织或个人的系统进行探测、入侵是违反法律法规的行为切勿在真实生产环境中操作。3.1 授权与目标界定做攻防视角的技术验证第一步不是扫描也不是上工具而是把授权书、测试范围和免责协议定清楚。工业环境的攻击测试和IT渗透测试有个很大不同IT测试里你扫崩溃了一台内部测试服务器最多影响一个研发项目OT测试里你扫断了一根 Profinet 总线或者把某个控制器CPU跑满可能直接导致产线停线造成的损失谁承担、测试提前终止的条件是什么全都要在方案里写明确。我在实际项目中通常会先和客户签一个详细测试方案里面明确只允许在指定时间窗口内测试、只允许使用客户提供的测试账号和网段、哪些是“红线设备”严禁触碰比如直接控制关键工艺参数的控制器、测试过程中如果在生产时段出现异常必须立即停止。红线设备的确定非常关键甲方内部对这条的确认程度比任何扫描配置都重要。即使拿到了授权也建议先用旁路镜像流量做分析而不是直接往生产网络里打流量。3.2 信息收集与指纹识别授权范围内的第一步通常是从IT网络入口开始逐步向OT渗透或者直接从一个接入点对工控网络进行资产发现。工控网络里的资产指纹识别跟IT环境里不太一样。除了常规的IP、MAC、端口、操作系统指纹更重要的是识别设备类型、厂商、固件版本、模块型号对应到PLC上还要知道它是哪个系列的CPU运行的是什么固件有没有已知漏洞。在短平快的项目中我用得比较多的是被动流量分析和主动探测结合的方式。被动方式就是把现场交换机镜像口的流量抓下来通过解析Modbus/TCP、S7comm、EtherNet/IP等协议的握手过程直接还原出很多资产的基础信息。这种方式对在线业务几乎没有影响但信息获取速度偏慢。主动探测就要小心了ICMP扫描还好SNMP探测如果目标设备的老固件对畸形请求处理有坑可能会造成设备短暂无响应。所以我的建议是能被动就被动主动探测也要控制在低速率、低并发优先使用轻量级的探活而不是全端口无差别扫描。3.3 识别脆弱点与验证指纹拿到手之后就是找茬。工控场景里的漏洞挖掘重点往往不是Web攻击那一套而是集中在几个方向控制协议的逻辑缺陷、设备管理接口的口令强度、老固件中已知的远程代码执行漏洞、组态软件自身的安全问题例如某些SCADA软件的前端不需要认证就能读历史数据、以及上位机上第三方应用的暴露面。比如遇到一个暴露了S7comm的S7-1200 PLC我会先看它的连接机制是否允许无认证访问再查看固件版本对应的已知问题列表。遇到Modbus/TCP节点除了做端口扫描之外更常用的是直接构造合法读写报文做功能性验证——例如先读取几个保持寄存器的当前值确认通信正常再决定是否做有限的、可逆的设置测试这里每一步都要慎之又慎因为写操作一旦出错可能直接改变工艺参数。大部分时候我们只会验证到“可控”这一层把证据链做实了就收手后面设备是否脱缰、影响面多大留给防护方案去解决。3.4 建立访问与控制攻击链走到最后一步通常就是如何在目标系统里维持控制能力。考虑到这是“入门”级的文章我不会去展开任何具体的后门植入方式但想借此普及一个原则攻击者真正重视的不是“一次性破坏”而是“持续控制”。通过长连接、计划任务、替换合法运维工具等方式攻击者可以在不引起注意的前提下长期驻留等到关键时机再触发恶意动作。所以防守方需要建立的认知是攻击检测不能只看“有没有单点的恶意行为”更要看“异常行为的组合模式”。比如某台HMI深夜连续登出登入、某台PLC的DCOM端口突然对外开放、某个账户在凌晨两点从办公网发起RDP连接这些孤立事件每一条都不起眼组合起来就有很高的嫌疑。平时多关注这类关联分析防守能力就已经比只看病毒特征库的同行走在前面了。4. 防御侧怎么落地4.1 网络分区是地基别想着一步到位防御工程最核心的一步不是上多贵的设备而是先把网络结构捋清楚。我见过太多工厂一上来就买一大堆安全设备结果部署完了发现流量根本没经过设备或者为了迁就生产又不得不把策略全部放通。网络分区这件事虽然做起来很土、很费劲但它是后面一切安全手段能发挥作用的基础。分区的基本原则遵循普渡模型把不同层级和不同业务域用防火墙/工业交换机隔开。层级之间只放行必需的业务端口默认全部拒绝。办公网到生产网的互联用一个独立DMZ区放文件服务器、历史数据库镜像不直接把供应链系统对接到PLC。_WP_IF_见惯了的情况下具体分多少个区、按什么粒度划分要跟着产线情况来。老线改造的时候很多地方没办法立刻加防火墙可以先用交换机ACL做一层逻辑隔离再逐步向硬件防火墙演进。整个过程不要想着一步到位但方向一定要坚持所有通往PLC的路径最终都要收口到可管控的通道里。4.2 白名单机制是工控安全的核心玩法给工控网络做安全的同学一定听说过白名单这个概念。IT安全里习惯用黑名单查病毒特征但OT环境里很多漏洞是未知的、协议的行为边界是模糊的黑名单根本拦不住。白名单的思路是反过来先建立起一套“正常行为基线”凡是偏离基线的都告警或阻断。白名单可以分几个层面来做。网络层白名单只允许特定源IP和目的IP之间互相访问特定端口和协议。例如一台PLC只接受工程师站的S7连接别的IP一概拒绝这一步可以用工业防火墙实现。应用层白名单针对Modbus/TCP这类协议严格校验功能码和寄存器地址范围比如只允许读功能码0x03、0x04阻止写操作0x06、0x10这需要能深度解析工控协议的安全网关才能做到。主机层白名单在工程师站和操作员站上做应用程序白名单只允许运行组态软件、办公软件等已登记应用的可执行文件从根源上防住U盘或者钓鱼文件释放出来的恶意程序。从项目实施效果看多数工控安全事件被止损的关键点往往都是白名单体系先于特征库发现了“越界”行为。我自己在客户现场就遇到过类似的情况一个内部维护人员误操作把一台新笔记本接到控制网开始用PS走S7协议连PLC白名单策略立刻推送告警并拦下了建立连接的动作。当时设备还没上线但这条告警让运维人员及时发现了私接设备的问题避免了一个未经认证的终端提前走进了控制网络环境。4.3 资产台账与漏洞生命周期管理工控安全的另一个硬伤就是“不知道自己家里有什么”。很多工厂的资产台账停留在纸面上新增加了一台传感器、换了一块网卡、调了一个IP没人更新记录。没有准确资产清单就没法做针对性的漏洞管理和风险分析这是一切的基础也是个又苦又累但绕不开的活。资产发现这里我建议分三步走第一步通过厂商的设备列表和图纸整理出静态台账第二步用被动流量分析工具跑一到两周结合主动轻量探测把实际活跃IP、MAC、设备类型补全第三步将台账落地到资产管理平台保持周期复核。有条件的工厂甚至可以在采购环节就明确要求设备必须支持SNMP/v3或具备资产识别标记能力减少后续的维护成本。漏洞管理在OT里往往不是越新越好。很多安全更新补丁还没有经过厂商适配验证直接打上去可能引入新的兼容性问题。正确的做法是建立一条“漏洞跟进—风险验证—变更窗口—灰度发布”的闭环流程。对每个新披露的漏洞先判断它是否真正影响自己环境的设备型号和固件版本再结合可利用条件评估风险等级。如果确实需要补要跟生产计划对齐在工艺停机窗口里做变更补完以后立刻回归测试控制功能。千万不要觉得“网上出了补丁我就赶紧打”是对的在OT环境里这种做法反而容易出大事。4.4 运维侧的“人”永远是防线的一部分技术手段再强最终都要落到操作人员的日常习惯上。我从多个工控安全项目里感受到真正的薄弱点往往不是设备而是流程和习惯上的随意性。比如工程师为了方便调试把HMI和PLC之间的通信密码直接写在一个共享文档里比如外来调试人员进车间连上控制网后全程无人登记审批再比如U盘在办公网和控制网之间来回插从不做病毒查杀。对这些行为层面的问题单纯靠技术管控不完全靠谱。建议从三个方向一起抓制度上建立外来人员或设备接入审批流程和追溯记录技术上对工程师站实行账户统一管理权限最小化U口做物理管控或软件策略限制意识上定期做小型演练让操作和维护人员亲身体会一次“误操作导致产线停线”的后果比发一百条安全通告都有用。运维侧管理做得好攻击者连第一步“渗透边界”都会困难很多因为接入就会被发现、异常就会被追问。5. 实战中的常见问题与排查实录5.1 误报风暴安全设备把正常生产流量当成入侵上了工控安全设备之后最常遇到的坑就是误报太多把正常生产流量当成攻击流量。比如组态软件启动时会批量请求某些设备的端口安全设备触发大量告警运维人员一天收到几千条消息很快就“狼来了”对后续真正的高风险告警也麻木了。这个问题的根子在于安全策略建立时没有充分考虑业务基线。解决办法其实不复杂部署工业安全设备后一定要留出一段“学习期”让设备基于正常的业务流量自动建立基线模型然后再进入监控和阻断模式。用白名单策略时也建议从宽松模式起步逐步收窄。我通常建议客户在完全上线前先跑一个月左右的学习模式其间只记录不阻断运维人员每周审核一次告警列表把确认为正常业务的流量加入白名单。等误报率降到可控区间后再逐步放开阻断策略这个过程的耐心非常重要省了这步后面全是泪。5.2 扫描把PLC扫“宕机”这就不多解释了前面提了好几次。团队在授权测试中曾经对一台老式PLC做过快速扫描结果目标设备的嵌入式协议栈处理不了大量并发连接CPU全被占满最后设备重启。事故发生后整个项目被迫暂停了两天来做原因分析和设备恢复验证。这是我早期做工业渗透测试踩过最大的坑之一。给大家三条硬经验第一对生产控制器的主动探测永远先做资产确认搞清楚设备类型和固件年代再决定扫描方式第二默认使用低速率、半开连接扫描时限并发控制到很小尽量避免直接发畸形报文第三测试窗口优先选择产线空转、检修或非生产时段还要建立实时应急回退机制。一旦设备出现异常立即断网、重启交换机端口并按应急预案通知工艺人员千万不能为了“多测一点”死扛。5.3 补丁到底该不该打什么时候打这个问题几乎每位客户都会问也是最难回答的问题之一。给工控环境打补丁核心矛盾是安全和可用性之间的取舍。我的建议是把设备分类管理控制层的PLC和RTU基本不需要打操作系统补丁因为它们的代码是固定的、无文件系统或者固件化一般优先关注固件更新而操作员站、工程师站和SCADA服务器的操作系统和应用软件才是补丁管理的重点。具体操作上先对需要打补丁的台套编号建立清单评估每个补丁对已有组态软件和驱动的兼容性然后找一台测试环境哪怕是一台虚拟机跑一遍完整回归确认组态软件、通信早就和业务驱动都不受影响后再在停机窗口里分批部署。另外有个小技巧给工程师站准备一个镜像备份工具打完补丁后如果出现兼容性问题十分钟内就能回滚到之前可用的快照这在实战中救过我很多次。5.4 资产台账“漏项”引发的连锁问题最后一个常见坑来自台账有时候资产清单漏掉了一个车间里的嵌入式设备结果这台设备的漏洞没人管直到事件发生了才被发现。这类设备往往是监测仪表、协议网关或者某种专用小盒子平时不怎么起眼但它们通常会用传统账号密码还会开放Web管理界面。解决思路是建立周期性的资产核查机制把被动流量分析纳入日常运维流程用机器自动识别取代人工统计。即使厂商的设备管理做不到全自动至少也要保证每年做一次全网资产复核把新增、报废、变更的设备及时更新进台账。另外采购环节就应该对新增设备提出安全准入要求必须能产生资产识别信息、默认口令必须可修改、固件必须能升级做不到这三点买回来就是个“安全坏账”到时候再头疼就晚了。最后再分享一点我个人的体感。做了这些年攻防和防护项目发现工控安全领域真正有经验的人几乎都是从“被自己的扫描器坑过”或者“被生产事故吓到过”的经历里长出来的。入门的人往往热衷于研究攻击手法越看到后面越觉得兴奋真正上过一线的人反而越做越谨慎越做越敬畏生产系统。攻与防本身就是螺旋上升的过程——每次攻击视角的研究都会促使防御策略不断完善每个生产系统的新变化又会暴露出新的攻击面。所以与其焦虑“漏洞怎么这么多”不如踏实把网络结构梳理清楚、把白名单机制做扎实、把资产台账建明白。做到这几点你所在系统的安全水位在同行业里已经算相当靠前了。