又遇TCP协议栈异常问题
作者:易隐者 发布于:2013-10-29 16:47 Tuesday 分类:案例讨论
大家还记得我以前写的《TCP确认机制异常案例》(链接为:http://www.vants.org/?post=200)吗?今天在一个用户那边再次遇到了一个TCP协议栈异常的问题。
用户反馈的问题现象是业务交互出现异常,难以定位异常出现的原因,我在用户现场分析了异常出现时的报文交互情况,如下图所示:
由F5设备主动向服务器发送SYN连接请求报文,服务器响应SYN/ACK报文,F5发送ACK报文确认后,向服务器连续发送3个大小分别为1514、1514、350大小的应用请求报文,但是1.199秒之后,F5重传了应用请求的第一个报文(该报文序列号为No7,该数据报其实是序号为No4的报文的重传),紧接着,2秒后,看到服务器的SYN/ACK的重传报文(该报文序列号为No8,该报文为No2报文的重传报文),后面数十秒的交互,基本是都是F5对应用请求报文的重传和服务器SYN/ACK报文的重传,在40秒之后,由F5主动发送RST报文释放该TCP连接。
由整个交互的过程,我们可以清晰的看到,服务器不断重传SYN/ACK报文,说明服务器没有正常处理F5的ACK报文(序列号为No3的报文),站在F5的角度,TCP连接已经建立成功,但是站在服务器的角度,却认为TCP连接未建立完成,因此服务器不断重传SYN/ACK报文,为什么服务器在明确收到了F5的三次握手的ACK报文,却没有正确处理呢?而且后续F5重传的应用请求报文(No7、No10、No11、No14、No17)都可以说是对服务器SYN/ACK报文的确认,但是服务器全部忽略了,因此,这基本上可以判断为服务器端系统的TCP协议栈出现异常,导致了应用出现了异常。
标签: TCP F5 应用故障 SYN 重传 TCP协议栈 应用异常
利用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
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情,那么往往只能一个人独自去做"——理查德·耶茨
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)