蜜罐部署排障：Pentbox、Cowrie与Defnet端口日志实战

简介《三种蜜罐的搭建与使用方法》是一份面向网络安全初学者、渗透测试入门者及实验教学场景的实操型文档围绕 Defnet、Pentbox 与 Cowrie 三类蜜罐的部署和使用展开帮助读者理解低交互与中交互蜜罐在攻击诱捕、行为监测和日志记录中的差异。资源包仅含 1 个 docx 文件大小约 7.96MB内容以图文记录和配置说明为主便于在本地或 Kali 实验环境中对照阅读。文档覆盖 Pentbox 的端口监听与访问告警、Defnet 虚拟 Telnet 服务及连接过程监视、Cowrie 的 SSH 蜜罐安装配置与日志关注点并涉及虚拟服务伪装、监听端口选择、运行环境依赖处理等常见问题。已有 3085 人学习适合用于课程实验、安全练习和蜜罐方案选型参考也可作为搭建与排错时的查阅材料。1. 蜜罐挂上去三天零日志不是攻击者不来是你根本没收流量蜜罐这类东西最容易给人错觉——搭完盯着控制台空空如也第一反应是“没人攻击我”。实际上九成情况是端口没监听、转发没生效、日志没写权限。我见过最典型的一次某开发者把 Cowrie 的 listen_port 改成了 63333iptables 却还 REDIRECT 到 2222而真实 sshd 又被搬去了 62225外部打进 22 的流量全落进一个没人监听的洞里三天日志干干净净他还以为是实验室网段太干净。Pentbox 更直接Ruby 没装、脚本没加执行位菜单都进不去Defnet 图形界面点得飞快结果监听在了错误的网卡上攻击机连过去只会超时。这三套工具本身门槛都不高坑几乎全集中在“运行环境、端口对齐、文件权限”这三件事上下面按报错现场一个个拆。2. Pentbox 起不来Ruby 解释器、执行位与 80 端口占用Pentbox 是个用 Ruby 写的安全套件除了蜜罐还带一堆网络工具所以它不像编译型程序那样丢个二进制就能跑运行时依赖没配好你连主菜单都看不到。这一章按“跑不起来 → 跑起来不监听 → 监听了收不到”三段来拆基本覆盖了新手在这套工具上翻车的全部姿势。2.1./pentbox.rb: No such file or directory其实是解释器缺失第一次拿到 pentbox-1.8.tar.gz很多人的操作顺序是解压、cd进去、直接./pentbox.rb然后终端回一句bash: ./pentbox.rb: /usr/bin/env: bad interpreter: No such file or directory或者干脆No such file or directory。这句话极具误导性因为文件明明就在眼前。真实原因是脚本首行的 shebang 写的是#!/usr/bin/env ruby而当前系统里根本没有 ruby 这个可执行文件内核把“找不到解释器”报成了“找不到文件”。常见做法是先确认解释器和执行位再决定要不要换 Ruby 版本# 1. 确认 ruby 是否真的存在以及版本 which ruby || echo ruby 未安装 ruby -v 2/dev/null # 2. Debian / Kali 系安装 ruby 与解压工具 apt-get update apt-get install -y ruby tar # 3. 解压并定位真正的入口脚本 cd /opt tar -zxvf pentbox-1.8.tar.gz find . -maxdepth 3 -name pentbox.rb # 4. 补上执行位再运行 cd /opt/pentbox-1.8 ls -l pentbox.rb # 正常应带 x 位-rwxr-xr-x chmod x pentbox.rb ./pentbox.rbwhich ruby用来确认 PATH 里有没有解释器ruby -v顺带看版本find -name pentbox.rb是因为有些压缩包会多套一层同名目录直接cd容易进错地方chmod x补的是执行位缺了它终端会报Permission denied那是另一种错别和解释器缺失混在一起。如果 ruby 装完仍然报语法错比如syntax error, unexpected ...多半是发行版自带的 Ruby 3.x 和新版语法检查更严格而这个 1.8 版脚本年纪不小了。我一般的处理是装一个 2.x 的 Ruby 环境跑它或者干脆把 Pentbox 丢进一个独立的容器里别污染主机环境。2.2 菜单进得去选完快速配置却没监听80 端口被人占了进到主菜单之后路径是2Network Tools→3Honeypot→1Fast Auto Configuration这套快速模式会直接把监听端口定死成 80并且立刻开始等待连接。问题是 80 是个兵家必争之地Apache、Nginx、某些面板、甚至你之前跑挂没退出的 pentbox 进程都可能已经蹲在上面。这时候表现有两种一种是脚本直接抛Address already in use另一种更阴——脚本不报错但外部访问没有任何响应因为绑定失败了但错误被吞了。先确认端口占用情况再动手不要盲猜# 看 80/23/22 三个常用端口被谁占着 ss -lntp | grep -E :(80|23|22)\b # 老系统没有 ss 就用 netstat netstat -lntp | grep -E :(80|23|22)\b # 确认 pentbox 进程是否已经在后台跑着 ps -ef | grep -i pentbox | grep -v grep # 需要腾出 80 就先停掉常见的两个 Web 服务 systemctl stop apache2 2/dev/null systemctl stop nginx 2/dev/nullss -lntp里的-l只看监听态-n不做域名解析快-t限 TCP-p显示进程名和 PID一眼就能看出 80 是被 httpd 还是被 ruby 占着。ps -ef | grep是防止上一次 pentbox 没退出还挂着——它前台跑的时候看着像卡住很多人会开第二个终端再跑一遍两个进程抢同一个端口谁也别想监听成功。停服务这两条加了2/dev/null是因为机器上未必装了 apache2 或 nginx报“unit not found”不影响后续操作。如果你不想动主机上已有的 Web 服务就别用快速模式改走2Manual Configuration它会依次问你四件事监听端口、返回给访问者的错误提示、是否保存日志以及日志文件名、是否开启蜂鸣报警。这一步选择高位端口更稳妥# Manual Configuration 之后自检 ss -lntp | grep ruby # 期望看到类似LISTEN 0 128 0.0.0.0:8080 users:((ruby,pid...,fd...))注意0.0.0.0:8080这个绑定地址很关键。如果显示的是127.0.0.1:8080说明它只监听本地回环外部机器永远连不上这时候要在配置里改用0.0.0.0或者直接监听指定网卡地址。手动模式下还有一个高频误操作错误提示串里带了空格和特殊字符脚本处理参数时会被截断建议只写纯字母数字比如Access denied。2.3 浏览器访问不到 Access denied先分清是网络不通还是蜜罐没应答本地监听正常之后从另一台机器打开http://蜜罐IP理论上会看到一个Access denied页面同时运行 pentbox 的终端刷出HONEYPOT ACTIVATED ON PORT 80和INTRUSION ATTEMPT DETECTED两行。看不到这两行先别怀疑工具本身按“本机自测 → 同网段他机测试 → 抓包”三层往下压。# 第一层在蜜罐本机自测排除脚本本身问题 curl -v http://127.0.0.1:8080/ # 第二层从同网段另一台机器测试 curl -v http://192.168.44.130:8080/ # 第三层在蜜罐主机抓包看请求到底有没有进来 tcpdump -i any -nn port 8080 -c 20curl -v会打印完整握手过程如果本机能拿到响应、他机超时问题一定在网络层跟 pentbox 没关系——常见的是虚拟机网卡设成了 NAT攻击机在另一个网段或者主机防火墙把入站 8080 拦了。tcpdump -i any -nn port 8080里-i any抓所有网卡-nn不做主机名和端口解析-c 20抓二十个包就停避免刷屏。只要 tcpdump 里看不到 SYN 包就说明流量根本没到这台机器回头去查网段和防火墙不要在蜜罐配置上浪费下一小时。还有一个不那么明显的坑用https://去访问一个只讲 HTTP 的蜜罐浏览器会先尝试 TLS 握手pentbox 收到一堆二进制直接当垃圾丢掉页面上什么也没有但终端里其实已经记录了入侵尝试。看到“终端有记录、浏览器没页面”这种组合先确认地址栏协议。3. Cowrie 装不上、起不动pip 编译中断与缺失模块Cowrie 是目前用得最多的中等交互 SSH 蜜罐它能把攻击者暴力破解用的字典、敲进去的命令、上传下载的文件全部录下来而且攻击者上传的可执行文件在蜜罐里跑不起来对宿主机相对安全。但它对 Python 环境的挑剔程度也是三套里最高的装一遍下来能踩到四五种不同的报错。3.1Unable to locate package python-twistedPython 2 时代的老依赖照着老文档走第一条 apt 安装命令就会卡住apt-get install -y python-twisted python-crypto python-pyasn1 python-gmpy2 python-mysqldb python-zope.interface终端返回一串E: Unable to locate package。根因不是源配错了而是这套包全是 Python 2 时代的产物新版本系统已经默认只保留 Python 3对应的 python-xxx 包被整体移除你在源里翻多久都翻不出来。正确的做法是跳过系统包用 Python 3 的虚拟环境装依赖别和系统包管理器硬碰# 1. 建立专用低权限账号蜜罐绝不能拿 root 跑 useradd -r -m -s /bin/bash honey passwd honey # 交互输入密码 # 2. 装 Python3 基础工具链 apt-get install -y python3 python3-pip python3-venv git # 3. 拉取源码到 /opt 下 cd /opt git clone cowrie 仓库地址 cowrie cd /opt/cowrie # 4. 建虚拟环境并激活 python3 -m venv env source env/bin/activate python -V # 确认进的是 3.x 而不是系统 python # 5. 在虚拟环境里装运行时依赖 pip install --upgrade pip pip install twisted cryptography pyopenssl gmpy2 configparser service_identity pycryptodome tftpy这里几个选择值得说明useradd -r -m里的-r建的是系统账号-m保证有家目录-s /bin/bash是给它一个能登录的 shell因为后面要用su honey切过去启动服务用python3 -m venv而不是老的virtualenv是因为前者随 Python 自带少一个依赖少一个坑pycryptodome顶替老文档里的pycrypto后者在 Python 3.8 之后基本编译不过。激活虚拟环境之后所有 pip 操作都落在env/目录里系统 Python 一点不受影响这一点在蜜罐这种“装一堆冷门包”的场景下特别重要。3.2 pip 装到一半报ffi.h: No such file or directory缺的是开发头文件虚拟环境建好后执行pip install twisted cryptography pyopenssl gmpy2很容易在编译cffi或cryptography时中断报fatal error: ffi.h: No such file or directory或者openssl/opensslv.h: No such file or directory。这是 C 扩展在编译期找不到系统头文件pip 本身没问题缺的是发行版级别的开发包。# 补齐 C 扩展编译所需的头文件和链接库 apt-get install -y build-essential python3-dev apt-get install -y libffi-dev libssl-dev apt-get install -y libgmp-dev libmpfr-dev libmpc-dev # 装完回到虚拟环境重跑 source /opt/cowrie/env/bin/activate pip install twisted cryptography pyopenssl gmpy2build-essential提供 gcc 和 make没有它连编译都启动不了python3-dev提供Python.h是 Python C 扩展的入口libffi-dev对应ffi.hlibssl-dev对应 OpenSSL 头文件这两个是最常见的两个“编译中断点”libgmp-dev、libmpfr-dev、libmpc-dev是给gmpy2用的缺了它在大整数运算相关的编译上会挂。装完依赖还是失败的话看 pip 输出的最后二十行真正的原因就在那儿前面大段是编译日志噪音。我一般会加--no-cache-dir重试一次排除半成品缓存导致的诡异失败pip install --no-cache-dir twisted cryptography pyopenssl gmpy23.3 启动报ModuleNotFoundError少哪个补哪个别整套重装终于到了启动环节bin/cowrie start一执行日志里刷ModuleNotFoundError: No module named configparser或者 TLS 相关的service_identity缺失告警。这类错误信息非常明确缺什么装什么就行不需要推倒重来# 补装启动阶段报缺的模块 pip install configparser service_identity pycryptodome tftpy # 用 honey 身份启动避免生成 root 属主的文件 chown -R honey:honey /opt/cowrie su honey cd /opt/cowrie bin/cowrie start # 启动结果看日志不要只看终端 tail -f var/log/cowrie/cowrie.logconfigparser在 Python 3 里其实是标准库但老版本 Cowrie 的代码路径是import configparser的兼容写法某些分支下会去 site-packages 找同名包补一个能直接绕过去service_identity不装Twisted 在 TLS 校验时会抛警告甚至拒绝连接表面现象是“蜜罐起来了但 SSH 连不上”tftpy只在开 TFTP 服务时才用到不开可以跳过。chown -R honey:honey和su honey这两步的顺序千万别颠倒。如果先用 root 启动一遍再看日志日志目录和主机密钥文件都会变成 root 属主之后切回 honey 用户启动直接报权限拒绝而且报错信息里不一定提到权限很容易误判成配置问题。踩过一次之后我固定成“先改属主再切用户最后启动”的顺序。3.4 改端口把自己改断了listen_port、iptables、sshd 三处必须对齐为了让攻击者打到 22 端口的流量进蜜罐标准做法是改蜜罐监听端口、做本机端口重定向、把真实 sshd 挪走。这三步任何一步的数字对不上结果就是“蜜罐在跑但一个连接都收不到”。原文里就出现过转发目标端口和实际监听端口不一致的情况这类问题在真实环境里极其常见。# 1. 改蜜罐监听端口默认 2222用高位端口降低被扫描器直接发现的概率 cd /opt/cowrie vi cowrie.cfg # listen_port 63333 # 2. 修正日志 umask默认 0077 会让日志只有属主可读 vi start.sh # umask 0077 - umask 0022 # 3. 把外部打到 22 的流量重定向到蜜罐端口注意 to-port 要和 listen_port 一致 iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 63333 # 4. 真实 sshd 挪到另一个端口别和自己抢 22 vi /etc/ssh/sshd_config # Port 62225 systemctl restart ssh # 5. 核对三方端口是否自洽 ss -lntp | grep -E :(22|63333|62225)\bREDIRECT是 nat 表里的本机重定向目标--dport 22匹配进入本机 22 的连接--to-port 63333把它改写到蜜罐端口蜜罐只需监听本机任意地址即可收到。这里最容易犯的错是“转发目标写成 2222蜜罐监听改成 63333”两个数字各改各的谁也不知道对方变了。ss -lntp那一行是最后的保险22 上不该有 sshd 监听因为流量要走 NAT 跳转63333 上应该有 cowrie62225 上应该有 sshd。三者对不上就别往下测了。还有一条容易被忽略REDIRECT只对“进入本机”的流量生效从本机自己发起ssh -p 22 127.0.0.1走的是 OUTPUT 链压根不经过 PREROUTING。很多人拿本机自测发现转发“没生效”其实配置是对的必须从另一台机器发起才算数。4. Defnet 连上就断客户端、网段与伪装参数Defnet 是图形化的 Windows 蜜罐能虚拟出 Web、FTP、SMTP、Finger、POP3、Telnet 服务还提供一个 Advanced 面板专门调伪装细节让虚拟出来的系统看着更真。它的操作门槛看着最低——点几下鼠标就行——但正因为不涉及命令行出问题时反而没有日志可看只能靠外围手段定位。4.1telnet 不是内部或外部命令客户端本身就没装打开命令行敲telnet 192.168.44.1终端回一句telnet 不是内部或外部命令也不是可运行的程序。这不是蜜罐的问题是新版本 Windows 默认不安装 telnet 客户端。三条路可选我按推荐顺序给# 方案一用 PowerShell 自带的端口探测不需要额外装东西 Test-NetConnection -ComputerName 192.168.44.1 -Port 23 -InformationLevel Detailed # 方案二启用 Windows 内置 telnet 客户端需要管理员权限 dism /online /Enable-Feature /FeatureName:TelnetClient /NoRestart # 方案三直接用 PuTTY 或任意 SSH 客户端选 Telnet 协议Test-NetConnection的-Port 23会给出TcpTestSucceeded : True/False这是个比 telnet 更干净的连通性判断因为它不涉及协议协商只要 TCP 握手成功就算通。也就是说如果它返回 False问题在端口或网络返回 True 但 telnet 一登录就断问题在协议层或蜜罐的交互逻辑两者排查方向完全不同。dism那条是在线启用系统功能/NoRestart避免直接重启。4.2 连接超时而不是拒绝监听网卡选错、权限不足或防火墙拦截在 Defnet 里设好 Telnet 服务、填了用户名密码、点了 Monitore从虚拟机发起连接却一直卡在“正在连接”最后超时。超时和拒绝是两种完全不同的信号拒绝Connection refused说明包到了机器但没有进程监听超时说明包根本没到或者被中间设备丢了。先确认物理机上的监听状态和防火墙# Windows 侧查看 23 端口监听情况管理员权限的 PowerShell netstat -ano | findstr :23 # 临时放行入站 23 端口测试完记得删规则 netsh advfirewall firewall add rule namehoneypot-23 dirin actionallow protocolTCP localport23netstat -ano的-a列全部连接和监听-n数字形式-o带 PID拿到 PID 可以去任务管理器确认是不是 Defnet 本体如果压根看不到 23 的 LISTENING 行说明监听没起来最常见的原因是 Defnet 没以管理员身份运行绑定低于 1024 的端口被系统拒绝而图形界面往往只是弹一句提示就过去了。netsh advfirewall那条是临时开洞测试完记得delete rule namehoneypot-23删掉别留着一个长期敞开的入站规则。网段这一层也经常翻车。物理机跑蜜罐虚拟机当攻击机如果虚拟机网卡是 NAT 模式它能访问物理机的地址往往不是ipconfig里那个 192.168 开头的地址而是虚拟网卡所在的另一个网段。稳妥的做法是两边都改成桥接或者干脆在虚拟机里用ping先确认能通到蜜罐主机再谈 Telnet。4.3 Advanced 里的盘符和剩余空间随手填蜜罐一眼就假Defnet 的 Advanced 面板可以设伪装驱动器盘符、卷标、目录创建时间、剩余磁盘空间、MAC 地址、网卡类型。这些参数看着是锦上添花实际上决定了蜜罐能不能骗过稍有经验的对手。常见的敷衍填法盘符写C卷标写test剩余空间填0MAC 地址随手敲一串11:22:33:44:55:66。这样虚拟出来的系统自相矛盾——一个装着C:盘却剩余空间为零的 Windows一个 MAC 前缀不属于任何网卡厂商的设备一个目录创建时间是 1970 年的系统盘。攻击者敲两条命令就能判定这是蜜罐接下来的所有交互都是演给你看的假数据日志价值归零。参数设置上我一般遵守三条剩余空间填一个合理量级几十 GB不要是整数、目录创建时间早于当前时间但不要跨年代、MAC 地址前三字节用真实网卡厂商前缀。网卡类型和盘符要和宣称的操作系统版本自洽别在一个声称是老版本系统的蜜罐上挂着新型号虚拟网卡。4.4 Monitore 记录一片空白不是没记录是你没让它落盘设置完点 Monitore 开始监听攻击机连上来、输了用户名密码、甚至登录成功了回头一看记录窗口还是空的。Defnet 的监视窗口是实时刷新的如果连上之后马上断开有些版本会来不及渲染更常见的原因是监听启动顺序反了——先让攻击机连再点 Monitore中间那一段自然没被捕获。正确的操作顺序是设好 HoneyPot 参数 → 点 Monitore 进入监听态 → 再从攻击机发起连接 → 观察窗口里的连接、用户名、密码、超时、登录成功几个阶段的记录。原文里那次实验记录里完整出现了“输入用户名和密码 → 连接超时 → 登陆成功”的序列这说明监听确实在工作只是需要按时间顺序看。如果顺序对了还是空白回到 4.2 节用netstat确认 23 端口上到底有没有进程在听。图形化工具最大的问题是它不给你黑匣子出问题只能从外部一点点逼近。5. 蜜罐实验避坑记录五条把两小时拖成通宵的问题下面这五条是我在这三套工具上反复踩过的现象都很像“工具坏了”实际上全是配置或环境问题。每条按“现象 → 原因 → 解决”写遇到类似的直接对号入座。第一条日志文件全是 600 权限后面的分析脚本一个都读不到。现象是蜜罐跑了一整天日志确实生成了但换个用户或者用日志采集脚本去读直接Permission denied而ls -l看文件是-rw-------。原因是 Cowrie 的start.sh里默认umask 0077进程创建的所有文件都剥掉了组和其他人的读写位。解决是把start.sh里的umask 0077改成umask 0022再重启改完记得确认新生成的日志权限是-rw-r--r--已经生成的老日志不会自动跟着变需要单独chmod一次。第二条iptables 转发配好了本机测试却怎么都不生效。现象是iptables -t nat -L PREROUTING里规则明明白白但从蜜罐主机自己ssh -p 22 127.0.0.1连过去进的还是真实 sshd不是蜜罐。原因是本机发起的连接走 OUTPUT 链不经过 PREROUTINGnat 重定向对它们无效。解决办法是从另一台机器发起测试或者临时加一条 OUTPUT 链的对应规则专门用于自测。这个坑最坑的地方在于它会让你误以为整套转发都是坏的然后去乱改本来正确的配置。第三条切换用户后蜜罐起不来日志里只有一行看不懂的密钥错误。现象是su honey之后执行bin/cowrie start进程秒退日志里是加载 host key 失败之类的信息看不出和权限有关。原因是之前用 root 跑过一次var/下的主机密钥和日志文件属主变成了 roothoney 用户没有写权限。解决是chown -R honey:honey /opt/cowrie把属主整体刷回来然后固定“先改属主、再切用户、最后启动”的顺序别用 root 试跑。第四条蜜罐日志里全是自己的扫描流量真实攻击被淹了。现象是日志量很大仔细一看源地址全是自己实验室的网段全是端口扫描和漏扫工具的探测。原因是搭建过程中为了验证效果顺手拿扫描器对着蜜罐扫了几轮这些记录和真实攻击混在一起。解决办法是搭建验证阶段用单独的测试网段或者在分析时按源地址先过滤掉已知的测试机更彻底的做法是蜜罐上线前重建一次日志目录把调试期数据清干净。第五条虚拟机重启后蜜罐“自己关了”规则和进程全没了。现象是昨天还好好的今天开机发现 22 端口又回到了真实 sshd蜜罐日志停止增长。原因是 iptables 的 nat 规则默认不持久化Cowrie 也不是系统服务重启即失效。解决是把规则落盘iptables-save 之后在启动时恢复把 Cowrie 注册成系统服务两者都做一遍再谈“长期观察”。这一步不做你的蜜罐永远只能活在当次开机的几个小时里。6. 快速定位从一条 tcpdump 开始的排查顺序三套工具、十几种报错真到了现场不可能一条条回忆。我现在固定按一条链路往下压从“包有没有到”开始倒推到“服务有没有起”基本五分钟内能定位到层。第一步永远是抓包它回答的是最底层的问题流量到底有没有到达这台机器。# 在蜜罐主机上抓目标端口先看有没有 SYN 进来 tcpdump -i any -nn -c 30 tcp and port 23 # 有 SYN 但没有 SYN-ACK说明本机没人监听或被防火墙丢包 # 有 SYN 也有 SYN-ACK说明服务在跑问题在协议层或应用层看完抓包结果按下面这张表对号入座比凭感觉乱改配置快得多抓包/端口现象最可能的层下一步动作完全抓不到 SYN网络层查网段、虚拟网卡模式、上游防火墙有 SYN回 RST传输层端口没监听查进程和绑定地址有 SYN无响应主机层本机防火墙 DROP查 iptables/firewalld握手成功随即断开应用层看蜜罐日志、协议协商、密钥或认证配置握手成功日志无记录文件层查日志目录权限和 umask第二步查监听用ss -lntp一次看全所有相关端口。Pentbox 看它选的那个端口上是不是 rubyCowrie 看listen_port上是不是 pythonDefnet 在 Windows 上用netstat -ano看 23 上是不是 Defnet 本体。绑定地址是0.0.0.0还是127.0.0.1这一栏比端口号更容易出事。第三步查日志落盘。Pentbox 的日志写在它运行目录下手动模式才会生成Cowrie 在var/log/cowrie/下同时有纯文本和 JSON 两份JSON 那份更适合后续做分析Defnet 只有界面里的监视窗口。日志目录的属主和权限每次都要顺手看一眼ls -l一秒钟的事能省掉半小时的“为什么没记录”。第四步才是回头看工具配置。这一步放到最后是因为前面三步能排除掉八成问题而配置改动是有副作用的——你改了一个自认为可疑的参数可能把本来正常的转发链路弄断然后又多出一个新故障。从那以后我每次搭蜜罐都强制走一遍“抓包 → 端口 → 日志 → 配置”这个顺序不管多急都不跳步。跳过一次就是拿一个通宵去换十分钟的省事。这套顺序写在便签上贴在显示器边比记十几个具体命令管用得多。希望帮到你。本文还有配套的精品资源点击获取