HFish跨平台蜜罐平台v2.2.0部署与实战：从节点配置到攻击告警

简介HFish v2.2.0 是一套开放源码的跨平台蜜罐系统面向网络安全研究人员、安全运维人员以及需要开展攻防实验的高校师生可在 Windows、Linux、macOS 等系统上部署用于诱捕攻击、记录攻击行为并分析攻击者策略。压缩包共 349 个文件约 33.77MB以 Go 语言源码为主体辅以前端 js、css、html 页面资源以及 hf 配置、png/svg 图标、字体文件、sql 脚本、Dockerfile 与说明文档等结构清晰、注释详尽便于理解蜜罐工作机制并进行二次开发。目前已有 311 人学习下载。资源附带预设配置与建站模板可省去繁琐配置快速搭建蜜罐环境同时集成日志查看、数据分析与报警等组件帮助读者在模拟真实攻击中掌握部署、监控与响应流程适合作为网络安全教学案例与毕业设计参考素材。1. HFish 跨平台蜜罐平台 v2.2.0从一台机器到一片诱捕网你手上有一台闲置的云主机公网 IP 暴露着每天 SSH 日志里塞满爆破记录。与其封 IP 封到手软不如反过来——让攻击者以为攻进来了然后看他到底想干什么。HFish 就是干这个的一个跨平台蜜罐平台把散落在各处的诱饵节点统一管起来Web 界面看攻击态势节点端负责伪装服务、记录交互。v2.2.0 这个版本号意味着它已经迭代到相对稳定的阶段部署方式、节点管理、告警联动都有成熟路径。这篇文章不讲“蜜罐是什么”直接讲怎么把 HFish 跨平台蜜罐平台 v2.2.0 跑起来、节点怎么加、告警怎么配、哪些参数不调会翻车。适合手里有公网资产、想低成本做威胁感知的运维和安全从业者。新手能照着命令走通熟手能直接跳到参数调优和避坑章节。2. 部署架构与最小可用环境管理端和节点端怎么摆2.1 管理端与节点端的分工逻辑HFish 的架构是典型的管理端 节点端模式。管理端负责 Web 控制台、数据库、告警策略、节点心跳调度节点端负责在目标机器上监听端口、模拟服务、上报攻击数据。两者通过管理端下发的指令通信节点端不需要公网入站以外的额外权限。为什么这样设计因为蜜罐的核心价值在于“诱捕面”的广度。你不可能在每台机器上都装一套完整控制台但可以在每台机器上跑一个轻量节点把数据汇聚到一个管理端。v2.2.0 的管理端和节点端是同一个二进制包通过启动参数区分角色部署时不需要分别下载。常见做法是管理端放在内网一台有固定 IP 的机器上节点端放在公网暴露的蜜罐主机上。管理端需要能被节点端访问到指定端口默认 4433节点端需要开放蜜罐服务端口给公网。如果管理端也在公网务必改默认密码并限制访问来源。2.2 管理端部署从解压到 Web 可访问假设你拿到的是HFish跨平台蜜罐平台 v2.2.0.zip在 Linux 管理端上操作。先解压、给权限、启动。# 解压到 /opt 目录 unzip HFish跨平台蜜罐平台\ v2.2.0.zip -d /opt/hfish # 进入目录查看文件结构 cd /opt/hfish ls -la # 通常包含 hfish 二进制、config 配置目录、db 数据库目录、web 静态资源 # 给二进制执行权限 chmod x hfish # 启动管理端默认监听 4433 和 4434 ./hfish -mode server启动后管理端默认监听4433作为 Web 控制台端口4434作为节点通信端口。浏览器访问https://管理端IP:4433默认账号admin默认密码在首次启动时会打印在终端或者查看config/config.yaml里的初始配置。参数说明-mode server指定管理端角色如果要用 systemd 托管写一个 unit 文件ExecStart/opt/hfish/hfish -mode serverWorkingDirectory/opt/hfishRestartalways。注意工作目录必须是解压后的根目录否则找不到db和web资源。2.3 节点端部署一条命令接入管理端节点端的部署更简单同样用这个二进制包但启动参数不同。# 在蜜罐节点机器上解压 unzip HFish跨平台蜜罐平台\ v2.2.0.zip -d /opt/hfish-node cd /opt/hfish-node chmod x hfish # 启动节点端指定管理端地址 ./hfish -mode agent -server https://管理端IP:4434节点端启动后会向管理端注册管理端 Web 界面“节点管理”里会出现这台节点状态为“在线”。如果状态一直“离线”先检查管理端4434端口是否放行、节点端到管理端的网络是否通、证书是否被拦截。节点端本身不存储攻击数据所有交互记录实时上报管理端。所以节点端机器被攻击者拿下也不影响数据完整性——这是蜜罐和普通 IDS 的关键区别蜜罐不怕被攻破怕的是攻击者不进来。2.4 最小可用验证确认诱饵端口真的在监听部署完管理端和至少一个节点端后别急着配告警先验证蜜罐服务是否真的在监听。# 在节点端机器上查看监听端口 ss -tlnp | grep hfish # 从另一台机器尝试连接蜜罐端口以 SSH 蜜罐 2222 为例 ssh -p 2222 test节点IP # 随便输入用户名密码然后回管理端看是否有记录如果ss看不到蜜罐端口说明节点端没有成功从管理端拉取到蜜罐模板配置。常见原因是管理端 Web 界面里没有给这个节点分配蜜罐服务或者节点端与管理端的通信被防火墙阻断。管理端“节点管理”里每个节点都有一个“部署蜜罐”按钮勾选需要的蜜罐类型后下发节点端会在几秒内开始监听对应端口。3. 蜜罐模板配置与攻击数据捕获让诱饵像真的3.1 蜜罐模板的选择逻辑不是越多越好HFish v2.2.0 内置了多种蜜罐模板常见的有 SSH、HTTP、MySQL、Redis、Telnet、FTP 等。每个模板模拟对应服务的协议交互记录攻击者的输入、尝试的账号密码、执行的命令。选模板的原则是“贴合目标机器的真实角色”。一台 Web 服务器上开 SSH 蜜罐合理开 MySQL 蜜罐也合理但开一个 Redis 蜜罐在非缓存服务器上就有点突兀。攻击者也会做指纹识别端口开放但服务特征不对反而暴露蜜罐身份。我一般会先看这台机器原本跑什么服务然后选 2 到 3 个相关蜜罐模板。比如一台对外提供 Web 的机器开 HTTP 蜜罐80/443、SSH 蜜罐22 或 2222、MySQL 蜜罐3306。端口尽量用真实服务端口如果真实服务已占用就换高位端口但要在管理端备注清楚。3.2 通过 Web 界面下发蜜罐模板管理端登录后进入“节点管理”找到目标节点点击“部署蜜罐”。界面会列出所有可用模板每个模板有默认端口和可自定义端口。操作步骤勾选需要的蜜罐模板比如 SSH、HTTP、MySQL。修改端口SSH 默认 2222HTTP 默认 8080MySQL 默认 3306。如果节点上这些端口已被真实服务占用改成其他端口。点击“下发”等待节点端拉取配置。回到节点端ss -tlnp确认端口已监听。参数说明每个蜜罐模板有“深度交互”和“浅交互”两种模式。浅交互只记录连接和基础输入深度交互会模拟完整的命令执行环境比如 SSH 蜜罐会返回一个假的 shell。深度交互更逼真但资源消耗略高。v2.2.0 里 SSH 和 Telnet 支持深度交互HTTP 蜜罐支持自定义响应页面。3.3 攻击数据在哪里看Web 控制台与数据库攻击数据实时上报到管理端Web 界面“攻击记录”里按时间倒序展示。每条记录包含攻击时间、攻击源 IP、目标节点、目标端口、蜜罐类型、攻击载荷比如尝试的账号密码、执行的命令。如果需要做二次分析可以直接查管理端的数据库。v2.2.0 默认使用 SQLite数据库文件在db/hfish.db。-- 查看最近 100 条 SSH 蜜罐的攻击记录 SELECT * FROM attack_log WHERE honeypot_type ssh ORDER BY attack_time DESC LIMIT 100; -- 统计攻击源 IP 的尝试次数 SELECT attack_ip, COUNT(*) as cnt FROM attack_log GROUP BY attack_ip ORDER BY cnt DESC LIMIT 20;参数说明attack_log表是核心表字段包括attack_ip、attack_time、honeypot_type、payload等。如果数据量大建议定期归档SQLite 单表超过百万行后查询会变慢。常见做法是每天导出一次 CSV然后清空历史记录。3.4 告警联动把攻击事件推到你的手机上蜜罐的价值在于“知道有人来了”所以告警必须配。HFish v2.2.0 支持 Webhook、邮件、Syslog 三种告警方式。Webhook 最灵活可以对接钉钉、企业微信、飞书或者自建告警平台。配置路径管理端“系统设置” - “告警配置” - “Webhook”。填入 Webhook 地址选择触发条件比如“所有攻击”或“仅深度交互”保存后可以点“测试”发一条测试消息。{ msgtype: text, text: { content: HFish 告警节点 web-01 的 SSH 蜜罐被攻击源 IP 1.2.3.4尝试账号 root/admin } }这是钉钉机器人接收的 JSON 格式示例。HFish 的 Webhook 会 POST 一个 JSON body字段包括node_name、honeypot_type、attack_ip、payload。如果你用企业微信把msgtype改成markdowncontent里用 markdown 语法即可。注意Webhook 地址不要填内网地址除非管理端能访问到。如果告警量太大建议在“触发条件”里勾选“仅深度交互”或“仅特定蜜罐类型”避免手机被轰炸。4. 避坑与排查那些让我半夜爬起来的问题4.1 节点端显示在线但蜜罐端口不监听现象管理端“节点管理”里节点状态是“在线”但节点端ss -tlnp看不到蜜罐端口。原因节点端与管理端的通信正常但蜜罐模板配置没有成功下发。常见于管理端 Web 界面里勾选了模板但没点“下发”或者节点端拉取配置时网络抖动导致配置丢失。解决在管理端节点管理里重新点击“下发”然后到节点端重启 agent 进程。如果还不行检查节点端日志logs/hfish.log看是否有“pull config failed”之类的报错。实在不行删掉节点重新注册一次。4.2 攻击记录里全是扫描器没有真实交互现象攻击记录里大量记录但 payload 都是空的或者只有连接信息没有账号密码、命令执行等深度数据。原因大部分公网扫描器只做端口探测和 banner 抓取不会进行协议交互。这是正常现象不是蜜罐坏了。但如果连一个深度交互记录都没有可能是蜜罐模板选错了——比如开了 HTTP 蜜罐但攻击者只扫 SSH。解决调整蜜罐模板组合确保覆盖常见攻击面。SSH 和 Telnet 蜜罐最容易拿到深度交互数据因为爆破工具会尝试登录。HTTP 蜜罐可以自定义一个假的登录页面诱导攻击者提交表单。另外把蜜罐端口设在常见端口上22、80、3306扫描器命中率更高。4.3 管理端 Web 界面打不开或登录后白屏现象浏览器访问https://管理端IP:4433显示连接被拒绝或者登录后页面空白。原因管理端进程没起来或者web静态资源目录丢失。v2.2.0 的 Web 资源是打包在二进制里的但如果解压不完整web目录可能缺失。另外如果管理端机器时间不对HTTPS 证书校验可能失败。解决先ps aux | grep hfish确认进程在跑。如果进程在但端口没监听检查config/config.yaml里的web_port配置。如果登录后白屏按 F12 看浏览器控制台报错通常是静态资源 404重新解压一次完整包覆盖即可。时间问题用date命令校准或者ntpdate同步。4.4 告警发不出去Webhook 测试失败现象Webhook 配置保存后点“测试”提示发送失败但地址在浏览器里能打开。原因HFish 管理端发 Webhook 请求时如果目标地址是 HTTPS 且证书是自签的会校验失败。另外如果管理端所在网络需要代理才能出外网而 HFish 没有配代理也会失败。解决如果 Webhook 地址是 HTTPS 且证书自签在config/config.yaml里找到webhook_skip_verify改成true。如果需要代理在管理端机器上设置环境变量export HTTPS_PROXYhttp://代理地址:端口然后重启 HFish 管理端。注意代理只影响管理端出站不影响节点端。4.5 数据库文件越来越大查询变慢现象运行几周后db/hfish.db文件几个 GBWeb 界面加载攻击记录要等很久。原因SQLite 单表数据量过大且没有定期清理。HFish 默认不自动删除历史记录。解决在管理端“系统设置”里找到“数据清理”设置保留天数比如 30 天开启自动清理。如果已经很大了先手动导出需要的记录然后DELETE FROM attack_log WHERE attack_time 2025-01-01;再VACUUM;收缩数据库文件。VACUUM 期间会锁库建议在低峰期操作。5. 进阶技巧用蜜罐数据做攻击者画像5.1 从攻击记录里提取攻击者指纹蜜罐数据最值钱的不是“有多少次攻击”而是“攻击者长什么样”。通过分析 payload 里的账号密码、命令、User-Agent可以给攻击源打标签。import sqlite3 import re from collections import Counter conn sqlite3.connect(/opt/hfish/db/hfish.db) cursor conn.cursor() # 提取 SSH 蜜罐的账号密码尝试 cursor.execute( SELECT attack_ip, payload FROM attack_log WHERE honeypot_type ssh AND payload IS NOT NULL ) rows cursor.fetchall() ip_creds {} for ip, payload in rows: # payload 格式通常是 username:password match re.search(r(\S):(\S), payload) if match: user, pwd match.groups() ip_creds.setdefault(ip, []).append((user, pwd)) # 统计每个 IP 最常用的账号密码组合 for ip, creds in list(ip_creds.items())[:10]: counter Counter(creds) top counter.most_common(3) print(f{ip}: {top}) conn.close()这段脚本从 SQLite 里读 SSH 蜜罐的 payload用正则提取账号密码对然后统计每个攻击 IP 最常用的组合。参数说明payload字段的格式取决于蜜罐模板SSH 蜜罐通常是username:passwordHTTP 蜜罐可能是 JSON 或表单字符串需要根据实际情况调整正则。5.2 用攻击源 IP 做威胁情报匹配拿到攻击源 IP 后可以批量查询威胁情报平台判断是普通扫描器还是已知恶意 IP。常见做法是导出 IP 列表用脚本调威胁情报 API。# 从数据库导出最近 7 天的攻击源 IP去重 sqlite3 /opt/hfish/db/hfish.db \ SELECT DISTINCT attack_ip FROM attack_log WHERE attack_time datetime(now, -7 days); \ /tmp/attack_ips.txt # 统计 IP 数量 wc -l /tmp/attack_ips.txt导出后可以用任何威胁情报平台的批量查询接口。如果不想调外部 API至少可以在本地防火墙或 WAF 里把这些 IP 加黑名单。注意蜜罐的攻击源 IP 不一定都是恶意的有些是安全公司的扫描器加黑前先确认。5.3 蜜罐节点的反制与隔离蜜罐被攻破是预期内的但攻破后不能让它成为跳板。节点端机器应该做网络隔离只允许蜜罐端口对外其他出站流量限制。如果攻击者通过蜜罐拿到了一个假 shell他可能会尝试从节点端横向移动到内网。我一般会在节点端机器上配 iptables限制出站# 允许已建立的连接 iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 允许到管理端的通信 iptables -A OUTPUT -d 管理端IP -p tcp --dport 4434 -j ACCEPT # 允许 DNS 和 NTP iptables -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -A OUTPUT -p udp --dport 123 -j ACCEPT # 其他出站全部拒绝 iptables -A OUTPUT -j DROP这样即使攻击者拿到 shell也无法从节点端主动外连。注意这条规则要在节点端注册到管理端之后再配否则节点端连不上管理端。另外如果节点端还需要跑其他正常服务把对应出站规则加在 DROP 之前。5.4 蜜罐数据的长期价值从告警到趋势单条告警的价值有限但积累几个月后可以看到攻击趋势哪些端口被扫得最频繁、哪些账号密码组合最常被尝试、攻击源 IP 的地理分布。这些数据可以用来调整真实业务的安全策略——比如发现某个密码被大量尝试说明它可能已经在泄露字典里赶紧改掉。我习惯每周导出一次攻击记录用简单的脚本生成趋势图。不需要复杂的 BI 工具Python 的 matplotlib 或者直接输出 CSV 用 Excel 画图都行。关键是坚持记录蜜罐这东西跑一天和跑一个月价值完全不一样。最后说个血泪教训蜜罐节点不要用生产机器也不要用有敏感数据的机器。我见过有人把蜜罐跑在测试环境里结果测试环境的数据库密码和蜜罐在同一台机器上攻击者通过蜜罐拿到 shell 后直接读了数据库配置。蜜罐就是蜜罐给它一台干净的、隔离的、没有后悔药的机器。希望帮到你。本文还有配套的精品资源点击获取