鉴别流量攻击与防御姿势构建

发布时间：2021-12-29 12:58:53

本文约3100字，阅读约需8分钟。

参加过实网攻防演习的安全从业者都知道，每年防守方都会购买或者租借众多安全设备，同时在安全设备的帮助下发现攻击并阻断攻击。

安全设备会抓取客户全流量进行检测，以免遗漏攻击，并着重部署于靶标系统的出入站流量。

而用户流量是庞大的，这时候，设备的数据清洗能力就尤为重要。强大的规则库是辨别攻击的基础，但仍会不可避免地存在误报。

本文着重讲解如何识别这些流量攻击，以及如何进行规则上的防御构建，从而减少工作量并缩减误报。

1

常规攻击

设备抓取的攻击一般是什么样子呢？

一、sql注入。设备一般都会对数据库操作语句，如insert、select、update、delete、and、xor等关键字进行拦截，并且针对攻击常见编码，都会进行解码来识别攻击。如下图所示的双重url编码，包括base64等，都逃不过设备监控：

二、xss攻击。同样基于关键字script、img、alert、prompt标签符号，<>; ‘ “ () \ / 等进行拦截，不过以个人接触过的设备来说，误报也很大，具体情况各位战友可自行体验：

三、弱口令。这个问题可谓是一大毒瘤，基本无法彻底根除。特别是大公司，资产越多越是让防守方头疼。明文传输、验证码复用等情况也比较多：

四、HTTP请求中有可疑powershell命令：

五、Web命令执行：

六、Thinkphp：

七、横向端口扫描：

八、挖矿：

九、内网请求恶意域名：

十、Shiro反序列化：

十一、java反序列化：

2

串联攻击

发现攻击后，第一时间需要进行应急处置。为了协助应急溯源人员快速定位问题，需要根据设备捕捉到攻击者的发起时间、ip地址、攻击类型等因素做基础判断，找到攻击者的切入点是什么。

这时候串联攻击的能力很重要，对设备使用度也很重要。那我们应该如何串联呢？

我暂时将攻击链划分为三部分：外对内、内对内、内对外。

首先，找到攻击者入侵时间点，确认使用ip是否为真实地址，还是挂代理攻击，以及在该时间段做了哪些攻击行为。

我们来看一个具体案例。

首先根据告警，检索事件发生时间段，在早上6点47分发现大量sql注入告警：

查看报文特征,解码后内容如下：

id=-9575%'UNION ALL SELECT 29,29,29,29,29,29,29,29,29,29#

根据告警强度发现，昨晚异常告警凸起在6.20左右。在排查时，建议将告警低危级别根据告警类型快速过一遍，设备存在误报可能，需要人为去判别是否存在低危放过的情况。

此时，通过告警得知的入侵目标是“www.xxxx.com.cn”，这时直接去验证一遍最有效。

验证后发现站点不存在sql注入，但是不能百分百确认没问题。此时将告警中的ip、域名相关时间段全部提取出来，搜索IP，发现在之前就已经尝试其他攻击，但是频率不高。所以没有引起注意：

搜索该域名在该段时间是否遭受过其他类型攻击、如弱口令尝试等等。在我们确认后，发现此处攻击没有成功入侵，地址也是直接封禁了。

此时肯定有同学疑惑，为什么之前攻击没被发现，难道告警没凸起就发现不了吗？

解释一下，不是发现不了，造成这种现象原因有很多，人员疏忽、设备误报，但是最重要的是，当时设备没有部署上去，查之前的日志当然没有了。

而且有趣的是，我们在设备在近两天的时间内，发现了内网主机发起的探测存活扫描。

此时，我们将重心转移到了内网的排查，发现了对内网整个C段发起的探测：

并且关联到了来自内网对外部网络发起的异常回连，捕捉到了回连域名：

经过对回连地址的解析后，发现反连的域名解析ip竟然是外网发起攻击的IP。

排查时，这台服务机属于边界服务器，暂时没有开始大规模投放攻击，猜测攻击中应该是怕动静太大，可能是需要等待一个合适的时机。这里开始了支撑溯源的工作：

在开源情报查询后找到了最近被标记的域名，直接备案查询：

