SYN flood+带宽消耗混合式DOS攻击一例
作者：易隐者 发布于：2014-4-11 21:02 Friday 分类：网络安全
一用户新系统上线前，发现流量存在异常，利用wireshark抓包后，查看summary视图，发现其每秒近4000个包，平均包长991字节，如下图所示：
我们查看这些数据包的具体解码，如下图所示：
综 合上述分析，基本可判断为黑客利用被拿下的机器，对固定主机发送包含以“0”填充的、长度为970字节的应用数据的SYN Flood攻击报文，在对服务器造成SYNflood攻击效果之外，还会给被攻击主机的互联网出口带宽资源带来较大的消耗，到达综合的拒绝服务攻击效果。
常规DOS攻击手段以前遇到和处理的蛮多，但这种较为聪明和更有效率的混合式DOS攻击方式在实际工作过程中较为少见，是以记之，供各位兄弟姐妹参考。标签: wireshark DOS DOS攻击 SYN flood 混合式DOS攻击 带宽消耗
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位同时置一
基于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端口
基于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端口。这就给黑客提供的可乘之机。
-
QQ邮箱订阅
-
搜索
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情，那么往往只能一个人独自去做"——理查德·耶茨
2019-06-25 21:34
- 日后我们知道，真正的人生道路是由内心决定的。不论我们的道路看上去如此曲折、如此荒谬地背离我们的愿望，它终归还是把我们引到我们看不见的目的地。（茨威格《昨日世界》）
2019-03-16 21:27
- 如果你渴望得到某样东西，你得让它自由，如果它回到你身边，它就是属于你的，如果它不会回来，你就从未拥有过它。——大仲马《基督山伯爵》
2018-10-09 22:07
- 人生有两大悲剧：一个是没有得到你心爱的东西；另一个是得到了你心爱的东西。人生有两大快乐：一个是没有得到你心爱的东西，于是可以寻求和创造；另一个是得到了你心爱的东西，于是可以去品味和体验。——弗洛伊德
2018-09-25 18:06
- 一个人越有思想，发现有个性的人就越多。普通人是看不出人与人之间的差别的——布莱兹·帕斯卡尔
2018-08-30 18:44
存档
- 2020年11月(2)
- 2018年1月(1)
- 2017年12月(1)
- 2017年11月(6)
- 2017年6月(1)
- 2017年5月(1)
- 2017年4月(1)
- 2017年3月(1)
- 2016年11月(1)
- 2016年4月(1)
- 2015年7月(2)
- 2015年6月(1)
- 2015年5月(5)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(1)
- 2014年4月(3)
- 2014年2月(2)
- 2014年1月(2)
- 2013年12月(1)
- 2013年11月(1)
- 2013年10月(2)
- 2013年9月(1)
- 2013年8月(1)
- 2013年7月(3)
- 2013年6月(2)
- 2013年5月(1)
- 2013年4月(3)
- 2013年3月(1)
- 2013年2月(2)
- 2013年1月(2)
- 2012年12月(11)
- 2012年11月(12)
- 2012年10月(12)
- 2012年9月(26)
- 2012年8月(29)
- 2012年7月(18)
- 2012年6月(2)
- 2012年5月(25)
- 2012年4月(16)
- 2012年3月(13)
- 2012年2月(6)
标签
blogger
