欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

SYN flood+带宽消耗混合式DOS攻击一例

作者:易隐者 发布于:2014-4-11 21:02 Friday 分类:网络安全

       一用户新系统上线前,发现流量存在异常,利用wireshark抓包后,查看summary视图,发现其每秒近4000个包,平均包长991字节,如下图所示:
 点击查看原图
      我们在通过coversations视图查看其连接情况,发现IP连接会话中,源主机向113.105.171.88、121.12.110.60、121.12.110.61等3个IP交互的报文数远远大于其他IP的,如下图所示:
点击查看原图
       我们再查看TCP会话,发现交互特征明显,都是发送一个长度为1024字节的报文,如下图所示:
 点击查看原图
      我们回到数据包视图:
 点击查看原图
      看上去基本上都是SYN报文,但是常规的SYN报文一般只有64字节,无应用层数据,而这里其显示存在970字节的应用层数据,这明显是不合常理。
      我们查看这些数据包的具体解码,如下图所示:
点击查看原图
       发现其长度为970字节的应用层数据全部是“0”填充的。
 点击查看原图

        综 合上述分析,基本可判断为黑客利用被拿下的机器,对固定主机发送包含以“0”填充的、长度为970字节的应用数据的SYN Flood攻击报文,在对服务器造成SYNflood攻击效果之外,还会给被攻击主机的互联网出口带宽资源带来较大的消耗,到达综合的拒绝服务攻击效果。

       常规DOS攻击手段以前遇到和处理的蛮多,但这种较为聪明和更有效率的混合式DOS攻击方式在实际工作过程中较为少见,是以记之,供各位兄弟姐妹参考。

阅读全文>>

标签: wireshark DOS DOS攻击 SYN flood 混合式DOS攻击 带宽消耗

评论(0) 引用(0) 浏览(94121)

PSH|RST同置位,系统应用共沉寂!

作者:易隐者 发布于:2014-2-7 14:34 Friday 分类:案例讨论

       年前一位技术兄弟维护的站点遇到异常流量,导致无法正常访问站点。其将捕获到的报文发给我,让我帮其分析一下大致是什么情况。年前杂事较多,未来得及写分析文档,年后将未完成的部分补充完全,放在此供各位兄弟讨论。

       我首先查看其TCP会话数较多(8500多个),而且大部分的TCP会话是219.140.167.122与X.X.254.18之间产生的,并且这些会话具有较为明显的流量特征,如下图所示: 

点击查看原图

       我们在报文 中任意查看其中一个TCP会话的交互报文,如下图: 

点击查看原图

       我们可以发现,其在完成三次握手之后,219.140.167.122主机与X.X.254.18发起了一个PSH、RST同时置一的报文,如下图:

点击查看原图

       这个报文的解码和follow TCP Stream显示其为一个http  get请求报文,如下: 

点击查看原图

       将其解码,如下: 

点击查看原图

        可见这是一个针对站点某个pdf文档进行访问的操作。

点击查看原图

        在这个TCP交互过程中,我们可发现服务器在收到这个PSH、RST位同时置一的get请求之后,并没有立即RST释放这个TCP连接,而是在72秒之后,服务器才向客户端发送RST报文释放该TCP连接。

        一般情况下,在收到RST报文之后,系统传输层会立即释放对应的TCP连接,为什么要等到72秒之后才发送RST报文呢?TCP协议栈在收到PSH,RST位同时置一的报文时,应该如何处理??

       Google百度均未找到相关的说明资料。

       我们不妨自己先大胆推测一下服务器在收到PSH、RST位同时置一的报文时时如何处理。
三种假设:
1,如果服务器先处理RST位,则服务器端会立即释放相关的TCP连接表信息。PSH位置一应该会失去应有的意义,传输层不会将客户端的应用字段递交给应用层处理。
2,如果服务器先处理PSH位,后处理RST位,则服务器将get请求提交应用层之后,释放TCP连接。服务器及时向应用层在处理完客户端的get请求之后,应用层向传输层提交应用层响应数据,这时,会发现在服务器传输层已有的TCP连接表信息中找不到对应的TCP连接,传输层向应用层报错,应用层放弃。
3,如果服务器先处理PSH位,忽略RST位,则服务器会将应用层的响应字段正常发送给客户端。

       我们再来仔细的看看上述报文交互的情况:

点击查看原图

       我们可以发现,服务器在72秒之后向客户端发送的RST报文其ACK位是置一的,ACK相对确认号是1,这说明这个RST报文发送出来的时候,服务器端的TCP连接表信息是正常的,并且传输层并未处理PSH、RST位置一的报文,否则ACK相对确认号应该是805而不是我们看到的1。

        我们再来看一下这个服务器发送的RST报文的解码,如下图所示: 

点击查看原图


        该报文TTL=64,可说明两点:

1,这个报文的确是服务器发送的,不会是第三方进行TCP会话劫持伪造发送的;

2,这个服务器可能是linux的服务器。

       上面的这些说明了什么呢?

       我个人认为,造成上述情况出现的原因是服务器过滤了RST位置一的报文!

       服务器要做到对TCP标识位进行过滤并不是一件难事,iptables就可以。iptables如下命令即可实现对RST位置一报文的过滤:
  iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP

       服务器过滤了PSH/RST位置一的报文,它不管PSH是否置一,因此那个客户端发送给服务器的PSH/RST位置一的http get报文并未被服务器传输层收到,服务器传输层在等待了72秒未收到客户端的任何请求之后,主动RST释放了这个TCP连接。

       这些流量特征一致的TCP会话基本都是一样的,在三次握手建立TCP连接之后,向服务器发送PSH、RST位同时置一的http get请求报文,如下图所示:  

点击查看原图

       客户端短时间内大量的这种报文,导致服务器的连接表骤增而在一定时间内难以释放,从而给服务器造成了DOS攻击的效果。

阅读全文>>

标签: TCP RST TTL get push DOS攻击 连接表 异常流量 HTTP PSH RST过滤 iptables PSH/RST位同时置一

评论(4) 引用(0) 浏览(107564)

基于UDP 7000端口的DOS攻击案例

作者:易隐者 发布于:2012-9-24 11:12 Monday 分类:网络安全

       在某某用户现场捕获到基于UDP 7000端口实施DOS攻击的报文。

我们简单的看一下大致的分析过程:

1,通过对报文的统计,我们可以看出流量较大,平均包长1266.6字节,大包居多: 

点击查看原图

2,我们查看数据包交互情况,发现基本上都是192.168.218.112的5444端口发往121.10.173.106的UDP 7000端口的报文,这些报文大小都是1070字节,IP标识逐步递增,在15秒的时间内发送了12192个UDP报文: 

点击查看原图

3,我们查看其UDP封装的应用字段,发现全部为“AAAAAAAAAAA”的无意义填充数据: 

点击查看原图

小结:
       无论是基于什么端口的,大部分的基于UDP的攻击都是利用UDP无连接的特性,向被攻击者发送大流量的垃圾报文,导致被攻击者的网络带宽资源被占用,造成拒绝服务的攻击效果,这个案例当然也不例外。 

阅读全文>>

标签: UDP 拒绝服务攻击 DOS DOS攻击 UDP 7000端口

评论(0) 引用(0) 浏览(52371)

基于UDP 80端口的DOS攻击案例

作者:易隐者 发布于:2012-9-10 17:16 Monday 分类:网络安全

       在某用户实际环境下,捕获了交互的报文,在“UDP会话”中,我们发现了大量的UDP 80端口的UDP会话,如下图所示:

点击查看原图

       这些UDP会话都是来自于同一个源主机,目的主机IP也是固定的,并且交互的报文都是单向的。

       我们随便找了几个UDP会话,通过UDP会话重组功能,我们可以发现,其发送的都是明显填充的字段,如下图所示:

点击查看原图

点击查看原图

       以此判断为基于UDP 80端口的DOS攻击行为无疑。

      黑客这样做主要考虑两点:

1, 利用UDP无连接特性,发送大量UDP大包,消耗攻击目标的网络带宽资源,造成DOS攻击效果;

2, UDP 80端口被过滤的可能性更小;

      TCP 80端口为最为常见的HTTP应用,基本上,绝大部分的运营商、用户都会放行TCP 80端口的报文,而其他不常见的端口则很可能被运营商、用户的安全设备、ACL过滤,而利用UDP 80 端口实施该攻击,则主要利用很多网络管理员在制定安全防护过滤策略时的不严谨性,很多人图省事,在制定相关策略时,只选择放行80端口,而不选择TCP协议或UDP协议,这样默认情况下,设备会放行TCP 80端口和UDP 80端口。这就给黑客提供的可乘之机。

阅读全文>>

标签: UDP DOS 80端口 DOS攻击 UDP 80 拒绝服务

评论(0) 引用(0) 浏览(177418)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1