蜜罐：原理与识别

蜜罐是一类主动防御和威胁观测技术。它通过部署具有吸引力的系统、服务或数据，引导扫描、探测和攻击行为进入可监控环境，再记录交互过程，为告警、溯源和威胁研究提供证据。

对于授权安全测试人员，蜜罐带来的风险不只是“浪费时间”。访问诱饵页面、连接模拟服务或运行漏洞验证工具时，测试端可能主动暴露网络来源、浏览器特征、工具指纹，甚至触发客户端自身支持的危险协议能力。认识蜜罐的目的，不是与防守方对抗，而是在授权范围内减少不必要的信息暴露，并避免把诱饵环境误判为真实业务系统。

本文依次讨论两个问题：蜜罐是什么，以及如何建立可靠的识别证据。

一、蜜罐是什么

1.1 核心目的不是“伪装”，而是观测

NIST 对蜜罐的定义是：为了吸引潜在入侵者而设计的系统或系统资源。它可以是一台服务器、一个 Web 后台、一项网络服务，也可以是文件、凭据、API 密钥等诱饵资源。

正常业务系统的首要目标是向合法用户提供服务；蜜罐的首要目标则是让未经预期的访问产生高价值信号。一个没有正常用户、没有公开业务入口的服务，只要出现连接或操作，本身就可能构成告警。相比在海量生产日志中寻找异常，这类信号噪声更低，也更适合记录完整交互链。

蜜罐通常承担以下任务：

捕获端口扫描、口令尝试、漏洞探测和攻击载荷；
记录请求头、协议字段、命令序列、上传文件和会话行为；
观察攻击工具、自动化脚本和基础设施之间的关联；
为安全运营提供高置信度告警；
在隔离环境中研究未知攻击方式和恶意软件行为。

蜜罐并不天然具备“反击”能力。多数系统的核心仍是诱导、记录和告警。部分产品会进一步收集访问端环境信息，但这种能力依赖具体的 Web API、客户端协议和浏览器策略，不能把所有蜜罐都理解为能够直接读取测试人员设备的系统。

1.2 低交互、高交互与混合型

蜜罐常按交互程度划分。交互程度越高，环境越接近真实系统，能够收集的信息越丰富，部署和失陷后的风险也越高。

类型	实现方式	优势	局限
低交互	模拟有限服务、协议或漏洞	部署简单、资源消耗低、容易规模化	状态机和业务逻辑有限，较容易暴露实现差异
高交互	提供真实操作系统或完整应用	交互逼真，可记录深入行为	运维成本高，必须严格限制出站和横向风险
混合型	低交互前端筛选，再转发至高交互后端	兼顾规模和观测深度	路由切换与状态同步可能产生异常特征

低交互蜜罐常用于捕获批量扫描、自动化口令尝试和常见漏洞载荷。它只需要实现协议中最常用的一部分，因此在错误码、连接状态、命令支持范围和数据持久性方面可能与真实产品不一致。

高交互蜜罐运行真实服务，甚至提供完整系统权限。它更难通过简单指纹识别，也能观察攻击者取得初始访问后的命令、文件和横向行为。代价是环境必须与生产网络严格隔离，否则被完全控制的蜜罐可能反过来成为攻击其他目标的跳板。

混合型蜜罐在前端承接大量连接，根据来源、载荷或交互深度筛选会话，再把值得继续观察的流量转入高交互环境。这种架构提升了效率，但前后端在协议实现、延迟、会话状态和系统指纹上的差异，也可能成为识别线索。

1.3 蜜罐能够记录什么

蜜罐可见的信息取决于交互入口，而不是“蜜罐”这个名称本身。

网络层：来源地址、端口、连接时间、DNS 行为和流量模式；
协议层：HTTP 请求头、TLS 指纹、SSH 客户端版本、数据库握手能力等；
应用层：访问路径、输入参数、登录尝试、漏洞载荷和命令序列；
客户端环境：浏览器语言、时区、屏幕、图形能力，以及特定 API 暴露的网络信息；
后续行为：下载地址、回连基础设施、上传样本和自动化工具特征。

这里需要区分“服务端自然可见的信息”和“页面额外采集的信息”。来源地址和请求头是建立连接时自然产生的；浏览器指纹、第三方身份探测或 WebRTC 候选收集则需要页面脚本主动执行。分析蜜罐时，真正值得关注的是后者是否超出页面正常业务所需。

二、常见蜜罐及其信息采集方式

2.1 Web 蜜罐

