简介HFish跨平台蜜罐平台v2.2.0源码包面向网络安全研究人员、安全运维人员及计算机专业学生用于搭建诱捕环境、监控攻击行为并分析攻防策略。资源共349个文件约33.77MB以Go语言源码为主体辅以JavaScript、CSS、HTML等前端资源及PNG、SVG图标素材另含SQL脚本、Dockerfile、YAML配置与说明文档结构清晰、注释详尽便于理解蜜罐工作机制并进行二次开发。已有311人学习下载。读者可获取完整可编译的蜜罐系统源码结合预设配置快速部署Windows、Linux、macOS多平台环境并通过日志查看、数据分析与报警组件高效管理捕获数据同时适合作为毕业设计或教学案例在模拟真实攻击中积累攻防对抗经验。1. 从一台 HFish 蜜罐说起为什么跨平台部署是刚需很多做安全运营的朋友第一次接触蜜罐都是被上级或甲方一句“能不能把攻击流量引出来看看”问住的。HFish 就是在这个场景里被反复提起的名字——一个开源的跨平台蜜罐平台v2.2.0 这个版本号在圈子里流传很广因为它把 Web 管理端、节点探针、告警通知这几块拼成了一个能直接落地的整体。所谓“跨平台”不是一句宣传语而是指它的管理端和探针能分别跑在 Linux、Windows、macOS 上你可以在云主机上放管理端在办公网 Windows 机器上丢一个探针在测试环境再挂一个统一在一个 Web 界面里看攻击日志。这篇文章不聊虚的就讲清楚三件事HFish 这套东西到底解决什么问题、怎么从零把它跑起来、以及部署和运营过程中那些让人翻车的坑。适合手里有公网 IP、想搭一套低成本攻击诱捕体系的运维和安全从业者。2. HFish 的架构与选型管理端、探针、数据库各管什么2.1 管理端与探针的分工逻辑HFish 的核心设计是“中心管理 分布式探针”。管理端负责 Web 界面、规则配置、告警推送和数据聚合探针负责在目标机器上监听端口、模拟服务、记录攻击行为然后把数据回传给管理端。这个拆分带来的直接好处是你不需要在每台机器上都装一套完整的 Web 服务探针可以很轻管理端可以集中部署在一台有固定公网入口的机器上。为什么强调“跨平台”因为真实网络里你想诱捕的攻击面往往分散在不同操作系统的资产上。比如办公网里大量 Windows 主机DMZ 区是 Linux测试环境可能还有 macOS 做开发机。如果蜜罐只能跑在 Linux 上那 Windows 侧的诱捕能力就是空白。HFish 的探针覆盖了主流平台管理端也提供了对应平台的安装包这才让“一套平台管所有节点”成为可能。从选型角度看HFish 适合中小规模、追求快速上手的场景。它不像一些商业蜜罐那样提供深度交互和沙箱能力但胜在部署简单、协议模板多、告警渠道全。如果你需要的是“先跑起来看到攻击数据”HFish 的投入产出比很高。2.2 数据库与端口规划部署前必须定下来的三件事在动手之前有三件事必须先定下来否则后面改起来很痛苦。第一管理端用什么数据库。HFish 默认使用 SQLite开箱即用适合节点数少、日志量不大的场景。但如果你的探针超过 10 个或者每天攻击日志上万条SQLite 的写入瓶颈就会显现。常见做法是换成 MySQL在管理端配置文件里改数据库连接串即可。这里要注意换库不是改个配置就完事需要先建好库和用户并确保管理端能连通。第二管理端 Web 端口和探针通信端口。管理端默认 Web 端口是 4433探针回连端口是 4434。这两个端口如果和现有服务冲突必须在部署前改掉。尤其是 4433很多云主机安全组默认不放行需要手动开。第三探针部署位置。探针要放在你能控制、且攻击者可能扫到的机器上。常见做法是在 DMZ 区放一个探针模拟 Web 服务在办公网放一个探针模拟 SMB 和 RDP在云主机上放一个探针模拟 SSH。每个探针只开必要的模拟端口不要贪多否则容易和真实业务冲突。下面这张表是部署前需要确认的参数清单配置项默认值建议说明管理端 Web 端口4433按需修改需在安全组放行探针回连端口4434按需修改管理端与探针之间通信数据库SQLite节点多时换 MySQL影响日志写入性能探针模拟端口按模板按实际攻击面选避免与业务端口冲突告警渠道无至少配一种支持邮件、Webhook 等提示端口规划阶段就要把安全组、防火墙、云平台 ACL 一起考虑进去不要等部署完才发现探针回连不上。3. 从零跑通 HFish管理端安装与探针接入的完整步骤3.1 管理端部署Linux 下的最小可用命令管理端是整个平台的大脑先把它跑起来。以下以 Linux 环境为例假设你已经拿到 HFish v2.2.0 的安装包并解压到/opt/hfish目录。# 进入管理端目录 cd /opt/hfish # 给管理端二进制文件执行权限 chmod x hfish-server # 前台启动方便看日志和排错 ./hfish-server # 确认端口监听情况 ss -tlnp | grep -E 4433|4434启动后用浏览器访问https://管理端IP:4433默认账号和密码在安装包的说明文件里首次登录后立即修改。如果页面打不开先检查三件事进程是否在运行、端口是否监听、安全组是否放行。逻辑说明hfish-server是管理端主程序前台启动可以看到初始化日志包括数据库连接、端口绑定、探针通信服务启动等信息。参数方面如果要用 MySQL需要在同目录下的配置文件里修改数据库连接串而不是在命令行传参。配置文件通常叫config.yaml或类似名字具体以安装包内文件为准。3.2 探针安装Windows 与 Linux 的差异点探针的安装比管理端简单但跨平台的差异主要体现在服务注册方式上。Linux 探针# 进入探针目录 cd /opt/hfish-probe # 赋予执行权限 chmod x hfish-probe # 指定管理端地址和回连端口启动 ./hfish-probe -s 管理端IP:4434 # 后台运行建议用 systemd 或 nohup nohup ./hfish-probe -s 管理端IP:4434 probe.log 21 Windows 探针# 以管理员身份打开 PowerShell # 进入探针目录 cd C:\hfish-probe # 注册为 Windows 服务 .\hfish-probe.exe install -s 管理端IP:4434 # 启动服务 net start hfish-probe # 查看服务状态 sc query hfish-probe逻辑说明-s参数指定管理端的 IP 和探针回连端口探针启动后会主动连接管理端并注册自己。Windows 下用install子命令注册服务好处是开机自启、崩溃后自动拉起。Linux 下如果不用 systemd用nohup也能跑但重启后不会自动恢复生产环境建议写一个 systemd unit 文件。参数方面探针的模拟端口是在管理端 Web 界面里配置的不是探针本地配置。也就是说你添加一个探针后要在管理端的“节点管理”里给它分配模板和端口探针会拉取这些配置并生效。3.3 验证探针在线与模拟服务生效探针启动后回到管理端 Web 界面在“节点管理”里应该能看到新节点状态为“在线”。如果显示离线按以下顺序排查探针所在机器能否telnet 管理端IP 4434不通就是网络或安全组问题。管理端日志里有没有探针连接记录没有就是探针没发起到管理端的连接。探针本地日志probe.log里有没有报错常见的是管理端地址写错或端口不对。验证模拟服务是否生效最简单的方法是从另一台机器扫描探针的模拟端口。比如探针模拟了 22 端口 SSH你用ssh 探针IP去连管理端应该很快出现一条攻击日志。如果连了没反应检查管理端里该探针的模板是否启用、端口是否分配。注意不要在探针所在机器上用 localhost 去连模拟端口有些系统会绕过网络栈导致蜜罐记录不到。用另一台机器测。4. 告警配置与日志运营让蜜罐数据真正可用4.1 告警渠道配置邮件与 Webhook 的最小配置蜜罐如果只记录不告警就变成了一个“事后翻日志”的工具价值大打折扣。HFish 支持多种告警渠道最常用的是邮件和 Webhook。邮件告警需要在管理端配置 SMTP 服务器。以常见企业邮箱为例需要填写的参数包括SMTP 服务器地址、端口、发件账号、密码或授权码、收件人列表。配置完成后点“测试”按钮能收到测试邮件才算通。Webhook 告警更适合对接企业微信、钉钉或自建告警平台。配置时填 Webhook URLHFish 会把攻击事件以 JSON 格式 POST 过去。下面是一个典型的 Webhook 接收端处理逻辑# 一个最小的 Webhook 接收示例用于验证 HFish 告警格式 from flask import Flask, request import json app Flask(__name__) app.route(/hfish/webhook, methods[POST]) def receive_alert(): data request.get_json() # HFish 推送的字段通常包含攻击时间、源IP、目标端口、攻击类型 attack_time data.get(time) src_ip data.get(src_ip) dst_port data.get(dst_port) attack_type data.get(type) print(f[告警] {attack_time} 来自 {src_ip} 的攻击类型 {attack_type}目标端口 {dst_port}) return ok, 200 if __name__ __main__: app.run(host0.0.0.0, port8080)逻辑说明这段代码起了一个 Flask 服务监听/hfish/webhook路径收到 POST 请求后解析 JSON 并打印关键字段。实际使用时你可以把打印换成写入数据库、发消息到群机器人、或者触发封禁流程。参数方面HFish 的 Webhook 推送字段名可能因版本略有差异建议先用这个接收端把原始 JSON 打印出来确认字段后再写业务逻辑。4.2 日志分级与误报处理蜜罐跑起来后最大的困扰不是没数据而是数据太多。扫描器、爬虫、误连的业务流量都会产生日志。如果不做分级告警很快就会被淹没。常见做法是按“攻击类型 目标端口 源 IP 信誉”三个维度做分级。比如高危针对模拟数据库端口3306、6379的交互行为且源 IP 不是内网。中危针对模拟 Web 端口的路径扫描且请求中包含敏感路径关键词。低危单纯的端口扫描和连接试探。HFish 本身提供了基础的日志分类但更细的分级需要在告警接收端做。比如在 Webhook 接收逻辑里加一个判断如果源 IP 在内部资产清单里直接丢弃或降级因为那很可能是自己人的扫描器。误报的另一个来源是搜索引擎爬虫和监控探针。这些流量特征明显比如 User-Agent 里带特定标识或者请求频率极高但路径单一。处理方式是在告警端加白名单而不是在蜜罐端关掉模拟服务。提示蜜罐的日志不要只存本地管理端的数据库要做定期备份。攻击日志在溯源和取证时是有价值的丢了就没了。5. 避坑与排查HFish 部署运营中最容易翻车的五个点5.1 探针显示在线但收不到攻击日志现象管理端节点列表里探针状态是“在线”但模拟端口被扫描后没有任何日志。原因最常见的是探针的模拟端口没有真正监听。探针从管理端拉取配置后需要在本地绑定端口。如果端口被占用、或者权限不足比如绑定 1024 以下端口非 root绑定会失败但探针进程本身不会退出所以管理端仍显示在线。解决登录探针所在机器用ss -tlnp查看模拟端口是否在监听。如果没有看探针日志里的绑定错误。Linux 下绑定低端口需要 root 或setcap授权Windows 下一般不存在这个问题。5.2 管理端换 MySQL 后启动失败现象修改数据库配置为 MySQL 后管理端启动报错或卡在初始化。原因一是 MySQL 版本不兼容HFish 对 MySQL 版本有要求太新或太旧都可能出问题二是数据库字符集不对建库时没有指定utf8mb4三是管理端所在机器连不上 MySQL防火墙或账号权限问题。解决先确认 MySQL 版本在支持范围内建库时用CREATE DATABASE hfish DEFAULT CHARSET utf8mb4;然后检查账号是否允许从管理端 IP 连接。如果还不行临时换回 SQLite 确认管理端本身没问题再逐步排查 MySQL 侧。5.3 告警邮件被当成垃圾邮件现象测试邮件能收到但实际攻击告警进了垃圾箱。原因邮件内容里包含大量 IP、端口、攻击载荷等敏感词触发了邮件网关的垃圾邮件规则。另外发件频率过高也会被限流。解决在邮件网关里把发件地址加白名单告警邮件正文不要直接贴原始攻击载荷做摘要处理高频告警做聚合比如 5 分钟内同一源 IP 只发一封。5.4 探针被攻击者识别为蜜罐现象攻击者扫到模拟端口后很快就不再交互或者直接标记为蜜罐。原因模拟服务的指纹太明显。比如 SSH 蜜罐的 banner 和真实 OpenSSH 差异大Web 蜜罐的响应头缺少常见字段。解决HFish 的模板可以自定义 banner 和响应内容。把模拟服务的版本号、响应头改成和真实业务一致。另外不要在同一台机器上开太多不相关的模拟端口真实服务器不会同时开 22、3306、6379、8080 还都允许外连。5.5 管理端 Web 界面访问慢或超时现象登录管理端后页面加载慢节点列表刷新不出来。原因日志量太大SQLite 查询慢或者管理端机器资源不足CPU 和内存被占满。解决换 MySQL 并加索引定期归档旧日志管理端机器至少给 2 核 4G日志量大时加到 4 核 8G。如果只是自己用可以在管理端前面加一层 Nginx 做缓存和限流。6. 进阶技巧用 HFish 做攻击源画像与联动封禁HFish 的价值不止于“看到攻击”更在于把攻击数据变成可行动的线索。我一般会做两件事攻击源画像和联动封禁。攻击源画像的思路是把 HFish 的告警数据按源 IP 聚合统计每个 IP 的攻击类型分布、目标端口分布、时间分布。如果一个 IP 在短时间内扫了多个探针的多个端口且攻击类型多样那它大概率是自动化扫描器如果一个 IP 只针对某一个端口做深度交互那可能是定向攻击。这个画像可以帮你决定哪些 IP 需要重点封禁哪些只需要观察。联动封禁的实现方式取决于你的网络环境。如果探针和管理端都在云上可以用云平台的 API 把恶意 IP 加到安全组黑名单。如果是自建防火墙可以用 Webhook 触发脚本调用防火墙接口。下面是一个简单的联动封禁脚本框架#!/bin/bash # 从 HFish Webhook 接收的 JSON 中提取源 IP并调用防火墙接口封禁 # 实际使用时这个脚本由 Webhook 接收端调用传入 IP 和封禁时长 IP$1 DURATION$2 # 示例调用 iptables 封禁仅限 Linux 且脚本有 root 权限 iptables -I INPUT -s $IP -j DROP echo 已封禁 $IP时长 $DURATION 秒 # 定时解封 sleep $DURATION iptables -D INPUT -s $IP -j DROP echo 已解封 $IP逻辑说明这个脚本接收两个参数——IP 和封禁时长用 iptables 做临时封禁到时间自动解封。实际生产环境不建议直接用 iptables因为规则多了会乱更好的做法是调用云平台安全组 API 或专业防火墙的接口。参数方面封禁时长要根据攻击类型定扫描类封 1 小时交互类封 24 小时重复攻击的 IP 直接拉黑名单。还有一个技巧是“蜜罐诱捕 真实服务联动”。比如你在探针上模拟了一个假的数据库端口攻击者尝试连接后你可以把源 IP 同步给真实数据库的访问控制列表提前阻断。这个思路在攻防演练里特别有用相当于用蜜罐给真实资产加了一层预警。最后说一个我自己的习惯每次部署完 HFish我都会先用一台外部机器做一次完整的模拟攻击从端口扫描到模拟交互确认告警链路全通。这个“自测”步骤花不了十分钟但能避免真正有攻击时才发现告警没配好。蜜罐这东西平时看着安静关键时刻掉链子才是最让人后悔的。希望帮到你。本文还有配套的精品资源点击获取