HFish蜜罐部署实战：从环境准备到排错全流程

简介：开源蜜罐系统HFish 3.3.1 Linux版本，面向安全运维、红蓝对抗团队及企业安全建设者，用于快速部署蜜罐环境，诱捕扫描探测与攻击行为，并采集威胁情报。整套资源打包为tgz格式，共139个文件，包含前端管理界面（js、css、svg、png）、数据库初始化与查询脚本（sql）、服务端核心程序（server、hfish）、部署脚本（sh）、跨平台客户端工具（client、exe）、证书文件（pem）以及报告模板（docx）等文件类型，压缩包约111.6MB，从环境搭建、功能配置到日志分析均有对应内容。内置admin默认账号与初始化登录密码，便于首次登录体验管理后台；附带的docx报告与csv数据可直接用于攻击记录汇报。当前已有567人学习，该版本适合需要自建蜜罐平台、开展攻防演练或验证检测响应能力的初中高级安全工程师。

1. 为什么在一堆安全工具里，我最后还是把蜜罐选型定在 HFish 上

1.1 蜜罐在防御体系里的真实位置

先说说我做蜜罐选型时的一个真实感触。很多团队总觉得把防火墙、WAF、EDR 部署齐了就够了，蜜罐可有可无。但实际上，这些防护手段的目标都是“挡住攻击”，而蜜罐做的事完全不同——它是主动制造诱饵，等攻击者自己撞进来。真正的价值不在于拦截，而在于观察：观察攻击者用什么工具扫、走什么流程、想摸哪个端口，这些信息用传统安全设备很难拿到。

我做的最初一次蜜罐实验，是在一个几乎没有业务流量的测试网段放了一台 SSH 蜜罐。结果呢，上线不到 6 个小时，后台就收到了几百条来自不同地区的扫描记录。那个瞬间我突然意识到，身边网络里扫描探测的活跃程度，远比你想象的高得多。有了这些数据，不管是溯源还是加固，方向感都清晰了。

1.2 中心端 + 节点的架构优势

HFish 让我觉得最顺手的一点，是它的“中心端 + 节点”架构。你不需要每台服务器上都装一套独立的管理端，而是部署一个中心端做管理和数据汇总，再把轻量级的节点散落到各个网段。节点只负责运行蜜罐服务和上报数据，中心端统一展示攻击事件。

这种架构贴合了大多数企业的实际网络情况。比如你有办公网、生产网、测试网，每个网段里丢一个节点，所有攻击数据都回流到中心端，不需要挨个登录服务器看日志。而且节点资源消耗非常小，塞在虚拟机里跑完全没问题。对于安全研究或红队溯源场景，也可以通过临时部署高交互蜜罐节点，快速扩展诱捕范围。

1.3 3.3.1 这个版本值得关注的理由

版本号这个东西，不是越新越好，关键是适合自己的部署环境和需求。我选 3.3.1 作为演示和落地版本，主要基于三个原因：

• 3.x 系列整体架构稳定，3.3.1 属于修复了一些兼容性问题之后的版本，踩坑概率相对低；
• 网上的教程、社区问答、插件资源大多围绕 3.x 系列展开，遇到问题更容易找到现成答案；
• 官方对 Linux 环境和国产化系统的适配在 3.3.1 版本里已经比较完整。

当然，如果你是从零开始，拉官方最新版也可以，但如果你对这套系统还不熟悉，从一个有大量参考资料沉淀的版本入手，会更顺利。

2. 实际动手前：环境和端口的准备，能省掉你后面一半的排查时间

2.1 服务器配置与系统选型

蜜罐系统对硬件的要求真不算高，但千万别以为“随便一台机器就能跑”。我见过不少人在低配环境下装了蜜罐，结果攻击量一上来，数据库写入延迟，后台页面卡死，节点心跳丢失。这很影响判断。

我自己习惯的参考配置是这样的：

操作系统选型上，如果你用的是公司内部统一管理的 CentOS 或者 Ubuntu LTS，直接装就行。如果涉及国产化环境，比如麒麟、统信 UOS，需要确认有没有对应的适配包。HFish 3.3.1 对部分国产系统做了适配，但不同 CPU 架构（x86、ARM、MIPS）对应的二进制包不一样，下载时千万别选错。

2.2 基础依赖和工具检查

HFish 是 Go 语言写的，二进制基本都是静态编译，常规情况下不需要装什么运行库。但它安装过程依赖 bash、tar、wget 或 curl，这些工具在绝大多数 Linux 发行版里都自带，不过保险起见，我每次部署前还是会先检查一遍：

