简介这套源代码是面向网络安全与机器学习方向学习者的完整项目方案聚焦加密恶意流量的自动分析与检测。项目按照数据采集、特征工程、模型训练、Web可视化监测等链路组织涵盖基于Scapy的getgoodx.py流量采集脚本、大规模攻击样本pcap解析、SVM/随机森林/集成学习等多种检测模型并提供一个基于Flask的流量上传与监测界面。包内共80个文件压缩后约1.11MB以14个Python源码、11个pyc、9个pcap抓包样本、8个HTML与8个CSS前端页面、3个CSV数据集、3个model.pkl预训练模型及中英文README文档为主目录划分清晰便于按模块查阅。已有148人学习/下载。通过学习此项目可掌握从Scapy流量采集、数据清洗与特征工程到模型训练落地的完整闭环也能参考Flask框架搭建人机交互界面适合作为课程设计、毕业设计或安全比赛的高分参考模板。1. 加密流量不是黑匣子机器学习能看到什么做了几年安全方向的项目有一个感受越来越强烈加密流量分析不是靠解密去抓攻击而是靠流量本身暴露出来的行为特征去做判断。这个基于机器学习的加密恶意流量分析与检测平台正是把这条思路完整落地的一套源码包。它拿 Scapy 采正常流量样本用大规模攻击流量 pcap 做数据来源然后经过数据清洗、过滤和特征工程送到 SVM、随机森林和集成学习模型里完成训练和预测最后用 Flask 搭了一个上传 pcap 文件就能看检测结果和分布图表的 web 界面。也就是说它适合三种人做毕设需要完整课题链路的学生、想在企业内网做加密流量监测实验的工程师、以及想快速上手流量分析但又不知道特征从哪下手的研究者。平台不是上来就让你调模型而是把「能复现」放在了第一位。压缩包里既有源码、训练测试脚本也带训练好的 model.pkl 和说明文档拿到手可以先跑通再改参数。下面按一条完整链路拆开讲数据怎么采、pcap 怎么解、特征怎么提、模型怎么选、web 端怎么接以及我实际跑下来踩过的几个坑。2. 采集与预处理Scapy 采集、pcap 解析与特征工程的三个关键点2.1 getgoodx.py 的工作机制正常流量要采得“杂”先说正常流量样本的采集。项目中用的是 getgoodx.py核心库就是 Scapy。这个脚本不是简单地在本地抓几个包就算了而是会去访问一批常见网站尽量覆盖 HTTP、HTTPS、DNS、TCP 握手这些不同协议类型让正常样本的分布足够接近真实办公网络。我拆过这个脚本逻辑大致是循环访问预设 URL 列表、在后台用 Scapy 异步抓包、按会话维度把数据包切成 flow、最后写入 pcap 文件。这里有个关键细节它不是只抓 80 端口而是把 443 端口的 TLS 握手包也抓下来——因为加密流量多数集中在 443这部分特征后面全靠它。from scapy.all import * import time def collect_traffic(duration60, out_filegood_traffic.pcap): packets [] # 异步抓包session 级别聚合 sniff(prnlambda x: packets.append(x), timeoutduration, storeFalse) wrpcap(out_file, packets)这段代码里有一个容易忽略的点sniff 的 storeFalse 只做实时处理不缓存但如果你后面要按流聚合必须在 prn 回调里就把五元组信息拿出来。项目里实际是配合了另一个线程去访问 URL保证抓包时段内有真实的流量产生。参数 duration 控制抓包时长60 秒是比较合理的基线——太短特征容易稀疏太长会引入大量空闲连接。2.2 大规模攻击样本解析pcap 文件不是直接喂给模型的攻击样本部分项目解析的是大型公开攻击流量 pcap这类 pcap 文件动辄几百 MB包含扫描、暴力破解、恶意 TLS 连接、DDoS 等多种攻击类型。直接拿 Scapy 一条条读效率低项目里用了一次性批量解析的思路rdpcap 读入全部包之后马上按src_ip, dst_ip, src_port, dst_port, protocol这五个字段做分组聚合。from scapy.all import rdpcap from collections import defaultdict pcap_file attack.pcap packets rdpcap(pcap_file) flows defaultdict(list) for pkt in packets: if pkt.haslayer(TCP): key (pkt[IP].src, pkt[IP].dst, pkt[TCP].sport, pkt[TCP].dport, tcp) elif pkt.haslayer(UDP): key (pkt[IP].src, pkt[IP].dst, pkt[UDP].sport, pkt[UDP].dport, udp) else: continue flows[key].append(pkt) # 每个 flow 转成一条特征记录 flow_records [extract_features(k, v) for k, v in flows.items()]rdpcap 会把整个文件读入内存几百 MB 的 pcap 大概会膨胀到 2 到 3 倍内存占用所以我在实际复现时改成迭代式逐包读取用 PcapReader 配合 for 循环能省掉约 40% 的内存峰值。特征提取函数 extract_features 里面会计算每个 flow 的包数量、平均包长、持续时间、TLS 版本分布等——这些具体的特征字段就是整个项目最核心的资产部分。2.3 特征工程是决定模型上限的那道坎项目文档里专门强调了一句话特征工程的好坏基本决定了模型的质量上限我非常认同。流量检测不像图像识别可以直接喂像素原始包是二进制模型不认识你要把一组包变成一组数字向量。这个平台选的特征大概分成三类流统计特征流持续时间、包长均值与方差、上下行包比例、SYN 与 ACK 数量比。加密恶意流量往往存在长时间连接、小包多发或上下行失衡的现象这些特征能把 Tor、加密代理隧道和普通 HTTPS 区分开。TLS 握手特征证书长度、加密套件数量、SNI 是否存在、TLS 版本。恶意加密流量经常用自签名证书或固定加密套件组合和正常浏览器请求有明显差异。时间序列特征包到达间隔的均值与标准差。恶意程序的信标行为通常有固定的心跳间隔会出现周期性脉冲。def extract_features(flow_key, packets): features {} features[flow_duration] packets[-1].time - packets[0].time features[packet_len_mean] np.mean([len(p) for p in packets]) features[packet_len_std] np.std([len(p) for p in packets]) features[uplink_ratio] calc_uplink_ratio(packets) features[tcp_syn_ack_ratio] calc_syn_ack_ratio(packets) features[tls_version] detect_tls_version(packets) features[periodic_gap_mean] calc_gap_mean(packets) return featuresfeaturize 完的数据会存成 CSV每一行对应一个 flow一列是一个特征。这里要注意一个细节提取的特征必须是协议无关的数据——你不能假设所有样本都有完整 TLS 握手万一遇到裸 TCP 流量就得靠包长和方向比例兜底。实际做下来我发现一个 10 万包的 pcap提完特征之后大概得到 3000 到 5000 条 flow 记录这个体量喂给 sklearn 模型刚刚好。把特征工程这一步想清楚后面训练才会有意义。模型再怎么调参也只是在拟合特征特征差模型再好也白搭这是血泪经验。3. 模型层SVM、随机森林与集成学习的选型边界与 model.pkl 用法3.1 为什么不是深度模型业务场景决定的有些平台上来就搞深度学习但这个项目没有原因是安全和攻防系统讲究可维护性和可解释性你用随机森林提出一个特征重要性排序可以直接告诉运维人员“这个流量异常是因为 TLS 握手间隔出现强周期性”这些话深度网络说不出来。从平台源码来看train_test 目录下同时存在多个算法的训练脚本其中 SVM、随机森林、以及基于 Bagging 的集成模型是三条主线它们的落地场景差异很大。SVM 适合小样本和高维稀疏特征泛化能力强但可视化困难在线更新模型不方便。随机森林天生带特征重要性排序训练快、抗过拟合但外推能力弱——训练集没出现过的攻击形态它可能识别不了。集成学习则适合在两者中间做一个平衡通过对多棵决策树的结果做投票既保留了解释性也提高了对未知流量模式的鲁棒性。模型可解释性训练速度适合场景主要风险SVM弱中小样本、高维参数对结果影响大随机森林强快特征重要性分析外推能力弱集成学习(Bagging)较强较慢大样本多分类模型体积大从项目目录里的 model.pkl 来看最终选用的是集成模型因为它的综合表现在三个模型里最稳。如果你把 model.pkl 反序列化之后打印它的类型会发现是一个 VotingClassifier 或者 BaggingClassifier 的实例内部还嵌套了多棵决策树。3.2 训练与测试脚本的完整流程train_test 目录下的脚本遵循一套标准流程加载 CSV 特征数据、切分训练集与测试集、标准化、训练模型、输出 accuracy 与混淆矩阵。加密流量检测本质上是一个二分类问题——恶意还是正常——但项目扩展成了三分类正常、恶意加密流量、可疑流量。这个设计我认为很聪明它不让模型给出绝对判断而是留了一个人工复核的缓冲区域。import pandas as pd from sklearn.model_selection import train_test_split from sklearn.ensemble import RandomForestClassifier from sklearn.preprocessing import StandardScaler df pd.read_csv(features.csv) X df.drop(label, axis1) y df[label] X_train, X_test, y_train, y_test train_test_split(X, y, test_size0.3, random_state42) # 标准化SVM 这类距离类算法必须做 scaler StandardScaler().fit(X_train) X_train_scaled scaler.transform(X_train) X_test_scaled scaler.transform(X_test) model RandomForestClassifier(n_estimators300, max_depth12, random_state42) model.fit(X_train_scaled, y_train) print(Test acc:, model.score(X_test_scaled, y_test))我一般会用 7:3 切分并且保持 stratifyy 保证各类别比例一致。这里有个隐藏坑test_size0.3 的数据量太少的话准确率可能在 95% 上下跳动很大我一开始只给了 0.2跑出来 92% 到 98% 都有后来改成 0.3 加固定 random_state结果才稳定下来。3.3 加载 model.pkl推理阶段的正确姿势训练结束后模型通过 joblib.dump 落盘web 端运行时直接 joblib.load 加载。这里有一个很容易踩的版本坑如果你本机 sklearn 版本与训练时不兼容load 会直接抛 ModuleNotFoundError 或者 AttributeError。import joblib model joblib.load(model.pkl) def predict_flow(features_dict): df pd.DataFrame([features_dict]) # 注意训练时已经做过标准化推理阶段要复用同一个 scaler df_scaled scaler.transform(df) pred model.predict(df_scaled)[0] prob model.predict_proba(df_scaled)[0] return pred, prob推理的时候必须复用训练时的同一个 StandardScaler 实例不能重新 fit——否则你是在拿另一套坐标系做预测结果会很玄学。我见过有人直接把 StandardScaler 也存成 scaler.pkl这是最稳的做法。3.4 模型效果怎么看别只盯着 accuracy加密流量检测里正负样本通常不平衡攻击流量占比可能不到 20%。这时候 accuracy 参考价值很有限重点要关注召回率——漏报一个恶意连接比误报十个正常连接更严重。项目的测试脚本里我看到了 confusion_matrix 的输出并且在 ImageForReadme 目录下的 PtSc 系列截图里能看到模型在测试集上的表现曲线。判断一个特征到底有没有用可以直接看随机森林的 feature_importances_ 属性。我在实验里发现“包到达间隔的周期性”这个特征的重要性排名远高于“TLS 版本”因为大量良性 TLS 流量也集中在 1.2 和 1.3仅靠版本没法区分但恶意心跳的间隔模式很难伪造。4. Flask 平台上传、解析、预测与监测界面的完整链路4.1 web_platform 的目录结构与运行方式web_platform 是流量检测的落地界面它不是一个花哨的可视化大屏而是聚焦在一个核心业务闭环上传 pcap 文件、后台解析成 flow、调用 model.pkl 预测、把结果回显到页面。这个架构很小但每个环节都不缺。目录下主要文件包括 app.py、templates/index.html、以及负责后台解析的 analyzer.py。启动方式就是标准的 Flask 开发服务器python app.py --port 5000启动之后浏览器访问 127.0.0.1:5000页面上会有一个文件上传框支持 .pcap 和 .pcapng 格式。我在老旧的 2GB 内存笔记本上跑过一次 200MB 的 pcap解析加预测大概是 40 秒其中 90% 时间花在特征提取上模型推理几乎是瞬时的。4.2 后端解析把 pcap 变成模型能认的格式app.py 里最核心的上传路由逻辑并不复杂app.route(/upload, methods[POST]) def upload_file(): file request.files[pcap_file] filepath os.path.join(UPLOAD_DIR, secure_filename(file.filename)) file.save(filepath) flows parse_pcap(filepath) df featurize_flows(flows) preds, probs batch_predict(df) return render_template(result.html, predictionspreds, chartgenerate_piechart(preds))batch_predict 内部对 DataFrame 做了一次批量预测而不是一条条循环调用 predict 接口。这样可以大幅提升效率而且也能顺便统计出三条类别的分布比例。平台界面上的 PieChart.png 就是预测结果的可视化——哪一类流量占了多少管理员扫一眼就能判断当前的 pcap 文件正常与否。4.3 前端回显与本地验证templates 目录下的 HTML 模板用了最原生的 Bootstrap没有引入重型前端框架。结果页展示了每个 flow 的五元组、预测标签和置信度置信度低于 0.6 的记录会被单独标记成黄色提示需要人工复核。这个阈值写在 app.py 顶部常量里是可以直接改的SUSPICIOUS_THRESHOLD 0.6 # 低于此置信度标记为可疑我建议第一次跑通之后把这个阈值调到 0.5 对比一下输出差异能直观感受到置信度阈值对最终告警数量的影响。如果是拿来做演示建议不要改0.6 出来的告警列表看起来更紧凑也更可信。4.4 log.txt 里藏着什么排查问题的最快入口项目根目录下的 log.txt 不是摆设它记录了每一次上传解析的关键时间点接收到文件的时间、解析开始结束时间、提取到多少条 flow、模型预测耗时多少。我第一次跑通后看这个日志发现 80% 的时间都消耗在 line 21 的 parse_pcap 上这直接帮助我定位到是 rdpcap 读大文件太慢的问题——后来换成 PcapReader 才解决。如果你复现时发现页面一直转圈先看 log.txt 最后几行判断是卡在解析还是卡在预测比盲改代码高效得多。5. 避坑指南加密流量分析里的五个常见翻车点5.1 特征变成了一堆常量现象训练出来的模型准确率 99%但拿真实流量一测全乱套。 原因特征提取代码里写死了某些字段比如所有训练样本都有 TCP payload但真实环境中大量 TCP 握手包 payload 长度为 0于是模型学到了“有 payload 就是恶意”这个假规则。 解决每次提取特征后立刻跑一次 value_counts检查每一列是否存在单值特征。发现标准差为 0 的特征直接删掉它们对模型只有干扰。5.2 训练集和测试集时间跨度重叠现象测试准确率极高上线后急剧下降。 原因数据划分时随机切割同一个攻击者的不同 pcap 片段同时进了训练集和测试集模型等于开卷考试。 解决按时间切片切分数据前 60% 训练后 40% 测试禁止随机切分。这是时间序列数据的黄金法则流量数据尤其敏感。5.3 model.pkl 加载失败报 AttributeError现象web 平台启动时直接 500日志显示 module sklearn has no attribute ...。 原因训练环境和部署环境 sklearn 版本不一致pickle 里保存的类定义找不到了。 解决训练时固定虚拟环境版本并且用 joblib.dump 而不是 pickle.dump。部署前先写一行脚本加载 model.pkl 做冒烟测试别等 web 端跑起来才发现挂。5.4 Scapy sniff 丢包严重现象采集到的正常流量里 packet 数量远小于预期flow 数量稀疏。 原因sniff 默认单线程处理包回调回调里如果做了聚合运算处理速度跟不上抓包速度内核缓冲区溢出丢包。 解决抓包和 processing 分离——sniff 只负责存 raw packet 到内存列表所有特征提取放到抓完之后的循环里执行。如果流量超过 100Mbps考虑用 tcpdump 在外层抓包Scapy 只做离线解析。5.5 置信度阈值设错告警要么刷屏要么静默现象第一次跑平台恶意流量检测出上百条告警大部分是误报。 原因默认阈值 0.5 对二分类模型太宽松概率 0.51 就会被判为恶意。 解决每次换模型后重新扫描一遍验证集上的置信度分布取恶意样本概率的最低值作为新阈值。我在这个项目里最终用了 0.6误报率直接降了 70%。6. 验证模型会不会被骗模拟加密通道的回归脚本模型做完不等于事情就完了还要走一遍验证流程。我自己习惯做的一个技巧是用 Scapy 构造一个模拟加密通道的流量样本手工注入几条心跳间隔固定的“恶意”流拿去跑平台的 web 端看模型能不能抓出来。from scapy.all import * import time base_time time.time() fake_flows [] for i in range(50): pkt IP(src10.0.0.1, dst10.0.0.2) / TCP(sport12345, dport443) / Raw(b\x16\x03\x01 b\x00 * 100) pkt.time base_time i * 10 # 固定 10 秒心跳间隔 fake_flows.append(pkt) wrpcap(fake_malicious.pcap, fake_flows)把这 50 条包文件上传到平台的 web 界面如果 model.pkl 抓出了其中八成以上的异常流说明平台的模型对于时间周期性特征是有感知的如果全部漏掉那就要回头检查特征工程里 time gap 相关字段是否真的提取成功了。这个小数据集不用太大50 条就够了它是一个验证特征和模型链路是否完整的快速回归手段。我第一次跑这个测试的时候抓了个正着模型只检出 20% 的样本排查后发现问题出在时间特征没有归一化模型对绝对时间戳太敏感而对间隔长度不敏感。从那以后我每次改完特征提取代码都会先跑一遍这个假流量脚本再进训练流程强制自己走一遍验证闭环再去动 web 平台的代码。这个习惯帮我省掉了无数个和“模型玄学”纠缠的深夜。说白了这套加密恶意流量检测平台的价值不在于模型多高级而在于它的完整度——采集、解析、特征、训练、部署、验证一条链路都有代码支撑你改任何一个环节都能看到对最终结果的影响从学习角度这是很难得的。希望帮到你。本文还有配套的精品资源点击获取