基于客户端蜜罐和机器学习的风险网站检测系统

简介：面向毕业设计、课程设计与工程实训的“基于客户端蜜罐和机器学习的风险网站检测系统”完整工程包，适合网络安全方向学生用于项目复现、答辩展示与功能扩展。系统将客户端蜜罐采集数据与机器学习模型相结合，工程内含可运行源码、前后端资源与模型数据文件。压缩包共155个文件，约63.8MB，主要包含42个Python脚本（后端逻辑与模型训练）、44个JavaScript文件（前端交互）、23个pyc编译文件，以及CSS/XML/HTML等页面资源、pickle模型文件、环境依赖（Pipfile）和部署脚本（sh），目录结构清晰，便于按模块学习。目前已有45人学习/下载。项目代码经严格测试，功能完整可复现，相关设计报告也可借鉴；下载后可通过说明文件快速搭建环境，亦可在此基础上修改扩展，实现更多检测功能，适合作为网络安全类毕业设计、课程作业或大创项目的起点。

1. 风险网站检测系统与客户端蜜罐：被动黑名单之外的另一条路

风险网站检测系统最尴尬的时刻不是漏报，而是黑名单永远慢半拍：一个仿冒登录页上线后几小时内就能完成一轮收割，等人举报、人工核实、同步名单时，它往往已经换域名跑路了。基于客户端蜜罐和机器学习的风险网站检测系统换了条思路——不指望被动等名单，而是伪装成普通访客主动访问可疑 URL，把恶意脚本在浏览器上的动作完整录下来，再用机器学习从这些行为记录里判断网站的真实意图。这个思路非常适合做成毕设、课设、实训或竞赛项目：三个模块边界清楚，前端可演示、中间有数据、后端有模型，工程量横跨爬虫、安全、特征工程和分类模型，每一块都能单独展开作为论文或报告的支撑点。

2. 客户端蜜罐的采集架构：伪装成访客，把恶意行为录下来

2.1 为什么这里选客户端蜜罐而不是服务端蜜罐

服务端蜜罐的常见做法是暴露一个模拟的脆弱服务，等攻击者来扫描、爆破，主要捕获的是攻击流量和漏洞利用尝试。它解决的是"谁在打我、怎么打"的问题。风险网站场景里威胁方向完全相反——不是有人打你，而是这些网站主动打路过的人：访问者进入仿冒登录页后，脚本会检测环境、诱导输入账号、弹出伪造对话框，甚至尝试读取剪贴板或触发下载。服务端蜜罐接不住这类攻击，因为攻击链发生在浏览器侧，它根本看不到。

客户端蜜罐的定位正好是受害者视角：它模拟一个真实用户，用真实浏览器内核访问目标 URL，让页面里的脚本以为来了活人，于是恶意脚本开始执行，所有行为被采集下来。说白了，服务端蜜罐是守株待兔，客户端蜜罐是主动出门踩点。对比一下就很清楚：

所以在"风险网站检测"这个命题里，客户端蜜罐是比服务端蜜罐更贴合目标的采集手段。实现时它也不需要在服务器上开真实服务，只需要一个能稳定跑浏览器的环境，门槛低很多。

2.2 三个核心模块和最小可运行实现

客户端蜜罐拆开看只有三块：URL 调度器、渲染器、行为采集器。URL 调度器负责从待检队列取 URL、控制访问频率和指纹轮换；渲染器负责用真实浏览器内核打开页面，让脚本完整执行；行为采集器在渲染的同时把网络请求、DOM 变化、弹窗、重定向链全部记录下来。

为什么必须用 Playwright、Puppeteer 这类真实浏览器驱动，而不是 requests 直接拉 HTML？因为风险站的恶意逻辑基本都写在 JavaScript 里，requests 只会拿到一段等 JS 渲染的壳，真正的跳转和伪装行为完全看不到。下面是一段用 Python + Playwright 写的最小可运行采集器，也是整套系统里最核心的一段代码：

