HFish 蜜罐协议与流量特征分析报告

HFish 蜜罐流量特征与协议特征分析

基于 HFish 3.3.6 本地实验环境的协议返回、流量行为与 Web 指纹分析

摘要

本文以本地 VMware NAT 环境中部署的 HFish 3.3.6 为分析对象，从端口暴露、协议返回、交互上下文、HTTP 响应头、Web 登录行为以及 Wireshark 抓包方法等角度，对 HFish 蜜罐的流量特征和协议特征进行系统化分析。实验目标地址为 192.168.111.128，真实 SSH 管理端口迁移至 22222，22、23、6379、8080、8081、9000、9200 等端口由 HFish 蜜罐服务接管。

分析结果表明，HFish 的多个协议实现存在较稳定的识别特征：SSH 服务端 Banner 固定伪装为 OpenSSH_7.4；Telnet 连接后无标准 login/password 提示，任意输入固定返回 test；Redis 对明文 PING/INFO 存在吞首字符回显，对标准 RESP PING 返回 +ok；Elasticsearch 返回模板化 JSON；Web 类蜜罐在不同伪装页面上复用 Content-Md5、Ohc-Cache-Hit、Server: JSP3/2.0.14、Set-Cookie: session 等统一响应头特征。

关键词

HFish；蜜罐识别；流量分析；协议指纹；Wireshark；SSH；Telnet；Redis；Elasticsearch；Web 蜜罐

一、前言

蜜罐是网络安全攻防对抗中常见的欺骗与诱捕系统，常用于发现扫描行为、捕获爆破凭据、记录漏洞利用过程、辅助攻击溯源和威胁情报分析。HFish 是一款多协议蜜罐平台，可通过低交互或高交互方式模拟 SSH、Telnet、Redis、Elasticsearch、Web 登录系统等多种服务。HFish在国内使用较多，所以下文做数据统计主要统计国内使用情况

从防守视角看，理解 HFish 的流量特征有助于验证蜜罐是否正常工作、是否成功捕获攻击行为以及如何在流量平台中检索相关事件。从流量分析和协议研究视角看，HFish 本身也会在协议实现、响应模板、页面资源、交互上下文等方面留下稳定特征。本文重点围绕这些可观测特征进行分析。

这是quake引擎收录的HFish蜜罐在国内的分布情况

本文参考“基于特征的蜜罐检测”思路，将 HFish 的可识别点归纳为五类：协议返回特征、协议实现差异、Web 页面与响应头特征、上下文交互特征以及多端口组合特征。

二、实验环境与网络拓扑

本次实验在 Windows 主机与 VMware Ubuntu 虚拟机之间完成。虚拟机使用 NAT 模式接入，Windows 侧通过 VMware Network Adapter VMnet8 与虚拟机通信。HFish 部署在 Ubuntu 虚拟机中，版本为 3.3.6。

项目	配置/说明
Windows 主机网卡	VMware Network Adapter VMnet8
目标虚拟机 IP	192.168.111.128/24
HFish 版本	HFish 3.3.6
HFish 安装目录	/opt/hfish/3.3.6
HFish 数据目录	/usr/share/hfish
真实 SSH 管理端口	22222/tcp
HFish SSH 蜜罐端口	22/tcp
抓包位置	Windows 主机监听 VMnet8

由于 22 端口需要由 HFish SSH 蜜罐接管，因此真实 sshd 已迁移至 22222 端口。后续管理虚拟机时使用 ssh -p 22222 root@192.168.111.128，避免与 HFish SSH 蜜罐冲突。

三、HFish 整体端口暴露特征

HFish 的一个典型现象是同一主机集中暴露多个不同类型的伪装服务。单独某个端口的返回可能不足以确认其为蜜罐，但当同一 IP 同时出现 SSH、Telnet、Redis、Elasticsearch、ESXi、Coremail、IOT-HIKCAM 等服务，且响应均存在模板化特征时，整体判断价值会明显提高。

