蚂蚁网-多维人生，三实而立！

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

ACK flood攻击的影响

作者：易隐者 发布于：2012-10-8 10:14 Monday 分类：网络安全

       我们在分析ACK flood攻击对端系统和中间系统的影响之前，首先需要了解端系统和中间系统一般情况下是如何处理其收到的ACK报文。

端系统对ACK flood报文的处理

       端系统在收到一个ACK报文时，如果目的端口未开放，那么端系统会直接向源IP发送RST报文，其交互过程大致如下图所示： 

       如果端系统的相关端口是对外开放的，那么其在收到ACK报文时，首先会检查这个ACK报文是否属于TCP连接表中的一个已有连接（这个过程会对端系统主机CPU资源造成一定的消耗），如果是的话，则正常处理，如果不属于任何一个已有连接，那么端系统会向源IP发送RST报文，交互过程如下图所示： 

       根据上面两个过程的分析，我们可推论ACK flood攻击对端系统性能的影响并不会非常大，至少跟SYN flood（端系统需要给每个SYN报文分配相应连接表空间，会消耗端系统内存资源）攻击相比，其攻击效果似乎难上台面。

中间系统对ACK flood报文的处理

       路由器和防火墙的工作机制决定了路由器和防火墙在处理ACK报文的时候是完全不同的，我们分别将路由器与防火墙对ACK flood攻击的处理过程做简单描述。
       路由器是网络层的设备，其主要功能是选路和转发，其选路的依据大部分都是基于网络层信息（目的IP、源IP等），因此路由器在处理ACK报文的时候，其并不关心它是不是ACK报文，它主要关心其目的地址，需要根据其目的地址来进行选路，如果ACK flood攻击的目的主机都是固定的，那么路由器其实只需要在收到第一个ACK flood攻击报文时，调用CPU资源实现选路和转发，后续的ACK flood攻击报文由于目的主机是固定的，其甚至不需要调用CPU资源，直接使用快速转发表即可实现对ACK flood报文的转发，路由器对ACK报文的处理过程大致如下： 

       防火墙对ACK报文的处理主要跟连接状态表有关，防火墙在收到ACK报文时，首先检查该ACK报文是否属于连接状态表中的已有连接，如果是，防火墙转发该ACK报文，如果未命中任何一个已有连接，防火墙会将该ACK报文丢弃，如下图所示： 

ACK Flood攻击对系统的影响

       由此来看，ACK flood攻击对端系统与中间系统的影响相对于其他攻击来说都不是非常明显，至于网上有相关资料讲其需要配合SYN flood攻击产生较好的攻击效果，原因为针对防护SYN flood攻击的一种技术 ——SYN cookie技术。
       当某些启用SYN cookie技术进行SYN flood攻击防护的中间设备（专业抗DOS设备、防火墙、IPS、负载均衡、路由器等），在收到ACK报文时，需要计算cookie值，这个过程会消耗一部分中间设备的CPU资源，如果大量的ACK报文过来的话，很可能很快就会导致设备资源耗尽，达到拒绝服务的效果。

关于SYN cookie的工作机制，我在互联网上找到一篇文章，文章链接为：
http://blog.csdn.net/force_eagle/article/details/5348946，作者：droplet，现全文引用至此：

“

