本文将对DDOS攻击的原理做一个剖析，并提供一些解决方法。
一. DDOS攻击
什么是DDOS？DDOS是英文Distributed Denial of Service的缩写，意即"分布式拒绝服务",DDOS的中文名叫分布式拒绝服务攻击，俗称洪水攻击。首先，我们来了解一下相关定义。
服务：系统提供的，用户在对其使用中会受益的功能
拒绝服务：任何对服务的干涉如果使其可用性降低或者失去可用性均称为拒绝服务。
拒绝服务攻击：是指攻击者通过某种手段，有意地造成计算机或网络不能正常运转从而不能向合法用户提供所需要的服务或者使得服务质量降低
分布式拒绝服务攻击：处于不同位置的多个攻击者同时向一个或者数个目标发起攻击，或者一个或多个攻击者控制了位于不同位置的多台机器并利用这些机器对受害者同时实施攻击，由于攻击的发出点是分布在不同地方的，这类攻击称为分布式拒绝服务攻击。
 |
| 图 |
如图所示，DDOS攻击将造成网络资源浪费、链路带宽堵塞、服务器资源耗尽而业务中断。这种攻击大多数是由黑客非法控制的电脑实 施的。黑客非法控制一些电脑之后，把这些电脑转变为由地下网络远程控制的“bots”，然后用这些电脑实施DDOS攻击。黑客还以每台为单位，低价出租这 些用于攻击的电脑，真正拥有这些电脑的主人并不知道自己的计算机已经被用来攻击别人。由于有数百万台电脑现在已经被黑客变成了“bots”，因此这种攻击 将非常猛烈。被DDoS攻击时的现象：
网络中充斥着大量的无用的数据包；
制造高流量无用数据，造成网络拥塞，使受害主机无法正常和外界通讯；
利用受害主机提供的服务或传输协议上的缺陷，反复高速的发出特定的服务请求，使受害主机无法及时处理所有正常请求；
严重时会造成系统死机。
由于网络层的拒绝服务攻击有的利用了网络协议的漏洞，有的则抢占网络或者设备有限的处理能力，使得对拒绝服务攻击的防治成为了一个令管理员非常头痛的问题。尤其是目前在大多数的网络环境骨干线路上普遍使用的防火墙、负载均衡等设备，在发生DDoS攻击的时候往往成为整个网络的瓶颈，造成全网的瘫痪。
二. 数据包结构
要了解DDOS的攻击原理，就要首先了解一下数据包的结构，才能知根知底，追本溯源。首先来回顾一下数据包的结构。
2.1 IP报文结构
 |
| 图 |
2.2 TCP报文结构
 |
| 图 |
一个TCP报头的标识（code bits）字段包含6个标志位：
SYN：标志位用来建立连接，让连接双方同步序列号。如果SYN＝1而ACK=0，则表示该数据包为连接请求，如果SYN=1而ACK=1则表示接受连接
FIN：表示发送端已经没有数据要求传输了，希望释放连接。
RST：用来复位一个连接。RST标志置位的数据包称为复位包。一般情况下，如果TCP收到的一个分段明显不是属于该主机上的任何一个连接，则向远端发送一个复位包。
URG：为紧急数据标志。如果它为1，表示本数据包中包含紧急数据。此时紧急数据指针有效。
ACK：为确认标志位。如果为1，表示包中的确认号时有效的。否则，包中的确认号无效。
PSH：如果置位，接收端应尽快把数据传送给应用层, 不必等缓冲区满再发送 。
2.3 UDP报文结构
 |
| 图 |
2.4 ICMP报文结构
 |
| 图 |
 |
| 图 |
三. DDOS攻击方式
3.1 SYN Flood攻击
SYN- Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击，它利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量 的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现，但至今仍然显示 出强大的生命力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。它的数据包特征通常 是，源发送了大量的SYN包，并且缺少三次握手的最后一步握手ACK回复。
3.1.1 原理
例如，攻击者首先伪造地址对 服务器发起SYN请求（我可以建立连接吗？），服务器就会回应一个ACK+SYN（可以+请确认）。而真实的IP会认为，我没有发送请求，不作回应。服务 器没有收到回应，会重试3-5次并且等待一个SYN Time（一般30秒-2分钟）后，丢弃这个连接。
如果攻击者大量发送这种伪造源地址的 SYN请求，服务器端将会消耗非常多的资源来处理这种半连接，保存遍历会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行 SYN+ACK的重试。最后的结果是服务器无暇理睬正常的连接请求—拒绝服务。在服务器上用netstat –an命令查看SYN_RECV状态的话，就可以看到：
 |
| 图 |
如果我们抓包来看：
 |
