简介HFish v2.2.0 是一套开放源码的跨平台蜜罐系统面向网络安全研究人员、安全运维人员以及需要开展攻防实验的高校师生用于搭建诱捕环境、监控并记录攻击者行为为防御策略提供数据支撑。资源包共 349 个文件约 33.77MB以 Go 语言源码为主体配合 JavaScript、CSS、HTML 等前端资源以及 hf 配置、png/svg 图标、字体文件与 sql 脚本另含 Dockerfile、yml、sh 等部署脚本结构清晰、注释详尽便于理解蜜罐工作机制并进行二次开发。目前已有 311 人学习关注。借助源码与预设配置读者可快速完成 Windows、Linux、macOS 下的部署体验蜜罐设置、攻击数据采集与日志分析流程也可在教学中模拟真实攻击场景加深对攻防对抗机制的理解锻炼系统集成与安全分析能力。1. HFish 跨平台蜜罐平台 v2.2.0从一台机器到一片诱捕网你手上有一台闲置的云主机想把它变成一个能看见攻击者动作的观察哨。直接上 IDS 太重自己写脚本记录端口扫描又太散这时候 HFish 这类蜜罐平台就派上用场了。它做的事情很具体在主机上开一批仿真服务端口把每一个连接、每一次尝试登录、每一条执行命令都记下来再汇总到一个 Web 控制台里。v2.2.0 这个版本号意味着它已经迭代过若干轮节点管理、告警通知、多协议仿真这些模块相对稳定不是早期那种只能开一两个端口的玩具。跨平台是它被反复提起的原因——Linux、Windows、Docker 都能跑节点可以分散在不同网段管理端统一收数据。适合谁安全运维、红蓝对抗里的蓝队、想给内网加一层低成本感知的团队。不适合谁指望它直接阻断攻击的人蜜罐的定位是发现和记录不是防火墙。2. 部署前先想清楚管理端和节点怎么分工2.1 管理端与节点的角色差异HFish 的架构不复杂但第一次接触的人容易把两个角色混在一起。管理端负责 Web 界面、数据库、告警规则、节点状态汇总节点负责实际监听端口、仿真服务、上报数据。你可以把管理端和节点装在同一台机器上也可以管理端一台、节点若干台。生产环境里我一般会分开管理端放在运维能访问的网段节点放在业务区或者 DMZ节点只和管理端通信不对外暴露管理端口。这个分工带来的直接好处是扩展。你新增一个网段不需要动管理端只需要在那台机器上装一个节点填上管理端地址和通信密钥节点就会自动注册。v2.2.0 的节点注册流程比早期版本顺密钥在管理端生成节点配置文件里填一次就行。选型上还有一个点管理端的数据库。默认用 SQLite小规模够用但节点超过十个、告警量上来之后SQLite 的写入会成为瓶颈。常见做法是换成 MySQL管理端配置文件里改连接串重启生效。这一步不是必须但如果你打算长期跑建议一开始就换掉。2.2 最小部署单机跑通管理端加节点先在一台 Linux 机器上把管理端跑起来。假设你已经拿到了 v2.2.0 的压缩包解压后目录结构里会有管理端和节点两个子目录。下面以 Linux 为例Windows 的操作逻辑一样只是路径和启动方式不同。# 解压压缩包 unzip HFish-v2.2.0.zip -d /opt/hfish # 进入管理端目录 cd /opt/hfish/management # 给启动脚本执行权限 chmod x hfish-server # 前台启动先看日志有没有报错 ./hfish-server启动之后默认监听 4433 端口浏览器访问https://你的IP:4433默认账号密码在管理端目录的config.ini或者首次启动日志里能看到。第一次登录会强制改密码这一步别跳过。管理端跑起来之后在同一台机器上装节点# 进入节点目录 cd /opt/hfish/node # 编辑节点配置填管理端地址和通信密钥 vi config.ini节点配置文件里关键的就三项管理端 IP、管理端端口、通信密钥。密钥在管理端 Web 界面的「节点管理」里生成复制过来填进去。填完之后启动节点chmod x hfish-node ./hfish-node节点启动后管理端界面上应该能看到节点上线状态是绿色。如果一直是灰色先看节点日志再看管理端和节点之间的端口通不通。默认通信端口是 4434别被防火墙拦了。提示第一次部署建议管理端和节点同机排除网络因素之后再拆开。同机能通、拆开不通问题一定在防火墙或者路由。2.3 节点配置里三个必调参数节点配置文件里有一批参数但真正影响你日常使用的就三个。第一个是bind_ip。默认是0.0.0.0意思是监听所有网卡。如果你的机器有多张网卡只想让蜜罐监听其中一张就改成具体 IP。这个参数决定了攻击者能从哪个网段访问到你的仿真服务。第二个是service_port_range。HFish 的仿真服务会占用一批端口默认范围是 21、22、23、80、443、3306、6379 这些常见端口。如果你的机器上已经有真实服务占了 80要么改真实服务的端口要么在 HFish 里把 80 的仿真关掉。端口冲突是新手翻车最多的地方节点启动失败先查这个。第三个是report_interval。节点向管理端上报数据的时间间隔默认 30 秒。调小会让管理端压力变大调大则告警延迟变高。内网环境 30 秒够用如果节点数量多可以调到 60 秒。这三个参数改完重启节点生效。不要改一个重启一次攒一起改完再重启省时间。3. 仿真服务怎么配从端口到交互记录3.1 常见仿真模板与适用场景HFish 内置了一批仿真模板SSH、Telnet、HTTP、MySQL、Redis、FTP 这些都有。每个模板对应一组端口和一套交互逻辑。比如 SSH 模板会模拟一个登录过程攻击者尝试用户名密码HFish 记录下每一次尝试但不会真的让攻击者登录进去。HTTP 模板会返回一个仿真页面同时记录请求路径、User-Agent、POST 数据。选模板的原则是看你的网络环境里什么服务最可能被扫。对外网暴露的机器SSH 和 HTTP 是必开的内网机器MySQL 和 Redis 的仿真更有价值因为内网攻击者通常先扫这两个端口找弱口令。不要一股脑全开端口开得越多误报和噪音越大。模板的启用和停用在管理端 Web 界面操作勾选之后下发到节点节点会自动调整监听。这里有一个细节模板变更不是实时的节点下一次上报心跳才会拉取新配置所以改完之后等一个上报周期再验证。3.2 自定义仿真页面改 HTML 和返回头内置模板的仿真页面比较通用如果你想让 HTTP 蜜罐看起来更像真实业务可以自定义返回内容。HFish 的模板目录下每个服务有一个template文件夹里面是 HTML 文件和配置文件。# 进入 HTTP 模板目录 cd /opt/hfish/node/template/http # 查看当前模板文件 ls -la你会看到index.html和一个config.json。index.html就是攻击者访问时看到的页面直接替换成你自己的登录页或者错误页。config.json里可以配返回头比如Server字段默认是nginx你可以改成Apache或者别的让指纹看起来更真实。{ server_header: Apache/2.4.41 (Ubuntu), status_code: 200, response_delay_ms: 100 }response_delay_ms是响应延迟单位毫秒。加一点延迟会让仿真服务更像真实服务器但别加太多超过 500ms 攻击者可能会觉得异常。改完模板文件重启节点生效。注意自定义页面不要放任何真实业务的敏感信息蜜罐页面是给攻击者看的不是给用户看的。3.3 告警规则什么情况下该通知你HFish 的告警规则决定了哪些事件会推送到你的邮箱、Webhook 或者钉钉。默认规则比较宽端口扫描也会告警跑一天下来邮箱会被塞满。我的做法是分层高频低危事件只记录不告警比如单纯的端口连接涉及登录尝试、命令执行、文件上传的才告警。在管理端的「告警配置」里可以按服务类型、按来源 IP、按事件等级设置过滤条件。比如 SSH 服务只对密码尝试次数超过 3 次的来源 IP 告警HTTP 服务只对 POST 请求和特定路径告警。这样能把噪音降下来真正有攻击行为的时候你才会注意到。Webhook 的配置格式是 JSON管理端会往你填的地址 POST 一条 JSON 数据。如果你用钉钉或者企业微信中间需要一个转换服务把 HFish 的 JSON 转成机器人能识别的格式。这个转换服务自己写一个简单的 Flask 或者 Node 脚本就行不复杂。4. 避坑与排查节点掉线、端口冲突、告警风暴4.1 节点显示离线但进程还在现象管理端界面上节点是灰色但登录到节点机器上ps能看到hfish-node进程在跑。原因节点和管理端之间的心跳断了。常见的是通信端口被防火墙拦了或者管理端地址配错了。还有一种情况是管理端换了 IP节点配置没更新。解决先在节点机器上telnet 管理端IP 4434看端口通不通。不通就查防火墙和安全组。通的话看节点日志日志里会打印心跳失败的具体原因。如果是管理端 IP 变了改节点配置文件里的地址重启节点。4.2 节点启动报端口占用现象节点启动失败日志里写bind: address already in use。原因HFish 要监听的端口被真实服务占了。最常见的是 80 和 443很多机器上本来就跑了 Nginx 或者 Apache。解决两个选择。要么改真实服务的端口把 80 让给 HFish要么在管理端把 80 的仿真模板关掉只保留其他端口。我一般选后者因为改真实服务端口影响面大。关掉模板之后节点重启端口冲突就没了。4.3 告警邮件一天几百封现象邮箱被 HFish 的告警邮件塞满大部分是端口扫描和无效连接。原因告警规则太宽没有做过滤。默认配置下任何连接都会触发告警。解决进管理端「告警配置」把「端口扫描」类事件的告警关掉只保留「登录尝试」「命令执行」「文件上传」这些高价值事件。同时设置来源 IP 白名单把你自己的扫描器 IP 加进去避免自己人触发告警。调整之后告警量能降一个数量级。4.4 管理端数据库写入慢现象节点数量多了之后管理端界面卡顿告警延迟从几秒变成几分钟。原因默认的 SQLite 数据库在高并发写入下性能不够。每个节点每次上报都会写库节点多了写入频率线性增长。解决换 MySQL。管理端配置文件里改数据库连接串重启管理端。数据迁移用管理端自带的导出功能先导出再导入 MySQL。换完之后写入性能明显改善界面也不卡了。4.5 仿真服务被攻击者识破现象攻击者连上 SSH 仿真端口试了一次就断开没有后续动作。原因仿真服务的指纹太明显。比如 SSH 版本号是默认的或者登录失败返回的消息和真实 SSH 不一样。解决改仿真模板的版本号和返回消息。SSH 模板的配置文件里可以改banner字段改成和真实服务器一致的版本号。HTTP 模板改Server头。这些细节不影响功能但能提高仿真服务的可信度让攻击者愿意多停留一会儿。5. 进阶用 HFish 做攻击者画像和溯源线索5.1 从告警日志里提取攻击者指纹HFish 记录的每一条事件都带来源 IP、时间、服务类型、交互内容。单条看没什么积累一周之后就能做画像。我一般会导出事件日志用 Python 做几个统计来源 IP 的地理分布、最常被尝试的用户名密码组合、攻击时间段的分布。import sqlite3 import pandas as pd # 连接 HFish 的 SQLite 数据库如果没换 MySQL conn sqlite3.connect(/opt/hfish/management/data/hfish.db) # 读取 SSH 登录尝试记录 df pd.read_sql(SELECT src_ip, username, password, create_time FROM ssh_login_attempts, conn) # 统计尝试次数最多的来源 IP top_ips df.groupby(src_ip).size().sort_values(ascendingFalse).head(20) print(top_ips) # 统计最常用的用户名密码组合 top_creds df.groupby([username, password]).size().sort_values(ascendingFalse).head(20) print(top_creds)这段代码的逻辑很直接从数据库里拉出 SSH 登录尝试记录按来源 IP 和用户名密码组合做聚合。top_ips能告诉你哪些 IP 最活跃top_creds能告诉你攻击者最常用的弱口令是什么。这些信息可以用来加固真实服务器的密码策略也可以用来做 IP 封禁。参数说明sqlite3.connect的路径根据你的实际安装位置调整。如果换了 MySQL把连接方式改成pymysql或者sqlalchemy。head(20)是取前 20 条按需调整。5.2 把蜜罐数据接入现有安全体系HFish 的 Webhook 可以把告警实时推送到你的 SIEM 或者 SOAR 平台。我一般会写一个中间服务接收 HFish 的 Webhook做两件事一是把事件格式转换成 SIEM 能识别的格式二是根据来源 IP 查威胁情报库如果 IP 有恶意记录就自动触发封禁。from flask import Flask, request import requests app Flask(__name__) app.route(/hfish-webhook, methods[POST]) def handle_webhook(): data request.json src_ip data.get(src_ip) event_type data.get(event_type) # 查威胁情报 intel requests.get(fhttps://你的威胁情报接口/check?ip{src_ip}).json() if intel.get(malicious): # 触发封禁逻辑 requests.post(https://你的防火墙接口/block, json{ip: src_ip}) # 转发到 SIEM requests.post(https://你的SIEM接口/ingest, jsondata) return ok, 200 if __name__ __main__: app.run(host0.0.0.0, port5000)这个中间服务的逻辑是接收 HFish 的告警提取来源 IP查威胁情报如果 IP 被标记为恶意就调防火墙接口封禁同时把事件转发到 SIEM。src_ip和event_type是 HFish Webhook 里带的字段具体字段名以你收到的实际 JSON 为准。提示封禁逻辑要加白名单别把自己人的 IP 封了。我一般会在封禁前先查一下这个 IP 是不是内部资产。5.3 验证蜜罐是否真的在工作的三个方法部署完之后怎么确认蜜罐真的在干活我一般用三个方法验证。第一个方法从另一台机器手动连一下仿真端口。比如telnet 蜜罐IP 22然后随便输一个用户名密码去管理端看有没有记录。有记录说明链路通了。第二个方法用扫描器扫一下蜜罐 IP。nmap -sS 蜜罐IP扫完之后管理端应该能看到端口扫描事件。如果没看到说明告警规则或者上报链路有问题。第三个方法看节点的连接数。在节点机器上netstat -an | grep 仿真端口如果有外部 IP 连着说明仿真服务在响应。这个方法适合排查仿真服务是否真的在监听。这三个方法从不同角度验证手动连验证记录链路扫描验证告警链路连接数验证监听状态。三个都通过蜜罐才算真正跑起来了。我自己的习惯是每次部署完新节点先手动连一次确认管理端有记录再去干别的。这个动作花不了一分钟但能省掉后面半小时的排查。希望帮到你。本文还有配套的精品资源点击获取 HFish 蜜罐平台 v2.2.0 部署与实战：从单机到分布式诱捕网
简介HFish v2.2.0 是一套开放源码的跨平台蜜罐系统面向网络安全研究人员、安全运维人员以及需要开展攻防实验的高校师生用于搭建诱捕环境、监控并记录攻击者行为为防御策略提供数据支撑。资源包共 349 个文件约 33.77MB以 Go 语言源码为主体配合 JavaScript、CSS、HTML 等前端资源以及 hf 配置、png/svg 图标、字体文件与 sql 脚本另含 Dockerfile、yml、sh 等部署脚本结构清晰、注释详尽便于理解蜜罐工作机制并进行二次开发。目前已有 311 人学习关注。借助源码与预设配置读者可快速完成 Windows、Linux、macOS 下的部署体验蜜罐设置、攻击数据采集与日志分析流程也可在教学中模拟真实攻击场景加深对攻防对抗机制的理解锻炼系统集成与安全分析能力。1. HFish 跨平台蜜罐平台 v2.2.0从一台机器到一片诱捕网你手上有一台闲置的云主机想把它变成一个能看见攻击者动作的观察哨。直接上 IDS 太重自己写脚本记录端口扫描又太散这时候 HFish 这类蜜罐平台就派上用场了。它做的事情很具体在主机上开一批仿真服务端口把每一个连接、每一次尝试登录、每一条执行命令都记下来再汇总到一个 Web 控制台里。v2.2.0 这个版本号意味着它已经迭代过若干轮节点管理、告警通知、多协议仿真这些模块相对稳定不是早期那种只能开一两个端口的玩具。跨平台是它被反复提起的原因——Linux、Windows、Docker 都能跑节点可以分散在不同网段管理端统一收数据。适合谁安全运维、红蓝对抗里的蓝队、想给内网加一层低成本感知的团队。不适合谁指望它直接阻断攻击的人蜜罐的定位是发现和记录不是防火墙。2. 部署前先想清楚管理端和节点怎么分工2.1 管理端与节点的角色差异HFish 的架构不复杂但第一次接触的人容易把两个角色混在一起。管理端负责 Web 界面、数据库、告警规则、节点状态汇总节点负责实际监听端口、仿真服务、上报数据。你可以把管理端和节点装在同一台机器上也可以管理端一台、节点若干台。生产环境里我一般会分开管理端放在运维能访问的网段节点放在业务区或者 DMZ节点只和管理端通信不对外暴露管理端口。这个分工带来的直接好处是扩展。你新增一个网段不需要动管理端只需要在那台机器上装一个节点填上管理端地址和通信密钥节点就会自动注册。v2.2.0 的节点注册流程比早期版本顺密钥在管理端生成节点配置文件里填一次就行。选型上还有一个点管理端的数据库。默认用 SQLite小规模够用但节点超过十个、告警量上来之后SQLite 的写入会成为瓶颈。常见做法是换成 MySQL管理端配置文件里改连接串重启生效。这一步不是必须但如果你打算长期跑建议一开始就换掉。2.2 最小部署单机跑通管理端加节点先在一台 Linux 机器上把管理端跑起来。假设你已经拿到了 v2.2.0 的压缩包解压后目录结构里会有管理端和节点两个子目录。下面以 Linux 为例Windows 的操作逻辑一样只是路径和启动方式不同。# 解压压缩包 unzip HFish-v2.2.0.zip -d /opt/hfish # 进入管理端目录 cd /opt/hfish/management # 给启动脚本执行权限 chmod x hfish-server # 前台启动先看日志有没有报错 ./hfish-server启动之后默认监听 4433 端口浏览器访问https://你的IP:4433默认账号密码在管理端目录的config.ini或者首次启动日志里能看到。第一次登录会强制改密码这一步别跳过。管理端跑起来之后在同一台机器上装节点# 进入节点目录 cd /opt/hfish/node # 编辑节点配置填管理端地址和通信密钥 vi config.ini节点配置文件里关键的就三项管理端 IP、管理端端口、通信密钥。密钥在管理端 Web 界面的「节点管理」里生成复制过来填进去。填完之后启动节点chmod x hfish-node ./hfish-node节点启动后管理端界面上应该能看到节点上线状态是绿色。如果一直是灰色先看节点日志再看管理端和节点之间的端口通不通。默认通信端口是 4434别被防火墙拦了。提示第一次部署建议管理端和节点同机排除网络因素之后再拆开。同机能通、拆开不通问题一定在防火墙或者路由。2.3 节点配置里三个必调参数节点配置文件里有一批参数但真正影响你日常使用的就三个。第一个是bind_ip。默认是0.0.0.0意思是监听所有网卡。如果你的机器有多张网卡只想让蜜罐监听其中一张就改成具体 IP。这个参数决定了攻击者能从哪个网段访问到你的仿真服务。第二个是service_port_range。HFish 的仿真服务会占用一批端口默认范围是 21、22、23、80、443、3306、6379 这些常见端口。如果你的机器上已经有真实服务占了 80要么改真实服务的端口要么在 HFish 里把 80 的仿真关掉。端口冲突是新手翻车最多的地方节点启动失败先查这个。第三个是report_interval。节点向管理端上报数据的时间间隔默认 30 秒。调小会让管理端压力变大调大则告警延迟变高。内网环境 30 秒够用如果节点数量多可以调到 60 秒。这三个参数改完重启节点生效。不要改一个重启一次攒一起改完再重启省时间。3. 仿真服务怎么配从端口到交互记录3.1 常见仿真模板与适用场景HFish 内置了一批仿真模板SSH、Telnet、HTTP、MySQL、Redis、FTP 这些都有。每个模板对应一组端口和一套交互逻辑。比如 SSH 模板会模拟一个登录过程攻击者尝试用户名密码HFish 记录下每一次尝试但不会真的让攻击者登录进去。HTTP 模板会返回一个仿真页面同时记录请求路径、User-Agent、POST 数据。选模板的原则是看你的网络环境里什么服务最可能被扫。对外网暴露的机器SSH 和 HTTP 是必开的内网机器MySQL 和 Redis 的仿真更有价值因为内网攻击者通常先扫这两个端口找弱口令。不要一股脑全开端口开得越多误报和噪音越大。模板的启用和停用在管理端 Web 界面操作勾选之后下发到节点节点会自动调整监听。这里有一个细节模板变更不是实时的节点下一次上报心跳才会拉取新配置所以改完之后等一个上报周期再验证。3.2 自定义仿真页面改 HTML 和返回头内置模板的仿真页面比较通用如果你想让 HTTP 蜜罐看起来更像真实业务可以自定义返回内容。HFish 的模板目录下每个服务有一个template文件夹里面是 HTML 文件和配置文件。# 进入 HTTP 模板目录 cd /opt/hfish/node/template/http # 查看当前模板文件 ls -la你会看到index.html和一个config.json。index.html就是攻击者访问时看到的页面直接替换成你自己的登录页或者错误页。config.json里可以配返回头比如Server字段默认是nginx你可以改成Apache或者别的让指纹看起来更真实。{ server_header: Apache/2.4.41 (Ubuntu), status_code: 200, response_delay_ms: 100 }response_delay_ms是响应延迟单位毫秒。加一点延迟会让仿真服务更像真实服务器但别加太多超过 500ms 攻击者可能会觉得异常。改完模板文件重启节点生效。注意自定义页面不要放任何真实业务的敏感信息蜜罐页面是给攻击者看的不是给用户看的。3.3 告警规则什么情况下该通知你HFish 的告警规则决定了哪些事件会推送到你的邮箱、Webhook 或者钉钉。默认规则比较宽端口扫描也会告警跑一天下来邮箱会被塞满。我的做法是分层高频低危事件只记录不告警比如单纯的端口连接涉及登录尝试、命令执行、文件上传的才告警。在管理端的「告警配置」里可以按服务类型、按来源 IP、按事件等级设置过滤条件。比如 SSH 服务只对密码尝试次数超过 3 次的来源 IP 告警HTTP 服务只对 POST 请求和特定路径告警。这样能把噪音降下来真正有攻击行为的时候你才会注意到。Webhook 的配置格式是 JSON管理端会往你填的地址 POST 一条 JSON 数据。如果你用钉钉或者企业微信中间需要一个转换服务把 HFish 的 JSON 转成机器人能识别的格式。这个转换服务自己写一个简单的 Flask 或者 Node 脚本就行不复杂。4. 避坑与排查节点掉线、端口冲突、告警风暴4.1 节点显示离线但进程还在现象管理端界面上节点是灰色但登录到节点机器上ps能看到hfish-node进程在跑。原因节点和管理端之间的心跳断了。常见的是通信端口被防火墙拦了或者管理端地址配错了。还有一种情况是管理端换了 IP节点配置没更新。解决先在节点机器上telnet 管理端IP 4434看端口通不通。不通就查防火墙和安全组。通的话看节点日志日志里会打印心跳失败的具体原因。如果是管理端 IP 变了改节点配置文件里的地址重启节点。4.2 节点启动报端口占用现象节点启动失败日志里写bind: address already in use。原因HFish 要监听的端口被真实服务占了。最常见的是 80 和 443很多机器上本来就跑了 Nginx 或者 Apache。解决两个选择。要么改真实服务的端口把 80 让给 HFish要么在管理端把 80 的仿真模板关掉只保留其他端口。我一般选后者因为改真实服务端口影响面大。关掉模板之后节点重启端口冲突就没了。4.3 告警邮件一天几百封现象邮箱被 HFish 的告警邮件塞满大部分是端口扫描和无效连接。原因告警规则太宽没有做过滤。默认配置下任何连接都会触发告警。解决进管理端「告警配置」把「端口扫描」类事件的告警关掉只保留「登录尝试」「命令执行」「文件上传」这些高价值事件。同时设置来源 IP 白名单把你自己的扫描器 IP 加进去避免自己人触发告警。调整之后告警量能降一个数量级。4.4 管理端数据库写入慢现象节点数量多了之后管理端界面卡顿告警延迟从几秒变成几分钟。原因默认的 SQLite 数据库在高并发写入下性能不够。每个节点每次上报都会写库节点多了写入频率线性增长。解决换 MySQL。管理端配置文件里改数据库连接串重启管理端。数据迁移用管理端自带的导出功能先导出再导入 MySQL。换完之后写入性能明显改善界面也不卡了。4.5 仿真服务被攻击者识破现象攻击者连上 SSH 仿真端口试了一次就断开没有后续动作。原因仿真服务的指纹太明显。比如 SSH 版本号是默认的或者登录失败返回的消息和真实 SSH 不一样。解决改仿真模板的版本号和返回消息。SSH 模板的配置文件里可以改banner字段改成和真实服务器一致的版本号。HTTP 模板改Server头。这些细节不影响功能但能提高仿真服务的可信度让攻击者愿意多停留一会儿。5. 进阶用 HFish 做攻击者画像和溯源线索5.1 从告警日志里提取攻击者指纹HFish 记录的每一条事件都带来源 IP、时间、服务类型、交互内容。单条看没什么积累一周之后就能做画像。我一般会导出事件日志用 Python 做几个统计来源 IP 的地理分布、最常被尝试的用户名密码组合、攻击时间段的分布。import sqlite3 import pandas as pd # 连接 HFish 的 SQLite 数据库如果没换 MySQL conn sqlite3.connect(/opt/hfish/management/data/hfish.db) # 读取 SSH 登录尝试记录 df pd.read_sql(SELECT src_ip, username, password, create_time FROM ssh_login_attempts, conn) # 统计尝试次数最多的来源 IP top_ips df.groupby(src_ip).size().sort_values(ascendingFalse).head(20) print(top_ips) # 统计最常用的用户名密码组合 top_creds df.groupby([username, password]).size().sort_values(ascendingFalse).head(20) print(top_creds)这段代码的逻辑很直接从数据库里拉出 SSH 登录尝试记录按来源 IP 和用户名密码组合做聚合。top_ips能告诉你哪些 IP 最活跃top_creds能告诉你攻击者最常用的弱口令是什么。这些信息可以用来加固真实服务器的密码策略也可以用来做 IP 封禁。参数说明sqlite3.connect的路径根据你的实际安装位置调整。如果换了 MySQL把连接方式改成pymysql或者sqlalchemy。head(20)是取前 20 条按需调整。5.2 把蜜罐数据接入现有安全体系HFish 的 Webhook 可以把告警实时推送到你的 SIEM 或者 SOAR 平台。我一般会写一个中间服务接收 HFish 的 Webhook做两件事一是把事件格式转换成 SIEM 能识别的格式二是根据来源 IP 查威胁情报库如果 IP 有恶意记录就自动触发封禁。from flask import Flask, request import requests app Flask(__name__) app.route(/hfish-webhook, methods[POST]) def handle_webhook(): data request.json src_ip data.get(src_ip) event_type data.get(event_type) # 查威胁情报 intel requests.get(fhttps://你的威胁情报接口/check?ip{src_ip}).json() if intel.get(malicious): # 触发封禁逻辑 requests.post(https://你的防火墙接口/block, json{ip: src_ip}) # 转发到 SIEM requests.post(https://你的SIEM接口/ingest, jsondata) return ok, 200 if __name__ __main__: app.run(host0.0.0.0, port5000)这个中间服务的逻辑是接收 HFish 的告警提取来源 IP查威胁情报如果 IP 被标记为恶意就调防火墙接口封禁同时把事件转发到 SIEM。src_ip和event_type是 HFish Webhook 里带的字段具体字段名以你收到的实际 JSON 为准。提示封禁逻辑要加白名单别把自己人的 IP 封了。我一般会在封禁前先查一下这个 IP 是不是内部资产。5.3 验证蜜罐是否真的在工作的三个方法部署完之后怎么确认蜜罐真的在干活我一般用三个方法验证。第一个方法从另一台机器手动连一下仿真端口。比如telnet 蜜罐IP 22然后随便输一个用户名密码去管理端看有没有记录。有记录说明链路通了。第二个方法用扫描器扫一下蜜罐 IP。nmap -sS 蜜罐IP扫完之后管理端应该能看到端口扫描事件。如果没看到说明告警规则或者上报链路有问题。第三个方法看节点的连接数。在节点机器上netstat -an | grep 仿真端口如果有外部 IP 连着说明仿真服务在响应。这个方法适合排查仿真服务是否真的在监听。这三个方法从不同角度验证手动连验证记录链路扫描验证告警链路连接数验证监听状态。三个都通过蜜罐才算真正跑起来了。我自己的习惯是每次部署完新节点先手动连一次确认管理端有记录再去干别的。这个动作花不了一分钟但能省掉后面半小时的排查。希望帮到你。本文还有配套的精品资源点击获取