Cookie如何计算？
cookie = MD5(srcip,dstip,sport,dport)
端口是否需要考虑哪？没有端口的话，可以少一点计算。
Syn-cookie是无状态的，在Gateway上，不会保存任何与connection相关的东西，所以不会占用gateway的资源，缺点就是需要计算cookie，CPU占用会高一点。
如果不考虑端口的话，cookie是不是可以cache哪，如果cache了，就有查找的开销，并不一定比MD5的hash快多少。
在Syn-cookie之前，先要检查一下srcip是不是spoofing的，这里需要做一个反向的路由查找，看看是不是从错误的接口进来的，也可以确认一下源地址是否可达。
是不是也应该做一个源端口的检查哪？如果是0~1024的端口，就默认是非法的，因为这些端口在操作系统里面，一般是保留的，不会分配给应用程序。
Syn attack是否有signatue? 不同的syn flood工具，生成的工具包，应该有一定的模式，如果能够找到这个signature，就可以通过signature来直接drop这个syn，不用再做syn-cookie的检查了。
Syn-cookie会strip掉client和server的tcp option，对client，可疑在cookie里面带上tcp option，但是对server来说，就比较难办一点。strip掉tcp option，对connection的性能有影响。
对syn-flood的防范，目前还是threshold based，因为不能区分正常包和攻击包，但是如果能够定义攻击的signature，就可以做signature based的防范，这样可以更有效一点。”

       在这里有个疑问，启用SYN cookie技术的中间设备在收到SYN报文的时候会建立cookie序列，在收到ACK报文的时候会计算cookie是否合法，那么是不是任何一个ACK报文都计算cookie值呢？从全文的描述来看，应该是在收到三次握手的最后一个ACK报文时才进行计算。
       如果是对所有ACK报文都进行cookie值计算，这个中间设备对SYN cookie技术的实现是不是非常不科学呢？如果仅针对三次握手时的第三个ACK报文进行cookie值计算，那么中间设备应该直接丢弃随机伪造的ACK flood攻击报文。如果是丢弃随机伪造的ACK flood报文，那么对中间设备资源的消耗也是有限的。

        需要申明的是，以上仅为我个人站在技术原理的角度作出的推论，实际环境下没有亲见ACK flood攻击带来的影响。欢迎各位兄弟姐妹一起做进一步的探讨。

阅读全文>>

标签: TCP RST 防火墙 ACK flood SYN flood 连接表 SYN cookie ACK报文 连接状态表

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

关于《DDoS攻击原理及防护方法论》一文的疑问

作者：易隐者 发布于：2012-10-7 20:12 Sunday 分类：网络安全

       在网上查找ACK flood攻击相关资料时，发现了51CTO中的一篇名为《DDoS攻击原理及防护方法论》的文章，其链接为：http://netsecurity.51cto.com/art/200903/114969_3.htm，原文大家直接点击链接查看，在此不做引用。

       在这篇文章中对ACK flood攻击做了相关的描述，但是我个人对这篇文章有一些疑问，特将其罗列如下，供各位感兴趣的兄弟一起讨论：

1，“如果存在则检查该数据包所表示的状态是否合法，然后再向应用层传递该数据包”

数据包本身并无状态可言，所谓状态是端系统或中间系统根据数据包的交互情况，自行判断的，因此，这里所指的“检查该数据包所表示的状态是否合法”不知到底是什么意思。

2，“例如该数据包所指向的目的端口在本机并未开放，则主机操作系统协议栈会回应RST包告诉对方此端口不存在”

所列举的例子不适用于前文描述的场景，前文描述为“主机在接收到一个带有ACK标志位的数据包的时候，需要检查该数据包所表示的连接四元组是否存在，如果存在则检查该数据包所表示的状态是否合法，然后再向应用层传递该数据包”，而此处列举的例子为端口未开放的场景，既然端口未开放，又何来连接四元组信息？既然无四元组信息，则“检查该数据包所表示的连接四元组是否存在”有从何而来？

3，“可以肯定的是，ACK Flood不但可以危害路由器等网络设备，而且对服务器上的应用有不小的影响”

ACK flood真的可以给路由器带来很大影响吗？首先我们需要明确概念：ACK为传输层的概念，路由为网络层设备，主要负责选路和转发（这个过程会消耗路由的CPU资源），路由器是不会管你是不是ACK报文，其工作的机制过程都是一样的，如果ACK flood攻击的目的主机都是固定的，那么路由器其实只需要在收到第一个ACK flood攻击报文时，调用CPU资源实现选路和转发，后续的ACK flood攻击报文由于目的主机是固定的，其甚至不需要调用CPU资源，直接使用快速转发表即可实现对ACK flood报文的转发，因此，这个说法不科学。值得进一步讨论和推敲。

