T-pot蜜罐系统搭建的辛酸路程：从反复劝退到稳定运行的完整复盘
如果你在安全圈混过一阵子，大概率听过T-pot的大名。开源的蜜罐平台，官方文档写得漂亮，示意图上各种攻击热力图、实时统计面板，一眼看过去战斗力拉满。我最初也是被这套效果图吸引，兴致勃勃地准备在服务器上搭一套，结果从选型到部署再到日常维护，每一步都踩在坑里。这篇文章就从我的角度完整梳理一遍搭建T-pot的辛酸路程，把那些官方文档没写透、论坛帖子里零散提到、以及我反复折腾才搞明白的门道，一次性说清楚。
这篇内容适合谁看呢？如果你正准备部署T-pot，想知道硬件到底要多高配置、安装时哪些地方容易卡住、跑起来之后有哪些隐藏雷区，那这篇文章基本能帮你绕开我走过的弯路。如果你是安全方向的学生或者刚入门的研究者，看完之后你也会明白，蜜罐系统真正的价值不只在"部署成功"那一刻，而在后续长周期的观察和数据积累。
1. 为什么是T-pot：蜜罐选型时的纠结与最终判断
1.1 聊一聊我对比过的几套蜜罐方案
在决定用T-pot之前，我其实花了不少时间在选型上。市面上的蜜罐方案五花八门，从单点的小工具到全家桶式的平台都有，不同方案的侧重点差别很大。我拿以下几类做过简单对比：
第一类是单引擎蜜罐，比如Cowrie、Dionaea、Glastopf各自独立部署。Cowrie擅长模拟SSH和Telnet服务，能记录攻击者输入的命令；Dionaea主攻服务漏洞捕获，能收集恶意样本；Glastopf后起之秀，专门做Web层面的攻击诱捕。这套方案的优势是轻量、可控性强，缺点是每个蜜罐要单独部署、单独维护、单独接入日志，攻击数据分散，很难形成全局视角。
第二类是商业蜜罐平台，功能确实强大，威胁情报整合得也很完善，但授权费用高，对个人研究者和中小企业并不友好。
第三类就是我最终选择的T-pot。它把多个蜜罐引擎整合在一个平台上，基于Docker容器化运行，自带全套的日志采集、分析、可视化和告警组件。用一套系统就能看到所有蜜罐捕获的数据，还有ELK日志套件提供搜索和图表展示。
1.2 T-pot的核心优势与潜在代价
T-pot的设计思路很清晰：把所有蜜罐相关组件打包成模块化的Docker镜像，通过容器方式运行在独立宿主机上。系统启动后，多个蜜罐监听在不同端口上，流量到达后各司其职，日志统一汇总到数据管道，最终进入Elasticsearch，由Kibana做可视化展示。另搭配实时攻击地图、SpiderFoot OSINT工具模块、以及用于检测恶意文件的威胁情报模块，整体架构属于"一套系统，全家到位"的类型。
这样设计的好处非常明显：部署一套系统，就等于在服务器上同时开了SSH蜜罐、Web蜜罐、恶意软件捕获器、网络入侵检测等一串服务，而且数据天然汇聚在一个界面里。对于攻击趋势分析、恶意样本收集这类任务，它的效率远超单引擎拼凑的方案。
但代价也摆在那里。官方文档提到建议配置是"8核CPU、32GB内存、200GB以上磁盘空间"，当时我还觉得这个要求太夸张了，事实证明它不仅没夸张，在某些场景下甚至不够用。如果你手头的服务器资源紧张，T-pot的高资源消耗就会变成搭建路上第一个"辛酸"来源。
1.3 什么情况下可以选T-pot，什么情况下不建议选
做选择之前，先把适用边界想清楚很重要。如果你的目标是长期观察网络攻击态势、收集恶意样本、或者做安全数据分析展示，T-pot非常合适。它自带的数据聚合和可视化能力能让你快速从碎片数据里看出趋势。但如果你只是想在公司的内网里小范围做一次验证性测试，或者服务器资源本身就非常有限，又不想承担高维护成本，那我建议还是从单引擎蜜罐入门，至少能把维护成本控制在一个可控范围内。
我的教训是：不要因为功能多就选全家桶，先评估自己手里的资源和你真正想解决的问题。
2. 部署前置条件：那些被官方文档一句话带过的硬性门槛
2.1 硬件资源要求：官方建议32GB内存，不是没道理
我第一次部署时候用的是8GB内存的服务器，想着蜜罐不过就是几个容器在跑，能有多大消耗。结果T-pot启动过程中，光是多个容器同时运行就把内存吃满了，页面卡成PPT，最后系统直接OOM崩溃。不得已重新买了一台高配服务器，才把平台稳定跑起来。
我的实测结论是：
- 如果你的机器只有16GB内存，系统能启动，但Kibana和Elasticsearch同时跑起来之后会非常吃力，偶尔会有查询卡顿。
- 如果只有8GB内存，基本可以放弃，除非你只启动部分模块，不跑全量套件。
- 最理想的情况还是按官方建议来：8核以上CPU、至少32GB内存。磁盘方面，200GB起步，如果你打算长期运营并保留全部日志，建议直接上500GB或者更大容量。
这里特别提醒一下，如果你使用的是云服务器，选配置的时候就要计算好成本，因为T-pot不只是部署那一刻吃资源，它是全天候一直在吃的。
2.2 系统版本和网络环境：影响安装顺利程度的隐藏变量
T-pot官方对宿主机系统版本有一定要求。安装时它会自动拉取Docker镜像并执行大量脚本，系统版本太旧容易在新旧组件之间出现兼容性问题，版本太新又可能因为内核模块差异导致系统组件运行异常。我当时用了一版较新的Ubuntu，结果安装过程中某个内核依赖找不到，折腾了半天才通过换源和补装依赖解决。我的建议是严格按官方文档来，部署在官方明确标注支持的发行版和版本上。
另一个容易忽略的问题是网络环境。安装过程需要从网络拉取大量镜像和数据包，如果你的服务器网络环境对海外源支持不好，下载速度会非常慢，甚至中途失败。我当时第一次卡在这一步，进度条卡住不动，进也不是退也不是。后来是通过换成本地镜像源才解决，部分网络条件下还需要配置代理调整下载通道。这一点跟你的实际网络环境关系很大，建议在国内的云服务器上提前确认相关软件源的可访问性并做好替换方案。
2.3 独立服务器还是共享环境：不推荐在已有生产环境上部署
这是很多人容易犯的错误。我当时也想过，既然手头已经有一台在跑的服务器，能不能顺手把T-pot搭上去？事实证明这是非常不理智的选择。
T-pot本身会开启一系列蜜罐服务，这些服务会监听端口并在公网暴露，自然也会引来大量扫描流量和攻击尝试。如果这台服务器上还运行着其他业务服务，这些频繁的攻击探测会加大系统负载，甚至引发安全风险。更麻烦的是，蜜罐捕获的日志量很大，容易占满磁盘，间接影响到其他服务的正常运行。
所以我的强烈建议是：给T-pot准备一台独立的服务器，不要让任何生产业务和它共存。蜜罐的价值就在于它能被攻击，如果跟生产环境混在一起，那你就是引狼入室。
3. 安装阶段：三次差点把我劝退的瞬间
3.1 第一步卡壳：Docker镜像拉取从白天等到天黑
T-pot的部署方式是基于Docker套件拉取一系列镜像，包括各类蜜罐引擎、Elasticsearch、Kibana、Logstash、Nginx等。这些镜像体积都不小，而且数量多，总下载量相当可观。我第一次安装的时候，光镜像拉取阶段就等了一下午，中间还因为网络波动断过两次，每次断了就得重试。
如果你也准备安装，我建议你在这一步务必留出充足时间，不要指望十分钟内完成。同时做好失败重试的心理准备。为了减少重复等待，我后来找到一个方法：先把镜像源切到本地的加速地址，再用预下载的方式把核心大镜像提前拉下来，这样后续真正执行安装流程时会快很多。
3.2 SSH端口冲突：我把22端口改了三次，才搞明白真正的冲突点
T-pot部署过程中涉及到SSH服务的配置。默认情况下，系统自带的SSH服务监听在22端口，而T-pot的Cowrie蜜罐也需要模拟一个SSH服务。这时候问题来了：两个服务抢同一个端口，总要有一个让位。
我第一次没注意这个细节，执行完部署脚本后，发现Cowrie一直没正常监听，排查了半天才发现是系统自带的SSH占着22端口。解决办法很简单，把系统SSH服务改到别的端口，把22端口留给蜜罐使用。但这里有个非常容易踩的坑：有些云厂商的防火墙规则会默认放行22端口，如果你把系统SSH改到其他端口后忘了更新安全组规则，你可能连服务器都登不上去了。我自己就因为这个原因远程中断过一次，最后只能通过厂商后台的应急功能把机器救回来。
这个过程的经验可以总结为：修改SSH端口前先把云防火墙新增规则放在第一位，再动手改配置。改了之后不要急着断开当前会话，用新的端口重新开一个会话验证能连上，再断开旧的。
3.3 Dashboard的初始密码和SSH密钥：忘了就等着哭
T-pot安装完成后会生成一个管理面板的访问入口，以及用于认证的密码和SSH密钥。这里有个很坑的细节：不少版本安装完成后，最终的地址和认证信息是随机生成，而且只在安装过程的输出结尾显示一遍。我当时把这串信息复制到一个临时文档里，后来清理临时文件的时候顺手就删了。等想登录面板的时候才发现密码不知道，密钥也没了，无奈之下只能重新部署一遍。
因此我强烈建议你在安装结束的那一步，把输出信息完整保存到本地加密笔记软件里。包括访问地址、用户名、密码、SSH端口和密钥内容都存好，不要有任何侥幸心理。
4. 运行阶段：真正的"辛酸"才刚刚开始
4.1 端口映射与防火墙：漏掉一个，半个平台就废了
T-pot跑起来之后，各蜜罐模块会在宿主机上监听大量端口，比如SSH蜜罐的22端口、Web蜜罐的80端口、其他服务蜜罐的各个专用端口。与此同时，管理面板和Kibana分别监听在独立的HTTPS端口上。
如果你使用的是云服务器，那就不得不面对安全组和防火墙规则的配置问题了。这部分的坑在于：放行端口是有讲究的。你既要把蜜罐服务使用的端口全放出去，让攻击流量能进来，又要保护管理端口不暴露给所有人，最好设置为只允许你的办公IP访问。
我当时配置的时候就漏了一个端口，导致Dionaea模块日志一直为空。那个模块监听在一个不常用端口上，我最初以为它没启用，排查了很久才发现是防火墙根本没开放这个端口。所以建议在部署完成后，用端口扫描工具从外部扫一遍，逐一对比哪些端口在对你放行、哪些不是。
4.2 资源消耗监控：16G内存扛不住ELK全家桶
T-pot跑起来之后，我很快发现资源占用比我想象中严重得多。Elasticsearch本身就是吃内存的大户，加上Kibana的常驻进程，以及Logstash的数据处理管道，三巨头加起来几乎吃掉了整台服务器大半的内存。多个蜜罐容器本身也要占用内存，整体加起来，一台16GB内存的机器到后期运行已经有些吃力了。
如果你在资源规划上本来就紧张，我的建议是优先关注两点：一是为系统增加Swap或者预留一部分内存缓冲，避免瞬时高峰把服务拖死；二是针对ELK组件做一些基础调优，比如调低Elasticsearch的JVM堆内存配置，关闭一些不常用的日志索引。这些调优措施可以在T-pot的配置目录或Docker Compose文件中进行调整。
4.3 磁盘空间暴涨：日志轮转必须提前配置
蜜罐系统是全天候开着的，攻击扫描流量从不间断。意味着日志数据是持续累积的，而且累积速度非常快。我运行了不到一周，磁盘占用就肉眼可见地大幅增长。这是因为ELK的索引数据加上各蜜罐自身的日志文件，完全不像想象中那么"小巧"。
我后来配置了日志索引的定期清理策略和日志轮转机制，确保旧数据被自动删除，磁盘空间不会被无限吃满。这里要提醒一下：如果你有长期保留数据做研究的计划，需要给日志数据单独挂载大容量存储盘，它的增长速度远比你预期得快。
5. 排错全链路：一次Dashboard访问故障的完整排查思路
5.1 从访问超时开始：我如何一步步缩小问题范围
发生了一次偶发故障后，我总结了一套完整的排查链路，整个过程如下。
当时的情况是：管理面板突然打不开，页面加载超时。我首先检查了系统里相关容器的运行状态，发现容器本身还在运行，进程没有退出。再看系统资源，CPU和内存也没有出现异常。说明问题不出在容器本身，而是出在容器对外提供服务的链路上。
接下来我从入站方向一层层排查：先看云服务器安全组的端口是否仍然放行；再查宿主机防火墙状态；然后检查Nginx反向代理容器的状态和日志。整套过程走下来，最终定位到问题跟端口映射规则有关系：宿主机防火墙规则在系统重启后没有自动加载，规则丢失导致外部流量进不来。
5.2 容器状态正常，端口却不响应：Nginx层与端口映射的关系
T-pot的管理面板和数据可视化界面，是通过Nginx反向代理对外提供服务的。Nginx容器负责把请求转发到对应的内部端口上。在这个架构里，任何一个环节出了问题，都会表现为"页面打不开"。
我这起故障，恰恰是宿主机的防火墙拦截了外部访问请求，Nginx服务本身没有任何问题，容器日志里也没有报错。这类问题最迷惑人的地方就是"容器看起来一切正常，日志也干干净净"，让你误以为是内部应用出错了。经过这次教训，我在排查类似问题时会先确认网络层，再进入应用层，顺序不能反。
5.3 恢复流程与预防措施：把被动救火变成主动防御
恢复操作其实不复杂，补上防火墙规则放行对应端口后，页面立即恢复了。真正的重点在于预防：后续我在服务器上增加了防火墙规则的持久化配置，每次重启之后规则会自动加载，不会再出现规则丢失的情况。
另外我也整理了端口清单，把管理端口、数据可视化端口、各类蜜罐监听端口分别记录了用途和防火墙状态，方便以后排查问题时快速对照。这套做法之后帮我省了不少时间，推荐你也试试。
6. 跑通之后，长期运营T-pot还需要知道的几件事
6.1 版本升级：不要盲目跟随新版本，先看兼容性说明
T-pot隔一段时间会发布新版本，修复漏洞、增加新蜜罐引擎或改进界面。别急着升级。升级前一定要先看官方发布的变更说明，确认新版本与当前宿主机系统、Docker版本是否兼容。我见过有人盲目升级后，整个ELK集群数据索引全部重建，跑了几天数据直接被清空，损失惨重。
升级前建议对配置目录和日志数据做完整快照和备份。T-pot配置文件并不复杂，但备份的事绝对不能省略。
6.2 数据备份：攻击数据和研究价值要从第一天开始保护
蜜罐系统的价值全在数据里。攻击者的手法、恶意样本的样本特征、扫描规律的变化，全都在日志和索引中沉淀。如果硬盘损坏或者误操作导致数据丢失，那损失不只是几百GB日志，可能是一整段观察周期的成果。
我的做法是：每周对Elasticsearch索引做一次快照备份到独立存储，同时保留原始日志的压缩归档。虽然这样做占一点存储空间，但拿这些空间换数据安全感，非常划算。
6.3 关于告警通知：让系统主动找人，而不是人盯系统
T-pot本身带有告警配置能力，邮件告警是目前比较推荐的方式。把告警接上之后，当有攻击事件或特殊威胁样本出现时，系统会自动发邮件通知，这才算真正从"被动看守"进入了"半自动运营"的状态。
我自己的感受是：接上告警后，终于不用每天去刷面板确认系统状态了，真正感受到了蜜罐平台的自动化价值。
7. 一些经验总结
搭建T-pot的过程确实很辛酸：从选型纠结、硬件资源不足、镜像拉取卡住、SSH端口冲突，到跑起来之后才发现磁盘暴涨、防火墙漏配，每一个环节我都吃过亏。但回过头看，这些踩坑经历恰好帮我理清了一套完整的安全运营思维。
如果你问我现在有什么想对准备搭建的人说的，我的建议是：动手前把硬件资源预算做足，把网络环境准备好，把安装过程的输出信息保存好，把日志轮转和告警机制提前配置好，然后带着宽容的心态去迎接那些"意料之中又意想不到"的问题。T-pot本身是一款好工具，它值得花时间学习，希望我的这些经验能帮你少走一段弯路，哪怕只是少一小时盯着进度条发呆，也有意义。
