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

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) 浏览(108982)

利用UDP19端口实施DOS攻击的真实案例

作者:易隐者 发布于:2013-10-17 17:06 Thursday 分类:网络安全

       昨天在一个用户现场发现了一个利用UDP19端口对互联网受害者主机进行DOS攻击的真实案例。这个情况是我第一次见到,个人认为对以后遇到此类情况的兄弟具有参考价值。有必要做一个简单的分析记录。

       在此次的分析过程中,我主要通过wireshark来抓取相关数据报文的。

数据包分析

1,我们首先通过wireshark的“Summary”功能,查看网络流量统计情况,如下图所示: 

点击查看原图


我们发现服务器区域的流量较大,平均每秒10M左右的流量,这个流量相对于用户整个30M的互联网出口带宽而言,已经算相当大的流量了。
2,我们再通过wireshark的“Protocal Hierarchy”功能,查看这么大的流量在各个协议之间的分布情况,如下图: 

点击查看原图

我们看到UDP和IP分片的报文流量占据了总流量的92%以上,而业务应用所使用的TCP流量仅有7.24%!这意味着绝大部分的流量都是垃圾流量,那么这些垃圾流量到底是什么呢?
3,我们接下来分析这些占总流量92%以上的UDP报文和IP分片报文到底是用来干什么的。我们通过wireshark的数据包查看UDP报文都是UDP19端口交互的报文,如下图: 

点击查看原图


 我们使用wireshark的“Follow UDP Stream”功能,将其中任意一个UDP19端口交互的报文进行重组还原,如下图所示: 

点击查看原图