Web 蜜罐常伪装成管理后台、文件管理器、设备控制台、OA 系统或存在已知漏洞的站点。低交互实现可能只返回固定页面和预设响应，高交互实现则可能运行真实框架，并在后台完整记录访问和操作。

仅凭“页面看起来像后台”无法判断蜜罐。很多真实系统同样使用通用模板，很多诱饵也会复刻真实产品。更有价值的观察包括：页面是否加载与业务无关的采集脚本、是否批量访问第三方接口、输入后状态是否真正变化，以及不同会话之间的数据是否一致。

JSONP 是旧式跨源数据调用方式，也曾被用于第三方登录状态或用户信息探测。其基本形式如下：

<script>
  function receive(data) {
    console.log(data);
  }
</script>
<script src="https://service.example/profile?callback=receive"></script>

这类探测必须同时满足几个条件：第三方接口支持回调参数、响应中包含可利用数据、浏览器凭据策略允许识别用户，而且页面确实处理或回传了结果。因此，出现 callback 参数只能算线索，不能单独证明页面获取了用户名、手机号等信息。

WebRTC 也常被描述为“获取真实 IP”的手段，但这一说法不够准确。WebRTC 使用交互式连接建立（Interactive Connectivity Establishment，ICE）收集多种候选地址：

host：来自本机物理或逻辑接口，包括 VPN 创建的接口；
srflx：通过 STUN 获得的 NAT 映射地址；
prflx：连接检查过程中形成的对等反射候选；
relay：由 TURN 中继服务器分配的地址。

页面实际能够看到哪些候选，取决于浏览器版本、mDNS 隐藏策略、VPN 或代理方式、网络结构和 ICE 配置。准确的风险描述应是：WebRTC 可能暴露不同于普通 HTTP 请求路径的网络信息，从而增加环境关联可能性。

2.2 SSH、Telnet 与通用服务蜜罐

服务型蜜罐通过模拟 SSH、Telnet、FTP、Redis、SMB、工业协议或物联网设备接口，捕获扫描、口令尝试和命令操作。低交互系统通常只实现常用命令和预设文件系统，高交互系统则可能把会话放入容器或隔离虚拟机。

这类蜜罐最常收集以下数据：

客户端版本字符串和握手参数；
用户名、口令字典及尝试顺序；
登录后的命令、下载地址和执行链；
上传文件、恶意样本和持久化操作；
自动化工具在异常响应下的固定行为。

识别难点在于，真实的老旧设备同样可能协议实现不完整、响应缓慢或文件系统内容单一。因此，“某条命令不支持”只能作为弱证据。只有多项状态矛盾能够稳定复现，例如系统版本、内核信息、文件时间和命令输出彼此冲突，证据强度才会上升。

2.3 数据库蜜罐与 `LOCAL INFILE`

数据库蜜罐可以记录连接参数、驱动特征、认证尝试和查询行为。MySQL 场景还有一项需要测试端特别注意的客户端能力：LOAD DATA LOCAL INFILE。

它的正常用途是由客户端读取本地文件并导入数据库。简化后的协议流程如下：

客户端                                      服务端
  │──── 握手：声明 CLIENT_LOCAL_FILES ────────>│
  │──── 查询 ─────────────────────────────────>│
  │<─── 0xFB + 服务端指定的文件路径 ──────────│
  │  客户端在自身权限范围内读取文件             │
  │──── 文件内容 ─────────────────────────────>│

风险点在于，经过修改的服务端可能返回一个并非用户预期的文件路径。但这并不意味着“连接 MySQL 就一定会被读取文件”。行为成立至少依赖以下条件：

客户端或驱动实现并启用了 LOCAL INFILE；
握手中声明了 CLIENT_LOCAL_FILES；
客户端接受服务端指定路径，没有目录限制或安全回调阻止；
客户端进程对目标文件拥有读取权限。

MySQL 官方安全文档明确提示了不可信服务端请求客户端文件的风险，也提供了禁用该能力或限制允许目录的方式。判断数据库蜜罐时，应观察能力协商、0xFB 请求出现的时机及客户端配置，而不是依赖某个固定敏感文件路径。

三、如何识别蜜罐

实战中的核心原则是工具自动化优先，手工验证兜底。成熟的蜜罐指纹库已经覆盖了绝大多数开源和商业蜜罐，先让工具替你筛一遍，只对可疑但不确定的目标才进入深度手工检查。

本节按效率从高到低组织：网络空间搜索引擎（动手前）→ 浏览器插件（浏览时自动告警）→ 扫描器内置检测（批量扫描时自动过滤）→ 常见蜜罐快速指纹（秒级确认）→ 手工深度验证（兜底）。

