简介这份资源面向网络安全与机器学习方向的学习者提供基于IoT23数据集的网络流量异常检测与多分类完整实验方案。项目使用Python 3.8.8结合scikit-learn、pandas、numpy、matplotlib、seaborn及psutil等工具覆盖朴素贝叶斯、决策树、随机森林、支持向量机与逻辑回归等多种分类器的对比实验适合具备一定机器学习基础、希望深入IoT安全场景的读者。资源包共215个文件包含164张png可视化图表、31个py脚本、9个xlsx结果表格、8个json评分文件及说明文档压缩包约12.14MB结构清晰便于按模块查阅与复现。目前已有1456人学习下载。通过该资源读者可获取从数据预处理、模型训练到多分类评估的完整代码与图表结果理解不同算法在IoT流量异常识别中的表现差异并借助评分文件与可视化输出快速定位关键结论为后续研究或课程实践提供可复用的参考。1. 从一份被低估的流量数据集说起IoT23 异常分类到底难在哪如果你手头有一批 IoT 设备抓下来的 pcap想做一个「正常 / 异常」二分类甚至多分类大概率绕不开 IoT23 这个数据集。它由一批研究者用真实物联网设备在受控环境下采集覆盖门铃、温控、灯泡、摄像头等二十多种设备标注了十余类攻击流量和正常流量。很多人第一次跑它会以为「标签都有了特征一抽XGBoost 一上F1 就上去了」。真跑一遍才发现类别极度不均衡、部分攻击样本只有几百条、pcap 里混杂着大量重传和扫描噪声模型在多数类上刷到 0.99在少数类上直接躺平。这篇笔记就围绕「基于 IoT23 数据集的网络流量异常检测与分类」这条主线把从数据理解、特征工程、模型选型到排错的完整链路讲清楚。适合两类人一类是刚拿到 IoT23、想快速跑通一个可复现 baseline 的新手另一类是做流量侧安全、想搞清楚「为什么我的模型指标虚高但线上抓不到攻击」的熟手。我不会假装见过某份源码包所有步骤都是这个方向里最常见、最稳的做法参数和坑我会给到能直接抄的程度。2. 先搞懂 IoT23 的数据形态pcap、标签与类别分布2.1 数据集的目录结构与标签来源IoT23 的原始形态是「按设备 攻击场景切分的 pcap 文件」配套一份标注文件通常以conn.log.labeled这类 Zeek/Bro 连接日志的形式给出。也就是说它已经帮你把 pcap 聚合成了一条条「连接记录」每条记录带五元组、时长、字节数、包数以及一个label字段。这个 label 一般长这样PartOfAHorizontalPortScan、Okiru、CC、DDoS、Benign等前面还会带一个-或Malicious/Benign的粗粒度前缀。理解这一点很关键你拿到的不是原始包而是连接级聚合。这意味着基于包间隔、TCP 标志位序列的细粒度特征在 IoT23 上天然受限你更多是在「流特征」层面做文章。常见做法是先用 Zeek 重新解析 pcap 拿到更全的字段或者直接用官方给的 labeled 日志。先做一件事把标签分布统计出来别急着建模。import pandas as pd # 读取 Zeek 连接日志sep 用制表符注意 label 列名可能是 label 或 tunnel_parents label df pd.read_csv(conn.log.labeled, sep\t, comment#, low_memoryFalse) # 官方日志里 label 常带前缀拆出细粒度类别 df[detail] df[label].astype(str).str.split().str[-1] print(df[detail].value_counts()) print(总连接数:, len(df))这段代码做两件事一是用comment#跳过 Zeek 的头部注释行二是把复合标签拆成细粒度类别。跑完你会看到典型的长尾分布——Benign可能占七成以上某些攻击类只有几百条。参数说明low_memoryFalse是为了避免混合类型推断导致 label 被截断如果你的日志列名不同先用df.columns打印确认别硬套。2.2 类别不均衡到底有多严重把上一步的分布画成表你会得到类似这样的结构数值是量级示意以你本地实际为准类别量级占比建模风险Benign60%~80%主导损失模型倾向全预测它扫描类PortScan10%~20%特征明显容易学DDoS / DoS5%~15%与正常大流量易混CC / 恶意软件5%样本少召回率低其他攻击1%几乎学不动看到这张表你就该放弃「直接上 accuracy」的念头。在 IoT23 上accuracy 是最没用的指标一个全预测 Benign 的模型也能有 0.7 以上。正确姿势是看 macro-F1 和每类 recall后面模型章节会展开。2.3 特征字段里哪些能用、哪些是陷阱Zeek 连接日志的字段很多但不是都能进模型。我一般分三类处理直接可用duration、orig_bytes、resp_bytes、orig_pkts、resp_pkts、proto、conn_state、service。需要编码proto、conn_state、service是类别型用 one-hot 或 target encoding别直接丢 label encoding 给树模型以外的模型。必须剔除uid、ts、id.orig_h、id.resp_h这类标识和时间戳。血泪经验IP 和时间戳进模型会让模型学到「某个 IP 段就是攻击」这种伪相关离线指标漂亮换一批数据直接翻车。提示id.resp_p端口号可以保留但建议做分桶如 well-known / registered / dynamic否则高基数会稀释树模型的分裂增益。3. 从 pcap 到特征矩阵可复现的预处理流水线3.1 用 Zeek 重新解析还是直接用 labeled 日志两条路各有取舍。直接用官方 labeled 日志最快但字段可能不全用 Zeek 重跑 pcap 更灵活但耗时且需要环境。我的建议是先跑通 labeled 日志的 baseline再决定要不要重解析。如果你确实要重解析命令大致如下# 用 Zeek 解析单个 pcap输出 conn.log zeek -r capture.pcap /path/to/zeek/scripts/base/protocols/conn # 批量处理一个目录下的 pcap for f in pcaps/*.pcap; do zeek -r $f local done逻辑说明-r指定离线读取 pcaplocal是你自定义的脚本入口里面加载 conn 日志。跑完会在当前目录生成conn.log。参数说明如果 pcap 很大加-C忽略校验和错误能提速但会引入少量噪声生产环境别加。3.2 特征工程数值归一化与类别编码拿到 DataFrame 后核心是把异构字段拼成模型能吃的东西。下面是一段我常用的预处理骨架import numpy as np from sklearn.preprocessing import StandardScaler num_cols [duration, orig_bytes, resp_bytes, orig_pkts, resp_pkts] cat_cols [proto, conn_state, service] # 1. 数值列缺失填 0做 log1p 压缩长尾再标准化 for c in num_cols: df[c] pd.to_numeric(df[c], errorscoerce).fillna(0) df[c] np.log1p(df[c].clip(lower0)) scaler StandardScaler() df[num_cols] scaler.fit_transform(df[num_cols]) # 2. 类别列one-hot限制最小频次避免维度爆炸 df pd.get_dummies(df, columnscat_cols, min_frequency50) # 3. 丢掉标识列 drop_cols [uid, ts, id.orig_h, id.resp_h, label, detail] X df.drop(columns[c for c in drop_cols if c in df.columns]) y df[detail]逻辑说明流量字节数、包数都是典型长尾分布直接标准化会被极值带偏所以先log1p再StandardScaler。min_frequency50是把出现次数少于 50 的类别归为 infrequent防止 one-hot 维度失控。参数说明clip(lower0)是防御性写法Zeek 偶尔会输出-表示未知转数值后变 NaNfillna 已处理但 clip 能兜住负值异常。3.3 划分训练集时别用随机切分这是最容易踩的坑之一。IoT23 的流量是按时间连续采集的随机切分会让同一时段的相似流量同时出现在训练和测试集指标虚高。正确做法是按时间或按设备切分from sklearn.model_selection import GroupShuffleSplit # 假设你保留了设备标识列 device gss GroupShuffleSplit(n_splits1, test_size0.3, random_state42) train_idx, test_idx next(gss.split(X, y, groupsdf[device])) X_train, X_test X.iloc[train_idx], X.iloc[test_idx] y_train, y_test y.iloc[train_idx], y.iloc[test_idx]逻辑说明GroupShuffleSplit保证同一设备的样本不会跨训练/测试集模拟「新设备上线」的真实场景。参数说明test_size0.3是经验值样本少时可降到 0.2random_state固定住方便复现。4. 模型选型与训练从树模型 baseline 到代价敏感学习4.1 为什么先上 LightGBM 而不是深度学习流量特征大多是表格型、维度不高、样本量中等这个场景下梯度提升树几乎总是优于 MLP。LightGBM 训练快、对类别特征友好、能直接输出特征重要性非常适合做第一版 baseline。深度学习在 IoT23 上不是不能做但需要序列建模如把连接按时间排成序列工程成本高收益不稳定。我一般会先用 LightGBM 把指标和特征重要性跑出来再决定要不要上序列模型。4.2 处理类别不均衡的三种手段前面说了 IoT23 长尾严重训练时必须处理。三种手段按推荐顺序class_weight 加权最省事LightGBM 里用class_weightbalanced或自定义权重。重采样对少数类过采样SMOTE 在流量特征上要慎用容易生成不合理的合成样本或对多数类欠采样。代价敏感 阈值调整训练后按类调决策阈值牺牲部分多数类精度换少数类召回。先看加权训练的代码import lightgbm as lgb from sklearn.utils.class_weight import compute_class_weight classes np.unique(y_train) weights compute_class_weight(balanced, classesclasses, yy_train) class_weight dict(zip(classes, weights)) model lgb.LGBMClassifier( n_estimators500, learning_rate0.05, num_leaves63, class_weightclass_weight, random_state42, ) model.fit(X_train, y_train)逻辑说明compute_class_weight(balanced)按类别频率反比给权重少数类权重高模型会更关注它们。参数说明num_leaves63是控制模型复杂度的关键流量特征噪声大叶子太多容易过拟合n_estimators500配合learning_rate0.05是稳妥组合想更快收敛可以提到 0.1 但要注意早停。4.3 评估macro-F1 与混淆矩阵才是重点训练完别只看 accuracy。下面这段评估代码是我每次必跑的from sklearn.metrics import classification_report, confusion_matrix, f1_score y_pred model.predict(X_test) print(classification_report(y_test, y_pred, digits4)) print(macro-F1:, f1_score(y_test, y_pred, averagemacro)) # 看哪些类被混淆 cm confusion_matrix(y_test, y_pred, labelsclasses) cm_df pd.DataFrame(cm, indexclasses, columnsclasses) print(cm_df)逻辑说明classification_report给出每类 precision/recall/F1macro-F1对每类等权能暴露少数类拉胯。混淆矩阵帮你定位「哪两类在互相误判」比如 DDoS 和正常大流量经常混。参数说明digits4只是显示精度不影响计算。4.4 特征重要性验证模型有没有学到伪相关跑完模型一定要看特征重要性。如果id.resp_p或某个编码后的类别特征排在最前面要警惕。正常情况应该是resp_bytes、duration、orig_pkts这类行为特征靠前。如果发现可疑特征回到 3.3 检查有没有漏删标识列。5. 避坑与排查IoT23 分类里最容易翻车的五件事5.1 指标 0.99 但线上抓不到攻击现象离线 macro-F1 很高部署后几乎不报警。原因随机切分导致训练测试同分布或者标签泄漏比如把 label 的某个衍生字段留在了特征里。解决改用 GroupShuffleSplit 或按时间切分逐列检查特征是否直接来自 label。5.2 少数类 recall 长期为 0现象CC 类 recall 一直是 0模型完全不预测它。原因样本太少 未做任何不均衡处理模型直接放弃。解决先加 class_weight再考虑对少数类做适度过采样如果样本只有几十条考虑把它合并到「其他恶意」大类别硬分。5.3 训练时报类别数不匹配现象ValueError: y contains previously unseen labels。原因one-hot 或编码器在训练集上拟合测试集出现了训练时没见过的类别。解决用handle_unknownignore的 OneHotEncoder或像 3.2 那样用min_frequency把稀有类别提前归并。5.4 内存爆掉现象读 conn.log 时进程被 OOM kill。原因Zeek 日志动辄几百万行one-hot 后维度爆炸。解决分块读取chunksize或先做特征筛选再编码pd.get_dummies前先统计每列基数超过 100 的类别列考虑 target encoding。5.5 模型在某个设备上集体失效现象整体指标正常但某类设备的样本几乎全错。原因该设备流量模式特殊训练集中占比过低。解决按设备分层采样或在损失里给该设备样本更高权重也可以做设备维度的指标拆解别只看全局。6. 进阶技巧用分位数特征和阈值搜索把少数类召回拉起来到这一步你已经有一个能跑的 baseline 了。但如果你真的要把 IoT23 的异常分类做到可用还有两个技巧值得花时间。第一给流量特征加分位数统计。单条连接的resp_bytes是绝对值但「这条连接的字节数在同设备同服务里处于什么分位」往往更有区分度。做法是按(device, service)分组对resp_bytes、duration算分位数再把每条记录映射到分位区间。这个特征能让模型区分「大流量但对该设备正常」和「大流量且异常」对 DDoS 和正常视频流的混淆特别有效。# 按设备服务分组计算 resp_bytes 的分位排名 df[bytes_pct] df.groupby([device, service])[resp_bytes].rank(pctTrue)逻辑说明rank(pctTrue)返回每条记录在组内的百分位取值 0~1。参数说明分组键里service可能有缺失先 fillna 成 unknown否则整组会被丢掉。第二别用默认 0.5 阈值做逐类阈值搜索。多分类里每类的决策边界可以独立调。思路是对每个类在验证集上扫一遍阈值选让该类 F1 最大的那个。下面是一个简化实现import numpy as np from sklearn.metrics import f1_score proba model.predict_proba(X_test) best_thresholds {} for i, cls in enumerate(model.classes_): best_f1, best_t 0, 0.5 for t in np.arange(0.1, 0.9, 0.05): pred (proba[:, i] t).astype(int) true (y_test cls).astype(int) f1 f1_score(true, pred, zero_division0) if f1 best_f1: best_f1, best_t f1, t best_thresholds[cls] best_t print(f{cls}: best_t{best_t:.2f}, F1{best_f1:.4f})逻辑说明把多分类拆成「对每个类做一对多」独立搜阈值。参数说明np.arange(0.1, 0.9, 0.05)是搜索网格太细会过拟合验证集太粗找不到最优点zero_division0避免某类全不预测时报 warning。最后说个我自己的习惯每次调完参我都会把当次的特征列表、类别分布、macro-F1 和每类 recall 存成一个版本记录。IoT23 这种长尾数据集改动一个编码方式就可能让某类 recall 从 0.6 掉到 0.2没有版本记录你根本不知道是哪一步退化的。这个习惯帮我省了无数次「后悔药」。希望帮到你。本文还有配套的精品资源点击获取