蜜罐部署实战：HFish、Cowrie、T-Pot选型与避坑指南

简介三种蜜罐Defnet、Pentbox、Cowrie的搭建与使用方法构成内容核心面向网络安全初学者、渗透测试人员以及对入侵诱捕与日志分析感兴趣的运维人员。资源以Defnet可视化蜜罐和Kali Linux环境下Pentbox、Cowrie的部署为主线覆盖从基础配置到日志观察、攻击捕获的完整流程既有Windows平台图形化操作演示也有Linux命令行部署示范适合需要快速掌握常用蜜罐选型与实操的读者。包体为1个docx文档大小约7.96MB图文说明与命令示例一并收录可按章节对照实践。已有3080人学习下载内容编排清晰包含Pentbox的自动/手动配置、Defnet虚拟服务与监听捕捉、Cowrie的Python环境部署及SSH端口修改等关键细节并附有实验现象说明能够帮助读者深入理解蜜罐的工作原理与实际安全价值。无论是用于实验教学、安全研究还是防御加固这份资料都能提供直接可用的参考。1. 蜜罐不是摆设三种方案分别解决什么问题内网横向移动是大部分防守方最头疼的阶段告警少、动作小只要有一台机器被拿下后面基本是畅通无阻。蜜罐是少数愿意“挨打”还能主动把攻击过程留痕的方案。这篇文章要讲的是三种蜜罐的搭建与使用方法HFish 适合业务内网快速布点和告警联动Cowrie 适合记录 SSH/Telnet 爆破后的完整命令T-Pot 适合把多种蜜罐聚合成一个研究平台。三种不需要全上按手里有多少机器、想解决什么问题选一到两种即可。如果你正准备做蜜罐部署可以直接按第三章的命令起步。新手跟完能跑通熟手可以对照第四章的坑位做加固。2. 选型对比三套蜜罐方案分别适合谁2.1 蜜罐的三种“交互度”低交互、中交互、高交互怎么选蜜罐的核心差异在交互度。低交互蜜罐只监听端口、返回预设的 banner 和响应攻击者敲两下命令就发现是假的但它的优势是便宜、安全、可以大量铺。中交互蜜罐会维持一个伪造的 shell攻击者敲进去的命令会被记录下来但它并不真正执行系统调用攻击者拿不到真实权限。高交互蜜罐直接给攻击者一个真实的操作系统或容器观察者能看到攻击者从入侵到提权的完整路径代价是维护成本和风险都很高——它本身就是个黑匣子你不知道会被打成什么样。选型逻辑很简单业务内网防守用低交互铺量看扫描和探测行为想研究爆破成功之后的命令用 Cowrie 这种中交互做攻防演练或恶意样本研究才值得上高交互。三者的数据价值也不一样低交互给你“谁来了”中交互给你“他要干什么”高交互给你“他能做到哪一步”。2.2 HFish分布式管理平台适合业务内网布点HFish 是开源蜜罐平台里少有的“管理端 节点”架构。管理端负责汇总数据、展示告警、下发配置节点可以分别部署在不同网段贴近真实业务的位置。蜜罐类型覆盖常见服务包括 MySQL、Redis、SSH、Telnet、HTTP、FTP 这类攻击者高频试探的协议管理员在 Web 界面里勾选启用就行。它对机器要求不高一台低配的闲置机器就能当管理端节点则更轻。告警可以接到钉钉、企业微信、邮件或任意 Webhook适合不想自己造轮子的团队。HFish 的最大价值是可视化谁在扫描、扫了哪些端口、尝试登录了哪个账号界面上一目了然。如果你是第一次搭蜜罐我建议从 HFish 起步它把“蜜罐部署”三个字变成了一个 Web 界面和几条命令。2.3 CowrieSSH/Telnet 命令记录器适合爆破与入侵行为分析Cowrie 是中交互蜜罐里的老兵专门针对 SSH 和 Telnet。它会和攻击者维持一个假的 shell攻击者输入的每条命令、下载的每个文件、修改过的每个文件内容都会被记录。数据以 JSON 格式落盘方便用 jq 或者写脚本二次分析。Cowrie 适合放在一个对外可达的地址上观察真实世界的暴力破解和入侵手法。攻击者以为自己在操控一台 Linux 机器实际上是在一个精心布置的沙箱里。它的局限也很明显高级攻击者敲几条命令就能识别出这是假环境所以它不是用来“骗过所有人”而是用来收集那些自动化爆破和脚本化入侵的行为样本。2.4 T-Pot多蜜罐聚合平台适合安全研究与演练T-Pot 不是一个蜜罐而是一组蜜罐加上一套分析平台。它用 Docker 编排了 Cowrie、Dionaea、Suricata 等十几个组件再把所有日志汇入 Elasticsearch用 Kibana 做可视化。装好之后你看到的不再是“某个端口被扫了”这种碎片信息而是整个攻击时间线。代价是重需要足够的内存和磁盘小机器硬跑会在启动阶段直接 OOM 翻车。T-Pot 适合安全研究、攻防演练、靶场建设这类场景不适合只有一台 2G 内存小云主机的人。数据沉淀完整ELK 的检索能力也能让你把几个月的攻击记录拉出来做对比分析。方案交互度资源占用数据形式适合场景HFish低交互为主低Web 界面 数据库业务内网布点、告警联动Cowrie中交互低JSON 日志SSH/Telnet 爆破行为分析T-Pot混合高ELK 全文检索安全研究、攻防演练3. 动手部署HFish 容器化、Cowrie 挂端口、T-Pot 聚合台3.1 HFish 容器部署docker-compose 拉起管理端和节点HFish 官方提供了 Docker 镜像最常见的做法是直接用 docker-compose 拉起一个管理端。先建目录、写编排文件mkdir -p /opt/hfish cd /opt/hfishversion: 3 services: hfish: image: threatbook/hfish:latest container_name: hfish restart: always volumes: - ./data:/usr/share/hfish ports: - 4433:4433 - 4434:4434执行启动命令docker compose up -d docker ps这段编排文件里4433是管理台 Web 端口4434是节点与管理端的通信端口两个都要映射出去否则节点连不上管理端。./data挂载到容器内数据目录保证容器删了重建后配置和日志还在。restart: always让蜜罐在宿主机重启后自动拉起省得半夜告警通知你“蜜罐掉了”。启动后浏览器访问http://服务器IP:4433/web/按引导初始化管理员账号。接着在管理台的“节点管理”里添加节点页面会生成一条安装命令通常是curl管道或一段 shell 脚本在目标机器上执行后节点就注册进来了。节点可以放在不同网段这样扫描行为才能真正贴近你的业务区域。这里提醒一句管理台是蜜罐的核心不要把它暴露到公网。我在生产环境里一般只让内网 IP 访问 44334434 也只对已授权的节点网段开放。蜜罐是用来收集攻击的不是用来给攻击者送管理后台的。3.2 Cowrie 容器部署把 SSH 诱饵挂在 2222 端口Cowrie 有官方容器镜像部署命令很轻mkdir -p /opt/cowrie docker run -d \ --name cowrie \ --restart always \ -p 2222:2222 \ -v /opt/cowrie:/cowrie \ -e TZAsia/Shanghai \ cowrie/cowrie:latest注意这里我把整个/opt/cowrie挂到了容器的/cowrie目录日志、配置都持久化在宿主机上。2222:2222是蜜罐映射端口外部连的是 2222不是真实 SSH 的 22避免和业务端口冲突。TZAsia/Shanghai是为了让日志时间跟本地时间一致默认 UTC 会让事件时间差 8 小时排查时非常别扭。启动后先改配置。进入容器docker exec -it cowrie vi etc/cowrie.cfg重点调整这几处[ssh] listen_endpoints tcp:2222:interface0.0.0.0 [honeypot] hostname web01 contents_path etc/contentslisten_endpoints指定监听端口和地址默认挂在 2222 就行。hostname改成你业务里真实主机名比如web01、db01之类越像真的越好。contents_path是攻击者登录后看到的文件系统内容模板改得越贴近业务攻击者越不容易快速察觉。验证蜜罐是否工作用另一个终端连它ssh root127.0.0.1 -p 2222随便输个密码登录成功后输入id、cat /etc/passwd。然后回去看日志docker exec cowrie tail -50 var/log/cowrie/cowrie.log.json日志里会出现类似这样的记录{eventid: cowrie.login.success, src_ip: 127.0.0.1, username: root, timestamp: ...} {eventid: cowrie.command.input, src_ip: 127.0.0.1, input: id}用 jq 可以把爆破成功后的命令全部捞出来jq -r select(.eventidcowrie.command.input) | [.src_ip, .timestamp, .input] | tsv /opt/cowrie/var/log/cowrie/cowrie.log.json | tail -100这条命令选了cowrie.command.input事件输出来源 IP、时间和命令内容按 tab 分隔。一次爆破进来的攻击者在这台机器上敲过什么全在这里。3.3 T-Pot 部署安装脚本、组件裁剪与 Kibana 数据入口T-Pot 有两种常见装法。一种是直接下载官方 ISO 装到独立虚拟机适合没有现成 Linux 环境的人另一种是在已有的 Ubuntu 机器上跑安装脚本适合想快速在现有资源上落地的人。第二种也是我更常用的方式git clone https://github.com/telekom-security/tpotce cd tpotce/iso/installer sudo ./install.sh --typeuser sudo reboot--typeuser是交互式安装模式安装过程中会提示你设置管理账号和网络参数。装完重启之后T-Pot 会自动拉起整套 Docker 组件。登录入口默认是https://服务器IP:64297SSH 管理端口是 64295。这两个端口如果不对去官方仓库看当前版本的说明不同大版本之间有过调整。T-Pot 默认启动的组件很多不是每个场景都用得上。编辑主配置sudo vi /opt/tpot/etc/tpot.yml这里定义了一整套 compose 服务不想要的直接注释掉然后重载cd /opt/tpot sudo docker compose up -d查看当前在跑的蜜罐组件docker ps --format table {{.Names}}\t{{.Status}}做完这一步攻击数据就开始流入 Elasticsearch。打开 Kibana 界面默认会有预置的 dashboard按协议、来源 IP、目标端口聚合的攻击事件都能直接看。T-Pot 的重心不在“搭建”而在“看数据”你应该花时间在 dashboard 和检索语法上而不是反复调部署。4. 蜜罐部署与使用中的常见问题现象、原因、解决4.1 蜜罐被扫描器一眼认出来现象蜜罐上线当天就收到大量针对默认端口的访问有些扫描器甚至直接标记“此 IP 为蜜罐”。原因默认端口和 banner 指纹太明显。HFish 管理台默认 4433Cowrie 默认 2222T-Pot 默认 64297这些端口在扫描器指纹库里几乎是公开的秘密。再加上 Cowrie 的 SSH banner 和真机有差异扫描器连接后对比指纹就能识别。解决给蜜罐换端口越不像蜜罐越好。HFish 在管理台配置里改监听端口Cowrie 在cowrie.cfg里把listen_endpoints改成类似tcp:10022这种高位端口T-Pot 修改 Nginx 反向代理的监听端口。同时把真实业务常用的主机名、系统版本、SSH banner 都伪装上让蜜罐看起来像一台普通业务机。我自己的习惯是伪装成一台跑着老版本 CentOS 的 Web 服务器攻击者渗透到一半才发现环境不对那时候命令已经全被记下来了。4.2 容器时间不同步告警时间对不上现象告警时间比真实时间慢 8 个小时多个蜜罐之间的事件时间线错乱同一个攻击行为在不同蜜罐上显示的先后顺序是反的。原因Docker 容器默认使用 UTC 时区而国内服务器一般用 Asia/Shanghai。宿主机时间是对的容器内日志和告警却差了整整 8 小时。管理端和节点如果用的时区设置不一致时间线混乱会直接影响攻击链还原。解决容器启动时加上-e TZAsia/Shanghai同时在 compose 文件里挂载宿主机时区文件volumes: - /etc/localtime:/etc/localtime:ro宿主机本身也要做 NTP 同步用 chrony 或 systemd-timesyncd 都行。HFish 节点和管理端之间对时间更敏感节点注册之后如果两端时间差太大告警聚合会按错误时间戳计算加完 TZ 后最好用date在两端各看一眼再确认。4.3 蜜罐没有流量日志一直是空的现象部署完成后等了几天蜜罐日志里连一条扫描记录都没有。检查服务状态正常端口也开着但就是什么也等不到。原因流量根本没进来。最常见的三个环节云安全组没放行蜜罐端口、系统防火墙默认 DROP、Docker 端口映射和宿主 iptables 规则冲突。很多人在云控制台只开了 22 端口蜜罐的 4433、2222 全部被挡在外面。解决按链路逐层排查。先在本机回环测试nc -vz 127.0.0.1 2222本机通再从外部机器扫一下nmap -p 2222 蜜罐IP本机通而外部不通去查安全组和系统防火墙sudo ufw allow 2222/tcp sudo firewall-cmd --permanent --add-port2222/tcp sudo firewall-cmd --reload还要注意 Docker 的 iptables 规则和宿主防火墙同时生效时流量可能被 Docker 自建链先接管顺序不对就丢了。判断方法是看宿主机iptables -L -n里有没有 docker 链有的话把蜜罐端口在 docker 链里放行。这条链路排查完九成以上的“蜜罐没日志”都能解决。4.4 磁盘被日志写满现象Cowrie 的日志目录几个小时后暴涨到几个 GT-Pot 的 Elasticsearch 索引占满磁盘docker compose 连镜像都拉不动。原因蜜罐上线后的前一周是扫描噪音最大的时期自动化爆破脚本会以每分钟几十次的速度尝试登录每条尝试都会写一行 JSON。T-Pot 更夸张ELK 的数据膨胀速度远超预期。解决给日志加轮转。Cowrie 的日志目录在宿主机上用系统的 logrotate 最简单/opt/cowrie/var/log/cowrie/cowrie.log.json { daily rotate 7 compress size 100M }daily按天轮转size 100M表示超过 100M 也会触发轮转compress压缩旧日志rotate 7只保留最近 7 份。T-Pot 则在配置里减少保留周期我把 Elasticsearch 的索引保留时间从默认改到 30 天够用了。顺便提一句如果蜜罐面向公网日志量会远超内网部署前给日志目录单独分区别跟系统盘放一起这是血泪经验。4.5 蜜罐被当成跳板现象蜜罐所在的机器上出现到内网其他主机的连接或者容器里出现可疑进程。原因Cowrie 这种模拟 shell 不会执行攻击者的命令攻击者拿不到真实 shell。但 T-Pot 的部分组件运行在真实容器里某些蜜罐服务为了模拟真实业务会开放更多执行能力一旦攻击者找到真实漏洞容器就可能被突破。蜜罐被用来中转扫描、发起横向移动是防守人最不希望看到的局面。解决网络层面做隔离而不是指望蜜罐程序本身。蜜罐机器的防火墙只放行蜜罐端口入方向出方向全部拒绝iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -A OUTPUT -j DROP这三条规则放行既有连接的回包和 DNS 查询其余出站流量全部丢掉。蜜罐只能接收攻击不能发起连接。做这一步之前先确认蜜罐不需要对外下载更新否则先把要放行的目的地址加上。同时把蜜罐放到独立网段跟业务子网隔离不让它有横向到业务主机的路。5. 进阶验证蜜罐是不是在“假装干活”的两种自测法蜜罐没有告警最怕的不是攻击者没来而是蜜罐自己挂了流量没进来。所以我每次部署完不会只盯着界面看而是主动打自己两下确认数据链路从头到尾是通的。第一种自测法模拟一次爆破和命令执行。用 Python 的 paramiko 写一个 10 行脚本连 Cowrie 并执行命令import paramiko client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) try: client.connect(127.0.0.1, port2222, usernameroot, passwordtest123, timeout5, allow_agentFalse, look_for_keysFalse) print(client.exec_command(cat /etc/passwd)[1].read().decode()) except Exception as e: print(连接失败:, e) finally: client.close()allow_agentFalse和look_for_keysFalse是必须的否则本机的 SSH 密钥会被带到蜜罐里把真实凭证泄露给攻击者的模拟器。执行完去查cowrie.log.json看有没有新增的cowrie.login.success和cowrie.command.input记录。时间和来源 IP 都能对上就证明蜜罐在工作。第二种自测法验证告警推送链路。HFish 的告警通道如果是 Webhook发一条测试告警看微信或钉钉是否收到curl -s -X POST $WEBHOOK_URL \ -H Content-Type: application/json \ -d {msgtype:text,text:{content:蜜罐自测告警}}这里把$WEBHOOK_URL换成你自己通道的地址。告警从蜜罐到聊天工具链路越短越好别在中间再套一层消息队列或者自研平台真到排查的时候你会被这层黑匣子折腾疯。我自己的习惯是每隔一周看一次蜜罐日志里新出现的命令顺便翻一下告警记录有没有哑火。如果一周下来一个陌生 IP 都没有我的第一反应不是“安全了”而是蜜罐可能已经掉了或者流量被防火墙挡了。蜜罐这东西最大的技术含量不在部署在后面日复一日地确认它真的在干活。希望帮到你。本文还有配套的精品资源点击获取