简介：HFish跨平台蜜罐平台 v2.2.0 源码包面向网络安全研究人员、安全运维人员及计算机相关专业学生，提供一套可自主部署、可二次开发的开源蜜罐系统，用于攻击行为监控、威胁情报采集与攻防教学实践。压缩包共349个文件，约33.77MB，以Go语言源码为主体，辅以JavaScript、CSS、HTML等前端资源及图片、字体、地图文件，另含SQL脚本、Dockerfile、YAML配置与说明文档，结构完整，便于理解系统架构与部署流程。目前已有311人学习下载。源码注释详尽、模块划分清晰，读者可据此掌握蜜罐服务配置、日志分析与告警机制，并基于预设模板快速搭建实验环境，适合用于毕业设计、课程案例与安全防御策略研究。
1. 从一台 HFish 蜜罐说起：跨平台蜜罐平台到底在防什么
很多人第一次听到「蜜罐」这个词，脑子里浮现的是安全圈的黑话，觉得离自己很远。但如果你手上管着几台公网服务器，或者公司有一小段暴露在外的业务网段，你大概率已经被扫过、被爆破过、被当成跳板试探过。HFish 这类跨平台蜜罐平台解决的，就是「我不知道谁在打我、用什么手法打我」这个黑匣子问题。它把一堆仿真服务部署在诱饵节点上，把攻击者的源 IP、尝试的账号密码、执行的命令、上传的文件全部记下来，形成一份可追溯的威胁情报。标题里的 v2.2.0.zip 是一个可直接部署的发行包，跨平台意味着它能在 Linux、Windows、macOS 上跑起来，不挑环境。这篇文章面向的是想真正把蜜罐用起来的安全运维、渗透测试和中小团队负责人，不是让你背概念，而是让你从零把它跑通、看懂数据、避开部署时最容易翻车的那几个点。
2. HFish 的架构与部署选型：为什么它适合中小团队落地
2.1 管理端与节点分离的设计逻辑
HFish 的核心架构是「一个管理端 + 多个节点」的模式。管理端负责接收节点上报的数据、展示攻击地图、管理蜜罐模板和告警规则；节点负责在目标网络里实际监听端口、仿真服务、捕获流量。这种分离设计有两个直接好处：第一，你可以在不同网段、不同云厂商的机器上部署节点，统一汇总到一个管理端，形成跨区域的攻击面感知；第二，节点被攻击者识破甚至打挂，管理端的数据不受影响，取证链条不会断。
常见做法是管理端部署在一台内网机器或者有固定公网 IP 的轻量服务器上，节点部署在需要监控的业务网段边缘。节点和管理端之间通过一个固定的通信端口保持心跳，默认走 TCP，部署时要确保这个端口双向可达。如果你在内网做实验，管理端和节点可以放在同一台机器上，但生产环境不建议这么干，因为一旦这台机器被拿下，整套感知体系就全丢了。
选型上，HFish 相比自研脚本或者单纯用 iptables 记录日志，优势在于它内置了大量仿真模板：SSH、Telnet、Redis、MySQL、HTTP、FTP 等常见服务的假响应，攻击者连上来会以为是真的服务，从而愿意多花时间尝试，你就能拿到更完整的攻击链。相比商业蜜罐，它的部署成本几乎为零，社区版功能对中小团队足够用。
2.2 跨平台部署的最小步骤与命令
下面以 Linux 环境为例，走一遍从解压到管理端启动的完整流程。Windows 和 macOS 的图形化操作类似，核心是确认端口和防火墙。
# 1. 解压发行包（假设包名为 HFish-v2.2.0.zip） unzip HFish-v2.2.0.zip -d /opt/hfish # 2. 进入管理端目录（不同版本目录名可能略有差异，以实际解压结果为准） cd /opt/hfish # 3. 给可执行文件加权限 chmod +x ./hfish-server # 4. 启动管理端，默认监听 4433 端口（Web 管理界面） ./hfish-server -mode=server # 5. 查看进程是否存活 ps aux | grep hfish-server # 6. 查看监听端口 netstat -tlnp | grep 4433逻辑说明：第一步解压后你会看到 server 和 node 两个方向的启动入口，管理端只需要跑 server。第三步加权限是因为 zip 包在跨平台传输后经常丢失可执行位，这是血泪经验，很多人卡在这里以为程序坏了。第四步的-mode=server是显式指定角色，避免误启动成节点。第六步确认 4433 端口处于 LISTEN 状态，如果没起来，先看防火墙和 SELinux。
参数说明：管理端的 Web 端口默认是 4433，通信端口默认是 4434，这两个端口在部署脚本里可以改，但改完要同步改节点的配置。如果你在云服务器上部署，安全组里要放行 4433 给管理员访问，4434 只对节点 IP 开放，不要对整个公网开放，否则管理端本身就成了攻击目标。
2.3 节点接入管理端的配置要点
节点部署的核心是让它知道管理端在哪、用什么身份上报。
# 在节点机器上进入解压目录 cd /opt/hfish # 启动节点，指定管理端 IP 和通信端口 ./hfish-client -mode=node -server=192.168.1.100:4434 # 确认节点进程 ps aux | grep hfish-client # 在管理端 Web 界面查看节点是否上线 # 浏览器访问 https://192.168.1.100:4433逻辑说明：-server参数填的是管理端的 IP 和通信端口，不是 Web 端口，这两个别搞混。节点启动后会在管理端的「节点管理」页面出现，状态变成在线才算接入成功。如果一直显示离线，先 ping 管理端 IP，再用 telnet 测 4434 端口通不通，最后看节点日志里有没有报连接超时。
参数说明：节点上可以配置多个蜜罐模板，每个模板对应一组监听端口。比如你启用 SSH 模板，节点就会在 22 端口上仿真一个 SSH 服务；启用 Redis 模板，就在 6379 端口上仿真。建议初期只开两三个高频被扫的端口，比如 22、6379、3306，观察一段时间后再逐步增加，避免一次性开太多端口影响宿主机正常业务。
3. 蜜罐模板配置与攻击数据捕获：把诱饵摆对位置
3.1 模板选择与端口映射的实操
HFish 的模板本质上是一组预定义的仿真服务配置。你在管理端界面上勾选模板、下发到节点，节点就会在对应端口上启动监听。这里的关键是「诱饵要像真的」，但又不能影响真实业务。
# 查看当前节点上已启用的监听端口（在节点机器上执行） ss -tlnp | grep hfish # 如果发现 22 端口被真实 SSH 占用，需要把蜜罐的 SSH 模板改到其他端口 # 在管理端界面：节点管理 -> 模板配置 -> SSH -> 修改监听端口为 2222 # 然后重新下发配置到节点逻辑说明：很多 Linux 服务器本身就跑着真实的 SSH 服务，22 端口被占用，蜜罐模板再配 22 就会启动失败。解决办法是把蜜罐的仿真端口改成一个不常用的高位端口，比如 2222、22222，同时在防火墙上把这个端口对公网开放。攻击者扫描时发现 2222 端口有 SSH 响应，一样会尝试爆破，你照样能拿到数据。
参数说明：模板配置里有一个「深度仿真」选项，开启后蜜罐会对攻击者的输入做出更复杂的响应，比如模拟登录失败、模拟命令执行返回。这个选项会增加一点 CPU 开销，但对捕获高质量攻击行为很有帮助。建议对 SSH、Redis 这类高频目标开启，对 HTTP 模板可以按需开启。
3.2 攻击数据的字段解读与告警规则
节点捕获到攻击后，数据会实时上报到管理端。你在「攻击列表」里能看到每条记录的源 IP、目标端口、攻击类型、尝试的账号密码、时间戳。这些字段里最有价值的是「尝试的账号密码」和「攻击类型」，前者能告诉你攻击者用的是哪个字典，后者能区分是暴力破解、漏洞利用还是扫描探测。
# 管理端数据默认存在内置数据库里，可以通过 Web 界面导出 CSV # 如果需要 API 拉取，常见做法是调用管理端的接口（具体路径以实际版本为准） curl -k "https://192.168.1.100:4433/api/v1/attack/list?limit=100" \ -H "Authorization: Bearer <你的token>"逻辑说明：导出 CSV 适合做离线分析，比如统计哪个 IP 攻击次数最多、哪个账号被尝试最多。API 拉取适合接入你自己的 SIEM 或者告警系统。注意-k是跳过证书校验，因为管理端默认用的是自签名证书，生产环境建议换成受信任的证书。
参数说明：告警规则里可以设置「同一 IP 在 N 分钟内攻击超过 M 次就触发告警」。N 建议设 5 到 10 分钟，M 建议设 20 到 50 次，太低会误报，太高会漏掉慢速爆破。告警方式支持邮件和 Webhook，Webhook 可以对接钉钉、飞书或者自建的通知服务。
3.3 用蜜罐数据做溯源与封禁的闭环
蜜罐最大的价值不是「抓到人」，而是「抓到之后能做什么」。一条完整的闭环是：蜜罐捕获攻击 IP → 告警通知 → 自动或手动封禁 → 把 IP 加入威胁情报库。
# 示例：从管理端导出攻击 IP 列表，去重后写入防火墙封禁 curl -k "https://192.168.1.100:4433/api/v1/attack/ips" \ -H "Authorization: Bearer <你的token>" | jq -r '.data[]' | sort -u > /tmp/attacker_ips.txt # 批量添加到 iptables 封禁（谨慎操作，确认不会误封自己的 IP） while read ip; do iptables -I INPUT -s "$ip" -j DROP done < /tmp/attacker_ips.txt逻辑说明：第一步用 API 拉取攻击 IP，jq解析 JSON 取出 IP 字段，sort -u去重。第二步循环写入 iptables 的 INPUT 链，直接丢弃来自这些 IP 的流量。这里必须加一句提醒：封禁前一定要确认列表里没有你自己的办公 IP 或者合作方 IP，否则一封就是事故。
参数说明：iptables 规则是临时的，重启后会丢失。如果要持久化，需要用iptables-save或者把规则写进启动脚本。更稳妥的做法是把封禁动作交给云厂商的安全组或者 WAF，蜜罐只负责产出 IP 列表。
4. 避坑与排查：HFish 部署中最容易翻车的 5 个点
4.1 管理端 4433 端口打不开
现象：浏览器访问https://IP:4433一直转圈或者提示连接被拒绝。
原因：最常见的是云服务器安全组没放行 4433，其次是管理端进程没起来，或者 SELinux 拦截了非标准端口。
解决：先在服务器上curl -k https://127.0.0.1:4433看本地能不能通，本地通说明是安全组问题，去云控制台放行；本地不通就看进程和日志，tail -f管理端目录下的日志文件，看有没有报端口绑定失败。SELinux 的话临时用setenforce 0验证，确认是它的问题后再加策略放行。
4.2 节点一直显示离线
现象：节点进程明明在跑，管理端「节点管理」里状态一直是灰色离线。
原因：节点和管理端之间的 4434 通信端口不通，或者节点启动时-server参数填错了。
解决：在节点机器上telnet 管理端IP 4434，不通就检查中间的网络 ACL 和防火墙。通了还离线，检查节点启动命令里的 IP 是不是写成了 127.0.0.1，这个错误在新手部署里出现频率极高。另外确认管理端和节点的版本一致，跨版本通信有时会握手失败。
4.3 蜜罐端口起不来，日志报「address already in use」
现象：节点下发模板后，对应端口没有监听，日志里提示地址已被占用。
原因：宿主机上已经有真实服务占用了那个端口，比如 22 被真实 SSH 占了，6379 被真实 Redis 占了。
解决：把蜜罐模板的监听端口改成高位端口，比如 2222、16379，然后在安全组里放行新端口。改完后重新下发配置，用ss -tlnp确认新端口处于 LISTEN 状态。不要为了省事去停掉真实业务，蜜罐是来帮忙的，不是来添乱的。
4.4 攻击数据不上报或者上报延迟大
现象：节点本地能看到捕获记录，但管理端界面上迟迟不显示。
原因：节点到管理端的网络抖动，或者管理端数据库写入压力大。
解决：先看节点日志里有没有上报失败的报错，有的话检查 4434 端口的稳定性和带宽。管理端这边，如果攻击量很大，内置数据库可能会成为瓶颈，常见做法是定期清理历史数据，或者把数据导出后归档。延迟在几秒到十几秒内属于正常范围，超过一分钟就要查网络。
4.5 误封自己人导致业务中断
现象：封禁脚本跑完后，办公网访问不了服务器，或者合作方反馈接口不通。
原因：攻击 IP 列表里混入了 NAT 出口 IP，很多办公网和合作方走的是同一个出口，蜜罐看到的是出口 IP，一封就把整个出口封了。
解决：封禁前先做白名单过滤，把已知的办公出口 IP、合作方 IP 段排除掉。更稳妥的做法是只封禁单个 IP，不封整个 C 段，并且封禁动作先跑「观察模式」，只记录不执行，确认一周无误报后再真正下发。这个后悔药一定要提前吃。
5. 进阶技巧：用 HFish 做长期威胁狩猎与情报沉淀
5.1 把蜜罐数据变成可复用的威胁情报
蜜罐跑起来只是第一步，真正拉开差距的是你怎么用这些数据。我一般会做三件事：第一，按周统计攻击源 IP 的归属地和 ASN，找出哪些云厂商的 IP 被大量用作扫描源；第二，提取攻击者尝试的账号密码字典，反哺自己业务的密码策略，看看自己的员工密码有没有出现在字典里；第三，把高频攻击 IP 和攻击手法整理成内部情报简报，发给运维和开发团队，让他们知道当前的真实威胁长什么样。
# 示例：统计攻击 IP 的 ASN 分布（需要提前安装 whois 工具） cut -d',' -f1 /tmp/attack_export.csv | sort -u | while read ip; do asn=$(whois "$ip" | grep -i "origin" | head -1) echo "$ip,$asn" done > /tmp/ip_asn.csv # 按 ASN 聚合计数 cut -d',' -f2 /tmp/ip_asn.csv | sort | uniq -c | sort -rn | head -20逻辑说明：先从导出的 CSV 里取出 IP 列，去重后逐个查 whois 拿 ASN，最后按 ASN 聚合排序。这样你就能看到攻击来源集中在哪些网络，如果某个 ASN 的攻击量异常高，可以考虑在边界设备上对整个 ASN 做限速或者重点监控。
参数说明：whois 查询有频率限制，IP 多的时候要加sleep，不然会被限流。生产环境建议用离线的 IP 库或者商业情报接口，速度和稳定性都更好。
5.2 多节点协同与诱饵编排
当你部署了多个节点后，可以做一些更有意思的编排。比如在 DMZ 区放一个仿真 Web 服务的节点，在内网放一个仿真数据库的节点，攻击者从外到内的横向移动路径就会被完整记录下来。你看到的不再是孤立的攻击事件，而是一条从入口到内网的攻击链。
| 节点位置 | 仿真服务 | 监控目标 |
|---|---|---|
| DMZ 区 | HTTP、SSH | 外部扫描与初始入侵 |
| 办公网 | Redis、MySQL | 横向移动与内网探测 |
| 核心区 | Telnet、FTP | 针对关键资产的定向攻击 |
这张表是我自己在用的一个基础编排，你可以根据业务实际情况调整。核心原则是：诱饵要放在攻击者「顺路」能碰到的地方，太偏了没人碰，太显眼了容易被识破。
5.3 验证蜜罐是否真的在工作
部署完不是就结束了，你得定期验证它是不是还在正常工作。我习惯每周做一次自检：从一台外部机器手动扫描蜜罐端口，看管理端有没有产生对应的攻击记录。如果没有，说明链路断了，可能是节点挂了、端口被封了、或者上报通道堵了。
# 从外部机器模拟一次扫描（仅用于验证自己的蜜罐，不要扫别人） nmap -sT -p 2222,16379 <你的蜜罐节点IP> # 然后去管理端看有没有产生记录 # 如果有记录，说明蜜罐工作正常；如果没有，按第 4 章的排查步骤逐项检查这个自检动作花不了几分钟，但能避免「以为在监控，其实早就瞎了」的尴尬。我吃过这个亏，有一次节点进程被系统 OOM 杀掉后没起来，整整一周没有数据，直到客户问起来才发现。
希望帮到你。
本文还有配套的精品资源，点击获取
