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

MOTS攻击技术分析

作者:飞鸟 发布于:2017-6-8 17:28 Thursday 分类:网络安全

1.   背景

我们经常遇到这样一个场景:在用户现场通过端口镜像对流量做镜像,用来分析数据包或者审计的时候,疑心较大的用户总是怀疑其数据会被篡改或客户端信任的结果并非真实服务器返回的值。我想大多数的技术兄弟可能都会和我一样回复用户:这是一台审计设备,是旁路部署,只能审计,不是串在里面的,不可能对数据进行篡改;也不可能影响客户端的最终请求响应的结果。这个理论我一直深信不疑...

阅读全文>>

标签: 端口镜像 TCP 明文 reset 分片 MOTS 链路劫持 劫持 HTTP劫持

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

利用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) 浏览(110292)

【转】某加密机经天融信防火墙后应用异常故障案例

作者:易隐者 发布于:2012-9-24 14:10 Monday 分类:案例讨论

【写在前面】:

1,该案例是一个特殊应用、特殊环境下的疑难故障案例,给我们的启示是在故障现场,我们需要充分了解清楚跟故障有关的应用特性,比如此案例中的加密机的工作机制;

2,该案例涉及到以下知识点:IP报头校验和、IP分片(请参考本博《IP分片》一文)、防火墙对分片报文的处理等;

3,此案例在整理文档时,应该简化了很多的分析测试过程,我按照我的理解做一些梳理:

(1),IP报头校验和只跟IP报头有关,跟IP封装的数据无关,因此,如果原文中的描述的“收到报文是否进行校验和检查”是指IP报头检验和的话,那么应该不会存在校验和错误而被防火墙丢弃的问题,如果是指TCP校验和或UDP检验和的话,那么,每个来自于加密机的报文其TCP或UDP校验和都是错误的(因为多了33字节),因此防火墙肯定会直接丢弃这个报文,根本不存在文档中描述的在防火墙转发接口抓到1460字节数据包的情况;

(2),防火墙不对收到的报文进行校验和计算,那么这个报文才会进入防火墙的内核处理流程,因为来自于加密机的报文是IP分片报文,因此防火墙会对此分片报文进行处理(选择直接转发分片报文还是重组后匹配策略再转发),如果防火墙直接转发,则没什么问题,如果是重组转发,这里就存在一个问题:防火墙能否完成这个报文的重组?因为IP分片的重组是根据IP报头中的相关信息来完成的,其中非常重要的一个参数就是分片偏离量,这个值决定了分片报文在原始报文中的位置,而在这个故障环境下,每个报文都被加密机在尾部添加了只有加密机能够识别的特征码,防火墙并不能识别,那么防火墙在重组这些报文的时候,如何处理正常分片报文跟前一分片报文尾部添加的33字节部分的重叠呢?这是值得思考的。如是覆盖33字节的尾部识别码,则到达对端加密机后,加密机会丢弃这个报文,并不是因为文中所说的“认为加密数据被篡改”,而是由于被覆盖了数个识别码导致接收端加密机无法正常识别加密报文(篡改的识别是通过校验和得到的,接收方根据报头信息可以计算出校验和,也就是说只要报头信息没错,校验和就不会错,而防火墙在重组完毕后转发前肯定会重新计算转发报文的报头校验和)。

4,各位读者兄弟根据自己的理解,自由参考我上面的分析和下面的案例原文,欢迎探讨和交流。

【原文全文】:

一、拓扑 

点击查看原图


二、环境描述

       该拓扑使用的VPN链路是某公司的产品,该VPN在做加密处理时,TCP头和IP头都不做加密,只对数据区做加密,通过在加密机的抓包,发现加密机把所有MTU大于1300的数据包做了分片处理,并且在所有包的末尾加入自己的N字节加密识别码,这样从加密机发出的数据包MTU值最大1333,对于大于1333的报文(如1460)的数据包加密机都是分2个包进行传送,在没接防火墙时一切正常,接入防火墙后导致访问不正常;
       拓扑中客户端172.16.1.22在访问服务器172.16.1.33时,服务器回应的MTU值1460数据包被服务器端加密机拆成2个包(第一个包1300),并在每个包的末尾加入33位,而防火墙在接收时将两个包合并转发,具体表现为防火墙接收口(接服务器端加密机)收到的报文数据长度是1333,而转发口(接客户端加密机)转发的报文数据长度是1460,这样客户端加密机就认为加密数据被篡改,导致VPN加密通讯错误;

三、分析过程与解决方式

