安全事件运营SOP：蜜罐告警

在开篇《安全事件运营SOP【1】安全事件概述》中，介绍了安全事件的定义、分级、处置原则及处置流程。当发生某类安全事件时，该如何快速处置？以及如何保证不同人员处置的效果都达标？安全事件的种类虽然繁多，但是处理起来并非无据可循。为了解决上述两个问题，同时提升工作效率和降低安全风险。经过大量的运营处置实践，总结出以下常见的处置标准操作程序（SOP）。

本文将从基础概念、运营处置和反向攻击三个维度，对蜜罐应用和告警事件运营SOP进行阐述。由于作者所处平台及个人视野有限，总结出的SOP虽然经过大量重复的操作、总结及提炼，但仍会存在错误或不足，请读者同行们不吝赐教，这也是分享该系列实践的初衷。

01

—

蜜罐基础概念

1.1 什么是蜜罐

一种广泛用于企业安全建设中的入侵检测/威胁诱捕技术，从使用的角度来看，其实就是一个具备告警功能、甚至反制能力的陷阱。在不对称的攻防环境中，相对主动的帮助防守方发现攻击。蜜罐可以针对攻击的攻击行为进行告警，一碰就报告；蜜罐可以伪装为攻击者感兴趣的目标（数据/服务/系统），吸引攻击者去触碰；蜜罐还可以藏着攻击武器，在攻击者连接之后，索要他的身份信息或进行攻击…

1.2 有哪些蜜罐

通常会按照交互程度分为低交互和高交互，交互程度越高、诱骗攻击者越深入，越有可能获取更多攻击者的信息。但仅从攻击检测来说，低交互的蜜罐足以使用，按功能可分为：

• 数据蜜罐：又叫面包屑，包括蜜数据、蜜文件、蜜邮件…洒落在内外网的各个角落，均是攻击者信息收集时关注的数据或文件，比如在GitHub上传存在敏感蜜数据的代码、在内网服务器上存储蜜数据…引导攻击者访问蜜环境；

• 服务蜜罐：对外开放22、23、3389等可能存在风险的高危端口及服务，部署在业务系统周边及全局设计部署在各网段，一触碰就产生告警，常见的工具或蜜罐系统有opencanary（具备web控制台进行管理）、HFish、Kippo、MHN、T-POT等；

• 业务蜜罐：伪装为业务系统（业务系统克隆），或业务系统的一个不常碰到的功能点，混淆攻击者的视听并起到告警作用。初级水平，常用setoolkit等工具进行目标系统静态资源提取，提取之后仍需修改网站源代码才能跑通；更高一点的水平已经实现流量重放，根据攻击者的请求重放API的response，包括对一些攻击行为的响应。

1.3 蜜罐的应用

在重要系统旁部署蜜罐、在各内网网段部署蜜罐、在互联网上部署蜜罐（尤其需要注意安全性，单独规划蜜罐网段，在网络层进行隔离，避免“引狼入室”），总之就是大范围部署上线、下线、卸载、测试、数据备份及恢复等对蜜罐的管理动作，故需统一管控平台进行日常运营。在整个过程中，至少需要考虑：

• 蜜罐的多样性：各类低交互的蜜罐（业务蜜罐&服务蜜罐），如oa、crm等攻击队关注的系统应该要有，ssh、rdp、tomcat等系统及应用服务也需要覆盖，保持足够多的种类，可增加发现攻击的可能性；

• 蜜罐的存活率：在管理平台设计时，加入对蜜罐存活的判断，定时去探活。解决蜜罐部署很多，但面对攻击行为时不能告警的窘境。

02

—

安全运营SOP

蜜罐告警的场景比较简单，即：一碰就响。在实际运营工作中，会遇到误报、不能直接找到源地址等问题。在介绍sop前，对误报原因进行了总结与分析，主要有以下四类：

