简介这是一份面向网络安全初学者与渗透测试爱好者的蜜罐实战资料围绕 Defnet、Pentbox、Cowrie 三种主流蜜罐工具讲解从环境搭建到实际使用的完整流程其中 Pentbox 与 Cowrie 部分均在 Kali Linux 环境下完成适合想入门主动防御与攻击诱捕技术的读者。资源包内仅含 1 个 docx 文档约 7.96MB以图文步骤形式记录了各工具的命令操作与配置细节。内容覆盖 Pentbox 的下载解压、快速与手动配置蜜罐、端口监听及入侵告警验证Defnet 虚拟 Web、FTP、Telnet 等服务的伪装设置与监视记录以及 Cowrie 的依赖安装、虚拟环境配置、SSH 端口修改等关键环节并附有 telnet 连接测试与日志观察过程。目前已有 3082 人学习下载可帮助读者快速理解蜜罐原理、掌握三种工具的部署方法并积累攻击行为捕获与分析的排错经验。1. 三种蜜罐的搭建与使用方法从零跑通 Pentbox、Defnet 与 Cowrie手里只有一台云主机和 Kali Linux想看看每天到底有哪些人在扫我的端口最直接的办法就是架一个蜜罐。蜜罐这东西听起来玄学其实本质就是“故意露个破绽等人来踩”踩的人越多你拿到的攻击样本、扫描源 IP、常用字典就越真实。Pentbox 适合新手十分钟上手Defnet 偏向 Web 场景的交互欺骗Cowrie 则是 SSH/Telnet 领域最经典的交互式蜜罐能录下攻击者敲的每一条命令。这三者覆盖了端口探测、Web 诱捕、SSH 爆破三条最常见的攻击路径搭起来对硬件要求都不高一台 1 核 1G 的 Ubuntu 或 Kali 就能跑。下面按“先跑通、再调参、最后避坑”的顺序把三种蜜罐的搭建与使用方法拆开讲清楚新手能照着敲熟手能直接看参数边界。2. Pentbox 蜜罐十分钟跑通端口诱捕与告警Pentbox 是一个用 Ruby 写的轻量级安全工具里面自带一个 honeypot 模块能在指定端口上监听并记录连接来源。它的价值不在于多强大而在于“快”——装完 Ruby 环境几条命令就能让一个假服务上线特别适合临时在 VPS 上布一个观察点看看自己暴露在公网上的机器每天被扫多少次。2.1 为什么选 Pentbox 做第一层诱捕端口扫描是攻击链里最早、最廉价的一步攻击者用 masscan 或 nmap 几分钟就能扫完一个 C 段。Pentbox 的 honeypot 模块默认会监听一个端口任何 TCP 连接都会被记录下源 IP、时间戳和连接行为。它不模拟复杂协议所以不会跟攻击者产生深度交互但正因为简单它几乎不会因为环境依赖出问题跑起来就稳。对于刚接触蜜罐部署的人来说先用 Pentbox 建立“有人在扫我”的直观感受比一上来就啃 Cowrie 的配置要友好得多。选它还有一层现实考虑Pentbox 对系统侵入极小不需要 root 常驻不需要数据库日志就是纯文本。你可以在 Kali Linux 里跑也可以在 Ubuntu 上跑甚至在一台已经跑了业务的机器上临时开一个高位端口做观察不影响主服务。这种“低干扰”特性让它在做初步资产暴露面摸底时特别顺手。2.2 在 Kali Linux 上安装 Ruby 环境并拉取 PentboxPentbox 依赖 RubyKali Linux 默认可能没装完整 Ruby 环境先补齐。以下命令在 Kali 2023 以后的版本上验证过Ubuntu 22.04 同样适用。# 更新包索引并安装 Ruby 及必要依赖 sudo apt update sudo apt install -y ruby ruby-dev build-essential git # 确认 Ruby 版本Pentbox 对 Ruby 2.x 和 3.x 都能跑 ruby -v # 从 GitHub 克隆 Pentbox 源码到本地工具目录 cd /opt sudo git clone https://github.com/technicaldada/pentbox.git sudo chown -R $USER:$USER /opt/pentbox这里有几个参数和动作需要说明。ruby-dev和build-essential是为了保证后续如果有原生扩展能编译通过虽然 Pentbox 本身是纯 Ruby 脚本但装上不亏。克隆到/opt是 Linux 下放第三方工具的惯例避免和系统包混在一起。chown那一步是为了让当前用户有写权限否则后面改配置文件会一直要 sudo。装完之后进入目录看一眼结构核心文件是pentbox.rbhoneypot 逻辑在它内部通过菜单调用。不需要额外 gem 安装这也是它比很多现代蜜罐省事的地方。2.3 启动 honeypot 模块并配置监听端口Pentbox 是交互式菜单驱动的直接运行主脚本按菜单选 honeypot 即可。但如果你要在没有图形界面的 VPS 上跑或者想写成脚本自动启动可以用管道把选择喂进去。cd /opt/pentbox # 交互式启动适合第一次手动看菜单 ruby pentbox.rb # 菜单路径1) Network tools - 3) Honeypot - 1) Fast auto configuration # 或者手动指定端口选 2) Manual configuration然后输入端口号比如 8080手动配置时它会依次问你监听端口、是否记录到文件、是否显示告警。我一般会选一个高位端口比如 8080 或 2222避免和真实服务冲突。记录文件默认写在当前目录下名字类似honeypot.log。如果你想让它后台跑用nohup或screen包一层# 用 nohup 后台运行日志重定向到文件 nohup ruby pentbox.rb /var/log/pentbox_console.log 21 # 查看 honeypot 记录到的连接 tail -f /opt/pentbox/honeypot.log参数上唯一需要留意的是端口选择。不要用 22、80、443 这些已经被真实服务占用的端口否则 Pentbox 起不来会报Address already in use。如果你就是想观察针对 SSH 的扫描可以把 Pentbox 监听在 2222然后把真实 SSH 挪到别的端口或者干脆用 Cowrie 来做 SSH 蜜罐Pentbox 只做辅助观察。2.4 验证诱捕效果与日志字段解读启动后从另一台机器用nc或nmap连一下你设置的端口然后回来看日志。# 在另一台机器上测试连接 nc -v your_server_ip 8080 # 回到蜜罐机器查看日志 cat /opt/pentbox/honeypot.log日志里通常包含时间、源 IP、目标端口和连接状态。如果看到类似192.168.1.100 connected to port 8080的记录说明诱捕生效。Pentbox 的记录粒度不细不会存 payload但对于判断“谁在扫、扫得多频繁”已经够用。你可以配合awk做简单统计# 统计每个源 IP 的连接次数按次数降序 awk {print $NF} /opt/pentbox/honeypot.log | sort | uniq -c | sort -rn | head -20这个统计能让你快速看出哪些 IP 在批量扫描。如果某个 IP 在短时间内连了几十次不同端口基本可以判定是扫描器。Pentbox 的局限也在这里它只记录连接不记录攻击者后续发了什么。所以它适合做第一层“预警”真正要抓攻击载荷还得靠 Cowrie 或 Defnet。3. Defnet 蜜罐Web 交互欺骗的配置与诱捕逻辑Defnet 是一个偏 Web 场景的蜜罐框架它的思路和 Pentbox 不同——不是简单监听端口而是模拟一个看起来有漏洞的 Web 应用诱导攻击者进行目录扫描、参数注入、登录爆破等操作并把这些行为完整记录下来。如果你的资产里有 Web 服务或者你想研究攻击者针对 Web 的常见手法Defnet 比纯端口蜜罐更有观察价值。3.1 Defnet 的适用场景与部署前提Defnet 适合部署在公网 VPS 上模拟一个“看起来没打理好”的网站。它通常会内置一些常见的 Web 路径比如/admin、/wp-login.php、/phpmyadmin以及一些带参数的接口攻击者扫描到这些路径后会尝试默认口令、SQL 注入或文件包含。Defnet 把这些请求全部记下来包括请求方法、路径、参数、User-Agent 和源 IP。部署前提是你要有一个能跑 Web 服务的环境。Defnet 一般用 Python 或 PHP 写常见做法是跑在一个独立端口上比如 8000然后用 Nginx 反代或者直接暴露。我一般会把它放在一台没有其他业务的 VPS 上避免蜜罐被攻破后影响真实资产。系统层面Ubuntu 20.04 或 22.04 都行Kali Linux 也可以但 Kali 默认的 Web 环境比较杂建议用 Ubuntu 做宿主。3.2 在 Ubuntu 上部署 Defnet 并配置诱捕路径Defnet 的源码获取方式因版本而异常见做法是从项目仓库克隆后按 README 启动。这里给出一套通用的 Python 环境部署流程适用于大多数基于 Flask 或 Django 的 Defnet 变体。# 安装 Python3 虚拟环境和 pip sudo apt update sudo apt install -y python3 python3-pip python3-venv git nginx # 创建虚拟环境并激活 cd /opt sudo git clone https://github.com/defnet/defnet.git sudo chown -R $USER:$USER /opt/defnet cd /opt/defnet python3 -m venv venv source venv/bin/activate # 安装依赖具体依赖文件以项目实际为准 pip install -r requirements.txt如果项目没有requirements.txt通常需要手动装 Flask 或 Django。启动前要改配置文件一般是一个config.py或settings.py里面会定义监听端口、日志路径、模拟的路径列表。以下是一个典型的配置片段# config.py 示例定义蜜罐监听端口和诱捕路径 HONEYPOT_PORT 8000 LOG_FILE /var/log/defnet/access.log # 模拟的敏感路径攻击者扫描这些路径时会被记录 FAKE_PATHS [ /admin, /wp-login.php, /phpmyadmin, /.env, /config.php.bak ]参数说明HONEYPOT_PORT建议用 8000 或 8080避免和 Nginx 的 80 冲突。LOG_FILE要确保目录存在且当前用户可写否则启动会报权限错误。FAKE_PATHS列表可以根据你观察到的扫描趋势动态加比如最近很多扫描器在找/.git/config就把它加进去。启动方式一般是# 激活虚拟环境后启动 source venv/bin/activate python app.py # 或者用 gunicorn 后台跑 gunicorn -w 2 -b 0.0.0.0:8000 app:app --daemon3.3 用 Nginx 反代隐藏真实端口并记录原始请求直接暴露 Python 应用端口不够优雅也不方便做 TLS。常见做法是用 Nginx 反代把 80 或 443 的流量转到蜜罐端口同时让 Nginx 记录一份原始访问日志。# /etc/nginx/sites-available/defnet server { listen 80; server_name your_domain_or_ip; access_log /var/log/nginx/defnet_access.log; error_log /var/log/nginx/defnet_error.log; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }启用配置并重载 Nginxsudo ln -s /etc/nginx/sites-available/defnet /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx这样攻击者看到的是 80 端口的标准 Web 服务实际请求被转发到 Defnet。Nginx 的access_log会记录所有请求包括那些被 Defnet 返回 404 的路径这些 404 请求恰恰是扫描器留下的痕迹。你可以用grep快速筛出敏感路径的访问# 找出所有访问 /admin 的请求 grep /admin /var/log/nginx/defnet_access.log | awk {print $1, $7, $12} | sort | uniq -c | sort -rn3.4 分析 Defnet 捕获的 Web 攻击载荷Defnet 的价值在于它不只记录“谁来了”还记录“来了之后干了什么”。如果攻击者尝试在登录框输入 OR 11 --这个 payload 会出现在日志里。你可以写一个简单的 Python 脚本从日志里提取可疑参数# 从 Defnet 日志中提取包含 SQL 注入特征的请求 import re sql_patterns [ r(\%27)|(\)|(\-\-)|(\%23)|(#), r((\%3D)|())[^\n]*((\%27)|(\)|(\-\-)|(\%3B)|(;)), r\w*((\%27)|(\))((\%6F)|o|(\%4F))((\%72)|r|(\%52)) ] with open(/var/log/defnet/access.log, r) as f: for line in f: for pattern in sql_patterns: if re.search(pattern, line, re.IGNORECASE): print(line.strip()) break这段代码的逻辑是用正则匹配常见的 SQL 注入特征比如单引号、双横线注释、or关键字组合。参数上re.IGNORECASE保证大小写不敏感因为攻击者经常用Or或OR混写。跑出来的结果就是疑似注入尝试你可以进一步看源 IP 和 User-Agent判断是自动化工具还是人工。Defnet 的坑在于如果模拟的页面太假攻击者可能扫一眼就走了不会留下深度交互。所以配置FAKE_PATHS时最好模仿真实 CMS 的路径结构比如 WordPress 的/wp-login.php和/xmlrpc.php一起放这样扫描器会认为这是一个真实站点停留时间更长。4. Cowrie 蜜罐SSH/Telnet 交互式诱捕的完整搭建Cowrie 是 SSH 和 Telnet 蜜罐里最经典的一个它能模拟一个完整的 shell 环境攻击者爆破进来之后以为自己拿到了一个真实系统实际上每敲一个命令都被记录。Cowrie 会伪造文件系统、支持常见的 Linux 命令还能记录攻击者下载的恶意脚本。对于研究 SSH 爆破和僵尸网络传播的人来说Cowrie 几乎是必搭的。4.1 Cowrie 的交互式诱捕原理与部署选型Cowrie 的核心是一个 Python 写的 SSH 服务端它不执行真实命令而是根据内置的 fake filesystem 返回预设结果。攻击者ls看到的是假目录cat /etc/passwd看到的是假内容但 Cowrie 会把所有输入输出记下来。它支持两种模式一种是代理模式把攻击者转发到真实系统危险不推荐另一种是模拟模式完全在蜜罐内部闭环。部署选型上Cowrie 官方推荐用 Ubuntu 或 DebianKali Linux 也能跑但依赖冲突较多。我一般用 Ubuntu 22.04 的干净容器或 VPSPython 3.10 以上。Cowrie 需要非 root 用户运行监听 22 端口时需要authbind或端口转发因为普通用户不能绑定 1024 以下端口。常见做法是让 Cowrie 监听 2222然后用 iptables 把外部 22 转发到 2222。4.2 创建专用用户并安装 Cowrie 依赖Cowrie 不建议用 root 跑先建一个专用用户。# 创建 cowrie 用户不分配登录 shell sudo adduser --disabled-password --gecos cowrie # 安装系统依赖 sudo apt update sudo apt install -y git python3 python3-venv python3-pip libssl-dev libffi-dev build-essential authbind # 配置 authbind 允许 cowrie 用户绑定低端口 sudo touch /etc/authbind/byport/22 sudo chown cowrie:cowrie /etc/authbind/byport/22 sudo chmod 755 /etc/authbind/byport/22参数说明--disabled-password表示不设密码只用于跑服务。authbind是为了后面能让 Cowrie 直接监听 22如果你打算用 iptables 转发这一步可以跳过。libssl-dev和libffi-dev是编译 Twisted 等依赖需要的缺了会在pip install时报错。4.3 配置 Cowrie 监听端口与伪造文件系统切换到 cowrie 用户克隆源码并安装 Python 依赖。sudo su - cowrie git clone https://github.com/cowrie/cowrie.git cd cowrie python3 -m venv cowrie-env source cowrie-env/bin/activate pip install --upgrade pip pip install -r requirements.txt接下来复制配置文件模板cp etc/cowrie.cfg.dist etc/cowrie.cfg编辑etc/cowrie.cfg关键配置项如下[honeypot] # 监听端口如果直接用 authbind 绑 22这里写 22 listen_endpoints tcp:2222:interface0.0.0.0 # 主机名让攻击者看到的 hostname hostname svr04 # 日志目录 log_path var/log/cowrie # 是否记录下载的文件 download_path var/lib/cowrie/downloads如果你用 iptables 转发listen_endpoints保持 2222然后加一条规则# 把外部 22 转发到 Cowrie 的 2222 sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222伪造文件系统在honeyfs目录下你可以改honeyfs/etc/passwd里的内容让攻击者看到的用户列表更真实。比如加几个常见的服务账户去掉太明显的假名。4.4 启动 Cowrie 并验证 SSH 爆破记录启动 Cowrie# 在 cowrie 用户下激活虚拟环境后启动 source cowrie-env/bin/activate bin/cowrie start查看状态和日志bin/cowrie status tail -f var/log/cowrie/cowrie.log从另一台机器尝试 SSH 连接ssh -p 2222 rootyour_server_ip # 输入任意密码Cowrie 会接受并给出一个假 shell登录后随便敲几个命令比如ls、cat /etc/passwd、wget http://example.com/malware.sh然后回来看日志。Cowrie 会记录登录尝试的用户名密码、执行的命令、下载的文件哈希。日志格式通常是 JSON方便后续分析# 提取所有尝试登录的用户名和密码 grep login attempt var/log/cowrie/cowrie.log | python3 -c import sys, json for line in sys.stdin: try: data json.loads(line) print(data.get(username), data.get(password)) except: pass 这个脚本把 Cowrie 的 JSON 日志解析出来打印攻击者尝试的账号密码组合。你可以据此统计最常用的弱口令比如root/123456、admin/admin然后针对性加固真实系统。Cowrie 还有一个实用功能是记录攻击者下载的文件。在var/lib/cowrie/downloads目录下所有通过wget或curl下载的文件都会被保存文件名是 SHA256 哈希。你可以把这些文件传到 VirusTotal 或本地沙箱分析看看攻击者传播的是什么僵尸网络样本。5. 三种蜜罐的避坑与常见问题排查蜜罐搭起来容易跑得稳、数据可用才是关键。下面这几条是我在实际部署里踩过的坑按“现象 → 原因 → 解决”整理覆盖 Pentbox、Defnet 和 Cowrie 三种场景。5.1 端口冲突导致蜜罐启动即退出现象Pentbox 或 Cowrie 启动后立刻报Address already in use进程消失。原因目标端口被真实服务占用。比如 Cowrie 想监听 22但系统自带的 SSH 已经在跑Pentbox 选了 8080但 Nginx 或 Tomcat 已经占了。解决先用ss -tlnp | grep 端口号确认占用进程。如果是真实 SSH把 Cowrie 改到 2222 并用 iptables 转发或者把真实 SSH 挪到高位端口。Pentbox 换一个没人用的端口比如 18080。改完配置后重启蜜罐再用ss确认监听状态。5.2 Cowrie 日志不记录密码或命令现象Cowrie 能连上但日志里只有连接记录没有登录尝试的用户名密码也没有命令记录。原因Cowrie 的日志级别配置不对或者cowrie.cfg里log_path指向的目录没有写权限。另一个常见原因是用了authbind但没生效Cowrie 实际没绑定成功连接被转发到了真实 SSH。解决检查etc/cowrie.cfg里的log_path确保 cowrie 用户对该目录有写权限。用bin/cowrie status看运行状态如果显示not running去看var/log/cowrie/cowrie.log里的报错。如果是权限问题chown -R cowrie:cowrie /home/cowrie/cowrie/var。另外确认listen_endpoints和实际转发规则一致别一个配 2222 一个转发到 22。5.3 Defnet 被扫描器识别为蜜罐直接跳过现象Defnet 部署后Nginx 日志里只有零星几个请求没有后续的目录扫描或注入尝试。原因模拟的 Web 页面特征太明显比如返回的 Server 头是Werkzeug而不是Apache或者所有不存在的路径都返回一模一样的 404 页面扫描器一眼就认出是蜜罐。解决在 Nginx 里改server_tokens off并伪造Server头比如more_set_headers Server: Apache/2.4.41 (Ubuntu)。Defnet 的 404 页面要模仿真实 CMS 的样式不要用框架默认的调试页面。另外FAKE_PATHS里加一些真实存在的静态资源路径比如/wp-content/uploads/2023/01/logo.png让扫描器认为这是一个有内容的站点。5.4 Pentbox 日志文件无限增长占满磁盘现象Pentbox 跑了一周后VPS 磁盘告警honeypot.log涨到几个 GB。原因Pentbox 默认不做日志轮转每个连接都追加写入公网扫描量大的时候一天就能写几百 MB。解决用logrotate给 Pentbox 日志做轮转。新建/etc/logrotate.d/pentbox/opt/pentbox/honeypot.log { daily rotate 7 compress missingok notifempty copytruncate }copytruncate是关键因为 Pentbox 一直持有文件句柄直接删文件不会释放空间必须用截断方式。Cowrie 和 Defnet 的日志也建议做类似配置尤其是 Cowrie 的 JSON 日志量大了之后解析也会变慢。5.5 蜜罐被攻破后成为攻击跳板现象蜜罐运行一段时间后发现它在外发大量 SSH 连接或 HTTP 请求成了攻击者的跳板。原因Cowrie 的模拟 shell 如果配置不当某些命令可能被真实执行或者 Defnet 的 Web 应用存在真实漏洞攻击者拿到了 shell。解决蜜罐必须跑在隔离环境里最理想是独立 VPS 或容器不要和真实业务同机。Cowrie 确保用非 root 用户跑并且honeyfs里不要放任何真实凭据。Defnet 的 Python 进程用systemd限制权限比如NoNewPrivilegesyes、PrivateTmpyes。另外在 VPS 的安全组里限制蜜罐的出站流量只允许必要的日志回传防止它被用来对外攻击。6. 用 Cowrie 的 JSON 日志做攻击源画像与自动化封禁三种蜜罐跑通之后真正拉开差距的是怎么用数据。Pentbox 和 Defnet 的日志偏文本Cowrie 的 JSON 日志结构化最好适合做自动化分析。我一般会写一个定时脚本每小时跑一次从 Cowrie 日志里提取攻击源 IP、尝试的账号密码、下载的文件哈希然后做两件事一是生成一份简单的攻击源画像二是把高频攻击 IP 推送到防火墙做临时封禁。先看提取脚本的核心逻辑# cowrie_report.py从 Cowrie JSON 日志生成攻击源摘要 import json import collections from datetime import datetime, timedelta LOG_PATH /home/cowrie/cowrie/var/log/cowrie/cowrie.json TIME_WINDOW timedelta(hours1) ip_counter collections.Counter() cred_counter collections.Counter() download_counter collections.Counter() cutoff datetime.utcnow() - TIME_WINDOW with open(LOG_PATH, r) as f: for line in f: try: event json.loads(line) except json.JSONDecodeError: continue ts event.get(timestamp) if not ts: continue # Cowrie 时间戳格式为 ISO8601去掉 Z 后解析 event_time datetime.fromisoformat(ts.replace(Z, )) if event_time cutoff: continue src_ip event.get(src_ip) if src_ip: ip_counter[src_ip] 1 if event.get(eventid) cowrie.login.failed: cred_counter[(event.get(username), event.get(password))] 1 if event.get(eventid) cowrie.session.file_download: download_counter[event.get(shasum)] 1 print( 高频攻击源 IP ) for ip, count in ip_counter.most_common(10): print(f{ip}: {count} 次) print(\n 最常尝试的账号密码 ) for (user, pwd), count in cred_counter.most_common(10): print(f{user}/{pwd}: {count} 次) print(\n 下载文件哈希 ) for shasum, count in download_counter.most_common(5): print(f{shasum}: {count} 次)这段代码的逻辑是只统计最近一小时的事件避免历史数据干扰。ip_counter统计每个源 IP 的事件总数cred_counter统计登录失败的用户名密码组合download_counter统计下载文件的 SHA256。参数上TIME_WINDOW可以根据你的日志量调整量大的话缩到 15 分钟量小的话放到 6 小时。拿到高频 IP 之后可以用ipset加iptables做自动封禁# 创建 ipset 集合 sudo ipset create cowrie_blacklist hash:ip timeout 3600 # 把高频 IP 加入集合这里假设 report 输出里提取了 IP 列表 for ip in $(python3 cowrie_report.py | grep -oE ^[0-9]\.[0-9]\.[0-9]\.[0-9]); do sudo ipset add cowrie_blacklist $ip done # 让 iptables 引用这个集合丢弃来自黑名单的流量 sudo iptables -I INPUT -m set --match-set cowrie_blacklist src -j DROPtimeout 3600表示封禁一小时到期自动解封避免误封正常 IP。这个方案的好处是封禁列表在内存里查询快不影响正常流量。我一般会把脚本挂到cron里每 30 分钟跑一次日志量大的时候能明显减少无效连接对蜜罐的干扰。最后说一个我自己的习惯蜜罐的日志不要只留在本地定期打包传到另一台机器或对象存储。有一次 VPS 被攻击者发现是蜜罐后直接格式化了本地日志全丢后来我就养成了每天凌晨自动同步日志的习惯。蜜罐这东西数据比蜜罐本身值钱。希望帮到你。本文还有配套的精品资源点击获取