1、 由于加密机的特殊性,所以加密封包后的数据在通过防火墙时,会被认为是错误报文,
解决方法:将防火墙“选项设置”---“安全设备系统参数”---“系统参数开关”下的“收到报文进行是否效验和检查”选项取消,如下图所示 

点击查看原图


2、 加密机对大于1300的数据包做分片处理,到防火墙时,发现数据是分片包,防火墙又给重组后转发,导致对端加密机认为数据被篡改,不再对该数据包做解密处理;
解决方法:启用防火墙中的分片处理,将经过防火墙的数据都不做分片重组处理;
3、 以上两点设置好后,TCP报文可以正常通讯,但UDP报文(如视频报文)由于数据量大的缘故在通过防火墙时,经常丢包;
解决方法:研发根据该问题给了一个特殊的补丁,专门解决UDP报文处理的,只要打上该补丁即可;

四、总结

1、 将防火墙“选项设置”---“安全设备系统参数”---“系统参数开关”下的“收到报文进行是否效验和检查”选项取消;
2、 启用防火墙中的分片功能,将经过防火墙的数据都不做分片重组处理;
3、 打上专用的补丁;

阅读全文>>

标签: ip分片 天融信 分片 防火墙 重组 校验和 IP报头检验和

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

iPhone与Multicast DNS

作者:易隐者 发布于:2012-9-21 20:58 Friday 分类:案例讨论

        前两天看到CSNA论坛上有一个求助帖,原帖连接为:http://www.csna.cn/network-analyst-49133-1-1.html,故障现象大致为:网络经常出现断网情况,抓包发现断网时有大量的DNS包,楼主认为是IPHONE或IPAD在连接公司无线网络时出现的数据包。

       我下载了其数据包文件,并选其中的一个数据包文件进行了大致的分析:
1, 在数据包视图中查看其发包频率,如下图: 

点击查看原图

在1秒的时间内 发送了15542个IPv6的多播报文,这种发包频率,足以影响相关无线路由、交换机等设备的处理性能,而接收方对多播报文的处理流程决定了过多的多播报文对网络和主机的影响,大家可参考本人个人博客中《基于UDP组播实施分片攻击的可能性》一文。

2,我们查看其详细解码: 

点击查看原图

IPV6封装UDP 5353端口的DNS请求行为,经网络搜索相关信息,确认为Multicast DNS(组播DNS)报文;

       经查阅相关资料,苹果系列产品在本地局域网内缺少DNS服务器的环境下,使用Multicast DNS,实现名字和IP地址的解析,每个主机都知道自己的名字,并且会自动响应来自多播报文中针对该名字的请求。 使用Multicast DNS的设备大致工作过程如下:

1,在“.local.”子域下,挑选所需的名字;
2,使用Multicast DNS进行名字查询,看是否有主机已经使用了这个名字;
3,如果收到来自与其他主机的名字解析响应,则在“.local.”子域下重新选择一个名字,直至确认本地局域网内无其他设备使用该名字为止。

       大家可参考苹果支持主页中关于“Multicast DNS”的相关页面:http://support.apple.com/kb/TA20999?viewlocale=en_US

       这些都明确说明这个报文是iPhone发出的Multicast DNS报文,但是异常之处在于设备发包的频率太快了,而楼主反馈说,“不是每次连接都出现这个问题,只是偶尔会出现”,这也从侧面说明这个异常行为应该是属于iPhone本身跟“Multicast DNS”有关的进程异常导致的,可能是iPhone的BUG亦未可知。

       我在搜索相关信息的时候,竟然找到了一篇跟MAC OS相关的DNS异常问题的帖子,应该属于相关内容了,感兴趣的可以自行查看下面连接:http://blog.sina.com.cn/s/blog_539a3a320100q5dq.html

阅读全文>>

标签: 交换机 分片 解码 故障 UDP 多播 DNS iPhone Multicast DNS 多播DNS 组播DNS IPv6

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

TCP MSS与PMTUD

作者:易隐者 发布于:2012-9-6 19:16 Thursday 分类:网络分析

 

       一旦DF位置一,将不允许中间设备对该报文进行分片,那么在遇到IP报文长度超过中间设备转发接口的MTU值时,该IP报文将会被中间设备丢弃。在丢弃之后,中间设备会向发送方发送ICMP差错报文。
为了简单直观的展示这个交互的过程,我做了下面这个图示: 

点击查看原图


       我找了一个实际环境下捕获的ICMP需要分片但DF位置一的差错报文,下图为其解码格式: 

