“产线又停了PLC被人下了停机指令现场一片混乱领导盯着你等结果……”这是搞工控或者工业网络运维的朋友最怕遇到的场景。排查半天最后往往是靠抓包软件从留存的数据里找到那只“幕后黑手”。作为在工业网络和控制系统运维这个圈子里摸爬滚打多年的老工程师我可以说Wireshark加S7comm协议分析是每个工控安全排查人员都要熟练掌握的技能组合。这篇内容不聊理论不扯远景就讲讲我在实际排查S7comm安全隐患时怎么抓包、怎么过滤、怎么在一堆白色噪声里精准定位到那些不怀好意的流量以及踩过的坑和总结出的经验。不管你是刚接触工控网络的新人还是需要处理现场告警的运维老手这篇文章都值得你花几分钟认真看看。1. 排查前的底层认知为什么S7comm协议容易出问题1.1 工控系统里的“通用语言”藏着的隐患工业控制系统里PLC可编程逻辑控制器是产线的核心控制单元而上位机监控组态软件、触摸屏、其他PLC之间要对话靠的就是各种通信协议。在以西门子S7系列PLC为核心的控制系统里S7comm协议几乎就是“母语”它承载了大量生产设备的控制指令、状态采集和参数读写。问题在于这个“母语”诞生于几十年前工业以太网还不怎么考虑安全性的时代。它本质上是一个明文协议既要传输生产数据DB块、M区、I/O状态也具备远程读写、启停PLC这类“高权限操作”的能力。更要命的是S7comm在设计之初就没有考虑任何认证机制——也就是说只要谁能物理或者逻辑上接触这个网络谁就可以发送指令给PLCPLC基本不会验证“你凭什么这么干”。这类协议在封闭的工业环境下运行效率很高但一旦网络边界失守、或者内部混入了不怀好意的终端S7comm就会变成攻击者手里最顺手的刀。我们做排查首先就要建立这个认知S7comm流量里不止有数据更藏着“控制权”。1.2 明文、无认证、权限大三层风险叠加S7comm的安全隐患我每次做安全评估都会给客户讲基本可以归纳为三点第一明文传输。使用Wireshark抓包只要能抓到报文就能直接看到功能码、读写地址、数据内容。操作员给PLC下发什么参数、修改了什么DB块值全在包里面清清楚楚。对于攻击者来说这不叫破解这叫“直接阅读”。第二缺乏身份认证。S7comm连接建立后通信双方几乎不校验对方身份。这就意味着攻击者不需要掌握什么高深的密码学知识只需把自己的设备IP地址配置成上位机的IP然后向PLC发起连接PLC是不会拒绝的。在网络里“伪装成自己人”成本极低。第三功能码权限过大。S7comm协议里有功能码可以读取和写入数据也还有可以直接控制PLC运行状态启动/停止的命令。个别不怀好意的指令一旦被外部触发轻则影响单台设备重则整条产线停机甚至损坏设备。而很多老工控网络中PLC的CPU模块根本没有设置访问保护等级或者保护形同虚设谁都能用编程软件连上去操作。你可以把S7comm想象成一栋办公大楼的中央门禁系统。它原本设计的功能是让员工刷卡进出效率很高。但问题在于这个门禁系统既没有监控摄像头明文可读也不验证刷卡人是不是真的在员工名册里无认证而且任何一张卡都能打开机房重地权限过大。你想这样的门禁系统怎么让人安心1.3 锁定排查目标既要看“活”也要防“鬼”明白了隐患我们排查的目标就非常清晰了。我们抓包分析S7comm核心任务不外乎两个层面一是查“活”排查网络里是否存在因错误配置、软件故障导致的异常S7通信行为比如某个上位机疯狂写DB块导致控制器总线负载升高影响正常生产扫描周期。二是防“鬼”排查是否存在未授权终端接入控制网探测PLC节点、非法读写数据、仿冒上位机下发控制指令的情况。通常后者是我们工作中的重中之重因为涉及到直接的生产安全事故。后面所有抓包分析技巧都是围绕“识别正常”与“揪出异常”展开的。正常通信我们心里要有底异常通信则要一帧一帧地盯。2. 抓包准备与正确姿势工控现场不是实验室很多朋友在实验室里用Wireshark抓包很熟练一到工控现场就抓瞎。这是很正常的因为工控网络环境比办公网络复杂得多对抓包的方法、位置和工具都有特殊的要求。2.1 抓包位置选不好等于白干工控网络大多是环形或者星型拓扑交换机、网关、PLC之间通过工业以太网协议比如Profinet、Modbus TCP、S7comm进行通信。我们抓包一般有三个位置可以选各有优劣第一选择是核心交换机的镜像端口。这是最推荐的方式。在交换机上配置端口镜像Port Mirror也就是常见所说的SPAN端口把连接PLC和上位机的关键端口流量复制一份到我们接Wireshark的排查笔记本端口。这样不会影响原有通信数据也最全。第二选择是部署网络分流器TAP。这个方式需要在链路里物理插入一个TAP设备它会把链路流量复制一份出来。好处是物理层隔离性能影响小坏处是必须割接链路现场往往不具备停机条件所以实际用得比镜像少一些。第三选择是直接串接在链路里。我极不建议在排查S7comm安全隐患时这么干。原因很简单如果你用一个普通笔记本串接在PLC与交换机之间笔记本网卡的转发性能和处理速度直接决定这条链路通不通。笔记本一旦死机或者网卡丢包直接影响PLC通信这在连续生产的现场是不可接受的。另外要注意Wireshark抓包时网卡必须开启混杂模式。不然网卡只会收发给本机的包其他终端的S7流量你根本看不到。不过工控上位机多是直连如果用笔记本连到上位机同网段的交换机上做镜像一般默认就是能收到所有流量但养成检查混杂模式开启的习惯总是好的。2.2 Wireshark版本与插件直接用新版省心省事Wireshark对S7comm协议的支持已经非常完善了不仅仅是基础的S7comm解析连更高级的S7comm-FFS比如用于S7-1200/1500的安全通信扩展也能解析到字段级别。所以我强烈建议直接使用当前最新的稳定版Wireshark不要纠结于老版本。老版本最大的痛点是解析器不完整。同样的报文新版Wireshark能直接展开到功能码、参数块、数据块每一层的含义老版本往往只能解析到TCP层S7comm载荷全是“不透明的数据”看起来像乱码排查效率极低。另外如果在实际工作中发现某些厂家的私有扩展字段解析不正确可以考虑给Wireshark添加自定义的S7comm解析插件Lua脚本或C语言插件。虽然我很少这么干但对那些使用非标准功能码的特殊设备插件是唯一的出路。设置方面我每次开始抓包前都会做两个动作一是确认“自动滚动”关闭避免抓包过程中界面一直在跳影响定位二是设置好时间显示格式把默认的“相对时间”改成“UTC或本地时间”这在我们排查时比对现场操作记录非常重要。时间戳对不上后面分析会非常被动。2.3 建立正常基线没有参照物异常都是空谈进入现场抓包后第一步不是找异常而是画“正常”。需要在系统稳定运行、无报警、无操作的时间窗口内抓取至少30分钟到1小时的数据作为基线样本。这个步骤很多人会忽略但踩过坑的都懂没有基线数据看到大量S7写请求时你根本分不清这是正常的数据采集机制在周期性刷新还是攻击者在下发恶意覆盖指令。有了基线你就知道网络里正常运行时的流量特征是什么哪些IP和哪些IP经常通信大概多少个包每秒常见的功能码分布是什么样。基线数据也用来做流量建模。S7comm正常流量大多是周期性的、规律性的读请求数据块长度相对固定会话持续时间也较稳定。一旦排查时发现请求频率陡增、通讯地址变化、出现陌生IP或者写请求变多你就可以非常迅速地把它和基线对比识别出“新面孔”和“异常行为”。3. S7comm报文核心语法你得能看懂“话”里藏着的意思Wireshark虽然能解析S7comm但如果你自己不懂报文结构出了包也只能干瞪眼。我建议每个排查人员都至少要熟悉S7comm的分层结构和几个关键功能码。3.1 先拆开三层外壳才看得到S7comm真身在以太网里传输的S7comm报文并不是裸奔的。它的结构像俄罗斯套娃最外层是以太网帧Ethernet II接着是IP头和TCP头TCP目的端口号固定是102。这里展开说一下102端口是S7comm的“门牌号”看到目标端口102基本就可以锁定是S7comm或S7comm-FFS协议了。TCP层往上是TPKT层也叫RFC1006协议。它是个传输层封装作用是把大量S7数据分段封装成几十KB以内的传输单元方便承载在TCP流上。再往上是COTP层ISO 8073 Connection-Oriented Transport Protocol面向连接的传输协议。COTP负责建立、维护和释放传输连接这里面有个关键的“TPDU类型”字段比如0x0E是连接请求CR0x0F是连接确认CC0x0D是数据确认DT。S7comm真正的内容就藏在COTP数据段里面。在Wireshark里你把S7comm报文展开时从上到下依次是帧、IP、TCP、TPKT、COTP、S7comm。看起来层级多实际上只要掌握了“TCP 102端口 TPKT长度 COTP数据类型”这组特征就能快速把S7comm从其他流量里剥出来。下面给出最常用的几个过滤表达式建议直接存进收藏夹# 只看S7comm协议 s7comm # 看S7 comm以及其扩展协议部分S7-1200/1500设备 s7comm || s7comm-ffs # 按TCP端口只看102口流量 tcp.port 102 # 看S7comm写操作 s7comm.param.func 0x05 # 看S7comm读操作 s7comm.param.func 0x04 # 看COTP连接建立过程 cotp.tpdu_type 0x0e || cotp.tpdu_type 0x0f3.2 读操作和写操作一眼看出“目的”S7comm报文真正有用的东西在功能码Function字段。核心的功能码就这几个我列个表说明功能码十六进制含义备注0x04读请求上位机读取PLC的DB块、M区、I/O区数据0x05写请求上位机向PLC写入数据这是需要重点盯防的操作0x1A请求含多种子功能常用于S7-1200/1500里面也包含读写操作0xF0建立会话请求建立S7通信会话的第一步0xF2读诊断信息读取PLC诊断缓冲区常用于故障排查0x00CPU服务包括启动、停止等CPU操作比如0x28表示停止以最经典的0x04和0x05为例。一个读请求报文展开后你会看到参数部分有“项数”Item Count、“数据长度”以及请求的具体区域比如DB区、M区、I/O区、起始地址和字节长度。一个写请求报文除了上面的基本信息还会多出具体的“数据”字段这里就是要写到PLC里的值。排查安全隐患的时候看到0x04读请求可以放松几分最多是有人在偷偷“窥视”生产数据看到0x05写请求就要打起十二分精神了。尤其是一个本来只应该做监控的IP突然频繁发送0x05写请求那几乎可以断定网络里出现了越权操作或者控制指令仿冒。3.3 追踪流一个动作拉通整个“对话”在实际排查中我们经常需要查看一次完整交互过程比如从握手到读写到断开。Wireshark里“右键某个S7comm报文选择追踪TCP流”是一个高频操作。这个方法能把同一TCP连接里的所有载荷按时间顺序展示出来。我在排查时常用它来实现两件事一是看通信是否规范。正常上位机软件和PLC通信顺序一定是TCP三次握手然后是COTP的连接请求和连接确认再是S7comm会话建立0xF0最后才是正常的读写循环。如果追踪流发现直接跳过了某些握手或者仅有一两个报文就结束了大概率是某种非正常的通信工具比如扫描脚本在探测。二是看写操作的实际内容。通过TCP流窗口我可以同时看到多个写请求之间的逻辑关系比如是否在短时间内对同一个地址连续写了多次不同的值值的变化是否符合工艺逻辑。有一次排查我就通过追踪流发现某上位机每隔几百毫秒就对某个DB地址写一个递增的数值后来查明是组态软件在里面对计数器变量做自增模拟属于配置错误但当时被误当成了外发指令。3.4 常见误判不是所有TCP 102都是S7comm这一节单独拿出来提醒是因为我见过太多人在这里翻车。实际环境中有些旧型号PLC支持的ISO-on-TCP比如ISO 8073协议头也会使用TCP 102端口但它的实际内容不包含标准的S7comm参数块展开后只有“COTP”层而看不到“S7comm”层。还有的厂商设备会借鉴S7comm的报文格式但加入私有扩展字段Wireshark的通用解析器解析不出来显示为“malformed packet”或者一大段未解释的字节流。看到这种情况先不要急着判死刑说“不是S7流量”要核对设备型号和端口号结合现场配置再下结论。我提供一个万能的检查思路在Wireshark上方过滤器中输入tcp.port 102 cotp先把所有走102端口的COTP报文全部列出再逐个点击展开看有没有解析成S7comm。如果大部分包都能正常解析只有极少数解析不出来那就要重点分析了因为很可能是一条手工构造的特殊报文。4. 三类典型安全隐患的排查实战掌握了报文结构和过滤语法下面进入正题怎么揪出网络里潜伏的威胁。我在工控安全排查中碰到最多的就是扫描探测、非法读写和身份仿冒这三类问题。下面我逐个用一个模拟的场景案例来拆解排查思路注意场景和IP地址等都是虚构的仅用于说明方法。4.1 场景一网络里多了个“扫描器”被动探测PLC资产现象某车间运维人员在核心交换机上发现端口流量告警但查看交换机CPU负载正常、产线运行正常没有特别明显的异常。不过安全评估时要求排查是否存在非法扫描行为。排查过程在核心交换机镜像口接入Wireshark抓包30分钟后停止。首先用统计菜单里的“端点”和“会话”看整体概况我习惯先看IPv4端点列表并按照数据包数量排序。正常情况下抓包结果里应该主要是上位机比如192.0.2.10和PLC比如192.0.2.20之间的通信报文数量最多。但如果发现某个陌生IP比如192.0.2.99的包数量虽然不多却和很多IP都有过通讯或者在短时间内发出了大量TCP SYN包这基本就是在进行资产扫描了。我继续用过滤器tcp.flags.syn 1 tcp.flags.ack 0查看所有主动发起的TCP连接请求。如果一个IP对多个PLC的102端口发起了SYN请求而PLC侧迟迟没有建立完整连接正常上位机连接会很快完成三次握手那几乎可以断定是扫描行为。深入分析时选中其中一个探测报文展开它的S7comm层。如果这个SYN包还有配套的S7comm建立会话请求比如0xF0并且后面跟了多个不同的功能码请求就说明这不是普通的“嗅探式扫描”而是有针对性的协议级探测。攻击者可能在枚举PLC型号、固件版本以及支持的S7服务。排查建议确认扫描源IP后立即到接入交换机上查MAC地址和对应物理端口顺藤摸瓜找设备。对于这种扫描行为不用急着抓详细包先通过交换机日志找到物理位置多半就能锁定设备。4.2 场景二非法下发“写DB”指令数据被恶意篡改现象某产线的质量检测系统突然频繁上报数据异常工艺参数在一段时间内出现非规律波动现场查看程序和上位机操作日志都没发现问题。怀疑有外部设备在往PLC里写数据。排查过程这个场景必须抓包并且要抓“实锤”。因为是数据篡改所以我们关注的功能码直接锁定0x05写请求。使用过滤器s7comm.param.func 0x05把这段时间内所有的S7写请求全部拉出来。在结果列表里我重点关注三个要素源IP、目的PLC地址、以及写操作的目标区域和数据值。正常的上位机写DB块目标地址和值的变化应该与工艺操作一一对应比如操作员在组态界面点击“启动阀门”写操作应该指向该阀门的控制DB。如果看到某个固定源IP向PLC的某个DB地址频繁写入与现场操作无关且变化诡异的数据那就要对这些数据展开分析。我还见过一种更隐蔽的手法攻击者不是高频写而是每隔一段时间可能是1小时写一次每次都把某个DB地址里的值改成一个固定数字导致所有读取该DB块的设备都显示异常。这种情况靠肉眼看非常容易漏我一般会用Wireshark的“IO Graphs”工具把协议过滤器设为s7comm.param.func 0x05按时间轴画出写请求的频率分布。如果发现规律性尖峰就说明写操作是定时任务触发的。排查建议一旦确认存在非法的0x05写请求不要直接断网产线还等着用而是先用Wireshark导出该IP的所有会话并备份。然后追踪TCP流把写请求的完整上下文整理出来作为后续追查和加固的证据。这也是最能说服管理层的“实锤”。4.3 场景三仿冒上位机“建立会话”PLC被遥控启停现象某车间反应釜控制PLC在深夜发生两次不明原因停机现场无人操作上位机历史记录没有任何报警。警惕性高的工程师马上意识到可能有人在远程控制PLC停机。排查过程启停PLC在S7协议里不是简单的0x05写操作通常涉及更高级的CPU服务比如0x00功能码中的0x28服务或者特殊报文。这类命令大多会经过会话建立0xF0因此排查的第一过滤器是s7comm || s7comm-ffs然后配合时间定位到停机前后几分钟。我发现停机前几十秒有个源IP地址为192.0.2.50的设备向PLC192.0.2.20发起了S7会话请求之后紧跟了一条CPU服务报文。但这个192.0.2.50并不在车间上位机清单里现场正常上位机是192.0.2.10到192.0.2.15说明是一个未登记的设备。这条CPU服务报文展开后我在参数层看到了明确的PLC停止服务类型。这种直接面向PLC运行状态的命令在正常生产中几乎不可能出现除非人为操作或者程序触发。由于时间点与停机时间完全吻合基本可以确定这就是导致停机的“元凶”。排查建议仿冒上位机是S7comm最危险的攻击方式。遇到这种情况除了立即阻断该IP与PLC之间的通信还要在交换机上查找该IP对应端口并排查是否有无线接入点把工控网和办公网打通了。很多时候仿冒设备就是通过无线桥接接入控制网的。4.4 一张表格总结三类威胁的Wireshark特征我在实际工作中把这三类异常的特征浓缩成了一张速查表排查时按图索骥效率提升很多威胁类型主要功能码或报文特征Wireshark关键视图快速判断方法资产管理扫描大量无ACK的SYN包、多个目标IP的102端口请求端点、IPv4会话统计陌生IP的SYN包数量对PLC端口发起大量请求多为扫描非法写数据0x05、0x1A写请求地址和值规律性变化IO Graphs、TCP流对比基线寻找超出工艺逻辑的写请求可用IO Graphs看时间尖峰仿冒通信/PLC启停0xF0建立会话后紧跟CPU服务指令TCP流、协议层级核对源IP是否在资产清单内确认连接建立后的操作类型5. 常见问题与排查技巧实录这些坑我都帮你踩过了下面这部分是很多朋友拿着Wireshark到现场却无法下手的“疑难杂症”以及我这么多年积累的处理方法。5.1 抓了半天Wireshark里根本没有s7comm协议这是新手最容易遇到的问题我几乎每周都会收到类似的咨询。先别急按顺序排查首先确认你抓包的位置。如果笔记本接的端口和PLC不在同一个广播域或者没有配置镜像端口你根本收不到PLC和上位机的流量。用过滤器eth.addr 你的网卡MAC看一眼有没有任何数据包进来没有就是接入问题。其次确认设备是否确实走S7comm协议。比如S7-1200/1500在较新的固件版本中如果组态里勾选了“安全通信”那么你看到的可能是S7comm-FFS协议在Wireshark里显示为s7comm-ffs而不是s7comm。此时要把过滤条件改成s7comm || s7comm-ffs。S7comm-FFS报文也走102端口但载荷增加了TLS握手和加密内容在Wireshark里展开已经看不到明文数据块只能看到协议头。再次确认网卡是否支持抓包时的混杂模式。在Wireshark的“捕获选项”里网卡接口旁边有一个混杂模式复选框如果取消了只能收到本机相关流量S7报文全被网卡过滤掉了。最后别忘了过滤栏也要设置正确。Wireshark在抓到包后默认只显示所有流量但当数据集庞大时先用tcp.port 102过滤一遍可以有效缩小范围。5.2 抓到的S7报文时间戳对不上乱成一锅粥S7comm排查很依赖时间线。我遇到过设备报警时间显示在14:30:00但抓包里对应的写请求时间却是14:32:00。一查发现PLC系统时间、上位机时间和抓包笔记本时间三个时间源不一致偏差达到两分钟。所以日常排查前一定要先做三件事一是同步抓包笔记本时间网络时间协议校准或者手动校准到和上位机一致二是记录PLC和上位机的系统时间可用读取诊断信息功能码来获取PLC时间三是抓包时打开Wireshark的“视图 - 时间显示格式 - 绝对日期与时间”确保每个报文都有完整的年月日时分秒信息。这样即使各系统时间有偏差记录的时候也能通过相对偏移来对齐。5.3 只知道“有攻击”但过滤了s7comm还是找不到问题这种情况多半是因为异常流量不是标准的S7comm结构。比如攻击者利用S7协议栈的漏洞发送畸形报文Wireshark显示为“malformed packet”或者攻击者直接把S7报文封装在UDP里非标准用法但也见过亦或是用的是其他工业协议Modbus TCP、Profinet IO等。如果过滤s7comm后什么异常都没有建议先将过滤条件扩大回ip.addr PLC的IP看看所有与PLC直接相关的通信。如果发现来自某个IP的非TCP-102端口流量特别多再展开看具体协议。排查不能一根筋锁死在S7comm上工控网络里很多恶意流量都是伪装成其他协议的。5.4 加固建议排查完才发现安全薄弱点远不止S7每次排查完总有人问我“要不要装个防火墙或者入侵检测设备”。我的建议是硬件先放一放先把S7comm最容易出问题的几个点堵上第一如果PLC CPU支持访问保护一定设置并启用。这能挡掉大量未授权的功能码操作。很多设备出厂默认是“无保护”状态等于现代楼房把所有房间的钥匙都挂在门口了。第二利用交换机ACL或者防火墙规则限制只允许已知上位机IP访问PLC的102端口其他IP一概拒绝。这能从根源上防住“仿冒上位机”这类攻击。第三区分控制网和办公网的VLAN严禁跨网段直接访问。大量攻击是从办公网侧突破后横向渗透到控制网的。第四抓包不能只是出了事才做建议做周期性的安全抽查抓几个小时的流量人工或脚本比对基线及时发现新增会话和异常写操作。5.5 一个实用技巧用导出对象批量提取S7载荷有时候排查完需要出报告需要把可疑报文的原始载荷导出来进行分析。Wireshark有一个不太被工控运维注意的功能——“文件 - 导出分组解析结果 - 为纯文本文件”可以把过滤后的报文按文本格式导出保留每一层的关键信息。我常用它把某个IP的S7写请求全部导出再自己写个小脚本统计目标地址分布快速梳理篡改规律。如果需要把单个报文的原始字节流提出来可以右键报文选择“复制 - 作为十六进制流”。这个方法在做报文复现和编写检测规则时尤其好用。结尾的几句大实话干了这么多年工控网络排查我的体会是大多数S7comm安全隐患都是因为历史遗留的“信任模式”导致的——网络里默认所有设备是可信的协议本身没有防护加上现场维护往往没有完善的资产台账和访问控制。抓包分析是发现问题的重要手段但最终还是要落到管理制度的完善和网络架构的加固上。最后分享一个我个人一直坚持的小习惯排查完任何一次S7comm安全问题我都会把抓到的异常报文样本、过滤规则和排查结论整理成一个文本档案保存。下次再遇到类似告警直接套用旧规则和旧方法定位速度快得不是一点半点。这条经验送给所有愿意折腾Wireshark的工控人。
