Pentbox、Defnet、Cowrie三种蜜罐部署分工与避坑实战

简介：面向网络安全初学者与渗透测试实验人员的蜜罐实践文档，围绕 Defnet、Pentbox 与 Cowrie 三种方案展开，重点解决在实验环境中快速搭建、配置并观察蜜罐捕获行为的问题。内容结合 Kali Linux 与 Windows 物理机场景，覆盖端口监听、虚拟 Telnet/Web/FTP 等服务、日志与告警查看、SSH 蜜罐安装及依赖排错等关键环节，帮助读者理解低交互与中等交互蜜罐的差异及适用边界。压缩包内为 1 个 docx 文件，约 7.96MB，便于集中阅读和按步骤复现实验。已有 3085 人学习，说明其在课程实验与入门演练中具有一定参考价值。读者可从中获得三套蜜罐的搭建思路、参数配置要点、攻击连接监测方法以及常见环境问题的处理线索，适合用于安全课程作业、实验报告整理和基础攻防演练前的环境准备。

1. 三种蜜罐跑完一轮，我把 Pentbox、Defnet、Cowrie 分了工

三种蜜罐的搭建与使用，我在实验环境里前后折腾了三轮，最后落到一个很朴素的结论：Pentbox 负责三分钟起一个能报警的 HTTP 假服务，看谁在敲门；Defnet 负责伪装一台像样的 Telnet 主机，专门等弱口令撞上来；Cowrie 才是能真正留下攻击者字典、命令序列和上传文件的那一台。honeypot 这个词听着玄，落地无非是把一个假服务摆到网络上，然后老老实实读日志。

这篇把 Pentbox、Defnet、Cowrie 三条路重走一遍，从下载解压、菜单路径、伪装参数，到依赖报错、端口重定向、日志字段，每一步说清为什么这么配、配错会怎样。刚接触蜜罐的能照着敲完；已经在做内网欺骗的熟手，重点看第四节端口对齐那几段和第五节的翻车现场，那里才是真正花时间的地方。

2. Pentbox：80 端口三分钟起一个会报警的低交互蜜罐

Pentbox 是一个用 Ruby 写的安全套件，面向 GNU/Linux，Windows、MacOS 以及任何装了 Ruby 的环境也能跑。它里面的 Honeypot 模块属于典型的低交互蜜罐：只监听端口、只回一个错误页面、只记一笔来源地址，没有什么可交互的 shell。也正因为简单，它特别适合放在实验环境的第一步，用来确认「我到底会不会看日志」这件事。

2.1 下载解压与菜单路径，别在第一屏就选错

整个安装过程没什么技术含量，真正的门槛在于菜单是纯文本交互，选错一层就得从头再来。我在 Kali 上的操作顺序是这样的：

# 进入工作目录，把 pentbox-1.8 拉下来 root@kali:~# wget https://sourceforge.net/projects/pentbox18realised/files/latest/download/pentbox-1.8.tar.gz # 解压并进入目录 root@kali:~# tar -zxvf pentbox-1.8.tar.gz root@kali:~# cd pentbox-1.8/ # 确认启动脚本在，然后运行 root@kali:~/pentbox-1.8# ls root@kali:~/pentbox-1.8# ./pentbox.rb

启动之后是一个带编号的主菜单。要去蜜罐，路径是主菜单选 2（Network Tools），进去之后再选 3（Honeypot）。这一步经常有人卡住，因为主菜单第一屏看起来像通用的信息收集工具集，很容易顺手选了 1 就去扫端口了。记住 2 → 3 这条路径，剩下的才是配置。

进到 Honeypot 之后会出现两个选项：一个是快速自动配置，选完直接在 80 端口起监听；另一个是手动配置，可以自己指定端口、错误提示语、是否保存日志、是否在检测到访问时蜂鸣报警。第一次跑建议先用快速配置把链路走通，确认浏览器能访问、终端能出告警，再去碰手动配置，不然连问题出在配置还是出在网络上都分不清。

2.2 快速配置与手动配置，差别不只是端口号

