从昨晚的18：50分开始，每隔30分钟左右进行10G流量的ddos***，实在没招，只能使用阿里云的高防IP来防御。
主要的***是：
趁此机会，全面了解DDos***： （以下是总结内容来源：
http://www.secpulse.com/archives/37785.html?utm_source=tuicool&utm_medium=referral
http://www.ijiandao.com/safe/cto/15952.html
DDoS（Distributed Denial of Service，分布式拒绝服务）***的主要目的是让指定目标无法提供正常服务，甚至从互联网上消失，是目前最强大、最难防御的***之一。这是一个世界级的难题并没有解决办法只能缓解.
1、网络层DDoS分类
SYN-FLOOD
SYN Flood是互联网上最经典的DDoS***方式之一，最早出现于1999年左右，雅虎是当时最著名的受害者。SYN Flood***利用了TCP三次握手的缺陷，能够以较小代价使目标服务器无法响应，且难以追查。
利用TCP建立连接时3次握手的“漏洞”，通过原始套接字发送源地址虚假的SYN报文，使目标主机永远无法完成3次握手，占满了系统的协议栈队列，资源得不到释放，进而拒绝服务，是互联网中最主要的DDOS***形式之一.标准的TCP三次握手过程如下：
1、客户端发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号；
2、服务器在收到客户端的SYN报文后，将返回一个SYN+ACK（即确认Acknowledgement）的报文，表示客户端的请求被接受，同时TCP初始序号自动加1；
3、客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加1。
经过这三步，TCP连接就建立完成。TCP协议为了实现可靠传输，在三次握手的过程中设置了一些异常处理机制。第三步中如果服务器没有收到客户端的最终ACK确认报文，会一直处于SYN_RECV状态，将客户端IP加入等待列表，并重发第二步的SYN+ACK报文。重发一般进行3-5次，大约间隔30秒左右轮询一次等待列表重试所有客户端。另一方面，服务器在自己发出了SYN+ACK报文后，会预分配资源为即将建立的TCP连接储存信息做准备，这个资源在等待重试期间一直保留。更为重要的是，服务器资源有限，可以维护的SYN_RECV状态超过极限后就不再接受新的SYN报文，也就是拒绝新的TCP连接建立。
SYN Flood正是利用了上文中TCP协议的设定，达到***的目的。***者伪装大量的IP地址给服务器发送SYN报文，由于伪造的IP地址几乎不可能存在，也就几乎没有设备会给服务器返回任何应答了。因此，服务器将会维持一个庞大的等待列表，不停地重试发送SYN+ACK报文，同时占用着大量的资源无法释放。更为关键的是，被***服务器的SYN_RECV队列被恶意的数据包占满，不再接受新的SYN请求，合法用户无法完成三次握手建立起TCP连接。也就是说，这个服务器被SYN Flood拒绝服务了。
网上有一些加固的方法，例如调整内核参数的方法，可以减少等待及重试，加速资源释放，在小流量syn-flood的情况下可以缓解，但流量稍大时完全不抵用。防御syn-flood的常见方法有：syn proxy、syn cookies、首包（第一次请求的syn包）丢弃等。
AKC-FLOOD
对于虚假的ACK包，目标设备会直接回复RST包丢弃连接，所以伤害值远不如syn-flood。DDOS的一种原始方式。
UDP-FLOOD
使用原始套接字伪造大量虚假源地址的UDP包，目前以DNS协议为主。
ICMP-FLOOD
Ping洪水，比较古老的方式。
2、应用层DDoS***
DNS 请求 FLOOD
作为互联网最基础、最核心的服务，DNS自然也是DDoS***的重要目标之一。打垮DNS服务能够间接打垮一家公司的全部业务，或者打垮一个地区的网络服务。前些时候风头正盛的***组织anonymous也曾经宣布要***全球互联网的13台根DNS服务器，不过最终没有得手。
UDP***是最容易发起海量流量的***手段，而且源IP随机伪造难以追查。但过滤比较容易，因为大多数IP并不提供UDP服务，直接丢弃UDP流量即可。所以现在纯粹的UDP流量***比较少见了，取而代之的是UDP协议承载的DNS Query Flood***。简单地说，越上层协议上发动的DDoS***越难以防御，因为协议越上层，与业务关联越大，防御系统面临的情况越复杂。
DNS Flood就是***者操纵大量傀儡机器，对目标发起海量的域名查询请求。为了防止基于ACL的过滤，必须提高数据包的随机性。常用的做法是UDP层随机伪造源IP地址、随机伪造源端口等参数。在DNS协议层，随机伪造查询ID以及待解析域名。随机伪造待解析域名除了防止过滤外，还可以降低命中DNS缓存的可能性，尽可能多地消耗DNS服务器的CPU资源。
伪造源地址的海量DNS请求，用于是淹没目标的DNS服务器。对于***特定企业权威DNS的场景，可以将源地址设置为各大ISP DNS服务器的ip地址以突破白名单限制，将查询的内容改为针对目标企业的域名做随机化处理，当查询无法命中缓存时，服务器负载会进一步增大。
DNS不只在UDP-53提供服务，同样在TCP协议提供服务，所以防御的一种思路就是将UDP的查询强制转为TCP，要求溯源，如果是假的源地址，就不再回应。对于企业自有权威DNS服务器而言，正常请求多来自于ISP的域名递归解析，所以将白名单设置为ISP的DNS server列表。对于源地址伪造成ISP DNS的请求，可以通过TTL值进一步判断。
Http Flood （cc）
上文描述的SYN Flood、DNS Query Flood在现阶段已经能做到有效防御了，真正令各大厂商以及互联网企业头疼的是HTTP Flood***。它的巨大危害性主要表现在三个方面：发起方便、过滤困难、影响深远。
SYN Flood和DNS Query Flood都需要***者以root权限控制大批量的傀儡机。收集大量root权限的傀儡机很花费时间和精力，而且在***过程中傀儡机会由于流量异常被管理员发现，***者的资源快速损耗而补充缓慢，导致***强度明显降低而且不可长期持续。HTTP Flood***则不同，***者并不需要控制大批的傀儡机，取而代之的是通过端口扫描程序在互联网上寻找匿名的HTTP代理或者SOCKS代理，***者通过匿名代理对***目标发起HTTP请求。匿名代理是一种比较丰富的资源，花几天时间获取代理并不是难事，因此***容易发起而且可以长期高强度的持续。
另一方面，HTTP Flood***在HTTP层发起，极力模仿正常用户的网页请求行为，与网站业务紧密相关，安全厂商很难提供一套通用的且不影响用户体验的方案。在一个地方工作得很好的规则，换一个场景可能带来大量的误杀。
最后，HTTP Flood***会引起严重的连锁反应，不仅仅是直接导致被***的Web前端响应缓慢，还间接***到后端的Java等业务层逻辑以及更后端的数据库服务，增大它们的压力，甚至对日志存储服务器都带来影响。
有意思的是，HTTP Flood还有个颇有历史渊源的昵称叫做CC***。CC是Challenge Collapsar的缩写，而Collapsar是国内一家著名安全公司的DDoS防御设备。从目前的情况来看，不仅仅是Collapsar，所有的硬件防御设备都还在被挑战着，风险并未解除。
互联网的架构追求扩展性本质上是为了提高并发能力，各种SQL性能优化措施：消除慢查询、分表分库、索引、优化数据结构、限制搜索频率等本质都是为了解决资源消耗，而CC大有反其道而行之的意味，占满服务器并发连接数，尽可能使请求避开缓存而直接读数据库，读数据库要找最消耗资源的查询，最好无法利用索引，每个查询都全表扫描，这样就能用最小的***资源起到最大的拒绝服务效果。
互联网产品和服务依靠数据分析来驱动改进和持续运营，所以除了前端的APP、中间件和数据库这类OLTP系统，后面还有OLAP，从日志收集，存储到数据处理和分析的大数据平台，当CC***发生时，不仅OLTP的部分受到了影响，实际上CC会产生大量日志，直接会对后面的OLAP产生影响，影响包括两个层面，一个当日的数据统计完全是错误的。第二个层面因CC期间访问日志剧增也会加大后端数据处理的负担。
CC是目前应用层***的主要手段之一，在防御上有一些方法，但不能完美解决这个问题。
慢速连接***
针对http协议，以知名的slowloris***为起源：先建立http连接，设置一个较大的content-length，每次只发送很少的字节，让服务器一直以为http头部没有传输完成，这样的连接一多很快就会出现连接耗尽。慢速连接***，最具代表性的是rsnake发明的Slowloris。
HTTP协议规定，HTTP Request以\r\n\r\n结尾表示客户端发送结束，服务端开始处理。那么，如果永远不发送\r\n\r\n会如何？Slowloris就是利用这一点来做DDoS***的。***者在HTTP请求头中将Connection设置为Keep-Alive，要求Web Server保持TCP连接不要断开，随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端，如a:b\r\n，导致服务端认为HTTP头部没有接收完成而一直等待。如果***者使用多线程或者傀儡机来做同样的操作，服务器的Web容器很快就被***者占满了TCP连接而不再接受新的请求。
目前出现了一些变种，http慢速的post请求和慢速的read请求都是基于相同的原理，比如POST方法向Web Server提交数据、填充一大大Content-Length但缓慢的一个字节一个字节的POST真正数据内容等等。
DOS***
有些服务器程序存在bug、安全漏洞，或架构性缺陷，***者可以通过构造的畸形请求发送给服务器，服务器因不能正确处理恶意请求而陷入僵死状态，导致拒绝服务。例如某些版本的app服务器程序存在缓冲区溢出，漏洞可以触发但无法得到shell，***者可以改变程序执行流程使其跳转到空指针或无法处理的地址，用户态的错误会导致进程挂起，如果错误不能被内核回收则可能使系统当掉。
这类问题效果也表现为拒绝服务，但本质上属于漏洞，可以通过patch程序的最新版本解决，笔者认为不属于DDOS的范畴。
3、***方式
混合型方式
以上介绍了几种基础的***手段，其中任意一种都可以用来***网络，甚至击垮阿里、百度、腾讯这种巨型网站。但这些并不是全部，不同层次的***者能够发起完全不同的DDoS***，运用之妙，存乎一心。
在实际大流量的***中，通常并不是以上述一种数据类型来***，往往是混杂了TCP和UDP流量，网络层和应用层***同时进行。
高级***者从来不会使用单一的手段进行***，而是根据目标环境灵活组合。普通的SYN Flood容易被流量清洗设备通过反向探测、SYN Cookie等技术手段过滤掉，但如果在SYN Flood中混入SYN+ACK数据包，使每一个伪造的SYN数据包都有一个与之对应的伪造的客户端确认报文，这里的对应是指源IP地址、源端口、目的IP、目的端口、TCP窗口大小、TTL等都符合同一个主机同一个TCP Flow的特征，流量清洗设备的反向探测和SYN Cookie性能压力将会显著增大。其实SYN数据报文配合其他各种标志位，都有特殊的***效果，这里不一一介绍。对DNS Query Flood而言，也有独特的技巧。
首先，DNS可以分为普通DNS和授权域DNS，***普通DNS，IP地址需要随机伪造，并且指明服务器要求做递归解析；但***授权域DNS，伪造的源IP地址则不应该是纯随机的，而应该是事先收集的全球各地ISP的DNS地址，这样才能达到最大***效果，使流量清洗设备处于添加IP黑名单还是不添加IP黑名单的尴尬处境。添加会导致大量误杀，不添加黑名单则每个报文都需要反向探测从而加大性能压力。
另一方面，前面提到，为了加大清洗设备的压力不命中缓存而需要随机化请求的域名，但需要注意的是，待解析域名必须在伪造中带有一定的规律性，比如说只伪造域名的某一部分而固化一部分，用来突破清洗设备设置的白名单。道理很简单，腾讯的服务器可以只解析腾讯的域名，完全随机的域名可能会直接被丢弃，需要固化。但如果完全固定，也很容易直接被丢弃，因此又需要伪造一部分。
其次，对DNS的***不应该只着重于UDP端口，根据DNS协议，TCP端口也是标准服务。在***时，可以UDP和TCP***同时进行。
HTTP Flood的着重点，在于突破前端的cache，通过HTTP头中的字段设置直接到达Web Server本身。另外，HTTP Flood对目标的选取也非常关键，一般的***者会选择搜索之类需要做大量数据查询的页面作为***目标，这是非常正确的，可以消耗服务器尽可能多的资源。但这种***容易被清洗设备通过人机识别的方式识别出来，那么如何解决这个问题？很简单，尽量选择正常用户也通过APP访问的页面，一般来说就是各种Web API。正常用户和恶意流量都是来源于APP，人机差别很小，基本融为一体难以区分。
之类的慢速***，是通过巧妙的手段占住连接不释放达到***的目的，但这也是双刃剑，每一个TCP连接既存在于服务端也存在于自身，自身也需要消耗资源维持TCP状态，因此连接不能保持太多。如果可以解决这一点，***性会得到极大增强，也就是说Slowloris可以通过stateless的方式发动***，在客户端通过嗅探捕获TCP的序列号和确认维护TCP连接，系统内核无需关注TCP的各种状态变迁，一台笔记本即可产生多达65535个TCP连接。
前面描述的，都是技术层面的***增强。在人的方面，还可以有一些别的手段。如果SYN Flood发出大量数据包正面强攻，再辅之以Slowloris慢速连接，多少人能够发现其中的秘密？即使服务器宕机了也许还只发现了SYN***想去加强TCP层清洗而忽视了应用层的行为。种种***都可以互相配合，达到最大的效果。***时间的选择，也是一大关键，比如说选择维护人员吃午饭时、维护人员下班堵在路上或者在地铁里无线上网卡都没有信号时、目标企业在举行大规模活动流量飙升时等。
反射型
2004年时DRDOS第一次披露，通过将SYN包的源地址设置为目标地址，然后向大量的
真实TCP服务器发送TCP的SYN包，而这些收到SYN包的TCP server为了完成3次握手把SYN|ACK包“应答”给目标地址，完成了一次“反射”***，***者隐藏了自身，但有个问题是***者制造的流量和目标收到的***流量是1:1，且SYN|ACK包到达目标后马上被回以RST包，整个***的投资回报率不高。
反射型***的本质是利用“质询-应答”式协议，将质询包的源地址通过原始套接字伪造设置为目标地址，则应答的“回包”都被发送至目标，如果回包体积比较大或协议支持递归效果，***流量会被放大，成为一种高性价比的流量型***。
反射型***利用的协议目前包括NTP、Chargen、SSDP、DNS、RPC portmap等等。
流量放大型
以上面提到的DRDOS中常见的SSDP协议为例，***者将Search type设置为ALL，搜索所有可用的设备和服务，这种递归效果产生的放大倍数是非常大的，***者只需要以较小的伪造源地址的查询流量就可以制造出几十甚至上百倍的应答流量发送至目标。
脉冲型
很多***持续的时间非常短，通常5分钟以内，流量图上表现为突刺状的脉冲。
之所以这样的***流行是因为“打-打-停-停”的效果最好，刚触发防御阈值，防御机制开始生效***就停了，周而复始。蚊子不叮你，却在耳边飞，刚开灯想打它就跑没影了，当你刚关灯它又来了，你就没法睡觉。
自动化的防御机制大部分都是依靠设置阈值来触发。尽管很多厂商宣称自己的防御措施都是秒级响应，但实际上比较难。
网络层的***检测通常分为逐流和逐包，前者根据netflow以一定的抽样比例（例如1000:1）检测网络是否存在ddos***，这种方式因为是抽样比例，所以精确度较低，做不到秒级响应。第二种逐包检测，检测精度和响应时间较短，但成本比较高，一般厂商都不会无视TCO全部部署这类方案。即便是逐包检测，其防御清洗策略的启动也依赖于阈值，加上清洗设备一般情况下不会串联部署，触发清洗后需要引流，因此大部分场景可以做秒级检测但做不到秒级防御，近源清洗尚且如此，云清洗的触发和转换过程就更慢了。所以利用防御规则的生效灰度期，在触发防御前完成***会有不错的效果，在结果上就表现为脉冲。
（我们受到的***就是这样。）
脉冲型
随着DDOS***技术的发展，又出现了一种新型的***方式link-flooding attack，这种方式不直接***目标而是以堵塞目标网络的上一级链路为目的。对于使用了ip anycast的企业网络来说，常规的DDOS***流量会被“分摊”到不同地址的基础设施，这样能有效缓解大流量***，所以***者发明了一种新方法，***至目标网络traceroute的倒数第二跳，即上联路由，致使链路拥塞。国内ISP目前未开放anycast，所以这种***方式的必要性有待观望。
对一级ISP和IXP的***都可以使链路拥塞。
来源：oschina
链接：https://my.oschina.net/u/4312161/blog/4344069