# 最小可运行的客户端蜜罐采集器 from playwright.sync_api import sync_playwright def collect_site(url, output_path): with sync_playwright() as pw: # 每个 URL 独立临时指纹，避免上个页面把 cookie / session 带过来 browser = pw.chromium.launch( headless=False, # 建议有头模式，部分恶意脚本会检测 headless args=["--no-sandbox", "--disable-blink-features=AutomationControlled"] ) context = browser.new_context( viewport={"width": 1366, "height": 768}, user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/124.0 Safari/537.36" ) page = context.new_page() result = {"sent_url": url, "final_url": None, "redirect_chain": [], "requests": [], "alerts": []} # 监听所有 HTTP 请求，记录资源类型和目的地 def on_request(req): result["requests"].append({ "url": req.url, "method": req.method, "resource_type": req.resource_type }) # 拦截弹窗，钓鱼页常用 alert 制造欺诈氛围 def on_dialog(dialog): result["alerts"].append(dialog.message) dialog.dismiss() page.on("request", on_request) page.on("dialog", on_dialog) try: resp = page.goto(url, timeout=30000, wait_until="load") result["final_url"] = page.url result["status_code"] = resp.status if resp else None page.wait_for_timeout(2000) # 停留 2 秒，等延迟脚本执行 except Exception as exc: result["error"] = str(exc) page.screenshot(path=f"{output_path}/shot.png") # 记录重定向链：从 sent_url 到 final_url 之间的所有中间地址 result["redirect_chain"] = [item.url for item in page.context.browser.contexts[0].pages] browser.close() return result

几个关键参数必须说清楚。headless=False 不是强迫症：很多风险站模板内置了 headless 检测，通过 navigator.webdriver、UA 和渲染行为就能识别自动化浏览器，用有头模式加延迟看到的页面更接近真实访客所见。--disable-blink-features=AutomationControlled 是去掉 webdriver 标记，属于初级反检测，但有总比没有好。timeout 设 30000，wait_until="load"，因为部分风险站会故意拖慢响应、延迟注入恶意脚本；超时后我一般记录错误特征，而不是直接判死刑。wait_for_timeout(2000) 是给页面脚本一个执行窗口，参数可调，实际跑的时候建议改成随机 1500~3000ms，减少规律性暴露。

注意：如果你在无显示器的服务器或虚拟机上跑，别直接改回 headless=True。可以用 xvfb-run 提供虚拟显示，或者用 Playwright 的 headless 新模式再配合更完整的指纹伪装。直接切 headless 会让一批带检测逻辑的风险站直接给你看正常页面。

2.3 采集下来的字段：为什么不能只存页面 HTML

很多第一次做这个方向的人会直接 save page html，然后拿去当特征，这是不行的。HTML 正文本身对风险判断帮助极有限，因为仿冒站点经常直接复用正常站点模板，甚至把正常页面原样代理过来。能真正区分风险的是行为——页面加载了什么、跳去了哪里、弹了什么窗、嵌了什么 iframe。

这些字段存起来之后，每一条访问记录就是一条样本。样本格式我一般用 JSONL，一行是一个 URL 的完整访问记录，后续特征工程直接按行读，简单粗暴不搞复杂存储。

3. 特征工程：把浏览器行为变成可以学习的数字特征

3.1 四组核心特征的设计思路

特征工程决定模型上限，这个方向尤其明显。采集器拿到的是原始行为，但模型只认数字，所以要把每条访问记录拆成一组可计算的量。我一般拆成四组：

第一组是 URL 与域名静态特征：URL 长度、是否用裸 IP、端口是否非 80/443、主域名年龄（可以用 RDAP 或 whois 查询）、子域名层级数、URL 里是否包含 login / verify / secure 这类伪造语境的高频词。这类特征看起来朴素，但风险站域名寿命短、常用 IP 直连，这两个信号成本极低、效果却非常稳定。

第二组是页面结构特征：iframe 数量（尤其跨域 iframe）、input 数量、是否存在 type 为 password 的输入框、form 的 action 是否指向登录类接口、页面里有没有悬浮层、倒计时这类诱导元素。钓鱼页和合法站的页面结构差异很大，结构特征抓的就是这个差异。

第三组是网络行为特征：请求总数、跨域请求占比、外部资源来自裸 IP 的占比、重定向次数、是否发起了下载或 WebSocket 连接。这些特征反映的是"这个页面到底想干什么"，资源加载路径越杂乱，越像临时拼装的欺诈页。

第四组是脚本交互特征：是否出现弹窗、弹窗文本是否包含诱导关键词、页面是否修改了 document.title、是否触发 debugger 断点检测。最后一类需要额外监听，成本和收益要自己权衡，但弹窗特征几乎必采。

3.2 特征提取的批量实现

有了原始记录，下一步是把 JSONL 里的访问记录转成一张特征表。下面这段代码把上一章采集器产出的 records.jsonl 转成 DataFrame，并保存为 parquet 供后续训练使用：

