安全的三要素——“保密性”、“完整性”和“可用性”中，DOS（Denial of Service拒绝服务攻击）所针对的目标是服务的“可用性”。这种攻击方式利用目标系统的网络服务功能缺陷或者直接消耗系统资源（主要是网络资源），使得该目标系统无法提供正常的服务。
DDOS 攻击(Distributed Denial of Service分布式拒绝服务)指攻击者操纵多台客户端(称为肉鸡或傀儡机)，联合起来对一个或多个目标发动DDoS攻击（同时攻击或按一定策略攻击），以提高拒绝服务的攻击效果。
某种意义上讲，没有“可用性”，何谈“保密性”和“完整性”？缺少DDOS防御的网络服务，随时都有从网络上”消失”的危险。DDOS攻击是目前最强大的，最难防御的攻击之一，和单纯的技术攻击手段相比，DDOS攻击更像是一种流氓或者强盗行为，即所谓的流氓会武术。
网络中的大部分数据都使用TCP/IP协议传输（包括其他如UDP等）,这些数据包必须遵循严格的协议标准，通常情况下满足这些协议的包对于目标服务和网络设备而言是正常数据，尤其是包含业务逻辑的数据，这些都是无害的；就像车站的检票员一样，如果乘客提供的车票合法可识别，且检票乘客均为正常乘车乘客，则检票过程通畅且安全；如果乘客提供的车票不合法或无法判断是否合法，再或者10个乘客中有9个站台票(甚至闲杂人等)，那么很明显检票员的大部分精力消耗在非法车票的识别或者非正常乘客上，从而影响正常乘客的检票流程；同时，如果大量非法乘客滞留在列车上，也会导致正常乘客无法进入列车。入口资源和服务资源，是最容易阻塞的位置和受到攻击的目标。
和检票员的工作流类似：1. 异常数据包(无用数据包)过多时，往往能造成网络设备或服务器的过载；2. 利用数据包或者协议的某些缺陷，人为的造一些不完成的畸形包，也会造成网络设备活服务器无法正常处理，从而产生拒绝服务；3. 尽管数据包正常，但不符合目标服务的正常业务逻辑，这种包的海量传输，也会造成拒绝服务。
总的来说，DDOS攻击的角度有如下两种：
然而，实际的网络环境很少有单一类型的攻击，混合型的攻击，以及正常流量和异常流量的各种组合，是当前攻击的主流方式；
DDOS攻击的常用示意图如下：
攻击者往往从互联网各种角落搞到大批肉鸡（傀儡机），并通过controller操作这些肉鸡向目标服务发起混合型攻击，比如syn flood或者dns query flood，甚至将其他网站的流量直接引到目标服务器，正所谓道高一尺魔高一丈，对于各种各样的DDOS攻击，业内并没有哪种防御手段能够在保证业务的同时防御所有类型DDOS攻击，更多的情况是在做两者的折中。
但DDOS的核心目的永远不会变，就是“对有限资源无限滥用”，包括直接滥用和间接滥用，已达到破坏“可用性”的目的。
Syn flood是最为经典的DDOS攻击，它利用了TCP/IP协议三次握手设计中的缺陷，以小博大，一直活跃了几十年，即使是现在，syn flood在互联网上已然很猖獗。Syn flood生命力过分强大的原因，在于它针对的是TCP/IP协议的缺陷，这个庞大的互联网的基础，想要修复或重构，几乎是不可能的。
攻击原理
三次握手的过程如下：
三次握手为了保证TCP的连接的可靠性，在第三次握手时做了一些异常处理，包括：
如果连接是伪造的，server会分配资源和时间来等待第三次握手，保证连接的可靠；当大量这种伪造的请求发起时，server需要大量的资源处理这种未完成三次握手的连接，且不断进行第三次握手的重试，结果就是没有资源处理正常的请求连接，而等待队列被这种恶意包占满，从而无法处理正常的连接请求，导致了拒绝服务。
防御syn flood的方法，通产的思路是弥补三次握手的缺陷，一方面减小缓解server资源压力，一方面是增大等待队列，还有就是减小重试次数。
Sync ookies可以起到缓解server资源压力的作用，它的处理方法是不再保存状态信息以等待client确认，而是以基于时间种子的随机数替代普通随机数作为syn初始序号y，当收到第三次握手时通过cookie校验算法确定是否和发出去的syn+ack序列号匹配，最终完成三次握手；
net.ipv4.tcp_max_syn_backlog参数(/etc/sysctl.conf，内核参数)则可以过server的内存换取更长的等待队列，使得攻击无法轻易的占满等待队列而产生拒绝服务；
net.ipv4.tcp_synack_retries则降低server第二次握手的syn+ack重试次数，不至于长时间占用资源；
提高协议自身抵抗力当然需要服务器额外的资源，所以实际情况如何处理，还需要考虑服务器配置性能和server业务进行折中。
除了提高协议自身能力外，防御syn flood还可以从异常行为识别下手，比如首包丢弃和黑白名单的思路；
首包丢弃的思路是丢弃掉client的首次报文，等待client 的syn的重传报文，有重传行为的IP则添加到白名单，没有重传行为的连接则认为是攻击行为；则处理过程为：
丢包重试的方案对syn flood起到明显的防御作用，然而这种方案缺不适合在server上处理——它对业务处理对产生负面的影响，比如影响时间增大等；一种思路是把首包丢弃的过程和业务处理过程分离出来，用专门的设备来处理——几乎所有的网络清洗设备都具备这种功能，丢包重试在这种清洗设备上有了更优化的方案，一般把这种放在其他设备上处理首包丢弃的方案叫做TCP Proxy。
不过事实上首包丢弃只是TCP Proxy狭义的一个功能，几乎所有和业务本身脱离的处理，都可以放在TCP Proxy端，比如上面提到的syn cookie和首包丢器结合的方式，在清洗设备上模拟server进行三次握手的验证，维护其黑白名单，并最终转发server的业务数据。成熟的清洗设备能够鉴别TCP包的更多异常和畸形，甚至通过模拟响应来鉴别客户端的攻击和恶意行为，并对这些流量进行清洗和过滤。
DNS Query Flood可以看做是UDP flood的升级版。UDP flood属于“流量型”DOS攻击，最常见的情况就是采用大量的UDP小包对骨干网和网络设备进行攻击。防御UDP Flood的难点在于它的无连接状态和五花八门的协议，不过提供UDP服务的IP很少，过滤伪造的IP相对比较容易，纯粹的UDP流量攻击慢慢也就变少了，而且大部分网络传输并不是UDP方式。但是流媒体服务和DNS这些以UPD为基础协议的服务，仍然是UDP Flood的重点攻击对象。
Query Flood的和UDP Flood最大的区别是Query Flood是应用层攻击而UDP Flood是协议层攻击。协议层次越高，和业务关联性越大，防御起来越难。Query Flood实际上执行的是真实的query，一种业务行为，但如果多台肉鸡同时发起这样的海量域名查询请求，对server来说则无法给正常的query请求返回结果，也就导致了拒绝服务。Query Flood为了增加攻击的随机性，不但需要像UDP flood一样在协议层伪造IP和端口，更需要在应用层伪造参数和域名等。随机性的目的，在于绕开dns服务器的过滤和缓存。
Query Flood的防御可以从以下三个层面考虑：
对域名进行授权，采取最小权限原则，非白名单中域名一律抛弃，以提高处理性能；
类似于首包丢弃的方法，首次DNS报文直接丢弃，强制client采取TCP方式进行域名Query；
增加DNS缓存和域名请求命中率，避免过多性能消耗；
这是一种与大多数攻击背道而驰的攻击手段，以慢著称，有些时间这种攻击很难被发现，它利用的是web server的一些特征来达到攻击目的，这种历史悠久的攻击现在看来有些情况下依然行之有效。
Slowloris攻击的是web server容器的并发上限，无论哪种web容器，都会对并发的连接数有一个上限，达到这个上限连接数后，web server无法接受新的请求，即：
当web server接收到新的http请求时，打开新的连接处理请求，处理完成后关闭这个连接；如果这个连接一直处理连接状态，新的http请需要打开新的连接进行处理；如果所有连接都一直处于连接状态，那么web server将服务处理任何新的请求。
Slowloris利用http的特性来达到这一目的：由于http请求以\r\n\r\n标识着headers的结束，如果web server只收到\r\n，则认为http headers部分没有结束，保持连接不放，等待后续的内容。实际的攻击中，一般是将http headers中的connections设置为keep-alive，这样web server会保持住这个TCP连接不断开，接下来间歇性的发送一些键值对到web server，就能一直保持着连接的不断开。当然也可以将content-length设置为很大，然后阶段性的post数据到web server，即HTTP POST DDOS。
这样的连接可以很容易的通过多线程或者肉鸡创建，不需要大量的流量，很快就能使web server的连接达到上限，而不再处理新的http请求。
防御Slowloris，同样需要从产生Slowloris的根本原因上进行考虑：1. TCP连接时间 2. http headers的传输时间 3. 每个TCP连接的报文数，所以Slowloris防御方法如下：
和上述几个典型的DDOS攻击相比，HTTP Flood攻击是最令人头疼的，因为目前所有的anti-ddos产品都没有行而有效的进行防御——这是因为HTTP Flood不是网络层攻击，而是一种应用层攻击。它有另外一个名字更为响亮，CC(Challenge Collapsar)，是挑战当时绿盟的一款叫做Collapsar(黑洞)的DDOS防御设备的一种挑衅的叫法。
网络层攻击都有着显著的特征，但是应用层的攻击，完全模拟用户请求，类似于各种搜索引擎和爬虫一样，这些攻击行为和正常的业务并没有严格的边界，很难辨别。CC的原理与其类似。
Web服务的性能受着相关资源的影响，直接资源包括CPU，MEM，DISK和NET（也就是性能测试的4个度量指标），这些资源受到数据库查询，网络带宽，文件大小，内存分配和算法等软硬件条件影响。
一些资源消耗较大的事务和页面，比如如果web应用涉及到分页和分表，很明显控制页面的参数过大，频繁的翻页会占用较多的web server资源，尤其在高并发频繁调用的时候，类似这样的事务，成了最早的CC攻击最早的目标。由于现在的攻击大都是混合型的，掺杂在正常的业务中，所以一般带有模拟用户行为的频繁操作都可以认为是CC攻击（哪些事务资源消耗严重也需要猜和判断）。但总体来说，CC这种应用层的攻击特点，就是和业务应用边界模糊。比如各种刷票软件对12306的访问，某种程度上就是CC攻击；另外某个网站或者店铺做了活动和宣传，导致忽然过多流量访问某天的忽然访问，如果web server无法支持这样突高的流量，也是一种类CC行为。
由于CC攻击瞄准的是web应用的后端业务，所以除了导致拒绝服务之外，还会直接影响web应用的功能和性能，比如影响web影响时间，影响数据库服务，影响磁盘读写等，这些都会导致功能和性能的异常。
另外，和前面提到的DDOS攻击相比，CC攻击更容易发起。由于它发起的流量属于正常的业务流量，很难被鉴别，所以很多时候不需要大量的肉鸡；互联网上有着丰富的HTTP代理，可以使用这些HTTP代理直接向目标发起HTTP攻击；甚至还可以入侵一个大流量网站，再将访问到这个网站的流量转发到目标位置。
尽管对CC来说目前并没有行之有效的防御手段，但是一些方法对CC攻击还是有一定的防御效果。
限制访问频率：可以通过IP和cookie定位客户端，并判断一段时间内的访问频率，如果过于频繁，可以暂时添加到黑名单，或直接返回错误页面；访问频率的逻辑也可以放在清洗设备上，对访问频率过高的客户端直接添加黑名单。这种方法简单，但是有两点不足：1. 无法判断来自代理服务器的攻击 2. 误杀正常访问。
CDN缓存：缓存能够对CC起到缓和的作用，对于大部分请求可以使用缓存中的结果直接返回，单服务器适用，互联网服务同样适用；对于大型的互联网结构，一般都有CDN节点来做内容的缓存。
人机识别：最常用的人机识别方式是验证码，它的根本目的就是拦截请求的自动重放，但验证码在拦截自动请求的同时也影响用户体验，另外如果验证码的不是足够的“随机”，通过彩虹表还是可以绕开；判断User-agent也是一种方法，但是User-agent也是可以修改的，遇到这种自动请求会失效；利用客户端解析JS(或者flash)也是一种判断方法：模拟的请求无法像客户端(浏览器)一样解析JS，发送一段JS 到客户端，收到正常跳转则正常处理并添加到白名单。
Web容器：web容器自身也提供一些防御能力，可以通过配置参数根据业务需求进行折中处理，比如一些如timeout，maxclients，alivetimtout等参数。
互联网的发展，让越来越多的人们享受到网络技术带来的便利，也正因为如此，互联网面临的安全问题也日益严重，道高一尺魔高一丈，防御方法需要不断的研究改进以应对花样百出的攻击手段。
近几年迅速崛起的云生态圈，当然也需要应对各种各样的安全攻击。和云生态的复杂性一样，此时的DDOS攻击，也不再是纯粹单一的DDOS攻击。
供应商网络，骨干网，IDC入口，集群，CDN，负载均衡，主机，服务等等很多点部署在一起，支撑起庞大的云生态网络。
这样多层次庞大复杂的网络环境中，任何一点出现问题，都可能对业务带来影响；甚至有些攻击不再基于某一单一层次，而是基于多个层次组合上的漏洞或者缺陷。所以长链路的系统拓宽了DDOS攻击的目标范围，而越来越多的组件和服务迁移到云上，任何组件都可能导致业务线出现故障。
另外，由于不同用户的业务位于一个相同的物理机上，任何一个用户的业务受到攻击，都可能影响其他用户的业务。
正所谓没有新的元素，只有新的组合。高级的攻击都会根据目标的攻击范围和环境，进行多层次多方法的组合。这种混合攻击包括欺骗性、针对性和混淆性等等。
欺骗性：比如syn flood攻击时可以加入进行验证的syn+ack报文，以此混淆清洗设备的syn cookie检测，加强攻击效果和清洗设备压力。这样的欺骗性混合，往往需要对网络设别的清洗和判断策略有一定的了解，打的是攻防仗，任何策略泄露或被猜到，都会带来严重的后果。
针对性：互联网的混合攻击针对性比较强，比如CC攻击不再模拟用户浏览器操作的请求，而直接模拟web api的调用，这种调用的正常业务也是自动的，在CC中加入这种业务，使得攻击和正常业务界限更为模糊，清洗设备更难过滤。
混淆性：最简单的混合攻击就是几种DDOS攻击直接混合，比如syn flood, slowloris和CC混合在一起进行攻击，这种方式会让清洗设备压力增大，而且如果服务受到了攻击，工作人员需要花时间判断是哪种攻击导致的。
由于越来越多的组件服务和应用迁移到云这个复杂且庞大的网络环境中，处于顶层的各种应用，成了各种DDOS攻击的目标，云环境下应对DDOS的难点在于，使用大部分处于应用层以下的设备和环境来防御集中在应用层的攻击，而基础设施和应用的关系是支撑和保护，不能直接控制应用。如何防御应用层的DDOS攻击，是当前云生态圈下DDOS防御面临的最大问题。
云环境不但提供了弹性计算，CDN，存储等各种服务，还提供了虚拟主机，VIP和通畅的带宽，这样的环境为中小公司提供了更好的创业环境的同时，也为黑客提供了资源。
比如国内的一个特殊的职业——黄牛，每年春运购票高峰时，他们的需求便接踵而来。他们是云服务的客户之一——按时间和宽带购买大量主机，直接部署自己的镜像，然后开始使用这些主机进行刷票，几百台主机在云环境下几乎秒杀火车票。主机购买的时长（比如1小时）对于黄牛刷火车票来说足够用了，对于黄牛来说这样的成本是很低的。
然而对于12306来说这无疑是一个噩梦，尽管是正常的业务访问，某种意义上看却是攻击，而且直击核心业务——不但正常的用户无法登陆和操作，而且连票都卖完了，购票网站还混啥呢？
同样的道理，黄牛如果真的是黑客呢？如果这些主机不是购买的而是入侵的呢？这些主机也就成了性能良好的傀儡机，为黑客提供了便利。
云生态下的创业公司是痛苦的，一方面要遭受黑客和同行的攻击，一方面还要花钱购买各种云服务和安全服务。在感叹的同时也要为奋斗在安全防御产品线的同事们辩解一下，和其他应用相比，安全体系往往需要投入更多的人力来维护。
安全防御这件事，与其说是技术系统，不如说是人工运维体系。因为安全防御本身就一个半自动化的体系，看似高大上的安全产品，其实都是后端各种攻防战的积累。DDOS防御也脱离不了各部门的应急和处理，比如运营，运维，开发，测试，客服，网工等等，正常情况下运营和网工也需要保持电话通畅和网络可用，甚至路边散步的时候忽然就需要打开电脑人工处理某个攻击事件。
所以选择攻击的时机，也是攻击成败的一个因素。人员工作时间有早晚，应用的业务处理白天和晚上也不同，网络的拥堵也不同。之前在一个互联网公司工作过，团建的时候是禁止发活动相关的微博的，因为竞争对手会在团建的时候做自己的安排，如发布新版本和攻击等。
安全的攻防，是个持续的过程，而且绝对的结果导向；对于攻击方来说，使用哪种技术和漏洞不重要，攻击的结果才重要，所有对结果有影响的任何要素都需要考虑。
互联网和云环境的DDOS防御，目前来说依然是一个挑战，因为防御的目标不再是一个应用或者服务，而是一个生态圈。
纵深防御是白帽子的一个原则，云生态的DDOS防御同样适用。每个层次必须有自己各自的安全防护，不依赖于其他层面的保护，且有自身的告警和跟踪。
针对不同层次的安全防御进行规划，才能从整体出发构建整体的防御体系。不同层面有不同层面的特点，实施的安全措施也不同，相互配合才能保证整体的安全；另外，有些攻击需要在某些层次做针对性的防御，比如syn flood和slowloris的这样的防御可以放到清洗设备中，而防火墙可以做网络底层的防御，主机安全负责云主机的应用安全，内部防火墙则在主机被控制为傀儡机时切断和controller的连接，而SLB和CDN层上也需要的一定的清洗和过滤。
随着云生态的逐渐成熟，云服务的需求量也不断增加，包含横向和纵向的扩展，比如扩容和最小化环境部署。
在这里，扩容指有服务器达到上限或新功能特殊需要扩建新的服务集群，最小化部署指将云生态的全部或部分缩放部署在某个局域网内，比如现在各云厂商都在推的私有云。
云产品的安全防御，属于云生态的默认属性，云环境扩容或者最小化部署的同时，要求安全防御也要有这种”最小化部署”的可移植性：一方面虚拟&物理的安全设备，可以部署在网络的任何地方；另一方面，整套安全防御体系可以随云的移动而移动，复制到任何部署云的地方。
这里提到的引擎指WAF，IPS，IDS，DLP。互联网云生态环境，要求这些引擎更加强大，并且可以为处于各层次的节点提供引擎服务。
一方面引擎要保证最小粒度的可见，能够方便的部署在其他层面或者直接提供服务；另一方面云生态的内部也要防御层次间的安全和攻击问题。
保证引擎粒度的最小可见性，对于一个优秀的云环境，是必须的。
前面提到，应用层的DDOS攻击会直接带来业务层的影响，而云生态中面临的业务安全并不仅仅是DDOS攻击带来了，也包含其他技术攻击(注入、钓鱼、暴力破解等)和业务攻击(欺诈等)，所以在构架安全防御的体系中，业务安全自身也要集成到体系中。
业务安全包含的范畴比较广，更多的是网状的结构，不同的业务对自身安全要求也不同，所以业务安全的集成，更多的是以服务的形式对外提供。
和业务集成安全类似，云体系的安全防御体系需要逐步的服务化，并对外输出。
首先，不同用户的业务不同，对安全的业务需求也不同——游戏行业对DDOS攻击的防御需求远大于普通网站业务，所以在防御力度上用户需要有所选择；
另一方面，有些用户对云服务提供的默认安全引擎和设备并不满意，希望能够选择其他的引擎和设备。
基础这些考虑，云生态对外提供各种服务的同时，也将安全服务化，并提供对外服务方式，如接口或者相关的页面操作。
除了防御体系的整体策略需要考虑外，安全技术之外的一些架构处理也可以配合防御，云生态是一个整体，靠各层配合；云安全同样也是一个整体，需要各层的配合。享受安全防御体系保护的同时，去配合安全体系建设，是云体系中各层的架构需要。
大型互联网服务，都具有支撑业务的备份和缓存服务，这些对安全防御有着重要作用：备份可以加快告警后的处理并且降低损失，缓存对于DDOS攻击更是起到的缓和作用。正因为如此，CDN节点数量从某种角度来说，可以衡量一个系统的DDOS防御能力。
除了CDN节点数量外，每个节点的VIP分配需要根据实际攻击情况处理，比如对一定数量的VIP，可以根据CDN节点遭受攻击的严重程度和VIP被攻击的频率做好VIP的重新分配，优先对哪些CDN节点分配哪些VIP，得到的DDOS防御能力是不同的。
另外，对于分布式的CDN，受到大流量攻击时如何分流到不同节点，动态轮询和hash的结果，也不会相同。
负载均衡服务，除了提供了负载均衡和VIP外，还可以提供负载均衡层面的监控数据，比如流量相关：bps, pps, qps等；连接相关：VIP、TCP等连接的 newconns, concurconns；业务相关：业务处理量，失败处理等。
虽然大型的互联网服务系统都会有专门的系统做分光后的流量分析，但这些分析是通用的，并不能做某一层专属的分析；另外，业务相关的分析，也只能由每一层做自身特定的处理。
除了在策略和架构角度的考虑，一些常用的安全的原则和技巧在云安全防御体系中也是经常用到的，这里只做简单的介绍。
最小权限原则是安全的基本原则之一，要求只授予必要权限，不必要的权限不能授权。云环境中，每层内部需要梳理本层的业务需求和权限，保证其他层次调用时使用最小权限，其他权限的操作采取不信任的态度。
黑白名单也是安全的基本原则之一，相对于“最小权限”在多种权限上的信任，黑白名单的信任建立在绝对互斥的基础上，非白即黑或非黑即白。很多时候安全的防御过程，就是条件判断的过程，这个过程中黑白名单起着绝对重要的作用。
但在云生态这种多层次的防御环境下，黑白名单的使用也需要注意一些问题：
由于不同业务和层次关系关注各自不同的策略和规则，分层使用黑白名单不但益处维护，也减少故障的产生。
之前在CC的防御里提到了使用清洗设备使用IP和Cookie定位客户端计算访问频率，但对于应用层来说访问频率并不是绝对的，所以很容易出现误杀的情况。
一种做法是访问频率的判断交由各层处理，这样的判断结果更具有针对性，且各自的判断算法也不相同，效果会更好。
目前的一种成熟做法，是在旁路对访问频率做监控，当访问连接超过预定阈值，切换清洗设备对主路流量做清洗操作，最终通过清洗的结果决策下一步操作。
在CC中提到过人机识别和典型的人机识别，即验证码，人机识别的根本目的是判断请求是否由机器重发，但识别的过程也面临着问题。
验证码的缺点之前提到过，影响用户体验，而且不够随机的情况下验证码同样可以绕过，在用户体验和识别的过程上，很难做到一个折中。
之前参与过一个刷票软件的开发，经历了12306验证码的各种变革，最终12306还是没有一个好的方案通过验证码过滤掉所有刷票提交操作——有时候自动化对图像的识别能力比人眼还好使，那么显然验证码在这种情况下没有达到设计初衷。
人机识别面临的模糊边界显然不止这些，比如之前提到的webapi的调用。这些接口的调用，本来就是由程序发起的，如果程序不断循环调用，那么是否也是一种攻击呢？
无论验证码，还是更复杂的访问频率计算，或者其他人机识别方法，想提高识别的精度需要更复杂的计算；然而无论再好的算法，做流量分析的时候，都无法保证速度和精度的双赢。随着机器学习和离线数据处理的发展，相信在人机识别上会有更好的方案出来。
之前提到了，DDOS的防御永远都是一个攻防战，处在半自动的积累过程中，想要有更好的防御效果，需要良好的监控，组织和流程来支持。看似简单的攻击处理，都是处于各流程的同事的积累和配合。
相关文章
