简介这是一套面向工控安全研究、网络防御测试和工业系统运维场景的协议流量数据集覆盖西门子S7、Modbus等常见工控协议的真实通信过程能有效缓解工控协议分析中公开流量样本稀缺的问题对深入理解工控网络通信具有重要意义。压缩包共255个文件其中251个pcap抓包文件为主要内容另配有json与md说明文档整体大小68.92MB适合开展协议逆向解析、通信基线与异常行为对比、入侵检测规则开发等方向的研究。已有118人学习浏览。由于多数工控协议在设计时缺乏安全机制这批来自不同环境与测试场景的流量数据有助于分析控制指令、状态读取、寄存器读写等报文字段并能观察正常通信与攻击探测之间的差异从而帮助定位协议脆弱点、评估安全防护策略。无论是编写检测脚本还是判断工业网络安全隐患这些抓包文件都能提供扎实的一手分析素材与验证样本支持研究人员和运维人员快速上手。 干工控这行或者搞OT安全的人迟早都会遇到一个场景现场工程师扔过来一个几十MB的pcap文件说“系统异常了你帮我看看这流量里到底发生了什么”。这时候你手里的工具还是那套抓包分析的老伙计但面对的协议已经不是HTTP、MySQL这些互联网协议而是Modbus TCP、S7comm、DNP3、EtherNet/IP这类工控协议。工控协议流量分析这件事难点不在于会不会用Wireshark而在于懂不懂协议背后的控制逻辑——一台PLC为什么反复读同一个寄存器某条读写指令是不是在合法操作这些从通用网络视角看只是“流量”放到工控场景里却可能是事故的起点。这篇内容比较适合工控安全工程师、工业网络运维人员以及刚接触工控流量分析的安全研究员。我不会只讲过滤语法而是从一份实际pcap文件入手把工控协议流量的整体分析思路、报文字段解读、异常识别和时间线取证串起来最后附上我自己踩过的一些坑。1. 工控协议流量分析到底在分析什么1.1 工控协议和传统IT协议的区别先明确一个基础问题工控协议和Web协议、数据库协议有什么本质区别最核心的一点是工控协议里的每一次请求背后都可能对应一个物理动作。HTTP里一个GET请求失败最多就是页面报错但Modbus TCP里一条写线圈指令如果被恶意执行现场可能就是设备启停、阀门开闭。所以分析工控流量时不能只看“有没有流量”还得看“请求是否合理、参数是否越界、时序是否异常”。工控协议大多是请求-响应模型而且字段设计非常紧凑可读性远不如HTTP。以Modbus TCP为例报文主体就几个字节事务处理标识符、协议标识符、长度、单元标识符、功能码、数据。这种紧凑性带来的问题是流量里一旦出现非预期字段仅靠肉眼很难快速定位必须借助解析工具或脚本把二进制数据映射成可理解的语义。1.2 为什么pcap是工控流量的标准载体pcapPacket Capture文件是目前流量分析领域的事实标准格式Wireshark、TShark、Scapy、tcpdump等工具都原生支持。工控场景选择pcap除了工具生态成熟之外更重要的是它保留了数据链路层的原始信息——MAC地址、VLAN标签、时间戳都在。这在做工业网络资产识别和故障溯源时非常关键一个PLC的IP地址是动态的或者配置错了你还能靠MAC地址锁定具体设备。还需要注意pcap文件本身是有格式约束的不是简单的数据拼凑。我见过不少同事拿十六进制编辑器打开pcap看到一堆字节就懵了。实际上pcap文件由三部分组成全局文件头、逐包数据包头、真正的包数据。全局文件头固定24字节前面4个字节是魔术数字通常为0xa1b2c3d4用来标识字节序再往后是版本号、时区校正、时间戳精度、最大抓包长度和数据链路类型。数据链路类型直接决定了上层怎么解析常见值包括以太网1、Linux cooked capture113等。搞懂这一层后面无论用Wireshark还是写脚本解析心里都有底。1.3 常见工控协议和它们的流量特征实际项目里工控协议大多是“常规协议应用层功能码”的组合。比如Modbus TCP就是把Modbus RTU的协议数据单元封装在TCP报文里S7comm是西门子PLC的通信协议同样跑在TCP 102端口上EtherNet/IP则是基于TCP/UDP 44818端口和UDP 2222端口传输的。DNP3比较特殊它既支持TCP也支持UDP默认端口是20000在电力行业用得特别多。给一张常见工控协议的端口和特征表方便大家拿到pcap文件后第一时间定位协议默认端口传输层典型厂商/场景常见报文特征Modbus TCP502TCPPLC、DCS、RTU协议标识符固定为0x0000长度字段后面是单元标识符和功能码S7comm102TCP西门子报文开头有TLS或TPKT头协议版本通常为0x32EtherNet/IP44818/2222TCP/UDP罗克韦尔、AB报文包含封装头和CIP命令常见命令0x0063列表标识DNP320000TCP/UDP电力自动化同步头为0x0564报文有长度和CRC校验OPC UA4840TCP跨厂商数据采集基于鉴别的安全报文通常有HelloMessage帧拿到一份工控pcap后我建议第一时间用Wireshark的统计功能看协议分布别急着抓包。如果里面既有Modbus又有HTTP先确认哪些是核心控制流量哪些是管理网混进来的杂流再决定后续分析重点。2. 抓包准备与pcap文件基础2.1 工控网络抓包的几个关键点很多人以为抓包就是把笔记本接到交换机上就开始抓但在工控环境中这是行不通的。工业交换机上往往不能随便接设备而且普通交换机端口只能看到本端口的广播和组播流量要去抓PLC和HMI之间的通信得先配置镜像端口把目标端口的流量复制一份出来。更规范的做法是串联TAP设备或者在防火墙上做流量分发。无论哪种方式都要先确认自己有权在相关设备上进行抓包千万不要在未经授权的情况下接入生产网络。抓包位置的选取会影响后续分析。比如你要分析PLC是否有异常写操作就得抓PLC的接入端口流量要分析上位机和PLC之间是否存在非法通信最好抓核心交换机上联口。抓包时长也值得注意工控系统问题可能是偶发的建议至少抓24小时并且按文件大小自动滚动保存防止磁盘写满。还有一个容易忽略的点是抓包长度。默认snaplen可能是65535字节但工控协议报文普遍很小一个Modbus TCP请求往往几十字节就结束了所以抓包长度可以设到128或256字节既能保留完整应用层数据又能降低文件体积。当然如果你怀疑有隐蔽数据传输还是要抓全包。2.2 pcap文件的二进制结构利用工具之前先花点时间理解pcap的二进制结构这对排查抓包异常和写专用解析脚本都很重要。前面提到全局头是24字节完整字段如下struct pcap_file_header { uint32_t magic; /* 0xa1b2c3d4 或字节序反转后的值 */ uint16_t version_major; /* 通常为2 */ uint16_t version_minor; /* 通常为4 */ int32_t thiszone; /* 时区修正一般为0 */ uint32_t sigfigs; /* 时间戳精度一般为0 */ uint32_t snaplen; /* 最大抓包长度 */ uint32_t network; /* 数据链路类型 */ };随后每个数据包头是16字节struct pcap_pkthdr { uint32_t ts_sec; /* 时间戳秒 */ uint32_t ts_usec; /* 时间戳微秒 */ uint32_t incl_len; /* 实际存储的包长度 */ uint32_t orig_len; /* 原始包长度 */ };这里有个关键点incl_len和orig_len可能不同比如因为snaplen限制导致截断incl_len会小于orig_len。解析时要以incl_len为准去移动文件指针否则整个文件解析都会错位。我知道有人用C语言解析pcap时读的是orig_len结果后面全部乱套所以这句请务必记下来。2.3 Wireshark打开工控pcap的第一步拿到pcap文件有些人直接双击打开发现Wireshark把工控流量识别成一堆TCP乱码原因很简单Wireshark默认优先按端口猜测协议但工控环境的端口经常被改或者报文走的是私有端口导致解码不正确。这时候不要急着放弃手动指定解码方式再试。在Wireshark中右键点击任意TCP报文选择“Decode As”把传输层端口映射为对应工控协议比如TCP 502映射为Modbus TCPTCP 102映射为S7comm。如果报文本身是标准的Modbus TCP配置之后基本就能正常解析出功能码、寄存器地址等字段。还有一种情况多段TCP流里只有一部分是工控协议另外一部分是心跳或握手包此时使用“Follow TCP Stream”配合过滤条件来观察完整会话会比单纯翻报文更高效。3. 从pcap中提取工控协议核心信息3.1 用Wireshark和TShark快速筛查分析工控pcap最常用的方式还是先用Wireshark的显示过滤器缩小范围。我经常会用下面这些过滤器基本覆盖了主要工控协议modbus s7comm dnp3 enip opcua如果需要命令行处理TShark是更顺手的选择。比如我想提取某个pcap里所有Modbus TCP读保持寄存器请求的源IP、目的IP和寄存器地址tshark -r capture.pcap -Y modbus.func_code 0x03 \ -T fields -e frame.time -e ip.src -e ip.dst -e modbus.reg_num这里modbus.func_code是Wireshark对Modbus功能码的字段名modbus.reg_num是寄存器地址。实际字段名可以在Wireshark报文详情里右键复制。这种一键提取的方式比人工翻报文快得多尤其是在几万条请求里找异常时。3.2 Modbus TCP报文拆解Modbus TCP是最常遇见的工控协议报文结构好理解用它来举例最合适。一个完整的Modbus TCP请求包含这么几个部分事务处理标识符Transaction ID2字节用于匹配请求和响应协议标识符Protocol ID2字节Modbus里固定为0x0000长度字段2字节表示后续内容的字节数单元标识符Unit ID1字节代表从站设备地址功能码1字节再后面是数据部分。以功能码0x03读保持寄存器为例数据部分包含起始寄存器地址和寄存器数量。比如起始地址0x0000、数量0x000A表示要读取从0号开始的10个寄存器。响应报文里会先返回字节数然后是按顺序排列的寄存器值。真正分析的时候要注意事务处理标识符和单元标识符是否一一对应。如果存在大量相同Transaction ID的报文或者请求后迟迟没有响应基本可以判定通信异常。功能码是判断操作意图的关键。0x01和0x02是读线圈和读离散输入0x03和0x04是读寄存器0x05和0x06是写单个线圈和写单个寄存器0x0F和0x10是写多个线圈和写多个寄存器。如果某台PLC平时只执行读操作突然出现大量0x10写多个寄存器的请求这就是很明显的红线事件应该立即纳入重点核查。3.3 用Scapy手工解析pcap中的工控报文有些场景下Wireshark解析不友好或者你需要批量处理大量文件这时写脚本最方便。Python的Scapy库是很好的选择虽然它不能深度解析每种工控协议但可以用Raw.load字段拿到原始应用层数据然后自己按协议格式拆解。举个例子读取pcap文件中所有TCP 502端口的报文并解析Modbus TCP请求头from scapy.all import rdpcap, IP, TCP, Raw packets rdpcap(capture.pcap) for pkt in packets: if pkt.haslayer(TCP) and pkt[TCP].dport 502 and pkt.haslayer(Raw): data pkt[Raw].load if len(data) 7: trans_id int.from_bytes(data[0:2], big) proto_id int.from_bytes(data[2:4], big) length int.from_bytes(data[4:6], big) unit_id data[6] func_code data[7] print(ftran_id{trans_id} proto_id{proto_id} flen{length} unit{unit_id} func{hex(func_code)})这段代码是基础版的协议解析原理不复杂先判断TCP目的端口确认是Modbus报文再按字段偏移量切数据。真正的生产环境里还可以把功能码、寄存器地址、设备状态做成统计表用于异常检测。C语言解析pcap也是同样的思路只要理解了上一节的文件头和数据包结构用fread按字段读取即可这里不再重复贴完整C代码。3.4 从流量里还原现场控制行为只看单条报文是不够的要还原现场行为得把同一对源目IP之间的请求响应按时间排出来看操作序列是否合理。比如HMI对PLC的执行逻辑通常是“读状态—写指令—确认结果”如果流量中出现没有读过程直接连续写的情况或者写操作的寄存器地址跨度大到不合理就可能不是正常操作流程。我自己常用的一种方法是把每个会话的请求内容做成“操作日志”例如“10:00:00.123 192.168.1.10 - 192.168.1.20 功能码0x10 写10个寄存器 起始地址100”。这样梳理下来整个工控系统的控制行为就变成了可读记录。再结合PLC侧的组态逻辑去判断哪些操作是程序预设、哪些是人工干预往往能定位到具体的异常时间窗口。还有个容易被忽视的陷阱工控协议可能使用了非标准端口或者在同一TCP连接里混合多种协议。解析时如果发现应用层数据无法用标准模板解析先别急着判定为“非工控流量”很可能是私有扩展协议或厂商自定义报文。这种场景下我会把原始数据做hexdump保存下来同时统计报文长度分布看是否存在规律性再决定要不要逆向。4. 工控异常流量识别与流量取证4.1 异常流量的典型特征工控协议的异常流量从检测视角看有几种很高频的模式。第一是异常功能码功能码不在该设备历史行为集合中比如一个从未写过的PLC突然出现大量写请求。第二是异常地址范围寄存器地址或线圈编号明显超出设备配置范围比如工艺数据区只有0到999却出现对地址6000的写操作。第三是扫描探测行为短时间内同一个源IP向大量目标IP发送相同请求这是资产探测的典型特征正常控制逻辑不会这么干。还有一种更隐蔽的是畸形报文比如长度字段与实际数据不符、CRC校验失败这类报文会让协议栈异常也可能暗示存在模糊测试或异常注入。分析时不要只盯着应用层传输层特征同样有价值。比如一条TCP流里SYN包反复重发但连接始终建立不上或者连接的打开和关闭频率极高都可能是扫描或暴力探测。把这些传输层规律和应用层状态放在一起看判断会准确得多。4.2 时间线分析定位异常事件工控事故分析最看重时间线。很多pcap文件里正常流量是规律的比如每秒钟采集一次数据异常发生瞬间包间隔会突然缩短或者出现了大体积突发流量。用Wireshark的“IO Graph”或TShark的统计功能可以画出时间-包数量曲线异常窗口一目了然。定位到时间窗口后再深入分析该时间窗口内所有工控协议报文尤其是请求和响应是否成对出现。如果某一时刻请求量突然增大但响应量没有同比例增长可能说明从站设备异常或者网络路径存在阻塞。响应码中如果是异常响应如Modbus的异常功能码0x80加异常码需要进一步追查是哪一类错误常见的有非法功能码、非法数据地址、非法数据值、从站设备忙等。我习惯把时间线分析的结果整理成三列时间、源目IP、报文摘要。这样无论是自己复盘还是写给其他人看都清楚明了。时间戳统一使用UTC或本地时间不要混用。工控设备日志经常是本地时间而pcap时间戳是系统时间两者如果存在时区差对不上就会错失线索。4.3 流量取证的注意事项如果是安全事件需要固证分析就不能只是打开pcap看了一眼就完事。第一步是先算哈希值用SHA256给原始pcap做摘要并记录文件大小、采集时间、采集设备信息保证证据链完整。第二步是用只读方式打开pcap文件不要用可写方式重新保存副本避免破坏原始数据。最好所有分析都基于复制出来的副本原始文件封存。流量取证还有一个概念叫“会话重组”。工控协议里一次写操作可能被拆分成多个TCP分段尤其是同时处理大量数据时。要还原完整操作就得用Wireshark的“Follow TCP Stream”或者TShark的-z follow,tcp,ascii把单条TCP流的所有数据拼回来。拼接后如果发现有分段缺失或乱序需要特别注意这可能是网络丢包也可能是有人故意在中间断开流量。取证报告里不仅要写结论还要写清楚分析方法和过滤条件。比如“共分析pcap文件XX个过滤Modbus TCP请求XX条其中异常请求XX条”这样的表述比单纯说“发现异常”更有说服力。如果分析过程依赖自写脚本记得把脚本也一并保存方便复核。4.4 pcap文件自身可能带来的坑分析之前先确认pcap文件本身是否可用。最常见的坑是文件被截断比如抓包程序异常退出文件尾部数据不完整但Wireshark可能正常打开并显示部分内容。这时候如果不检查包数量和时间跨度可能会漏掉关键信息。用capinfos命令看一眼文件摘要是最快的体检方式capinfos capture.pcap它会输出文件大小、包数量、时间范围、平均包长等信息。如果提示“File is truncated”或者包数量远小于预期就要考虑重新抓包。另一个坑是pcap文件里的时间戳可能不连续这通常来自抓包过程中系统休眠、磁盘繁忙或虚拟机时钟漂移。做时间线分析时对时间跳变要敏感。还有一个我常看到的问题是重复报文在部署多台抓包设备的情况下同一个包可能被抓了多次不做去重直接统计就会虚高。按IP.ID和TCP序列号可以判定重复包必要时用editcap -d进行去重。5. 工控流量分析常见问题与排查技巧5.1 排查速查表下面这张表是我在实际项目里最常用到的问题-原因-解决对照按频率排序现象可能原因解决思路Wireshark无法识别工控协议端口未映射到对应协议右键Decode As手动指定TCP/UDP端口对应协议过滤语法不生效字段名写错或协议层未正确解析在报文详情中右键字段复制为过滤表达式pcap文件包数量异常少snaplen设置过小、抓包覆盖时间短调大snaplen或延长抓包时间报文乱序严重多路径负载均衡或虚拟机时间漂移按TCP序列号排序或使用Follow TCP Stream重组请求有响应但响应错误功能码不受支持、地址越界解析异常码对照设备地址映射表同一IP出现数百个TCP连接可能存在扫描探测或恶意行为统计源的连接数、目标端口覆盖范围进一步扩大时间窗口分析pcap文件打开后全是乱码链路层头类型识别错误检查全局头network字段确认以太网为1必要时手工指定链路类型5.2 我踩过的几个实操坑先说一个最常见的错误直接把pcap文件发给别人却没说清楚里面的流量是在哪个网段、哪个设备上抓的。没有拓扑背景别人分析起来完全靠猜。我现在拿到pcap第一步是先用Ethernet MAC地址做一次设备统计确认哪些是PLC、哪些是HMI、哪些是工程师站。很多时候异常流量根本不是PLC发出的而是管理网里的某台主机摸到了工控协议端口。第二个坑是过分依赖Wireshark的协议解析。Wireshark对标准Modbus TCP解析得很好但对厂商私有扩展协议经常识别不准。遇到解析出的字段值跟实际设备配置对不上我建议回到原始hex数据手工核对一遍。尤其是寄存器值的大小端问题不同PLC的寄存器存储字节序可能不一样同一个值在两个平台显示完全不同这时候一定要用已知设备状态反推字节序规则别急着下结论。第三个坑和抓包时间有关。我遇到过有人只抓了十几分钟就说“没发现异常”。工控系统的异常往往和生产调度、交接班、定检周期有关不抓完一个完整循环很难看到规律。如果条件允许建议至少抓满一个生产班次并且把工控日志、报警记录同步收集。5.3 分析前的合规与安全提醒做任何工控流量分析前先确认自己是否有合法授权。除非是在自己的实验环境或已获客户/上级授权的项目中否则不要对生产网络随意抓包也不要把网络上捕获到的数据和报文细节随意发给无关人员。工控流量里往往包含产线工艺参数、设备地址、操作人员习惯等敏感信息分析完的pcap文件和报告要注意脱敏和妥善保存。具体操作上对外提供报告时可以隐去IP地址中最后一段、替换真实设备名寄存器值可以保留变化趋势而不暴露绝对数值。这样做既不影响结论表达也能降低数据泄露风险。一点个人体会做工控协议pcap分析这几年我最深的感受是工具只是门槛真正的难度在于把流量语言翻译成现场行为。Wireshark和TShark能帮你找到每一条报文但为什么这条写指令会出现在凌晨三点、为什么某台PLC会突然访问不存在的寄存器地址这些都离不开对控制流程和业务背景的理解。所以我建议每个做这块工作的人除了研究报文格式也多去了解PLC梯形图、DCS组态和现场工艺参数。最后分享一个小习惯我每次拿到新的工控pcap都会先写一个一行式的csvinfo加协议统计命令把整个文件的概况打出来再决定要不要深入分析。别嫌这个动作基础它能帮你少走很多弯路。本文还有配套的精品资源点击获取
简介这是一套面向工控安全研究、网络防御测试和工业系统运维场景的协议流量数据集覆盖西门子S7、Modbus等常见工控协议的真实通信过程能有效缓解工控协议分析中公开流量样本稀缺的问题对深入理解工控网络通信具有重要意义。压缩包共255个文件其中251个pcap抓包文件为主要内容另配有json与md说明文档整体大小68.92MB适合开展协议逆向解析、通信基线与异常行为对比、入侵检测规则开发等方向的研究。已有118人学习浏览。由于多数工控协议在设计时缺乏安全机制这批来自不同环境与测试场景的流量数据有助于分析控制指令、状态读取、寄存器读写等报文字段并能观察正常通信与攻击探测之间的差异从而帮助定位协议脆弱点、评估安全防护策略。无论是编写检测脚本还是判断工业网络安全隐患这些抓包文件都能提供扎实的一手分析素材与验证样本支持研究人员和运维人员快速上手。 干工控这行或者搞OT安全的人迟早都会遇到一个场景现场工程师扔过来一个几十MB的pcap文件说“系统异常了你帮我看看这流量里到底发生了什么”。这时候你手里的工具还是那套抓包分析的老伙计但面对的协议已经不是HTTP、MySQL这些互联网协议而是Modbus TCP、S7comm、DNP3、EtherNet/IP这类工控协议。工控协议流量分析这件事难点不在于会不会用Wireshark而在于懂不懂协议背后的控制逻辑——一台PLC为什么反复读同一个寄存器某条读写指令是不是在合法操作这些从通用网络视角看只是“流量”放到工控场景里却可能是事故的起点。这篇内容比较适合工控安全工程师、工业网络运维人员以及刚接触工控流量分析的安全研究员。我不会只讲过滤语法而是从一份实际pcap文件入手把工控协议流量的整体分析思路、报文字段解读、异常识别和时间线取证串起来最后附上我自己踩过的一些坑。1. 工控协议流量分析到底在分析什么1.1 工控协议和传统IT协议的区别先明确一个基础问题工控协议和Web协议、数据库协议有什么本质区别最核心的一点是工控协议里的每一次请求背后都可能对应一个物理动作。HTTP里一个GET请求失败最多就是页面报错但Modbus TCP里一条写线圈指令如果被恶意执行现场可能就是设备启停、阀门开闭。所以分析工控流量时不能只看“有没有流量”还得看“请求是否合理、参数是否越界、时序是否异常”。工控协议大多是请求-响应模型而且字段设计非常紧凑可读性远不如HTTP。以Modbus TCP为例报文主体就几个字节事务处理标识符、协议标识符、长度、单元标识符、功能码、数据。这种紧凑性带来的问题是流量里一旦出现非预期字段仅靠肉眼很难快速定位必须借助解析工具或脚本把二进制数据映射成可理解的语义。1.2 为什么pcap是工控流量的标准载体pcapPacket Capture文件是目前流量分析领域的事实标准格式Wireshark、TShark、Scapy、tcpdump等工具都原生支持。工控场景选择pcap除了工具生态成熟之外更重要的是它保留了数据链路层的原始信息——MAC地址、VLAN标签、时间戳都在。这在做工业网络资产识别和故障溯源时非常关键一个PLC的IP地址是动态的或者配置错了你还能靠MAC地址锁定具体设备。还需要注意pcap文件本身是有格式约束的不是简单的数据拼凑。我见过不少同事拿十六进制编辑器打开pcap看到一堆字节就懵了。实际上pcap文件由三部分组成全局文件头、逐包数据包头、真正的包数据。全局文件头固定24字节前面4个字节是魔术数字通常为0xa1b2c3d4用来标识字节序再往后是版本号、时区校正、时间戳精度、最大抓包长度和数据链路类型。数据链路类型直接决定了上层怎么解析常见值包括以太网1、Linux cooked capture113等。搞懂这一层后面无论用Wireshark还是写脚本解析心里都有底。1.3 常见工控协议和它们的流量特征实际项目里工控协议大多是“常规协议应用层功能码”的组合。比如Modbus TCP就是把Modbus RTU的协议数据单元封装在TCP报文里S7comm是西门子PLC的通信协议同样跑在TCP 102端口上EtherNet/IP则是基于TCP/UDP 44818端口和UDP 2222端口传输的。DNP3比较特殊它既支持TCP也支持UDP默认端口是20000在电力行业用得特别多。给一张常见工控协议的端口和特征表方便大家拿到pcap文件后第一时间定位协议默认端口传输层典型厂商/场景常见报文特征Modbus TCP502TCPPLC、DCS、RTU协议标识符固定为0x0000长度字段后面是单元标识符和功能码S7comm102TCP西门子报文开头有TLS或TPKT头协议版本通常为0x32EtherNet/IP44818/2222TCP/UDP罗克韦尔、AB报文包含封装头和CIP命令常见命令0x0063列表标识DNP320000TCP/UDP电力自动化同步头为0x0564报文有长度和CRC校验OPC UA4840TCP跨厂商数据采集基于鉴别的安全报文通常有HelloMessage帧拿到一份工控pcap后我建议第一时间用Wireshark的统计功能看协议分布别急着抓包。如果里面既有Modbus又有HTTP先确认哪些是核心控制流量哪些是管理网混进来的杂流再决定后续分析重点。2. 抓包准备与pcap文件基础2.1 工控网络抓包的几个关键点很多人以为抓包就是把笔记本接到交换机上就开始抓但在工控环境中这是行不通的。工业交换机上往往不能随便接设备而且普通交换机端口只能看到本端口的广播和组播流量要去抓PLC和HMI之间的通信得先配置镜像端口把目标端口的流量复制一份出来。更规范的做法是串联TAP设备或者在防火墙上做流量分发。无论哪种方式都要先确认自己有权在相关设备上进行抓包千万不要在未经授权的情况下接入生产网络。抓包位置的选取会影响后续分析。比如你要分析PLC是否有异常写操作就得抓PLC的接入端口流量要分析上位机和PLC之间是否存在非法通信最好抓核心交换机上联口。抓包时长也值得注意工控系统问题可能是偶发的建议至少抓24小时并且按文件大小自动滚动保存防止磁盘写满。还有一个容易忽略的点是抓包长度。默认snaplen可能是65535字节但工控协议报文普遍很小一个Modbus TCP请求往往几十字节就结束了所以抓包长度可以设到128或256字节既能保留完整应用层数据又能降低文件体积。当然如果你怀疑有隐蔽数据传输还是要抓全包。2.2 pcap文件的二进制结构利用工具之前先花点时间理解pcap的二进制结构这对排查抓包异常和写专用解析脚本都很重要。前面提到全局头是24字节完整字段如下struct pcap_file_header { uint32_t magic; /* 0xa1b2c3d4 或字节序反转后的值 */ uint16_t version_major; /* 通常为2 */ uint16_t version_minor; /* 通常为4 */ int32_t thiszone; /* 时区修正一般为0 */ uint32_t sigfigs; /* 时间戳精度一般为0 */ uint32_t snaplen; /* 最大抓包长度 */ uint32_t network; /* 数据链路类型 */ };随后每个数据包头是16字节struct pcap_pkthdr { uint32_t ts_sec; /* 时间戳秒 */ uint32_t ts_usec; /* 时间戳微秒 */ uint32_t incl_len; /* 实际存储的包长度 */ uint32_t orig_len; /* 原始包长度 */ };这里有个关键点incl_len和orig_len可能不同比如因为snaplen限制导致截断incl_len会小于orig_len。解析时要以incl_len为准去移动文件指针否则整个文件解析都会错位。我知道有人用C语言解析pcap时读的是orig_len结果后面全部乱套所以这句请务必记下来。2.3 Wireshark打开工控pcap的第一步拿到pcap文件有些人直接双击打开发现Wireshark把工控流量识别成一堆TCP乱码原因很简单Wireshark默认优先按端口猜测协议但工控环境的端口经常被改或者报文走的是私有端口导致解码不正确。这时候不要急着放弃手动指定解码方式再试。在Wireshark中右键点击任意TCP报文选择“Decode As”把传输层端口映射为对应工控协议比如TCP 502映射为Modbus TCPTCP 102映射为S7comm。如果报文本身是标准的Modbus TCP配置之后基本就能正常解析出功能码、寄存器地址等字段。还有一种情况多段TCP流里只有一部分是工控协议另外一部分是心跳或握手包此时使用“Follow TCP Stream”配合过滤条件来观察完整会话会比单纯翻报文更高效。3. 从pcap中提取工控协议核心信息3.1 用Wireshark和TShark快速筛查分析工控pcap最常用的方式还是先用Wireshark的显示过滤器缩小范围。我经常会用下面这些过滤器基本覆盖了主要工控协议modbus s7comm dnp3 enip opcua如果需要命令行处理TShark是更顺手的选择。比如我想提取某个pcap里所有Modbus TCP读保持寄存器请求的源IP、目的IP和寄存器地址tshark -r capture.pcap -Y modbus.func_code 0x03 \ -T fields -e frame.time -e ip.src -e ip.dst -e modbus.reg_num这里modbus.func_code是Wireshark对Modbus功能码的字段名modbus.reg_num是寄存器地址。实际字段名可以在Wireshark报文详情里右键复制。这种一键提取的方式比人工翻报文快得多尤其是在几万条请求里找异常时。3.2 Modbus TCP报文拆解Modbus TCP是最常遇见的工控协议报文结构好理解用它来举例最合适。一个完整的Modbus TCP请求包含这么几个部分事务处理标识符Transaction ID2字节用于匹配请求和响应协议标识符Protocol ID2字节Modbus里固定为0x0000长度字段2字节表示后续内容的字节数单元标识符Unit ID1字节代表从站设备地址功能码1字节再后面是数据部分。以功能码0x03读保持寄存器为例数据部分包含起始寄存器地址和寄存器数量。比如起始地址0x0000、数量0x000A表示要读取从0号开始的10个寄存器。响应报文里会先返回字节数然后是按顺序排列的寄存器值。真正分析的时候要注意事务处理标识符和单元标识符是否一一对应。如果存在大量相同Transaction ID的报文或者请求后迟迟没有响应基本可以判定通信异常。功能码是判断操作意图的关键。0x01和0x02是读线圈和读离散输入0x03和0x04是读寄存器0x05和0x06是写单个线圈和写单个寄存器0x0F和0x10是写多个线圈和写多个寄存器。如果某台PLC平时只执行读操作突然出现大量0x10写多个寄存器的请求这就是很明显的红线事件应该立即纳入重点核查。3.3 用Scapy手工解析pcap中的工控报文有些场景下Wireshark解析不友好或者你需要批量处理大量文件这时写脚本最方便。Python的Scapy库是很好的选择虽然它不能深度解析每种工控协议但可以用Raw.load字段拿到原始应用层数据然后自己按协议格式拆解。举个例子读取pcap文件中所有TCP 502端口的报文并解析Modbus TCP请求头from scapy.all import rdpcap, IP, TCP, Raw packets rdpcap(capture.pcap) for pkt in packets: if pkt.haslayer(TCP) and pkt[TCP].dport 502 and pkt.haslayer(Raw): data pkt[Raw].load if len(data) 7: trans_id int.from_bytes(data[0:2], big) proto_id int.from_bytes(data[2:4], big) length int.from_bytes(data[4:6], big) unit_id data[6] func_code data[7] print(ftran_id{trans_id} proto_id{proto_id} flen{length} unit{unit_id} func{hex(func_code)})这段代码是基础版的协议解析原理不复杂先判断TCP目的端口确认是Modbus报文再按字段偏移量切数据。真正的生产环境里还可以把功能码、寄存器地址、设备状态做成统计表用于异常检测。C语言解析pcap也是同样的思路只要理解了上一节的文件头和数据包结构用fread按字段读取即可这里不再重复贴完整C代码。3.4 从流量里还原现场控制行为只看单条报文是不够的要还原现场行为得把同一对源目IP之间的请求响应按时间排出来看操作序列是否合理。比如HMI对PLC的执行逻辑通常是“读状态—写指令—确认结果”如果流量中出现没有读过程直接连续写的情况或者写操作的寄存器地址跨度大到不合理就可能不是正常操作流程。我自己常用的一种方法是把每个会话的请求内容做成“操作日志”例如“10:00:00.123 192.168.1.10 - 192.168.1.20 功能码0x10 写10个寄存器 起始地址100”。这样梳理下来整个工控系统的控制行为就变成了可读记录。再结合PLC侧的组态逻辑去判断哪些操作是程序预设、哪些是人工干预往往能定位到具体的异常时间窗口。还有个容易被忽视的陷阱工控协议可能使用了非标准端口或者在同一TCP连接里混合多种协议。解析时如果发现应用层数据无法用标准模板解析先别急着判定为“非工控流量”很可能是私有扩展协议或厂商自定义报文。这种场景下我会把原始数据做hexdump保存下来同时统计报文长度分布看是否存在规律性再决定要不要逆向。4. 工控异常流量识别与流量取证4.1 异常流量的典型特征工控协议的异常流量从检测视角看有几种很高频的模式。第一是异常功能码功能码不在该设备历史行为集合中比如一个从未写过的PLC突然出现大量写请求。第二是异常地址范围寄存器地址或线圈编号明显超出设备配置范围比如工艺数据区只有0到999却出现对地址6000的写操作。第三是扫描探测行为短时间内同一个源IP向大量目标IP发送相同请求这是资产探测的典型特征正常控制逻辑不会这么干。还有一种更隐蔽的是畸形报文比如长度字段与实际数据不符、CRC校验失败这类报文会让协议栈异常也可能暗示存在模糊测试或异常注入。分析时不要只盯着应用层传输层特征同样有价值。比如一条TCP流里SYN包反复重发但连接始终建立不上或者连接的打开和关闭频率极高都可能是扫描或暴力探测。把这些传输层规律和应用层状态放在一起看判断会准确得多。4.2 时间线分析定位异常事件工控事故分析最看重时间线。很多pcap文件里正常流量是规律的比如每秒钟采集一次数据异常发生瞬间包间隔会突然缩短或者出现了大体积突发流量。用Wireshark的“IO Graph”或TShark的统计功能可以画出时间-包数量曲线异常窗口一目了然。定位到时间窗口后再深入分析该时间窗口内所有工控协议报文尤其是请求和响应是否成对出现。如果某一时刻请求量突然增大但响应量没有同比例增长可能说明从站设备异常或者网络路径存在阻塞。响应码中如果是异常响应如Modbus的异常功能码0x80加异常码需要进一步追查是哪一类错误常见的有非法功能码、非法数据地址、非法数据值、从站设备忙等。我习惯把时间线分析的结果整理成三列时间、源目IP、报文摘要。这样无论是自己复盘还是写给其他人看都清楚明了。时间戳统一使用UTC或本地时间不要混用。工控设备日志经常是本地时间而pcap时间戳是系统时间两者如果存在时区差对不上就会错失线索。4.3 流量取证的注意事项如果是安全事件需要固证分析就不能只是打开pcap看了一眼就完事。第一步是先算哈希值用SHA256给原始pcap做摘要并记录文件大小、采集时间、采集设备信息保证证据链完整。第二步是用只读方式打开pcap文件不要用可写方式重新保存副本避免破坏原始数据。最好所有分析都基于复制出来的副本原始文件封存。流量取证还有一个概念叫“会话重组”。工控协议里一次写操作可能被拆分成多个TCP分段尤其是同时处理大量数据时。要还原完整操作就得用Wireshark的“Follow TCP Stream”或者TShark的-z follow,tcp,ascii把单条TCP流的所有数据拼回来。拼接后如果发现有分段缺失或乱序需要特别注意这可能是网络丢包也可能是有人故意在中间断开流量。取证报告里不仅要写结论还要写清楚分析方法和过滤条件。比如“共分析pcap文件XX个过滤Modbus TCP请求XX条其中异常请求XX条”这样的表述比单纯说“发现异常”更有说服力。如果分析过程依赖自写脚本记得把脚本也一并保存方便复核。4.4 pcap文件自身可能带来的坑分析之前先确认pcap文件本身是否可用。最常见的坑是文件被截断比如抓包程序异常退出文件尾部数据不完整但Wireshark可能正常打开并显示部分内容。这时候如果不检查包数量和时间跨度可能会漏掉关键信息。用capinfos命令看一眼文件摘要是最快的体检方式capinfos capture.pcap它会输出文件大小、包数量、时间范围、平均包长等信息。如果提示“File is truncated”或者包数量远小于预期就要考虑重新抓包。另一个坑是pcap文件里的时间戳可能不连续这通常来自抓包过程中系统休眠、磁盘繁忙或虚拟机时钟漂移。做时间线分析时对时间跳变要敏感。还有一个我常看到的问题是重复报文在部署多台抓包设备的情况下同一个包可能被抓了多次不做去重直接统计就会虚高。按IP.ID和TCP序列号可以判定重复包必要时用editcap -d进行去重。5. 工控流量分析常见问题与排查技巧5.1 排查速查表下面这张表是我在实际项目里最常用到的问题-原因-解决对照按频率排序现象可能原因解决思路Wireshark无法识别工控协议端口未映射到对应协议右键Decode As手动指定TCP/UDP端口对应协议过滤语法不生效字段名写错或协议层未正确解析在报文详情中右键字段复制为过滤表达式pcap文件包数量异常少snaplen设置过小、抓包覆盖时间短调大snaplen或延长抓包时间报文乱序严重多路径负载均衡或虚拟机时间漂移按TCP序列号排序或使用Follow TCP Stream重组请求有响应但响应错误功能码不受支持、地址越界解析异常码对照设备地址映射表同一IP出现数百个TCP连接可能存在扫描探测或恶意行为统计源的连接数、目标端口覆盖范围进一步扩大时间窗口分析pcap文件打开后全是乱码链路层头类型识别错误检查全局头network字段确认以太网为1必要时手工指定链路类型5.2 我踩过的几个实操坑先说一个最常见的错误直接把pcap文件发给别人却没说清楚里面的流量是在哪个网段、哪个设备上抓的。没有拓扑背景别人分析起来完全靠猜。我现在拿到pcap第一步是先用Ethernet MAC地址做一次设备统计确认哪些是PLC、哪些是HMI、哪些是工程师站。很多时候异常流量根本不是PLC发出的而是管理网里的某台主机摸到了工控协议端口。第二个坑是过分依赖Wireshark的协议解析。Wireshark对标准Modbus TCP解析得很好但对厂商私有扩展协议经常识别不准。遇到解析出的字段值跟实际设备配置对不上我建议回到原始hex数据手工核对一遍。尤其是寄存器值的大小端问题不同PLC的寄存器存储字节序可能不一样同一个值在两个平台显示完全不同这时候一定要用已知设备状态反推字节序规则别急着下结论。第三个坑和抓包时间有关。我遇到过有人只抓了十几分钟就说“没发现异常”。工控系统的异常往往和生产调度、交接班、定检周期有关不抓完一个完整循环很难看到规律。如果条件允许建议至少抓满一个生产班次并且把工控日志、报警记录同步收集。5.3 分析前的合规与安全提醒做任何工控流量分析前先确认自己是否有合法授权。除非是在自己的实验环境或已获客户/上级授权的项目中否则不要对生产网络随意抓包也不要把网络上捕获到的数据和报文细节随意发给无关人员。工控流量里往往包含产线工艺参数、设备地址、操作人员习惯等敏感信息分析完的pcap文件和报告要注意脱敏和妥善保存。具体操作上对外提供报告时可以隐去IP地址中最后一段、替换真实设备名寄存器值可以保留变化趋势而不暴露绝对数值。这样做既不影响结论表达也能降低数据泄露风险。一点个人体会做工控协议pcap分析这几年我最深的感受是工具只是门槛真正的难度在于把流量语言翻译成现场行为。Wireshark和TShark能帮你找到每一条报文但为什么这条写指令会出现在凌晨三点、为什么某台PLC会突然访问不存在的寄存器地址这些都离不开对控制流程和业务背景的理解。所以我建议每个做这块工作的人除了研究报文格式也多去了解PLC梯形图、DCS组态和现场工艺参数。最后分享一个小习惯我每次拿到新的工控pcap都会先写一个一行式的csvinfo加协议统计命令把整个文件的概况打出来再决定要不要深入分析。别嫌这个动作基础它能帮你少走很多弯路。本文还有配套的精品资源点击获取