which bash && which tar && which wget && which curl

空的结果就补装对应工具包。另外还有一点容易忽略：glibc 版本。如果你的系统比较老，比如 CentOS 6 或者更早的 Debian，二进制可能跑不起来，报错信息类似version GLIBC_2.14 not found。遇到这种问题，要么升级系统，要么换兼容包，要么直接用容器方案。

2.3 端口规划与防火墙放行

HFish 3.3.1 默认需要用到的端口不算多，但每一个都不能漏：

• 4433：管理端 Web 页面，HTTPS 访问；
• 4434：节点与中心端之间的通信端口，TCP；
• 各蜜罐服务的监听端口，取决于你要开哪些服务，比如 SSH 蜜罐通常监听 22，HTTP 蜜罐监听 80 或 8080。

在部署之前，先把这些端口在防火墙和云安全组里放行。我见过很多新手在服务器本地测通了，但外网就是访问不了，最后发现云控制台的安全组根本没开。以 firewalld 为例：

firewall-cmd --permanent --add-port=4433/tcp firewall-cmd --permanent --add-port=4434/tcp firewall-cmd --reload

如果用 ufw，则执行ufw allow 4433/tcp和ufw allow 4434/tcp。这里有个细节值得记住：云安全组和系统防火墙是两层，两边都要放行，缺一不可。

3. 下载、解压、装完：从安装包到管理后台能访问的全过程

3.1 从官方仓库获取 3.3.1 安装包

HFish 的 Linux 版本安装包，在 GitHub 的 Releases 页面能找到。进入项目主页后，找到 v3.3.1 的 release 记录，展开 Assets 列表，选择对应的系统架构压缩包。常见文件名格式类似hfish-3.3.1-linux-amd64.tgz，ARM 平台则是arm64结尾。

下载这一步，我建议的两种方式：

# 方式一：直接用 wget 拉取，注意将地址替换为 release 页面实际展示的下载链接 wget https://github.com/hackxf/hfish/releases/download/v3.3.1/hfish-3.3.1-linux-amd64.tgz # 方式二：先在本地下载，再通过 scp 传到服务器 scp hfish-3.3.1-linux-amd64.tgz root@your-server-ip:/opt/

无论哪种方式，下载完成后都建议校验一下文件哈希，确认下载过程没有损坏。GitHub 的 release 页面一般会附带 SHA256 校验值，用sha256sum命令比对即可：

sha256sum hfish-3.3.1-linux-amd64.tgz

3.2 执行安装脚本时发生了什么

解压和执行安装，步骤不复杂：

tar -zxvf hfish-3.3.1-linux-amd64.tgz cd hfish-3.3.1 chmod +x install.sh ./install.sh

很多新手看到脚本刷屏就慌了，其实正常情况下，脚本主要帮你做了四件事：

1. 把服务端和节点端二进制文件安装到指定目录，通常是/usr/local/hfish；
2. 创建独立的运行账号，确保蜜罐服务不用 root 身份跑，减少被攻击后的提权风险；
3. 初始化默认数据库，默认是 SQLite；
4. 注册 systemd 服务并设置开机自启动。

安装完成后，可以用systemctl edit或直接编辑 service 文件调整启动参数，但初次部署不建议乱改，保持默认先跑通再优化。

3.3 首次启动和地址确认

安装脚本正常结束后，服务应该已经自动启动了。查看状态：

systemctl status hfish

如果一切正常，浏览器访问https://服务器IP:4433/web/。这里必然会出现一个证书警告，因为 HFish 默认用的是自签名证书，浏览器没法校验合法性。这个警告点“高级 - 继续前往”即可，毕竟是你自己的环境。

注意：管理端地址一定要用 HTTPS，端口是 4433，不是 80 也不是 8080。很多人习惯性输入http://IP:4433，结果访问不通，其实是因为 HTTP 和 HTTPS 协议不匹配。

4. 管理端配置与蜜罐服务上线的第一课

4.1 登录安全与账号初始化

首次登录的管理员账号是admin，初始密码是hfish。登录成功后，系统会强制要求修改密码，这一步必须认真对待。蜜罐管理端如果直接暴露在公网，默认密码就是给攻击者送人头的。

我遇到的几个环境里，负责部署的同事习惯性地把密码改成简单组合，比如Admin@123，结果没过几天就被爆破攻击。其实蜜罐本身的目的就是吸引攻击者，管理端更要做好防护。建议修改后的密码至少 12 位，包含大小写字母、数字和特殊符号。如果有条件，最好额外配置登录 IP 白名单。

4.2 节点接入：从中心端下发到节点上线