端口	服务/蜜罐	当前状态	主要可见特征
22/tcp	HFish SSH 蜜罐	open	服务端 Banner：SSH-2.0-OpenSSH_7.4；后续为 SSH 加密协商流量
23/tcp	HFish Telnet 蜜罐	open	无初始 login/password 提示；任意输入固定返回 test
6379/tcp	Redis 蜜罐	open	明文 PING 返回 ING；标准 RESP PING 返回 +ok
9200/tcp	Elasticsearch 蜜罐	open	返回固定 JSON：cluster_name=elasticsearch，lucene_version=4.10.2
8080/tcp	IOT-HIKCAM Web 蜜罐	open	登录页；HTTP Header 中存在 HFish Web 通用特征
8081/tcp	ESXi Web 蜜罐	open	登录页标题为“登录 - VMware ESXi”；HTTP Header 中存在通用特征
9000/tcp	Coremail Web 蜜罐	open	登录页标题为“Coremail邮件系统”；使用 login.js 提交登录表单
7879/tcp	HFish Local/HTTP 服务	open	GET / 返回 404 page not found；异常请求返回 400 Bad Request
4433/4434	HFish 管理/API 相关服务	open	HTTPS/HTTP2 下根路径返回 404；用于管理或节点通信相关场景
135/139/445/1433/3389	TCP 监听类蜜罐	open	主要用于触发连接/扫描告警，协议层主动返回较弱

这里通过nmap来扫描其全端口

从这里也可以看出Bannner的不同

从端口组合看，真实业务主机很少同时自然暴露如此多且业务跨度极大的服务。多端口组合本身不能作为唯一证据，但可以作为 HFish 环境的辅助判断条件。

四、协议类蜜罐流量特征分析

4.1 SSH 蜜罐特征

SSH 端口当前由 HFish 接管。客户端连接 22 端口后，首先可以在流量中看到服务端 Banner。实验中服务端返回如下：

该 Banner 与当前 Ubuntu 22.04 系统常见的真实 OpenSSH 版本不一致。真实 Ubuntu 22.04 默认 OpenSSH 通常为 OpenSSH_8.9p1 Ubuntu，而 HFish 蜜罐固定伪装为 OpenSSH_7.4。因此，当同一主机的系统指纹、真实管理端口和 22 端口 Banner 存在明显不一致时，可以作为 SSH 蜜罐识别依据。

需要注意，SSH 在密钥交换后即进入加密通信阶段，Wireshark 中通常无法直接看到登录用户名和密码明文。对 SSH 蜜罐流量的分析重点应放在 Banner、KEXINIT 算法列表、HostKey 算法、服务端指纹以及认证失败/断开行为上。

分析项	HFish SSH 蜜罐表现	真实 SSH 服务常见表现
Banner	SSH-2.0-OpenSSH_7.4	与系统发行版和 OpenSSH 版本相关，例如 OpenSSH_8.9p1 Ubuntu
加密前可见内容	服务端 Banner、客户端 Banner、KEXINIT	同样可见 Banner 与 KEXINIT
账号密码可见性	SSH 加密后不可直接在 Wireshark 看到明文	不可直接看到明文
识别重点	固定旧版本 Banner、算法组合、HostKey 指纹变化	版本与系统环境通常更一致

4.2 Telnet 蜜罐特征

Telnet 是最适合观察上下文交互的协议之一。真实 Telnet 服务通常会进行 IAC 选项协商，并主动输出 login:、Password: 等登录提示。HFish Telnet 蜜罐则表现出明显的模板化交互：连接后没有标准登录提示，客户端输入任意字符串后，服务端固定返回 test。

该行为与真实 Telnet 服务差异明显，也不同于 Cowrie 等蜜罐的常见交互方式。Cowrie 通常会模拟 login/password 流程，但 HFish 当前低交互 Telnet 模板更简单，固定返回 test 的行为具有较高识别价值。

输入内容	HFish Telnet 返回	特征说明
admin	test	无论输入内容如何，返回固定字符串
root	test	缺少真实 Telnet 登录上下文
123456	test	上下文关联性弱
任意字符串	test	模板化返回，可作为检测特征

通过指纹识别可以找到HFish的Telnet类型的蜜罐在国内的分布情况

