容器化Honeypot蜜罐搭建实战：攻击诱捕与威胁感知平台

Honeypot 在 2024 年早就不是网安圈里一个冷门术语了。凡是做过攻防演练、护网值守，或者被勒索软件折腾过的朋友，应该都体会过那种“流量里全是扫描，日志里全是爆破”的窒息感。传统防守思路是把门焊死，漏洞补掉，端口收敛；蜜罐的玩法完全反过来，它要故意留一扇“没锁好的窗”，等你翻进来，然后全程记录你的动作，把你的习惯、工具、目的摸得一清二楚。我最早接触蜜罐完全是偶然，当时只是想搞清楚“为什么公网一个闲置 IP 上会有人一直尝试 SSH 登录”，后来干脆照着开源的蜜罐方案把这台服务器改造成了一个诱捕节点。这套东西在 2024 年的语境下依然能打，尤其是配合容器化部署，成本低、见效快，非常适合安全运维、蓝队成员、以及正在准备安全方向面试的技术同学去深入玩一遍。这篇文章就围绕“如何从零搭建一套 Honeypot 诱捕与威胁感知平台”展开，把我踩过的坑、总结的参数选型思路、日志分析方法和排障经验一并梳理出来。

1. 项目整体设计与安全思路拆解

1.1 蜜罐的本质：给攻击者一座“假堡垒”

很多刚接触安全的朋友对蜜罐有个误解，以为它就是一台没人管的服务器，开着 22 端口扔在公网上等被人扫。实际上蜜罐的核心是“诱导”和“记录”。它不是一个简单暴露的服务，而是一个精心设计的、具备仿真业务特征的诱饵环境。攻击者命中蜜罐时，他会觉得自己进入了一个真实系统，但实际每一个交互行为都被后台完整记录，包括连接来源、端口扫描特征、尝试执行的命令、提交的 Payload、甚至文件上传样本。

2024 年再聊 Web 安全，大家的关注点早就从“找洞打点”转向了“攻击检测与溯源”。蜜罐在这条路径里的价值非常独特：它天然没有业务流量，所有连接都是可疑的。这就意味着你不需要像在正式业务日志里那样做海量数据降噪，任何一次 TCP 握手、任何一条认证失败记录，都可以直接当作告警来对待。这种“低噪声、高信号”的特性，是蜜罐作为威胁感知设施最核心的优势。

我自己搭建这套系统时，目标定得很明确：不追求高交互仿真，不搞花哨的桌面虚拟化，先把最常见、最容易遭攻击的三个入口仿真出来——SSH 登录入口、HTTP 服务入口、以及一个简单的数据库登录入口。攻击者最常打哪里，蜜罐就放在哪里。

1.2 部署位置与仿真对象的选择逻辑

蜜罐放哪儿很有讲究。真正在公网环境部署时，我推荐放在旁路隔离区或者云厂商的安全组边界，具体来说：选择一个没什么真实业务的闲置公网 IP，或者一个独立子网，专门用来承载蜜罐流量。这样做的好处是，即使蜜罐被攻陷、被当作跳板，也影响不到真实业务网段。

仿真对象的选择逻辑要跟着攻击热区走。2024 年比较典型的攻击入口包括三个方向：

第一是 SSH / RDP 这类远程管理端口，互联网上几乎每时每刻都有自动扫描器在探测，属于最多见、最容易“上钩”的入口。第二是 Web 服务，特别是包含文件上传、API 接口、管理后台这类高风险路径的应用。第三是数据库服务，比如常见的 MySQL 协议、云数据库接口，攻击者扫描到 3306 端口暴露时往往愿意花时间尝试弱口令。

我搭建的三台蜜罐容器，正好对应这三个入口。每个容器都跑在一个独立的容器网络中，宿主机只开放对应的映射端口，再在宿主机防火墙里做一层访问控制，保证蜜罐之间无法互相横向渗透。这个隔离设计非常重要，否则蜜罐就会变成蜜网里的“内鬼”。

1.3 为什么我选择通用开源组件来搭建

有人可能会问：为什么不直接用商业蜜罐设备？商业产品当然好，有漂亮的报表、完善的告警和态势感知整合，但价格不菲，对个人实验、中小规模安全团队来说其实有点重。用通用开源组件和容器化方案自己搭，最大的优势是三点：成本几乎为零、可定制性强、学习价值高。