# records.jsonl -> features.parquet import json import pandas as pd from urllib.parse import urlparse def _looks_like_ip(host): if not host: return False parts = host.split(".") return len(parts) == 4 and all(p.isdigit() for p in parts) def extract_features(record: dict) -> dict: final_url = record.get("final_url") or record.get("sent_url") parsed = urlparse(final_url) reqs = record.get("requests", []) # 页面 HTML 建议在采集端就压缩存盘，特征计算时只做标签统计 html_text = record.get("html", "") f = { # 页面结构特征 "iframe_cnt": html_text.count("<iframe"), "input_cnt": html_text.count("<input"), "form_cnt": html_text.count("<form"), "has_password_input": 1 if 'type="password"' in html_text else 0, } # 网络行为特征 total = max(len(reqs), 1) cross_domain = [ r for r in reqs if urlparse(r["url"]).netloc != parsed.netloc and r["url"].startswith(("http://", "https://")) ] ip_hosts = [ r for r in reqs if _looks_like_ip(urlparse(r["url"]).hostname) ] f["req_total"] = len(reqs) f["cross_domain_ratio"] = round(len(cross_domain) / total, 4) f["req_ip_ratio"] = round(len(ip_hosts) / max(len(reqs), 1), 4) # URL 与域名特征 f["url_len"] = len(final_url) f["path_levels"] = len([p for p in parsed.path.split("/") if p]) f["port_is_default"] = 1 if parsed.port in (None, 80, 443) else 0 return f rows = [] with open("records.jsonl", encoding="utf-8") as fh: for line in fh: rec = json.loads(line) rows.append(extract_features(rec)) df = pd.DataFrame(rows) df.to_parquet("features.parquet")

这里有三个特征需要解释。cross_domain_ratio 分母是请求总数、分子是 netloc 与落地域名不同的请求数，它抓的是"页面大量从外部域加载脚本"这类模板复用行为，钓鱼站模板常托管在另一个域名甚至另一个 IP 上。req_ip_ratio 抓"资源来自裸 IP"，很多快速搭建的仿冒站直接拿 IP 当静态资源服务器，合法站几乎不会这么干。url_len 和 path_levels 是低区分度但很稳定的基线特征，单看没意义，和结构特征组合起来能帮助模型确认"这是一个临时拼出来的路径结构"。

注意：这段代码里没做归一化是有意的。后面模型选树模型的话，归一化不仅没帮助，还会让特征的可解释性变差。如果换成 LR 或小规模神经网络，再用 StandardScaler 或 min-max 归一化不迟。

3.3 样本不平衡：训练前必须处理的一个默认坑

风险网站检测天然是黑样本少、白样本多，比例往往在 1:10 甚至更悬殊。处理方式分三步：第一，对白样本做下采样，把正负比例控制在 1:3 到 1:10 之间，模型对比例极其敏感，太极端会把决策边界整个拉偏；第二，切分数据集和交叉验证时要保持同样的比例；第三，评估指标用 PR 曲线而不是 ROC 曲线，ROC 在极端不平衡时对误报率的下降过于乐观，PR 曲线直接反映正样本识别能力，跟这个场景的实际目标更一致。

另外补充一点：这个场景里"漏报代价远大于误报代价"。漏一个风险站，用户可能已经填了账号密码；误报一个正常站，最多人工复核点一下。所以处理不平衡时不要追求训练集上的完美平衡，要给阈值留调整空间，后面第 4 章会专门讲阈值怎么定。

4. 机器学习模型选型与评估：小样本和分组切分是两座大山

4.1 为什么先别急着上深度学习

毕设或竞赛里经常看到一上来就套 CNN、Transformer 的，但在这个题目下我通常建议先冷静。这个场景的特征是几十维的表格数据，标注样本在项目阶段一般只有几千到几万条。这个量级下深度学习在表格数据上并没有明显优势，反而带来两个实际麻烦：一是可解释性差，安全运营需要每个告警能回答"为什么判风险"，树模型直接输出特征重要度，告警详情能附带触发特征；二是调参成本高，训一版深度学习的时间够把随机森林调完并完成线上验证。

我一般会先用随机森林把基线跑通，再用 XGBoost 做对比实验。如果答辩或评审需要对比，就把这两个效果和训练时间一起列出来，比硬堆一个效果差不多的网络更有说服力。

4.2 训练评估的最小流程：按域名分组切分是关键

下面这段代码是完整的训练评估流程，里面有一个容易被忽视但致命的点：分组切分。