4，“如果没有开放端口，服务器将直接丢弃，这将会耗费服务器的CPU资源。如果端口开放，服务器回应RST。
”

未开放端口是直接发送RST报文，而不是直接丢弃报文，并且直接RST对CPU资源的消耗并不大；如果端口开放，则检查TCP连接表，有相关信息则做相应的处理，无则发送RST报文。作者后面的这段表述与前面“例如该数据包所指向的目的端口在本机并未开放，则主机操作系统协议栈会回应RST包告诉对方此端口不存在”的表述出现差异，似乎从侧面反应写这篇文章的作者并未深入了解相关工作原理和机制，全文中出现前后矛盾的地方也说明作者很可能从其他地方照搬了很多作者本人未深入理解的内容。

5，“ACK Flood防护
利用对称性判断来分析出是否有攻击存在。所谓对称型判断，就是收包异常大于发包，因为攻击者通常会采用大量ACK包，并且为了提高攻击速度，一般采用内容基本一致的小包发送。这可以作为判断是否发生ACK Flood的依据，但是目前已知情况来看，很少有单纯使用ACK Flood攻击，都会和其他攻击方法混合使用，因此，很容易产生误判。
一些防火墙应对的方法是：建立一个hash表，用来存放TCP连接“状态”，相对于主机的TCP stack实现来说，状态检查的过程相对简化。例如，不作sequence number的检查，不作包乱序的处理，只是统计一定时间内是否有ACK包在该“连接”(即四元组)上通过，从而“大致”确定该“连接”是否是“活动的”。 ”

到底如何防护的？作者在此并未提供什么有价值的信息，仅仅简单的说了一下ACK flood的分析判断。站在网络分析的角度，ACK flood攻击的分析判断跟SYN flood攻击的分析过程大致相同，不同的在于分析其报文的解码，看其TCP标志位。

阅读全文>>

标签: RST ACK flood 路由器 连接表 DDOS

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

使用Omnipeek分析SSH端口攻击案例

作者：易隐者 发布于：2012-10-7 19:47 Sunday 分类：网络安全

       在某用户网络环境下发现攻击的实例，为了让大家对omnipeek有个初步直观的了解，此次我使用omnipeek作为分析的工具。

1，我们使用omnipeek打开数据包文件，通过omnipeek的“统计”功能，我们发现，在1分47秒的时间内，共产生了近119万个数据包，如下图所示：

 并且绝大部分都是小于127字节的小包，这是基本上可以判断网内存在明显的异常发包行为。

2，我们再看omnipeek的“IP Analysis”的统计情况，如下图： 

TCP SYN报文 25631个，TCP RST报文19247个，这说明基本上绝大部分的SYN连接都被RST了，网内可能存在基于TCP的大规模的扫描行为；

3，我们在查看omnipeek的“节点”统计功能，通过“总字节”参数排序，如下图所示： 

我们可以清楚的看到绝大部分的流量和数据包都来自于排名前三的IP地址。并且这三个IP地址的发送数据包个数和接收数据包个数都非常巨大。

4，我们可以通告“过滤器”功能来看一下排名第一的IP交互的具体情况，
我们在omnipeek的“专家-层次”功能界面，使用排序功能，针对服务器地址进行排序，如下图所示： 

我们可以明显的看到IP地址为X.X.28.134的主机与68.120.23.0-68.120.236.0网段的大量主机进行了交互，我们查看其交互的报文，如下图所示： 

发现其都是向68.120.23.0-68.120.236.0网段主机的SSH 应用TCP 22端口发送SYN报文。

由此可得出结论：
       主机X.X.28.134在针对68.120.23.0-68.120.236.0网段进行大规模的SSH端口扫描行为（实际的扫描网段范围很可能更大，因为我们抓包的时间有限，只有1分47秒）。

与此同时的ACK flood攻击

       我们在分析的过程中还发现，与X.X.28.134与 68.71.59.244与68.71.59.247两个IP之间存在巨大的交互报文，如下图所示： 