| 图 |
可以看到大量的SYN包没有ACK回应。
3.1.2 SYN Flood防护
目 前市面上有些防火墙具有SYN Proxy功能，这种方法一般是定每秒通过指定对象（目标地址和端口、仅目标地址或仅源地址）的SYN片段数的阀值，当来自相同源地址或发往相同目标地址 的SYN片段数达到这些阀值之一时，防火墙就开始截取连接请求和代理回复SYN/ACK片段，并将不完全的连接请求存储到连接队列中直到连接完成或请求超 时。当防火墙中代理连接的队列被填满时，防火墙拒绝来自相同安全区域（zone）中所有地址的新SYN片段，避免网络主机遭受不完整的三次握手的攻击。但是，这种方法在攻击流量较大的时候，连接出现较大的延迟，网络的负载较高，很多情况下反而成为整个网络的瓶颈；
Random Drop：随机丢包的方式虽然可以减轻服务器的负载，但是正常连接的成功率也会降低很多；
特征匹配：IPS上会常用的手段，在攻击发生的当时统计攻击报文的特征，定义特征库，例如过滤不带TCP Options 的syn 包等；
早 期攻击工具（例如synkiller，xdos，hgod等）通常是发送64字节的TCP SYN报文，而主机操作系统在发起TCP连接请求时发送SYN 报文是大于64字节的。因此可以在关键节点上设置策略过滤64字节的TCP SYN报文，某些宣传具有防护SYN Flood攻击的产品就是这么做的。随着工具的改进，发出的TCP SYN 报文完全模拟常见的通用操作系统，并且IP头和TCP头的字段完全随机，这时就无法在设备上根据特定的规则来过滤攻击报文。这时就需要根据经验判断IP 包头里TTL值不合理的数据包并阻断，但这种手工的方法成本高、效率低。 图是某攻击工具属性设置。
 |
| 图 |
SYN Cookie：就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，以后从这个 IP地址来的包会被丢弃。但SYN Cookie依赖于对方使用真实的IP地址，如果攻击者利用SOCK_RAW随机改写IP报文中的源地址，这个方法就没效果了。
3.1.3 商业产品的防护算法
syn cookie/syn proxy类防护算法：这种算法对所有的syn包均主动回应，探测发起syn包的源IP地址是否真实存在；如果该IP地址真实存在，则该IP会回应防护设备的探测包，从而建立TCP连接；大多数的国内外抗拒绝服务产品采用此类算法。
safereset算法：此算法对所有的syn包均主动回应，探测包特意构造错误的字段，真实存在的IP地址会发送rst包给防护设备，然后发起第2次连接，从而建立TCP连接；部分国外产品采用了这样的防护算法。
syn重传算法：该算法利用了TCP/IP协议的重传特性，来自某个源IP的第一个syn包到达时被直接丢弃并记录状态，在该源IP的第2个syn包到达时进行验证，然后放行。
综 合防护算法：结合了以上算法的优点，并引入了IP信誉机制。当来自某个源IP的第一个syn包到达时，如果该IP的信誉值较高，则采用syncookie 算法；而对于信誉值较低的源IP，则基于协议栈行为模式，如果syn包得到验证，则对该连接进入syncookie校验，一旦该IP的连接得到验证则提高 其信誉值。有些设备还采用了表结构来存放协议栈行为模式特征值，大大减少了存储量。
3.2 ACK Flood攻击
3.2.1 原理
ACK Flood攻击是在TCP连接建立之后，所有的数据传输TCP报文都是带有ACK标志位的，主机在接收到一个带有ACK标志位的数据包的时候，需要检查该 数据包所表示的连接四元组是否存在，如果存在则检查该数据包所表示的状态是否合法，然后再向应用层传递该数据包。如果在检查中发现该数据包不合法，例如该 数据包所指向的目的端口在本机并未开放，则主机操作系统协议栈会回应RST包告诉对方此端口不存在。
这里，服务器要做两个动作：查表、回应 ACK/RST。这种攻击方式显然没有SYN Flood给服务器带来的冲击大，因此攻击者一定要用大流量ACK小包冲击才会对服务器造成影响。按照我们对TCP协议的理解，随机源IP的ACK小包应 该会被Server很快丢弃，因为在服务器的TCP堆栈中没有这些ACK包的状态信息。但是实际上通过测试，发现有一些TCP服务会对ACK Flood比较敏感，比如说JSP Server，在数量并不多的ACK小包的打击下，JSP Server就很难处理正常的连接请求。对于Apache或者IIS来说，10kpps的ACK Flood不构成危胁，但是更高数量的ACK Flood会造成服务器网卡中断频率过高，负载过重而停止响应。可以肯定的是，ACK Flood不但可以危害路由器等网络设备，而且对服务器上的应用有不小的影响。抓包：
 |