点击查看原图


       我们可以看到其差错类型为3,代码为4,并且告知了下一跳的MTU值为1478。在ICMP差错报文里封装导致此差错的原始IP报文的报头(包含IP报头和四层报头)。

       一旦出现这种因DF位置一而引起丢包,如果客户端无法正常处理的话,将会导致业务应用出现异常,外在表现为页面无法打开、页面打开不全、某些大文件无法传输等等,这将严重影响业务的正常运行。
那么客户端如何处理这种状况呢?
TCP主要通过两种方式来应对:
1, 协商MSS,在交互之前避免分片的产生
2, 路径MTU发现(PMTUD)

TCP MSS

       TCP在三次握手建立连接过程中,会在SYN报文中使用MSS(Maximum Segment Size)选项功能,协商交互双方能够接收的最大段长MSS值。
       MSS是传输层TCP协议范畴内的概念,顾名思义,其标识TCP能够承载的最大的应用数据段长度,因此,MSS=MTU-20字节TCP报头-20字节IP报头,那么在以太网环境下,MSS值一般就是1500-20-20=1460字节。
客户端与服务器端分别根据自己发包接口的MTU值计算出相应MSS值,并通过SYN报文告知对方,我们还是通过一个实际环境中捕获的数据报文来看一下MSS协商的过程:

点击查看原图

       这是整个报文交互过程的截图,我们再来看一下客户端的报文详细解码: 

点击查看原图

       上图为客户端的SYN报文,在其TCP选项字段,我们可以看到其通告的MSS值为1460;我们在看看服务器端的SYN/ACK报文解码: 

点击查看原图


       上图为服务器端给客户端回应的SYN/ACK报文,查看其TCP选项字段,我们可以发现其通告的MSS值为1440。

       交互双方会以双方通告的MSS值中取最小值作为发送报文的最大段长。在此TCP连接后续的交互过程中,我们可以清楚的看到服务器端向客户端发送的报文中,TCP的最大段长度都是1440字节,如下图解码所示:

点击查看原图

       通过在TCP连接之初,协商MSS值巧妙的解决了避免端系统分片的问题,但是在复杂的实际网络环境下,影响到IP报文分片的并不仅仅是发送方和接收方,还有路由器、防火墙等中间系统,假设在下图的网络环境下: 

点击查看原图

       中间路径上的MTU问题,端系统并不知道,因此需要一个告知的机制,这个机制就是路径MTU发现(PMTUD: Path MTU Discovery )!

PMTUD

       说起PMTUD,我们必须在此回到上面讲到的ICMP需要分片但DF位置一差错报文,还记得那个ICMP差错报文中有一个字段是告知下一跳的MTU值的吗?PMTUD正是利用ICMP需要分片但DF位置一差错报文的这一特性来实现的。
       发送方在接收到该差错报文后,会根据该报文给出的下一跳的MTU值计算适合传输的最大段长度,从而在后续的发送报文过程中,避免在中间路径被分片的情况产生。
       这在端系统主要是通过在路由表里临时添加目的主机路由并将ICMP差错报文告知的下一跳MTU值跟该主机路由关联起来来实现。
       PMTUD的确是个非常不错的机制,但是在复杂的实际网络环境中,有时候会失效,因为为了安全起见,有些网络管理员会在路由器、防火墙等中间设备上设置过滤ICMP报文的安全策略,这将导致ICMP差错报文被这些中间设备丢弃,无法达到发送方,从而引起PMTUD的失效,网上有个宫一鸣前辈共享的案例——《错误的网络访问控制策略导致PMTUD 实现故障一例》,该案例正是说明这种情况绝好的例子,大家可以自行百度此文档学习参考。

       值得一提的是PMTUD仅TCP支持,UDP并不支持PMTUD。

       由于PMTUD可能存在ICMP差错报文被过滤的情况,很多中间设备的接口支持adjust tcp mss设置功能,思科路由器一般是在接口模式下使用命令“ip tcp adjust-mss 1400 ”来做设置,其他的品牌产品的相关设置大家可在实际工作环境下自查相关品牌和产品的使用手册。

        这个功能主要是通过由中间设备修改经过其转发的TCP SYN报文中的MSS值,让中间设备参与进TCP 三次握手时SYN报文的MSS协商来避免分片。

       需要注意的是,该功能不像MTU值,只针对出接口,此功能一旦开启,其将针对该接口的收发双向有效。
我做一个简化环境下的工作过程图示以便于大家理解其工作过程:

点击查看原图

阅读全文>>

标签: TCP icmp差错 分片 SYN TCP选项 UDP MTU ICMP PMTUD MSS

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

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