基于机器学习的Web攻击检测：特征工程与模型调优实战

简介面向毕业设计及课程设计场景这套完整项目基于机器学习实现Web攻击检测融合网络流量分析与特征工程适合计算机、电子信息、数学等专业学生作为实战案例参考。压缩包内含69个文件以Python源码py/pyc为主辅以模型权重pkl/pb/h5、训练数据csv/pcap、环境配置yml与说明文档txt/md整体大小26.55MB目录结构按AiWaf-1、AiWaf-2等模块划分便于按步骤研习。项目覆盖数据采集、特征提取、模型训练到系统部署的完整链路代码结构清晰预训练模型与测试样本均已包含可直接复现用于网络异常检测和入侵识别的实验。目前已有52人学习对于希望深入理解机器学习在安全领域应用的学生而言是一份兼顾原理与实操的完整参考资料。此外附带环境依赖文件可快速重建运行环境减少搭建成本。1. 基于机器学习做 Web 攻击检测从数据到模型的一次完整闭环这套资源不是那种只能跑通一个 demo 的玩具包拆开以后你会发现它是按一个完整毕设工作量组织的。里面分别有 AiWaf-1 和 AiWaf-2 两套工程都是围绕同一个目标——用机器学习做 web 攻击检测把 HTTP 请求数据变成可训练的样本再交给分类器识别 SQL 注入、XSS 这类常见攻击。做毕设或者课设最怕的不是算法难而是数据格式混乱、模型验证不规范、文档和代码对不上这套资源恰好把 data、model、code、说明文档拆得清清楚楚。适合计算机科学与技术、网络安全、电子信息工程、数学等专业的学生做毕业设计或课程设计参考也适合想快速上手机器学习在安全领域落地的新手。我按“环境复现 → 特征工程 → 模型训练 → 避坑调优”这条线带你过一遍你会发现它值得下下来当脚手架用。2. 拆开 zip 看结构AiWaf-1 与 AiWaf-2 两套工程的目录和依赖环境拿到压缩包第一步不是急着跑代码而是先把目录读明白。这套资源里最显眼的是两个平级工程目录 AiWaf-1 和 AiWaf-2首次打开容易懵到底用哪个我的判断是这是同一作者在项目不同阶段留下的迭代版本AiWaf-1 更偏向早期探索AiWaf-2 结构更完整、还多了 environment.yml 环境锁定文件。对于毕设和课设来说这反而是好事两套工程可以互相印证也能看出同一个功能在不同阶段的设计取舍。2.1 目录解读为什么一个项目要做两套先看 AiWaf-1 的目录构成目录/文件在项目中的角色code数据处理、特征构建、模型训练相关脚本data原始数据集或预处理后的样本数据model训练产出的模型文件image效果截图、可视化图表README.md项目说明文档Readme.txt补充说明或早期版本记录AiWaf-2 的目录则是把 image 换成了 images新增了 environment.yml其余结构保持一致。从命名习惯来看AiWaf 是 AI WAF 的组合即“基于人工智能的 Web 应用防火墙”整套系统的定位是替代或辅助传统规则型 WAF 的检测模块用机器学习判断一个 HTTP 请求是正常访问还是攻击载荷。早期版本里 Readme.txt 和 README.md 同时存在这种情况在真实项目里很常见README.md 是给别人看的正式说明Readme.txt 是作者随手记的要点。如果你发现两个文件内容有出入以 README.md 为准txt 里可能有作者自己的调试备注那部分反而是宝贵的背景信息。2.2 先把 conda 环境跑通environment.yml 怎么用AiWaf-2 目录下的 environment.yml 是整个项目能复现的前置条件。这个文件记录了 Python 版本和所有第三方库的版本约束用 conda 把这些依赖一次性装齐比手动 pip 安装省心得多尤其是 numpy、scipy、scikit-learn 这类底层库conda 会帮你处理二进制依赖冲突。conda env create -f environment.yml执行这条命令的前提是你已经在 AiWaf-2 目录下或者命令里写全路径。如果只是把 environment.yml 拷贝到别的目录再执行conda 会提示找不到文件。装完环境后激活并验证依赖是否正常conda activate aiwaf python -c import sklearn, pandas, numpy; print(sklearn.__version__, pandas.__version__)参数说明conda env create -f中的-f指定环境配置文件conda activate aiwaf中的 aiwaf 是在 environment.yml 里定义的name字段实际名称要以文件里的name:行为准不固定。如果安装过程中因为 conda 默认 channel 找不到某些包加上-c conda-forge重试conda env create -f environment.yml -c conda-forge依赖装好后不要急着跑训练先检查一下 code 目录下的脚本命名习惯。一般这类项目会把脚本按阶段编号比如 1_data_clean.py、2_feature_engineer.py、3_train_model.py或者拆成多个模块文件按 import 顺序执行。先花十分钟读 README.md再按编号顺序过一遍 code整个项目的执行主线就清楚了。2.3 从 data、model、code 三个目录读项目主线项目主线其实非常好找就是一条数据流水线data 是输入model 是输出code 是把 data 变成 model 的过程。data 目录决定你能训练出什么模型code 目录决定模型训练方式是否合理model 目录只是最终产物。先看 data 里有什么。以 Web 攻击检测这个场景来说常见的数据组织方式是每行一个 HTTP 请求列包括请求方法、URL、请求头、请求体最后一列是标签normal、sqli、xss 等也可能用 0/1 表示正常与攻击。如果你看到的 CSV 里只有特征列没有原始请求说明作者已经把特征工程做完并导出了中间结果那你就要在 code 里找对应的特征构建脚本确认特征定义和计算方式。再对比 AiWaf-1 和 AiWaf-2 的 data 目录如果两个目录的数据量或文件结构不一样很可能是数据集升级了或者标签重新处理了。这一点在毕设论文里非常值得写你对比了两版数据的差异分析了迭代前后模型的指标变化这就是一个完整的工作量叙述。model 目录里的模型文件建议先不要急着 load。原因在后文避坑章节会详细说这里先记住一个原则模型文件只能证明作者当时训出来的结果它依赖特定版本的 Python 和 sklearn换环境很可能加载失败。真正属于你自己的工作量是把 data 和 code 跑通重新训练出结果。所以复现顺序永远是先环境再数据再代码最后才轮到 model。3. 特征工程这一步把原始请求转成机器学习能理解的数字特征很多人拿到这类项目后第一个卡点不是模型而是不知道网络请求怎么变成特征矩阵。机器学习模型的输入必须是数值向量但 HTTP 请求是文本和协议结构的混合体。特征工程的目标就是把 URL、请求方法、参数这些原始信息拆成离散或连续的特征让攻击行为和正常请求在特征空间里能分开。3.1 Web 攻击检测的特征从哪里来Web 攻击检测的特征没有标准答案但常用的特征基本可以分四类请求行特征请求方法GET/POST/PUT 等做 one-hot 编码URL 总长度、路径层级数。攻击者要在 URL 里塞 payloadURL 通常比正常请求长路径层级也可能异常。字符统计特征字母数量、数字数量、特殊字符占比、大小写混合程度。SQL 注入和 XSS 的 payload 里经常出现大量特殊符号比如单引号、尖括号、百分号、分号这些字符在正常 URL 里的出现频率很低。语法特征URL 中是否包含 SQL 关键字比如 select、union、sleep、information_schema是否包含 XSS 特征比如 script、alert、onerror、prompt。这类特征本质上是把传统规则引擎的检测逻辑搬进来当先验知识。结构特征参数个数、参数名长度均值、查询串是否带 URL 编码字符。%27是单引号的 URL 编码形式正常业务请求里你几乎见不到它但 SQL 注入会大量使用。这四类特征配合使用的原因很直接攻击特征可以伪装可以大小写混淆可以编码绕过但请求长度分布、字符统计这些统计特征很难完全隐藏。机器学习与规则检测的区别就在于规则只抓已知的精确匹配模式机器学习则能学习到攻击行为的统计规律。3.2 标签与样本组织方式数据集里除了特征还必须有一个标签列。常见有两种组织方式一种是二分类标签就是 0 和 10 代表正常1 代表攻击另一种是多分类标签可能是 normal、sqli、xss 这样的字符串。多分类标签在训练前要转成数值最方便的做法是直接用 pandas 的 factorizeimport pandas as pd df pd.read_csv(data/requests.csv) df[label], label_names pd.factorize(df[label]) print(label_names)逻辑说明factorize 会把字符串标签映射成从 0 开始的整数同时返回标签的具体名称列表。比如 label_names 是 [normal, sqli, xss]那 0 代表 normal1 代表 sqli2 代表 xss。后面分析混淆矩阵时你需要靠这个顺序去对应类别。这里有一个容易忽略的点先检查标签分布。如果攻击样本只占 5%甚至某个攻击类别只有几十条样本你的模型很可能直接学成“全部预测为 normal”。看到标签分布失衡就要提前想好对策比如用 class_weight 或者过采样而不是等模型训完才发现指标不对。3.3 特征提取脚本一份可以直接改着用的版本下面的函数是我在类似项目里常用的特征构建方案可以直接放在 code/feature_extract.py 里根据实际数据列名调整import pandas as pd import re from urllib.parse import urlparse, parse_qs SQL_PATTERN re.compile(rselect|union|sleep|information_schema, re.I) XSS_PATTERN re.compile(rscript|alert\(|onerror|prompt\(, re.I) def build_features(df): rows [] for url, method in zip(df[url], df[method]): parsed urlparse(url) params parse_qs(parsed.query) url_len len(url) row { url_len: url_len, path_len: len(parsed.path), num_params: len(params), has_query: int(parsed.query ! ), digit_ratio: sum(c.isdigit() for c in url) / max(url_len, 1), special_char_ratio: sum(not c.isalnum() for c in url) / max(url_len, 1), sql_keyword: int(bool(SQL_PATTERN.search(url))), xss_keyword: int(bool(XSS_PATTERN.search(url))), } row[method_get] int(method.upper() GET) rows.append(row) return pd.DataFrame(rows)逻辑说明urlparse 把 URL 拆解成协议、路径、查询串等部分parse_qs 把查询串解析成参数字典参数字典的长度就是参数个数。两行正则分别匹配 SQL 和 XSS 的特征关键词命中记 1未命中记 0。字符统计部分用not c.isalnum()判断是否为特殊字符除以 URL 总长度得到占比。参数说明max(url_len, 1)的目的是防止 URL 为空时除零报错这种防御性写法在特征工程里属于基本素养。method_get 把请求方法转成哑变量只区分 GET 和非 GET因为大多数攻击 payload 出现在 GET 请求的 URL 或参数里。sql_keyword 和 xss_keyword 是手工规则特征可以捕捉强信号但单独用它们做判断容易被编码绕过所以必须和统计特征组合。生成特征后不要直接拿去训练先做一个快速健康检查feat_df build_features(df) print(feat_df.describe()) print(feat_df.isnull().sum())这一步能看出特征列有没有全零、有没有缺失值、量纲差异多大。比如 url_len 可能从几十到几千而 method_get 只有 0 和 1这种量纲差异会影响后续 SVM 这类模型。处理方法后面会讲。4. 模型选择与训练调优随机森林、SVM 与决策树的实测取舍特征矩阵准备好了下一步就是选模型。Web 攻击检测本质上是表格数据的分类问题不需要一上来就上深度神经网络。决策树、随机森林、SVM 这类经典算法在这个场景下表现稳定计算开销小而且好解释。毕设答辩时你能说清楚“为什么选这个模型”比“我用了最新模型”更有说服力。4.1 模型选型思路先看数据再看模型决策树最明显的优势是可解释性好你能把树的结构画出来直接看到模型在用什么特征做切分。但单棵决策树容易过拟合训练集上表现好测试集上掉点严重。它在项目里的定位更适合当基线或者作为分析工具去理解特征重要性。随机森林是决策树的集成通过随机抽样和特征随机选择训练多棵树最后投票输出结果。它的优势在于对高维特征、非线性关系、特征噪声都有较好的鲁棒性不需要做特别复杂的特征缩放训练完还能直接输出 feature_importances_帮你判断哪些特征贡献大。这是我在这类项目里的默认选择。SVM 在样本量不大、特征维度也适中时表现很好尤其擅长在高维空间里找分类边界。但 SVM 对特征缩放非常敏感数据不标准化的话数值范围大的特征会直接主导距离计算模型效果会莫名其妙地差。另外SVM 本质上是二分类器处理多分类要借助 OvR 或 OvO 策略训练和预测时间也会随样本量增加而明显变慢。4.2 三个模型的对比训练脚本下面的脚本把决策树、随机森林、SVM 放一起做五折交叉验证对比from sklearn.model_selection import train_test_split, cross_val_score from sklearn.tree import DecisionTreeClassifier from sklearn.ensemble import RandomForestClassifier from sklearn.svm import SVC from sklearn.pipeline import make_pipeline from sklearn.preprocessing import StandardScaler X_train, X_test, y_train, y_test train_test_split( feat_df, df[label], test_size0.25, random_state42, stratifydf[label] ) models { decision_tree: DecisionTreeClassifier(max_depth10, random_state42), random_forest: RandomForestClassifier(n_estimators200, max_depth15, n_jobs-1, random_state42), svm: make_pipeline(StandardScaler(), SVC(kernelrbf, C1.0, gammascale, probabilityTrue)), } for name, model in models.items(): scores cross_val_score(model, X_train, y_train, cv5, scoringf1_macro) print(f{name}: {scores.mean():.4f} (/- {scores.std():.4f}))逻辑说明train_test_split 的stratifydf[label]保证训练集和测试集的类别比例与原始数据一致这在攻击样本占比低时特别关键否则随机划分可能把某一类全分到测试集里。cross_val_score 的cv5表示五折交叉验证每一折轮流当验证集最后取五折均值比单次划分的结果更可靠。参数说明RandomForestClassifier 里的n_estimators200是树的棵数通常 100 到 300 之间足够继续加大收益递减而且训练变慢max_depth15限制单棵树的最大深度防止树在训练集上长到无法控制n_jobs-1让 sklearn 使用所有 CPU 核心并行训练。SVC 的C1.0是正则化参数的倒数越小对误分类的惩罚越轻模型偏差越大gammascale让算法根据特征数量自动确定 RBF 核函数的宽度是比手动指定 gamma 更稳的默认策略。从实测经验看在这个场景下随机森林的 f1_macro 值通常会明显高于单棵决策树SVM 在特征标准化之后也能接近随机森林的水平。如果发现 SVM 分数异常低先检查是不是漏了 StandardScaler这是最常见的原因。4.3 模型调参和效果观察模型跑通之后下一步是看哪些特征真的起了作用。随机森林可以直接输出特征重要性import numpy as np feat_names feat_df.columns.tolist() importances models[random_forest].feature_importances_ for name, imp in sorted(zip(feat_names, importances), keylambda x: x[1], reverseTrue): print(f{name}: {imp:.4f})观察输出时要注意一点如果 sql_keyword 和 xss_keyword 的重要性非常高而其它统计特征重要性接近零说明数据集里的攻击样本特征过于明显模型本质上是在学规则而不是学统计规律。这时候有两种处理方式一是承认这种特征组合在工程上够用毕设答辩就讲“规则先验 机器学习统计特征”的融合二是把规则特征去掉看模型能不能只靠统计特征区分攻击这样能体现你对特征工程更深的理解。训练完成后保存模型后面部署和验证要用import joblib joblib.dump(models[random_forest], model/rf_webattack.pkl)joblib 是 sklearn 官方推荐的模型持久化方式和 pickle 相比对 numpy 数组的处理更高效。这里提醒一句如果你后面发现 load 不出这个模型大概率是环境版本的坑具体原因写在下一章。5. 避坑手册训练集泄漏、样本不平衡与误报调试的实测记录这几条坑是我在类似项目里反复踩过的每一个都真实影响过最终的检测效果。写在这里是希望你不用再付一遍学费。5.1 特征泄漏归一化写在整个数据集上导致指标虚高现象交叉验证时 F1 值高得离谱接近 0.99心里还挺高兴。换一批新数据验证时立刻掉到 0.7 左右完全不是一个量级。原因标准化和归一化这类需要计算统计量的操作如果写在 train_test_split 之前对全量数据执行了 fit_transform那么测试集分布已经被训练集的均值、方差污染了。模型在交叉验证时“偷看”了测试集的统计信息这叫特征泄漏。在你自己的数据上跑一遍同样的操作指标自然回归真实水平。解决先划分训练集和测试集再单独在训练集上 fit 标准化器用这个训练好的标准化器去 transform 测试集。scaler StandardScaler().fit(X_train) X_train_scaled scaler.transform(X_train) X_test_scaled scaler.transform(X_test)同理缺失值填充、特征选择、降维这类会用到全局统计信息的操作都必须拆到划分之后分别处理。从那以后我写代码的顺序固定成了先 split再 fit再 transform。5.2 类别不平衡攻击样本不足时 accuracy 会骗人现象模型预测结果里所有请求都判成 normal准确率依然有 95%。看起来很好但 SQL 注入和 XSS 样本一条都没识别出来检测系统形同虚设。原因攻击样本在数据集中占比太低可能只有 3% 到 5%。分类器如果全部输出多数类损失函数也不会太大因为绝大多数样本本来就是 normalaccuracy 被大量正常请求撑起来了。解决不要用 accuracy 作为主要评价指标改成 f1_macro它对少数类的召回更敏感。训练时加类别权重RandomForestClassifier(n_estimators200, max_depth15, class_weightbalanced)class_weightbalanced会根据每个类别的样本数量自动反比调整权重少数类样本在损失函数里的权重放大模型不会一味倒向多数类。如果数据不平衡特别严重还可以用 imbalanced-learn 库的 SMOTE 做少数类过采样在特征空间里线性插值生成合成样本。但注意 SMOTE 也要在划分完训练测试集之后只用训练集样本生成否则同样泄漏。5.3 误报集中在带参数的正常 URL现象系统上线后用户访问/?keyword苹果、/?id1024这类带查询参数的正常页面也被标记为攻击。日志里误报样本点连成一片。原因特征设计太粗糙。num_params 大于 0、has_query 等于 1、url_len 偏长这些特征在攻击样本里确实常见但大量正常业务请求同样带参数。模型学到了“带参数即攻击”这个错误规律尤其是当数据集中带参数的正常样本数量较少时这种误判就更明显。解决回到误报样本里看特征分布把预测错的正常样本单独拉出来对比它们的特征值和攻击样本的特征值。常见做法是增加业务特征区分度比如参数名是否为敏感词、User-Agent 是否为浏览器正常值、请求路径是否在已知业务路径集合内。如果改动特征后模型 F1 下降但误报明显减少说明你的数据集里存在相似分布的攻击和正常请求这时可以调整判别阈值而不是急着改模型下一章会讲具体做法。5.4 model 文件加载失败Python 版本和依赖版本不匹配现象执行joblib.load(model/rf_webattack.pkl)时抛出 ModuleNotFoundError或者报类似于ValueError: pickle protocol was not recognized的错误。原因模型是用某个特定版本的 scikit-learn 序列化的里面记录了模型类的完整模块路径。换了环境后sklearn 的类路径变了或者 pickle 协议版本不兼容就加载不出来了。这不是你的问题是 Python 生态里常见的版本兼容问题。解决优先用 environment.yml 重建和作者一样的环境再尝试加载。如果环境重建后还是不行那就不要浪费时间折腾 pkl 文件了模型文件本来就不是项目的核心。数据、特征工程脚本、训练流程才是真正属于你的工作量。自己重新训练一个模型效果只会更好因为你对数据理解得更清楚。从实际项目角度看仓库里的 pkl 是作者留给你的“验收结果参考”不是必须复现的对象。6. 一个验证技巧用混淆矩阵和阈值调节降低误报先看混淆矩阵再做模型上线决策这是我在这个项目里养成的习惯。准确率只能告诉你整体预测对了多少而混淆矩阵能告诉你错在哪一类。from sklearn.metrics import confusion_matrix, classification_report y_pred best_model.predict(X_test) cm confusion_matrix(y_test, y_pred) print(cm)输出的矩阵里对角线是预测正确的样本非对角线是错误分类。对二分类来说右上方假正例是正常请求被误判为攻击左下方假负例是攻击被漏掉。在 Web 攻击检测场景里这两个错误的代价不同漏掉攻击意味着防线失守误报意味着正常用户体验受损。具体哪一个更不能接受要看系统部署在什么位置。多数分类器默认用 0.5 作为判别阈值但 0.5 不一定是你的最优选择。拿随机森林来说它可以输出每个样本属于攻击类别的概率这时候可以调阈值proba best_model.predict_proba(X_test)[:, 1] for threshold in [0.3, 0.4, 0.5, 0.6, 0.7]: y_pred_t (proba threshold).astype(int) print(fthreshold{threshold}) print(classification_report(y_test, y_pred_t, target_names[normal, attack]))阈值调高模型会更保守只在置信度高时判定为攻击误报率下降但攻击漏检率可能上升。阈值调低查全率上来但误报也会增多。我一般会画一条阈值与 F1 的曲线找一个误报和漏报相对平衡的位置而不是默认采用 0.5。从那以后每次更新特征集或换训练数据我都强制走一遍“重新训练 → 混淆矩阵 → 阈值扫描”的完整流程再也不敢直接信 accuracy 一个数字。希望这套验证方法能帮你在毕设答辩时把每一步都讲出依据来。本文还有配套的精品资源点击获取