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位同时置一
异常流量分析方法——发现-定位-管控
作者:易隐者 发布于:2012-11-8 21:50 Thursday 分类:网络分析
我们在实际工作环境中遇到各种影响网络系统和业务正常运行的异常流量的概率远远高于遇到疑难故障的概率,在我的博客里已经将疑难杂症的分析方法和思路做了非常深入的阐述(大家可参考《疑难故障分析常规流程和思路》、《疑难网络故障的分析方法和原理之关联分析法》、《疑难网络故障的分析方法和原理之对比分析法》等文),并且我为此撰写了大量的疑难故障的实际分析和解决的案例,我在《疑难故障分析常规流程和思路》一文中,仅仅简单的提到“全局捕包确认异常类型和源头”等寥寥数字,这并不是我疏忽,而是当这些异常流量足以对网络和业务应用产生较为严重影响的时候,其在流量的特性上往往具有较为明显的特征,因此站在网络分析技术的角度,我认为针对这些异常流量的分析是一件非常简单的事情,只要通过简单几个分析步骤和流程,即可快速的定位。但是这些看似简单的方法和流程,对于一些不了解网络分析技术或网络分析初学者来说,却是一件令人头疼的事情,我曾在工作中数次遇到朋友问我:为什么不把这些最常遇到的异常流量问题的分析方法和思路,简单明了的写出来,以助初学者快速入手呢?
我想的确有道理,把这些东西写出来,让更多的朋友能够利用我写的分析方法和思路解决实际工作过程中遇到的问题,岂不是一件快事?但是考虑到高彦刚老师在其《实用网络流量分析技术》一书中,已经对蠕虫、P2P、环路、ARP病毒等常见异常流量的分析案例做了专业的介绍,在此我将不再将高老师已经做过的、非常优秀的事情再做一遍,我主要将异常流量分析的方法和思路总结为一个简单易懂的、通用的分析流程。据此流程,你可以快速的分析定位大部分的异常流量。
该方法并不局限于任何一款具体的网络分析产品和工具,只要你熟练掌握某一种网络分析工具(wireshark、omnipeek、科来或其他),都可以按照这个分析方法,快速的分析定位大部分的异常流量。
什么是异常流量
严格的来讲,正常业务流量之外的流量,都应该归类为异常流量的范畴。但是,除了在工业控制系统等生产网络环境中,可以这样定义异常流量之外,其他的办公网络环境如此严格的定义异常流量都是不合适的。因为在普通的办公网环境下很难保证网内交互的都是业务流量。
在办公网络环境下,办公端系统的应用和管理是非常丰富和复杂的,我们难以做到让每个办公终端在固定的时间内只运行某些固定的业务系统,相反,这些办公终端会根据不同的使用者特性和个人偏好,在不同的时段运行的大量的应用进程,这些进程中可能包含正常的办公应用的进程,也可能包含大量依托于互联网的非业务应用进程,甚至可能包含使用者自己都不知道的第三方插件、木马、病毒等进程。因此,我们还需要定义一个应用更为广泛的狭义上的异常流量。
狭义范畴上的异常流量主要指:病毒、蠕虫、木马、垃圾应用(P2P下载/在线视频/在线游戏等)、攻击(各种DOS攻击流量)等影响网络和业务正常运行的流量。
如此一来,我们便明确了我们需要分析的对象了,如果你是一个初学者,这样是不是感觉更具体一点?是不是有种找到靶心的感觉,哈哈。话不多说,还是跟我一起来开启这趟分析之旅吧。
异常流量分析方法和思路
按照我个人的经验,我将异常流量的分析方法归纳为三大步骤和五个过程,分别为
发现-定位-管控三大步骤和Whether-Who-What -Where-How五个过程。如下图所示:
发现-定位-管控三大步骤
Whether-Who-What -Where-How五个过程
发现-定位-管控三大步骤:
定位(Location):通过分析定位出异常流量的根源、类型、运作模式以及具体的主机位置,为下一步的管控提供全面的信息。
管控(Control):利用现有资源,及时实现对异常流量的管理和控制,消除异常流量对网络和业务正常运转的影响。
Whether-Who-What -Where-How五个过程:
Whether:通过分析,大致判断网络内部是否存在异常流量?
Who:若存在异常流量,异常流量都与谁有关?
What:异常流量是什么类型的?异常流量的运作机制怎样?
Where:异常流量相关的主机都在什么位置?
How:如何实现对异常流量的及时管理和控制?
这三大步骤和五个具体分析过程是相互关联的。下面我们将这三大步骤和五个具体分析过程关联起来进行阐述。
标签: 交换机 TCP wireshark omnipeek 防火墙 IPS 科来 中间设备 UDP 抓包 DOS 攻击 行为特征 发包频率 异常流量 蠕虫 木马 P2P 扫描 TCP会话 UDP会话 平均包长 平均每秒包数 利用率
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情,那么往往只能一个人独自去做"——理查德·耶茨
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)