我选择的方案是基于容器运行的“低交互蜜罐镜像”，配合一台轻量主机和一套简单的日志采集服务。这种方式与操作系统解耦，不挑发行版，只要宿主机有容器运行环境就能跑。2024 年容器几乎是基础设施标准，所以这套方案在绝大多数公司里都能平滑落地。

另外，把蜜罐容器化以后，启停和扩容都非常方便。一次威胁样本分析完成后，可以直接把容器销毁重来，不留死角。相比用虚拟机跑高交互蜜罐，容器方式大幅降低了维护成本，也降低了被攻击者“反杀”后逐层渗透的风险。我的原则很简单：能用隔离手段解决的问题，就不要依赖运气。

2. 核心组件选型与关键参数配置

2.1 低交互与高交互：两条路线的取舍

蜜罐按照交互程度，大致分成低交互、中交互和高交互三类。低交互蜜罐通常只模拟服务的握手和基础协议行为，不提供真实操作系统；高交互蜜罐则直接给攻击者一台完整的操作系统或者虚拟机，让攻击者自由操作。到底选哪种，取决于你的目标和风险承受能力。

如果目标是收集扫描情报、观察自动化攻击和批量爆破行为，低交互就足够了。它占用资源少，维护简单，而且不会真被“攻破”，因为压根没有真实系统可以被突破。如果目标是分析高级攻击者的完整攻击链，比如看他会下载什么工具、修改什么文件、如何提权，那就需要高交互蜜罐，但这意味着你要做好被攻击者拿下的心理准备，而且隔离措施必须极其严密，稍有疏忽就可能成为攻击者的真正跳板。

我这次搭建选择的是低交互为主、个别入口做中交互增强的混合思路。SSH 蜜罐提供完整的认证流程仿真，允许攻击者尝试密码，但登录后给出受限的虚拟 Shell；Web 蜜罐不只返回一个假页面，还能模拟文件上传接口，收集攻击者提交的可疑文件；数据库蜜罐则模拟 MySQL 协议的握手和认证失败流程，记录所有尝试登录的用户名和密码组合。

2.2 三套蜜罐组件的选型对比

为了方便读者理解，我把这次选用的三套组件方案整理成了一张表，标注了它们各自负责的协议入口、核心能力和选型理由。

这个选型完全是基于性价比的考虑。市面上还有很多高仿真蜜罐框架，但部署复杂度偏高。对个人实验和中小团队来说，组件足够轻量、日志格式清晰、便于二次开发，比追求仿真度更重要。毕竟蜜罐的“仿真”只要达到“让自动化攻击工具不怀疑”的程度就成功了，大部分扫描器和爆破工具只验证成功的认证、直接返回的数据包格式，不会深究系统指纹是否绝对完整。

2.3 关键配置参数的设计思路

配置蜜罐时，几个关键参数直接决定效果。第一是监听端口。SSH 蜜罐我直接使用 22 端口，Web 蜜罐使用 8080 和 443 这对组合，数据库蜜罐使用 3306。有人觉得 22 端口太常见，扫描器未必会关注，但实际上互联网扫描器对 22 端口的探测强度是所有端口中最大的，因为 SSH 爆破是最廉价的攻击尝试。

第二是登录受限策略。SSH 蜜罐的虚拟 Shell 我设置了命令白名单：只允许 ls、pwd、cat、uname、wget 这类常见命令，超出范围直接返回“command not found”。这样做一方面能诱使攻击者继续操作，另一方面限制了蜜罐被用于恶意活动的可能。wget 命令虽然允许，但会做内容过滤，只记录请求不落盘，避免蜜罐变成钓鱼文件的宿主。

第三是日志级别。我会把三套蜜罐的日志统一设置为 JSON 格式输出，打开全部协议头、负载和认证信息的记录选项。后面做数据分析时，JSON 格式比 syslog 文本格式更省事，可以少写一半解析代码。

注意：仿真的服务版本号不要写成系统真实版本。目的不是恶心攻击者，而是减少蜜罐被确认不是真实业务系统的概率。版本号越旧、越常见，越容易在自动化工具里“蒙混过关”。

3. 实操过程与核心环节实现

3.1 部署环境与前置准备

