简介面向安全运维与攻防演练人员这份开源蜜罐 HFish 3.3.1 的 Linux 版本部署包可快速搭建轻量级蜜罐系统用于感知内网扫描、爆破与横向移动行为并借助攻击画像提升威胁溯源能力。压缩包共139个文件容量111.6MB包含前端界面所需的js/css/svg、后端配置与SQL初始化脚本、部署用shell脚本、证书文件及Windows客户端工具等涵盖启动、管理、展示与数据初始化各环节。默认管理入口账号admin、密码HFish2021便于用户开箱体验附带多份docx报告样例可作为告警分析输出参考。目前已有567人学习下载适合中高级安全工程师、蓝队人员及蜜罐技术研究者用于实验环境搭建与威胁分析练习。1. HFish 是什么为什么我盯上了它先说结论HFish 是一款开源的、主打“安全、简单、易用”的蜜罐系统我这次用的是v3.3.1 Linux 版本。它解决的问题很直接在一个内网环境里你怎么知道有没有人已经在横移、有没有主机被当跳板、有没有账号密码已经泄露并被试登录传统防守思路是堆防火墙、EDR、WAF但总有漏网之鱼。蜜罐的思路是反过来的——既然防不住那就主动放几个“假目标”出来谁碰它谁就有问题。HFish 跟传统蜜罐最大的区别在于“轻”。传统蜜罐比如 Kippo、Cowrie、Dionaea多是单点部署管理分散日志格式五花八门用起来很累。HFish 做成了 B/S 架构带一个 Web 管理端所有攻击数据集中展示还内置了几十种蜜罐服务模板比如 MySQL、Redis、SSH、FTP、Web 服务等等。你不需要自己去写服务模拟脚本点几下就能上线一个服务。我个人的使用场景是给客户做内网安全评估部署一套蜜罐作为“诱捕节点”观察攻击者进入内网后的行为路径。部署在 Linux 服务器上一次配置长周期运行数据可靠性要求高。HFish 的 Linux 版本在这方面表现稳定占用资源也低部署一台 2C4G 的云主机跑十几个蜜罐服务毫无压力。这篇文章就是把我在实际部署和使用 HFish v3.3.1 过程中的完整流程、踩坑记录、配置思路和问题排查方法整理出来给准备上手或者正在纠结选型的同学一个参考。2. 部署前必须想清楚的事蜜罐不是装上就完事2.1 蜜罐的部署位置决定你的数据价值很多人拿到 HFish 第一反应是“装到公网服务器上”然后等着扫描器来打。这样做确实能看到大量扫描流量但坦白说这类低质量数据除了吓唬自己之外分析价值很低——互联网上到处都是自动化扫描脚本碰一下就走了你怎么判断哪一次是真人攻击我的实际推荐是把蜜罐部署在内网的核心交换区或者业务隔离区。这样做的逻辑很简单攻击者从外部突破边界之后第二步一定是内网探测和横向移动。如果他在内网扫到一个莫名其妙的“MySQL 服务”并尝试连接这基本就能确认他正在找数据库口令、想拿业务数据。这种数据才是防守方真正需要的高价值情报。HFish 本身支持多节点部署可以一个管理端加多个蜜罐节点。管理端负责数据汇聚和展示节点只管跑蜜罐服务。我在实际部署时就是把管理端放在安全区把蜜罐节点分布在不同的业务网段。这样即使某个网段失守其他网段的节点还能继续工作数据也能完整回传到管理端。2.2 资源规划与版本选择HFish v3.3.1 这个版本从功能成熟度上来说已经相当能打了。它自带了一个“攻击payload”识别的功能能对攻击载荷做基础判断还内置了威胁情报对接模块可以拉取外部 IP 信誉库做标记。对于绝大多数中小企业或甲方安全团队来说这个功能集已经足够覆盖日常监控需求。资源方面HFish 官方建议的最低配置是 1核1G但我实测下来如果你要同时开启 8~10 个蜜罐服务并且开启每日攻击数据报告生成1G 内存会比较紧张高峰期有 OOM 风险。我个人的建议是至少2核4G这样管理端能跑得比较舒服。数据存储方面HFish v3.3.1 默认使用的是内嵌 SQLite如果你管理的节点较多、每天采集的攻击数据量较大建议提前在管理端配置 MySQL 存储避免长时间运行后 SQLite 文件过大导致查询变慢。这一点在部署文档里标得不是特别醒目很多人用了一个月之后才开始头疼我们不如在初始阶段就规划好。2.3 网络策略蜜罐服务最好别跟业务混在一起还有一个很容易被忽略的点蜜罐服务本身其实是有一定风险的。蜜罐的本质是要把攻击者吸引过来并与他交互这就意味着蜜罐服务端口必须对外开放攻击者确实可以连上来。如果蜜罐服务和核心业务数据库部署在同一台机器上那么即使蜜罐被攻破虽然概率不高但不是零风险也会被放大。所以部署蜜罐的服务器我强烈建议是独立的、不承载任何真实业务的服务器最好放在单独的安全域里。这样即使蜜罐被完全打穿损失也只是这台“假服务器”本身不会波及其他资产。这也符合蜜罐的本质属性它本身就是用来牺牲的。3. HFish v3.3.1 Linux 版安装全流程实录3.1 安装包获取与校验HFish 的发行版可以在 GitHub Releases 页面找到也可以从官网下载。我这次下载的是hfish-3.3.1-linux-amd64.tgz对应的系统是 CentOS 7.9内核版本 3.10。下载后先做一步校验。官方发布页面提供了 SHA256 校验值这个习惯一定要养成。虽然这次我们是从官方渠道下载但任何下载行为都应该校验一下完整性避免文件在传输过程中损坏或者被篡改。校验命令很简单wget https://github.com/hacklcx/HFish/releases/download/3.3.1/hfish-3.3.1-linux-amd64.tgz sha256sum hfish-3.3.1-linux-amd64.tgz把输出的哈希值和官方给出的值比对一致之后再进行解压。这一步能帮你规避掉绝大多数“解压后少文件”“启动报错”之类的基础问题。解压很简单tar zxvf hfish-3.3.1-linux-amd64.tgz cd hfish-3.3.1解压后目录结构长这样hfish/ ├── bin/ ├── conf/ ├── config/ ├── data/ ├── log/ ├── web/ └── start.shbin目录存放可执行二进制conf是配置文件相关web是前端页面文件log顾名思义就是日志。3.2 管理端初始化配置HFish 在 Linux 上的部署模式分两种单机模式和管理端节点模式。如果是小规模试用比如就一台服务器单机模式直接跑起来就行。如果是企业级部署建议采用管理端节点模式。管理端的核心配置在conf目录下的config.yaml文件中。v3.3.1 版本的默认配置中有几个关键项我实际部署时调整过system: http_port: 4433 # Web管理界面端口 data_port: 7879 # 节点与客户端通信端口 mysql_dsn: sqlite_path: ./data/hfish.db secret: change-me-pleasehttp_port是 Web 管理平台的访问端口data_port是节点向管理端上报数据的端口。secret这个字段是用来做节点通信加密的默认值是change-me-please这在实际生产环境里是绝对不能留着的。我之前见过不少部署案例管理端建起来了但secret没改节点通信相当于裸奔。建议用openssl rand -hex 16生成一个强随机密钥并填进去。如果你是首次部署直接在服务器上执行./start.sh启动脚本会检查目录结构、初始化数据库、启动对应的二进制进程。看到HFish is starting字样之后再等几秒浏览器访问https://服务器IP:4433就能看到初始化页面了。管理端默认使用 HTTPS 协议自签名证书在首次访问时会提示不受信任正常放行即可。首次进入系统会让你创建管理员账号这个账号是管理整套蜜罐系统的最高权限密码一定要设复杂一点不要使用弱口令。我见过有的部署为了图方便把管理端密码设为admin/123456结果蜜罐还没钓到攻击者管理端先被攻击者拿下了这就很尴尬——蜜罐反被端了真的是大型事故现场。3.3 节点部署与接入管理端节点部署是很多新手最迷糊的地方。HFish v3.3.1 的节点接入方式很直接在一台新的 Linux 服务器上解压同样的包然后执行./client -m 管理端IP:7879节点启动后会自动向管理端发起注册请求。管理端 Web 界面的“节点管理”里会看到一条新的待审批节点记录点击“同意接入”之后节点才正式加入管理。这里有一点很多人搞不懂节点不是启动就算接入的必须在管理端批准之后才会下发蜜罐服务配置。在实际操作中我建议把节点服务器上的config.yaml中secret也设置为与管理端相同的密钥这样通信过程会做一次认证握手避免别人伪造节点接入你的管理端窃取攻击数据或者下发恶意配置。管理端和节点之间的通信默认走的是data_port也就是 7879 端口。如果节点和服务器之间有防火墙记得先放通这条路径不然节点注册永远不成功你还会看到一堆connection refused的报错。4. 核心实操从零配置第一个蜜罐服务4.1 蜜罐服务模板的选择HFish 的蜜罐模板分两大类系统服务蜜罐和Web 应用蜜罐。系统服务蜜罐中最常用的是 SSH、MySQL、Redis、FTP、TelnetWeb 应用蜜罐则模拟了 Nginx、Tomcat、Spring Boot 等应用的登录页面或 API 接口。以我这次的实际部署为例我在内网一台节点上启用了三个服务SSH 蜜罐: 模拟一个对外开放的高危 SSH 服务记录攻击者爆破时使用的用户名字典和密码字典MySQL 蜜罐: 模拟一个 MySQL 数据库记录攻击者的连接尝试和 SQL 语句Web 登录页蜜罐: 模拟一个企业后台登录页记录攻击者的账号密码输入和后续的转发请求。选择这三个服务的原因是在内网横向移动的场景中攻击者最常探测的就是 SSH 弱口令和数据库弱口令Web 后台登录页则是用来测试撞库或弱口令的常用目标。用 HFish 默认的服务模板去模拟这些环境交互效果已经很逼真攻击者很难察觉这是陷阱。4.2 逐个配置蜜罐服务的详细过程进入管理端 Web 界面左侧菜单选择“服务管理”右上角点击“新建服务”。这里会让你选择节点、服务类型以及配置服务的监听端口和其他参数。以 MySQL 蜜罐为例点击“MySQL 服务”之后需要填这些参数服务名称: mysql-honeypot-01 监听端口: 3306 会话超时: 60秒 日志开关: 开启 匹配攻击类型: SQL注入/口令爆破监听端口选 3306这个端口在真实环境里太常见了攻击者扫到之后很容易上钩。不过要注意如果节点服务器上已经跑了真实的 MySQL端口会冲突所以建议给蜜罐分配独立的 IP 或者换端口。在 HFish 上同一台节点可以绑定多个 IP每个蜜罐服务可以指定监听在哪个 IP 上这样就能在同一台服务器上运行多个互不冲突的服务。SSH 蜜罐的配置稍微有点不同v3.3.1 默认的 SSH 蜜罐支持模拟版本 banner。攻击者用ssh -V或者直接连接时会看到你指定的 SSH banner 信息。默认比较有辨识度建议改成你环境中真实 SSH 的版本号比如SSH-2.0-OpenSSH_7.4这样攻击者第一眼看不出这是蜜罐。4.3 利用“自定义服务”模拟复杂协议HFish 内置模板覆盖了很多常见服务但如果你有特定业务想模拟还可以使用“自定义服务”功能。v3.3.1 的自定义服务支持 TCP 层的自定义协议模板你可以通过配置报文格式和应答内容来模拟任意一个简单的业务服务。实际操作中这个功能上手门槛稍高需要理解 TCP 协议的基础交互逻辑。举个例子如果你想模拟一个自定义的工控协议服务你需要根据该协议的类型、功能码、数据帧格式在 HFish 中配置监听端口、协议类型例如 Modbus TCP、S7comm 等、报文响应规则。系统会把请求包中的关键字段记录下来比如从站地址、寄存器地址、写入值等方便你分析攻击者是否针对工控系统发起了恶意操作。新手如果没有协议基础我不建议第一个蜜罐就上自定义服务容易因为配置不完整导致服务不可用或者被攻击者一眼识破。先从模板服务开始跑熟之后再进阶。5. 数据采集与告警配置怎么让蜜罐成为真正的“警铃”5.1 攻击数据的查看与筛选蜜罐装好、服务上线之后真正有价值的是它产生的情报数据。HFish 管理端的“攻击列表”页面会按照时间倒序展示所有攻击记录。每一条记录包含源 IP、目标端口、攻击类型、payload 内容、会话时长、节点名称等字段。在实际使用中攻击数据非常杂乱尤其是内网环境中还会有大量运维脚本的口令探测、监控系统的端口扫描等误报。因此学会筛选数据比学会部署蜜罐更重要。我推荐大家在“攻击列表”页面按这三步筛选按照攻击类型聚合排序重点看SQL注入、漏洞利用、后门访问这几种高可疑类型的攻击如果只是端口探测可以先放着。按照 IP 聚合查看行为同一个源 IP 如果有多次不同目标端口的攻击记录说明这个 IP 在尝试批量横移优先级立刻提高。按照时间维度看模式攻击行为集中在凌晨 1~5 点的大概率是真人操作全天候分布均匀的一般是扫描器或者蠕虫。这个特征在甲方溯源时非常实用。5.2 告警通知与自动化响应攻击数据看得到还不够你要能在第一时间收到通知。v3.3.1 的告警功能支持 Webhook 推送你可以配置把告警信息推送到企业微信机器人、钉钉机器人或者飞书机器人。配置方式很简单在“告警设置”里粘贴 Webhook 地址。我实际使用的是企业微信机器人告警消息会包含攻击源 IP、目标端口、攻击类型和 payload 摘要。这样可以做到攻击者一碰蜜罐值班手机上立刻弹出告警省去了每天登录后台翻日志的功夫。如果你愿意再深入一步可以将 HFish 的 Webhook 转发到内部的 SOC 平台或 SOAR 平台让蜜罐的告警自动联动防火墙封禁 IP。这就需要你在接收端写一个 Webhook 中转服务但这也是蜜罐系统真正发挥自动化价值的关键一步。我在实际项目中就用一个简单的 Python Flask 服务接收 HFish 告警然后调用防火墙 API 下发封禁策略整个过程 30 秒内完成自动化闭环效果非常好。6. 蜜罐安全加固保护你的蜜罐不被“反杀”6.1 管理端的访问控制这个环节很容易被忽视但却是蜜罐部署中最关键的一步。HFish 管理端是整套系统的“大脑”一旦管理端被攻击者拿下攻击者不仅能拿到所有蜜罐的日志数据还能看到蜜罐节点的分布情况甚至通过管理端下发恶意配置直接把你的蜜罐变成他的跳板。所以管理端部署后第一件事是加访问控制。如果你使用 Linux 服务器自带的 firewalld可以这么限制来源 IPfirewall-cmd --permanent --add-rich-rulerule familyipv4 source address你的安全网段 port protocoltcp port4433 accept firewall-cmd --permanent --remove-servicehttps firewall-cmd --reload上面这条规则意味着只有安全网段内的 IP 才能访问 Web 管理界面其他 IP 一律拒绝。这样即使管理端地址暴露在公网上攻击者也进不来。6.2 蜜罐服务本身的自我保护蜜罐服务端口为了诱捕效果必须对外开放但这不意味着我们可以不设防。在实际部署中建议在节点上启用系统的 TCPWrapper/etc/hosts.deny和/etc/hosts.allow或者在蜜罐外层加一层轻量防火墙规则放行必要的协议交互但限制一些明显的攻击行为来源 IP。另外蜜罐服务器本身要注意系统账户安全。不要设置弱密码禁用 root 远程登录定期更新系统补丁。有些蜜罐节点因为部署者疏于管理反而成了整个内网的突破口。蜜罐是来钓攻击者的不是给攻击者送礼的这一点一定要记住。7. 常见问题与排查技巧实录7.1 节点一直显示“离线”或“等待接入”这是我在交流群里看到最多的问题。原因大多出在数据端口不通。节点启动后它确实会尝试向管理端的 7879 端口发送注册信息但如果节点和管理端之间有防火墙拦截管理端会永远看不到节点状态。排查三步走# 1. 在节点上测试到管理端的数据端口连通性 telnet 管理端IP 7879 # 2. 在管理端上确认监听端口 netstat -tlnp | grep 7879 # 3. 查看节点的日志 tail -f log/client.log如果telnet不通多半是两台机器之间的防火墙没有放行数据端口如果client.log中出现secret mismatch之类字样则说明管理端和节点的密钥不一致改完密钥后重启节点服务即可。7.2 Web 管理页面无法打开页面打不开常见有两种原因管理端口没有在防火墙中放行检查4433端口是否被 firewalld 拦截。首次访问时使用了http://而不是https://。v3.3.1 默认启用 HTTPS如果使用 http 访问浏览器会显示“无法访问”或者被强制跳转到 https。这时候在浏览器地址栏直接输入https://服务器IP:4433就好。7.3 攻击数据没有上报蜜罐服务运行中攻击者也确实触发了交互但管理端攻击列表里一条记录都没有。这种问题通常出在数据库延迟写入上。v3.3.1 默认使用 SQLite 存储数据在高并发攻击的情况下数据写入会有一点延迟但一般不会超过几十秒。等待一段时间刷新页面看有没有数据。如果一直没有检查节点上的log/agent.log确认节点是否成功将数据上报给了管理端。我遇到过这样的情况管理端磁盘写满导致 SQLite 写入失败后来清掉部分历史数据后恢复正常。所以部署之后给服务器留足磁盘空间也很重要。7.4 自签名证书导致的浏览器拦截管理端页面默认使用自签名证书浏览器会给出“您的连接不是私密连接”的提示。这不影响功能使用点击“高级”-“继续前往”即可。如果你希望消除这个提示可以在管理端配置中换上受信任的证书但前提是域名解析正常。在生产环境建议使用企业内部的 CA 证书或外部 CA 证书。8. 实战经验分享HFish 给我带来的最大帮助部署和使用 HFish 这半年多我最大的感受是它不只是一个“工具”更是一个改变防守思路的“思路转变器”。传统安全运营依赖的是已知特征和规则而蜜罐提供的是“主动吸引”的视角。攻击者一旦碰到蜜罐暴露出来的就是真实意图和实战手法这是指纹库和特征库给不了你的。在实际项目中我曾用 HFish 在内网精准定位到一个通过 Wi-Fi 蹭网进入办公网的攻击者。他在蜜罐上尝试了 MySQL 弱口令HFish 记录了完整的客户端 IP 和登录时间我们顺着这个信息一路追查最终确认是外部人员混入了办公网。这种能力在传统安全设备上是很难实现的。最后再分享一个经验蜜罐的运营一定要有人定期去看。有很多单位装完蜜罐就不管了攻击数据堆了一大堆但从不分析、从不告警蜜罐成了“死罐”白白浪费了这么好的情报来源。蜜罐的最终价值不在“采集”而在“响应”。工具永远是辅助真正起决定性作用的是使用它的人。把这个工具用好你的内网安全感会提升一个档次。本文还有配套的精品资源点击获取 HFish蜜罐部署实战：内网安全威胁诱捕与攻击行为记录指南
简介面向安全运维与攻防演练人员这份开源蜜罐 HFish 3.3.1 的 Linux 版本部署包可快速搭建轻量级蜜罐系统用于感知内网扫描、爆破与横向移动行为并借助攻击画像提升威胁溯源能力。压缩包共139个文件容量111.6MB包含前端界面所需的js/css/svg、后端配置与SQL初始化脚本、部署用shell脚本、证书文件及Windows客户端工具等涵盖启动、管理、展示与数据初始化各环节。默认管理入口账号admin、密码HFish2021便于用户开箱体验附带多份docx报告样例可作为告警分析输出参考。目前已有567人学习下载适合中高级安全工程师、蓝队人员及蜜罐技术研究者用于实验环境搭建与威胁分析练习。1. HFish 是什么为什么我盯上了它先说结论HFish 是一款开源的、主打“安全、简单、易用”的蜜罐系统我这次用的是v3.3.1 Linux 版本。它解决的问题很直接在一个内网环境里你怎么知道有没有人已经在横移、有没有主机被当跳板、有没有账号密码已经泄露并被试登录传统防守思路是堆防火墙、EDR、WAF但总有漏网之鱼。蜜罐的思路是反过来的——既然防不住那就主动放几个“假目标”出来谁碰它谁就有问题。HFish 跟传统蜜罐最大的区别在于“轻”。传统蜜罐比如 Kippo、Cowrie、Dionaea多是单点部署管理分散日志格式五花八门用起来很累。HFish 做成了 B/S 架构带一个 Web 管理端所有攻击数据集中展示还内置了几十种蜜罐服务模板比如 MySQL、Redis、SSH、FTP、Web 服务等等。你不需要自己去写服务模拟脚本点几下就能上线一个服务。我个人的使用场景是给客户做内网安全评估部署一套蜜罐作为“诱捕节点”观察攻击者进入内网后的行为路径。部署在 Linux 服务器上一次配置长周期运行数据可靠性要求高。HFish 的 Linux 版本在这方面表现稳定占用资源也低部署一台 2C4G 的云主机跑十几个蜜罐服务毫无压力。这篇文章就是把我在实际部署和使用 HFish v3.3.1 过程中的完整流程、踩坑记录、配置思路和问题排查方法整理出来给准备上手或者正在纠结选型的同学一个参考。2. 部署前必须想清楚的事蜜罐不是装上就完事2.1 蜜罐的部署位置决定你的数据价值很多人拿到 HFish 第一反应是“装到公网服务器上”然后等着扫描器来打。这样做确实能看到大量扫描流量但坦白说这类低质量数据除了吓唬自己之外分析价值很低——互联网上到处都是自动化扫描脚本碰一下就走了你怎么判断哪一次是真人攻击我的实际推荐是把蜜罐部署在内网的核心交换区或者业务隔离区。这样做的逻辑很简单攻击者从外部突破边界之后第二步一定是内网探测和横向移动。如果他在内网扫到一个莫名其妙的“MySQL 服务”并尝试连接这基本就能确认他正在找数据库口令、想拿业务数据。这种数据才是防守方真正需要的高价值情报。HFish 本身支持多节点部署可以一个管理端加多个蜜罐节点。管理端负责数据汇聚和展示节点只管跑蜜罐服务。我在实际部署时就是把管理端放在安全区把蜜罐节点分布在不同的业务网段。这样即使某个网段失守其他网段的节点还能继续工作数据也能完整回传到管理端。2.2 资源规划与版本选择HFish v3.3.1 这个版本从功能成熟度上来说已经相当能打了。它自带了一个“攻击payload”识别的功能能对攻击载荷做基础判断还内置了威胁情报对接模块可以拉取外部 IP 信誉库做标记。对于绝大多数中小企业或甲方安全团队来说这个功能集已经足够覆盖日常监控需求。资源方面HFish 官方建议的最低配置是 1核1G但我实测下来如果你要同时开启 8~10 个蜜罐服务并且开启每日攻击数据报告生成1G 内存会比较紧张高峰期有 OOM 风险。我个人的建议是至少2核4G这样管理端能跑得比较舒服。数据存储方面HFish v3.3.1 默认使用的是内嵌 SQLite如果你管理的节点较多、每天采集的攻击数据量较大建议提前在管理端配置 MySQL 存储避免长时间运行后 SQLite 文件过大导致查询变慢。这一点在部署文档里标得不是特别醒目很多人用了一个月之后才开始头疼我们不如在初始阶段就规划好。2.3 网络策略蜜罐服务最好别跟业务混在一起还有一个很容易被忽略的点蜜罐服务本身其实是有一定风险的。蜜罐的本质是要把攻击者吸引过来并与他交互这就意味着蜜罐服务端口必须对外开放攻击者确实可以连上来。如果蜜罐服务和核心业务数据库部署在同一台机器上那么即使蜜罐被攻破虽然概率不高但不是零风险也会被放大。所以部署蜜罐的服务器我强烈建议是独立的、不承载任何真实业务的服务器最好放在单独的安全域里。这样即使蜜罐被完全打穿损失也只是这台“假服务器”本身不会波及其他资产。这也符合蜜罐的本质属性它本身就是用来牺牲的。3. HFish v3.3.1 Linux 版安装全流程实录3.1 安装包获取与校验HFish 的发行版可以在 GitHub Releases 页面找到也可以从官网下载。我这次下载的是hfish-3.3.1-linux-amd64.tgz对应的系统是 CentOS 7.9内核版本 3.10。下载后先做一步校验。官方发布页面提供了 SHA256 校验值这个习惯一定要养成。虽然这次我们是从官方渠道下载但任何下载行为都应该校验一下完整性避免文件在传输过程中损坏或者被篡改。校验命令很简单wget https://github.com/hacklcx/HFish/releases/download/3.3.1/hfish-3.3.1-linux-amd64.tgz sha256sum hfish-3.3.1-linux-amd64.tgz把输出的哈希值和官方给出的值比对一致之后再进行解压。这一步能帮你规避掉绝大多数“解压后少文件”“启动报错”之类的基础问题。解压很简单tar zxvf hfish-3.3.1-linux-amd64.tgz cd hfish-3.3.1解压后目录结构长这样hfish/ ├── bin/ ├── conf/ ├── config/ ├── data/ ├── log/ ├── web/ └── start.shbin目录存放可执行二进制conf是配置文件相关web是前端页面文件log顾名思义就是日志。3.2 管理端初始化配置HFish 在 Linux 上的部署模式分两种单机模式和管理端节点模式。如果是小规模试用比如就一台服务器单机模式直接跑起来就行。如果是企业级部署建议采用管理端节点模式。管理端的核心配置在conf目录下的config.yaml文件中。v3.3.1 版本的默认配置中有几个关键项我实际部署时调整过system: http_port: 4433 # Web管理界面端口 data_port: 7879 # 节点与客户端通信端口 mysql_dsn: sqlite_path: ./data/hfish.db secret: change-me-pleasehttp_port是 Web 管理平台的访问端口data_port是节点向管理端上报数据的端口。secret这个字段是用来做节点通信加密的默认值是change-me-please这在实际生产环境里是绝对不能留着的。我之前见过不少部署案例管理端建起来了但secret没改节点通信相当于裸奔。建议用openssl rand -hex 16生成一个强随机密钥并填进去。如果你是首次部署直接在服务器上执行./start.sh启动脚本会检查目录结构、初始化数据库、启动对应的二进制进程。看到HFish is starting字样之后再等几秒浏览器访问https://服务器IP:4433就能看到初始化页面了。管理端默认使用 HTTPS 协议自签名证书在首次访问时会提示不受信任正常放行即可。首次进入系统会让你创建管理员账号这个账号是管理整套蜜罐系统的最高权限密码一定要设复杂一点不要使用弱口令。我见过有的部署为了图方便把管理端密码设为admin/123456结果蜜罐还没钓到攻击者管理端先被攻击者拿下了这就很尴尬——蜜罐反被端了真的是大型事故现场。3.3 节点部署与接入管理端节点部署是很多新手最迷糊的地方。HFish v3.3.1 的节点接入方式很直接在一台新的 Linux 服务器上解压同样的包然后执行./client -m 管理端IP:7879节点启动后会自动向管理端发起注册请求。管理端 Web 界面的“节点管理”里会看到一条新的待审批节点记录点击“同意接入”之后节点才正式加入管理。这里有一点很多人搞不懂节点不是启动就算接入的必须在管理端批准之后才会下发蜜罐服务配置。在实际操作中我建议把节点服务器上的config.yaml中secret也设置为与管理端相同的密钥这样通信过程会做一次认证握手避免别人伪造节点接入你的管理端窃取攻击数据或者下发恶意配置。管理端和节点之间的通信默认走的是data_port也就是 7879 端口。如果节点和服务器之间有防火墙记得先放通这条路径不然节点注册永远不成功你还会看到一堆connection refused的报错。4. 核心实操从零配置第一个蜜罐服务4.1 蜜罐服务模板的选择HFish 的蜜罐模板分两大类系统服务蜜罐和Web 应用蜜罐。系统服务蜜罐中最常用的是 SSH、MySQL、Redis、FTP、TelnetWeb 应用蜜罐则模拟了 Nginx、Tomcat、Spring Boot 等应用的登录页面或 API 接口。以我这次的实际部署为例我在内网一台节点上启用了三个服务SSH 蜜罐: 模拟一个对外开放的高危 SSH 服务记录攻击者爆破时使用的用户名字典和密码字典MySQL 蜜罐: 模拟一个 MySQL 数据库记录攻击者的连接尝试和 SQL 语句Web 登录页蜜罐: 模拟一个企业后台登录页记录攻击者的账号密码输入和后续的转发请求。选择这三个服务的原因是在内网横向移动的场景中攻击者最常探测的就是 SSH 弱口令和数据库弱口令Web 后台登录页则是用来测试撞库或弱口令的常用目标。用 HFish 默认的服务模板去模拟这些环境交互效果已经很逼真攻击者很难察觉这是陷阱。4.2 逐个配置蜜罐服务的详细过程进入管理端 Web 界面左侧菜单选择“服务管理”右上角点击“新建服务”。这里会让你选择节点、服务类型以及配置服务的监听端口和其他参数。以 MySQL 蜜罐为例点击“MySQL 服务”之后需要填这些参数服务名称: mysql-honeypot-01 监听端口: 3306 会话超时: 60秒 日志开关: 开启 匹配攻击类型: SQL注入/口令爆破监听端口选 3306这个端口在真实环境里太常见了攻击者扫到之后很容易上钩。不过要注意如果节点服务器上已经跑了真实的 MySQL端口会冲突所以建议给蜜罐分配独立的 IP 或者换端口。在 HFish 上同一台节点可以绑定多个 IP每个蜜罐服务可以指定监听在哪个 IP 上这样就能在同一台服务器上运行多个互不冲突的服务。SSH 蜜罐的配置稍微有点不同v3.3.1 默认的 SSH 蜜罐支持模拟版本 banner。攻击者用ssh -V或者直接连接时会看到你指定的 SSH banner 信息。默认比较有辨识度建议改成你环境中真实 SSH 的版本号比如SSH-2.0-OpenSSH_7.4这样攻击者第一眼看不出这是蜜罐。4.3 利用“自定义服务”模拟复杂协议HFish 内置模板覆盖了很多常见服务但如果你有特定业务想模拟还可以使用“自定义服务”功能。v3.3.1 的自定义服务支持 TCP 层的自定义协议模板你可以通过配置报文格式和应答内容来模拟任意一个简单的业务服务。实际操作中这个功能上手门槛稍高需要理解 TCP 协议的基础交互逻辑。举个例子如果你想模拟一个自定义的工控协议服务你需要根据该协议的类型、功能码、数据帧格式在 HFish 中配置监听端口、协议类型例如 Modbus TCP、S7comm 等、报文响应规则。系统会把请求包中的关键字段记录下来比如从站地址、寄存器地址、写入值等方便你分析攻击者是否针对工控系统发起了恶意操作。新手如果没有协议基础我不建议第一个蜜罐就上自定义服务容易因为配置不完整导致服务不可用或者被攻击者一眼识破。先从模板服务开始跑熟之后再进阶。5. 数据采集与告警配置怎么让蜜罐成为真正的“警铃”5.1 攻击数据的查看与筛选蜜罐装好、服务上线之后真正有价值的是它产生的情报数据。HFish 管理端的“攻击列表”页面会按照时间倒序展示所有攻击记录。每一条记录包含源 IP、目标端口、攻击类型、payload 内容、会话时长、节点名称等字段。在实际使用中攻击数据非常杂乱尤其是内网环境中还会有大量运维脚本的口令探测、监控系统的端口扫描等误报。因此学会筛选数据比学会部署蜜罐更重要。我推荐大家在“攻击列表”页面按这三步筛选按照攻击类型聚合排序重点看SQL注入、漏洞利用、后门访问这几种高可疑类型的攻击如果只是端口探测可以先放着。按照 IP 聚合查看行为同一个源 IP 如果有多次不同目标端口的攻击记录说明这个 IP 在尝试批量横移优先级立刻提高。按照时间维度看模式攻击行为集中在凌晨 1~5 点的大概率是真人操作全天候分布均匀的一般是扫描器或者蠕虫。这个特征在甲方溯源时非常实用。5.2 告警通知与自动化响应攻击数据看得到还不够你要能在第一时间收到通知。v3.3.1 的告警功能支持 Webhook 推送你可以配置把告警信息推送到企业微信机器人、钉钉机器人或者飞书机器人。配置方式很简单在“告警设置”里粘贴 Webhook 地址。我实际使用的是企业微信机器人告警消息会包含攻击源 IP、目标端口、攻击类型和 payload 摘要。这样可以做到攻击者一碰蜜罐值班手机上立刻弹出告警省去了每天登录后台翻日志的功夫。如果你愿意再深入一步可以将 HFish 的 Webhook 转发到内部的 SOC 平台或 SOAR 平台让蜜罐的告警自动联动防火墙封禁 IP。这就需要你在接收端写一个 Webhook 中转服务但这也是蜜罐系统真正发挥自动化价值的关键一步。我在实际项目中就用一个简单的 Python Flask 服务接收 HFish 告警然后调用防火墙 API 下发封禁策略整个过程 30 秒内完成自动化闭环效果非常好。6. 蜜罐安全加固保护你的蜜罐不被“反杀”6.1 管理端的访问控制这个环节很容易被忽视但却是蜜罐部署中最关键的一步。HFish 管理端是整套系统的“大脑”一旦管理端被攻击者拿下攻击者不仅能拿到所有蜜罐的日志数据还能看到蜜罐节点的分布情况甚至通过管理端下发恶意配置直接把你的蜜罐变成他的跳板。所以管理端部署后第一件事是加访问控制。如果你使用 Linux 服务器自带的 firewalld可以这么限制来源 IPfirewall-cmd --permanent --add-rich-rulerule familyipv4 source address你的安全网段 port protocoltcp port4433 accept firewall-cmd --permanent --remove-servicehttps firewall-cmd --reload上面这条规则意味着只有安全网段内的 IP 才能访问 Web 管理界面其他 IP 一律拒绝。这样即使管理端地址暴露在公网上攻击者也进不来。6.2 蜜罐服务本身的自我保护蜜罐服务端口为了诱捕效果必须对外开放但这不意味着我们可以不设防。在实际部署中建议在节点上启用系统的 TCPWrapper/etc/hosts.deny和/etc/hosts.allow或者在蜜罐外层加一层轻量防火墙规则放行必要的协议交互但限制一些明显的攻击行为来源 IP。另外蜜罐服务器本身要注意系统账户安全。不要设置弱密码禁用 root 远程登录定期更新系统补丁。有些蜜罐节点因为部署者疏于管理反而成了整个内网的突破口。蜜罐是来钓攻击者的不是给攻击者送礼的这一点一定要记住。7. 常见问题与排查技巧实录7.1 节点一直显示“离线”或“等待接入”这是我在交流群里看到最多的问题。原因大多出在数据端口不通。节点启动后它确实会尝试向管理端的 7879 端口发送注册信息但如果节点和管理端之间有防火墙拦截管理端会永远看不到节点状态。排查三步走# 1. 在节点上测试到管理端的数据端口连通性 telnet 管理端IP 7879 # 2. 在管理端上确认监听端口 netstat -tlnp | grep 7879 # 3. 查看节点的日志 tail -f log/client.log如果telnet不通多半是两台机器之间的防火墙没有放行数据端口如果client.log中出现secret mismatch之类字样则说明管理端和节点的密钥不一致改完密钥后重启节点服务即可。7.2 Web 管理页面无法打开页面打不开常见有两种原因管理端口没有在防火墙中放行检查4433端口是否被 firewalld 拦截。首次访问时使用了http://而不是https://。v3.3.1 默认启用 HTTPS如果使用 http 访问浏览器会显示“无法访问”或者被强制跳转到 https。这时候在浏览器地址栏直接输入https://服务器IP:4433就好。7.3 攻击数据没有上报蜜罐服务运行中攻击者也确实触发了交互但管理端攻击列表里一条记录都没有。这种问题通常出在数据库延迟写入上。v3.3.1 默认使用 SQLite 存储数据在高并发攻击的情况下数据写入会有一点延迟但一般不会超过几十秒。等待一段时间刷新页面看有没有数据。如果一直没有检查节点上的log/agent.log确认节点是否成功将数据上报给了管理端。我遇到过这样的情况管理端磁盘写满导致 SQLite 写入失败后来清掉部分历史数据后恢复正常。所以部署之后给服务器留足磁盘空间也很重要。7.4 自签名证书导致的浏览器拦截管理端页面默认使用自签名证书浏览器会给出“您的连接不是私密连接”的提示。这不影响功能使用点击“高级”-“继续前往”即可。如果你希望消除这个提示可以在管理端配置中换上受信任的证书但前提是域名解析正常。在生产环境建议使用企业内部的 CA 证书或外部 CA 证书。8. 实战经验分享HFish 给我带来的最大帮助部署和使用 HFish 这半年多我最大的感受是它不只是一个“工具”更是一个改变防守思路的“思路转变器”。传统安全运营依赖的是已知特征和规则而蜜罐提供的是“主动吸引”的视角。攻击者一旦碰到蜜罐暴露出来的就是真实意图和实战手法这是指纹库和特征库给不了你的。在实际项目中我曾用 HFish 在内网精准定位到一个通过 Wi-Fi 蹭网进入办公网的攻击者。他在蜜罐上尝试了 MySQL 弱口令HFish 记录了完整的客户端 IP 和登录时间我们顺着这个信息一路追查最终确认是外部人员混入了办公网。这种能力在传统安全设备上是很难实现的。最后再分享一个经验蜜罐的运营一定要有人定期去看。有很多单位装完蜜罐就不管了攻击数据堆了一大堆但从不分析、从不告警蜜罐成了“死罐”白白浪费了这么好的情报来源。蜜罐的最终价值不在“采集”而在“响应”。工具永远是辅助真正起决定性作用的是使用它的人。把这个工具用好你的内网安全感会提升一个档次。本文还有配套的精品资源点击获取