4.3 Redis 蜜罐特征

Redis 蜜罐存在两类典型特征：一类是非标准明文输入下的异常回显，另一类是标准 RESP 协议输入下的异常响应。

真实 Redis 对 PING 命令通常返回 +PONG，对 INFO 命令则返回大量服务端信息，包括 redis_version、os、arch_bits、uptime_in_seconds 等字段。HFish 返回 ING、NFO 或 +ok 的行为均不符合真实 Redis 常见实现。

测试方式	输入	HFish 返回	真实 Redis 常见返回
明文 PING	PING\r\n	ING	+PONG\r\n 或协议错误
明文 INFO	INFO\r\n	NFO	包含 redis_version 等大量 INFO 信息
RESP PING	*1\r\n$4\r\nPING\r\n	+ok\r\n	+PONG\r\n

其中“吞掉首字符后回显”与“标准 PING 返回 +ok”组合后特征较强，可作为 Redis 蜜罐识别的重要依据。

4.4 Elasticsearch 蜜罐特征

访问 HFish Elasticsearch 蜜罐根路径时，会返回一段模板化 JSON。实验中的响应正文如下：

在本次实验环境中，HFish 的 Elasticsearch 蜜罐具有较明显的模板化返回特征。当目标同时满足三类特征时，可高度怀疑其为 HFish 类 Elasticsearch 蜜罐。

该响应模仿 Elasticsearch 根路径信息，但存在多个不自然点：name 为空、version.number 为空、cluster_name 固定为 elasticsearch、lucene_version 固定为 4.10.2，同时 HTTP 响应头中还出现 Set-Cookie: session=...。真实 Elasticsearch API 服务通常不会在根路径响应中设置这种 Web 会话 Cookie。

字段/响应头	HFish 表现	识别意义
name	空字符串	真实集群通常存在节点名称
version.number	空字符串	真实 Elasticsearch 通常返回明确版本号
lucene_version	4.10.2	固定模板字段
tagline	You Know, for Search	旧版 Elasticsearch 风格标语
Content-Type	text/plain; charset=utf-8	与真实 JSON API 的 application/json 风格不完全一致

对ES蜜罐实网目标进行检测

综合来看，单一字段可能存在偶然性，但当响应内容中同时出现 cluster_name 为 elasticsearch、lucene_version 为 4.10.2，且tagline 为 You Know, for Search 时，三者组合形成了较强的 Elasticsearch 蜜罐指纹特征。在实际检测中，可将该组合规则作为识别 HFish 类 Elasticsearch 蜜罐的重要依据。

这是ES蜜罐在国内的分布情况

五、Web 类蜜罐流量特征分析

当前 Web 类蜜罐主要包括 IOT-HIKCAM、ESXi 和 Coremail。三者页面模板不同，但核心诱捕流程一致：攻击者访问登录页，提交用户名和密码到 /login，hfish-server 根据访问端口识别服务类型并记录凭据。

5.1 IOT-HIKCAM Web 蜜罐（8080）

8080 端口虽然模拟 IoT 摄像头类登录页面，但 Login 标题、username/password 字段、sea.js 脚本等都只是普通页面模板特征，不能单独作为 HFish 蜜罐判断依据。更具蜜罐识别价值的是其响应头和交互逻辑：响应头中同时出现 Server: JSP3/2.0.14、Content-Md5、Ohc-Cache-Hit、Set-Cookie: session=<32位hex>、Timing-Allow-Origin: * 等字段；页面源码中存在 saved fromurl=(0057)http://www.musickid.org/doc/page/login.asp?_1614596164589 的静态复制痕迹；登录提交到 /login 后固定返回window.alert("用户名或密码错误");window.history.back();。这些特征组合起来，体现出明显的 HFish Web 蜜罐模板化特征。

为降低误报，脚本没有将 Login 标题、sea.js、username/password 字段作为强判定依据，而是采用评分制。只有当目标同时命中HFish Web 通用响应头、静态模板复制痕迹或固定登录失败响应等多类特征时，才判定为高度疑似 HFish Web 蜜罐。（以下两个web判断方式同上）