这次实验我准备了一台轻量云主机，2 核 4G 内存，60G 磁盘，操作系统用的主流 Linux 发行版。为什么特别强调这个配置？多台蜜罐容器加上日志采集服务，2 核 4G 在容器的弹性伸缩下完全够用，如果只用单核 1G 则容易出现容器启动缓慢、日志写入卡顿的情况。磁盘容量建议不低于 40G，因为蜜罐日志会积累得比你想象中更快，尤其是在公网、且被扫描器盯上的情况下，一天可能产生几条万级的连接记录。

前置组件只需要一个运行环境：容器服务。如果你的云主机还没有安装容器服务，参考对应平台的安装文档装好即可。安装完成后执行docker version确认客户端和服务端都在运行状态，这步经常有人忽略，最后容器启动失败才回过头来查。

此外我准备了一个独立目录作为数据持久化目录，比如/opt/honeypot。下面分成config、logs、samples三个子目录，分别存放配置文件、日志输出和攻击者提交的可疑文件。目录规划好以后，后续清理和维护都会轻松很多。

3.2 创建隔离网络与启动三套蜜罐容器

容器网络隔离是整个方案安全性的基础。我先创建了一个名为honeynet的容器网络，网段用172.20.0.0/24，并把宿主机远程管理端口排除在外，宿主机不加入这个网络。这样即使攻击者拿到容器权限，他能访问的也仅仅是这个虚拟网络里的其他蜜罐，而不是宿主机上的真实网络。

docker network create --subnet=172.20.0.0/24 honeynet

然后分别启动三套蜜罐容器。SSH 蜜罐的启动命令我留了宿主机 2222 端口到容器 22 端口的映射，因为宿主机本身可能已经占用 22 端口做远程管理，直接映射冲突。公网攻击者扫描任意端口都无所谓，关键是服务要响应。

docker run -d \ --name honeypot-ssh \ --network honeynet \ -p 2222:22 \ -v /opt/honeypot/logs:/var/log/honeypot \ --restart=always \ honeypot-ssh:3.1

Web 蜜罐的启动类似，映射宿主机 8080 端口到容器 80 端口，同时挂载samples目录，用来接收攻击者上传的样本。

docker run -d \ --name honeypot-web \ --network honeynet \ -p 8080:80 \ -v /opt/honeypot/logs:/var/log/honeypot \ -v /opt/honeypot/samples:/samples \ --restart=always \ honeypot-web:2.0

数据库蜜罐我映射宿主机 3306 端口，同时将配置目录挂载到宿主机，方便修改认证响应规则。

docker run -d \ --name honeypot-db \ --network honeynet \ -p 3306:3306 \ -v /opt/honeypot/logs:/var/log/honeypot \ -v /opt/honeypot/config:/etc/honeypot \ --restart=always \ honeypot-db:1.4

三条命令跑完之后，用docker ps检查容器状态，应该是三个容器全部处于 Up 状态。这一步最容易踩的坑是端口占用。如果宿主机的 3306 或 8080 已经被真实应用占用，容器启动会直接失败，启动前先执行ss -lntp检查端口状态是个好习惯。

3.3 配置 SSH 蜜罐的仿真参数

SSH 蜜罐是这套系统里最核心的组件，因为它承受的扫描流量最多。我编辑了它的配置文件，设置了一个看起来不算太新的版本号，并启用了虚拟终端交互。配置片段大致如下：

listen: host: 0.0.0.0 port: 22 max_connections: 1024 fake_banner: "SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6" auth: enabled: true max_attempts: 5 log_credentials: true shell: enabled: true allowed_commands: ["ls", "pwd", "cat", "uname", "id", "wget", "curl"] timeout_seconds: 300 logging: format: json path: /var/log/honeypot/alerts.jsonl

这个配置里最需要解释的是max_attempts参数。为什么要限制为 5 次？因为大部分自动化爆破工具会在几次失败后切换目标，允许无限次尝试反而会让工具反复撞库，产生大量无意义的日志噪音。限制 5 次既能收集足够的凭证信息，又不会把蜜罐变成“无限密码尝试机”。

allowed_commands的设定也有讲究。wget和curl是被攻击者高频使用的下载工具，但我会在日志里完整记录下载请求的 URL，并且阻止实际文件落盘。这相当于给攻击者一个“假动作”：命令执行成功，但文件从未真正下载到蜜罐里。

配置完成后重新加载容器，然后用ssh -p 2222 root@localhost从宿主机做一次连通性测试。如果配置正确，你会看到仿真版本号，并且任意密码都能触发认证失败提示，同时日志文件里会出现一条认证失败的 JSON 记录。到这一步，第一只“蜜罐”基本就可以进场了。