3.1 动手前：用网络空间搜索引擎预筛

在真正访问目标之前，先在 FOFA、Shodan、Quake 等平台查询目标 IP 或域名。这些平台已对大量蜜罐打了标签，30 秒就能筛掉一批已知诱饵。

FOFA：

// 直接查 IP 是否被打上蜜罐标签
ip=”目标IP” && honeypot=”true”

// 按已知蜜罐指纹搜——命中结果本身就说明问题
body=”static/x.js” && body=”w-logo-blue.png”           // HFish Web 蜜罐
header=”Server: HFish” && body=”login_verify”           // HFish 管理后台
cert=”dionaea.carnivore.it”                             // Dionaea 默认证书

Shodan：

// Shodan 的 Honeyscore 会为 IP 返回 0.0-1.0 的蜜罐概率评分
// 直接在 Web 界面输入 IP 即可看到，也可以命令行查询：
shodan honeyscore <目标IP>

// 按已知指纹搜索
“static/x.js” “w-logo-blue.png”
org:”Amazon” “SIMATIC”       // 云平台上出现工业协议 → 可疑

Quake / ZoomEye：

// Quake 内置蜜罐识别，直接查
quake honeypot <目标IP>

// ZoomEye
“static/x.js” +”w-logo-blue.png”

这些平台也有局限：新部署的蜜罐可能还没被打标签，自研蜜罐的指纹不在公开库中。预筛通过不代表安全，它只是第一道低成本过滤。

3.2 浏览器端：插件被动检测

浏览目标站点时，让浏览器插件在后台自动匹配指纹库。这是实战中投入产出比最高的一层——基本不增加操作成本，但能拦截大部分已知蜜罐的采集请求。

Heimdallr（推荐）

一款 Chrome 被动嗅探插件，无需额外配置即可工作。GitHub

核心能力：

151 条蜜罐告警规则：覆盖 JSONP 探测、蜜罐静态资源指纹、BurpSuite 探测识别、跟踪脚本等
103 条漏洞框架指纹：Struts2、Shiro、WebLogic、Tomcat 等
被动模式：不产生额外流量，不会触发蜜罐告警
自动拦截：可开启对已知蜜罐域名的请求阻断
防溯源：WebRTC 严格策略防真实 IP 泄露、Canvas 噪点注入对抗浏览器指纹

使用方式很简单：

Chrome ≥ v96，从 Releases 下载并加载已解压的扩展；
测试前在插件设置中开启蜜罐拦截和 WebRTC 严格策略；
日常浏览目标时，如果插件图标出现红色角标 → 已命中蜜罐规则 → 关闭标签页。

狗蛋蜜罐识别器

另一款 Chrome 插件，覆盖 35+ 种蜜罐平台、165+ 条检测规则，包括 HFish、Cowrie、Kippo、Dionaea、T-Pot 等。GitHub

两支插件可以同时安装，指纹库互补。都走被动检测，不会相互干扰。

注意事项： 插件只能检测已有指纹库覆盖的蜜罐。自研或深度定制的蜜罐可能不触发告警。插件的作用是替你处理 90% 的已知情况，剩下 10% 需要后面几步来兜底。

3.3 扫描阶段：Nuclei 蜜罐检测

Nuclei v3.4+ 内置了蜜罐检测功能，在批量漏洞扫描时自动标记疑似蜜罐目标。PR #7277

# 开启蜜罐检测：当单个主机命中超过阈值的不同模板时触发告警
nuclei -u <目标> -honeypot-detect -honeypot-threshold 15

# 对疑似蜜罐目标自动静默，不输出结果
nuclei -u <目标> -honeypot-detect -suppress-honeypot

# 批量扫描
nuclei -l targets.txt -honeypot-detect -suppress-honeypot

原理：正常主机的漏洞扫描结果通常是稀疏的——一个 IP 上不会同时存在几十种不相关漏洞。蜜罐为了扩大诱捕面，常堆叠大量模拟服务，导致扫描时命中异常多的漏洞模板。Nuclei 利用这个特征，统计每个主机命中的不同模板 ID 数量，超出阈值即告警。

其他可配合的工具：

工具	定位	蜜罐相关能力
GoFinger	资产指纹识别	集成 Goby/Ehole/Wappalyzer 指纹库，可联动 FOFA 等 API 批量识别
dddd	供应链漏洞探测	二开版本内置蜜罐检测、JS 目录爆破
honeydet	专用蜜罐检测	Go 语言，YAML 多步签名，支持 TCP/UDP 深度交互检测
gogo	红队自动化引擎	主动/被动指纹识别，最小发包原则，可自定义蜜罐检测规则

