简介HFish跨平台蜜罐平台v2.2.0源码包面向网络安全研究人员、安全技术人员及计算机相关专业学生用于搭建诱捕式防御环境、监控并记录攻击者行为也可作为毕业设计、课程案例与二次开发的学习素材。压缩包共349个文件约33.77MB以105个Go源码文件为核心辅以45个JavaScript、31个CSS及多套HTML模板构成Web管理界面另含hf配置、SQL脚本、Dockerfile与说明文档覆盖部署、配置与数据分析各环节。目前已有311人学习下载。源码结构清晰、注释详尽读者可据此理解蜜罐工作机制自定义服务与响应策略快速搭建功能完备的蜜罐系统并在模拟攻防中积累日志分析与威胁响应经验。1. 从一份 v2.2.0 源码包说起HFish 跨平台蜜罐平台能解决什么如果你手头正好有一台闲置的云主机或者实验室里几台跑着不同系统的机器想给它们加点“被攻击时能留下证据”的能力HFish 跨平台蜜罐平台 v2.2.0 的源码包就是一个可以直接拆开研究的对象。它不是一个只跑在 Linux 上的脚本集合而是能在 Windows、Linux、macOS 上部署的蜜罐系统压缩包里带着完整的源码、前端样式文件、说明文档以及一套可以快速搭起诱饵服务的配置模板。对于做网络安全课程设计、毕业设计或者想在自己的实验环境里观察扫描器行为的人来说这份资源的价值在于你能看到蜜罐从服务模拟、日志记录到告警展示的完整链路而不是只拿到一个黑匣子二进制。我拿到这个包的第一反应是翻目录结构。CONTRIBUTORS、style.css、weather-icons-wind.min.css、bootstrap.css、dashicons.min.css这些文件说明前端用了 Bootstrap 和 Dashicons 图标库界面层是典型的 Web 管理后台风格。源码开放意味着你可以改告警规则、加自定义蜜罐服务、甚至把日志格式对接进自己的 SIEM。适合谁安全运维想低成本布防的、学生要做攻防演示的、开发想学蜜罐服务模拟原理的都能从这份 v2.2.0 里找到下手的地方。接下来我不讲空泛的“蜜罐很重要”直接按“怎么跑起来、怎么配、坑在哪”的顺序拆。2. 部署前必须搞清的三件事运行模式、端口规划与源码结构2.1 管理端与节点端分离的架构逻辑HFish 的部署模型不是单进程一把梭。它把管理端和节点端拆开了管理端负责接收节点上报的数据、展示告警、配置蜜罐模板节点端负责在目标机器上真正监听端口、模拟服务、记录攻击载荷。这种分离设计的好处是你可以在 A 机器上跑管理端在 B、C、D 机器上只部署节点节点把数据回传给管理端。对于跨平台场景这意味着 Windows 节点和 Linux 节点可以同时接入同一个管理后台日志格式统一。为什么强调这一点因为很多人第一次解压后直接双击主程序发现 Web 界面能打开但没有任何攻击数据原因就是只启动了管理端没在本地或远程部署节点。常见做法是先在一台机器上启动管理端记下它的 IP 和通信端口然后去节点机器上配置指向这个 IP。源码里管理端和节点端的入口是分开的编译或运行时要注意区分。2.2 端口占用与防火墙放行清单蜜罐的本质是“假装有服务在跑”所以它会监听一批常见端口来吸引扫描。HFish v2.2.0 默认会模拟 SSH、HTTP、MySQL、Redis、Telnet 等服务对应端口通常是 22、80、3306、6379、23 等。如果你部署节点的机器上本身已经跑了真实的 SSH 或 Web 服务就会冲突。我一般会先把节点机器上不必要的服务停掉或者修改蜜罐模板里的监听端口改成不常用的高位端口。防火墙是第二个卡点。管理端和节点端之间需要通信节点上报数据、管理端下发配置都走这个通道。如果节点在云主机上安全组里必须放行管理端的通信端口否则你在后台看到节点状态永远是“离线”。下面这张表是我部署时习惯先核对一遍的端口清单用途默认端口是否可改注意点管理端 Web 界面4433可改浏览器访问用建议只对内网开放管理端与节点通信4434可改节点配置里要填对安全组放行蜜罐 SSH 模拟22可改与真实 SSH 冲突时改高位端口蜜罐 HTTP 模拟80可改同上避免和真实 Web 服务抢蜜罐 MySQL 模拟3306可改数据库机器上尤其注意提示改端口不是改一个地方就完事。管理端配置、节点配置、蜜罐模板三处要同步改漏一处就会出现“节点在线但蜜罐不生效”的玄学问题。2.3 源码目录里哪些文件值得先看解压后不要急着运行先花十分钟翻目录。说明.htm是安装指南虽然写得比较简略但能告诉你管理端和节点端的启动顺序。前端样式文件集中在style.css、bootstrap.css、dashicons.min.css这些里面如果你要改管理后台的界面从这里入手。weather-icons-wind.min.css和weather-icons.css是图标字体不影响核心功能但说明前端资源是打包好的二次开发时别误删。真正要关注的是节点端的服务模拟逻辑和日志上报模块。源码里通常会有类似node、server、web这样的目录划分。我一般会先找到节点端启动入口看它加载了哪些蜜罐模板模板里定义了监听端口、模拟的服务 banner、记录哪些字段。理解了这个你才能自定义一个新的蜜罐服务比如模拟一个假的 Docker API 端口。3. 从解压到第一个告警管理端与节点端的实操配置3.1 启动管理端并完成初始化管理端的启动方式取决于你拿到的包是编译好的二进制还是需要自己编译的源码。如果是二进制直接运行主程序如果是源码按说明.htm里的构建步骤来。启动后浏览器访问https://管理端IP:4433第一次会要求设置管理员账号和密码。这个初始化步骤只能做一次密码忘了就得清数据库所以别随手设一个然后丢掉。# 以 Linux 为例进入解压后的目录 cd HFish-v2.2.0 # 查看说明文件确认启动命令 ls -la # 常见启动方式直接运行管理端二进制 ./hfish-manage # 或者如果是源码包按说明先安装依赖再启动上面这段命令的关键是确认启动入口。hfish-manage只是示例名实际文件名以你解压后看到的为准。启动后终端会打印监听地址和端口记下来。如果启动报错提示端口被占用用netstat -tlnp | grep 4433查一下谁占了换端口或停掉冲突进程。3.2 节点端配置指向管理端节点端可以和管理端在同一台机器也可以分开。分开部署时节点端配置文件里要填管理端的 IP 和通信端口。这个配置文件通常是 JSON 或 YAML 格式在节点端目录下。改完之后重启节点端服务然后去管理后台的“节点管理”页面看状态。# 节点端配置示例以 JSON 为例实际字段名以源码为准 { manage_ip: 192.168.1.100, // 管理端 IP manage_port: 4434, // 管理端通信端口 node_name: test-node-01, // 节点名称后台显示用 heartbeat_interval: 30 // 心跳间隔秒 }manage_ip和manage_port必须和管理端实际监听的一致否则节点会一直重连失败。node_name建议用有意义的名字比如按机房或用途命名后面看告警时能快速定位是哪台机器被扫了。heartbeat_interval默认 30 秒够用网络不稳定可以调大但别超过 120 秒否则后台会误判节点离线。3.3 选择蜜罐模板并验证告警链路节点上线后在管理后台的“蜜罐管理”里选择要启用的模板。v2.2.0 通常预置了 SSH、HTTP、MySQL、Redis 等常见服务的模拟模板。勾选启用后节点端会开始监听对应端口。验证方法很简单从另一台机器用nmap扫一下节点 IP 的对应端口或者直接用ssh尝试连接蜜罐的 22 端口随便输个用户名密码。# 从测试机扫描节点触发蜜罐 nmap -sS -p 22,80,3306,6379 192.168.1.101 # 或者尝试 SSH 连接蜜罐端口 ssh test192.168.1.101 -p 22 # 输入任意密码后去管理后台看是否产生告警如果扫描后后台没有告警按这个顺序排查节点状态是否在线、蜜罐模板是否启用、节点机器防火墙是否放行了蜜罐端口、管理端和节点端时间是否同步时间差太大会导致日志排序混乱。我遇到过节点在线、模板也启用了但告警就是不来的情况最后发现是节点机器上 iptables 默认拒绝入站蜜罐端口根本没被外部访问到。这种坑后面还会细说。4. 避坑与排查部署 HFish 时最容易翻车的五个地方4.1 节点显示在线但蜜罐端口不通现象管理后台节点状态是绿色在线但扫描蜜罐端口没有任何响应后台也无告警。原因节点端和管理端的通信走的是管理端口这个通道正常不代表蜜罐监听端口正常。常见原因是节点机器防火墙拦截了蜜罐端口或者蜜罐模板虽然启用了但节点端进程没有真正绑定端口。解决先在节点机器上执行netstat -tlnp | grep 蜜罐端口确认进程是否在监听。如果没有监听检查节点端日志看模板加载是否报错。如果有监听但外部扫不通检查 iptables 或云安全组是否放行了该端口。4.2 管理端 Web 界面打不开或证书报错现象浏览器访问管理端地址时提示连接被拒绝或者证书不受信任。原因管理端默认用 HTTPS 自签名证书浏览器会拦截。连接被拒绝通常是管理端进程没启动成功或者端口被占用。解决自签名证书报错点“高级”继续访问即可生产环境建议换正式证书。连接被拒绝先看管理端进程是否在跑ps aux | grep hfish查一下再看端口监听netstat -tlnp | grep 4433。如果端口被占改管理端配置里的 Web 端口。4.3 节点端配置改了但重启后不生效现象修改了节点端配置文件里的管理端 IP重启节点后后台还是显示旧 IP 或离线。原因有些版本的节点端会把配置缓存到本地数据库或临时文件里直接改配置文件后重启进程可能读的是缓存。解决先停节点进程删掉节点目录下的缓存文件常见是data或db目录再改配置文件最后启动。或者直接在管理后台删除该节点重新添加节点并生成新的配置。4.4 蜜罐日志暴涨导致磁盘写满现象节点运行一段时间后磁盘告警发现日志文件几个 GB。原因蜜罐被大量扫描时每个连接都会记录日志如果不做轮转和清理日志会迅速膨胀。解决在管理端设置日志保留天数或者用系统 logrotate 对节点日志目录做轮转。我一般会把日志保留设为 7 天同时监控磁盘使用率超过 80% 就手动清理旧日志。4.5 时间不同步导致告警时间错乱现象后台告警列表里时间顺序混乱或者节点心跳超时误报。原因管理端和节点端系统时间不一致差几分钟就会导致日志时间戳对不上。解决所有部署 HFish 的机器都开启 NTP 时间同步。Linux 上用timedatectl set-ntp trueWindows 上在服务里启动 Windows Time 并配置同步源。这个坑很隐蔽但排查起来很费时间建议部署前就统一时间。5. 进阶用法自定义蜜罐模板与源码二次开发切入点5.1 照着现有模板改一个假 Docker API 蜜罐HFish v2.2.0 的蜜罐模板本质上是定义“监听哪个端口、返回什么 banner、记录哪些字段”。你可以找一个现有的 HTTP 模板复制一份改端口和响应内容模拟一个假的 Docker Remote API。攻击者扫描到 2375 端口并尝试访问/containers/json时蜜罐返回一个伪造的容器列表同时记录请求的 IP、User-Agent 和路径。# 伪代码示意自定义蜜罐服务的响应逻辑 def handle_docker_api(request): # 记录攻击者信息 log_attack( iprequest.remote_addr, pathrequest.path, uarequest.headers.get(User-Agent) ) # 返回伪造的容器列表诱导攻击者继续交互 if request.path /containers/json: return jsonify([{Id: fake_container_id, Image: nginx:latest}]) return jsonify({message: Docker API is running})这段逻辑的关键是“像真的但又不是真的”。返回的数据要足够让扫描器认为这是一个可交互的 Docker API但不能暴露真实环境信息。记录字段里User-Agent和请求路径是分析攻击者意图的重要线索。改完模板后在管理端重新加载配置节点端会自动同步。5.2 从源码里找日志上报和告警触发点如果你要做二次开发比如把告警推送到自己的钉钉或企业微信机器人需要找到源码里的告警触发模块。通常在管理端的alert或notify目录下会有邮件、Webhook 等通知方式的实现。照着现有的 Webhook 实现加一个自定义通知渠道比从头写要快得多。改完后重新编译管理端或者如果是脚本语言写的直接重启进程即可。验证自定义告警是否生效可以用curl手动触发一次蜜罐连接然后看通知渠道是否收到消息。我习惯在改完通知模块后先用一个测试蜜罐端口做一次完整链路验证扫描 → 节点记录 → 上报管理端 → 触发告警 → 收到通知。任何一环断了就去看对应模块的日志。5.3 源码阅读与二次开发的边界HFish 的源码可读性不错但要注意版本差异。v2.2.0 的前端资源文件bootstrap.css、dashicons.min.css等是打包好的改界面直接改这些文件可能被下次构建覆盖正确做法是改源样式文件再重新构建。后端逻辑改动前先确认你改的模块是否涉及数据上报协议如果改了协议格式管理端和节点端要同步更新否则会出现节点在线但数据解析失败的情况。从那以后我每次改 HFish 源码都强制走一遍“改配置 → 重启 → 扫描验证 → 看日志 → 确认告警”的完整流程不跳过任何一步。希望这份拆解能帮到你少走几个我踩过的坑。本文还有配套的精品资源点击获取