3.4 Web 蜜罐的核心交互实现

Web 蜜罐的配置重点不是页面长得像不像真实系统，而是需要暴露几个明确的敏感路径。我启用了两个典型路径：一个是/login.php，模拟后台登录；另一个是/upload.php，模拟文件上传接口。攻击者扫描到这两个路径时，会认为该系统存在可利用的后台或文件上传点，从而进一步提交请求。

/login.php的交互逻辑模拟了密码错误时返回特定的报错文本。这个细节很重要，因为很多扫描器会通过响应头的特征判断目标系统类型，所以我给 Web 蜜罐配置了与服务器版本匹配的响应头，包括Server、X-Powered-By等字段，尽量做到“像个老系统”。

/upload.php接口收到上传请求后，不会真正保存文件，但会在日志中记录文件原始文件名、大小、内容哈希和请求表单字段。很多攻击者在探测到上传接口后会尝试上传一句话木马或测试脚本，这些样本虽然不会被实际执行，但哈希值可以拿到本地沙箱做进一步分析，或者在威胁情报平台查询是否命中已知恶意样本。

我在 Web 蜜罐上还加了一个小功能：给访问敏感路径的连接自动追加一条来源 IP 的地理位置标签。地理信息不是日志分析必需的，但它能在告警时快速判断威胁来源，省得每次分析都要手动查 IP。

3.5 配置告警与输出

蜜罐的日志如果只躺在磁盘里，价值就打了个大折扣。我给它配了一条很简单的告警通道：当alerts.jsonl文件在短时间内新增记录条数超过阈值时，触发系统通知。这个阈值我调成了每分钟 30 条，因为公网扫描通常是短时脉冲式的，单条连接往往不值得告警，但每分钟超过 30 条时就说明有批量扫描行为发生。

告警通道对接的是通用的 Webhook 机器人。想象一下这个场景：正在盯业务系统的时候，突然收到一条消息提醒“外部 IP 正在高频尝试 SSH 登录蜜罐”，那种感觉跟在猎区实时报警一样，非常有掌控力。这种自动化告警的设计也给后续扩展留了接口，以后如果想对接完整的 SIEM 平台，只要把日志流导向那边就行。

告警消息的格式我做了精简，每条包含时间、来源 IP、目标协议、事件类型和原始载荷摘要。这比发送完整日志更有效，也避免消息刷屏。核对告警的时候注意：任何一条蜜罐日志都默认是可疑行为，如果告警频率恢复正常了，可以抽空回查原始日志做深度分析。

4. 日志数据分析与威胁情报提炼

4.1 从蜜罐日志里能看到什么

蜜罐日志记录的信息可以分为三个层次：连接层记录来源 IP、来源端口、目标端口和连接时间；认证层记录尝试的用户名密码组合、认证是否成功、客户端指纹；内容层记录攻击者发送的实际载荷、请求的路径或提交的命令。这三个层次的信息组合起来，基本能还原一次攻击尝试的骨架。

我最关注的记录类型是认证成功事件和命令执行事件。低交互蜜罐虽然不会给攻击者真实系统权限，但只要攻击者走了完整的认证流程并开始输入命令，就意味着他不是单纯的自动扫描器，而是有人在手动操作。这种事件往往比上万条扫描记录更有情报价值。

日志文件保存格式是 JSON Lines，一行一个事件对象，每个对象里包含所有字段。用命令行工具可以快速抽取可见字段：

cat /opt/honeypot/logs/alerts.jsonl | jq -r 'select(.event_type=="login_success") | .source_ip'

这条命令会把所有认证成功事件的来源 IP 提取出来。如果你看到大量从未见过的 IP 在短时间内集中出现，那就说明蜜罐的效果正在显现——你已经被扫到了。

4.2 一套最简单的统计脚本

日志真正要产生价值，不能靠肉眼一条条刷，而是要做聚合统计。我写了一个简单的 Python 脚本，用来统计“来源 IP + 用户名 + 尝试次数”的组合排名。这个脚本虽然没有用到任何复杂机器学习算法，但实测下来非常实用，能快速发现规律性爆破行为。