快速配置做的事情非常固定：监听 80，任何访问都返回一个 Access denied 的页面，同时在终端打印HONEYPOT ACTIVATED ON PORT 80，一旦有请求进来再补一行INTRUSION ATTEMPT DETECTED。它不给你选端口的机会，也不问你日志放哪。

手动配置才是 Pentbox 有用的地方，交互顺序是：先输入要开放的端口，再输入要显示的错误信息，然后问是否保存 log 以及 log 文件名，最后问是否开启蜂鸣警告，全部答完才开始监听。这几个参数我一般这么定：

有个细节值得提前说：手动配置选 22 端口时，本机如果已经跑着真的 sshd，Pentbox 是绑不上的，终端会直接报端口占用。这时候要么先把真的 sshd 停掉或挪到别的端口，要么干脆选 21、23 这种本机空着的端口。我吃过一次亏，配置完看着像启动了，其实监听根本没起来，访问自然什么反应都没有。

2.3 三个地方对照着验证，才算真的跑通

配置完不能只看终端有没有打印成功，要三处对照。第一处是浏览器，访问http://192.168.44.130（换成你自己那台机器的地址），应该看到 Access denied 的报错页面。第二处是终端，应该同时出现激活提示和入侵尝试提示。第三处是日志文件，打开看一眼有没有记下来源 IP 和时间。

想验证非 80 端口，用 telnet 最省事：

# 从另一台机器测试 23 端口，看蜜罐是否记录 telnet 192.168.44.130 23 # 测 22 端口 telnet 192.168.44.130 22 # 测 443 端口 telnet 192.168.44.130 443

每敲一次，Pentbox 终端都应该即时多一行告警。如果 telnet 卡在连接阶段，八成是端口没起、被防火墙挡了，或者本机别的服务占着这个端口。这里要建立一个习惯：低交互蜜罐的价值不在拦截，而在于「有人碰了这个不该被碰的端口」这件事本身，所以端口选得越像真实业务，记录越有信息量。

Pentbox 的短板也很明显：它只会记录连接，不会让攻击者真的「进来」，所以拿不到字典、拿不到命令、更拿不到样本。要这些，就得往中交互走。

3. Defnet：把 Telnet 蜜罐伪装成一台像样的 Windows 主机

Defnet 是图形化工具，跑在 Windows 上，思路和 Pentbox 不一样：它不是守一个端口回错误页，而是真的虚拟出若干个服务的登录界面，让攻击者以为自己连上了一台服务器。它能虚拟 Web、FTP、SMTP、Finger、POP3、Telnet 这几类服务，配置界面全在窗口里点，适合不想碰命令行的人上手。

3.1 虚拟服务开关与账号设定，先想清楚要钓什么

打开 Defnet，点 HoneyPot 按钮进入设置。第一步是勾选要虚拟的服务，我的建议是一次只开一个，别贪多。原因很简单：同时开六个服务，日志会混在一起，看不出攻击者的行为路径是先探 Web 还是先撞 Telnet。实验目的决定了配置方向，如果这次就是想看弱口令爆破，只开 Telnet 就够了。

Telnet Server 的账号密码可以自由设定。我通常设成root/123456这种一眼就能猜到的组合，因为蜜罐的目的不是挡住登录，而是让攻击者登进来之后多待一会儿，把后续动作都留在记录里。密码设得复杂，攻击者要么放弃要么耗在爆破上，反而拿不到有效信息。

账号设完之后别急着按监听，右下角还有一个 Advanced 按钮，那才是 Defnet 真正有意思的部分。很多人点开看一眼觉得是可选配置就跳过了，结果虚拟出来的主机破绽百出——攻击者敲两下dir发现盘符不对劲，立刻就知道是假的。

3.2 Advanced 里的伪装参数，决定这台假机器能撑多久

Advanced 的字段看起来琐碎，但每一个都在回答同一个问题：这台主机像不像真的。我一般这么填，思路是「贴合一个装了几年系统的老机器」：

填完之后回到第一个对话框，按 Monitore 开始监听。这时候蜜罐就开始在网络上「存在」了，接下来要做的就是从另一台机器去连它。

