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


本文约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另类利用方式

长按下方图片即可关注

点击下方阅读原文,加入社群,读者作者无障碍交流
免责声明:文章内容不代表本站立场,本站不对其内容的真实性、完整性、准确性给予任何担保、暗示和承诺,仅供读者参考,文章版权归原作者所有。如本文内容影响到您的合法权益(内容、图片等),请及时联系本站,我们会及时删除处理。查看原文

为您推荐