| 图 |
如果没有开放端口，服务器将直接丢弃，这将会耗费服务器的CPU资源。如果端口开放，服务器回应RST。
3.2.2 ACK Flood防护
利用对称性判断来分析出是否有攻击存在。所谓对称型判断，就是收包异常大于发包，因为攻击者通常会采用大量ACK包，并且为了提高攻击速度，一般采用内容基本一致的小包发送。这可以作为判断是否发生ACK Flood的依据，但是目前已知情况来看，很少有单纯使用ACK Flood攻击，都会和其他攻击方法混合使用，因此，很容易产生误判。
一 些防火墙应对的方法是：建立一个hash表，用来存放TCP连接“状态”，相对于主机的TCP stack实现来说，状态检查的过程相对简化。例如，不作sequence number的检查，不作包乱序的处理，只是统计一定时间内是否有ACK包在该“连接”(即四元组)上通过，从而“大致”确定该“连接”是否是“活动的 ”。
3.3 UDP Flood攻击
3.3.1 原理
UDP Flood是日渐猖厥的流量型DoS攻击，原理也很简单。常见的情况是利用大量UDP小包冲击DNS服务器或Radius认证服务器、流媒体视频服务器。 100k pps的UDP Flood经常将线路上的骨干设备例如防火墙打瘫，造成整个网段的瘫痪。由于UDP协议是一种无连接的服务，在UDP FLOOD攻击中，攻击者可发送大量伪造源IP地址的小UDP包。但是，由于UDP协议是无连接性的，所以只要开了一个UDP的端口提供相关服务的话，那 么就可针对相关的服务进行攻击。
正常应用情况下，UDP包双向流量会基本相等，而且大小和内容都是随机的，变化很大。出现UDP Flood的情况下，针对同一目标IP的UDP包在一侧大量出现，并且内容和大小都比较固定。攻击工具：
 |
| 图 |
53端口的UDP Flood攻击抓图：
 |
| 图 |
UDP Flood大包攻击（占带宽，分片）：
 |
| 图 |
3.3.2 UDP Flood防护
UDP协议与TCP 协议不同，是无连接状态的协议，并且UDP应用协议五花八门，差异极大，因此针对UDP Flood的防护非常困难。其防护要根据具体情况对待：
判断包大小，如果是大包攻击则使用防止UDP碎片方法：根据攻击包大小设定包碎片重组大小，通常不小于1500。在极端情况下，可以考虑丢弃所有UDP碎片。
攻击端口为业务端口：根据该业务UDP最大包长设置UDP最大包大小以过滤异常流量。
攻击端口为非业务端口：一个是丢弃所有UDP包，可能会误伤正常业务；一个是建立UDP连接规则，要求所有去往该端口的UDP包，必须首先与TCP端口建立TCP连接。不过这种方法需要很专业的防火墙或其他防护设备支持。
3.4 ICMP Flood攻击
3.4.1 原理
ICMP Flood 的攻击原理和ACK Flood原理类似，属于流量型的攻击方式，也是利用大的流量给服务器带来较大的负载，影响服务器的正常服务。由于目前很多防火墙直接过滤ICMP报文， 因此ICMP Flood出现的频度较低。比较下面两幅图，就应该可以看出是否有ICMP Flood攻击。
正常ICMP包：
 |
| 图 |
大包攻击的时候：
 |
| 图 |
3.4.2 ICMP Flood防护
其防御也很简单，直接过滤ICMP报文。这里就不做详细说明。
3.5 Connection Flood攻击
3.5.1 原理
Connection Flood是典型的并且非常的有效的利用小流量冲击大带宽网络服务的攻击方式，这种攻击方式目前已经越来越猖獗。这种攻击的原理是利用真实的IP地址向服 务器发起大量的连接，并且建立连接之后很长时间不释放，占用服务器的资源，造成服务器服务器上残余连接(WAIT状态)过多，效率降低，甚至资源耗尽，无 法响应其他客户所发起的连接。
其中一种攻击方法是每秒钟向服务器发起大量的连接请求，这类似于固定源IP的SYN Flood攻击，不同的是采用了真实的源IP地址。通常这可以在防火墙上限制每个源IP地址每秒钟的连接数来达到防护目的。但现在已有工具采用慢速连接的 方式，也即几秒钟才和服务器建立一个连接，连接建立成功之后并不释放并定时发送垃圾数据包给服务器使连接得以长时间保持。这样一个IP地址就可以和服务器 建立成百上千的连接，而服务器可以承受的连接数是有限的，这就达到了拒绝服务的效果。
另外，蠕虫大规模爆发的时候，由于蠕虫代码则比较简单，传播过程中会出现大量源IP地址相同的包，对于 TCP 蠕虫则表现为大范围扫描行为。这是在判断Connection Flood时需要注意的。
在受攻击的服务器上使用netstat –an来看：
 |