5.2 ESXi Web 蜜罐（8081）

8081 端口模拟 VMware ESXi 登录页面。页面标题为“登录 - VMware ESXi”，表单中包含 username/password 或 credentials.username/credentials.password 等字段，页面资源中可见 require.js、main.js 以及 VMware ESXi 风格的前端资源。

scripts/main.jsbower_components/requirejs/require.jsbower_components/es5-shim/es5-shim.js

5.3 Coremail Web 蜜罐（9000）

9000 端口模拟 Coremail 邮件系统。页面标题为 Coremail邮件系统，登录表单包含 uid/name=username 与 password 字段，关键脚本为 common/assets/login/login.js。该 JS 主要负责页面交互和表单提交，不直接负责将爆破结果写入数据库。

../common/assets/83306/jquery/jquery-1.8.2.min.js../common/assets/login/login.js

5.4 Web 通用响应头指纹

虽然 8080、8081、9000 分别伪装为不同系统，但它们的 HTTP 响应头高度一致，体现出 HFish Web 框架的共性特征。

Header	HFish 表现	分析价值
Server	JSP3/2.0.14	跨多个 Web 蜜罐复用，具有较强指纹价值
Content-Md5	随机字符串	值会变化，但字段名稳定
Ohc-Cache-Hit	随机字符串	字段名较特殊，适合做 Header 指纹
Set-Cookie	session=32位hex	不同伪装页面均使用统一 session 格式
Timing-Allow-Origin	*	跨模板复用，可作为辅助特征

因此，Web 类 HFish 识别不应只看页面标题，而应综合标题、表单路径、JS 资源、响应头字段和端口组合进行判断。

这是web类的蜜罐在国内的分布情况

5.5 登录爆破记录机制分析

Web 蜜罐的账号密码记录并不是由某个前端 JS 直接写库完成。前端页面主要模拟真实系统登录体验，攻击者提交用户名和密码后，请求到达 hfish-server，由后端根据端口和模板识别服务类型，再写入数据库。

后台“账号密码”页面对应的前端文件为 /opt/hfish/3.3.6/web/assets/Username.c96da552.js，其中可见如下 API 字符串：

/v1/asset/passwords/v1/asset/passwords/stats/v1/asset/passwords/keyword/v1/asset/passwords/export

这些 API 用于后台展示、统计、搜索和导出已捕获的账号密码；真正的捕获逻辑位于 hfish-server 后端，而非诱捕页面前端 JS。

组件	作用
伪装登录页	模拟真实系统页面，引导攻击者提交账号密码
/login	不同 Web 模板统一使用或包含的登录提交入口
hfish-server	处理请求、识别服务、记录攻击行为与凭据
hfish.passwords 表	保存用户名、密码、来源 IP、目标端口、服务类型、时间等信息
Username.c96da552.js	管理后台账号密码页面，调用 /v1/asset/passwords 相关 API 展示数据

这样类似的就是明显的爆破流量

六、Wireshark 抓包与过滤方法

在本实验环境中，Windows 主机与 Ubuntu 虚拟机之间的通信经过 VMware Network Adapter VMnet8，因此 Wireshark 应监听 VMnet8。抓包时建议按协议分开采集，每个协议单独保存一个 pcapng 文件，便于后续复盘和截图。

分析目标	Wireshark 显示过滤器
所有 HFish 流量	ip.addr == 192.168.111.128 && tcp
SSH 蜜罐	ip.addr == 192.168.111.128 && tcp.port == 22
Telnet 蜜罐	ip.addr == 192.168.111.128 && tcp.port == 23
Redis 蜜罐	ip.addr == 192.168.111.128 && tcp.port == 6379
Elasticsearch 蜜罐	ip.addr == 192.168.111.128 && tcp.port == 9200
Web 类蜜罐	http && ip.addr == 192.168.111.128
Web 登录请求	http.request.method == "POST" && http.request.uri contains "login"
单个 TCP 会话	选中数据包后 Follow -> TCP Stream

不同协议的可见内容不同。Telnet、Redis 明文输入和 HTTP 请求可直接在 Follow TCP Stream 中观察；SSH 在密钥交换后进入加密阶段，主要分析 Banner 与协商过程；Web 登录请求可观察表单字段和响应头。

