工控系统安全测试这件事圈子里讨论得很多但真正能落地的、可以直接复用的测试用例并不多。我之前在几个生产型企业的工控安全评估项目里前前后后整理过一批用例踩过不少坑也总结出了一些比较实用的设计思路。这篇就把我的做法摊开来写从用例设计逻辑、分类框架到具体执行细节尽量一次讲透。不管你是刚转行做工控安全的新人还是已经在做等保测评、渗透测试但没怎么碰过OT环境的同行这篇应该都能给你一些参考。1. 工控安全测试的整体思路先把场景想明白再动手1.1 工控环境与传统IT安全测试的本质差异很多做惯了IT渗透的人一上来就拿Web漏洞扫描器往工控网络里怼这是最典型的错误。工控系统和传统信息系统在安全目标排序上有着根本性的不同IT系统讲究机密性优先数据不能泄露是第一位而工控系统一定是可用性优先、完整性第二、机密性排最后。原因很简单——生产停一次机的损失可能顶得上几百条员工信息泄露。这里我常用一个类比来解释IT系统像普通门诊系统挂了可以重启患者等等没关系工控系统像ICU病房设备一旦停摆可能直接威胁到整个生产的生命线。所以在工控环境里做测试第一原则永远是“不干扰生产”而不是“测出多少漏洞”。这也决定了测试用例在设计时必须考虑影响面——哪些操作允许做哪些操作绝对禁止哪些操作需要提前跟客户确认窗口期全部要写进用例的前置条件里。另外工控环境还有一个特点就是技术代差跨度极大。一条产线里可能同时运行着上世纪九十年代的PLC、2010年前后的Windows XP上位机和新买的工业防火墙。老的PLC大多采用Modbus这类无认证、无加密的协议通信数据裸奔在网络上任意一个能触达网络的节点都能伪造指令。新的OPC UA则支持证书认证和传输加密安全性好了不少但配置复杂度也上来了现实里很少有人把安全配置真正做对。测试用例必须覆盖这个差异区间不能只拿一套标准糊弄过去。1.2 测试用例设计的核心原则我设计工控安全测试用例时基本遵循以下五条原则你可以直接拿去当检查清单用风险驱动原则先梳理资产和业务链路找出最关键的工业控制系统比如直接控制锅炉、反应釜、流水线启停的那一层优先设计针对这些核心资产的用例而不是平均用力。分层分级原则从边界网络、内部通信协议、上位机应用、现场控制设备到管理制度一层层往下打。测试行为从无害的配置核查逐步过渡到可能产生影响的渗透操作每提升一级都要重新评估风险。最小影响原则能用被动观测解决的绝不用主动发包能用单个包测试的绝不做全量扫描。比如抓包分析协议行为就够了的地方就不要对着PLC做模糊测试。可回溯原则每条用例都有独立编号操作步骤里的每个命令、每个数据包都能对应到记录和证据。工控测试出问题时第一反应一定是查“我们刚才做了什么”没有回溯能力基本等于没写用例。业务闭环原则用例必须关联到具体的工艺场景。比如“修改某PID控制器的设定值”这类用例要和客户的工艺工程师确认这个动作会不会触发联锁保护而不是简单套用IT渗透模板。这里要特别提醒一个新人容易犯的错误在设计用例时只关注“能不能打进去”忽视了“打完以后怎么恢复”。我见过不止一次测试完忘记恢复PLC里的临时寄存器值导致产线第二天开机数据异常。所以我的每一条用例模板里都有一个必填字段恢复步骤。这个字段不写清楚这条用例就不能通过审核。2. 测试用例架构与分类框架2.1 按测试对象分层从边界到车间工控安全测试用例要做到系统化关键是把测试对象分层。我参考Purdue模型的分层思想把用例分为五个层级每层关注的问题完全不同。测试对象层覆盖范围典型关注点用例特点网络边界层工业防火墙、安全区边界、DMZ访问控制策略是否有效、非授权跨区访问能否拦截以策略核查和绕过测试为主影响可控通信协议层Modbus、OPC UA、Profinet、DNP3等协议认证、加密、畸形报文处理能力需要专用测试工具风险较高主机与应用层工程师站、操作员站、HMI、历史数据库系统补丁、口令策略、恶意代码防护以基线核查为主少量渗透验证现场设备层PLC、RTU、DCS控制器、智能仪表固件完整性、未授权访问、在线篡改风险最高多数只能在停产检修窗口执行管理与流程层运维流程、账号权限、变更管理制度是否健全、流程是否可审计以访谈和文档审查为主完全无风险这样分层有个直接的好处风险可控且优先级清晰。我接项目时一般会先和客户谈清楚哪些层级做全覆盖哪些层级别碰。比如很多化工企业的DCS系统现场设备层别说做模糊测试了连在线扫描都要客户安全部门层层审批。这时候你的用例库就得有“不可执行”的标记机制确保测试方案不越界。2.2 按测试方法分类六种打法各司其职同一个测试对象从不同角度切入用到的测试方法也不同。我通常把用例按方法学分成六类它们之间有明确的逻辑先后基线核查类检查系统配置是否满足安全基线包括端口开放情况、账号口令策略、补丁安装情况、共享目录权限等。这类用例占比最大约40%基本无风险是每次测试的起点。漏洞扫描类用专用扫描器对主机和网络设备做漏洞探测注意一定选用支持工业协议的扫描器比如专门做ICS漏洞扫描的工具普通IT扫描器对工控协议支持极差还可能因为发包太猛把设备打挂。渗透验证类对基线核查和扫描发现的问题做进一步利用验证比如通过口令爆破进入某台工程师站然后尝试利用该主机访问PLC。这类用例必须有明确的授权边界。协议模糊测试类向被测设备发送畸形或异常报文观察设备是否崩溃、死机或产生异常响应。这类用例风险最高只能用于测试床环境或者停产检修时在客户明确的单台设备上执行。配置审计类针对工业防火墙、工业网关等专业安全设备的规则配置进行逻辑推演检查是否存在绕过路径或过度授权规则。固件与供应链类提取PLC、智能仪表固件检查硬编码口令、密钥泄露、签名校验缺失等问题。这类测试一般在实验室环境做不在现场做。我画过不少次用例矩阵图但这里不用图表也能说清楚横轴是五层测试对象纵轴是六种测试方法交叉点就是一个用例候选位置。比如“通信协议层 × 模糊测试”就是“Modbus TCP畸形报文测试”而“现场设备层 × 基线核查”就是“PLC未授权访问核查”。这个矩阵思路最大的价值是帮你发现盲区——如果某个交叉点一个用例都没有那大概率是你漏掉了一类风险。3. 典型测试用例的实操设计3.1 Modbus TCP协议安全测试用例工控测试的必修课Modbus TCP至今仍是国内多数工控现场最常见的工业协议之一。它设计于上世纪七十年代末几乎没有任何安全机制所以围绕它的测试用例也是最基础、最典型的。我在这里给出几条实测过、可复现的用例每一条都可以直接抄进你的用例库里。用例编号ICS-TC-MB-01用例名称Modbus TCP功能码枚举与非法功能码探测测试层级通信协议层风险等级中前置条件已获取目标PLC的IP地址已获得客户测试授权控制设备处于手动模式或已确认安全操作步骤1. 使用Nmap脚本或Modbus专用工具对目标地址进行功能码扫描2. 依次发送01H、02H、03H、04H、05H、06H、0FH、10H等功能码请求3. 记录设备对每个功能码的响应4. 对未支持的功能码构造异常长度请求观察设备响应预期结果设备对未支持的功能码返回异常响应码如01H Illegal Function对支持的功能码能返回正常数据不应出现设备无响应或崩溃恢复步骤连接的会话超时后会自动断开无需额外恢复操作如设备异常立即断开测试链路并联系现场工程师重启设备这个用例的关键点是判断设备是否对非法功能码做了过滤。老款PLC常常对任何功能码都给响应这意味着攻击者可以轻松枚举出所有可操作的数据区。测试时注意功能码扫描速度一定要慢我一般设置在每两秒一个请求太快了某些老设备的CPU会吃不消。用例编号ICS-TC-MB-02用例名称Modbus TCP未授权写寄存器测试测试层级通信协议层风险等级高前置条件必须在客户明确允许的测试窗口内执行目标寄存器已读取原始值并记录工艺工程师已在场确认写操作不会触发危险动作操作步骤1. 通过读保持寄存器03H读取目标寄存器当前值2. 构造06H写单个寄存器报文将值修改为在允许范围内的临时值3. 再构造03H读回确认写入成功4. 执行恢复步骤将寄存器值改回原始值5. 再次读回确认恢复完成预期结果设备允许无认证写入并返回确认响应说明存在未授权写入风险这本身就是安全发现写入不影响设备正常运行恢复步骤立即将寄存器值写回原始值并以第三次读回结果作为恢复确认证据记录在测试报告中这里必须重点强调写寄存器测试是风险最高的操作之一在没有和客户沟通清楚前永远不要执行。我实际操作时会先做一次只读测试03H读保持寄存器确认设备和数据区都正常以后再通过邮件和现场负责人双重确认才执行写操作。测试结束后的值恢复不只是把数改回去还要确认模拟量、开关量的实际状态没有改变否则改了外观值但设备内部状态已经变化一样会出问题。另外补一个实用技巧Modbus的从站地址扫描。很多现场工程师偷懒PLC配置时直接用默认Unit ID比如0、1、255之类的常见值。测试时可以用广播手段逐个探测从站地址很快就能把整条链路上的设备台账摸出来。这看起来像是信息收集工作但如果你把发现的设备清单和客户提供的资产清单做比对往往能发现“影子设备”——一些无人申报的历史遗留PLC。这部分在工控测试里价值极高因为影子设备正是供应链攻击和内网横向移动最喜欢的目标。3.2 OPC UA与OPC DA测试用例认证与加密的验尸报告OPC协议在工业上位机层面用得极广老一代的OPC DA基于微软COM/DCOM技术本身就是出了名的难防护新一代的OPC UA虽说支持证书和加密但实际配置情况常常很糟。我见过太多项目OPC UA服务器开着安全模式但实际用的是匿名登录证书验证形同虚设。用例编号ICS-TC-OPC-01用例名称OPC UA匿名登录与证书验证状态核查测试层级主机与应用层风险等级中前置条件已获取OPC UA服务器地址与端口通常4840已获得授权操作步骤1. 使用OPC UA客户端工具连接目标服务器2. 尝试匿名登录不提供用户名密码3. 记录服务器返回的SecurityPolicy和证书状态4. 尝试与服务器建立非加密会话5. 尝试使用无效证书或过期证书建立会话观察服务器是否拒绝预期结果若服务器接受匿名登录、允许非加密会话或接受无效证书均为安全缺陷记录在报告中恢复步骤测试会话结束后断开连接即可不影响服务器运行OPC DA的测试更麻烦。由于DCOM的端口动态分配特性单纯从外部扫描很难摸清全部开放端口。正确做法是在工程师站上安装专用的DCOM扫描工具从主机层发起查询枚举服务器上的OPC DA服务列表。这种测试我强烈建议只做枚举不做利用因为DCOM的稳定性本来就差任何异常操作都可能导致进程崩溃进而影响到生产监控画面。还有个被严重忽视的点OPC UA的证书生命周期管理。测试时你会经常发现服务器的证书已经过期但客户端依然能正常连上。这说明客户端根本没有做证书校验或者校验逻辑是默认放行。这种情况比“忘了配证书”更隐蔽因为系统表面一切正常一旦遇到真正的恶意节点冒充服务器数据就会被接管。所以这个用例的测试结果要单列一个风险等级不能和普通的配置问题混在一起。3.3 上位机与HMI测试用例从桌面到现场的距离上位机和HMI是攻击者最常盯的目标。原因很简单它们能控制整个产线而操作系统却普遍停留在老版本。我整理上位机测试用例时不喜欢一上来就跑漏洞扫描器而是优先做账号与口令审计。具体来说这类用例包含几项核心检查本地管理员账户是否禁用了默认账号是否有guest账户且未设置口令RDP远程桌面是否开放并暴露在生产网是否存在绕过UAC的潜在配置病毒库更新时间是否超过三个月。把这些基线核查项做成一个检查表比你扫描出几个CVE更有现实意义。因为工控上位机的漏洞你基本没有补丁可打——不少厂商规定工程师站不能擅自安装补丁会改变系统行为。所以能在基线层面堵住的口子必须先堵上这是用例设计的基本逻辑。HMI方面有一个有意思的现象很多HMI运行在带触摸屏的工业平板上操作系统登录界面被砍掉直接就进画面。测试这类设备时我一般会检查它的工程文件是否加密、组态软件是否允许未授权下载、HMI是否开启FTP或U盘自动运行功能。其中“工程文件明文存储”是我在所有HMI测试报告里出现频率最高的发现之一。很多组态软件导出的工程文件用户名、密码、IP地址、PLC寄存器映射表全都在XML文件里明文躺着拷走一个工程文件等于拿到了产线的完整控制权。用例编号ICS-TC-HMI-01用例名称HMI工程文件泄露敏感信息核查测试层级主机与应用层风险等级高前置条件已授权获取一台HMI设备或备份的工程文件操作步骤1. 定位HMI的工程存储路径2. 导出工程文件或连接组态软件下载工程3. 用文本工具检索关键字“password”“user”“IP”“PLC”4. 记录检索到的明文信息及对应资产预期结果若检索到明文口令或完整组态信息则记录为高风险发现并评估信息可造成的控制链路影响恢复步骤测试过程中不修改任何工程文件无需恢复如需下载工程完成后确认组态软件连接状态正常3.4 边界防护设备测试用例看看你的安全区牢不牢工业防火墙和工业安全网关是现在工控安全建设的标配但等级保护测评和实网攻防演练里边界设备被“一穿而过”的情况仍然屡见不鲜。原因多半不是设备本身防护能力不够而是策略配置不合理或者被管理人员长期忽略。边界防护测试用例我一般分三条主线展开第一条是策略有效性验证。从DMZ区或办公网发起对生产网的跨区访问测试选取几个常见端口如445、3389、502、4840尝试连接确认工业防火墙是否拒绝了所有非白名单流量。这里有个细节要提醒很多工业防火墙默认是允许模式放行一切靠黑名单阻断但安全设计应该默认是拒绝模式。测试时你要主动检查设备的默认策略而不是只看当下配置。第二条是策略冗余与过度授权审计。把防火墙策略导出来一条一条核对源IP、目的IP和端口找出“ALL to ANY”这类泛化策略。我在项目中碰到过最典型的场景某企业为了调试方便在防火墙里临时加了一条办公网到PLC网段的放行策略调试完成后忘了删除一放就是两年。这类用例虽然测起来不刺激但实际风险甚至比一个0day漏洞还高。第三条是设备自身安全状态核查。工业防火墙的管理接口是否暴露在生产网默认口令是否已修改固件版本是否更新日志是否接入集中审计平台。这些项目看起来简单但恰恰是安全检测里最有性价比的内容。因为边界设备自身一旦被攻破整个安全区的划分就等于是画在纸上的。我见过的情况是集成商交付后把防火墙管理密码贴在设备外壳上这种“最基础问题的防线缺口”真的要靠用例清单一条条盯出来。4. 测试执行流程与风险控制4.1 从基线采集到报告输出的完整流程用例设计得再好执行环节出了问题照样白搭。我通常把工控安全测试的执行流程拆成六个阶段每个阶段都有明确的进出条件和交付物阶段一资产梳理与现场调研。这一步不能省而且最好到现场跑一圈。跟客户的仪表工程师、自动化工程师分别聊聊搞清楚三条链工艺链路物料怎么流、控制链路数据怎么采、网络链路报文怎么走。交付物是一张资产清单和网络拓扑图。阶段二基线采集。把各设备当前的端口状态、服务列表、账号配置、关键参数全部导出存档。这一步的核心价值有两个一是作为测试后对比的基准二是万一测试发生意外你能第一时间恢复到初始状态。基线数据要双人复核存储到测试工作目录中并做哈希校验防止中途被篡改。阶段三非侵入式核查。执行所有基线核查类和配置审计类用例。这些用例不会对生产造成影响可以相对放心的执行但依然要注意扫描频率和并发量收着点来。阶段四低风险验证。执行漏洞验证和部分协议只读测试。此阶段开始产生真实攻击流量需要提前向客户提交详细的测试时间和目标清单并请现场人员在值班室盯屏。阶段五高风险测试如需。执行写操作、模糊测试等高危用例。这类用例要么安排在停产检修窗口要么在等比例的测试床环境复现。没有测试床条件的宁可放弃这部分用例也不要在生产环境冒险。阶段六结果汇总与报告输出。把用例执行情况、测试证据、风险等级、修复建议全部汇总。证据保留原始报文截图、工具输出日志和时间戳确保可追溯。4.2 生产环境操作的黄金法则在工控现场摸爬滚打这些年我总结了四条黄金法则每次测试前都会默念一遍任何操作前先保存基线。开测前把涉及设备的关键寄存器表、配置文件、运行状态全部导出备份。这条法则救过我一次——有次测试不小心触发了一个老PLC的故障自锁现场设备停了幸好基线里存了全部参数工艺工程师照着备份五分钟内把系统恢复到了原状。单一变量控制。测试过程中任何时刻只改动一个变量。要测功能码就只测功能码要测寄存器写入就只测一个寄存器。如果出了一堆问题却不知道是哪一步引起的那是最糟糕的测试结果。永远保留业务联系人的直线电话。不要通过客服工单系统不要通过微信群里人如果现场出现异常你要能在十秒内联系上那个能拍板停机和恢复的人。这条听起来很基础但我见过现场测试人员和厂方沟通不畅最后机器停了半小时才找到负责人的真实案例。测试前明确回滚方案。和客户工程师确认如果生产出现异常谁负责通知、谁负责处置、恢复的第一动作是什么。这个回滚方案不写在用例里但要作为执行阶段的第一页签署确认文件。4.3 常见问题与排查技巧实录工控测试里最常见的问题我列一个简明的速查表方便大家现场排查问题现象可能原因处置办法设备在扫描后无响应扫描器发包速率过高设备CPU被占满立即停止扫描断开测试链路等待设备自恢复若10分钟未恢复联系现场工程师重启设备Nmap扫不出任何开放端口该设备走专用协议如Profinet ETF、S7commTCP常规端口扫描无效改用协议专用探测工具或抓包分析设备主动上报的流量Modbus功能码扫描大量超时设备响应带宽受限或防扫描机制被触发降低请求频率至少间隔2秒先测单个设备不要并发OPC UA客户端连不上服务器服务端证书不受信任或安全策略不匹配检查客户端证书配置先尝试匿名和安全模式None连接确认基础连通性防火墙策略测试失败未被拦截策略可能配置成默认放行查看防火墙全局默认策略而不是只查当前规则列表测试后实际值与基线不符测试过程中某步操作触发了参数变更优先查看变更前后的操作日志回滚到基线值并记录为流程问题这里想多说一个我在项目里遇到的典型翻车现场。有一回在某个水处理厂做测试我按常规流程用工业协议扫描器对该厂的PLC做了个快速资产识别。结果扫描器刚跑完一个C类网段旁边机柜里的一台老旧PLC就“死机”了运行灯全灭现场值班人员的监控画面瞬间一片红。后来查明原因那台PLC固件版本太老对异常长度的请求报文处理存在缺陷收到畸形数据包后直接触发了看门狗复位。那次之后我养成了一个习惯涉及老设备的测试全部降速到极低频率并且先做单包试探。宁可多花半小时也不拿生产安全冒险。5. 工具清单与选型建议5.1 工控安全测试常用工具矩阵做工控安全测试工具选型直接影响效率和安全性。我把常用的工具按用途整理成一张矩阵供大家参考用途工具/方式使用要点风险等级网络发现与拓扑测绘Nmap配合工控协议脚本扫描限速禁用UDP全端口扫描低工业协议分析Wireshark配合专用解析插件用镜像端口抓包避免在线阻断低Modbus测试ModbusPoll、Modscan、自写Python脚本ModbusPoll做常规读写自写脚本做畸形报文中高工控漏洞扫描专用工业漏洞扫描器如基于插件库的OT扫描工具优先选择厂商认证过的工具降低误报和故障率中OPC UA测试UA Expert、UaPython等官方客户端库用客户端库可灵活构造会话比图形工具有更细的控制低固件分析binwalk、firmware-mod-kit、JTAG调试器等实验室环境使用注意固件版本匹配低实验室模糊测试部分开源工控协议Fuzz工具或自建测试框架仅限测试床使用生产环境禁止高这里的核心选型逻辑是能用抓包观察解决的问题就不要用扫描器解决能用低风险工具解决的就不要用高风险工具解决。信息收集阶段的工具有很多但工控环境下“少即是好”。我还想特别说一下脚本能力熟练工和入门选手在工控测试上差距最大的地方往往不是用现成工具多熟练而是能不能快速用Python写一个针对性的测试脚本。比如Modbus的畸形报文测试现成工具很少能精确控制报文里的每一段字段结构自己写脚本反而最可靠。Python的Modbus库很多网上也有大量参考代码稍微改改就能作为专用用例工具。5.2 我自己在工具使用上的取舍具体到工具使用还有几个细节想分享。Nmap做工控环境扫描时建议打开-T2或-T1的慢速模式并搭配--host-timeout参数。扫描前先向客户明确要扫描的IP清单不要顺带扫其他网段——工控网络里的设备种类繁杂很多你不知道的资产可能在扫描时暴露但暴露的代价可能是一台旧设备崩溃。使用Wireshark分析工业协议时除了常规的协议解析我强烈建议开启“流跟随”功能把一次完整的Modbus会话或多轮S7通信的交互过程完整看一遍。很多时候你不看完整会话就发现不了“设备主动上报大量数据到某个未知IP”这种异常行为——这在工控环境里往往是潜伏威胁的早期信号。漏洞扫描器在工控环境的使用要讲究时机。正常的IT漏洞扫描器发送的探测报文对工业设备来说常常过于激进。我自己的实践经验是工控漏洞扫描只在以下三种情况之一进行——获得厂商明确支持的机型、在停产检修窗口执行、在测试床环境执行。其余情况一律以基线核查和人工验证代替。6. 最后分享一点实话工控安全测试这件事情表面上是技术活本质上考验的是对业务的理解和对风险的敬畏。我做过十几个工控安全项目后发现真正拉开测试水平差距的不是你会不会用某款工具也不是你掌握了多少条用例而是你能不能在设计用例时想清楚“这一步操作在真实生产环境里意味着什么”。给正准备搭自己用例库的朋友两个建议第一用例库不要贪大求全先把你最常遇到的PLC品牌、上位机系统和工业协议各建一组高价值用例实打实跑通一个项目后再扩展第二每条用例都要写清楚“为什么这么测”这个注解将来回看时价值远大于用例本身。我在最初整理用例时也犯过错只顾着堆数量和覆盖范围结果项目执行时大部分高危用例根本不敢在生产环境里跑最后报告的深度反而很浅。后来我调整思路宁可用例数量少一些也要确保每条用例在前置条件、影响评估和恢复方案上都经得起现场的检验。工控安全在国内还在快速成长阶段测试方法也在慢慢成熟。希望这篇总结能帮你在面对工厂里那些沉默的PLC和HMI时多一分从容少一分踩坑。如果你在实际测试中有自己的心得体会欢迎一起交流碰撞这行里互相学习总能走得更快。