| 图 |
存 在大量连接状态，来自少数的几个源。如果统计的话，可以看到连接数对比平时出现异常。并且增长到某一值之后开始波动，说明此时可能已经接近性能极限。因 此，对这种攻击的判断：在流量上体现并不大，甚至可能会很小；大量的ESTABLISH状态；新建的ESTABLISH状态总数有波动。
3.5.2 Connection Flood防护
主动清除残余连接。
对恶意连接的IP进行封禁。
限制每个源IP的连接数。
可以对特定的URL进行防护。
反查Proxy后面发起HTTP Get Flood的源。
3.6 HTTP Get攻击
3.6.1 原理
这种攻击主要是针对存在ASP、JSP、PHP、CGI等脚本程序，并调用MSSQLServer、MySQLServer、Oracle等数据库的网站系 统而设计的，特征是和服务器建立正常的TCP连接，并不断的向脚本程序提交查询、列表等大量耗费数据库资源的调用，典型的以小博大的攻击方法。一般来说， 提交一个GET或POST指令对客户端的耗费和带宽的占用是几乎可以忽略的，而服务器为处理此请求却可能要从上万条记录中去查出某个记录，这种处理过程对 资源的耗费是很大的，常见的数据库服务器很少能支持数百个查询指令同时执行，而这对于客户端来说却是轻而易举的，因此攻击者只需通过Proxy代理向主机 服务器大量递交查询指令，只需数分钟就会把服务器资源消耗掉而导致拒绝服务，常见的现象就是网站慢如蜗牛、ASP程序失效、PHP连接数据库失败、数据库 主程序占用CPU偏高。这种攻击的特点是可以完全绕过普通的防火墙防护，轻松找一些Proxy代理就可实施攻击，缺点是对付只有静态页面的网站效果会大打 折扣，并且有些Proxy会暴露攻击者的IP地址。攻击工具：
 |
| 图 |
在遭受攻击的服务器上抓包，大量不同IP在请求资源。在实际情况中，也有可能使用代理地址连接。
 |
3.6.2 HTTP Get防护
对是否HTTP Get的判断，要统计到达每个服务器的每秒钟的GET 请求数，如果远远超过正常值，就要对HTTP协议解码，找出HTTP Get及其参数（例如URL等）。
然后判断某个GET 请求是来自代理服务器还是恶意请求。并回应一个带key的响应要求请求发起端作出相应的回馈。如果发起端并不响应则说明是利用工具发起的请求，这样HTTP Get请求就无法到达服务器，达到防护的效果。
3.7 UDP DNS Query Flood攻击
3.7.1 原理
UDP DNS Query Flood攻击实质上是UDP Flood的一种，但是由于DNS服务器的不可替代的关键作用，一旦服务器瘫痪，影响一般都很大。
UDP DNS Query Flood攻击采用的方法是向被攻击的服务器发送大量的域名解析请求，通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名，被攻击的DNS 服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存，如果查找不到并且该域名无法直接由服务器解析的时候，DNS 服务器会向其上层DNS服务器递归查询域名信息。域名解析的过程给服务器带来了很大的负载，每秒钟域名解析请求超过一定的数量就会造成DNS服务器解析域 名超时。
根据微软的统计数据，一台DNS服务器所能承受的动态域名查询的上限是每秒钟9000个请求。而我们知道，在一台P3的PC机上可以轻易 地构造出每秒钟几万个域名解析请求，足以使一台硬件配置极高的DNS服务器瘫痪，由此可见DNS 服务器的脆弱性。同时需要注意的是，蠕虫扩散也会带来大量的域名解析请求。
3.7.2 UDP DNS Query Flood防护
在UDP Flood的基础上对 UDP DNS Query Flood 攻击进行防护
根据域名 IP 自学习结果主动回应，减轻服务器负载（使用 DNS Cache）
对突然发起大量频度较低的域名解析请求的源 IP 地址进行带宽限制 在攻击发生时降低很少发起域名解析请求的源 IP 地址的优先级
限制每个源 IP 地址每秒的域名解析请求次数
四. 总结
看完这篇文章，您已经了解了7种主流的DDOS攻击方式，并且也了解了相应的解决方法。虽然道高一尺，魔高一丈，新的攻击方法也在源源不断出现。但是，只要您掌握了相应的原理，破解DDOS攻击并非难事，不过其前提是您在掌握原理的基础上，还需要有相应的软件、硬件来对抗。本文的最后，给出几个小题目，帮您回忆一下前面所说的内容。
1. 对上述方法的总结。
2. 如果您的主要业务是UDP音频应用，为了维护利益，尽可能降低攻击对其业务的影响，您平时应该如何关注？
3. 僵尸网络是个无坚不摧的矛吗？如何缓解来自僵尸网络的攻击带来的影响？如果一次ACK-Flood的攻击流量是通过僵尸网络发出来的，那么它通常会带有什么特征
转自http://netsecurity.51cto.com/art/200903/114969.htm,作者：戴鹏飞