节点接入是 HFish 部署里最有技术含量的步骤之一。登录管理端后，进入“节点管理”页面，点击新增节点，会生成一段令牌（token）和对应的安装命令，一般是这样的形态：

curl -sSL "https://中心端IP:4434/install.sh?token=xxxxxxxx" | bash

把这段命令在节点服务器上执行，节点就会拉取安装脚本，自动配置好中心端地址和令牌，然后启动节点服务。执行完成后，回到管理端的“节点管理”页面，刷新一下，正常状态下节点状态会显示“在线”。

这里有个比较隐蔽的坑：节点和中心端之间的时间必须同步。如果节点系统时间比中心端偏差过大，证书校验和通信都会失败，节点会反复连接不上，日志里还会出现 TLS 相关的报错。所以节点部署前，我用ntpdate或者chronyc做一次时间同步已经成了习惯。

4.3 常用蜜罐服务的配置组合

节点上线之后，就可以在管理端给节点分配蜜罐服务了。以一台典型的 Linux 节点为例，我通常会这样组合：

• SSH 蜜罐，监听 22 端口，模拟真实 SSH 登录流程；
• HTTP 蜜罐，监听 80，模拟一个后台管理系统登录页；
• MySQL 蜜罐，监听 3306，诱捕横向移动时尝试数据库连接的行为；
• Redis 蜜罐，监听 6379，这种情况在真实攻击链里很常见。

在后台的操作路径是：节点管理 → 选择目标节点 → 添加蜜罐服务 → 选择协议类型 → 填写端口 → 保存。配置完成后，蜜罐服务会随着节点的心跳自动下发并启动。

实际操作中还有个小技巧：不要把蜜罐的服务端口设置在 1000 以外的大端口，因为攻击脚本默认扫描的还是 22、3306、6379、8080 这些常见端口。如果蜜罐监听在 6379，防护效果远好于监听在 63330 这种冷门端口。判断一个蜜罐配置是否合理，就看“攻击者扫到你节点的概率高不高”。

5. 部署和运行中的多个常见病，以及对应的排查链路

5.1 管理页面访问不了？按这个顺序查

如果浏览器访问管理端超时或连不上，不要急着重装。我的排查顺序是：

第一步，看本机端口是否在监听：

ss -lntp | grep 4433

没有输出，说明服务没起来或者端口不对。看服务状态和日志：

systemctl status hfish journalctl -u hfish -n 100 --no-pager

日志里最常见的几种情况：端口被占用、数据库初始化失败、运行目录权限不对。端口被占用的话，先用ss -lntp | grep 4433找到占用进程，决定是换端口还是停掉冲突服务。

第二步，如果端口在监听，考虑防火墙。先在本机测试：

curl -k https://127.0.0.1:4433/web/

本机能通，外网不通，基本就是安全组或系统防火墙的问题，回到第 2 节检查防火墙的两层规则。

第三步，如果是云主机，还要检查安全组入方向规则。很多云厂商的安全组默认只放行 80、443 等常用端口，其他端口一律拒绝，这就解释了为什么本机能访问但外网不能。

5.2 节点一直不在线，问题可能出在哪

节点显示“离线”或者反复“连接中”，是部署时最容易遇到的问题。定位思路要先看通信链路，再分析日志。

在节点机器上查看节点进程：

ps -ef | grep hfish tail -f /usr/local/hfish/agent/logs/hfish-agent.log

日志里如果出现connection refused，说明中心端的 4434 端口没监听，或者防火墙拦截了节点访问。如果是token invalid或unauthorized，说明节点配置的 token 和管理端不一致，需要回到节点管理页面重新生成安装命令。

还有一个很隐蔽的坑是节点上跑着多个 hfish-agent 实例。有时候安装脚本执行了两次，系统里会有两个 agent 进程抢同一个端口，导致心跳上报异常。这时候用ps -ef | grep hfish-agent查看进程数量，如果有重复，全部 kill 再重启一个实例。

5.3 蜜罐端口被系统服务占用

最典型的是 SSH 蜜罐绑定 22 端口，但节点服务器本身也开着真实的 sshd 服务。这种情况下，蜜罐无法绑定端口，后台会提示启动失败。

解决思路有两个方向：

• 调整节点真实 sshd 的监听端口，比如改到 2222，把 22 完全留给蜜罐；
• 或者蜜罐不使用 22，改到 22222 等自定义端口。

我的建议是前者，因为攻击者扫描默认扫描 22 端口，把真实 SSH 移到不常用端口，既降低了真实服务暴露面，又方便蜜罐占住 22。

修改 sshd 端口后记得重启：