import json from collections import Counter log_path = "/opt/honeypot/logs/alerts.jsonl" counter = Counter() with open(log_path, encoding="utf-8") as f: for line in f: try: event = json.loads(line.strip()) except json.JSONDecodeError: continue if event.get("event_type") == "login_attempt": src_ip = event.get("source_ip", "") username = event.get("username", "") counter[(src_ip, username)] += 1 for (ip, user), cnt in counter.most_common(20): print(f"{ip}\t{user}\t{cnt}")

脚本跑完之后，输出里排行靠前的往往就是爆破行为。有一个现象值得注意：许多扫描器会固定尝试 root、admin 这类常见账号，用户名集中度非常高；而某些定向攻击者会尝试变量弱的账号组合，比如英文单词加数字。通过用户名分布可以初步判断攻击是广撒网还是定向侦察。

如果你只想知道哪些账号名被尝试得最多，脚本里把聚合键改成username即可。还可以顺手统计 24 小时内的攻击时间分布，找出“凌晨活跃”的扫描来源。这些统计结果放到周报里，就是非常清晰的攻击面变化趋势。

4.3 从告警线索到事件研判方法

拿到告警之后，正常情况下不要直接回复“已告警”然后就完事了。我习惯的做法是分三步做事件研判：第一步核对原始日志，看来源 IP 是否多次出现、尝试过哪些服务；第二步查威胁情报库，看该 IP 是否与已知扫描源、恶意样本家族有关联；第三步分析载荷内容，提取请求特征，判断攻击来源的意图。

举一个实际遇到的例子：某天凌晨蜜罐几条告警，来源 IP 全部相同，针对 SSH 和 Web 服务都发起了尝试。原始日志显示它不仅在爆破账号，还向 Web 蜜罐的上传接口提交了一个文件。我提取了文件哈希并查询威胁情报库，结果显示该文件与一组已知的 Web Shell 样本特征相似。整个过程从告警到形成结论不到半小时，如果不靠蜜罐日志，这种探测行为可能完全不会被注意到。

这里要特别提醒：研判过程中不要把蜜罐采集的日志直接当作“定罪”依据，它只能说明有人在与你的蜜罐交互，不能证明对方一定对真实业务系统有恶意。它真正的作用是帮你提前锁定可疑目标，为后续防守动作争取时间。

5. 常见问题与排查技巧实录

5.1 故障速查表

搭建和运行蜜罐的过程中，一定会遇到各种问题。我把大量实践中遇到的故障整理成了一张速查表，方便读者对照排查。

其中“扫描器立即识别蜜罐”这个问题最隐蔽。早期我部署了一套 Web 蜜罐，配置的Server响应头是某个较新版本的 Web 服务器，结果不到半天就发现连接数量断崖式下降。后来分析才意识到，新版本响应头与实际页面内容呈现的年代特征不匹配，导致扫描器轻易判断出这是伪造节点。调整配置并让服务指纹整体回到同一代际之后，上钩率又恢复了。

5.2 蜜罐被识破的典型原因

蜜罐被识破几乎无法完全避免，但我们可以尽量压缩被识别的原因。最典型的原因有三个：指纹不一致、行为异常、缺少常见配置路径。

指纹不一致是指响应头、页面特征和服务版本“混搭”。比如页面底部写着某个旧版本的版权信息，但响应头暴露了新版服务器版本，这明显不合常理。行为异常是指蜜罐响应速度过快或过于一致，真实系统在高并发下会有一点延迟抖动，而蜜罐镜像通常反应速度恒定；这个问题可以通过在网络层增加轻度延迟抖动来缓解，但一般扫描器不太会检测这个层面。

缺少常见配置路径则是比较“顽固”的失误。真实系统总会存在一些辅助页面，比如favicon.ico、robots.txt、.DS_Store，蜜罐如果只暴露一个登录页，扫描器很快就能通过路径字典匹配发现“这个站点没有普通站点的边角料”。我后来给自己的 Web 蜜罐补充了一批静态资源和常见路径，页面完整度立刻提升了一个档次。

5.3 蜜罐日常维护的注意事项

蜜罐不是搭好就可以放在那里“自生自灭”了。它就像一张网，要定期检查、清理和调整。在我的维护节奏里，至少每周做三件事：检查日志文件大小并轮转留存，清理过期日志防止磁盘写满；查看告警统计，判断本周攻击热区有没有变化；更新恶意特征库，保证对已知攻击样本的识别能力。

日志轮转非常重要。一个被公网扫描器密集探测的蜜罐，一周产生的日志能在几百兆以上。如果不做轮转，日志文件越来越大，后续分析脚本解析的效率也会下降。我习惯用系统自带的日志轮转工具，按天切分，保留最近 30 天，过期自动清理。

