提前声明：本文不说打穿蜜罐的那些破事，哈哈哈，失望了？没有？
众所周知，搞安全的都喜欢部署蜜罐系统/钓鱼系统，一般是丢在内网玩。除非是有实力，而且是非常有一腚实力的才敢放外网，不然呢？大家都看到xxx被爆菊了吧，哈哈哈～
所以，传统安全领域里说的蜜罐，咱就不说了，讲个不太一样的用法。
这个其实是个旧事，距今大概10几年了。那时候高草还在邮箱部门搬砖，重头构建新的安全体系。说重头做，其实都是被逼的，全TMD是被逼的，原系统基本没啥架构可言，破腚百出...
当时花了好几天时间，做了个半年计划，写完了自己看着PPT总觉得缺点啥，总感觉有一个环节没打通。
当时的情况是，每天铺天盖地乱飞的垃圾、钓鱼、欺诈、木马邮件都有个特别明显的特点：量大，重复的多。缺失的一环就应该是怎么自动化把这些破烂收起来，归纳总结，用算法（当时不流行说AI、深度、神经病算法这些）分析分析。
这事苦恼了好久也不知道怎么搞，索性静下心来人肉分析样本。于是，从系统各个环节采集样本，大概有几百万的规模。等都看完，问题有答案了，办法自己就来了，你说神奇不神奇！
咱直接在前面协议交互时，从HELO开始，就把那些发送给不存在人的邮件都收下来。在正常的协议交互里，自然是会告诉你这个账户不存在或者系统错误，然后byebye断开连接。这里可以做点手脚，另外找个地方继续往下走，邮件体咱都存下来，然后内容+行为分析下不就行了!
嗯，当然为了增加点迷惑性，还得加个随机，一会账号存在，一会账号不存在。
这个做法开发量非常少，很快就能上线，内容行为归纳总结的模块基本都是现成的，怼进去就行，把发现的异常样本按照出现数量排个序，定期更新，ban就是了，都不用担心会存在误判。于是，每天80%-90%的垃圾就这样被搞定了，哈哈哈～
为了方便非邮件系统圈子内读者的理解，这里稍微解释一下。逻辑是这样的，正常的邮件系统肯定是知道准确的收件人地址，手误写错地址的情况有，但是绝对不会在数量上占优。反而限于当时的邮件地址泄漏规模的大环境，黑产灰产还是采用基于字典广度覆盖的方式比较多。所以，在系统侧会发现，每天都有数目庞大的不存在地址探测。只是，正常情况下，这部分请求走到收件人地址检查这里就会告诉你“该用户不在服务区”，然后断开了，不会往下面流程走。
咱既然是要做个蜜罐，理论上100%都采集下来也问题不大，当然大系统就不推荐这么干，浪费资源不说，你这系统咋啥地址能收到呢？对方一眼就能发现问题，所以，设置一个不大不小的概率肯定是必须的。
至于存下来后面接的东西，无论是交互行为分析，还是内容分析，都不是什么难事，直接略过。
这套蜜罐直接对外网服务，按道理是不妥的，要解析内容就会遇到很多未知风险，如果给开了shell那就更sb了不是。所以，进入到后期分析之前，还是要做一些必要的过滤处理的，该丢的先都丢掉，也就是只解析一些我们感兴趣的东西，一般只要包括文字、图片、JS就行了。但是，JS不要解析不要解析不要解析！
说到图片，必须多讲几句，图片的处理库当年还不是那么多，开源的就几个，也不是很好用，都有一些大大小小的兼容性问题，core掉还不是大问题，单是溢出开shell都已经有很多了。咋办？完全重写肯定不现实，所以高草当时做了一件几乎不被开发理解的事情：把几种主要格式的处理库都剪裁出来了，重新包装了一遍，第一层必须是对buffer做限制性复制，然后才丢给相应的解析库处理。格式也不多，干起来也不难，BMP，JPEG，GIF...也就那么几种格式，很好搞。
至于剪裁解析库这个事，其实不需要过多解释，搜一下过去几年的开源图片处理库漏洞，比如imagemagick库给人家弄出来多少远程shell，你就知道那时候我在担心啥了。反正该做的都尽量做好，剩下的就是更衣沐浴抽根烟上线。
故事讲完了，这里说的这个蜜罐系统的做法，只是想说一句蜜罐其实也可以这么玩。不必纠结，蜜罐是好东西，小心用就是了，哈哈哈～
谨以此图，献给对蜜罐又爱又恨的朋友～