import pandas as pd from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import GroupKFold, cross_val_score from urllib.parse import urlparse df = pd.read_parquet("features.parquet") X = df.drop(columns=["label", "url"]) y = df["label"] # 1=风险，0=正常 # 按注册主域（TLD+1）分组，保证同一域名的页面不会同时出现在训练和验证集 def extract_domain(url: str) -> str: host = urlparse(url).netloc.lower() parts = host.split(".") if len(parts) <= 2: return host # 简易提取，正式场景建议用 tldextract 处理多级后缀 return ".".join(parts[-2:]) groups = df["url"].map(extract_domain) gkf = GroupKFold(n_splits=5) clf = RandomForestClassifier( n_estimators=300, max_depth=14, min_samples_leaf=4, class_weight="balanced", # 少数类加权，等价于给小类样本更高权重 n_jobs=-1, random_state=42, ) # 用 average_precision（PR-AUC）做交叉验证分数 scores = cross_val_score(clf, X, y, cv=gkf, scoring="average_precision") print(f"PR-AUC: {scores.mean():.3f} +- {scores.std():.3f}") # 全量训练，产出最终模型 clf.fit(X, y)

几个参数说明。n_estimators 设 300 是稳定性和训练时间的折中，再往上提升有限但训练时间翻倍。max_depth 设 14 是防止树过深学进噪声，min_samples_leaf 设 4 保证每个叶子至少有 4 个样本，这两个参数一起控制模型复杂度。class_weight="balanced" 是处理不平衡最简单有效的手段，原理是给少数类的损失加权，等价于把黑样本权重放大到白样本的十倍级。这些参数不是拍脑袋定的，实践顺序是先默认参跑一遍，再看交叉验证分数，用 GridSearchCV 扫 max_depth 的 [8, 12, 16] 和 min_samples_leaf 的 [2, 4, 8]，确定范围后再微调。

4.3 为什么必须按域名分组切分？一个让分数虚高的红线

这个坑我见过很多人踩：训练集和验证集随机切分，线下 PR-AUC 跑到 0.99，一上线立刻被打回原形。原因很简单——同一个钓鱼站可能生成几十个 URL，随机切分后这些 URL 一部分进了训练集、一部分进了验证集，模型直接背下了"这个域名是黑的"这个 pattern，验证分数当然漂亮。但上线遇到的是全新域名，模型根本没学过。

解决方法是分组切分：按注册主域（TLD+1）把样本分组，用 GroupKFold 保证同一域名的所有页面只出现在同一个 fold 里。这样验证集里出现的域名在训练集里完全没见过，模型只能靠行为特征泛化。如果你做完分组切分后分数从 0.9 掉到 0.7，不要慌，这才是真实水平。竞赛和答辩时主动讲出这一步，反而是明显的加分项，因为说明你理解数据泄漏。

4.4 评估指标怎么设：准确率在这个场景没有意义

直接说结论：准确率在这个场景里没有参考价值。假设黑样本只占 5%，模型全部预测为白，准确率也有 95%，但这个模型毫无用处。运营方真正关心三件事：风险站被拦下来的比例是多少，拦下来的里面有多少是真的，以及漏一个和误报一个哪个代价更高。

处理方法是看 PR 曲线的拐点。训练完模型后，在验证集上算出每个样本的风险概率，然后从 0.1 到 0.9 扫阈值，绘制不同阈值下的精确率和召回率。对这个场景，我一般优先保召回率，阈值可以压到 0.3 到 0.4，因为漏报一个风险站的成本远高于误报一个正常站的复核成本。

阈值不是一个固定值，它应该随运营节奏动态调整。这也是整套系统里少有的"调一个参数就能改变全局行为"的杠杆点，值得在文档里单独写一节。

5. 常见问题与避坑：从标签噪声到特征版本不一致的五个教训

5.1 标签噪声：白名单补集不是可靠的白样本

现象：训练时 PR-AUC 尚可，上线后误报集中在一批窃取正常模板、用正常 CDN 的灰色站点上。原因：训练白样本来自"不在黑名单里的站点"，但公开黑名单有严重时效差，很多灰色站根本没被收录，"不在名单 = 正常"这个假设本身就是噪声。解决：给训练样本增加确认程度字段，不确定的样本进"待确认"队列而不是直接标白，定期抽检改标。更彻底的做法是用第 6 章的回扫机制自动补正标签。

5.2 数据泄漏：随机切分让模型背下域名而不是学习行为

