防Ddos文献之敌情篇-DDoS***原理
http://www.myhack58.com/Article/60/sort096/2014/42210.htm
相比常规的***测试***来说，DDoS***比前者更具危害性，为什么这么说呢？因为发动一次大规模的DDoS***只需要拥有一定数量的僵尸网络即可，而完成一个***测试是需要长期及一定的技术水平才可以。而实施后者（DDoS）的门槛相对前者来说低了许多，而造成的危害后果却不亚于前者，可以说DDoS***是目前最强大、最难防御的***之一。本文由阿里巴巴的高级专家编写，带领大家认识及了解这种***的防御办法。
1. DDoS***基础
DDoS（Distributed Denial of service，分布式拒绝服务）***的主要目的是让指定目标无法提供正常服务，甚至从互联网上消失，是目前最强大、最难防御的***之一。
按照发起的方式，DDoS可以简单分为三类：第一类以力取胜，海量数据包从互联网的各个角落蜂拥而来，堵塞IDC入口，让各种强大的硬件防御系统、快速高效的应急流程而无用武之地，这种类型的***典型代表是ICMP Flood和UDP Flood，现在已不常见；第二类以巧取胜，灵动难以察觉，每隔几分钟发一个包甚至只需要一个包，就可以让豪华配置的服务器不再响应。这类***主要是利用协议或者软件的漏洞发起，如Slowloris***，Hash冲突***等，需要特定环境机缘巧合下才能出现；第三类是上述两种的混合，轻灵浑厚兼而有之，既利用了协议、系统的缺陷，又具备了海量的流量，如SYN Flood***，DNS Query Flood***，是当前的主流***方式。
下文将一一描述这些最常见、最具代表性***方式，并介绍他们的防御方案。
1.1 SYN Flood
SYN Flood是互联网上最经典的DDoS***方式之一，最早出现于1999年左右，雅虎是当时最著名的受害者。SYN Flood***利用了TCP三次握手的缺陷，能够以较小代价使目标服务器无法响应，且难以追查。
标准的TCP三次握手过程如下：
* 客户端发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的 端口以及TCP连接的初始序号;
* 服务器在收到客户端的SYN报文后，将返回一个SYN ACK（即确认Acknowledgement）的报文，表示客户 端的请求被接受，同时TCP初始序号自动加一。
* 客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加一。
经过这三步，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有兴趣的可以看看这里，这是笔者2006年写的代码，后来做过几次修改，修改bug，并降低了***性，纯做测试使用。
1.2 DNS Query Flood
作为互联网最基础最核心的服务，DNS自然也是DDoS***的重要目标之一。打垮DNS服务能够间接的打垮了一个公司的全部业务，或者打垮一个地区的网络服务。前些时候风头正盛的***组织anonymous也曾经宣布要***全球互联网的13台根DNS服务器，不过最终没有得手。
UDP***是最容易发起海量流量的***手段，而且源IP随机伪造难以追查。但是过滤比较容易，因为大多数IP并不提供UDP服务，直接丢弃UDP流量即可。所以现在纯粹的UDP流量***比较少见了，取而代之的是UDP协议承载的DNS Query Flood***。简单地说，越上层协议上发动的DDoS***越难以防御，因为协议越上层，与业务关联越大，防御系统面临的情况越复杂。
DNS Query Flood就是***者操纵大量傀儡机器，对目标发起海量的域名查询请求。为了防止基于ACL的过滤，必须提高数据包的随机性。常用的做法是UDP层随机伪造源IP地址，随机伪造源端口等参数。在DNS协议层，随机伪造查询ID以及待解析域名。随机伪造待解析域名除了防止过滤外，还可以降低命中DNS缓存的可能性，尽可能多的消耗DNS服务器的CPU资源。
关于DNS Query Flood的代码，笔者2011年7月份为了测试服务器性能曾经写过一份代码，见这里。同样的，这份代码人为降低了***性，只做测试用途。
1.3 HTTP Flood
上文描述的SYN
Flood、DNS Query Flood在现阶段已经能做到有效防御了，真正另各大厂商以及互联网企业头疼的是HTTP Flood***。HTTP Flood是针对WEB服务在第七层协议发起的***，它巨大危害性主要表现在三个方面，发起方便；过滤困难；影响深远。
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，所有的硬件防御设备都还在被挑战着，风险并未解除。
1.4 慢速连接***
一提起***，第一反应就是海量的流量，海量的报文。但是有一种***却反其道而行之，以慢著称，以至于有些***目标被打死了都不知道是怎么死的，这就是慢速连接***，最具代表性的是rsnake发明的SlowLoris。
HTTP协议规定，HTTP Request以rnrn结尾表示客户端发送结束，服务端开始处理。那么，如果永远不发送rnrn会如何？SlowLoris就是利用这一点来做DDoS***。***者在HTTP请求头中将Connection设置为Keep-Alive，要求Web Server保持TCP连接不要断开，随后缓慢的每隔几分钟发送一个key value格式的数据到服务端，如a:brn，导致服务端认为HTTP头部没有接收完成而一直等待。如果***者使用多线程或者傀儡机来做同样的操作，服务器的WEB容器很快就被***者占满了TCP连接而不再接受新的请求。
很快的，SlowLoris开始出现各种变种。比如POST方法向WEB Server提交数据，填充一大大Content-Length但是缓慢的一个字节一个字节的POST真正数据内容的等等。关于SlowLoris***，rsnake也给出了一个测试代码，这里。
2. DDoS***进阶
2.1 混合***
前一章介绍了几种基础的***手段，其中任意一种都可以用来***网络，甚至击垮阿里、百度、腾讯这种巨型网站。但是这些并不是全部，不同层次的***者能够发起完全不同的DDoS***，运用之妙，存乎一心。
高级的***者从来不会使用单一的手段进行***，而是根据目标的环境灵活组合。普通的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，人机差别很小，基本融为一体难以区分。
SlowLoris之类的慢速***，是通过巧妙的手段占住连接不释放达到***的目的，但是这也是双刃剑，每一个TCP连接既存在于服务端也存在于自身，自身也需要消耗资源维持TCP状态因此连接不能保持太多。如果可以解决这一点，***性会得到极大增强，也就是说SlowLoris可以通过stateless的方式发动***，在客户端通过嗅探捕获TCP的序列号和确认维护TCP连接，系统内核无需关注TCP的各种状态变迁，一台笔记本即可产生多大65535个TCP连接。
上文描述的，都是技术层面的***增强。在人的方面，还可以有一些别的手段。如果SYN Flood发出大量数据包正面强攻，再辅之以SlowLoris慢速连接，多少人能够发现其中的秘密？即使服务器宕机了也许还只发现了SYN***想去加强TCP层清洗而忽视了应用层的行为。种种***，都可以互相配合，达到最大的效果。***时间的选择，也是一大关键，比如说选择维护人员吃午饭的时候，维护人员下班堵在路上或者在地铁里无线上网卡都没有信号的时候，或者目标企业在举行大规模活动流量飙升的时候，等等。
这里是纯粹的***性行为，因此不提供代码，也不做深入介绍。
2.2 来自P2P网络的***
前面的***方式，多多少少都需要一些傀儡机，即使是HTTP Flood也需要搜索大量的匿名代理。如果有一种***，只需要发出一些指令，就有机器自动上来执行，才是完美的方案。这种***已经出现了，那就是来自P2P网络的***。
大家都知道，互联网上的P2P用户和流量都是一个极为庞大的数字。如果他们都去一个指定的地方下载数据，成千上万的真实IP地址连接过来，没有哪个设备能够支撑住。拿BT下载来说，伪造一些热门视频的种子，发布到搜索引擎，就足以骗到许多用户和流量了，但是这只是基础***。
高级的P2P***，是直接欺骗资源管理服务器。如迅雷客户端会把自己发现的资源上传到资源管理服务器，然后推送给其它需要下载相同资源的用户，这样，一个链接就发布出去。通过协议逆向，***者伪造出大批量的热门资源信息通过资源管理中心分发出去，瞬间就可以传遍整个P2P网络。更为恐怖的是，这种***是无法停止的，即使是***者自身也无法停止，***一直持续到P2P官方发现问题更新服务器且下载用户重启下载软件为止。
应对篇 ——DDoS防御方案
http://www.myhack58.com/Article/60/sort096/2014/42211.htm
1. 防御基础
1.1 ***流量到底多大
DDoS防御，首先就是要知道到底遭受了多大的***。这个问题看似简单，实际上却有很多不为人知的细节在里面。
以SYN Flood为例，为了提高发送效率在服务端产生更多的SYN等待队列，***程序在填充包头的时候，IP首部和TCP首部都不填充可选的字段，因此IP首部长度恰好是20字节，TCP首部也是20字节，共40字节。
对于以太网来说，最小的包长度数据段必须达到46字节，而***报文只有40字节，因此，网卡在发送的时候，会作一些处理，在TCP首部的末尾，填充6个0来满足最小包的长度要求。这个时候，整个数据包的长度为14字节的以太网头，20字节的IP头，20字节的TCP头，再加上因为最小包长度要求而填充的6个字节的0，一共是60字节。
但是这还没有结束。以太网在传输数据的时候，还有CRC检验的要求。网卡会在发送数据之前对数据包进行CRC检验，将4字节的CRC值附加到包头的最后面。这个时候，数据包长度已经不再是40字节，而是变成了64字节了，这就是常说的SYN小包***。
到64字节的时候，SYN数据包已经填充完成，准备开始传输了。***数据包很小，远远不够最大传输单元（MTU）的1500字节，因此不会被分片。那么这些数据包就像生产流水线上的罐头一样，一个包连着一个包紧密的挤在一起传输的吗？事实上不是这样的。
以太网在传输的时候，还有前导码（preamble）和帧间距（inter-frame gap）。其中前导码占8字节（byte），64比特位。前导码前面的7字节都是10101010，1和0间隔而成。但是第八个字节就变成了10101011，当主机监测到连续的两个1的时候，就知道后面开始是数据了。在网络传输的时候，数据的结构如下：
| 8字节前导码 | 6字节目的MAC地址 | 6字节源MAC地址 | 2字节上层协议类型 | 20字节IP头 | 20字节TCP头 | 6字节以太网填充 | 4字节CRC检验 | 12字节帧间距
也就是说，一个本来只有40字节的SYN包，在网络上传输的时候占得带宽，其实是84字节。
有了上面的基础，现在可以开始计算***流量和网络设备的线速问题了。当只填充IP头和TCP头的最小SYN包跑在以太网络上的时候，100Mbit的网络，能支持的最大PPS（Packet Per Second）是100*10^6 / (8 * (64 8 12)) = 148809，1000Mbit的网络，能支持的最大PPS是1488090。
1.2 SYN Flood防御
前文的***介绍过描述过，SYN
Flood***大量消耗服务器的CPU、内存资源，并占满SYN等待队列。相应的，我们修改内核参数即可有效缓解。主要参数如下：
1
2
3
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2
分别为启用SYN
Cookie、设置SYN最大队列长度以及设置SYN ACK最大重试次数。
SYN Cookie的作用是缓解服务器资源压力。启用之前，服务器在接到SYN数据包后，立即分配存储空间，并随机化一个数字作为SYN号发送SYN ACK数据包。然后保存连接的状态信息等待客户端确认。启用SYN Cookie之后，服务器不再分配存储空间，而且通过基于时间种子的随机数算法设置一个SYN号，替代完全随机的SYN号。发送完SYN ACK确认报文之后，清空资源不保存任何状态信息。直到服务器接到客户端的最终ACK包，通过cookie检验算法鉴定是否与发出去的SYN ACK报文序列号匹配，匹配则通过完成握手，失败则丢弃。当然，前文的高级***中有SYN混合ACK的***方法，则是对此中防御方法的反击，其中优劣由双方的硬件配置决定。
tcp_max_syn_backlog则是使用服务器的内存资源，换取更大的等待队列长度，让***数据包不至于占满所有连接以至于正常用户无法完成握手。net.ipv4.tcp_synack_retries是降低服务器SYN ACK报文重试次数，尽快释放等待资源。这三种措施与***的三种危害一一对应，完完全全的对症下药。但是这些措施也是双刃剑，可能消耗服务器更多的内存资源，甚至影响正常用户建立TCP连接，需要评估服务器硬件资源和***大小谨慎设置。
除了定制TCP/IP协议栈之外，还有一种常见做法是TCP首包丢弃方案，利用TCP协议的重传机制识别正常用户和***报文。当防御设备接到一个IP地址的SYN报文后，简单比对该IP是否存在于白名单中，存在则转发到后端。如不存在于白名单中，检查是否该IP在一定时间段内的首次SYN报文，不是则检查是否重传报文，是重传则转发并加入白名单，不是则丢弃并加入黑名单。是首次SYN报文则丢弃并等待一段时间试图接受该IP的SYN重传报文，等待超时则判定为***报文加入黑名单。
首包丢弃方案对用户体验会略有影响，因为丢弃首报重传会增大业务的响应时间，有鉴于此发展出了一种更优的TCP Proxy方案。所有的SYN数据报文由清洗设备接受，按照SYN Cookie方案处理。和设备成功建立了TCP三次握手的IP地址被判定为合法用户加入白名单，由设备伪装真实客户端IP地址再与真实服务器完成三次握手，随后转发数据。而指定时间内没有和设备完成三次握手的IP地址，被判定为恶意IP地址屏蔽一定时间。除了SYN Cookie结合TCP Proxy外，清洗设备还具备多种畸形TCP标志位数据包探测的能力，通过对SYN报文返回非预期应答测试客户端反应的方式来鉴别正常访问和恶意行为。
清洗设备的硬件具有特殊的网络处理器芯片和特别优化的操作系统、TCP/IP协议栈，可以处理非常巨大的流量和SYN队列。
1.3 HTTP Flood防御
HTTP Flood***防御主要通过缓存的方式进行，尽量由设备的缓存直接返回结果来保护后端业务。大型的互联网企业，会有庞大的CDN节点缓存内容。
当高级***者穿透缓存时，清洗设备会截获HTTP请求做特殊处理。最简单的方法就是对源IP的HTTP请求频率做统计，高于一定频率的IP地址加入黑名单。这种方法过于简单容易带误杀，并且无法屏蔽来自代理服务器的***，因此逐渐废止，取而代之的是javascript跳转人机识别方案。
HTTP Flood是由程序模拟HTTP请求，一般来说不会解析服务端返回数据，更不会解析JS之类代码。因此当清洗设备截获到HTTP请求时，返回一段特殊Javascript代码，正常用户的浏览器会处理并正常跳转不影响使用，而***程序会***到空处。
1.4 DNS Flood防御
DNS***防御也有类似HTTP的防御手段，第一方案是缓存。其次是重发，可以是直接丢弃DNS报文导致UDP层面的请求重发，可以是返回特殊响应强制要求客户端使用TCP协议重发DNS查询请求。
特殊的，对于授权域DNS的保护，设备会在业务正常时期提取收到的DNS域名列表和ISP DNS IP列表备用，在***时，非此列表的请求一律丢弃，大幅降低性能压力。对于域名，实行同样的域名白名单机制，非白名单中的域名解析请求，做丢弃处理。
1.5 慢速连接***防御
Slowloris***防御比较简单，主要方案有两个：
第一个是统计每个TCP连接的时长并计算单位时间内通过的报文的数量即可做精确识别。一个TCP连接中，HTTP报文太少和报文太多都是不正常的，过少可能是慢速连接***，过多可能是使用HTTP 1.1协议进行的HTTP Flood***，在一个TCP连接中发送多个HTTP请求。
第二个是限制HTTP头部传输的最大许可时间。超过指定时间HTTP Header还没有传输完成，直接判定源IP地址为慢速连接***，中断连接并加入黑名单。
2. 企业级防御
互联网企业防御DDoS***，主要使用上文的基础防御手段，重点在于监控、组织以及流程。
监控需要具备多层监控、纵深防御的概念，从骨干网络、IDC入口网络的BPS、PPS、协议分布，负载均衡层的VIP新建连接数、并发连接数、BPS、PPS到主机层的CPU状态、TCP新建连接数状态、TCP并发连接数状态，到业务层的业务处理量、业务连通性等多个点部署监控系统。即使一个监控点失效，其他监控点也能够及时的给出报警信息。多个点信息结合，准确的判断被***目标和***手法。
一旦发现异常立即启动在虚拟的防御组织中开始应急流程，防御组织需要囊括到足够全面的人员，至少包含监控部门、运维部门、网络部门、安全部门、客服部门、业务部门等，所有的人员都需要要2-3个备份。流程启动后，除了人工处理，还应该包含一定的自动处理、半自动处理能力。如自动化的***分析，确定***类型，自动化、半自动化的防御策略，在安全人员到位之前，最先发现***的部门可以做一些缓解措施。
除了DDoS到来之时的流程等工作之外，更多的工作是在***到来之前。主要包含CDN节点部署，DNS设置，流程演习等。对于企业来说，具备多个CDN节点是DDoS防御容量的关键指标。当一个机房承担不住海量数据的时候，可以通过DNS轮询的方式，把流量引导到多个分布节点，使用防御设备分头处理。因此DNS的TTL值需要设置得足够小，能够快速切换，每个CDN节点的各种VIP设置也需要准备充分。
在虚拟化时代，各种用户的不同业务共处在相同的物理机平台，遭受DDoS***的可能性越来越高，而且一个用户被***可能牵扯到大量的其它用户，危害被显著放大，因此防御显得尤为重要。阿里云的虚拟化业务，平均每天遭受约20起DDoS***，最大流量达到接近20Gbit/s，所有的这些***都在15分钟内自动处理完成，让我们的客户原理DDoS的威胁，专心发展业务。
总的来说，DDoS防御，主要的工作是幕后积累。台上10分钟，台下十年功，没有充分的资源准备，没有足够的应急演练，没有丰富的处理经验，DDoS***将是所有人的噩梦。
浅谈Ddos***范例
[ 目录 ]
一 背景
二 应急响应
三 常见ddos***及防御
四 根源及反击
五 总结
一 背景
在前几天，我们运营的某网站遭受了一次ddos***，我们的网站是一个公益性质的网站，为各个厂商和白帽子之间搭建一个平台以传递安全问题等信息，我们并不清楚因为什么原因会遭遇这种无耻的***。因为我们本身并不从事这种类型的***，这种***技术一般也是比较粗糙的，所以讨论得比较少，但是既然发生了这样的***我们觉得分享***发生后我们在这个过程中学到得东西，以及针对这种***我们的想法才能让这次***产生真正的价值，而并不是这样的***仅仅浪费大家的时间而已。
另外，我们发现大型的企业都有遭受***的案例，但是大家遭受***之后的应对措施及学到的经验却分享都比较少，这导致各家都是自行的摸索经验，依然停留在一家企业对抗整个互联网的***的局面，而对于***者却是此次***针对你，下次***却是针对他了，而且***之后无论是技术还是资源都没有任何的损耗，这也是导致这种***频繁并且肆无忌惮的原因。
我们来尝试做一些改变：）
二 应急响应
在***发生后，第一个现象是我们的网站上不去了，但是依然可以访问到管理界面，我们登陆上去简单执行了命令：
netstat -antp
我们看到有大量的链接存在着，并且都是ESTABLISHED状态，正常状态下我们的网站访问量没有这么高，如果有这么高我们相信中国的信息安全就有希望了，对于这样的情况其实处理就比较简单，这是一次四层的***，也就是所有ip都是真实的，由于目前为止只是消耗了webserver的网络连接资源，所以我们只需要简单的将这些ip在网络层封禁就可以，很简单，用下面的命令即可：
1
2
3
4
5
for i in `netstat -an | grep -i ‘:80 ‘|grep ‘EST’ | awk ‘{print $5}’ | cut -d : -f 1 | sort | uniq -c | awk ‘{if($1 > 50) {print $2}}’`
echo $i
echo $i >> /tmp/banip
/sbin/iptables -A INPUT -p tcp -j DROP -s $i
done
然后作为计划任务一分钟执行一次即可，很快，iptables的封禁列表就充斥了大量的封禁ip，我们简单的统计了下连接数最大的一些ip发现都来自韩国。为了保证系统的性能，我们调大了系统的可接受的连接数以及对Nginx进行了每个连接能够进行的请求速率，系统于是恢复了正常的运行。
正常状态一直持续到第二天，但是到中午之后我们发现访问又出现了问题，网络很慢，使用ping发现大概出现了70%左右的丢包，在艰难的登陆到系统上之后，发现系统已经很少有TCP的正常连接，为了查明原因，我们对系统进行了抓包：
tcpdump -w tmp.pcap port not 22
tcpdump -r tmp.pcap -nnA
我们发现***已经从应用层的***调整到了网络层的***，大量的目标端口是80的udp和icmp包以极快的速度充满了网络，一个包大小大概在1k左右，这次占据的资源纯粹是带宽资源了，即使在系统上做限制也解决不了这个问题，不过也没有关系，对于网络层的问题我们可以在网络层上做限制，我们只需要在网络上把到达我们ip的非TCP的所有包如UDP和ICMP等协议都禁止掉即可，但是我们没有自己的服务器也缺乏对网络设备的控制权，目前是由工信部CERT提供支持的，由于临时无法协调进行相应的操作，后果如大家看到，我们的服务很慢，基本上停止了服务，在一段时间之后***者停止了***，服务才进行了恢复，很憋屈是么？但是同时我们得到了很多热心朋友的帮助，得到了更好的网络和服务器资源，在网络资源方面的能力得到了很大的提升，缓解了这方面的问题，这里对他们表示感谢。
三 常见ddos***及防御
继续秉承80sec的”Know it then hack it”，这里简单谈一下ddos***和防御方面的问题。ddos的全称是分布式拒绝服务***，既然是拒绝服务一定是因为某些原因而停止服务的，其中最重要的也是最常用的原因就是利用服务端方面资源的有限性，这种服务端的资源范围很广，可以简单的梳理一个请求正常完成的过程：
1 用户在客户端浏览器输入请求的地址
2 浏览器解析该请求，包括分析其中的dns以明确需要到达的远程服务器地址
3 明确地址后浏览器和服务器的服务尝试建立连接，尝试建立连接的数据包通过本地网络，中间路由最终艰苦到达目标网络再到达目标服务器
4 网络连接建立完成之后浏览器根据请求建立不同的数据包并且将数据包发送到服务器某个端口
5 端口映射到进程，进程接受到数据包之后进行内部的解析
6 请求服务器内部的各种不同的资源，包括后端的API以及一些数据库或者文件等
7 在逻辑处理完成之后数据包按照之前建立的通道返回到用户浏览器，浏览器完成解析，请求完成。
上面各个点都可以被用来进行ddos***，包括：
1 某些著名的客户端劫持病毒，还记得访问百度跳搜狗的事情么？：）
2 某个大型互联网公司发生的dns劫持事件，或者直接大量的dns请求直接***dns服务器，这里可以使用一些专业的第三方dns服务来缓解这个问题，如Dnspod
3 利用建立网络连接需要的网络资源***服务器带宽使得正常数据包无法到达如udp的洪水***，消耗前端设备的cpu资源以使得数据包不能有效转发如icmp和一些碎片包的洪水***，消耗服务器方建立正常连接需要的资源如syn flood或者就是占用大量的连接使得正常的连接无法发起，譬如这次的TCP flood
4 利用webserver的一些特点进行***，相比nginx来说，apache处理一个请求的过程就比较笨重。
5 利用应用程序内部的一些特性***程序内部的资源如mysql，后端消耗资源大的接口等等，这也就是传统意义上的CC***。
这里涉及到***的概念，但是实际上如果了解对方的***点和***手法，防御会变成简单的一个拼资源的过程，不要用你最弱的地方去抗人家最强的地方，应该从最合适的地方入手把问题解决掉，譬如在路由器等设备上解决应用层***就不是一个好的办法，同理，在应用层尝试解决网络层的问题也是不可能的，简单来说，目标是只让正常的数据和请求进入到我们的服务，一个完善的防御体系应该考虑如下几个层面：
1 作为用户请求的入口，必须有良好的dns防御
2 与你的价值相匹配的带宽资源，并且在核心节点上布置好应用层的防御策略，只允许你的正常应用的网络数据包能够进入，譬如封杀除了80以外的所有数据包
3 有支持你的服务价值的机器集群来抵抗应用层的压力，有必要的话需要将一个http请求继续分解，将连接建立的过程压力分解到其他的集群里，这里似乎已经有一般的硬件防火墙能做这个事情，甚至将正常的http请求解析过程都进行分解，保证到达后端的是正常的请求，剔除掉畸形的请求，将正常的请求的请求频度等行为进行记录和监控，一旦发生异常就在这里进行应用层的封杀
每个公司都有自己对自己价值的评估从而决定安全投入上的大小，每一次***也会涉及到利益的存在，正如防御因为种种原因譬如投入上的不足和实施过程中的不完美，有着天生的弱点一样，***也是有着天生的弱点的，因为每一次***涉及到不同的环节，每个环节都可能由不同水平的人完成，他所拥有的资源，他使用的工具和技术都不会是完美的，所以才有可能进行防御，另外，我相信进行DDOS***的人是一个固定的行业，会有一些固定的人群，对于其中使用的技术，工具，资源和利益链都是比较固定的，与之相对的是各个企业却缺乏相应的沟通，以个人企业对抗一个产业自然是比较困难，而如果每一个企业都能将自己遭受***时的经验分享出来，包括僵尸网络的大小及IP分布，***工具的特征，甚至有能力的可以去分析背后的利益点及操作者，那么每一次***都能让大家的整体防御能力上升，让***者的***能力有损失，我们很愿意来做这个事情。
四 根源及反击
我困惑的是一点，***我们并不能得到实际的好处为什么还是有人来***，而且听说其他公司都有被***的情况，我觉得有一点原因就是***我们的确得不到什么好处，但是实际上***者也并不损失什么，无论是资源上还是法律风险上，他不会因为一次***而损失太多，而相比之下，服务提供者损失的东西却太多了，这从经济学角度来讲就是不平衡的，我们处于弱势。
一般而言，的确对于作恶者是没有什么惩罚措施，但是这次，我们觉得我们是可以做一些事情的，我们尝试挖掘背后的***者，甚至清除这个僵尸网络。
首先这次***起源于应用层的***，所以所有的ip都是真实的，经过与CERT沟通，也发现这些ip都是韩国的，并且控制端不在国内，因为期间没有与国内有过通讯，即使在后面换成了udp+icmp的flood，但是依然是那些韩国的ip，这很有意思，正常情况下udp+icmp的数据包是可以伪造的，但是这里居然没有伪造，这在后面大概被我们证实了原因。
这些ip是真实存在的ip，而且这些ip肯定在***完我们之后一定依然跟***者保持着联系，而一般的联系方式因为需要控制的方便都是dns域名，既然如此，如果我们能挖掘到这个dns域名我们就可能间接的挖掘出真正幕后黑手在哪里。首先，我们迅速的找出了这次***ip中开放了80端口的机器，因为我们对80端口上的安全问题比较自信，应该很快可以获知这些ip背后的细节（80sec名称由来），我们发现大部分是一些路由器和一些web的***设备，我们猜测这次***的主要是韩国的个人用户，而个人用户的机器操作系统一般是windows所以在较高版本上发送数据包方面可能有着比较大的限制，这也解释了为什么即使是udp+icmp的***我们看到的大都是真实ip。发现这些路由设备之后我们尝试深入得更多，很快用一些弱口令譬如admin/admin登陆进去，果然全世界的网民都一样，admin/admin是天生的入口。
登陆进去一些路由之后我们发现这些路由器里面存在一个功能是设置自己的dns，这意味着这下面的所有dns请求都可以被定向到我们自己设置的dns服务器，这对于我们去了解内部网络的细节会很有用，于是我们建立了一个自己的dns服务器，并且开启了dns请求的日志功能以记录所有请求的细节。我们大约控制了20台路由器的dns指向，并且都成功重定向到我们自己的服务器。
剩下的就是简单的数据分析，在这之前我们可以对僵尸网络的控制域名做如下的猜测：
1 这个dns应该为了灵活的控制域名的缓存时间TTL一般不会特别长
2 这个dns应该是定期的被请求，所以会在dns请求里有较大的出现比例
3 这个dns应该是为了控制而存在的，所以域名不应该在搜索引擎以及其他地方获得较高的访问指数，这与2中的规则配合起来会比较好确定，是一个天生的矛盾。
4 这个dns应该在各个路由下面都会被请求
这些通过简单的统计就很容易得出答案，我们发现了一些3322的通用恶意软件域名但是发现它并不是我们需要的，因为只有少数机器去访问到，经过一些时间之后最后我们发现一个域名访问量与naver（韩国的一个门户）的访问量持平，workgroup001.snow****.net，看起来似乎对自己的僵尸网络管理很好嘛，大概有18台机器访问过这个域名，这个域名的主机托管在新加坡，生存时间TTL在1800也就是半小时，这个域名在所有的搜索引擎中都不存在记录，是一个韩国人在godady一年前才注册的，同时我们访问这个域名指向主机的3389，简单的通过5下shift就判断出它上面存在着一个典型的windows后门，似乎我们找到它了，不是么？经过后续的观察，一段时间后这个域名指向到了127.0.0.1，我们确信了我们的答案,workgroup001.snow****.net，看起来似乎对自己的僵尸网络管理很好嘛：）
这是一次典型的ddos***，***之后我们获得了参与***的主机列表和控制端的域名及ip，相信中国和韩国的cert对于清理这次的***源很有兴趣，我们是有一些损失，但是***者也有损失了（大概包括一个僵尸网络及一个控制端域名，甚至可能包括一次内部的法律调查），我们不再是不平等的了，不是么？
五 总结
正如一个朋友所讲的，所有的防御是不完美的正如***是不完美的一样，好的防御者在提升自己的防御能力趋于完美的同时也要善于寻找***者的不完美，寻找一次***中的漏洞，不要对***心生恐惧，对于Ddos***而言，发起一次***一样是存在漏洞的，如果我们都能够擅长利用其中的漏洞并且抓住后面的***者那么相信以后的ddos***案例将会减少很多，在针对目标发起***之前***者也会做更多的权衡，损失，利益和法律。
91ri.org点评：文章提到的iptable防火墙是linux下自带的一款非常优秀的防火墙，用好它有的时候比增加带宽、流量有用多了。关于iptable防火墙的文章可以查看<<教你两小时玩转iptables>> <