sed -i 's/#Port 22/Port 2222/' /etc/ssh/sshd_config systemctl restart sshd

然后确认防火墙也放行了新端口，否则会把自己锁在服务器外面。

5.4 SELinux / AppArmor 的隐形拦截

很多 Linux 服务器默认开启了 SELinux 或者 AppArmor，服务端和节点的二进制文件如果没有对应策略，会被系统安全模块拦截，产生类似Permission denied或Operation not permitted的报错。

处理方式比较直接：

• 临时验证环境可以先设置 SELinux 为宽松模式：setenforce 0；
• 确认问题由 SELinux 导致后，再决定是长期关闭、给二进制添加策略，还是把服务放到容器环境。

在 CentOS 7 上我通常这样检查：

getenforce

如果返回Enforcing，可以先临时宽松测试，确认无误再配置正式策略。AppArmor 的检查在 Ubuntu 上通过aa-status查看加载的配置文件。生产环境直接关掉 SELinux 不是最好的方案，但蜜罐的二进制更新频率不高，配置好对应的文件上下文（context）就能稳定运行。

5.5 容器化部署的补充经验

如果你所在的团队基础环境是 Docker，HFish 也可以扔进容器跑。容器化带来的好处是摆脱宿主机 glibc 版本、SELinux 等环境差异问题，坏处是端口映射和网络模式要额外注意。

我比较推荐用host网络模式，让容器直接共享宿主机网络。这样蜜罐绑定端口的行为和裸机部署基本一致，不会出现端口映射遗漏导致蜜罐不可达的情况。唯一要做的是通过-v把数据目录挂载出来，防止容器重建后数据丢失：

docker run -d --name hfish --network host -v /data/hfish:/usr/local/hfish hfish:v3.3.1

6. 上线不代表结束——日志、告警和升级那些事

6.1 攻击日志的体量和磁盘规划

蜜罐上线后的第一周，是最能感受到“安全世界”真实压力的阶段。只要管理端口或蜜罐端口暴露在公网上，扫描流量几乎是 7×24 小时不间断的。后台的攻击列表会快速增长，单条记录虽然只有几 KB，但数量多了以后，磁盘占用很快会飙上来。

我自己的经验是，为 HFish 数据目录单独挂载一块数据盘，并且开启日志轮转或者定期清理过期数据。在管理后台可以设定攻击记录的保存时长，比如保留 90 天或 180 天，太旧的记录建议导出发票后清理，避免数据库膨胀导致查询变慢。

6.2 告警推送：别让告警疲劳毁掉主动感知

HFish 支持把攻击告警推送到钉钉、企业微信、飞书等平台的群机器人 Webhook，配置入口在“告警配置”里。

这里我想分享一个经验：不要对每一条攻击都开告警。高危漏洞扫描、全网背景扫描、随机端口探测，这些噪声占了攻击流量的 90% 以上。如果你把这些都推到企业微信群里，用不了一天，群里就变成高频骚扰，之后真出了高危事件，也没人认真看了。

我的告警策略是：

• 只对命中特定高价值蜜罐（比如 MySQL、Redis、OA 模拟）的事件告警；
• 同一源 IP 在短时间内命中多个蜜罐时，触发聚合告警；
• 监控节点离线事件，节点掉线本身就是一个值得关注的信号。

6.3 数据库备份和版本升级，要做在真正出问题之前

HFish 默认使用 SQLite，攻击数据其实就在一个数据库文件里。备份的思路很简单，定期把数据库文件拷贝到独立存储即可：

cp /usr/local/hfish/db/hfish.db /backup/hfish_$(date +%Y%m%d).db

如果数据量很大，建议切换 MySQL 存储。切换时在管理后台或者配置文件中指定 MySQL 连接信息，攻击数据就会写入 MySQL。用 MySQL 的好处是容量大、查询方便、备份体系成熟，适合攻击流量大、需要长期留存数据的场景。

版本升级我吃过一次亏。当时 3.x 版内一个子系统更新，我直接覆盖了二进制，结果原有的 SQLite 数据因为表结构变化读取失败，历史攻击记录全丢了。从那之后，无论升级哪个开源系统，我都会先做两件事：备份数据库，查看升级文档中关于数据迁移的说明。HFish 的升级包或者 release 说明里一般会写明是否需要执行数据库迁移脚本，照着做不会出大问题。

写了这么多，很多经验都是从踩坑里攒出来的。蜜罐这套东西，部署本身不复杂，难的是把它真正放到网络里持续运转起来。希望这篇过程记录能让你少走几步弯路。

本文还有配套的精品资源，点击获取