简介《三种蜜罐的搭建与使用方法》面向网络安全初学者、渗透测试学习者及实验教学人员围绕低成本部署与观察蜜罐展开帮助读者理解诱捕、监测和记录非授权访问的基本思路。资源包仅含 1 个 docx 文档压缩后约 7.96MB以图文笔记形式组织内容便于按工具章节查阅和复现实验。文档分别梳理 Defnet、Pentbox 与 Cowrie 三类蜜罐Defnet 部分涉及虚拟 Telnet、FTP、SMTP 等服务及监视记录Pentbox 部分结合 Kali 环境说明端口监听、日志保存与告警设置Cowrie 部分介绍中等交互 SSH 蜜罐的安装配置、攻击字典与命令捕获、恶意文件处置等要点。已有 3085 人学习适合作为课程实验、靶场练习和蜜罐入门选型的参考材料。1. 三种蜜罐摆在一起看从 80 端口的假页面到 63333 端口的假 shell把一台机器的 80 端口让出去让扫描器以为这里有东西听起来有点玄学其实三个工具就能覆盖「装样子」到「陪聊」的完整区间。Pentbox 是 Ruby 写的单文件套件一条命令就能在 80 端口立一块 Access denied 的牌子Defnet 是 Windows 上的图形化仿真器勾几个框就变出一台带盘符、卷标和 MAC 的假 Telnet 服务器Cowrie 则是中交互 SSH 蜜罐攻击者试的每个密码、敲的每条命令、传的每个文件都会落进日志。这三类蜜罐适合不同阶段想快速验证「我这个网段有没有人在扫」前两个足够想攒字典、看真人上来第一步干什么只能靠 Cowrie。下面按搭建顺序拆开参数怎么填、日志在哪看、哪一步最容易翻车都写进去。2. Pentbox 单文件蜜罐Ruby 脚本怎么在 80 和 23 端口上装样子2.1 为什么先拿 Pentbox 练手蜜罐按交互深度分低交互和中交互。低交互只做到传输层握手加一段伪造的应用层回应攻击者能连上、能看到 banner、能拿到一个错误页面但进不去任何真实服务中交互会给你一个假 shell让你敲命令、传文件全程被记录。Pentbox 属于典型低交互它的价值不在「骗得多深」而在「起得多快」。它的形态很讨巧整个套件是一堆 Ruby 脚本不编译、不装服务、不写系统配置解压完直接./pentbox.rb就跑起来CtrlC 就停机器上不留残留。对刚接手一台测试机、想先看看内网扫描流量的人来说这种「零部署成本」比功能多重要得多。反过来它的短板也很明确只能记录 TCP 连接事件和客户端发的第一批字节记录不到攻击者后续敲的命令也挡不住稍微懂行的人——连上 22 端口发现 SSH 版本协商对不上立刻就知道这是个假货。所以我的用法是把它当「探针」而不是「陷阱」在几台不重要的机器上各开一个端口一周看一次日志先搞清楚有没有人扫、扫的是哪些端口再决定要不要上 Cowrie 这种重家伙。Pentbox 面向 GNU/Linux 编写同时支持 Windows、MacOS 以及任何装了 Ruby 的系统这也是它跨平台好用的原因——同一份脚本拷到哪都能跑。2.2 环境准备与启动路径先确认 Ruby 在不在。Pentbox 1.8 是很老的脚本新系统上的 Ruby 3.x 有时会因为它用了已废弃的语法而报警告但基本功能还能跑如果直接报语法错装一个 compat 版本或者用容器里带的老 Ruby 更省事。# 确认 ruby 可用没有就先装 ruby --version || apt-get install -y ruby # 取发布包地址以你实际拿到的 pentbox-1.8 下载链接为准 wget -O pentbox-1.8.tar.gz pentbox-1.8 下载地址 # 解压并进入目录 tar -zxvf pentbox-1.8.tar.gz cd pentbox-1.8/ # 先看一眼目录确认 pentbox.rb 在 ls # 直接执行如果提示权限不足就 chmod x pentbox.rb 或者用 ruby pentbox.rb 调 ./pentbox.rb这段里唯一需要动脑的是最后一步。./pentbox.rb依赖文件本身有可执行位从 tar 包里解出来的脚本有时会丢这个位报Permission denied不是脚本坏了是权限问题chmod x就好用ruby pentbox.rb显式调用解释器则完全绕过这个问题我一般图省事就直接这么写。进入主菜单后路径是固定的先选2Network Tools再选3Honeypot。到这里会分叉出两个选项1是 Fast Auto Configuration2是 Manual Configuration。快速模式做的事非常有限——把监听端口钉死在 80直接开始 accept错误信息用内置的默认值。适合「我就想现在马上有个东西在听」的场景三十秒搞定验证完就 CtrlC。Manual 模式才是真正能用的那档它会把四个参数逐个问一遍。下面是这四项该怎么填。2.3 手动配置的四个参数提示项建议值说明开放端口21 / 23 / 80 / 443挑你所在网段最常被扫的端口别用 8080 这种半吊子错误信息Access denied / 404 Not Found浏览器直接显示这行字写得太离谱反而显眼是否保存 logy不落盘等于白干务必开log 文件名honey.log相对当前工作目录别写到 /tmp 这种会被清的地方蜂鸣报警n终端响铃只在本地会话有意义后台跑就是纯噪音端口这一项值得多说两句。伪装 Web 就用 80 或 443伪装 FTP 用 21伪装 Telnet 用 23这几个端口在扫描器眼里属于「高价值」连接量天然比 8000 之类的大。但要注意 Pentbox 在 22 端口上的效果是打折的SSH 客户端连接后会先做版本协商期待收到SSH-2.0-xxx这样的 banner而 Pentbox 只会回你配置的那句错误信息稍微懂一点的攻击者一眼就认出不是真 sshd。所以 22 端口适合「统计有多少人在扫 SSH」不适合「骗人深入」。错误信息那一项是纯社会工程学细节。默认的提示语偏「工具味」我一般改成和目标机器上真实服务一致的文案比如伪装 Web 就写403 Forbidden伪装 FTP 就写530 Login incorrect。这一步不改变任何技术行为但对自动化扫描器判断「这台是不是真机器」有影响属于低成本收益。日志文件名和蜂鸣这两项没什么可纠结的。蜂鸣在老式演示场景里很带感屏上一响就知道有人来了实际长期挂着的时候关掉否则半夜响一次你得爬起来看是不是真出事。2.4 验证三个入口对应三条记录配完之后终端会打出HONEYPOT ACTIVATED ON PORT 80这行字出现就说明 socket 已经 bind 成功并在 accept。接下来从另一台机器上制造三次访问每次回到 Pentbox 的终端看有没有对应的INTRUSION ATTEMPT DETECTED。# 第一次浏览器访问预期看到 Access denied curl -i http://192.168.44.130/ # 第二次打 80 端口的 TCP 握手不产生应用层数据 nc -vz 192.168.44.130 80 # 第三次换端口验证多实例比如伪装 telnet telnet 192.168.44.130 23这三条命令的差别在于触发层次。curl会走完 TCP 握手再发 HTTP 请求Pentbox 记录到的连接里带应用层内容nc -vz只做握手就断记录里就是一条空连接——这恰好说明低交互蜜罐记的是「事件」而不是「会话内容」。telnet那条更典型连上之后终端会卡住因为 Pentbox 不实现 Telnet 协议协商你得按Ctrl]再敲quit才能退出很多人第一次用以为程序挂了其实是在正常等你的输入。验证完端口就停在 80 和 23 上不动别急着加更多。低交互蜜罐开得越多误报越多——内网里正常的主机发现、资产扫描、打印机广播都可能打到这些端口上日志很快就变成一锅粥。我一般同时只挂两到三个端口跑一周统计出来的源 IP 分布比一堆杂乱记录有用得多。3. Defnet 的仿真面板把假 Telnet 服务伪装到驱动器盘符3.1 图形化蜜罐能做什么、不能做什么Defnet 走的是另一条路不做协议层伪造直接给你一个面板勾选要虚拟的服务填好账号密码和一堆系统属性然后点按钮开始监听。它的受众明显是教学和演示场景——没有命令行、没有依赖、没有配置文件所有参数都在对话框里适合在 Windows 上快速搭一个「看得见攻击者在干什么」的环境。它的能力边界比 Pentbox 稍微宽一点因为它能虚拟出 Web、FTP、SMTP、Finger、POP3、Telnet 六种服务并且对 Telnet 这种交互式协议能走完「输用户名 → 输密码 → 给个 shell 提示符」的完整流程。攻击者以为自己登进了一台 Windows 服务器实际上所有响应都是面板拼出来的。但它依然是低交互假 shell 里能看的目录、盘符、磁盘空间都是预先设好的静态值你敲cd进去也不会真的换目录。这种「静态仿真」在实战里的定位很清楚它拦不住老手但能完整记录新手和自动化工具的探测路径。很多人第一次拿到一个 shell 会先敲whoami、dir、ipconfig这三条命令的顺序本身就是有价值的情报——说明他用的什么工具、什么水平、下一步想干什么。3.2 虚拟服务与弱口令诱饵打开程序后点HoneyPot按钮进入设置对话框服务列表里按需勾选。这里有个常见误区以为勾得越多越好。实际上勾太多会让同一个 IP 上出现一堆不该同时存在的服务——一台机器开着 Web 又开着 Finger稍微像样点的扫描器都会标红。我一般只勾一到两个形成一个自洽的角色。账号密码这一栏是故意设弱的。原文里的示例用root/123456这个组合不是随意写的弱口令本身就是诱饵的一部分攻击者爆破成功后会产生「我进来了」的错觉接下来的操作才最有记录价值。如果你设一个 20 位的强密码爆破工具打不穿连都连不上等于什么都没录到。虚拟服务常见端口伪装建议Telnet23最推荐交互链完整能记录登录后操作FTP21适合记录匿名登录尝试和目录遍历Web80只回静态页记录请求路径最有价值SMTP25记录 EHLO 域名和发信尝试POP3110记录账号枚举行为Finger79老协议现在几乎只有扫描器会碰Telnet 那一栏填好用户名和密码之后别急着点确定右下角还有一个Advanced。这个按钮才是 Defnet 区别于普通端口监听的地方。3.3 Advanced 里的六个伪装项Advanced对话框里是一串用来「让假系统更真」的属性。这些字段攻击者登录后大概率会看填得敷衍就是自曝。参数作用填法建议Drive伪装驱动器盘符填C:和真实 Windows 一致Volume卷标填System或OS别用默认空白目录创建时间假目录的时间戳设成半年以前新建时间戳一眼假目录名假目录结构放几个像业务目录的名字别全是testFree space in bytes剩余磁盘空间填一个合理数值比如 32GB 上下MAC 地址 / 网卡类型硬件指纹MAC 用常见厂商前缀网卡选主流型号这张表里最容易被忽略的是时间戳和磁盘空间。攻击者登录后敲dir看到所有目录的创建时间都是今天立刻就知道这是刚搭的蜜罐看到剩余空间是 0 字节或者几个 TB同样起疑。MAC 地址也一样虚拟网卡默认的 MAC 前缀在公开的厂商库里查不到属于典型的「虚拟机指纹」。填完这些再回到主对话框点Monitore开始监听。这时候程序进入被动等待状态界面上会出现连接计数。3.4 监视器怎么读三段记录监听开起来之后从另一台机器发起连接。原文里的拓扑是物理机跑 Defnet192.168.44.1虚拟机里发起 telnet192.168.44.132。这个方向要注意Defnet 装在 Windows 上测试机可以是同网段的任意 Linux 或另一台 Windows。# 从测试机发起连接观察 Defnet 监视器是否有反应 telnet 192.168.44.1 23连接建立后监视器里会出现三段记录三段的含义完全不同混在一起看容易误判。第一段是「连接建立」只说明 TCP 握手成功什么都不能证明——扫描器的探测也会留下这一段。第二段是「输入用户名密码」这时候才有情报价值你能看到攻击者用的字典长什么样是admin/admin还是root/root。第三段分叉成两种一种是「连接超时」说明攻击者输完就挂在那里等多半是脚本跑完了没后续动作另一种是「登录成功」说明他拿到了假 shell接下来的每一条命令都会被记录下来。我习惯把这三段的时间戳记下来和同一时段的防火墙日志对一遍。有时候蜜罐上只有一条连接记录防火墙那边却有几十条被拒的包说明对方在批量扫端口蜜罐只是恰好命中了其中一个——这种情况下单看蜜罐日志会严重低估攻击面。4. Cowrie 中交互 SSH 蜜罐虚拟环境、端口改号与流量重定向4.1 它和前面两个不是一回事前两个工具记录的是「连接」Cowrie 记录的是「行为」。它是一个中交互 SSH 蜜罐攻击者用 SSH 客户端连上来会看到一个像模像样的登录提示爆破成功之后进入一个假 shell敲的每条命令、传的每个文件都被完整记下来。假 shell 里的命令是模拟执行的攻击者上传的恶意文件即使被chmod x再运行也不会真的生效所以对蜜罐主机本身相对安全。这个特性决定了它的用途拿暴力破解字典、看攻击者上来先跑什么侦察命令、收集他上传的木马样本。这些都是低交互蜜罐给不了的。代价是部署麻烦——要建独立用户、装一堆 Python 依赖、改 SSH 端口、配 iptables 转发每一步都有坑。维度PentboxDefnetCowrie交互深度低低中记录内容连接事件连接 登录动作命令、字典、文件部署成本一分钟十分钟半小时以上主要风险几乎无几乎无端口配错会锁死自己4.2 建独立用户与装依赖第一件事不是装软件是建一个专用低权限用户。蜜罐天生是「故意让人打」的服务用 root 跑等于把整台机器的命运交给一个假 shell 的漏洞。# 建一个不可登录系统账户之外的普通用户专门跑蜜罐 useradd -r -m -s /bin/bash honey passwd honey # 老版本 Cowrie 依赖的 python2 组件一次装齐 apt-get install -y python-twisted python-crypto python-pyasn1 \ python-gmpy2 python-mysqldb python-zope.interface # 虚拟环境工具 apt-get install -y virtualenv这里的-r是建系统账户-m强制创建家目录-s /bin/bash给它一个能用的 shell。三个参数缺一个都可能出问题不加-m的话家目录不存在后面 chown 会失败不给 shell 的话切过去执行脚本会报「此账户不可用」。依赖清单里那些python-开头的包是历史遗留。老版本 Cowrie 跑在 Python 2 上新一点的发行版已经把python-twisted这类包改名或者合并进别的包直接apt-get install会报「无法定位软件包」。遇到这个不要硬扛先确认你手上的 Cowrie 是哪个分支新版走pip install -r requirements.txt加 Python 3老版才需要这一串 apt 包。照抄老教程装不上八成就是版本对不上。4.3 虚拟环境与编译依赖报错代码拉下来之后不要直接pip install先建虚拟环境避免把系统 Python 搞乱——这台机器上可能还有别的服务在用 Python。cd /opt git clone cowrie 仓库地址 cowrie cd /opt/cowrie # 建虚拟环境并激活命令行前缀出现 (env) 才算成功 virtualenv env source env/bin/activate # 装运行时依赖 pip install twisted cryptography pyopenssl gmpy2第二条命令是报错重灾区。pip install跑到cryptography或cffi时挂掉报一堆ffi.h: No such file或者openssl/ssl.h: not found这不是 pip 的问题是系统缺 C 编译工具链和头文件。补三个包就好# cffi 和 cryptography 的编译依赖 apt-get install -y python-cffi libffi-dev libssl-dev # gmpy2 的数学库依赖 apt-get install -y libgmp-dev libmpfr-dev libmpc-dev三组包对应三类报错别混着装。libffi-dev解决的是cffi的头文件缺失libssl-dev解决的是cryptography找不到 OpenSSLlibgmp-dev这一组解决gmpy2编译时找不到大数运算库。装完重新执行上一条pip install通常会一次过。这条血泪经验适用于几乎所有需要编译的 Python 包不只是 Cowrie。4.4 目录归属、umask 与监听端口依赖装完接下来改三处配置每处都有明确的失败后果。# 目录归属交给 honey否则运行时写日志会 permission denied chown -R honey:honey /opt/cowrie # 从模板生成配置文件别直接改 .dist cp cowrie.cfg.dist cowrie.cfg # umask 从 0077 改成 0022否则日志只有 owner 能读采集脚本读不到 sed -i s/umask 0077/umask 0022/ start.sh # 核对改动是否生效 grep -n umask start.sh第一处是权限。Cowrie 启动时要在自己的目录下写日志、建临时文件如果目录属于 root 而进程是 honey 跑的启动瞬间就会因为写不了文件而退出日志里只有一行看不出所以然的错误。第二处是配置文件cowrie.cfg.dist是模板很多教程让你直接改它结果升级或者重装时被覆盖改过的参数全丢——正确做法是复制一份成cowrie.cfg程序优先读这个。第三处是 umask。这是最隐蔽的一个默认0077意味着新建的日志文件权限是600只有 honey 用户自己能读。如果你后面想用一个采集脚本或者日志转发进程去读这些文件会一直报权限不足而文件明明就在那里。改成0022之后新建文件是644别人能读不能写。已经生成的旧文件不会自动变得手动chmod一次。然后是监听端口。# 蜜罐的 SSH 监听端口选 60000 以上避开扫描器默认关注的低位端口 sed -i s/^listen_port.*/listen_port 63333/ cowrie.cfg # 复核别改错文件或者改错行 grep -n ^listen_port cowrie.cfg端口选高位是有讲究的。蜜罐自己的监听端口如果也用 22就会和真实的 sshd 抢 socket两者只能活一个就算真 sshd 改了端口把蜜罐挂在 22 上也容易被各种自动化工具的特殊探测打穿。选 60000 以上日常扫描基本不会碰日志干净很多。4.5 重定向与真 SSH 挪位三个数字必须自洽这一步是整套部署里最容易翻车的因为它涉及三个端口数字任何一个填错要么转发打空要么把自己锁在门外。# 22 端口进来的连接改投给蜜罐的 63333 iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 63333 # 真实 sshd 挪到 62222自己登录走这个端口 sed -i s/^Port 22/Port 62222/ /etc/ssh/sshd_config systemctl restart ssh # 复核监听状态确认 22 已经被腾出来 ss -tlnp | grep -E :(22|62222|63333)三个数字的关系必须满足--to-port等于cowrie.cfg里的listen_port真 sshd 的端口必须从 22 挪走且不等于前两者。第一个等式不成立转发目标没人监听连接直接被拒第二个条件不成立sshd 还占着 22iptables 的 REDIRECT 规则虽然生效但你自己 ssh 进来也会被送进蜜罐——更糟的情况是规则顺序问题导致本地回环都被重定向那就彻底失去远程访问。提示改 sshd 端口之前先确认手上还开着一个已经登录的会话或者有带外控制台可用。这是唯一的后悔药。改完用ss -tlnp复核是最省事的验证手段。理想输出里22 应该没有进程在监听或者只有一个 iptables 层面的转发不显示进程63333 是 honey 用户的进程62222 是 sshd。4.6 启动与首轮验证切换成 honey 用户启动别用 root。启动之后必须从另一台机器真实连一次否则你不知道它到底在不在工作。su honey cd /opt/cowrie bin/cowrie start # 缺依赖时按提示补常见的是这几个 pip install configparser service_identity pycrypto tftpy # 盯日志新连接进来会实时刷新 tail -f log/cowrie/cowrie.log启动阶段报缺包很常见因为虚拟环境里只装了核心依赖configparser、service_identity这些是启动到某个模块时才动态引用的。按报错逐个pip install即可不用一次装全。验证分两步。第一步从外部ssh -p 63333 honey蜜罐IP看到登录提示后随便输个错密码再去cowrie.log里找cowrie.login.failed事件能找到就说明链路通了。第二步故意登录成功用蜜罐里预设的弱口令进去敲whoami、ls、cat /etc/passwd然后在log/cowrie/cowrie.json里搜cowrie.command.input你敲的每一条都应该在。顺带一提假 shell 里ping一个外网地址看到的也是蜜罐侧伪造的输出别拿这个结果判断网络通不通。5. 三种蜜罐的避坑与排查端口占用、依赖报错和自锁风险5.1 连 22 端口进去看到的是自己的真 shell现象按教程配完 iptables 和 cowrie.cfg从另一台机器ssh到蜜罐的 22 端口输完密码直接进了真实系统whoami返回真实用户名日志里也没有任何记录。原因listen_port和 iptables 的--to-port不是同一个数或者真 sshd 的端口没改。原文里的示例在这处就埋了一个坑——转发写的是 62223配置里的监听端口却是 63333两个数字对不上REDIRECT 把流量送到了一个没人监听的端口实际连接要么被拒要么绕回真 sshd。解决先用ss -tlnp | grep -E :(22|62222|63333)把三个端口的实际监听状态打出来确认哪个进程占着哪个端口再回头对齐 iptables 规则、cowrie.cfg的listen_port、sshd_config的Port三处。改完iptables -t nat -L PREROUTING -n -v看一眼规则的包计数有增长才说明真的命中了。5.2 pip 装依赖报 ffi.h 或 ssl.h 找不到现象pip install cryptography编译到一半挂掉错误信息里出现fatal error: ffi.h: No such file or directory或openssl/ssl.h重试多少次都一样。原因这些包有 C 扩展pip 只负责下载源码编译要靠系统里的编译器和开发头文件。基础镜像为了瘦身通常不带-dev包所以永远编不过。解决按报错关键词补包——libffi-dev对应 ffi.hlibssl-dev对应 ssl.hlibgmp-dev libmpfr-dev libmpc-dev对应 gmpy2。装完不要急着重新pip install先pip cache purge清掉半成品缓存否则可能继续用坏掉的中间产物。5.3 蜜罐起来了但日志文件是空的现象bin/cowrie start显示成功进程也在ps能看到但log/cowrie/下没有新文件或者文件存在但一直是 0 字节。原因八成是目录归属问题。程序以 honey 用户运行但/opt/cowrie的所有者是 root写日志时被拒异常被吞掉了。另一种可能是 umask 还是 0077文件建出来了但权限是 600你用别的账户cat看不见内容误以为是空文件。解决ls -l log/cowrie/看文件权限和时间戳stat看 owner。归属不对就chown -R honey:honey /opt/cowrieumask 没改就回去改start.sh改完重启进程旧文件手动chmod 644一次。5.4 Defnet 监视器一片空白telnet 却显示连接成功现象从测试机telnet 192.168.44.1 23能连上也能看到登录提示但 Defnet 的 Monitore 窗口里一条记录都没有。原因两种可能。一是测试机和 Defnet 主机不在同一网段中间有设备做了地址转换蜜罐看到的源 IP 全是网关地址界面按会话聚合时看起来像没记录二是 Windows 防火墙放行了入站但没放行程序本身连接被系统层面接住了没进到应用层。解决先在蜜罐主机上netstat -an | findstr :23确认是 Defnet 的进程在监听不是系统服务。再临时关掉防火墙做一次对照测试确认是不是防火墙导致。跨网段的情况就老实把测试机挪到同一广播域别在 NAT 后面做蜜罐实验看到的源 IP 没有分析价值。5.5 蜜罐端口被别的服务先占了现象Pentbox 启动 80 端口时报 bind 失败或者 Cowrie 启动后立刻退出日志里只有一行Address already in use。原因系统上已经有 Web 服务、反向代理或者另一个蜜罐实例在监听同一端口。老系统里 Apache 和 nginx 默认就占 80容器环境里更常见。解决ss -tlnp | grep :80找到占用进程要么停掉它要么把蜜罐换个端口。这里有个原则不要为了跑蜜罐去停生产服务蜜罐的优先级永远低于真实业务。换端口之后再验证一遍触发链路别改了端口忘了同步 iptables 规则。6. 三份日志并排看一个二十行脚本和一条时间线习惯三种蜜罐的日志格式完全不通Pentbox 是纯文本行Defnet 是图形界面里的表格Cowrie 是每行一个 JSON。各看各的没问题一旦想把「同一个源 IP 在三个蜜罐上的行为」串起来手工翻就废了。我一般的做法是先统一成「时间、源 IP、事件、内容」四列再排序。# 把 cowrie 的 json 行日志压成四列方便和其他蜜罐的文本日志并排看 import json, sys for line in open(sys.argv[1], encodingutf-8, errorsignore): try: e json.loads(line) except ValueError: continue # 非 json 行直接跳过别让一行脏数据打断整批 eid e.get(eventid, ) # 只保留有分析价值的三类事件其余噪声连接建立、断开先扔掉 if eid in (cowrie.command.input, cowrie.login.success, cowrie.login.failed): print(e.get(timestamp, ), e.get(src_ip, ), eid.split(.)[-1], e.get(input, e.get(username, )))参数就一个sys.argv[1]指向cowrie.json。errorsignore是必须的攻击者上传的文件名里经常带非法字节不加这个参数整个脚本会在某一行崩掉。eid.split(.)[-1]把cowrie.command.input截成input输出窄一点终端里一行放得下。跑起来是这样python3 flatten.py log/cowrie/cowrie.json | sort -k1,1 cowrie.tsvsorted -k1,1按时间戳排这一步的意义在于 Cowrie 的 JSON 是追加写的多进程或者重定向场景下时间顺序可能是乱的。Pentbox 的honey.log和 Defnet 导出的记录用同样的四列手工对齐sort一遍三份文件并排打开同一个 IP 在哪几个蜜罐上出现过、先碰的哪个端口、有没有登录成功一眼就能看出来。这套流程里唯一需要养成的习惯是时间同步。三台机器如果时区或者 NTP 不一致日志对不上前面的功夫全白费。我吃过这个亏——蜜罐日志显示凌晨三点有人爆破防火墙日志里同一时段干干净净查了半天才发现是蜜罐主机时区设错了差了整整八小时。从那以后我每搭一台蜜罐第一件事是timedatectl确认时区和 NTP 同步状态第二件事才是改配置文件宁可多花两分钟也不想再对着一堆错位的时间戳排查。希望帮到你。本文还有配套的精品资源点击获取