简介基于客户端蜜罐与机器学习的风险网站检测系统是一份覆盖前端展示、后端逻辑、模型训练与预测的完整工程资源适合用于毕业设计、课程设计、工程实训、大作业及学科竞赛等场景也可作为初期项目立项和扩展开发的基础。资源共155个文件压缩包约63.8MB主要以Python源码、JavaScript脚本、配置文件、样式文件及日志记录为主其中Python文件承担检测模型与算法流程JavaScript文件对应前端交互与可视化展示目录结构清晰便于按模块检索。设计报告与说明文档一并提供可帮助理解整体架构、关键步骤与检测思路进而复现或改造出相似的风险网站检测方案。已有45人浏览学习项目经过测试运行功能可用适合在此基础上做功能扩展或借鉴其设计完成课程与竞赛任务。1. 先看它为什么值得复现客户端蜜罐与机器学习如何兜住漏网风险站黑名单URL拦截这种被动方式在0day钓鱼站面前基本是“事后补救”等威胁情报中心收录入库最早一批受害者早已提交了账号密码。我拿到这份“基于客户端蜜罐和机器学习的风险网站检测系统”时最直接的感觉就是它把一个课程设计级别的课题做成了真正能跑通的反钓鱼检测链路用客户端蜜罐主动访问可疑站点并采集行为特征再交给机器学习模型判断“这到底是不是风险网站”。它不只是代码堆出来的演示工程也适合毕设、课设、大作业和竞赛选型——一个课题同时覆盖了爬虫、安全检测、数据处理和模型评估四个方向横向对比同类选题比如纯静态漏洞扫描、域名黑名单分析它更容易撑起论文的创新点和工作量这也是我当初愿意拆它的原因。下面我按照源码包的架构拆解每一层的实现细节和排查过程。2. 客户端蜜罐采集层不是普通爬虫是带行为诱捕的访问器2.1 客户端蜜罐的定位无头浏览器与交互触发客户端蜜罐和传统服务端蜜罐的本质区别在于服务端蜜罐被动等攻击者来打客户端蜜罐主动去“访问”潜在恶意页面模拟真实用户行为让恶意脚本主动暴露出攻击意图。这个系统里对应的角色是一个基于Selenium的Chrome无头采集器它能完整执行页面上的JavaScript、加载iframe、触发onclick事件从而捕获服务端响应里看不到的“动态行为”。这套设计能解决黑名单检测覆盖不到的盲区恶意网站为了躲避爬虫经常把恶意代码藏在JS里等到浏览器加载完整页面、执行特定事件后才落地。采集器通过模拟滚动和点击可以把这些隐藏分支诱导出来。我一般会先在一个隔离的Linux虚机里跑采集器避免本机环境变量注入干扰浏览器渲染。2.2 采集任务队列与页面渲染控制整个蜜罐采集不是简单的单页抓取而是围绕“队列—渲染—取证—入库”四个环节展开。源码中对应的核心调度逻辑大致长这样# collector/scheduler.py def run_task(url): # 初始化带有反检测参数的Chrome选项 options webdriver.ChromeOptions() options.add_argument(--headless) options.add_argument(--disable-gpu) options.add_argument(--no-sandbox) # 设置页面加载超时避免恶意页面拖垮事件循环 options.add_argument(--page-load-timeout15000) driver webdriver.Chrome(optionsoptions) try: driver.get(url) # 等待首屏渲染完成给JS注入争取时间 WebDriverWait(driver, 10).until( lambda d: d.execute_script(return document.readyState) complete ) # 模拟用户滚动和点击触发延迟加载的恶意逻辑 for _ in range(3): driver.execute_script(window.scrollBy(0, 200)) time.sleep(0.5) # 收集页面证据DOM快照、请求记录、JS报错 page_source driver.page_source logs driver.get_log(browser) urls [item[url] for item in driver.get_log(performance)] # 常见的写法是抓performance日志 finally: driver.quit()这里有几个参数需要按照实际环境调整page-load-timeout15000指的是单页加载超时上限恶意页面经常故意挂起请求来拖慢采集器这里设成15秒是兼顾效率和稳定性的折中值滚动次数3次不是越高越好有些反爬脚本会统计页面滚动次数超过阈值反而返回验证码。采集结果不能直接送进模型需要先做字段规整。比如performance日志在不同Chrome版本里结构不一致需要统一抽取出requestWillBeSent事件里的URL字段再过滤掉浏览器内置扩展产生的噪音请求。这一步不做好后面特征提取会拿到一堆空值和脏数据。2.3 前端的价值管理后台不是摆设是数据标注平台源码包里出现了chunk-vendors、app.8cdbebd5.css这类文件构建产物对应一个Vue管理后台。这个后台的实际作用不只是展示检测结果——它在整个闭环里承担了两个关键职责一是白名单/黑名单的维护入口二是人工复核结果的数据标注平台。模型预测出来的“风险”不能直接封禁必须由运营人员看截图和DOM快照做二次确认。我第一次看到这个设计觉得有点重但实际使用中发现它很必要。纯自动化的ML检测在测试集上可以做到很高的准确率但真实流量里总有“伪装得过分正常”的钓鱼站。人工复核的结果会写回数据库作为增量数据定期重训模型这个反馈闭环比模型调参带来的收益更稳定。前端构建产物是静态文件部署时直接丢到Nginx的/var/www/html目录即可后端接口如果不在同域需要配置反向代理。毕设演示时可以先跑前端静态页再启动采集器和训练脚本三个进程像完整产品一样联动答辩效果比单纯跑一个Jupyter Notebook有说服力得多。3. 特征工程与数据清洗机器学习环节八成的调试时间花在这三步3.1 从原始页面到特征向量该提哪些特征热搜词里“机器学习中的数据处理”被频繁检索不是没道理——在这个项目里从蜜罐采集回来的DOM快照和请求日志是不能直接塞进模型的。原始数据是文本和嵌套结构而分类器需要的是定长数值向量。系统源码里特征提取得比较克制没有堆上百个特征而是围绕三条线索提取每条线索都对应一类攻击指纹。URL特征URL长度、是否包含IP地址、子域名层级数、特殊字符占比、TLD是不是常用后缀页面特征敏感关键词命中数、iframe标签数量、表单提交动作数量、页面中外部链接的同域比例证书特征SSL证书有效期剩余天数、签发组织名称长度、是否为自签名证书。这套特征设计来自一个朴素的观察——钓鱼站是低成本批量化部署的证书和URL细节一定会暴露出自动化痕迹。特征提取的核心代码大致如下# features/extractor.py def extract_url_features(url): parsed urllib.parse.urlparse(url) hostname parsed.hostname or return { url_length: len(url), is_ip: 1 if re.match(r^\d\.\d\.\d\.\d$, hostname) else 0, subdomain_depth: len(hostname.split(.)) - 2, entropy: calculate_entropy(hostname), # 域名字符熵随机域名熵值偏高 uses_https: 1 if parsed.scheme https else 0, } def extract_page_features(page_source): soup BeautifulSoup(page_source, html.parser) iframes soup.find_all(iframe) forms soup.find_all(form) external_links [a for a in soup.find_all(a, hrefTrue) if urlparse(a[href]).netloc] keywords [passport, verify, login, account, security] hit_count sum(1 for kw in keywords if kw in page_source.lower()) return { iframe_count: len(iframes), form_count: len(forms), external_ratio: len(external_links) / max(len(soup.find_all(a)), 1), keyword_hits: hit_count, }关键字选择这里需要解释一下passport、verify、security这类词是仿冒页复用模板时的高频残留它们本身不是恶意标识但组合出现时风险概率显著上升。external_ratio取的是外部链接在总链接中的占比钓鱼页为了把用户引向攻击者服务器外链占比通常异常高。3.2 清洗与编码缺失值、离散值、归一化的处理顺序特征提完后数据表里通常存在三类问题有的字段因为页面加载失败是空值有的字段比如协议类型、是否使用HTTPS是类别型有的连续特征量纲差异巨大。处理顺序错了后面全部白干。先说缺失值。在检测场景里证书字段缺失本身就是一种风险信号——真实站点几乎不会没有SSL证书。如果直接用均值填充等于把风险信息洗掉了所以我习惯保留一个独立的cert_missing标志位然后再做均值填充。这样模型能学到“缺失即可疑”的规律。离散特征要区分对待。二值特征是否使用HTTPS、是否IP直连直接保留0/1多值类别特征TLD类型、证书签发商可以用LabelEncoder映射为整数但要注意类别数量如果超过20个LabelEncoder的效果不如One-Hot实际。这个系统里TLD类型偏少直接LabelEncoder足够用。连续特征统一做Z-Score归一化处理前后的对比可以作为答辩素材归一化前随机森林的feature importance会被URL长度这种大数特征主导归一化后各特征的重要性分布才合理。这一步也直接对得上“机器学习中的数据处理”这个核心关注点。工程实现上存储建议直接拼一个DataFrame落CSV字段顺序固定下来后面训练和预测共用同一套feature_order避免漏字段导致模型报错。# dataset/process.py import pandas as pd from sklearn.preprocessing import StandardScaler df pd.read_csv(raw_features.csv) # 证书缺失标记单独成列 df[cert_missing] df[cert_days_remaining].isna().astype(int) # 连续列填充均值再标准化 df[cert_days_remaining] df[cert_days_remaining].fillna(0) scaler StandardScaler() num_cols [url_length, entropy, external_ratio, cert_days_remaining] df[[std_ c for c in num_cols]] scaler.fit_transform(df[num_cols])3.3 样本不均衡风险样本太少模型全预测“安全”怎么办风险网站样本采集本身就是少样本场景蜜罐跑一天可能抓到几十个恶意样本正常样本却有几千条。如果直接拿原始比例训练模型会学成“永远输出安全”因为这样准确率也有95%以上。这个坑几乎每个做这个方向的人都会踩一次。源码里采用了两个策略的叠加一是SMOTE过采样先生成少数类合成样本避免简单复制导致的过拟合二是在模型里设置class_weightbalanced让算法自动加大少数类的惩罚系数。两个策略同时用控制过采样倍率在1到2之间不要试图完全抹平类别差距。4. 模型训练与阈值选择逻辑回归到XGBoost的纵向对比与关键调参4.1 为什么不用线性回归二分类场景的损失函数陷阱不少课程设计拿到这份资源后第一反应是拿线性回归来做分类这其实是个经典误区。线性回归的因变量是连续值模型训练时优化的误差会让输出落在0和1之外预测结果变成0.3、0.7这种没有概率意义的数值。在“机器学习线性回归实验”里这样处理没问题但在风险检测场景里我们不仅需要分类结果还需要给人工复核提供置信度排序这只有逻辑回归这类概率模型才做得到。逻辑回归虽然同样学习特征与目标之间的线性关系但它通过sigmoid函数把输出压缩到(0,1)区间并配合交叉熵损失函数优化输出的数值可以解释为风险概率。4.2 三个模型的横向对比与参数网格这个系统的模型模块同时实现了逻辑回归、随机森林和XGBoost目的就是做对比实验。三个模型各有侧重逻辑回归适合当基线训练快、可解释性好能在答辩时展示特征权重和方向性随机森林对特征之间的非线性关系更敏感抗过拟合能力强适合在特征数量不多的情况下把准确率往上推一截XGBoost在三个模型里效果通常最好但对异常值和参数更敏感应用时容易泛化波动。训练和对比的代码逻辑大致如下# model/train.py from sklearn.linear_model import LogisticRegression from sklearn.ensemble import RandomForestClassifier from xgboost import XGBClassifier from sklearn.model_selection import train_test_split, GridSearchCV X df[feature_cols].values y df[label].values X_train, X_test, y_train, y_test train_test_split(X, y, test_size0.2, stratifyy, random_state42) # 逻辑回归基线C值控制正则化强度越小越保守 lr LogisticRegression(C0.5, max_iter500, class_weightbalanced) lr.fit(X_train, y_train) # 随机森林调参n_estimators 和 max_depth 是主要矛盾 rf RandomForestClassifier(n_estimators200, max_depth10, min_samples_leaf4, class_weightbalanced) rf.fit(X_train, y_train) xgb XGBClassifier(n_estimators150, max_depth4, learning_rate0.1) xgb.fit(X_train, y_train, sample_weightNone)参数上我的经验是逻辑回归的C不要小于0.1否则正则化过强会把少数类的信号也压掉检测会偏低随机森林的min_samples_leaf设置为4到8比默认值更稳钓鱼特征噪声大太细的叶子往往是在记住单次采集的错误数据XGBoost的max_depth不要超过6这类表格型特征深了必过拟合。模型的最终效果评估不只看准确率更要看召回率风险网站漏掉一个可能几十个用户就中招了。多数时候系统把阈值调到0.35附近让召回率保持在90%以上付出的代价是正常站点的误报率会上升但结合人工复核机制这个代价可控。4.3 阈值回调与置信度排序的实际操作模型输出的概率值需要二次处理才适合业务。系统把predict_proba结果存入risk_score字段并且额外用一个risk_level字段区分三个档位高分档0.75直接进封禁流程中分档0.35到0.75进人工复核队列低分档0.35放行。分档比一刀切更符合实际运营习惯也降低了人工复核的压力。我之前帮一个做反钓鱼的朋友调过这套系统把阈值从0.5调到0.35后有效检出多了一倍但复核队列也多了不少正常站点。后来给他加了一个“白名单优先”规则——历史已确认的安全域名直接跳过检测精准度和召回率才同时稳住。这个组合建议如果写进答辩的“系统优化”部分比单纯贴模型指标更有说服力。5. 避坑指南五个让复现翻车的高频问题与排查路径5.1 现象无头浏览器打开页面后拿到的DOM是空的/跳转验证码原因反爬脚本检测到window.navigator.webdriver属性为true直接返回了一个空壳页面或人机验证页面采集器拿到的不是真实页面内容特征全部异常。有些页面还会针对无Chrome版本的UA返回兼容模式页面。解决给ChromeOptions加上--disable-blink-featuresAutomationControlled并用execute_cdp_cmd在页面加载前清除webdriver标记。如果页面仍然弹验证码用session级UA伪装设置成与系统匹配的Chrome版本UA。5.2 现象蜜罐跑完一个批次特征文件里cert相关字段全是NaN原因网站没有启用HTTPS采集器没有拿到证书信息而代码里用rfc5280解析证书时遇到解析异常直接返回空。如果此时直接dropna整个数据集会丢掉一大部分高风险样本。解决把证书解析失败映射为cert_missing1同时用cert_days_remaining-1参与建模。特征提取阶段这类字段的开采逻辑要在预处理脚本里优先于缺失值填充执行。5.3 现象模型准确率90%但实际检测时漏报率特别高原因训练集和测试集都来自同一个蜜罐采集批次样本分布过于相似。实际环境里风险站点的特征漂移明显导致模型在“新样本”上表现下降。解决训练时用时间切分代替随机切分前70%时间的数据作训练集后30%作验证集。这比random_split更贴近真实场景。5.4 现象Vue管理后台能打开但页面列表一直转圈原因前端调后端接口的baseURL写的是localhost:8080后端实际跑在别的主机上或数据库没建表接口直接500。两个问题症状一样都是请求失败。解决先看浏览器Network面板的请求报错码——404是URL配置问题500是服务端或数据库问题。前端构建时把VUE_APP_API_BASE设置成实际后端地址重新打包即可。5.5 现象ClamAV的daily.cvd文件提示过期检测时报错原因源码包里自带的病毒库文件是打包当天的ClamAV有严格的库时效校验版本太旧会拒绝工作。解决部署后跑一次freshclam -u clamav手动更新之后加cron任务每天凌晨自动更新。daily.cvd这类增量库更新频率很高不做定时任务过几天就会再次失效。6. 落地验证与效果检查回测脚本与增量更新的具体流程系统跑通后最值得做的验证不是看训练集准确率而是做一次“时间回测”——用上个月采集的数据去验证当前模型。因为真实的威胁样本演变很快过去一个月就能让一个模型的ROC曲线明显退化。我会写一个独立的回测脚本加载最新采集数据与当前模型预测结果做对比重点看召回率有没有下降三五个点。如果出现退化就把新增的已确认样本加入训练集用增量学习方式重训而不是从零开始。验证阶段还需要检查误报样本。误报通常来自两类一是短链接跳转服务本身短链是安全的但因为跳转到高危站被误判二是内容中包含大量“login”“account”关键词但实际安全的页面比如正规邮箱登录页。处理办法是给这两类站点单独加白名单规则或把对应特征排除出模型。实际落地时我把每日新样本的标注审核时间固定为20分钟积累一周后统一重训模型再跑一次回测验证。系统还要做预测效果的实时监控——每1000次预测里随机抽50条请求记录做人工复看记录误报和漏报。这个环节是为了防止模型在不经意间出现“静默失效”。我拆过太多检测系统最大的共性问题不是上线时效果不好而是运行三个月后没人发现模型已经烂掉了。关于后续扩展这套系统预留了很好的改造空间。除了现在的三个模型这个课题还能把检测粒度从URL级别升级到页面行为序列级别用滑动窗口把用户交互行为串起来喂给RNN或Transformer也可以把客户端蜜罐采集到的定时器、事件监听器信息转成行为图做异常分检测。最后说一个我自己的习惯每次拿到类似源码包我先不急着跑训练第一步一定是检查数据文件里的正负样本数量比和特征完整度用代码统计完发现指标不对就果断停止训练先回溯数据。宁可数据层多花半小时也不要让模型在脏数据上进行无意义收敛。这套项目里也藏着类似的数据净化模块你先把它摸清后面的每一步都会顺很多。希望这次拆解过程也能帮你少走一些弯路。本文还有配套的精品资源点击获取