3.4 常见蜜罐的快速指纹速查

插件和扫描器告警后，或者怀疑目标但工具未命中时，可以用以下指纹快速确认。

HFish（国内部署量最大的开源蜜罐）

Web 蜜罐服务（端口 80/9000）：
  - 响应中包含 “static/x.js”
  - 响应中包含 “w-logo-blue.png?ver=20131202”
  - 页面加载 x.js 后通过 AJAX 将用户名密码 POST 到 /api/v1/post/report
  - 请求体携带 sec_key=9cbf8a4dcb8e30682b927f352d6559a0

管理后台（端口 9001）：
  - HTML 页面 MD5: f9dbaf9282d400fe42529b38313b0cc8
  - 响应头 Server: HFish

一键验证：
  curl -s https://target/ | grep -E 'static/x\.js|w-logo-blue\.png'

Cowrie / Kippo（SSH/Telnet 蜜罐）

SSH 连接后执行 ls /home，返回的用户名包含：
  phil, richard,  daniel,  arno,  hans

执行 uname -a 返回固定的内核版本：
  Linux debian 2.6.32-5-686

伪文件系统特征：
  - /proc 下文件极少且内容固定
  - 命令如 ifconfig 的输出与系统声称的网卡列表不匹配

Dionaea（多协议蜜罐）

1
2
3

- 默认 TLS 证书 CN = dionaea.carnivore.it
- 同时开放大量不相关端口（HTTP、SMB、FTP、MySQL、SIP 等）
- SMB 服务返回固定的共享列表

Conpot（ICS/SCADA 蜜罐）

1
2
3

- 在云厂商 AS 上出现 Siemens SIMATIC 等工业协议
- 默认配置下 HTTP 响应头包含 “Conpot”
- 协议响应中的设备序列号、固件版本为固定默认值

通用快速检查项：

# 1. 检查是否同时开放了大量不相关服务（蜜罐典型特征）
nmap -Pn -p 21,22,23,80,135,139,443,445,1433,3306,3389,5060,6379,8080,11211 target

# 2. 查证书——多节点共用证书是蜜罐集群的常见特征
openssl s_client -connect target:443 -servername target </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -fingerprint -sha256

# 3. 查 FOFA/Shodan 标签——确认是否已被测绘平台标记

3.5 手工深度验证（以上步骤都不确定时）

工具没告警、指纹没命中、但直觉告诉你不对劲——这时才需要手工介入。注意：手工验证的前提是已经做好了环境隔离（虚拟机、独立浏览器配置、关闭共享目录和剪贴板）。

Web 蜜罐：看采集→回传闭环

Web 蜜罐对测试端最直接的威胁不是页面造假，而是脚本在浏览器中执行采集逻辑。检查方法：

打开浏览器开发者工具 Network 面板，勾选 Preserve log 和 Disable cache；
重新加载页面，按 Domain 排序第三方请求；
对每个外部请求查看 Initiator——是哪个脚本发起的；
在 Sources 面板搜索 callback、jsonp、RTCPeerConnection、canvas、fingerprint、navigator；
检查外部请求的响应是否包含登录状态、用户标识或网络信息；
追踪这些数据是否通过后续 POST / Beacon / WebSocket 回传；
导出 HAR 作为证据。

判断标准只有一条闭环：采集了数据→整理→回传了。仅加载第三方脚本不算证据（正常站点也用 CDN、统计和 SSO），响应内容空或看不到回传也不能定案。

服务型蜜罐：与真实实现对照

不要在蜜罐上尝试危险命令。在本地部署同版本真实服务作为基线，对目标和基线发相同请求，比较：

维度	具体对照方法
Banner 一致性	版本号与支持的命令集、算法套件是否匹配？
状态持久性	新建会话后，之前的创建/修改/删除是否还在？
数据可信度	用户列表、文件时间戳、进程信息能否互相印证？
错误行为	非法请求的错误码和断开方式是否与真实实现一致？
多节点独立性	不同 IP 是否复用了本应唯一的 Host Key、证书或序列号？

MySQL：LOCAL INFILE 专项检查

MySQL 的 LOAD DATA LOCAL INFILE 允许服务端指定客户端本地文件路径。检查时先禁用：

1	mysql --local-infile=0 -h target -u test -p

在可合法抓包的场景中，Wireshark 过滤 tcp.port == 3306，观察服务端是否在客户端未请求本地导入时主动发送首字节为 0xFB 的文件请求。若连接使用 TLS，查看客户端日志或在本机复现，不要为抓包关闭 TLS。