协议	建议抓包动作	重点观察内容
SSH	ssh test@192.168.111.128	服务端 Banner、客户端 Banner、KEXINIT、HostKey
Telnet	telnet 192.168.111.128 23 后输入任意内容	无 login 提示、固定返回 test
Redis	发送 PING、INFO、RESP PING	ING、NFO、+ok 异常返回
Web	访问 8080/8081/9000 并提交登录表单	POST /login、username/password、响应头特征
Elasticsearch	访问 http://192.168.111.128:9200/	固定 JSON、Content-Type、Set-Cookie

七、自动化检测思路

在掌握各协议特征后，可以将其转化为自动化检测规则。建议采用“单协议强特征 + 多端口组合特征”的方式，减少误报。

检测对象	规则思路	置信度
SSH	22 端口 Banner 等于 SSH-2.0-OpenSSH_7.4，且系统指纹或其他服务与其不一致	中
Telnet	连接 23 端口后输入任意字符串，固定返回 test\r\n	高
Redis	RESP PING 返回 +ok 而非 +PONG，或 PING 返回 ING	高
Elasticsearch	根路径 JSON 中 version.number 为空且 lucene_version=4.10.2，并伴随 session Cookie	高
Web	多个 Web 端口同时出现 JSP3/2.0.14、Content-Md5、Ohc-Cache-Hit、session Cookie	高
组合判断	同一 IP 同时暴露 SSH/Telnet/Redis/ES/Web 多种模板化服务	高

自动化脚本可以优先进行轻量探测：读取 SSH Banner，连接 Telnet 后发送一行测试字符串，对 Redis 发送 RESP PING，对 9200 请求根路径，对 Web 端口读取响应头。最终根据命中特征数量进行评分，而不是依赖单个特征直接下结论。

八、HFish 不同版本的特征差异分析

前文基于 HFish 3.3.6 实验环境总结了 SSH、Telnet、Redis、Elasticsearch 以及 Web 类蜜罐的流量与协议特征。需要注意的是，蜜罐指纹并非所有版本完全一致。HFish 在不同版本中可能更新服务模板、前端资源、协议模拟逻辑和默认配置，因此在实际分析时应区分“跨版本稳定特征”和“版本强相关特征”。

总体来看，跨版本更稳定的是多协议集中暴露、低交互模板化响应、协议实现不完整、多个 Web 模板复用同一响应头框架等高层行为特征；而具体 JS 文件名、静态资源 hash、页面注释、固定 Banner 字符串和部分返回内容则更容易随版本变化。

8.1 特征稳定性分级

特征类型	跨版本稳定性	说明
多端口组合特征	高	同一 IP 同时暴露 SSH、Telnet、Redis、Elasticsearch、ESXi、Coremail、IOT-HIKCAM 等多类诱捕服务，这类组合特征通常比单一字符串更稳定。
低交互协议异常	中高	例如 Telnet 固定返回、Redis 异常响应等，本质是协议模拟不完整导致的行为特征，具体返回字符串可能随版本变化。
Web 通用响应头	中	3.3.6 中可见 Server: JSP3/2.0.14、Content-Md5、Ohc-Cache-Hit、session Cookie、Timing-Allow-Origin: *，其他版本需实测确认。
页面模板与静态资源	低	页面标题、JS 路径、资源 hash、HTML 注释可能随版本和模板更新变化，不适合作为单独强判定依据。
管理后台 JS 文件名	很低	例如 Username.c96da552.js 这类带 hash 的构建产物具有明显版本相关性，不适合作为跨版本通用指纹。
单个协议 Banner	中	SSH Banner、ES JSON 字段等直观但可能被模板或配置修改，应结合其他特征综合判断。

8.2 HFish 2.x 系列特征差异

HFish 2.x 属于较早版本，其管理端前端资源、内置蜜罐服务数量、Web 模板和协议模拟逻辑可能与 3.3.6 存在明显差异。因此，不能直接将 3.3.6 中发现的 JSP3/2.0.14、Ohc-Cache-Hit、Content-Md5、Username.c96da552.js 等具体特征无条件套用到 2.x 版本上。