3.3 从 Monitore 记录还原一次完整登录

实验环境里的连接方式是这样的：蜜罐跑在192.168.44.1这台机器上，攻击方从另一台机器192.168.44.132发起。先在蜜罐这台用ipconfig确认地址，再去另一台查一下自己的地址，然后在对方的命令行里：

# 从 192.168.44.132 连向蜜罐主机 192.168.44.1 telnet 192.168.44.1

连上之后会看到登录提示，输入之前设的root/123456。这里有个容易被误解的现象：有时候敲完账号密码会显示连接超时，但紧接着又提示登录成功。这不是软件出错，而是蜜罐故意拖了一段响应时间，模拟真实服务器在慢网络下的表现，让整个交互看起来不那么「秒回」。判断标准很简单，看 Monitore 窗口里的记录是不是完整的：连接建立、账号输入、密码输入、登录结果，每一环都有时间戳。

Monitore 里记录的这几步，恰好就是一次攻击的完整链路。看日志的时候不要只盯着「有没有人登录成功」，更要看节奏：账号和密码之间隔了几秒、登录成功后待了多久、有没有立刻断开。秒进秒出的大概率是自动化扫描器，反复试不同账号的是爆破脚本，登进去之后停留超过一分钟的，才值得单独翻出来看看。

Defnet 的定位到这里就清楚了：它擅长伪装和人机交互层面的观察，但它是图形化工具、跑在 Windows 上、拿不到命令行级的上传下载行为。要抓命令序列和样本文件，得上 Cowrie。

4. Cowrie：中交互 SSH 蜜罐的依赖、端口与日志

Cowrie 是一个中等交互的 SSH 蜜罐，装在 Linux 上。它的价值在于三件事：抓到攻击者用来暴力破解的字典、记录他敲过的每一条命令、以及收下他上传或下载的恶意文件。比较安全的一点是，攻击者上传文件之后执行操作一般都会失败，所以对蜜罐主机本身来说风险可控。整个实验都在 Kali 上进行。

4.1 建普通用户与依赖安装，第一个坑就藏在这

用 root 跑蜜罐是自找麻烦，第一步先把运行账户建出来：

# 建一个不能登录系统 shell 的普通用户 honey，并设置密码 useradd -r -m -s /bin/bash honey passwd honey # 安装 Cowrie 依赖的 python 相关包 apt-get install -y python-twisted python-crypto python-pyasn1 \ python-gmpy2 python-mysqldb python-zope.interface # 安装虚拟环境工具 apt-get install virtualenv

-r表示建的是系统用户，-m会同时创建家目录，-s /bin/bash给了 shell，方便后面su honey切过去操作。密码在实验环境设简单点没关系，但主机绝对不能拿来做别的事。

接下来把源码拉下来并初始化虚拟环境：

# 拉取 cowrie 源码到 /opt 下 cd /opt git clone http://github.com/micheloosterhof/cowrie # 建虚拟环境并激活 cd /opt/cowrie virtualenv env source env/bin/activate # 在虚拟环境里装 python 依赖 pip install twisted cryptography pyopenssl gmpy2

pip install这一步大概率会报错，这是第一次跑 Cowrie 的人几乎绕不过去的坎。报错原因是编译 crypto 相关包时缺系统级的头文件，不是 pip 本身的问题，补上这些依赖再重跑同一条命令就行：

# 补上 ffi、ssl、gmp 的开发库，解决 pip 编译失败 apt-get install -y python-cffi libffi-dev libssl-dev apt-get install -y libgmp-dev libmpfr-dev libmpc-dev

看到Successfully installed一类的输出，虚拟环境才算配完。这里的关键判断依据是：pip 报错时先看报错里提到的是哪个 C 库名字，缺什么补什么，不要盲目apt-get upgrade，那只会把环境搞得更乱。

4.2 配置文件、umask 和监听端口

虚拟环境好了之后，先把目录归属改掉，再生成配置文件：

