从Pentbox到Cowrie：三种蜜罐部署实战指南

简介三种蜜罐的搭建与使用围绕防护与诱捕这一安全主题面向安全测试入门者、网络运维人员以及高校相关专业学生。文档借助Defnet、Pentbox、Cowrie三种工具系统演示Windows与Kali Linux环境下的蜜罐部署涵盖端口开启与监听、虚拟Web/FTPSMTP/POP3/Telnet服务配置、用户名口令设定、日志保存与蜂鸣报警同时讲解Cowrie在Linux中创建非root用户、安装Python相关包、建立虚拟环境、修改SSH监听端口等完整流程。资源为单个docx文档大小7.96MB步骤配有命令行、界面与效果说明可直接对照复现。文档还展示了模拟访问被拒、telnet连接记录、蜜罐检测到入侵尝试等典型结果便于理解蜜罐工作机制。通过阅读可获得三种蜜罐的选型对比与常见踩坑点提升实际排错能力。已有3082人浏览学习适合需要快速上手蜜罐技术、开展内网安全实验或构建威胁诱捕环境的学习者。1. 蜜罐网络攻击者的“假系统”与你的第一手数据来源手里压着几台公网服务器或搭建了实验室环境的从业者大概率见过这样的场景日志里每天几十次 SSH 暴破尝试IP 来自各个国家用户名从 root 到 admin 挨个试。你拦得住一部分但拦不住攻击者留下的痕迹——他们到底传了什么文件、执行了哪些命令、用了什么字典。蜜罐Honeypot就是为回答这些问题而生的你故意放一个“假系统”在网络里让攻击者以为攻破了目标实际上他的一举一动都被录下来。本文要拆的这份资源覆盖了三种典型蜜罐Pentbox 的轻量监听、Defnet 的图形化多协议模拟、以及 Cowrie 的 SSH 全记录。它们按交互程度递进分别适合临场取证、教学演示和长期收集攻击情报。往下读我会把每一步操作和踩过的坑都写清楚照着做就能在 Kali 和 Windows 上跑起来。2. Pentbox一条命令起一个监听型蜜罐先分清自动与手动配置2.1 Ruby 安全套件里的 Honeypot 模块它到底监听什么Pentbox 是一个用 Ruby 编写的安全套件它的核心卖点是把渗透测试里重复性高的小工具打包在一起蜜罐只是其中一个模块。和后面要讲的 Cowrie 不同Pentbox 不模拟任何真实协议它只做一件事在指定端口上开启监听当有连接请求进来时记录来源并弹告警。这意味着它的“诱敌”能力很弱一个自动化扫描器扫到 80 端口发现响应头不是正常 HTTP 服务立刻就会识别出异常。但它的价值恰恰在轻量——装 Ruby 就能跑不需要配置数据库不用调整内核参数适合你在应急排查时快速起一个端口观察是否有内网扫描行为。选择 Pentbox 的理由也很实在如果你只是想知道“当前网段里有没有人正在探测我”一个监听 80 端口的蜜罐就够了没必要上 Cowrie 那一整套依赖。Pentbox 的告警能直接显示在终端里配合日志文件可以在几分钟内判断出扫描频率和来源 IP 段。我一般会在拿到一台新 VPS 或装好 Kali 虚拟机后先跑一个 Pentbox 放在非标准端口上观察两小时心里大概有个底。2.2 下载到激活自动配置 80 端口的完整操作Pentbox 的下载和运行过程都很直接但有几个细节需要留意。第一它的下载地址在 SourceForge 上如果你的网络环境访问外网慢建议提前准备好 tar.gz 包第二解压后要注意文件权限部分环境下载下来的脚本可能没有执行权限需要 chmod 补一下。下面是完整流程# 下载 pentbox-1.8 源码包地址是 SourceForge 的 latest/download 跳转 rootkali:~# wget https://sourceforge.net/projects/pentbox18realised/files/latest/download/pentbox-1.8.tar.gz # 解压到当前目录 rootkali:~# tar -zxvf pentbox-1.8.tar.gz # 进入目录并查看文件结构 rootkali:~# cd pentbox-1.8/ rootkali:~/pentbox-1.8# ls # 通常会看到 pentbox.rb、README、modules 目录等 # 启动程序 rootkali:~/pentbox-1.8# ./pentbox.rb启动后会进入交互式菜单。主菜单里选2进入 Network Tools再选3进入 Honeypot这时会出现两个子选项1是快速自动配置2是手动配置。按1回车Pentbox 会直接监听本机 80 端口并在终端打印一行HONEYPOT ACTIVATED ON PORT 80。这里解释一下参数含义快速自动配置没有给你任何自定义空间端口固定为 80错误信息使用默认值。80 端口之所以被选中是因为绝大多数 Web 扫描器会优先探测它命中率最高。但反过来也意味着如果你的本机已经有 Apache 或 Nginx 在跑监听会失败。碰到这种情况要么停掉现有服务要么改用后面的手动配置挑一个别的端口。启动成功后打开浏览器访问http://你的IP比如http://192.168.44.130。浏览器会显示一个 Access denied 的报错页面这是 Pentbox 伪造的默认响应而终端里会同步出现INTRUSION ATTEMPT DETECTED的告警。这一步很关键它验证了蜜罐确实在记录访问。我建议你顺手再用另一台虚拟机执行curl -I http://蜜罐IP观察 Pentbox 是否也把它当成一次入侵记录——你会发现蜜罐不区分善意访问和恶意扫描凡是连接都会留下记录。2.3 手动配置端口、错误信息、日志与蜂鸣的取舍自动配置只能解决“有没有人来看我”的问题手动配置则能让你控制“对方看到什么”。在主菜单里选2手动配置交互过程会依次询问四个问题Enter the port to listen: 23 Enter the banner to show: Welcome to Ubuntu 20.04 LTS Save log to file? [y/n]: y Log file name: pentbox.log Enable beep sound on intrusion? [y/n]: y第一个参数是端口号你可以填 21、22、23、443 等任何未被占用的端口第二个参数是错误信息也就是对方连接进来时看到的横幅第三是是否写日志文件第四是是否开启蜂鸣警告。填完后 Pentbox 会在指定端口开始监听并持续输出连接记录。我特别想强调错误信息这个参数的作用。攻击者用 nc 或 telnet 连上端口时第一眼看到的就是服务横幅。如果你的错误信息是Access denied稍微有经验的人就知道这是蜜罐但如果你模仿真实服务写一条220 Welcome to FTP server扫描器会把它当作真的 FTP 服务继续交互从而暴露更多攻击行为。实践中我会把一条最常见的服务横幅直接填进去比如 SSH 的SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.5这比默认值有用得多。验证手动配置的效果最直接的方式是用 telnet 或 nc 连接你设置的端口。比如你监听的是 23 端口就在另一台机器上执行telnet 192.168.44.130 23连接后你会看到自己设置的横幅同时 Pentbox 终端出现本次访问记录。同理监听 22、443 端口也能收获同样的效果。不过要提醒一句Pentbox 只做端口监听和记录它不会响应任何后续协议交互攻击者按下几个命令发现没反应就会离开。它适合收集“谁在扫我”不适合收集“扫我之后做了什么”——那是下一步 Cowrie 的活。3. DefnetWindows 图形化蜜罐把虚拟服务伪装成真实主机3.1 Defnet 的定位为什么图形界面更适合模拟多协议如果说 Pentbox 是靠一条命令起一个监听端口那 Defnet 就是完全不同的思路它运行在 Windows 上用图形界面让你勾选要虚拟的服务——Web、FTP、SMTP、Finger、POP3、Telnet——然后逐个配置细节。它的优势在于两点一是不需要记命令适合在培训或演示环境里临时搭一台“假服务器”二是它能模拟完整的协议握手攻击者用 telnet 客户端连上去会看到一个有模有样的登录界面而不是 Pentbox 那种只连一下就断开的裸端口。Defnet 的实际应用场景我见过最多的是内网教学和红蓝对抗演练。比如你要给新人演示“什么叫做攻击者的视角”就在物理机 Windows 上开一个 Defnet 的 Telnet 蜜罐让虚拟机里的 Kali 来连接观察 Defnet 记录了多少步操作。它记录的不只是连接时间还包括对方输入的用户名、密码、发出的命令这比单纯看端口连接记录有价值得多。当然受限于它是 Windows 程序部署位置通常是内网或实验室不太适合直接放到公网服务器上——毕竟 Windows 图形界面程序在无人值守环境里很容易因为休眠或锁屏中断监听。3.2 从虚拟 Telnet 到高级伪装一步一步建一个假服务器在物理机上打开 Defnet点击主界面的 “HoneyPot” 按钮进入设置对话框。左侧是服务类型列表勾选 Telnet Server右侧会出现登录配置框。这里可以随便设用户名和密码比如用户名填root密码填123456——蜜罐的精髓在于让攻击者“顺利”登录进来你设的密码越弱越容易钓出后续行为。注意这个登录其实是假的Defnet 在背后监听并记录每一次尝试无论对方填什么账号密码它都能放行。下面重点说右下角的 “Advanced” 高级设置这是 Defnet 和普通蜜罐拉开差距的地方。点开后你可以配置以下字段字段示例值作用DriveC:伪造的盘符让命令如C:\显得真实VolumeSYSTEM卷标对应 Windows 默认系统卷Directory creation time2023-08-15 10:22:33目录创建时间捏造一台“有历史”的主机Free space in bytes107374182400剩余磁盘空间单位是字节100GB 对应 107374182400MAC address00:0c:29:xx:xx:xx伪装网卡 MAC建议填虚拟机厂商前缀Network card typeIntel PRO/1000 MT网卡型号与 MAC 配合形成完整指纹这些参数的价值在于对抗“指纹识别”。攻击者如果只是 telnet 上来看到登录提示可能还会犹豫但如果他用 nmap 做一次服务识别扫描工具会抓取开放的端口、响应横幅、甚至是远程服务的系统指纹。你把 MAC 地址改成 VMware 默认前缀盘符和目录时间做成正常系统该有的样子扫描工具就会判定这是一台真实的 Windows 服务器而不是蜜罐。我在演练中见过攻击者因为蜜罐的Volume字段填的是乱码当场认出是伪造系统所以这个字段不是可填可不填的装饰而是决定蜜罐成败的关键之一。配置完成后回到初始对话框点击 “Monitore” 按钮开始监听。此时蜜罐已在后台监听对应服务端口界面上会滚动显示连接记录。注意Defnet 的监听是基于 Windows 服务的配置好之后不要关闭主窗口最小化即可。3.3 监听与验证物理机命令行连接蜜罐的全过程验证 Defnet 是否在工作需要一个和物理机在同一网段的客户端。我在实验环境里的网络拓扑是物理机 Windows 的 IP 是192.168.44.1虚拟机 Kali 的 IP 是192.168.44.132。先让物理机命令行执行ipconfig确认 IP再在 Kali 上执行ip addr确认地址在同一个网段内。接下来回到 Kali 上执行 telnet 连接命令# 在 Kali 虚拟机里连接物理机上的 Defnet 蜜罐 kalikali:~# telnet 192.168.44.1连接成功后Defnet 会给出一段伪装的 telnet 登录界面此时你输入之前设置的用户名root和密码123456。Defnet 的“Monitore”窗口会同步出现连接来源、登录尝试和密码内容整个过程和真实 telnet 服务器一模一样。连接超时或登录成功后Defnet 也都会记录下来。有一点值得注意这里的“登录成功”是 Defnet 伪造的假象攻击者输入任何账号密码都会被放行。你输入root/123456后看起来进入了 shell但随后你会发现自己敲入的命令没有真实执行——这正是蜜罐想要的状态让攻击者以为自己得手了实际上每敲一个命令都在给 Defnet 提供情报。验证时不要把假 shell 当成真终端来用否则容易造成“蜜罐被攻破”的误判。4. Cowrie中等交互 SSH 蜜罐把攻击者的命令和文件全留下来4.1 中等交互的含义为什么说它比 Pentbox 更懂攻击者Cowrie 是这三种蜜罐里技术含量最高的一个它属于“中等交互蜜罐”攻击者能够完成 SSH 连接、输入账号密码、执行命令、上传下载文件但这些操作全部运行在一个隔离的 Python 虚拟环境里任何命令的执行都会被记录恶意文件上传后无法真正落盘执行。它获取的东西很具体暴力破解用的字典、攻击者输入的每一条命令、上传或下载的文件内容。用 Pentbox 时我们只能知道“有人连了我”用 Defnet 时能知道“有人试了 root/123456”而用 Cowrie 时你能完整重建攻击者的操作时间线他先wget下载了一个脚本然后chmod x接着运行这一系列动作全部写在日志里。这对安全分析的意义是决定性的——你可以用这些数据反推攻击者的工具包来源、判断它是不是某个已知恶意家族的变种甚至提取出它的 C2 地址。Cowrie 官方默认推荐安装在 Linux 上Kali 环境完全兼容下面按照我实际搭建的顺序走一遍。4.2 从零搭建 Cowrie用户隔离、依赖安装与启动排错搭建 Cowrie 的第一步是创建一个非 root 用户来运行蜜罐。道理很简单蜜罐本质上是暴露给攻击者的即使 Cowrie 设计得再安全也不能用 root 跑它。我习惯用honey这个用户名# 创建系统用户 honey创建家目录指定 bash shell useradd -r -m -s /bin/bash honey # 设置密码实验中为了方便设为 123456 passwd honey第二行命令的-r表示系统用户-m强制创建家目录-s指定登录 shell。之所以要-m是因为 Cowrie 会尝试写入honey用户家目录下的文件夹没有家目录会直接报错。依赖安装是第一个分水岭Kali 的老版本源里包名比较老建议一次装齐# 安装 Cowrie 运行所需的 Python 相关包 apt-get install -y python-twisted python-crypto python-pyasn1 python-gmpy2 python-mysqldb python-zope.interface # 安装 virtualenv 虚拟环境工具 apt-get install -y virtualenv这两步完成之后下载 Cowrie 源码到/opt目录# 进入 /opt 目录并克隆 Cowrie 源码仓库 cd /opt git clone https://github.com/micheloosterhof/cowrie.git # 进入源码目录创建 Python 虚拟环境 cd /opt/cowrie virtualenv env # 激活虚拟环境 source env/bin/activate虚拟环境的好处是不污染系统的 Python 环境即使后面装坏了直接删掉env目录重建即可。接下来安装 Python 依赖这一步非常容易翻车# 在虚拟环境中安装 Cowrie 的 Python 依赖 pip install twisted cryptography pyopenssl gmpy2我在这条命令上报过错错误信息是gmpy2编译失败因为系统缺少 GNU 多精度运算库的开发头文件。解决方式很直接# 安装编译 gmpy2 所需的系统级依赖 apt-get install -y python-cffi libffi-dev libssl-dev apt-get install -y libgmp-dev libmpfr-dev libmpc-dev装完这三组系统库之后重新执行pip install twisted cryptography pyopenssl gmpy2依赖才能顺利通过。提醒一句不要试图跳过gmpy2Cowrie 的某些密钥交换算法依赖它少了这个库会在后面启动时或客户端连接时报错而且错误信息很难看懂。依赖装完把源码目录的所有权交给 honey 用户否则蜜罐运行时没法写日志# 将 /opt/cowrie 目录属主改为 honey chown -R honey:honey /opt/cowrie4.3 端口转发与真实服务剥离让攻击者走蜜罐、你走安全通道Cowrie 默认配置文件是cowrie.cfg.dist我们要复制一份出来再改。需要改动的有三个地方日志的 umask、蜜罐监听端口、以及系统真实 SSH 端口。# 复制配置模板 cp cowrie.cfg.dist cowrie.cfg # 修改 start.sh 里的 umask默认是 0077 vim start.sh # 将 -- umask 0077 改为 -- umask 0022umask 从 0077 改成 0022 的意义在于默认值下 Cowrie 生成的日志文件只有 honey 用户本人能读而安全分析人员通常用另一个账号登录服务器查看日志0022 让同组用户有读取权限避免每次查看日志都要先切换用户。然后是蜜罐的监听端口。编辑cowrie.cfg找到listen_port参数# 修改 cowrie.cfg 中的蜜罐监听端口 vim cowrie.cfg # 找到 listen_port 并改为 63333 listen_port 63333这里选一个大端口是故意的nmap 默认扫描常用端口列表只覆盖到 60000 以下的部分端口63333 这种端口能避开大量自动化扫描器的默认探测从而减少无关噪音让蜜罐记录到的都是定向攻击。下一步是将公网访问服务器 22 端口的请求转发到蜜罐端口。这一步的目的是让攻击者扫 22 端口时直接掉进蜜罐# 将访问本机 22 端口的 TCP 流量重定向到蜜罐的 63333 端口 iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 63333这里用到了 REDIRECT 而非 DNAT因为流量是到本机的REDIRECT 不需要重新指定目标 IP直接改目标端口即可。但如果这台机器是网关需要转发给内网另一台蜜罐就该换成 DNAT 加-i eth0之类的出口限制。做实验时用 REDIRECT 就足够。最关键的一步把系统真实的 SSH 端口挪走否则你转发 22 端口后自己也连不上服务器了# 编辑 sshd 配置把真实 SSH 端口改到 62225 vim /etc/ssh/sshd_config # 找到 #Port 22改成 Port 62225 # 重启 ssh 服务使配置生效 service ssh restart这一步的顺序非常重要必须先改真实 SSH 端口并确认能通过新端口登录再执行 iptables 转发。否则一旦 iptables 规则生效22 端口就被蜜罐接管你的管理会话会直接断掉需要去控制台操作。4.4 日志里能看到什么cowrie.log 与 cowrie.json 的字段对照启动 Cowrie 前先切换用户然后激活虚拟环境并启动# 切换为 honey 用户 su honey # 进入源码目录并启动蜜罐 cd /opt/cowrie bin/cowrie start第一次启动可能遇到缺少模块的报错我遇到的是configparser、service_identity、pycrypto、tftpy这些没装上。此时在虚拟环境里补装# 在虚拟环境中补装缺失的 Python 模块 pip install configparser service_identity pycrypto tftpy装好后重新执行bin/cowrie start看到类似Starting cowrie with PID xxxx的输出就说明启动成功了。此时用另一台机器做 SSH 连接测试连接的目标端口取决于你想验证哪条链路直接连 63333 验证蜜罐本身连接 22 端口验证 iptables 转发。我建议先连 22 端口因为这才是攻击者真实会走的路径。连接成功后查看日志# 查看 cowrie.log 中的连接日志 tail -f /opt/cowrie/log/cowrie.log # 查看 cowrie.json 中的结构化日志 tail -f /opt/cowrie/log/cowrie.jsoncowrie.log是可读的纯文本每行包含时间戳、连接来源、输入的命令等cowrie.json是结构化 JSON每条事件包含eventid、src_ip、username、password、input等字段。连上蜜罐后在客户端执行ping www.baidu.com日志里会记录你输入的这条命令但实际网络请求不会真的发出去——Cowrie 模拟了这个过程。同样是登录连接 Cowrie 和连接 Defnet 的本质区别在于Cowrie 会完整记录命令和文件Defnet 只能记录登录。5. 蜜罐搭建避坑记录端口冲突、权限问题、转发链路的五个坑5.1 Pentbox 提示 HONEYPOT ACTIVATED 但外部访问失败现象终端显示蜜罐已在 80 端口激活但另一台机器浏览器访问http://IP却一直超时。原因通常是虚拟机的网络模式问题Kali 虚拟机用的是 NAT 模式而不是桥接模式外部机器和它不在同一网段或者本机 80 端口已经被其他服务占用Pentbox 的监听实际失效了。解决先用ss -ltnp | grep 80确认端口监听情况。若端口被 Apache 占用停掉 Apache若网络不通把虚拟机网络切到桥接模式并保证 IP 在同一网段内。5.2 Defnet 的 Monitore 开启后telnet 提示拒绝连接现象在物理机 Windows 上打开 Defnet 并启动监听Kali 虚拟机 telnet 到物理机 IP 提示Connection refused。原因Windows 防火墙默认阻止了外部对 Telnet 端口的访问Defnet 监听的端口没有在防火墙入站规则中放行。解决在 Windows 防火墙高级设置中添加入站规则放行 Defnet 对应的 TCP 端口默认 23同时确认 Defnet 主窗口没有关闭最小化不等于关闭关闭主进程监听也会终止。配置完成后用netstat -ano | findstr :23确认端口确实在听。5.3 Cowrie 执行 pip install gmpy2 一直编译失败现象在 Cowrie 的虚拟环境中执行pip install gmpy2时报错提示缺少mpfr.h或gmp.h。原因gmpy2 需要链接 GMP、MPFR、MPC 这三个数学库的开发头文件Kali 默认没有装这些开发包pip 在编译时找不到头文件就放弃了。解决先执行apt-get install -y libgmp-dev libmpfr-dev libmpc-dev再重新执行pip install gmpy2。如果还报错检查是否缺少python-cffi和libffi-dev按这个顺序补装通常能一次性解决。5.4 Cowrie 启动成功但日志文件无法读取现象用 honey 用户启动 Cowrie 后切换回 root 或其他账号查看/opt/cowrie/log/cowrie.log提示权限不足。原因Cowrie 的start.sh里默认的umask 0077导致生成的日志文件权限为-rw-------只有 honey 用户可读。解决把start.sh中的-- umask 0077改成-- umask 0022然后重启 Cowrie。已生成的旧日志权限不会变可以用chmod 644 /opt/cowrie/log/*手动修正。5.5 配置 iptables 后自己 SSH 也掉进蜜罐现象按文档配好iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 63333后自己 ssh 连接服务器 22 端口进入的竟然是蜜罐的假 shell而不是真实系统。原因真实 SSH 服务的端口还没有从 22 改走sshd 仍然在监听 22和 iptables 转发规则同时存在或者你先配了 iptables再改 sshd_config导致规则先于服务生效。解决先编辑/etc/ssh/sshd_config把 Port 改到 62225重启 sshd确认能通过新端口登录然后再配置 iptables 转发。如果已经把自己锁外面了就只能通过云控制台 VNC 登录修复。6. 把蜜罐数据用起来日志分析、转发链路验证与上线自查清单蜜罐搭建完成只是起点真正有技术含量的是让数据为我所用。这里提三个我每次部署都会做的验证和排查动作它们能帮你确认蜜罐不是在“假工作”。第一验证端口转发链路是否真的生效。执行iptables -t nat -L PREROUTING --line-numbers查看规则确认 22 端口的 REDIRECT 正常然后用tcpdump -i any tcp port 63333监听蜜罐端口再在另一台机器上尝试连接 22 端口你会看到流量确实被转到了 63333。这一步能避免“蜜罐启动了但攻击者流量根本没进来”的尴尬。# 从 JSON 日志中提取攻击者使用的用户名和密码列表 cat /opt/cowrie/log/cowrie.json | jq -r select(.username ! null) | \(.src_ip):\(.username):\(.password) # 按来源 IP 统计暴力破解次数 cat /opt/cowrie/log/cowrie.json | jq -r .src_ip | sort | uniq -c | sort -rn第二用 jq 分析cowrie.json重建攻击者的攻击时间线。第一条命令能快速得到“哪个 IP 用了哪些密码”的字典第二条命令能统计扫描频率。这些数据可以直接进 SIEM 或生成威胁情报报告。要是没有 jq用 Python 脚本也能做同样的事但 jq 的实时管道处理明显更快。第三每次部署上线前强制走一遍自查清单检查项预期结果蜜罐监听端口ss -ltnp能看到监听端口iptables 规则iptables -t nat -L有 REDIRECT 记录真实 SSH 端口/etc/ssh/sshd_config中 Port 已改为 62225 且可登录日志权限cowrie.log权限为 644 或 664伪装信息Defnet 的 MAC、卷标、盘符已按真实系统风格配置防火墙Windows 防火墙已放行 Defnet 对应端口以前我部署 Cowrie 时觉得反正蜜罐有日志启动成功就够了结果一周后去看发现 iptables 规则没生效22 端口的流量全部打到了真实 sshd 上蜜罐白跑了一个星期。从那以后我每次部署蜜罐都强制自己走一遍 tcpdump 验证和一条模拟攻击命令确认日志里真的多了那条记录才收工。这个习惯帮我避开了很多“看起来在部署蜜罐实际上啥也没干”的陷阱希望帮到你。本文还有配套的精品资源点击获取