ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

三种蜜罐搭建实战:Cowrie、Pentbox、Defnet 从零部署与避坑指南

三种蜜罐搭建实战:Cowrie、Pentbox、Defnet 从零部署与避坑指南 简介这是一份面向网络安全初学者与渗透测试爱好者的蜜罐实战资料围绕 Defnet、Pentbox、Cowrie 三种工具讲解在 Kali Linux 等环境下搭建与使用蜜罐的完整思路帮助读者理解如何用蜜罐发现、转移并记录非授权访问行为。资源包内共 1 个 docx 文档约 7.96MB以图文笔记形式组织涵盖 Pentbox 的下载解压、快速与手动配置监听端口、Defnet 虚拟 Telnet 服务及监视记录、Cowrie 的安装依赖、虚拟环境配置与 SSH 端口修改等关键环节并附有终端命令与操作截图说明。内容侧重实验过程与排错细节适合想动手复现蜜罐环境、积累攻防对抗经验的读者参考。目前已有 3082 人学习下载可作为蜜罐入门与实验记录的实用参考。1. 三种蜜罐的搭建与使用方法从零把 Cowrie、Pentbox、Defnet 跑起来很多人第一次接触蜜罐是被人忽悠着“装个假的 SSH 骗攻击者玩”结果装完发现日志全是乱码端口还被真扫挂了。我最早在 Kali Linux 上折腾蜜罐时也翻过车——Cowrie 装完连不上Pentbox 一开就报端口占用Defnet 干脆连文档都找不到。后来才明白蜜罐不是装完就完事它本质是一个“故意暴露的诱饵服务”你得先想清楚要抓什么行为再决定用哪种。这篇笔记就围绕三种常见蜜罐——CowrieSSH/Telnet 交互型、Pentbox轻量端口诱饵、DefnetWeb 应用型——把搭建、配置、验证和排错一次讲透。适合手里有台 Kali Linux 或 Ubuntu 测试机、想自己搭一套观察环境的安全爱好者也适合需要给内网做低成本告警的运维。下面所有操作我都实际跑过命令和参数直接抄就能用。2. 先搞清楚三种蜜罐分别抓什么选型比安装更重要2.1 Cowrie、Pentbox、Defnet 的能力边界对比蜜罐按交互深度分低交互、中交互、高交互。低交互只模拟端口响应抓不到攻击者输入的命令中交互能提供伪 shell记录完整会话高交互则把攻击者引到真实系统里风险高、维护重。这三种里Pentbox 属于低交互Cowrie 属于中交互Defnet 偏向 Web 层的中低交互。选错了你要么抓不到东西要么把自己搭进去。维度CowriePentboxDefnet模拟服务SSH / Telnet任意 TCP 端口HTTP / Web 表单交互深度中交互伪 shell低交互仅响应低到中页面级日志能力完整会话、命令、文件下载连接记录、简单告警请求记录、表单提交部署难度中依赖 Python 环境低单文件脚本中需 Web 容器适合场景抓暴力破解和命令执行快速铺端口诱饵抓 Web 扫描和注入尝试我一般这样选想观察攻击者拿到 shell 后干什么用 Cowrie只想在内网快速布几个假端口做告警用 Pentbox如果目标是 Web 应用比如有人扫你的后台用 Defnet。三者不冲突可以同时跑在不同端口上。2.2 环境准备Kali Linux 与 Ubuntu 的差异Kali Linux 自带大量安全工具但默认 Python 环境比较“脏”装 Cowrie 时容易和系统包冲突。Ubuntu 干净但需要自己补依赖。我的习惯是Cowrie 放在 Ubuntu 22.04 的独立虚拟环境里跑Pentbox 和 Defnet 放 Kali 上因为 Kali 的网络工具链更顺手。先统一做基础准备两台机器都执行# 更新源并安装基础依赖 sudo apt update sudo apt upgrade -y sudo apt install -y git python3 python3-pip python3-venv net-tools lsof # 确认当前监听端口避免后面冲突 sudo netstat -tlnp | grep -E 22|2222|80|8080net-tools提供netstatlsof用来查端口占用。这一步别省后面 Pentbox 报“Address already in use”基本都是这里没看清。Kali 用户注意如果你之前改过 SSH 端口先记下来Cowrie 默认要占 2222别和真 SSH 的 22 搞混。提示所有蜜罐都建议跑在隔离网络或测试机上不要直接暴露在办公网核心区。蜜罐被攻破本身不致命但它可能成为跳板。3. Cowrie 搭建把 SSH 诱饵做成能记录命令的伪 shell3.1 用虚拟环境安装 Cowrie 并初始化Cowrie 是 Python 写的官方推荐用 venv 隔离。下面这套流程我在 Ubuntu 22.04 上跑通多次Kali 也能用只是系统包名略有差异。# 1. 克隆源码放到用户目录下避免权限问题 cd ~ git clone https://github.com/cowrie/cowrie.git cd cowrie # 2. 创建虚拟环境并激活 python3 -m venv cowrie-env source cowrie-env/bin/activate # 3. 升级 pip 并安装依赖 pip install --upgrade pip pip install -r requirements.txt # 4. 复制配置文件模板 cp etc/cowrie.cfg.dist etc/cowrie.cfgrequirements.txt里包含 Twisted、cryptography 等核心库安装过程如果卡在cryptography编译先装sudo apt install -y build-essential libssl-dev libffi-dev python3-dev。虚拟环境的作用是防止 Cowrie 的依赖污染系统 Python这点在 Kali 上尤其重要因为 Kali 很多工具依赖特定版本的库。3.2 改三个必调参数端口、主机名、日志路径配置文件etc/cowrie.cfg里参数很多新手只需要盯住三个[honeypot] # 监听端口默认 2222避免和真 SSH 的 22 冲突 listen_endpoints tcp:2222:interface0.0.0.0 # 伪装的主机名攻击者登录后会看到这个 hostname svr04 # 日志目录默认在 cowrie/var/log/cowrie/ log_path var/log/cowrielisten_endpoints里的0.0.0.0表示监听所有网卡如果你只想本机测试改成127.0.0.1。hostname别用默认的svr04改成一个看起来像内网业务机器的名字比如web-prod-03这样攻击者更愿意多待一会儿。日志路径保持默认即可后面排查直接去var/log/cowrie/cowrie.log看。改完启动# 在 cowrie 目录下确保虚拟环境已激活 bin/cowrie start # 查看状态 bin/cowrie status # 确认端口监听 sudo netstat -tlnp | grep 2222如果status显示 not running先看var/log/cowrie/cowrie.log最后 20 行九成是端口被占或依赖没装全。3.3 验证 Cowrie 是否真的在记录攻击行为启动后别急着关自己模拟一次登录看日志有没有落盘# 另开一个终端用 ssh 连 Cowrie 的 2222 端口 ssh -p 2222 root127.0.0.1 # 随便输几次密码比如 123456、admin # 登录失败后去 Cowrie 日志里搜 grep -i login attempt ~/cowrie/var/log/cowrie/cowrie.log正常的话你会看到类似login attempt [root/123456] failed的记录。Cowrie 默认接受任意密码组合并进入伪 shell你在伪 shell 里敲ls、cat /etc/passwd它都会记录到var/log/cowrie/cowrie.log和var/lib/cowrie/tty/下的会话回放文件。tty目录里的文件可以用playlog工具回放命令是bin/playlog var/lib/cowrie/tty/xxxxx能看到攻击者逐字输入的过程这个功能在复盘时非常有用。注意Cowrie 的伪 shell 只模拟了有限命令攻击者如果上传真实恶意文件Cowrie 会把它存到var/lib/cowrie/downloads/但不会执行。别在宿主机上直接运行这些文件。4. Pentbox 搭建单文件脚本快速铺端口诱饵4.1 下载与运行 Pentbox 的最小命令Pentbox 是一个 Ruby 写的轻量蜜罐原项目比较老但胜在简单。Kali 上如果没 Ruby先装sudo apt install -y ruby然后下载 Pentbox 脚本。由于原仓库地址经常变动我一般直接从本机已有的工具目录找或者用git clone拉取常见镜像。假设你已经拿到pentbox.rb# 赋予执行权限 chmod x pentbox.rb # 以交互模式启动 ruby pentbox.rb启动后会看到菜单选2Network tools再选3Honeypot然后选1Fast auto configuration或2Manual configuration。快速模式会自动在常见端口上开诱饵手动模式可以指定端口和响应内容。我一般用手动模式因为快速模式开的端口太多日志反而难读。4.2 手动配置端口与告警参数手动配置时Pentbox 会依次问你端口号、是否记录日志、是否发送邮件告警。下面是一次典型交互Enter the port number: 8080 Do you want to save the log? (y/n): y Do you want to send an email alert? (y/n): n端口选 8080 是因为它常被扫描器盯上又不会和 Cowrie 的 2222 冲突。日志默认存在pentbox/logs/下文件名带日期。邮件告警功能依赖本机 sendmail测试环境一般关掉用日志加tail -f实时看就行。启动后验证# 另开终端用 nc 连一下 8080 nc -v 127.0.0.1 8080 # 随便发点数据 GET / HTTP/1.1Pentbox 会在终端打印连接信息同时写入日志。如果你看到Connection from 127.0.0.1就说明生效了。Pentbox 的局限是它只记录连接和原始数据不会解析 HTTP 请求所以更适合做“有人碰了端口”的告警而不是深度分析。4.3 让 Pentbox 在后台稳定运行Pentbox 默认前台运行关掉终端就断。用nohup或screen挂后台# 用 nohup 后台运行日志重定向到文件 nohup ruby pentbox.rb pentbox.out 21 # 查看是否在跑 ps aux | grep pentboxnohup配合是最简单的后台方案但交互式菜单没法用所以后台运行前先在配置文件里把参数写死或者用echo管道喂给脚本。更稳的做法是用screen -S pentbox开一个会话在里面跑然后CtrlA D剥离需要时screen -r pentbox回去看。Pentbox 长时间跑可能会因为 Ruby 版本问题内存缓慢增长建议每周重启一次或者用cron定时重启。5. Defnet 搭建Web 层蜜罐的部署与请求捕获5.1 Defnet 的获取与 Web 容器选择Defnet 不像 Cowrie 那样有活跃的官方仓库常见做法是把它作为一个 PHP 或 Python 的 Web 应用部署。我一般用 Python Flask 起一个最小 Web 服务来模拟 Defnet 的诱饵页面因为这样可控性最强。如果你手头有 Defnet 的源码包直接放进 Web 根目录即可如果没有用下面的 Flask 脚本可以复现它的核心行为——记录所有请求并返回一个假登录页。# defnet_honeypot.py from flask import Flask, request, render_template_string import logging from datetime import datetime app Flask(__name__) # 配置日志记录请求来源、路径、方法和表单数据 logging.basicConfig( filenamedefnet_access.log, levellogging.INFO, format%(asctime)s %(message)s ) # 一个看起来像后台登录的假页面 LOGIN_PAGE htmlbody h2Admin Login/h2 form methodpost action/login Username: input nameusernamebr Password: input namepassword typepasswordbr input typesubmit valueLogin /form /body/html app.route(/) def index(): return render_template_string(LOGIN_PAGE) app.route(/login, methods[POST]) def login(): # 记录攻击者提交的账号密码 username request.form.get(username, ) password request.form.get(password, ) ip request.remote_addr logging.info(fLOGIN_ATTEMPT ip{ip} user{username} pass{password}) # 永远返回登录失败诱导继续尝试 return Login failed, 401 if __name__ __main__: app.run(host0.0.0.0, port8080)这段代码的关键在logging.info那一行它把 IP、用户名、密码全部落盘。render_template_string直接渲染字符串省去模板文件。app.run的host0.0.0.0让外部可访问port8080和 Pentbox 错开。5.2 启动 Defnet 并验证请求捕获安装 Flask 后启动pip install flask python3 defnet_honeypot.py然后浏览器访问http://127.0.0.1:8080随便输个账号密码提交。去看defnet_access.logtail -f defnet_access.log你会看到类似LOGIN_ATTEMPT ip127.0.0.1 useradmin pass123456的记录。如果要把 Defnet 放到生产级 Web 容器里可以用 Nginx 反代加 uWSGI但测试阶段 Flask 自带服务器足够。注意 Flask 自带服务器不适合高并发如果扫描器疯狂请求可能会卡死这时候用gunicorn -w 4 defnet_honeypot:app起多进程。5.3 把 Defnet 日志接入告警光有日志不够得能第一时间知道有人碰了。最简单的做法是用tail -f配合grep关键字或者写个定时脚本检查日志增量# 每 60 秒检查一次新日志有 LOGIN_ATTEMPT 就打印 while true; do tail -n 5 defnet_access.log | grep LOGIN_ATTEMPT echo --- 发现新尝试 --- sleep 60 done这个脚本很糙但胜在不用装额外组件。生产环境可以换成 Filebeat 加 Elasticsearch或者直接让 Flask 在logging.info后调一个 webhook。我一般测试阶段就用上面的循环够用。6. 三种蜜罐的避坑与常见问题排查6.1 端口冲突导致蜜罐起不来现象Cowrie 启动后status显示 not runningPentbox 报Address already in useDefnet 的 Flask 直接抛OSError: [Errno 98]。原因2222、8080 这些端口被其他进程占了或者上一次蜜罐没退干净。解决用sudo lsof -i :2222和sudo lsof -i :8080查占用进程kill -9掉或者改配置文件换端口。改完记得同步改防火墙规则。6.2 Cowrie 伪 shell 里命令无响应现象SSH 连上 Cowrie 后输入ls没反应或者直接卡住。原因Cowrie 的伪 shell 依赖bin/cowrie里的 Python 环境如果虚拟环境没激活就启动或者cowrie.cfg里shell相关路径写错就会这样。解决确保启动前source cowrie-env/bin/activate然后bin/cowrie restart。还不行就看cowrie.log里的 traceback通常是某个 Python 包版本不兼容按报错降级或升级对应包。6.3 Pentbox 日志不记录或记录为空现象nc连上了 Pentbox终端有回显但pentbox/logs/下没有文件。原因Pentbox 的日志目录权限不对或者启动时选了不保存日志。解决手动创建日志目录并赋权mkdir -p pentbox/logs chmod 755 pentbox/logs重新跑一遍手动配置确认Do you want to save the log?选了y。6.4 Defnet 被扫描器打挂现象Flask 进程消失日志中断浏览器访问超时。原因Flask 自带服务器单线程遇到大量并发请求会阻塞甚至崩溃。解决换gunicorn或uwsgi起多 worker命令gunicorn -w 4 -b 0.0.0.0:8080 defnet_honeypot:app。同时在前端加 Nginx 限流比如limit_req_zone限制单 IP 请求频率。6.5 蜜罐日志暴露敏感信息现象日志里记录了攻击者提交的真实密码如果这些密码和内部系统重合可能造成泄露。原因蜜罐日志默认明文存储且可能被同步到公共日志平台。解决日志文件权限设为600只允许蜜罐运行用户读写定期清理旧日志不要把蜜罐日志和业务日志混在同一个索引里。如果只是做研究可以在记录前对密码字段做哈希但那样就失去了分析价值自己权衡。7. 进阶用蜜罐日志做行为画像与联动封禁三种蜜罐跑起来后真正的价值在日志分析。我习惯把 Cowrie 的cowrie.log、Pentbox 的连接记录、Defnet 的defnet_access.log汇总到一个目录然后用一个 Python 脚本做简单聚合。下面这个脚本统计每个 IP 的尝试次数和首次出现时间输出按次数排序的列表# analyze_honeypot.py import re from collections import defaultdict from datetime import datetime # 匹配 Cowrie 和 Defnet 日志里的 IP ip_pattern re.compile(r(\d\.\d\.\d\.\d)) stats defaultdict(lambda: {count: 0, first_seen: None}) def process_log(filepath): with open(filepath, r, errorsignore) as f: for line in f: match ip_pattern.search(line) if match: ip match.group(1) stats[ip][count] 1 if stats[ip][first_seen] is None: stats[ip][first_seen] datetime.now().strftime(%Y-%m-%d %H:%M) # 依次处理三种日志 for log in [cowrie.log, pentbox.log, defnet_access.log]: try: process_log(log) except FileNotFoundError: print(f跳过不存在的日志: {log}) # 按尝试次数降序输出 for ip, data in sorted(stats.items(), keylambda x: x[1][count], reverseTrue): print(f{ip:15} 尝试 {data[count]:4} 次 首次 {data[first_seen]})这个脚本的ip_pattern用正则抓 IPdefaultdict做计数first_seen记录首次出现时间。跑完你会看到哪些 IP 最活跃。如果某个 IP 在短时间内对多个蜜罐都有尝试基本可以判定是扫描器。接下来可以把这个 IP 喂给iptables做临时封禁# 封禁单个 IP 24 小时示例 sudo iptables -A INPUT -s 192.168.1.100 -j DROP但别急着自动封先人工确认因为 NAT 环境下可能误封整个出口 IP。我一般会观察三天把反复出现的 IP 加入黑名单同时记录到自己的威胁情报表里。验证蜜罐是否真正生效除了看日志还可以用tcpdump抓包对照sudo tcpdump -i any port 2222 -w cowrie.pcap抓一段时间后用 Wireshark 打开看是否有完整的 SSH 握手和交互数据。如果只有 SYN 没有后续说明蜜罐没响应回去查进程状态。最后说个我自己的习惯每次搭完蜜罐先自己攻击自己一遍把ssh、nc、curl都试一轮确认日志里能看到自己的操作再把它放到目标网络。这个“自测”步骤帮我省过很多次事后排查的麻烦。希望帮到你。本文还有配套的精品资源点击获取
返回列表