# 把 cowrie 目录交给 honey 用户 chown -R honey:honey /opt/cowrie # 从模板生成实际生效的配置文件 cp cowrie.cfg.dist cowrie.cfg

然后改start.sh里的 umask。默认是 0077，意味着新生成的文件只有属主能读，日志由 honey 用户写、你换个账户去读就读不到，排查问题时很容易误判成「日志没生成」。改成 0022：

# 编辑启动脚本，把 0077 改成 0022 cd /opt/cowrie vim start.sh # change "-- umask 0077" into "-- umask 0022"

接着改监听端口。默认是 2222，建议改到 60000 以上，避开扫描器默认扫的常用端口段：

# 修改蜜罐监听端口 cd /opt/cowrie vim cowrie.cfg # 把 listen_port 改成 62223

端口数字本身不重要，重要的是后面三处必须完全一致：cowrie.cfg里的listen_port、iptables 转发规则的--to-port、以及你实际 ssh 连接时用的-p。我见过笔记里写 63333、转发写 62223、连接写 2222，三处全不一样，结果就是蜜罐启动了却一个连接都收不到。

4.3 22 端口重定向，把攻击者引到蜜罐里

蜜罐监听在高位端口上是没用的，因为攻击者只会连 22。所以要做一个端口重定向，把打到 22 的流量转给蜜罐：

# 把访问本机 22 端口的 TCP 请求重定向到蜜罐的 62223 iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 62223

这条规则生效之后，任何连本机 22 的尝试都会落到 Cowrie 上。但你自己也得能连上这台机器，所以真实 sshd 必须挪走：

# 改真实 SSH 的监听端口，避免和重定向规则冲突 vim /etc/ssh/sshd_config # 将 Port 改为 62225 service ssh restart

操作顺序很关键，先改 sshd 端口并确认新端口能连上，再去加 iptables 规则。反过来做的后果是自己被锁在门外，只能去控制台救。这也是为什么我习惯留一个已经建立好的 SSH 会话不关，等新通道验证通过了再退。

4.4 切换 honey 用户启动，两份日志配合着读

用 root 配完之后，切到 honey 用户启动：

# 切到 honey 用户，用它的身份跑蜜罐 su honey cd /opt/cowrie bin/cowrie start

启动时还可能再报一次缺包，提示里点名的通常是configparser、service_identity、pycrypto、tftpy这几个，在虚拟环境里补装即可：

pip install configparser service_identity pycrypto tftpy

启动成功后，从另一台机器用 ssh 连过来验证：

# 连向蜜罐的高位端口，看是否拿到伪造的 banner ssh -p 62223 root@192.168.44.130

连上之后看到的是蜜罐给出的提示信息，不是你真实系统的 banner，这就对了。这时候 Cowrie 会同时写两份日志：cowrie.log是给人看的文本流，记录了连接、登录尝试、执行的命令；cowrie.json是结构化的，适合后续做统计和检索。具体路径以cowrie.cfg里的输出段为准，一般在log/cowrie/目录下。

有个细节能说明蜜罐「装得像」有多重要：在蜜罐里执行ping www.baidu.com，返回的信息是蜜罐伪造的，你从cowrie.log里能看到这次命令被完整记录下来。攻击者以为自己在探测外网通不通，实际上每一条命令都进了你的日志。

5. 避坑清单：五处最容易把蜜罐部署搞翻车的地方

这一节集中说翻车现场。蜜罐这类东西有个特点，配错了往往不报错，只是安静地什么都不记，等到复盘时才发现整段时间的日志是空的，那时候想补也补不回来。

5.1 现象：pip 装到一半报编译错误，重试多少次都一样

原因基本固定：cryptography 这类包需要编译 C 扩展，缺libffi-dev、libssl-dev就会在编译阶段失败。反复执行pip install没有意义，因为它每次都缺同一个头文件。

解决是按报错里出现的库名补齐系统依赖，再重跑同一条 pip 命令。我现在的做法是装完virtualenv之后先把python-cffi、libffi-dev、libssl-dev、libgmp-dev、libmpfr-dev、libmpc-dev一次性装好，省得中途被打断。