• 系统误报：蜜罐管理系统出现问题，导致没有触碰蜜罐时，也产生告警；
• 正常行为：用户在访问目标系统时输入错误、同网段Windows主机发现等可能会产生访问记录导致告警；
• 违规行为：违反安全红线的行为可能产生告警，如业务方测试时，超范围漏洞扫描碰到蜜罐；
• 安全事件：指攻击者在进行信息搜集、探测时触发的告警，也是蜜罐告警最主要关注和分析的类型。

2.1 找出攻击源

收到告警时，获得的Sip可能并不是真实的，有的是NAT或LVS的地址。此时就需要使用相关流量、日志、CMDB平台等进行查询，找到真实的Sip。

2.2 确定责任人

通过资产管理平台（cmdb/scmdb），查询Sip的资产owner，包括归属人、运维人、安全责任人等。

2.3 判断告警场景

联系归属人（如果无归属人，则依次询问运维人、安全责任人）沟通Sip访问蜜罐的原因，以支撑接下来的处置动作。

2.4 执行处置动作

若是正常行为，则close告警；

若是员工扫描行为，则根据是否报备等实际情况进行处理；

若是系统误报，则通知干系人排错修复；

若确认是安全事件，则立即开始应急响应流程。

2.5 SOP流程图

2.1 – 2.4描述的内容，如下图所示：

03

—

蜜罐其他玩法

前面章节的主要聚焦在入侵告警及处置，针对一个蜜罐收到告警、多个蜜罐收到告警聚合，均可以参照上述SOP进行处置，并且可部分实现（半）自动化。但蜜罐的应用已经不局限于被动的检测，更多的技术已经被应用到蜜罐上，实现了多元化的输出：

3.1 捕获0day漏洞

多用在互联侧进行大规模、工程化部署，以增加捕获0day漏洞攻击的可能性。这里提到的是可能性，说明实战场景中在该方面的收益并不大，也不适合于大多数公司。不过随着攻击识别和流量牵引技术的发展，在内网为攻击者准备一套特定的环境，已有可能让攻击者进入并引导其使用0day。

3.2 识别攻击者身份

在业务系统前端页面嵌入js脚本，获取攻击者社交账号信息，通过社工库碰撞出或工具指纹识别出攻击者身份。但这招需要储备存在敏感信息的API、需要攻击者登录过API所属网站并保持会话有效。

在国家级攻防演习活动中，防守队仅靠守住已经不能拿到很好的名次，需要溯源加分。面对经验丰富的攻击队员，这招大概率不生效，但谁又能保障他们每次都头脑清醒以及每个人都是高手呢？

3.3 反向控制攻击者

通过蜜罐引诱攻击者，在其不知情或不知情的情况下，控制其终端。通常可以利用已知漏洞进行攻击，最为常见的有：

• 浏览器：业务系统页面嵌入BeEF（浏览器攻击框架，The Browser Exploitation Framework Project）攻击代码，反向控制攻击者浏览器甚至拿到权限；

• MySQL反制：通过伪造MySQL报文来模拟服务；从客户端（攻击者终端）读取文件，可参照https://github.com/qigpig/MysqlHoneypot；

• 反向RDP攻击：利用CVE-2018-20179、CVE 2018-20181、CVE 2018-8795等漏洞对rdesktop等软件进行攻击；

• 伪造恶意程序：通过假装咬钩钓鱼邮件，将对方引入蜜网，散播存有后门的虚假敏感文件反击攻击者，如office文档木马、winrar压缩包等。

3.4 在攻防演习中应用

利用攻击者拿到终端据点后进行本地信息收集的招式，在员工终端存放蜜文件，引导攻击者去访问蜜系统，如：桌面上存放password.txt文件；内部IM聊天记录中收藏蜜环境地址与账密；浏览器中保存蜜环境域账密等。

原文始发于微信公众号（我的安全视界观）：安全事件运营SOP：蜜罐告警