我们可清晰看到这个UDP19端口交互的内容都是明显填充的内容。
4,UDP19端口是用来做什么的呢?我们百度一下,摘录了百度百科中对UDP19端口的相关描述如下:
“端口:19
服务:Character Generator
说明:这是一种仅仅发送字符的服务。UDP版本将会在收到UDP包后回应含有垃圾字符的包。TCP连接时会发送含有垃圾字符的数据流直到连接关闭。HACKER利用IP欺骗可以发动DoS攻击。伪造两个chargen服务器之间的UDP包。同样Fraggle DoS攻击向目标地址的这个端口广播一个带有伪造受害者IP的数据包,受害者为了回应这些数据而过载。”
(该段百度百科描述的原始链接为:
http://baike.baidu.com/link?url=PVKVjqJ4jUhiI6y9bPnrTiVZwSi8vu6mxIw9LxHVqRpmjKWpPJyboZIUddoLL6m3aYVo_LcwgDwSOnLJcElRU_)
5,我们了解了这个UDP19端口的上述信息,那么用户目前遇到的情况是否正是黑客利用其对外进行DOS攻击呢?我们来一起验证一下。
我们通过抓包发现,跟服务器192.168.1.8的UDP端口交互的主机主要有37.17.173.32、88.190.35.204、97.86.229.87、71.61.231.170、等,我们分别来看一下这些IP与192.168.1.8交互报文的解码: 

点击查看原图

点击查看原图

点击查看原图

明显发现,这些报文的TTL都是236,这基本可判定这些报文应该都来自于同一物理位置的机器,换句话说,这些报文都是一台机器伪造的IP报文!
6,至此,我们基本可以将此次异常的原因定位为黑客利用服务器开启的UDP19端口,伪造源IP为互联网某受害者服务器的IP地址向192.168.1.8服务器的UDP19端口发送报文,服务器在收到这个报文后会向互联网受害者服务器IP送填充任意字符的报文,导致受害者服务器带宽被占满,从而达到对受害者服务器DOS攻击的效果,其工作机制大致如下图所示:

点击查看原图


更进一步的分析

我们分析清楚了异常的原因,但是UDP19端口并不是服务器的对外提供业务的端口,为什么服务器会开启UDP19端口呢?我们在服务器上通过“netstat –ano”命令,查看UDP19端口是由什么进程开启的,如下图所示:

点击查看原图

 由上图我们知道该端口由进程ID号为1432的进程开启,查看任务管理器,得知该进程为简单TCPIP服务,进程名为tcpsvcs.exe,该进程是微软Windows网络组件的一部分。这个系统进程用于计算机使用专用的TCP/IP网络服务,例如DHCP,简单TCP和打印服务。
通过百度搜索tcpsvcs.exe、UDP19端口等关键字,如下图所示: 

点击查看原图

我们发现曾有人遇到过这种问题,当事人反馈“win2003 sp2 近来发现tcpsvcs.exe上传速度太猛了,最高时有2m,都差不多占了全部带宽了…….总是国外IP连接19端口,IP禁了几十个,还是不断有新的” (原始链接为:http://bbs.csdn.net/topics/390496813),这说明我们的用户并不是唯一一个遇到这种情况的:黑客利用服务器对外开放的UDP19端口,伪造受害者IP向服务器发送报文,服务器在收到报文后,会向受害者IP发送填充的字符报文,这些报文大部分都是大报文,需要分为多个分片报文,这会产生较大的网络流量,消耗服务器和互联网受害者的网络带宽资源。

阅读全文>>

标签: wireshark 分片 TTL DOS UDP19端口 tcpsvcs进程 伪造源IP Character Generator tcpsvcs.exe

评论(3) 引用(0) 浏览(108395)

数据包中出现超长帧的分析

作者:易隐者 发布于:2012-11-1 16:36 Thursday 分类:网络分析

抓包环境

       在用户处的抓包环境如下图所示: 

点击查看原图


说明:
1、在核心交换机上做端口镜像抓取进出互联网的数据包;
2、监听端口为一台服务器接入端口,在服务器上开启科来网络分析系统抓取数据包。

问题现象描述

       在抓取数据包,并对数据包进行分析时,我们发现了一些问题,主要是以下几点:
1、 数据包中有很多长度超过1518字节的数据帧,其字节分布从1600-8880字节不等。如下图所示: 

点击查看原图

这是正常的吗?是什么原因导致的呢?
2、 存在较多的IP标识一致但是长度大小不一致的数据包,如下图所示: 

点击查看原图

问题分析

1 关于超长帧问题的分析

1、一般以太网环境中数据链路层能够传输的最大数据为1518字节,有些网卡在故障时会发送一些超长帧,但是这种帧一般都会被中间设备或捕获数据包的网卡丢弃,抓包工具一般无法正常显示,但是,在此次所捕获的数据包中,这些超长帧都能正常显示,而且通过分析其数据包通讯过程,也能够确定其通讯正常。可以排除设备网卡故障的可能。
2、在网上查找了一些关于超长帧的文档,发现其是一种专门为千兆以太网而设计的厂商标准的超长帧格式,其长度从9000字节~64000字节不等。采用Jumbo Frame能够令千兆以太网性能充分发挥,使数据传输效率提高50%~100%,超长帧一般在内部网络的存储环境中应用较多。Jumbo Frame需要在相互通讯的2个通讯端口(交换机端口或网卡端口)上同时支持,而且与以前的以太网产品不兼容,因此主要会应用于千兆主干的端口之间以及服务器端口接入到网络主干的链路。交换机把Jumbo Frame格式的数据转发向不兼容Jumbo Frame的端口时应进行帧格式的转换,即把Jumbo Frame帧格式的数据转换成标准以太网的帧格式,从而保证其正常工作。相反,从不兼容Jumbo Frame的端口向支持Jumbo Frame的端口转发数据时,交换机可以把多个标准以太网帧合并成超长Jumbo Frame帧,从而提高传输效率。
3、通过对数据包的分析,结合相关的资料,我们基本上可以推断出网络中的相关服务器和交换机支持jumbo frame,并且服务器正在使用超长帧与交换机进行相应的数据交互。
4、验证:可以在相应的服务器与交换机上查看它们对超长帧支持的相关设置。

2 关于IP标识一样但数据包大小不一样问题的分析

1、我们知道IP标识一样,说明属于同一数据包,如果在网络中同一数据包出现多次的话,说明网络中存在IP分片或网络中存在环路,但是,我们在数据包中未发现IP分片数据包,并且,如果是环路的话,其TTL值肯定会逐渐减小至0,但通过对数据包的分析,也未发现其TTL为1或0的数据包,因此可以排除网络环路或IP分片的问题。
2、我们在仔细对比分析了相应的数据包后,发现IP标识一样的数据包除了长度大小不一样外,还存在以下几点异同:
(1) 源MAC地址不一样;
(2) TTL值不一样;
(3) TCP序列号一致。
具体如下图所示:
第三个PACKET的数据包解码图:
 点击查看原图

点击查看原图

TTL值由128变成127了,说明经过了一跳路由,MAC地址变了就是经过路由的证据,为什么会经过一跳路由呢?联系我们的抓包拓扑和环境,我们便能明白:
科来网络分析系统是部署在服务器172.16.4.55上的,服务器与其他主机间的通讯数据流首先会被科来网络分析系统捕获下来,同时,服务器的网卡又捕获进出互联网出口的数据流,因为核心交换机上做了针对互联网出口的端口镜像,并且监听口为服务器在交换机上的接入端口。具体数据流见下图的图示: 

点击查看原图

也就是说,第三个packet是服务器网卡发送的数据包,而第四个packet是核心交换机互联网出口转发的数据包,它们是同一数据包,经过核心交换机的VLAN间路由后,TTL值减1了,并且,将服务器的源MAC替换成核心交换机相应VLAN的MAC。
3、上面我们分析了第三个packet与第四个packet属于同一数据包,那么,为什么它们的长度大小不一样呢?考虑到“交换机把Jumbo Frame格式的数据转发向不兼容Jumbo Frame的端口时应进行帧格式的转换,即把Jumbo Frame帧格式的数据转换成标准以太网的帧格式,从而保证其正常工作。”,我们可以推断第四个packet是核心交换机将第三个packet转换而来的。
4、验证:我们可以通过计算上下packet的TCP segment段长来验证是否是核心交换机将服务器发送的超长帧转换成多个较小的packet进行传输。如下图所示: 

点击查看原图

我们可以发现第三个packet的TCP段长正好是第四个packet与第五个packet的TCP段长之和。同样的道理,我们可以一一验证后续的超长帧与相关数据包的这种关系。

结论

通过上面的分析,我们得出以下结论:
1、网络中出现超出以太网MTU值的数据包是由于jumbo frame造成的,Jumbo frame在内部的服务器之间或服务器与交换机之间经常使用,以提高数据传输的效率,在互联网上不会出现。
2、jumbo frame的使用需要相关服务器和交换机的支持。
3、出现的IP标识一致的数据包是由于同一数据包被捕获了两次,长度大小不一样是由于后面的长度较小的数据包是交换机将前面较大的数据包转换为多个常规以太网数据包而来。

引申问题

假设服务器在很短的时间内发送了大量的超长数据包,其IP标识都很接近,在经过交换机时,交换机需要对这些超长的数据包进行转换,一个超长的数据包会被转换成多个常规的数据包,交换机在进行这个转换的时候,需要给那些转换后常规数据包重新分配IP标识(转换后的第一个数据包的IP标识为转换前的超长数据包的IP标识,后续的数据包的IP标识逐一增加),那么,是否会存在转换后数据包的IP标识与转换前的数据包的IP标识一样而导致对端设备接收异常呢?如下图所示: 

点击查看原图

我们以第9个packet至第15个packet等7个数据包来分析这个问题,如下图所示:

点击查看原图

 第9个packet、第10个packet都是超长帧,经过交换机是需要转换的,通过相应的IP标识值以及TCP段长的计算,我们可以知道第9个packet被转换为第11、12两个packets,第10个packet被转换为第13、14、15三个packets。
       通过比较这些数据包的IP标识,我们可以发现服务器在发生这些超长数据包时,似乎已经考虑到我们前面提到的问题,并将其相应的IP标识设置为转换后不会存在冲突的值。

阅读全文>>

标签: IP标识 IPID TTL MTU 超长帧 Jumbo Frame

评论(1) 引用(0) 浏览(10915)

端系统对RST报文的过滤

作者:易隐者 发布于:2012-10-8 17:00 Monday 分类:网络分析

       前段时间在分析网上一个兄弟传给我的报文时,发现了几个有意思的现象,我觉得值得分析讨论,我们首先来看一个服务器与客户端交互的会话: 

点击查看原图

       在这个交互的过程中,我们可以看到一个比较奇怪的现象,那就是客户端10.16.137.56在收到来自服务器的FIN报文之后,紧接着向服务器端发送RST报文,但是服务器给其回应了一个ICMP主机管理性禁止差错报文,并且不断尝试向服务器发送FIN报文。
       我们来看一下服务器给客户端回应的ICMP主机管理性禁止差错报文的解码: 

点击查看原图

       Type 3,Code 10——主机管理性禁止差错,其封装的原始报文报头信息显示,该ICMP差错报文正是由客户端发往服务器端的RST报文引起的。下图为客户端发往服务器端的RST报文解码: 

点击查看原图

       另外,我们注意到,服务器发送给客户端的ICMP差错报文的TTL值为48,而服务器端发送给客户端的FIN报文报头中的TTL值也是48,如下图所示: 

点击查看原图

       这从侧面说明这个ICMP差错报文的确是服务器端系统发送的,而不是中间设备发出的。

       那么为什么服务器端系统会过滤掉客户端的RST报文呢?

       想想TCP会话劫持和TCP RST攻击,大家就能够体会,服务器管理员为什么这么做了。

       TCP会话劫持的实施者经常会扮演对端的身份分别向客户端或服务器端发送RST报文,以达到干扰客户端与服务器端正常交互的目的。有些服务器的管理员可能遇到过这种TCP会话劫持的攻击,因此在服务器端系统上利用相关工具设置了过滤RST报文的策略,当服务器收到RST报文时,直接忽略掉,因此服务器端系统的传输层并不会收到这个RST报文。

       其交互过程大致如下图所示:

点击查看原图

过滤RST报文可能带来的影响

       服务器传输层无法收到客户端的RST 报文,只能在多次尝试重传FIN报文直至超时,然后主动向客户端发送RST报文。如此带来的影响就是执行过滤策略的端系统无法正常处理来自于TCP连接对端的异常释放行为(RST),这将导致端系统的TCP连接释放需要更长的时间,在有大量对端通过RST报文异常释放TCP连接的场景下,可能会对性能产生一定的影响。

阅读全文>>

标签: TCP RST icmp差错 会话劫持 TTL FIN type 3 code 10 端系统

评论(2) 引用(0) 浏览(11096)

访问搜狐163时主页变为2008年某日主页面故障分析案例

作者:易隐者 发布于:2012-8-13 22:26 Monday 分类:网络分析

1 故障环境

        故障环境的拓扑结构示意图如下:
 

点击查看原图


        防火墙做NAT通过电信接入线路访问互联网,核心交换机上接入的设备和线路比较多,内部网络规模比较大。

2 故障现象

       故障现象主要体现在以下几个方面:
1,用户在内网访问搜狐和163主页时,页面变为2008年某日的主页面,所有连接均为2008年的新闻连接,如下图所示: 

点击查看原图


其他网站页面访问均正常。
2,使用笔记本配置为公网地址直接访问搜狐和163正常;
3,在防火墙的一个空闲端口设置地址,通过防火墙NAT地址转换后访问搜狐163主页正常;

       此故障已经持续了数周。

阅读全文>>

标签: 端口镜像 交换机 疑难故障 TCP 天融信 RST reset HTTP会话劫持 会话劫持 TTL

评论(1) 引用(0) 浏览(8272)

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