安全矩阵

 找回密码
 立即注册
搜索
查看: 786|回复: 0

常见攻击及防御技术详解——骨灰篇

[复制链接]

215

主题

215

帖子

701

积分

高级会员

Rank: 4

积分
701
发表于 2023-9-5 16:01:50 | 显示全部楼层 |阅读模式

DNS Query Flood攻击

2.1 攻击原理

攻击者向被攻击的服务器发送大量的域名解析请求,通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名,被攻击的DNS 服务器在接收到这些域名解析请求的时候首先会在服务器上查找是否有对应的缓存,如果查找不到并且该域名无法直接由服务器解析的时候,DNS 服务器会向其上层DNS服务器递归查询域名信息。域名解析的过程给服务器带来了很大的负载,每秒钟域名解析请求超过一定的数量就会造成DNS服务器解析域名超时并瘫痪。2.2 防御原理

常用手段是源认证,其防御模型可简化为:1)防御侧收到DNS Query报文后,回复一个TC置位的DNS Reply报文,以此要求客户端使用TCP方式重新发起DNS查询;2)如果DNS Query报文源IP是虚假源,则不会收到步骤1)的DNS-Reply报文,也就不会做出任何响应;3)如果DNS Query报文源IP是真实源,则会重新发送SYN报文,请求建立三次握手,在这一阶段可以借助上期讲到的SYN Flood防御手段的源认证方式,认证通过则将该源IP加入白名单;4)后续报文直接放行,客户端与服务器之间建立TCP连接,并以TCP方式完成DNS查询。另一种是首包丢弃思想,其防御模型可简化为:1)防御侧收到DNS Query报文后,提取相关字段信息计算HASH并丢弃该查询报文; 2)如果DNS Query报文源IP是虚假源,则一般不会对丢弃报文进行重传,并且攻击报文发包速率很高、时间间隔远小于重传时间间隔要求;3)防御侧在允许的重传时间间隔内,再次收到与步骤1)计算HASH相同的DNS Query报文时则认为是重传报文,通过并将该源IP加入白名单,后续报文直接放行。
DNS Reply Flood攻击

3.1 攻击原理

DNS缓存服务器向DNS授权服务器发起查询动作后,会收到授权服务器返回的DNS Reply报文,并从中解析出DNS对应关系,提供给发起查询的用户。不过,由于这个查询过程通常基于UDP协议,DNS缓存服务器收到DNS Reply报文时,不会去检查这个回应信息是否是自己发起的,攻击者发出大量的Reply报文,导致DNS缓存服务器资源耗尽,无法响应其他正常的查询请求。3.2 防御原理

DNS Reply Flood防御的基本思想还是源认证,其防御模型可简化为:1)防御侧收到DNS Reply 报文后,提取相关字段计算HASH并主动发送一个目的IP为DNS Reply报文源IP(除此之外,还有会UDP源端口号、DNS Query ID信息,用于后续验证环节)的DNS Query报文,主动探测一下该源IP是否真实存在;2)如果是虚假源IP则收不到该DNS Query报文,也就不会做出任何响应;3)如果是真实源IP则会回复一个DNS Reply报文;4)防御侧收到DNS Reply报文,再次提取相关字段计算HASH并进行比对,若比对通过则丢弃该DNS Reply、并将该源IP加入白名单后续访问直接放行,若比对不通过则直接丢弃该DNS Reply报文。除此之外,还有近几年盛行的DNS反射攻击,作为是DNS Reply Flood的变种和升级,其攻击源都是真实存在的。在这种情况下,源认证方案则不再适用,可以参照TCP SYN-ACK状态检测防御思想,防御侧收到DNS Reply报文后检查会话表项,若查到则放行、若查不到则丢弃。需要注意的是这种模式也只适用于串接部署来回路径一致的场景,即保证DNS Query和DNS Reply报文都会经过防御设备。
HTTP Flood攻击

4.1 攻击原理

攻击者利用攻击工具或者操纵僵尸主机,向目标服务器发起大量的HTTP GET/ HTTP POST报文,请求服务器上涉及数据库操作的URI或其它消耗系统资源的URI,造成服务器资源耗尽,无法响应正常请求。4.2 防御原理

HTTP Flood防御思想就是源认证,根据认证方式不同通常可分为重定向验证和验证码验证两种思路。对于重定向防御模型可简化为:1)防御侧收到HTTP GET/HTTP POST报文,提取相关字段计算HASH并作出响应,给客户端返回一个新的URI;2)常见的HTTP GET报文回应302状态码重定向,HTTP POST报文回应307状态码重定向;3)如果是虚假源IP则收不到该重定向报文,也就不会做出任何响应,或者即便收到重定向报文也不会做出任何响应;4)如果是真实源IP则根据重定向报文,向新的URI发起HTTP GET/HTTP POST请求;5)防御侧收到新的请求报文,再次提取相关字段计算HASH进行比对,若通过则将该IP加入白名单后续报文直接放行,若不通过则直接丢弃;这一步处理中可以是RST中断掉该连接,也可以是再次重定向到最开始的URI上。对于验证码防御模型,主要区别在于防御侧不是回复重定向报文了,而是直接给客户端回复一个验证码页面,对于虚假源或者僵尸主机不会有人机交互动作,自然无法通过认证。而真实的浏览器行为则会人工输入验证码,完成认证。
HTTP 慢速攻击

5.1 攻击原理

HTTP慢速攻击是利用HTTP协议的正常交互机制,先与目标服务器建立一个连接,然后长时间保持该连接不释放。如果攻击者持续与目标服务器建立这样的连接,就会使目标服务器上的可用资源耗尽,无法提供正常服务。HTTP慢速攻击主要包括针对HTTP请求报文头部结束符的Slow Headers攻击,以及针对POST请求报文数据长度的Slow Post。Slow Headers:攻击者通过GET或者POST向服务器建立连接,但是HTTP头字段不发送结束符,之后发送其他字段进行保活。服务器会一直等待头信息中结束符而导致连接始终被占用。Slow Post:攻击者发送Post报文向服务器请求提交数据,将总报文长度设置为一个很大的数值,但是在随后的数据发送中,每次只发送很小的报文,这样导致服务器端一直等待攻击者发送数据。5.2 防御原理

通过上述攻击原理介绍,HTTP慢速攻击行为的特征都是比较明显的。对于Slow Headers防御思路为:防御侧检查HTTP报文头,若发现某个源发出的连续多个HTTP GET/POST请求报文的报文头中都没有结束符“\r\n”,则认为发生Slow Headers攻击,将该源IP地址加入黑名单。对于Slow Post防御思路为:防御侧检查HTTP报文头,若发现某个源发出的连续多个HTTP POST请求报文的长度设置的很大,但是实际报文的数据部分长度都很小,则认为发生Slow Post攻击,将该源IP地址加入黑名单。
结语

至此,《常见攻击及防御技术详解》系列内容全部结束,欢迎小伙伴多多留言,有更多攻防知识也可随时交流!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|安全矩阵

GMT+8, 2024-11-28 11:33 , Processed in 0.017072 second(s), 18 queries .

Powered by Discuz! X4.0

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表