简介本资源是一套面向工控安全研究者、网络协议分析人员及ICS领域学习者的工控协议流量数据集聚焦S7、Modbus等主流协议的原始通信行为建模与异常检测基线构建。压缩包共255个文件含251个pcap格式流量捕获文件覆盖S7、ICSHoneypod、4SICS等典型工控场景、1个APCI协议解析说明json、1份README.md文档、1个sv文件及1个系统隐藏文件.DS_Store整体大小68.92MB结构清晰便于按协议类型或实验环境分类使用。已有121人学习下载适合开展协议逆向分析、IDS规则开发、流量特征提取及工控蜜罐行为复现等实践。读者可直接加载pcap文件进行Wireshark深度解析结合json中的APCI字段定义理解应用层交互逻辑并依托README梳理各捕获场景的设备拓扑与攻击/正常流量上下文为工控安全防护方案设计与教学实验提供真实、可复用的数据支撑。1. 工控协议pcap文件不是“随便抓的流量包”而是能复现Modbus/TCP、S7Comm、DNP3真实通信行为的可验证数据基底你手头那份标着“工控协议pcap”的压缩包大概率不是Wireshark随手点几下就生成的玩具数据——它极可能是某次PLC与HMI之间完成完整读写周期后导出的原始字节流里面藏着Modbus功能码03读保持寄存器触发的16个字节响应载荷、S7Comm中JobAcknowledge交互的三次握手痕迹甚至DNP3链路层控制字段里那个被置位的PRM位。这类pcap文件的核心价值不在于“有流量”而在于“有上下文”时间戳对齐、会话连续、异常帧可定位、协议状态可回溯。它直接服务于三类刚需场景一是安全研究员做协议模糊测试前的语料喂养二是高校实验室搭建ICS蜜罐时的流量特征建模依据三是自动化运维团队验证新部署的工控防火墙规则是否真能拦截非法写操作。如果你正卡在“协议解析脚本跑不通”“Snort规则误报率高”“Wireshark显示‘TCP segment of a reassembled PDU’却看不到应用层内容”这些节点上这份pcap不是辅助材料而是你调试链条里缺失的那块校准基准。2. 工控协议pcap的构成逻辑为什么必须包含多协议共存、带标签的会话切片与原始帧边界2.1 协议共存不是杂乱堆砌而是按ICS网络分层刻意组织真实工控环境从不只跑一种协议。一份合格的工控pcap必然体现“协议分层混布”特征底层是Ethernet II帧头含源/目的MAC中间是IPv4/IPv6注意部分老旧DCS仍用IPX但当前主流pcap已基本淘汰传输层常见TCPModbus/TCP、S7Comm、UDP某些OPC UA PubSub变体或自定义L2封装如PROFINET IRT的实时通道。关键点在于同一pcap内必须存在至少两种主流工控协议的完整会话。例如一个典型样本会包含Modbus/TCP端口502功能码01/03/16事务ID递增且与后续响应严格匹配S7Comm端口102COTP连接建立后携带S7协议头TPKTISO COTPS7含明确的Read/Write请求与Data Unit响应DNP3端口20000链路层0x05/0x64起始、传输层控制字节含DIR/PRM/FIN/FCB、应用层功能码0x01读取内部指示器三级结构完整。提示若你下载的pcap里只有单一协议且无异常帧如Modbus异常响应0x83大概率是教学演示包不适合作为IDS规则训练集。2.2 会话切片必须带语义标签而非仅靠五元组硬切普通网络pcap按TCP流切片即可但工控协议要求按协议语义切片。以S7Comm为例一个完整“读DB1.DBD0”操作实际跨越多个TCP段但Wireshark默认的“Follow TCP Stream”会把COTP连接建立、S7协商、读请求、数据响应、连接释放全部揉进一个文本流导致无法精确定位“哪个TCP段承载了真正的寄存器值”。合格的工控pcap应通过tshark预处理打上会话标签# 提取S7Comm完整会话含所有分片并按Transaction ID分组保存 tshark -r industrial.pcap -Y s7comm -T fields -e frame.number -e ip.src -e ip.dst -e tcp.port -e s7comm.tid -e s7comm.function -E separator, s7comm_sessions.csv该命令输出CSV含frame.number帧序号、s7comm.tid事务ID、s7comm.function功能码后续可用Python按tid聚合连续帧——这才是构建“可执行的协议状态机”的基础。2.3 原始帧边界决定解析成败为什么Wireshark显示“Malformed Packet”工控设备固件常存在帧构造缺陷Modbus/TCP头长度字段2字节未按实际PDU长度填写导致Wireshark误判后续字节为新PDUS7Comm的Data Unit长度字段2字节与实际负载不符触发“Reassembled TCP”警告DNP3链路层FCS校验字段缺失或错误使解析器丢弃整帧。这类“非标准但设备能互通”的帧在安全分析中恰恰是重点。因此优质pcap必须保留原始二进制帧即未经Wireshark重组的Raw bytes可通过以下方式验证# 检查第100帧是否含完整Modbus/TCP头6字节且PDU长度字段有效 import dpkt with open(industrial.pcap, rb) as f: pcap dpkt.pcap.Reader(f) for i, (ts, buf) in enumerate(pcap): if i 99: # 第100帧索引99 eth dpkt.ethernet.Ethernet(buf) if isinstance(eth.data, dpkt.ip.IP): ip eth.data if isinstance(ip.data, dpkt.tcp.TCP) and ip.data.dport 502: tcp ip.data if len(tcp.data) 6: # Modbus/TCP头最小6字节 mb_header tcp.data[:6] transaction_id int.from_bytes(mb_header[0:2], big) protocol_id int.from_bytes(mb_header[2:4], big) length int.from_bytes(mb_header[4:6], big) print(fFrame {i1}: TID{transaction_id}, ProtoID{protocol_id}, PDU_len{length}) # 若length远大于len(tcp.data[6:])说明帧截断或长度字段错误该脚本直接读取原始帧绕过Wireshark解析层确认协议头字段真实性——这是后续所有深度解析的前提。3. 工控协议pcap的四大核心用途从协议逆向到规则验证的闭环路径3.1 协议逆向用tshark Python提取状态转移序列工控设备厂商常不公开私有协议细节。此时pcap就是唯一逆向入口。以某国产PLC的私有协议为例假设其使用TCP端口4000我们需从流量中还原“登录→读寄存器→写寄存器→登出”全流程# 步骤1过滤目标端口所有TCP流导出十六进制载荷 tshark -r industrial.pcap -Y tcp.port4000 -T fields -e frame.number -e tcp.stream -e data.text -E separator| raw_streams.txt # 步骤2用Python按tcp.stream分组识别固定字段如登录请求必含0x1A2B3C4D魔数 import re streams {} with open(raw_streams.txt) as f: for line in f: parts line.strip().split(|) if len(parts) 3: continue frame_num, stream_id, payload parts[0], parts[1], parts[2] if stream_id not in streams: streams[stream_id] [] streams[stream_id].append((int(frame_num), payload)) # 步骤3遍历每个stream查找魔数位置及后续字段偏移 for sid, frames in streams.items(): for fn, pl in frames: if 1a2b3c4d in pl.replace( , ): # 登录请求特征 print(fStream {sid} Frame {fn}: Login request at offset {pl.find(1a2b3c4d)//2}) # 后续帧中查找响应包比对相同offset处是否返回0x00表示成功此方法不依赖协议文档纯靠流量统计规律定位关键字段是逆向闭源工控设备的事实标准流程。3.2 IDS规则开发用Snort 3生成可验证的检测逻辑工控IDS规则失效主因是“匹配太宽泛”。例如简单匹配content:\x00\x01\x00\x00\x00\x06\x00\x03Modbus读保持寄存器会误报所有含该字节串的HTTP流量。正确做法是结合协议状态与上下文约束# Snort 3规则精准检测非法Modbus写操作功能码16且仅当源IP为非授权HMI时告警 alert tcp $HOME_NET any - $EXTERNAL_NET 502 ( \ msg:INDUSTRIAL: Illegal Modbus Write Multiple Registers from unauthorized HMI; \ content:|00 00 00 00 00 06 00 10|; \ depth:8; \ offset:0; \ byte_test:1,!,0x01,12,relative; # 检查字节12功能码后第1字节是否非0x01即非合法HMI\ sid:1000001; \ rev:1; \ )注意byte_test指令在此处强制校验功能码后第1字节即地址字段高位是否为非授权值避免单纯content匹配的误报。该规则必须用你下载的pcap中的真实非法写帧进行测试——将pcap导入Snort 3并启用此规则观察告警是否精确命中目标帧。3.3 防火墙策略验证用Scapy重放流量并观测策略生效点部署工控防火墙后需验证“禁止PLC响应外部读请求”是否真正生效。不能只看日志要实测# 构造一个合法Modbus读请求来自授权IP 192.168.1.100目标PLC 192.168.1.200 from scapy.all import * ip IP(src192.168.1.100, dst192.168.1.200) tcp TCP(sport54321, dport502, flagsPA, seq100, ack1) # Modbus/TCP头TID0x0001, ProtoID0x0000, Length0x0006, UnitID0x01, Func0x03, StartAddr0x0000, RegCount0x0001 mb_pdu b\x00\x01\x00\x00\x00\x06\x01\x03\x00\x00\x00\x01 pkt ip/tcp/mb_pdu # 发送并捕获响应若防火墙阻断将收不到响应若放行将收到含0x0001寄存器值的响应 ans, unans sr(pkt, timeout2, verbose0) if ans: resp ans[0][1] if TCP in resp and resp[TCP].flags 0x10: # ACK标志位 print(Firewall ALLOWED the request) # 解析响应中的寄存器值取第9字节起的2字节 if len(resp[TCP].payload) 11: reg_val int.from_bytes(resp[TCP].payload[9:11], big) print(fPLC returned register value: {reg_val}) else: print(Firewall BLOCKED the request — policy working.)此脚本直接验证策略效果比单纯看防火墙日志更可靠——因为日志可能被缓冲或采样丢失。3.4 教学演示用Wireshark着色规则让协议结构一目了然对学生讲解S7Comm时若只展示原始十六进制学员极易迷失。应利用Wireshark着色规则突出协议层次# 将以下内容保存为 ~/.wireshark/colorfilters/s7comm.cf # S7Comm COTP连接建立绿色 s7comm cotp cotp.len 2 # S7Comm Read请求蓝色 s7comm s7comm.function 0x04 # S7Comm Write请求红色 s7comm s7comm.function 0x05 # S7Comm Data Unit响应紫色 s7comm s7comm.function 0x07 s7comm.data_unit.length 0加载后Wireshark界面中不同语义的S7帧自动染色学生一眼可辨“哪段是请求、哪段是响应、哪段是异常”大幅提升教学效率。此功能依赖pcap中S7Comm字段被Wireshark正确解析——再次印证pcap质量决定上层工具效能。4. 工控协议pcap避坑指南五个血泪经验换来的边界条件核查清单4.1 现象Wireshark显示“TCP segment of a reassembled PDU”但右键“Export Packet Bytes”导出的文件无法被dpkt解析原因pcap文件在抓包时启用了TCP流重组如TShark-o tcp.desegment_tcp_streams:TRUE导致导出的单帧实际是重组后的应用层PDU而非原始以太网帧。dpkt等底层库要求输入原始帧含Ethernet/IP/TCP头而重组后数据缺失TCP头。解决重新抓包时禁用重组tshark -i eth0 -w fixed.pcap -o tcp.desegment_tcp_streams:FALSE或用editcap修复现有pcapeditcap -F libpcap -T ether fixed.pcap repaired.pcap。4.2 现象用scapy.rdpcap()读取pcap后pkt[IP].src报错IndexError: Layer [IP] not found原因该pcap包含非IP流量如PROFINET RT使用以太网类型0x8892无IP头而Scapy默认只解析IP层。当遍历帧时遇到非IP帧pkt[IP]直接抛异常。解决遍历前加类型判断for pkt in rdpcap(industrial.pcap): if IP in pkt: print(fIP src: {pkt[IP].src}) elif Ether in pkt and pkt[Ether].type 0x8892: # PROFINET print(PROFINET frame detected)4.3 现象Snort 3规则在测试pcap中不告警但用tcpdump -r确认目标帧存在原因Snort 3默认启用stream预处理器会对TCP流进行重组。若pcap中TCP分片顺序错乱如因交换机QoS导致Snort可能无法正确重组导致规则匹配失败。解决临时禁用stream预处理器测试snort -r industrial.pcap -c /etc/snort/snort.lua --no-prefilter -A console若此时规则触发则需检查pcap时间戳是否连续用tshark -r p.pcap -T fields -e frame.time_epoch | head -5验证或启用stream.flush_on_timeout参数。4.4 现象用pandas.read_csv()解析tshark导出的CSV时data.text字段含换行符导致行错位原因tshark导出的data.text字段含\n如0000 01 03 00 00 00 01 84 0a\n0010 00 01而CSV解析器将其视为新行。解决导出时强制转义换行符tshark -r p.pcap -Y modbus -T fields -e frame.number -e data.text -E quoted -E occurrencef modbus.csv-E quoted启用双引号包裹-E occurrencef确保每行仅输出首个匹配字段。4.5 现象DNP3流量中dnp3.control字段显示not dissected无法提取FCB位原因Wireshark版本过低3.6或未启用DNP3解码器。DNP3控制字节Control Field解析需Wireshark 3.6且编译时启用--with-dnp3。解决升级Wireshark至最新版并在Edit Preferences Protocols DNP3中勾选Enable DNP3 dissector或用命令行强制启用tshark -o dnp3.enabled:true -r p.pcap -Y dnp3.control.fcb 1。5. 进阶技巧用Python构建工控协议pcap的“指纹-行为”双维度校验体系5.1 协议指纹从原始帧提取不可伪造的设备特征工控设备固件版本常通过协议字段暴露。例如西门子S7-1200 PLC在S7Comm协商阶段会发送SZL ID 0x0011模块标识其响应数据中包含固件版本字符串。但手动翻找效率低下需自动化提取def extract_s7_firmware(pcap_path): 从pcap中提取所有S7Comm SZL 0x0011响应的固件版本 import dpkt firmware_versions set() with open(pcap_path, rb) as f: pcap dpkt.pcap.Reader(f) for ts, buf in pcap: try: eth dpkt.ethernet.Ethernet(buf) if isinstance(eth.data, dpkt.ip.IP): ip eth.data if isinstance(ip.data, dpkt.tcp.TCP) and ip.data.dport 102: tcp ip.data if len(tcp.data) 20: # 确保有足够数据 # 查找SZL 0x0011响应特征S7头后紧跟0x0011且长度字段10 payload tcp.data # S7Comm头结构TPKT(4)COTP(2)S7(12)共18字节 if len(payload) 18: s7_header payload[6:18] # 跳过TPKTCOTP if len(s7_header) 12: # 检查是否为SZL响应S7头中Function Code0x07Data UnitData Unit中SZL ID0x0011 if s7_header[8] 0x07 and payload[18:20] b\x00\x11: # 固件版本在SZL数据区偏移0x1A处ASCII字符串 if len(payload) 32: fw_start 32 fw_end payload.find(b\x00, fw_start) if fw_end fw_start: fw_str payload[fw_start:fw_end].decode(ascii, errorsignore) if V in fw_str: # 典型固件格式如V4.4.2 firmware_versions.add(fw_str) except Exception as e: continue return firmware_versions # 执行 versions extract_s7_firmware(industrial.pcap) print(Detected S7 firmware versions:, versions) # 输出{V4.4.2, V2.3.1}该函数直接解析原始帧绕过Wireshark提取出设备真实固件指纹——这是评估漏洞影响范围的关键依据如CVE-2023-XXXX仅影响V4.2.0以下。5.2 行为画像用时间序列分析识别异常通信模式正常工控流量具有强周期性。例如PLC以100ms间隔轮询传感器。若pcap中某IP突然以10ms间隔密集发送Modbus读请求即为异常。需构建时间序列模型import numpy as np from scipy import stats def analyze_modbus_interval(pcap_path, target_port502): 分析目标端口Modbus请求的时间间隔分布 import dpkt intervals [] last_ts None with open(pcap_path, rb) as f: pcap dpkt.pcap.Reader(f) for ts, buf in pcap: try: eth dpkt.ethernet.Ethernet(buf) if isinstance(eth.data, dpkt.ip.IP): ip eth.data if isinstance(ip.data, dpkt.tcp.TCP) and ip.data.dport target_port: tcp ip.data if len(tcp.data) 6: # 检查是否为Modbus/TCP请求功能码01/03/04/16 func_code tcp.data[7] if len(tcp.data) 7 else 0 if func_code in [0x01, 0x03, 0x04, 0x10]: if last_ts is not None: interval_ms (ts - last_ts) * 1000 intervals.append(interval_ms) last_ts ts except Exception: pass if len(intervals) 10: print(Not enough Modbus requests to analyze) return # 计算统计量 arr np.array(intervals) print(fTotal requests: {len(intervals)}) print(fMean interval: {np.mean(arr):.2f}ms) print(fStd deviation: {np.std(arr):.2f}ms) print(fMin/Max: {np.min(arr):.2f}ms / {np.max(arr):.2f}ms) # 检测异常值Z-score 3 z_scores np.abs(stats.zscore(arr)) outliers np.where(z_scores 3)[0] if len(outliers) 0: print(fOutlier intervals (index, ms):) for idx in outliers[:5]: # 显示前5个 print(f {idx}: {arr[idx]:.2f}ms) # 执行 analyze_modbus_interval(industrial.pcap)该脚本输出类似Total requests: 1247 Mean interval: 100.23ms Std deviation: 2.15ms Min/Max: 95.42ms / 156.78ms Outlier intervals (index, ms): 882: 156.78ms 883: 155.21ms这提示在第882帧附近出现持续超长间隔可能对应PLC重启或网络拥塞——这种基于pcap的行为分析比单纯看设备日志更客观。5.3 双维度校验表指纹与行为交叉验证决策树将上述两个维度结果整合形成可操作的校验表校验维度正常表现异常表现应对动作协议指纹S7Comm响应中固件版本一致如全为V4.4.2同一pcap中出现V2.3.1与V4.4.2混用检查是否为多型号设备混合网络或存在仿冒设备请求间隔Modbus读请求标准差5ms100ms周期标准差20ms且存在10ms密集请求启动流量溯源检查发起IP是否为授权HMI响应时延95%请求响应时间15ms响应时间50ms占比5%检查PLC CPU负载或网络延迟非协议问题异常帧率Modbus异常响应0x83占比0.1%异常响应占比2%且集中于特定寄存器地址检查该寄存器是否被恶意写入导致PLC故障注意此表必须基于你下载的pcap实际运行结果填充。我曾在一个客户现场发现其pcap中S7Comm固件指纹显示V2.3.1但行为分析显示请求间隔标准差仅1.2ms——这明显矛盾最终查明是旧版Wireshark将V4.4.2误解析为V2.3.1因SZL数据区偏移计算错误。从那以后我每次拿到新pcap都强制先用dpkt脚本提取指纹再与Wireshark显示对比否则绝不信任任何上层分析结论。希望帮到你。本文还有配套的精品资源点击获取