对 2.x 版本更适合采用抽象层面的检测思路：观察是否存在多协议集中暴露、低交互固定响应、协议实现不完整、Web 页面模板化以及同一主机多个端口返回风格一致等现象。

8.3 HFish 3.0/3.1 系列特征差异

HFish 3.0/3.1 系列与 3.3.6 同属 3.x 大版本，整体架构和多服务诱捕思路更接近。因此，多端口组合特征、低交互协议异常、Web 模板复用等行为特征可能具有一定延续性。

但 3.0/3.1 与 3.3.6 之间仍可能存在前端打包文件名、后台 API 资源、默认模板内容、协议返回字段等差异。因此，在对 3.0/3.1 版本进行识别时，应避免将 3.3.6 的某个文件名或某条固定字符串作为唯一判断依据。

8.4 HFish 3.3.x 系列特征差异

HFish 3.3.x 系列内部版本差异相对较小，3.3.6 中发现的特征对 3.3.x 版本具有较高参考价值。尤其是 Web 类蜜罐通用响应头、session Cookie 格式、固定登录失败逻辑、Redis 异常响应、Telnet 模板化交互和 Elasticsearch 固定 JSON 等特征，更可能在同系列版本中复现。

不过，即使在 3.3.x 系列内部，静态资源文件名和前端构建 hash 仍然可能变化。例如 Username.c96da552.js 这类文件名只应作为分析当前样本的证据，而不应作为跨版本检测规则。

8.5 按协议划分的版本差异

协议/模块	3.3.6 已验证特征	其他版本可能变化点	跨版本检测建议
SSH	服务端 Banner 为 SSH-2.0-OpenSSH_7.4	Banner 字符串、KEX 算法列表、HostKey 类型和指纹可能变化	不要只依赖 OpenSSH_7.4，应结合 Banner、算法列表、HostKey、认证失败行为和多端口组合判断。
Telnet	连接后无标准 login/password 提示，任意输入返回 test	是否主动输出 login、是否进行 IAC 协商、固定返回内容可能变化	重点关注“缺少真实登录上下文”和“返回高度模板化”，而不是只看 test 字符串。
Redis	PING 返回 ING，INFO 返回 NFO，RESP PING 返回 +ok	可能修正为 +PONG，或伪造 INFO 输出，明文回显逻辑可能变化	重点检测是否符合真实 Redis 协议行为，将异常响应作为蜜罐证据。
Elasticsearch	cluster_name=elasticsearch、lucene_version=4.10.2、tagline=You Know, for Search	ES 模板版本、lucene_version、build_hash、version.number、Content-Type 可能变化	该三元组适合作为 3.3.x 类 ES 蜜罐强特征，跨版本需结合 JSON 完整性、字段异常和 Cookie/Header 判断。
Web 蜜罐	Server: JSP3/2.0.14、Content-Md5、Ohc-Cache-Hit、session Cookie、Timing-Allow-Origin: *	Server Header、登录失败提示、页面模板、JS 资源路径、HTML 注释可能变化	优先使用多个 Web 模板共同复用的 Header 框架和固定登录失败逻辑，降低误报。
后台前端资源	Username.c96da552.js 中存在 /v1/asset/passwords 相关 API	文件名 hash 和打包结构很容易变化	不要将具体 JS 文件名作为规则，应关注 API 功能路径和后台展示逻辑。

8.6 Elasticsearch 蜜罐版本指纹说明

对于本文实验中的 HFish 3.3.6，Elasticsearch 蜜罐的核心指纹可以归纳为 cluster_name: elasticsearch、lucene_version: 4.10.2、tagline: You Know, for Search 三者组合。单一字段可能存在偶然性，但三者同时出现时，具有明显的模板化返回特征。

cluster_name: elasticsearch

lucene_version: 4.10.2

tagline: You Know, for Search