为什么这两个IP与扫描主机交互的报文如此巨大？我们来具体的看一下这两个IP与扫描主机之间交互的报文：

这两个IP向扫描主机发送数量巨大的ACK报文（无应用数据，SYN/FIN标志位未置一的报文）。
扫描主机在收到这些ACK报文后的处理方式如下图所示： 

扫描主机向68.71.59.244的SSH端口发送RST报文。

我们来看一下具体 的ACK报文解码和RST报文解码，先看ACK报文的，如下图所示：

 仅ACK标志位置一，源主机IP为68.71.59.247，端口为SSH的22端口，针对X.X.28.134主机的60502端口。

我们再看看“数据包”视图：

       在极短的时间间隔内，同一个TCP会话中，68.71.59.247向X.X.28.134发送大量的ACK报文，这些ACK报文的序列号、确认号等信息完全一致，IP标识逐步递增，这些足以说明这些ACK报文不是简单的快速重传报文，也不是在网内被不断重复捕获的同一数据报文。
我们再看一下X.X.28.134对这些ACK报文回应的RST报文的解码，如下图所示： 

RST标志位置一，ACK Number为0，说明该连接并不在X.X.28.134的连接表中，或者X.X.28.134并未开放60502端口。

       难道这就是传说的“ACK flood”攻击吗 ？

       忽然想起数年前，我在组织内部培训时，小鲍似乎在准备某个攻击话题时，提到ACK Flood攻击，记得当时我反问小鲍，实施这种攻击的意义何在？它不会像SYN flood攻击那样对防火墙、目的主机造成非常明显的资源消耗的影响，如果有人使用ACK Flood攻击目标主机并不会获得良好的拒绝服务效果，并且固执的认为这种攻击应该不会有人会用的。但是看到这个报文并分析至此，我不得不收回我以前的话，并承认我们遇到的的确就是一个ACK Flood攻击！

        源主机在针对大网段扫描SSH端口，同时被来自互联网的其他两个IP针对其执行扫描的源端口发送大量的ACK报文，实施ACK flood攻击？这是为什么呢？难道是源主机扫描攻击别人，被别人发现，别人就来个复仇计划，用两台高性能服务器对其发其反击？

       真实用户网络环境的各种凌乱，若非亲见，又怎会相信。

阅读全文>>

标签: omnipeek RST SSH ACK flood 攻击 SYN flood 端口扫描

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

针对随机组播地址的ping攻击案例

作者：易隐者 发布于：2012-9-25 11:22 Tuesday 分类：网络安全

       前段时间，某兄弟在用户处遇到一个问题，说是在无线环境下，生产系统中的条码系统经常卡机，迟迟难以定位，网上找到我，并将报文发给我，让我帮忙看看。
       根据他的描述，一开始我以为是个应用系统故障，准备建议其在生产客户端与服务器端同时抓包做对比分析，后来仔细看起报文时，发现了一个主机针对随机的组播IP地址发送ping请求报文，如下图所示： 

我们查看其中某个报文的解码： 

       这个主机的网络交互行为特征大致有以下几点：

1，该主机发送了大量的ping报文，但是正常情况下，生产主机不会发送跟生产业务无关的报文，包括ping报文；
2，ping报文的目的地址都是随机的组播地址；
3，ping组播地址的发包频率虽有变化，但是其发包高峰时可以达到毫秒以内的时间间隔

       结合上述三点，我们可以确定为该主机异常行为。

       主机对多播报文的处理流程决定了网内过多的多播报文会对主机和网络性能带来严重的影响。而目前这个很可能只是大规模爆发之前的预演，发包时间间隔较为随机，有些是几毫秒，有些几十秒，真正爆发时，以该数据包文件来看，这台主机可以做到每秒数万的报文，到时候，估计将会出现全网瘫痪的现象。

       一台机器足以单挑一个的网络了！ 

阅读全文>>

标签: 组播 多播 ping 攻击 行为特征 发包频率 随机组播地址

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