还有一个运维细节是容器镜像的升级。2024 年主流容器镜像已经支持非常灵活的标签管理和自动拉取策略，不要在运行中的蜜罐容器上直接修改核心配置，正确的是更新配置文件后重建容器。这样做既保证配置的可追溯，也避免运行中的容器状态和配置漂移。

6. 进阶扩展方向与个人实践心得

6.1 从单点蜜罐走向分布式蜜网

当一套蜜罐跑顺之后，你会很快意识到单个节点的视野有限，毕竟它只覆盖三个端口，只能感知部分扫描方向的攻击。真正想扩大威胁感知面，可以考虑把单点蜜罐扩展成分布式蜜网：在多个网段、多个云区域部署蜜罐节点，将日志汇聚到统一的分析中心。

分布式蜜网的难点不在于“多装几台容器”，而在于日志集中管理和关联分析。实际方案中，每个区域的蜜罐节点可以把日志实时回传到中心分析服务器，中心服务器再通过任务编排完成跨节点事件的关联。比如同一批来源 IP 在短时间内先扫了 A 区域的 SSH 蜜罐，又尝试连接 B 区域的 Web 蜜罐，这就可以判定为一次有计划的批量侦察，而不是随机扫描。

蜜网的建设还有一个隐性收益：为威胁情报库提供高质量的攻击源数据。将蜜网采集到的来源 IP、指纹行为、载荷特征定期导出，再结合其他安全数据源交叉验证，就能形成一套有价值的内部情报系统。这个方向对安全团队建设尤其有吸引力。

6.2 与现有安全设备联动

蜜罐虽然好，但不能孤立运行，最好能和现有的安全防护体系联动。最常见的联动方式是把蜜罐日志接入 SIEM 平台，与防火墙日志、EDR 告警、IDS 日志做关联分析。蜜罐参数可以作为网络威胁的“早期警告信号”，当蜜罐检测到某个来源 IP 的行为后，自动下发防火墙策略封锁该 IP，形成一个简单的自动化响应闭环。

我自己的环境里实现过一条轻量联动策略：当蜜罐日志中出现“认证成功 + 执行下载命令”的组合事件时，自动触发脚本，在防火墙上临时封禁该来源 IP 一小时。这套闭环的逻辑在于，“认证成功”和“尝试下载文件”这两个连续行为表明已经不是普通扫描器，而是具备主动攻击意图的会话。自动封禁的阈值需要谨慎设置，宁可保守一点，也不要把封禁策略做得过于激进，避免产生误伤。

另外我也把蜜罐日志与威胁情报平台做了对接。每次分析事件时，脚本自动提取来源 IP 和载荷哈希，在情报平台批量查询，结果回写到观察列表。这样做既能“有的放矢”，也不会把情报平台的调用额度浪费在无关流量上。

6.3 关于这项技术的一点大实话

在接触蜜罐之前，我一直觉得防守方是“被动挨打”，只能等攻击者触发规则才有所反应。蜜罐彻底改变了我的这个看法。它的思路是主动出让一些看起来有价值的“攻击面”，利用攻击者的贪婪和自动化工具的低识别力，把未知的探测行为转化为已知的可分析数据。2024 年的攻击面越来越复杂，自动化攻击工具也越来越普及，蜜罐这种“以退为进”的思想反而能在防守体系里占据独特位置。

我个人在实际操作中的体会是，蜜罐的价值不在于它能不能“抓到攻击者”，而在于它能不能帮你重新理解你的边界。它能看到你在常规防护日志里永远看不到的探测流量，让你知道谁在看你的系统、想怎么进来、进来之后打算做什么。哪怕只是一个月跑下来积累的日志，也足够你对自己的暴露面做一次非常深刻的反省。

最后再分享一个实际经验：蜜罐也需要保护，尤其是它的配置文件和日志。只要有可能，尽量把蜜罐的数据目录单独存放到带加密的磁盘，并把日志设置为只追加、仅管理员可写。因为万一蜜罐被入侵者反制，他第一件事可能就是清理日志，从而抹掉自己的行动痕迹。给日志加上保护，相当于给整个诱捕系统加了一层保险。希望这篇实战梳理能给你一些启发，也欢迎你在自己的环境里动手实验，做出属于你自己的威胁感知节点。