在实际检测中，可以将该三元组作为识别 HFish 3.3.x 类 Elasticsearch 蜜罐的重要依据。但对更早版本或未来版本，应保留弹性判断逻辑，例如同时关注 version.number 是否为空、name 是否为空、build_hash 是否固定、响应头中是否出现 session Cookie，以及 Content-Type 是否与真实 Elasticsearch 行为一致。

8.7 Web 蜜罐版本指纹说明

Web 类蜜罐受版本影响最大。以 8080 端口的 IOT-HIKCAM 模板为例，Login 标题、username/password 字段、sea.js 脚本并非强蜜罐特征，普通 Web 系统也可能出现这些元素。更可靠的是 HFish Web 框架通用响应头、静态模板复制痕迹以及固定登录失败响应。

Server: JSP3/2.0.14

Content-Md5: <随机字符串>

Ohc-Cache-Hit: <随机字符串>

Set-Cookie: session=<32位hex>

Timing-Allow-Origin: *

POST /login -> window.alert("用户名或密码错误");window.history.back();

其中，Server、Content-Md5、Ohc-Cache-Hit、session Cookie 和 Timing-Allow-Origin 的组合比单独的页面标题或 JS 路径更有价值。如果不同版本修改了页面模板，但仍保留同一套响应头框架，则仍然可以通过组合规则识别。

8.8 跨版本检测策略

综合来看，HFish 跨版本检测应采用评分制，而不是单点命中即判定。高权重特征包括 Telnet 任意输入后的模板化返回、Redis 不符合真实协议的异常响应、Elasticsearch 固定 JSON 三元组、多个 Web 模板复用同一响应头框架。低权重特征包括页面标题、JS 文件名、HTML 注释、单个 Header 或单个 Banner。

跨版本评分示例：

+2 多协议集中暴露

+2 Redis RESP PING 返回异常值

+2 Telnet 缺少真实登录上下文且返回固定内容

+2 Elasticsearch 命中 cluster_name/lucene_version/tagline 三元组

+2 Web 命中 Server/Content-Md5/Ohc-Cache-Hit/session/Timing-Allow-Origin 组合

+1 SSH Banner 与系统环境明显不一致

+1 页面模板或静态资源存在复制痕迹

总分越高，目标越可能为 HFish 或同类多协议蜜罐。

这种策略的优点是能够兼容不同版本的细节差异：当某个版本修改了单一字段时，检测结果不会完全失效；当多个独立协议或多个独立层面的特征同时命中时，整体置信度会明显提高。

8.9 小结

HFish 不同版本之间，页面模板、静态资源、JS 文件名和部分协议返回可能发生变化，因此不能将单一字符串作为所有版本的通用指纹。跨版本更稳定的是多服务集中暴露、低交互固定响应、协议实现不完整以及 Web 响应头框架复用等行为特征。对于本文实验使用的 3.3.6，可将 SSH OpenSSH_7.4、Telnet test、Redis +ok/ING/NFO、Elasticsearch 三元组和 Web 通用响应头作为已验证特征；对于其他版本，则应以这些特征为基础进行实测确认和组合判断。

九、总结

HFish 蜜罐的识别不能只依赖端口开放情况，而应结合协议返回、响应模板、上下文交互、HTTP Header 和多端口组合进行综合分析。当前实验环境中，22 端口 SSH 伪装为 OpenSSH_7.4，23 端口 Telnet 任意输入固定返回 test，6379 端口 Redis 存在 PING->ING 与 RESP PING->+ok 的异常响应，9200 端口 Elasticsearch 返回固定 JSON，8080/8081/9000 Web 蜜罐复用 JSP3/2.0.14、Content-Md5、Ohc-Cache-Hit、Set-Cookie 等通用响应头，这些都构成了较稳定的 HFish 流量与协议特征。

从防守运营角度，这些特征可以帮助验证蜜罐是否正常接管端口、是否能够记录爆破行为以及如何在流量审计中快速定位蜜罐交互。从协议研究角度，这些差异也说明低交互蜜罐在模拟真实服务时容易留下模板化痕迹。后续可继续补充 pcapng 样本截图、自动化探测脚本、Suricata/Snort 规则以及不同 HFish 版本之间的特征差异对比。