去年在《凌云》杂志上写过一篇关于DDoS攻防的文章，在线版本可以到官方网站http://storage.aliyun.com/aliyun_portal_storage/lingyun/lingyun-journal-2.pdf查看。当时因为篇幅的原因有些细节没有展开，加上时间过去了大半年，出现了许多新的流行的攻击方式，所以决定写一篇补遗。
一、DRDoS攻击
DRDoS（分布式反射攻击）最早在2004年左右就出现了，安全焦点上还有一份国外的代码，可以在http://www.xfocus.net/tools/200406/717.html下载查看。当时的DRDoS攻击不具备放大流量的能力，某种意义上说类似拿冲锋枪打墙，依靠反射回来的弹壳伤人，攻击力不升反降，因而并没有流行开来。
但是从2013年开始，DRDoS已经是互联网上最流行、最吸引眼球的DDoS攻击手段了，因为它附加流量放大属性，通过史无前例的海量流量击败了如日中天的云安全公司CloudFlare，引得大小黑客纷纷仿效。
DRDoS攻击的原理是黑客伪造成受害者的IP地址，向互联网上大量开放特定服务的主机发起请求，接收到请求的那些主机根据源IP地址将响应数据包返回给受害者。整个过程中，大量的无辜主机完全不知情，成为黑客攻击的帮凶。一般来说，黑客会使用响应包远大于请求包的服务来利用，这样才可以以较小的流量换取交大的流量去攻击，几十倍的放大攻击。能利用来做放大反射攻击的服务，常见的有DNS服务、NTP服务、SNMP服务、Chargen服务等等，甚至某些online游戏服务器也被利用来参与攻击。
1.1. 基于UDP的反射攻击
CloudFlare在2013年遭受的300Gbps的攻击属于DNS反射攻击，当时导致他们全网故障。在2014年2月，它们遭受了前所未见的400Gbps的攻击，黑客使用了NTP服务进行放大。
互联网上有非常多的时间服务器，通过NTP协议提供对时服务。但是它缺乏身份认证手段，可以被任意使用。更重要的是，NTP协议有一个指令monlist可以列举出最近同步过时间的600个主机列表，如下图：
攻击者发出的Monlist指令只有1个数据包，耗费几十个字节，而返回包多达几十个，耗费2000-3000字节甚至更大，达到约50倍的放大。越是繁忙的NTP服务器，这个放大倍数越大。
攻击者只需要100Mbps的请求流量，可以换来5Gbps的攻击流量，效率非常高。其它的DNS放大、SNMP放大、Chargen放大与NTP放大原理一致，只是使用的协议有区别，不一一描述。
1.2. 基于TCP的反射攻击
反射攻击利用的协议，一般同时具有3种特征：容易伪造源IP地址、无身份认证、响应包远大于请求包。因此，基于UDP的DNS协议、NTP协议、Chargen协议、SNMP协议成为首选。那么，是不是只有基于UDP的上层协议才能够用来做放大反射攻击，需要完成三次握手才能开始业务会话的基于TCP的上层协议就无法利用了？其实不是。
Chargen是一个常见的测试网络连通性服务，同时工作在UDP协议和TCP协议上。对于它监听的TCP端口，只要有客户端连上，就会源源不断的向客户端返回随机字符串，永不停止。可以想象，如果这个东西可以利用起来做攻击，无穷倍数的放大，是何等厉害。但是很遗憾，TCP不能伪造源IP地址，除非攻击者能够让攻击目标主动连接到Chargen的TCP端口去。
这种事情，恰好是代理协议做的事情！如果攻击目标是HTTP Proxy或者Socks5 Proxy，攻击者只需要连接上目标的代理端口，然后去访问Chargen服务并保持TCP连接不断掉就行了。以HTTP代理为例，直接连接target的3128端口，然后发出类似http://chargen_server.com:19这样的请求即可，socks5代理类似。
使用Chargen攻击代理服务器效果虽好，但是毕竟应用范围比较狭窄，一般的攻击目标都是网站。黑客的创意在这儿展露无遗，他们也有各种新奇的手法，比如利用Google的某些服务或者Wordpress之类的博客来做DDoS攻击。
Google有一个叫做FeedFetcher的爬虫，为Google Feed API提供后端支持，会定期抓取RSS以及其它各种数据，如他们的电子表格服务spreadsheet中的链接。当电子表格服务中存在内容=image(“http://example.com/image.jpg”)时，Google就会“派出”FeedFetcher爬虫去抓取这个图片并保存到缓存中以将其显示出来。
恶意攻击者会找一个较大的文件，给文件名附加上随机参数，使FeedFetcher多次抓取这个文件。也就是说，如果一个网站有一个10MB的文件，将以下列表输入到Google spreadsheet中，那么Google的爬虫就会抓取该文件1000次，使网站产生大量出站流量。
=image(“http://targetname/file.pdf?r=0″)
=image(“http://targetname/file.pdf?r=1″)
=image(“http://targetname/file.pdf?r=2″)
=image(“http://targetname/file.pdf?r=3″)
…
=image(“http://targetname/file.pdf?r=1000″)
如果是带宽比较小的站点，面对这种攻击时会非常痛苦。拦截会影响SEO效果，不拦截则需要付出更多的带宽租赁费用。
基于类似的原理，Wordpress博客的pingback功能也可以用来做反射攻击。PingBack是用来通知blog系统有文章被引用的一种手段。向
http://www.anywordpresssite.com/xmlrpc.php
提交POST请求， 数据格式如下：
<methodCall><methodName>pingback.ping</methodName><params><param><value><string>http://victim.com/post.php?id=1</string></value></param><param><value><string>http://www.anywordpresssite.com/pst?id=111</string></value></param></params></methodCall>， 则服务器www.anywordpresssite.com会向http://victim.com/post.php?id=1发起GET请求。如果攻击者同时向大量的开启了pingback的blog系统提交请求，则有大量的GET请求涌向攻击目标，更多的更多细节可以参见http://drops.wooyun.org/news/1062。
但是就我看来，pingback这样的反射攻击意义不大，因为流量和请求次数都没有被放大，如果单纯是为了隐藏自己，可以选择通过proxy的方式发起攻击。更好的做法应该是向某个开启了pingback的blog a发送大量的POST包（这里的POST包通过代理发起），让它去ping大量的blog，然后大量的http response会同攻击者发起的POST包一起淹没blog a，这才是优雅的反射放大攻击——付出的代价是这种攻击方式仅对有pingback功能的系统起作用。
1.3. DrDoS的防御
TCP的反射攻击有可能发生，但是危害程度远不如UDP，而且发起难度较大，需要很多诡异的条件配合。因此，防御上无需做过多考虑，将目光主要集中到基于UDP的反射放大攻击。
首先，我们需要足够大的带宽，没有带宽一切都枉然。一般的，带宽可以通过CDN的方式提供，将业务分散到不同地区的不同机房。
其次，从DRDos的本质知道，这种反射攻击数据包的源端口一定是固定的，NTP放大攻击源端口一定是UDP 123端口，DNS放大攻击源端口一定是UDP 53端口。这其实是一个很好的特征，也是攻击者不愿意却不得不留下的特征——有得到就有代价。在带宽足够的情况下，可以在网络边界部署ACL策略，禁止外网进来的源端口是UDP 123的报文，禁止外网进来的源端口是UDP 161的报文，禁止外网进来的源端口是UDP 19的报文，诸如此类。源端口是UDP 53的也可以过滤？也可以的，至少大部分IP地址可以无需请求外部的DNS服务。
这里涉及到一条防御准则，可以三层过滤的不要在四层做，可以在四层做的过滤不要到七层做。越往上，解析开销越大。
二、高级SYN Flood攻防
1.4. SYN Cookie、SYN Proxy
最常见的SYN Flood防御手段是SYN Cookie和SYN Proxy，它们原理简单，而且效果也非常好。
在正常情况下，服务器端接收到客户端发送的SYN包，会分配一个连接请求块（即request_sock结构）用于保存连接信息，然后发送SYN+ACK包给客户端，并将连接请求块添加到半连接队列中，没收到最后一个ACK的话就轮询重发SYN+ACK包。
对于启用了SYN Cookie的服务器，不会这样处理，它不维持任何连接信息， 而是将源IP、目的IP、源端口、目的端口、SYN序列号等信息进行hash运算，生成一个数字称之为cookie。服务端将这个cookie作为SYN+ACK包的ACK确认号发送给客户端，然后对这个IP发过来的后续ACK包的确认号进行验算，与Cookie吻合的说明是正确的报文，正常建立连接，而攻击的报文直接没有了任何后续动作，也没有额外开销。
SYN Proxy则是管家式的防御，它站在攻击者和目标服务器之间，伪装成目标服务器对所有的SYN报文进行应答，包括攻击者在内。当三次握手正确的建立起来后，就伪装成客户端IP地址与后端的目标服务器建立三次握手，然后转发数据，需要注意的是，TCP三次握手在这里变成了6次握手，而且两个握手内的ACK号肯定不一致，需要做一个修正。
SYN Cookie可以和SYN Proxy无缝集成，协同工作，提供更好的防御服务，基本上100%无误杀。那么使用这种防御手段，付出的代价是什么？
我们可以看到，SYN Cookie和SYN Proxy对每一个SYN包都会进行答复，如果攻击者发送1Gbps的报文过来，防御方会发送1Gbps的报文回去。10Gbps就10Gbps，100Gbps就100Gbps。问题是，企业网络禁得起这种折腾么？基本上，攻击流量达到一定程度，网络不攻自溃。
1.5. 随机丢包
对于过大的反弹流量的问题，安全厂商想出了许多新的办法，那就是在答复之前做一些测试，能轻易过滤的流量就不反弹了。最主要的是随机丢包策略，直接粗暴的丢弃SYN包，按照TCP协议正常的用户会在3秒内重发这个SYN包，攻击流量的源IP是伪造的，因此直接被丢弃了没有任何后续。
这个方案看起来对SYN Cookie之类技术是一个很好的补充，但是也有一些问题。首先，正常用户的体验受到影响，访问业务的速度变慢了。其次是某些高级攻击者可以利用这个手段，绕过防御，简单的说，同样的SYN包发两次有可能被判定为正常访问。一旦被防御设备加入白名单，后续的报文就直接漏过了。
1.6. 反向探测
除了SYN Cookie、Proxy技术之外，还有一种反向探测的技术，也是颇为流行。防御设备接收到SYN包时，回复一个ACK确认号错误的SYN+ACK报文。按照协议，客户端会发一个RST报文过来重置连接。攻击者一般是伪造源IP地址，没有人会帮他做这个应答，SYN包被直接过滤掉。
这个方案，在实际环境中会遇到一些问题。某些防火墙设备，包括iptables，会过滤掉ACK号错误的SYN+ACK包，导致正常用户的RST包发不过来而导致被误杀。因此，考虑到稳定可靠，防御设备回复的SYN+ACK包的ACK确认号需要满足某些特征，比如小于或者等于SYN确认号。
对于攻击者而言，他们可以通过tcp ping的方式扫描到真实存活的主机列表，然后使用这些IP地址作为源IP地址发起攻击，可以有效绕过这种防御手段。虽然一般的攻击是要伪造不存在的源IP以达到更好的效果，但是这里则要反其道而行之。
三、总结
总之，DDoS的防御和攻击都是一件非常精巧的事情。要优雅的攻击，优雅的防御。各种手法有符合常规的，也有要违背常规的。运用之妙，存乎一心。
四、后记
NTP攻击的图片来自网络，更多细节可以参见：
基于Google的攻击来自freebuf，参见：
http://www.freebuf.com/articles/web/28273.html。
原文来自阿里云产品博客