5.2 现象：蜜罐显示启动成功，但从外面连不上

原因有三种可能，得按顺序排。第一是listen_port和 iptables 的--to-port数字对不上，规则把流量转到了一个没人监听的端口。第二是真实 sshd 还占着 22，重定向没有生效。第三是防火墙在 nat 表之外又拦了一道。

解决是先在本机用ss -lntp确认蜜罐确实在监听那个端口，再iptables -t nat -L PREROUTING -n看规则里的目标端口，最后从另一台机器试连。三处数字对齐，问题基本就没了。

5.3 现象：日志文件存在，但内容一直是空的

原因是start.sh里的 umask 还是 0077，蜜罐以 honey 身份写文件，你以别的账户去读，看起来就像没写东西。也可能是目录归属没改，chown -R honey:honey /opt/cowrie这一步被跳过了，导致 honey 用户根本没有写权限。

解决是两步都做到位：umask 改成 0022，目录归属改给 honey。改完重启蜜罐，再触发一次连接看日志有没有新增。判断依据不要靠猜，直接看文件的时间戳有没有变。

5.4 现象：蜜罐跑了几天，一条记录都没有

原因通常不是配置错，而是位置错。蜜罐部署在实验网段里，而这个网段本来就没人扫；或者跑在一台 NAT 后面的机器上，外部流量根本到不了。也有一种情况是端口选得太偏，扫描器的字典里压根没有这个端口。

解决是先把蜜罐放到有真实扫描流量的位置，或者自己用另一台机器做一次定向探测验证链路。端口层面，SSH 蜜罐的经典做法是占用 22 这个入口，靠重定向把流量导到高位端口，而不是直接在 22 上监听。

5.5 现象：日志里的时间和实际情况对不上

原因是蜜罐主机时区和你的分析机器不一致，或者主机时间本身就没同步。这在复盘攻击时间线时是致命的，两个来源的日志差八小时，你怎么也对不齐。

解决是部署前先统一时区，把主机时间校准，再启动蜜罐。这个动作只需要一分钟，但省下的是后面几个小时的对照工作。我现在的习惯是蜜罐上线前先看一眼date，和攻击方机器对一下，差得多就先修时间。

6. 三种蜜罐怎么分工：一条能落地的观察链

把三种蜜罐放在一起看，它们解决的是不同层次的问题，不是互相替代的关系。Pentbox 是「有没有人碰」，Defnet 是「他长什么样、怎么登录的」，Cowrie 是「他进来之后干了什么」。真要搭一条完整的观察链，顺序应该是先低后中，先用 Pentbox 把高频端口的敲门声记下来，确认哪些端口在被持续关注；再用 Defnet 在 Telnet 上放一个足够像的假主机，收集账号密码和登录后的短交互；最后用 Cowrie 承接 SSH 方向的流量，拿到字典、命令序列和样本。

上线顺序我一般这么走：先在实验网段起 Pentbox 守 80，跑一天看有没有记录，这一步验证的是网络链路和日志链路都通。通了之后换成 Defnet 守 Telnet，把伪装参数填细，观察登录行为的节奏。最后上 Cowrie，重点不是启动成功，而是三处端口数字对齐、真实 sshd 挪位、两份日志都在增长。每一步都用「有没有新增记录」作为验收标准，而不是「终端有没有打印成功」。

最后一个具体技巧：Cowrie 的日志不要只看cowrie.log，cowrie.json才是做统计的地方。想知道攻击者最常敲的前十条命令，直接对 JSON 里的命令字段做聚合，比人工翻文本快得多；想找上传的样本，就筛文件传输相关的事件。文本日志用来还原上下文，结构化日志用来找规律，两者配合才不浪费这台蜜罐。

从那以后我每次部署蜜罐，上线前都强制走一遍「端口对齐、时间对齐、日志可写」这三项检查，一项不过就不往下走。这三种蜜罐我前后重装过六七次，真正浪费时间的从来不是安装，而是装完以为成了、结果什么都没记下来。希望这些踩过的坑能帮你少绕两圈。

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