现象：线下验证分数接近满分，线上同量级站点漏报率直线上升。原因：同一个域名生成的几十个 URL 在随机切分下同时进入了训练集和验证集，模型直接记住了域名。解决：用 GroupKFold 按 TLD+1 分组切分，保证验证集域名在训练集里完全不可见。换成分组切分后分数掉下来是正常的，那才是真实泛化水平。

5.3 蜜罐指纹固定：同一套环境跑多了会被反检测识破

现象：蜜罐跑了一段时间后，部分站点回传的页面完全不含恶意代码，看起来跟正常站一模一样。原因：风险站内置了反检测脚本，比对 UA、字体、时区、自动化标记，同一套指纹访问多个目标时很容易被识别成"不是真人"。解决：每次访问用独立的临时 context，用完即销毁；随机化 UA、viewport、时区；访问间隔用随机延时模拟真人的行为节奏。指纹池要定期补充，不能一套配置打天下。

5.4 特征版本分裂：训练和推断各写一份，上线必然出问题

现象：模型训练时 PR-AUC 正常，部署到检测服务后预测分数整体偏移，甚至字段对不上直接报错。原因：训练代码和在线服务各写了一份特征提取逻辑，字段顺序、名称、计算口径不一致。解决：特征提取做成单一函数或独立模块，训练程序和检测服务都 import 同一份代码；特征文件里记录 version 和字段列表，加载时校验；每次改特征必须重新导出训练集。

5.5 重定向和 iframe 嵌套被忽略：只拿到最外层页面会整体失真

现象：风险站先跳到编码后的跳转页，再通过 iframe 把真正的钓鱼页嵌进来，采集器只记录了最外层页面的内容，所有特征严重失真。原因：默认抓取的是顶层 frame 的文档，压根没有收集 subframe 的加载事件和重定向链。解决：采集端监听 framenavigated 和 response 事件，把子页面 URL 连同外层 URL 一起记入记录；特征里增加"最终落地域名与入口域名是否一致""是否存在跨域 iframe 加载敏感路径"这两个字段。展示分析时生成一条完整的跳转链，而不是只看终点。

6. 回扫确认机制：让检测结果变成可持续迭代的闭环

模型预测只回答"此刻像不像"，回答不了"它明天会不会更坏"。回扫确认机制就是来解决这个问题的：第一轮模型分数落在灰色地带（比如 0.4 到 0.8）的样本，先不急着下结论，放进回扫队列，过 12 到 24 小时再访问一次。风险站有生命周期，刚上线的钓鱼站往往伪装成测试页面，恶意模块没有完全加载；隔几小时后再看，跳转链、弹窗、伪造表单都出来了，行为升级会直接反映在分数上。

# 回扫确认：pending 队列 + 定时任务 def rescan_job(): for row in pending_urls(score_range=(0.4, 0.8)): if hours_since(row.last_visited_at) < RESCAN_INTERVAL_HOURS: # 默认 24h continue evidence = collect_site(row.url) # 复用采集器，见第 2 章 features = extract_features(evidence) # 复用特征函数，见第 3 章 new_score = model.predict_proba([features])[0][1] if new_score > 0.75: add_to_retrain_set(row.url, 1, evidence) # 行为升级，补黑样本 row.status = "confirmed_risk" elif new_score < 0.2: add_to_retrain_set(row.url, 0, evidence) # 始终正常，补白样本 row.status = "confirmed_clean"

灰色区间和回扫间隔是两个可调参数，我一般把灰色区间设为 0.4~0.8、回扫间隔设为 24 小时。区间设太窄，回扫样本太少；太宽，模型该判的没判，还拖慢队列。回扫真正解决的是标签时效问题——训练集不再是一锤子买卖，每周自动长出新的黑样本和白样本，模型能跟着新出现的风险站手法一起更新。

回扫还有一个容易被忽略的收益：证据包。每次回扫和首次访问都存一套完整的 JSON + 截图 + 跳转链，模型调优时直接把误报 TOP10 调出来，打开截图看真实页面，对照特征值找出哪条规则诱导了误判。我第一版系统上线后吃了这个亏，只盯着准确率调模型，结果误报清单里躺着一批正常站点，运营对告警的信任直接崩掉。后来养成的习惯是：每次调参先看误报 TOP10，先把候审列表搅个底朝天，再回头改特征。证据包机制也是一次次翻车之后才逼出来的。按这个节奏把回扫、证据、分组评估三件事做扎实，这套系统才算真正能跑在巡检任务里，希望帮到你。

本文还有配套的精品资源，点击获取