简介HFish v2.2.0 是一套开放源码的跨平台蜜罐系统面向网络安全研究人员、安全运维人员以及需要开展攻防实验的高校师生用于搭建诱捕环境、监控并记录攻击者行为为防御策略提供数据支撑。压缩包共 349 个文件约 33.77MB以 Go 语言源码为主体辅以前端 js、css 与 hf 配置模板并包含 html、png、svg 等界面资源以及 sql、yml、dockerfile、sh 等部署与数据脚本目录结构清晰便于按模块阅读与二次开发。资源附有说明文档可帮助读者快速理解安装配置与使用方式。目前已有 311 人学习下载。源码可读性强、注释详尽读者既能深入理解蜜罐工作机制也能基于预设配置快速部署或按需修改源码实现自定义功能在真实攻防场景中积累威胁分析与响应经验。1. 从一份 v2.2.0 源码包说起HFish 到底能帮你防住什么很多人第一次听到「蜜罐」这个词脑子里浮现的是个铁疙瘩跟网络安全八竿子打不着。但如果你在甲方做过安全运营或者带过网络安全方向的毕业设计大概率被同一个问题折磨过日志里全是扫描告警可真要问「攻击者到底想干什么、用了什么手法、下一步会打哪」手里一点像样的证据都拿不出来。HFish 跨平台蜜罐平台 v2.2.0 就是冲着这个痛点来的——它把一组伪装成脆弱服务的诱饵节点铺到网络里谁碰、怎么碰、碰完干了什么全给你记下来。这份资源是带源码的压缩包解压后能看到 HFish 主目录、说明.htm以及一批前端样式文件bootstrap、dashicons、weather-icons 等意味着它不只是个能跑的黑盒而是可以拆开看、按需改的教学与实战素材。适合安全运营、渗透测试、以及拿它做课程设计或论文案例的同学。2. 蜜罐的诱饵逻辑与 HFish 的节点架构为什么它比单纯开个端口强2.1 诱饵不是「多开几个端口」那么简单刚接触蜜罐的人容易有个误解我在服务器上开个 22 端口、放个假 SSH不就是蜜罐了吗真跑起来你会发现这种「裸端口」只能记录到连接 IP 和尝试的用户名攻击者一旦发现 banner 不对扭头就走你拿到的数据薄得可怜。HFish 的思路是把诱饵做成有「服务质感」的节点它内置了多种协议模板SSH、RDP、MySQL、Redis、HTTP 这些常见服务都有对应的仿真响应攻击者连上来会看到像模像样的交互愿意多停留几步你才能采集到登录尝试、命令输入、payload 上传这类高价值行为。从架构上看HFish 走的是「管理端 诱饵节点」的分离设计。管理端负责下发配置、汇总告警、展示攻击地图诱饵节点部署在你要监控的网段里独立运行、独立上报。这个设计的好处是你可以在 DMZ、办公网、甚至云主机上各放一个节点管理端统一收口。源码包里那堆 bootstrap、dashicons 样式文件正是管理端 Web 界面用的说明这套 UI 是打包在源码里的你改完前端重新构建就能生效不用去猜它用了什么闭源组件。提示诱饵节点和管理端之间的通信要提前规划好端口和认证方式别等部署完了才发现节点上报被防火墙拦了这是最常见的「部署完没数据」原因。2.2 源码目录里藏着哪些可改的点解压 v2.2.0 的包你会看到 HFish 主程序目录、说明.htm以及一批 css 文件。说明.htm 是安装和配置的入口文档建议第一遍先通读尤其是端口占用和默认账号那几段。源码部分的价值在于你可以改诱饵的响应内容。比如默认的 SSH banner 是某个通用版本攻击者库里有指纹一眼就认出来是蜜罐你把 banner 改成和目标网段里真实服务器一致的版本号诱饵的可信度立刻上一个台阶。具体怎么改找到诱饵服务对应的配置或模板文件通常在节点目录下的 config 或 template 相关路径里。改之前先备份原文件改完重启节点然后用另一台机器 telnet 或 nc 连上去看 banner 有没有生效。这个验证动作别省我见过有人改完配置没重启排查了半天以为改错了地方。2.3 部署前必须想清楚的两个参数第一个是节点监听端口。HFish 默认会占用一批端口来模拟不同服务如果你的诱饵机同时还跑着真实业务端口冲突是必然的。部署前用netstat -tulnp把现有监听列出来跟 HFish 默认端口表对一遍冲突的要么改 HFish 配置要么把诱饵放到独立主机上。第二个是告警上报频率。节点采集到的攻击行为要上报到管理端频率太高管理端压力大太低攻击正在进行你却看不到实时数据。常见做法是首次部署用默认值观察一天管理端的负载和告警量再决定要不要调。这个参数没有标准答案取决于你的诱饵暴露面和被扫频率。3. 从解压到第一个诱饵上线Windows 与 Linux 两条部署路径3.1 Linux 下的部署与节点注册Linux 是蜜罐节点最常用的宿主环境因为部署轻、资源占用低。假设你已经把压缩包传到了目标机器下面是完整的落地步骤。# 解压资源包 unzip HFish-v2.2.0.zip -d /opt/hfish # 进入主目录确认文件结构 cd /opt/hfish ls -la # 给主程序加执行权限根据实际二进制文件名调整 chmod x hfish # 前台启动先看启动日志有没有报错 ./hfish启动后管理端默认会监听一个 Web 端口用浏览器访问http://节点IP:管理端口进入管理界面。首次登录用说明.htm 里写的默认账号进去第一件事就是改密码别拖。节点注册的逻辑是管理端生成一个节点安装命令或配置文件你把它放到诱饵机上执行节点就会自动向管理端报到。源码版的好处是你可以直接看节点注册的接口地址和认证 token 是怎么传的如果注册失败顺着日志里的请求地址去排查网络连通性比盲猜快得多。# 查看节点进程是否在跑 ps aux | grep hfish # 查看节点监听端口确认诱饵服务已起来 ss -tulnp | grep hfish # 如果注册失败看节点日志里的上报地址和错误码 tail -f /opt/hfish/logs/node.log参数说明ss -tulnp里的-t是 TCP-u是 UDP-l只看监听状态-n不做域名解析-p显示进程。这条命令用来确认诱饵端口真的在 listen而不是进程活着但服务没起来。tail -f跟日志是排查注册问题的标准动作重点看有没有 connection refused 或 timeout前者是管理端没开或端口不对后者是网络不通。3.2 Windows 下的部署差异Windows 上部署 HFish 节点流程类似但有几个坑。一是防火墙Windows 默认会弹窗询问是否允许程序通信如果你在远程桌面里操作弹窗可能被忽略导致节点起来了但外部连不上。部署前手动在高级防火墙里给 HFish 主程序放行入站规则比等弹窗靠谱。二是路径问题。Windows 下如果解压到带中文或空格的路径某些版本的节点程序会启动失败。我一般直接解压到C:\hfish这种干净路径省得后面排查玄学问题。启动方式可以是双击 exe也可以用命令行命令行能看到实时输出推荐后者。# 进入解压目录 cd C:\hfish # 命令行启动观察输出 .\hfish.exe # 另开一个 PowerShell 窗口确认端口监听 netstat -ano | findstr LISTENING | findstr hfishnetstat -ano里的-a显示所有连接和监听-n以数字形式显示地址和端口-o显示进程 PID。配合findstr过滤能快速定位 HFish 占了哪些端口。如果发现端口没起来先看主程序窗口有没有报错再看防火墙规则。3.3 验证诱饵是否真的「诱」到了人节点上线不等于有效。验证方法是从另一台机器不要从诱饵机本机去连诱饵端口模拟一次攻击行为然后回管理端看有没有产生告警。比如诱饵开了 SSH 仿真你从测试机ssh root诱饵IP -p 诱饵端口随便输个密码管理端应该几秒内出现一条登录尝试记录。如果管理端没数据按这个顺序查诱饵端口是否真的在 listenss或netstat→ 节点到管理端的网络是否通telnet 管理端IP 管理端口→ 节点日志有没有上报失败记录 → 管理端日志有没有收到请求但处理报错。这个链路排查一遍九成问题能定位。4. 源码二次开发与教学案例改造把 HFish 变成你自己的毕设素材4.1 改诱饵响应内容提升仿真度源码版最大的价值在这里。默认诱饵的响应模板是通用的攻击者指纹库一比对就知道是蜜罐。你要做的是让诱饵「像目标网段里的一台真实机器」。具体操作找到诱饵服务的模板文件通常在节点目录的 template 或 conf 下里面会有 banner 字符串、响应头、错误提示等字段。把 SSH banner 改成SSH-2.0-OpenSSH_7.4这种和目标环境一致的版本把 HTTP 诱饵的 Server 头改成常见的 nginx 或 Apache 版本号。改完不要只在本机测从另一台机器连上去看响应确认修改生效。这个动作在毕设里可以作为「蜜罐仿真度优化」的实验章节有对比数据改前改后的指纹识别结果论文里能写出东西。4.2 用样式文件做管理端界面定制压缩包里那批 bootstrap、dashicons、weather-icons 的 css 文件是管理端 Web 界面的样式依赖。如果你做的是「蜜罐管理平台设计与实现」这类题目改界面是加分项。找到管理端静态资源目录替换或覆盖对应的 css重新构建前端如果源码带构建脚本或直接刷新页面看效果。常见做法是先不改功能只改配色和 logo验证构建链路通不通通了之后再动布局。这样万一页面崩了你能快速判断是样式问题还是构建问题。改前端有个好处答辩时演示效果直观老师一眼能看到你做了工作。4.3 日志导出与数据分析模块的对接HFish 管理端自带告警展示但毕设往往要求「数据分析」。你可以把管理端的告警数据通过接口导出用 Python 做二次分析。下面是一个读取导出数据并做来源 IP 统计的示例。import json from collections import Counter # 假设从管理端导出的告警数据是 JSON 格式 with open(hfish_alerts.json, r, encodingutf-8) as f: alerts json.load(f) # 统计攻击来源 IP 频次 src_ips [item[src_ip] for item in alerts if src_ip in item] ip_counter Counter(src_ips) # 输出 Top 10 来源 IP for ip, count in ip_counter.most_common(10): print(f{ip}: {count} 次) # 统计被攻击最多的诱饵端口 ports [item[dst_port] for item in alerts if dst_port in item] port_counter Counter(ports) print(被攻击端口分布:, port_counter.most_common(5))逻辑说明这段代码假设你已经从管理端导出了 JSON 格式的告警数据字段名按实际导出结构调整。Counter用来做频次统计most_common(10)取前 10。参数上encodingutf-8别省告警数据里可能有中文或特殊字符不指定编码在 Windows 上容易报错。这个脚本可以直接放进毕设的「数据分析与可视化」章节配合 matplotlib 出图就是完整的一节。注意导出数据里可能包含真实 IP 和攻击 payload论文或公开材料里要做脱敏处理别直接把原始数据贴上去。5. 避坑与排查HFish 部署中最容易翻车的五个点5.1 管理端能登录但节点一直显示离线现象管理端 Web 能正常打开节点列表里新加的节点状态是灰色或离线。原因通常是节点到管理端的反向连接没通或者节点注册时用的管理端地址是127.0.0.1节点在另一台机器上自然连不上。解决检查节点配置文件里的管理端地址是不是可达 IP在节点机上telnet 管理端IP 管理端口确认连通性不通就查防火墙和安全组。5.2 诱饵端口被真实业务占用导致启动失败现象节点进程起来了但某个诱饵服务没监听日志里报 address already in use。原因诱饵机上有真实业务占了同一端口。解决ss -tulnp找到占用进程要么改 HFish 诱饵端口配置要么把诱饵迁到独立主机。别想着 kill 掉真实业务那是生产事故。5.3 攻击数据暴涨把管理端拖垮现象管理端页面打开极慢数据库体积几天内暴涨。原因诱饵暴露在公网或高风险网段被扫描器高频扫每条连接都产生告警。解决调整告警聚合策略对同一来源 IP 的重复扫描做合并或者把诱饵从公网挪到内网监控点位。源码版可以改上报逻辑加个去重窗口。5.4 改了源码但没重新构建改动不生效现象明明改了模板文件重启后诱饵响应还是老样子。原因HFish 的部分资源是编译进二进制或打包在前端 bundle 里的改源文件不等于改运行时。解决确认你改的是运行时读取的配置文件还是需要重新构建的源码。前者重启生效后者要走构建流程。改之前先看说明.htm 里有没有构建说明。5.5 默认账号没改被扫到现象管理端出现异常登录记录或者配置被篡改。原因部署后没改默认密码管理端口又暴露在可被扫描的网段。解决首次登录强制改密码管理端尽量只在内网或跳板机后访问别图省事直接放公网。6. 进阶技巧用 HFish 做一套可复现的攻击行为分析流程到这一步你已经能把 HFish 跑起来、改起来、排查常见问题了。但蜜罐的真正价值不在「部署完成」而在「从采集到的数据里提炼出可行动的结论」。我一般会走这么一条流程先让诱饵在目标网段静置 24 小时不急着分析让扫描器和自动化工具把「底噪」暴露出来然后把这段时间的告警按来源 IP 和攻击类型做一次聚类区分开「广撒网扫描」和「针对性探测」最后对针对性探测的来源做重点标记看它后续有没有进一步动作。这个流程里有个容易被忽略的技巧给不同诱饵节点打标签。比如 DMZ 区的节点标dmz办公网段标office云主机标cloud。这样在管理端看告警时你能快速判断攻击是来自外部还是内部横向。源码版可以在节点配置里加自定义标签字段上报时带上分析脚本里按标签分组统计。验证这套流程是否有效可以自己做一次「受控攻击」从测试机对诱饵发起一轮模拟扫描和登录尝试看管理端能不能完整记录、标签对不对、聚类结果是否符合预期。这个受控验证在毕设答辩时特别有用老师问「你怎么证明系统有效」你直接演示一遍采集到分析的闭环。# 按节点标签分组统计告警验证标签体系是否生效 import json from collections import defaultdict with open(hfish_alerts.json, r, encodingutf-8) as f: alerts json.load(f) grouped defaultdict(list) for item in alerts: tag item.get(node_tag, unknown) grouped[tag].append(item) for tag, items in grouped.items(): print(f节点标签 [{tag}] 共 {len(items)} 条告警) # 进一步可按攻击类型细分 types defaultdict(int) for it in items: types[it.get(attack_type, other)] 1 print( 攻击类型分布:, dict(types))这段脚本的关键在node_tag字段它依赖你在节点配置里把标签加上并确保上报时携带。如果跑出来全是unknown说明标签没生效回节点配置里检查字段名和上报逻辑。参数上defaultdict省去了判空逻辑get方法给了默认值避免字段缺失直接报错。从那以后我每次部署蜜罐都强制先跑一遍受控攻击验证采集链路确认数据从诱饵到管理端到分析脚本全程通再把它放到真实网段里。这个习惯帮我省掉了好几次「部署完以为在监控其实啥也没采到」的尴尬。希望帮到你。本文还有配套的精品资源点击获取