竟然是以个人名义注册的。还发现了另一个域名：

访问第二个域名得知，其旗下存在公众号，以及支付宝和微信支付码、邮箱等信息：

之后通过同账户名找到网易云账户，得知其为浙江杭州人，90后：

生日为7月3日：

这是又对第二个域名进行了历史查询解析，惊喜地发现，在16年首次注册使用的是qq邮箱：

但是qq是不完整的，此时我天真的以为，只有前两位不知道，枚举下来也就99个，不多。

但是结果确实没搜到，有点烦躁——眼看着已经找到人了。

冷静后想了想，qq肯定是存在的，也有可能是注销了，只能碰运气。随后开始了加位数的枚举。加到3位，4位，终于找到了这个大哥的qq，没白费功夫：

虽然空间进不去，但是得知其本人曾在云南大学就读：

利用各大厂商找回密码功能，基本确认手机号为182xxxxx104，枚举结果就不放了：

最后打包信息提交给了客户。

此次溯源，成功通过设备发现了异常凸起告警，根据告警特征判断未攻击成功。

为了以防万一，根据相关时间段排查内网告警时，在内网发现了异常的回连告警，回连地址解析后发现了相同的ip，并且找到了其他注册域名。

通过信息收集，发现了qq、微信、电话、姓名等等相关信息。

这次案例是通过一次完整的告警信息成功的捕捉到了攻击者，从外部到内部、内部到外部的攻击动作，抓到了攻击者。

这里不得不说一下低危放过的告警，案例中没有直接发现回连可能是因为规则没有更新，或者特征被擦除掉了，因为告警信息并不明显，所以排查时间被拉长。

3

规则构建

说完了案例，那我们该如何帮助用户去完善那些不完整的地方呢？

此处将防御重点放置于基于流量规则的精细化，基于攻击来源、协议、特征、时间、频率、中间件、端口、服务等等，此处总结了一点规则构建的方法论，可能不够全面，欢迎补充：

相信同学们认真看完脑图后，对规则的构建起码有了一个轮廓。此处同样举例一个基于360自身设备构建的相关场景规则。

有同学可能会问，为什么构建这条规则，规则有什么作用。

解释一下，下面的案例目的是提升告警命中率，在低危告警中找到真实的攻击。最好出来告警，就可以确认在外部系统中，这个功能点是不是真的有漏洞，并且还是企业内部日常管理应用中不注重的点，是真切需要企业去排查的问题。如果规则准确率达到90%，那这就是一条不可忽视的规则。

首先我们要评估场景。

场景名称：多台外部主机对同一个网站发起攻击；

条件：1.外网主机；2.多个攻击源；3.同一目标；4.数据源日志。

接下来制定规则。

1.判断内外网条件：

内网：源地址belong内网IP

外网：not源地址belong 内网ip

2.添加多个攻击源，如：源地址>3；

3.指定目的地址：目的地址=1；

4.找到数据源数据：数据源="xxx"；告警级别="低危"。

再查验字段：

找到我们规则中所需要字段，如网段信息、数据源、告警级别等等：

数据源="360_AISA"  and 原始级别="low" and 状态="1"：

然后布置规则。

再确认所需字段后，布置测试上线：

最后进行实用测试：

在规则上，我们总要不断调优，擦除特征这种方式是最直接有效的。

发现一类攻击在user-agent中带有公司标识，是某类业务发起的正常操作，直接将ua头通过匹配方式not掉。

设备也是提供了通过跑一些历史数据或者实时数据测试误报率，经过几轮调优来提升规则准确率，还是比较友好。

这里提示一下，各位同学在查找攻击来源时，要注意XFF是否存在。

4

总结

此处演示仅提供思路，方便各位同学可以在海量数据调优的过程中，更快更精准地找到攻击并通过自己的攻击串联思路找到攻击者，谨以此文，献给曾经熬夜坚守在安全设备前的安服战友们。

- END -

往期推荐

记一次卑微的渗透测试

pwn入门之栈入门

MYSQL另类利用方式

长按下方图片即可关注

点击下方阅读原文，加入社群，读者作者无障碍交流

查看原文