浅谈DDOS攻击攻击与防御.docx
《浅谈DDOS攻击攻击与防御.docx》由会员分享，可在线阅读，更多相关《浅谈DDOS攻击攻击与防御.docx（19页珍藏版）》请在冰豆网上搜索。
浅谈DDOS攻击攻击与防御
浅谈DDOS攻击攻击与防御
2012/07/26|分类：
IT技术|0条评论|标签：
DDOS,网络安全,黑客
分享到：
来源：
80sec
一、背景
在前几天，我们运营的某网站遭受了一次ddos攻击，我们的网站是一个公益性质的网站，为各个厂商和白帽子之间搭建一个平台以传递安全问题等信息，我们并不清楚因为什么原因会遭遇这种无耻的攻击。
因为我们本身并不从事这种类型的攻击，这种攻击技术一般也是比较粗糙的，所以讨论得比较少，但是既然发生了这样的攻击我们觉得分享攻击发生后我们在这个过程中学到得东西，以及针对这种攻击我们的想法才能让这次攻击产生真正的价值，而并不是这样的攻击仅仅浪费大家的时间而已。
另外，我们发现大型的企业都有遭受攻击的案例，但是大家遭受攻击之后的应对措施及学到的经验却分享都比较少，这导致各家都是自行的摸索经验，依然停留在一家企业对抗整个互联网的攻击的局面，而对于攻击者却是此次攻击针对你，下次攻击却是针对他了，而且攻击之后无论是技术还是资源都没有任何的损耗，这也是导致这种攻击频繁并且肆无忌惮的原因。
我们来尝试做一些改变：
）
二、应急响应
在攻击发生后，第一个现象是我们的网站上不去了，但是依然可以访问到管理界面，我们登陆上去简单执行了命令：
1
netstat-antp
我们看到有大量的链接存在着，并且都是ESTABLISHED状态，正常状态下我们的网站访问量没有这么高，如果有这么高我们相信中国的信息安全就有希望了，对于这样的情况其实处理就比较简单，这是一次四层的攻击，也就是所有ip都是真实的，由于目前为止只是消耗了webserver的网络连接资源，所以我们只需要简单的将这些ip在网络层封禁就可以，很简单，用下面的命令即可：
1
2
3
4
5
foriin`netstat-an|grep-i‘:
80‘|grep‘EST’|awk‘{print$5}’|cut-d:
-f1|sort|uniq-c|awk‘{if（$1>50）{print$2}}’`
echo$i
echo$i>>/tmp/banip
/sbin/iptables-AINPUT-ptcp-jDROP-s$i
done
然后作为计划任务一分钟执行一次即可，很快，iptables的封禁列表就充斥了大量的封禁ip，我们简单的统计了下连接数最大的一些ip发现都来自韩国。
为了保证系统的性能，我们调大了系统的可接受的连接数以及对Nginx进行了每个连接能够进行的请求速率，系统于是恢复了正常的运行。
正常状态一直持续到第二天，但是到中午之后我们发现访问又出现了问题，网络很慢，使用ping发现大概出现了70%左右的丢包，在艰难的登陆到系统上之后，发现系统已经很少有TCP的正常连接，为了查明原因，我们对系统进行了抓包：
1
2
tcpdump-wtmp.pcapportnot22
tcpdump-rtmp.pcap-nnA
我们发现攻击已经从应用层的攻击调整到了网络层的攻击，大量的目标端口是80的udp和icmp包以极快的速度充满了网络，一个包大小大概在1k左右，这次占据的资源纯粹是带宽资源了，即使在系统上做限制也解决不了这个问题，不过也没有关系，对于网络层的问题我们可以在网络层上做限制，我们只需要在网络上把到达我们ip的非TCP的所有包如UDP和ICMP等协议都禁止掉即可，但是我们没有自己的服务器也缺乏对网络设备的控制权，目前是由工信部CERT提供支持的，由于临时无法协调进行相应的操作，后果如大家看到，我们的服务很慢，基本上停止了服务，在一段时间之后攻击者停止了攻击，服务才进行了恢复，很憋屈是么？
但是同时我们得到了很多热心朋友的帮助，得到了更好的网络和服务器资源，在网络资源方面的能力得到了很大的提升，缓解了这方面的问题，这里对他们表示感谢。
三、常见ddos攻击及防御
继续秉承80sec的”Knowitthenhackit”，这里简单谈一下ddos攻击和防御方面的问题。
ddos的全称是分布式拒绝服务攻击，既然是拒绝服务一定是因为某些原因而停止服务的，其中最重要的也是最常用的原因就是利用服务端方面资源的有限性，这种服务端的资源范围很广，可以简单的梳理一个请求正常完成的过程：
1用户在客户端浏览器输入请求的地址
2浏览器解析该请求，包括分析其中的dns以明确需要到达的远程服务器地址
3明确地址后浏览器和服务器的服务尝试建立连接，尝试建立连接的数据包通过本地网络，中间路由最终艰苦到达目标网络再到达目标服务器
4网络连接建立完成之后浏览器根据请求建立不同的数据包并且将数据包发送到服务器某个端口
5端口映射到进程，进程接受到数据包之后进行内部的解析
6请求服务器内部的各种不同的资源，包括后端的API以及一些数据库或者文件等
7在逻辑处理完成之后数据包按照之前建立的通道返回到用户浏览器，浏览器完成解析，请求完成。
上面各个点都可以被用来进行ddos攻击，包括：
1某些著名的客户端劫持病毒，还记得访问XX跳搜狗的事情么？
：
）
2某个大型互联网公司发生的dns劫持事件，或者直接大量的dns请求直接攻击dns服务器，这里可以使用一些专业的第三方dns服务来缓解这个问题，如Dnspod
3利用建立网络连接需要的网络资源攻击服务器带宽使得正常数据包无法到达如udp的洪水攻击，消耗前端设备的cpu资源以使得数据包不能有效转发如icmp和一些碎片包的洪水攻击，消耗服务器方建立正常连接需要的资源如synflood或者就是占用大量的连接使得正常的连接无法发起，譬如这次的TCPflood
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的vpn设备，我们猜测这次攻击的主要是韩国的个人用户，而个人用户的机器操作系统一般是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攻击案例将会减少很多，在针对目标发起攻击之前攻击者也会做更多的权衡，损失，利益和法律。
魏兴国：
深入浅出DDoS攻击防御
2013/04/18|分类：
IT技术|2条评论|标签：
DDOS,DNS,网络安全,黑客
分享到：
来源：
《程序员》
敌情篇——DDoS攻击原理
DDoS攻击基础
DDoS（DistributedDenialofService，分布式拒绝服务）攻击的主要目的是让指定目标无法提供正常服务，甚至从互联网上消失，是目前最强大、最难防御的攻击之一。
按照发起的方式，DDoS可以简单分为三类。
第一类以力取胜，海量数据包从互联网的各个角落蜂拥而来，堵塞IDC入口，让各种强大的硬件防御系统、快速高效的应急流程无用武之地。
这种类型的攻击典型代表是ICMPFlood和UDPFlood，现在已不常见。
第二类以巧取胜，灵动而难以察觉，每隔几分钟发一个包甚至只需要一个包，就可以让豪华配置的服务器不再响应。
这类攻击主要是利用协议或者软件的漏洞发起，例如Slowloris攻击、Hash冲突攻击等，需要特定环境机缘巧合下才能出现。
第三类是上述两种的混合，轻灵浑厚兼而有之，既利用了协议、系统的缺陷，又具备了海量的流量，例如SYNFlood攻击、DNSQueryFlood攻击，是当前的主流攻击方式。
本文将一一描述这些最常见、最具代表性攻击方式，并介绍它们的防御方案。
SYNFlood
SYNFlood是互联网上最经典的DDoS攻击方式之一，最早出现于1999年左右，雅虎是当时最著名的受害者。
SYNFlood攻击利用了TCP三次握手的缺陷，能够以较小代价使目标服务器无法响应，且难以追查。
标准的TCP三次握手过程如下：
●客户端发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号；
●服务器在收到客户端的SYN报文后，将返回一个SYN+ACK（即确认Acknowledgement）的报文，表示客户端的请求被接受，同时TCP初始序号自动加1；
●客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加1。
经过这三步，TCP连接就建立完成。
TCP协议为了实现可靠传输，在三次握手的过程中设置了一些异常处理机制。
第三步中如果服务器没有收到客户端的最终ACK确认报文，会一直处于SYN_RECV状态，将客户端IP加入等待列表，并重发第二步的SYN+ACK报文。
重发一般进行3-5次，大约间隔30秒左右轮询一次等待列表重试所有客户端。
另一方面，服务器在自己发出了SYN+ACK报文后，会预分配资源为即将建立的TCP连接储存信息做准备，这个资源在等待重试期间一直保留。
更为重要的是，服务器资源有限，可以维护的SYN_RECV状态超过极限后就不再接受新的SYN报文，也就是拒绝新的TCP连接建立。
SYNFlood正是利用了上文中TCP协议的设定，达到攻击的目的。
攻击者伪装大量的IP地址给服务器发送SYN报文，由于伪造的IP地址几乎不可能存在，也就几乎没有设备会给服务器返回任何应答了。
因此，服务器将会维持一个庞大的等待列表，不停地重试发送SYN+ACK报文，同时占用着大量的资源无法释放。
更为关键的是，被攻击服务器的SYN_RECV队列被恶意的数据包占满，不再接受新的SYN请求，合法用户无法完成三次握手建立起TCP连接。
也就是说，这个服务器被SYNFlood拒绝服务了。
对SYNFlood有兴趣的可以看看
DNSQueryFlood
作为互联网最基础、最核心的服务，DNS自然也是DDoS攻击的重要目标之一。
打垮DNS服务能够间接打垮一家公司的全部业务，或者打垮一个地区的网络服务。
前些时候风头正盛的黑客组织anonymous也曾经宣布要攻击全球互联网的13台根DNS服务器，不过最终没有得手。
UDP攻击是最容易发起海量流量的攻击手段，而且源IP随机伪造难以追查。
但过滤比较容易，因为大多数IP并不提供UDP服务，直接丢弃UDP流量即可。
所以现在纯粹的UDP流量攻击比较少见了，取而代之的是UDP协议承载的DNSQueryFlood攻击。
简单地说，越上层协议上发动的DDoS攻击越难以防御，因为协议越上层，与业务关联越大，防御系统面临的情况越复杂。
DNSQueryFlood就是攻击者操纵大量傀儡机器，对目标发起海量的域名查询请求。
为了防止基于ACL的过滤，必须提高数据包的随机性。
常用的做法是UDP层随机伪造源IP地址、随机伪造源端口等参数。
在DNS协议层，随机伪造查询ID以及待解析域名。
随机伪造待解析域名除了防止过滤外，还可以降低命中DNS缓存的可能性，尽可能多地消耗DNS服务器的CPU资源。
关于DNSQueryFlood的代码，我在2011年7月为了测试服务器性能曾经写过一份代码，链接是
HTTPFlood
上文描述的SYNFlood、DNSQueryFlood在现阶段已经能做到有效防御了，真正令各大厂商以及互联网企业头疼的是HTTPFlood攻击。
HTTPFlood是针对Web服务在第七层协议发起的攻击。
它的巨大危害性主要表现在三个方面：
发起方便、过滤困难、影响深远。
SYNFlood和DNSQueryFlood都需要攻击者以root权限控制大批量的傀儡机。
收集大量root权限的傀儡机很花费时间和精力，而且在攻击过程中傀儡机会由于流量异常被管理员发现，攻击者的资源快速损耗而补充缓慢，导致攻击强度明显降低而且不可长期持续。
HTTPFlood攻击则不同，攻击者并不需要控制大批的傀儡机，取而代之的是通过端口扫描程序在互联网上寻找匿名的HTTP代理或者SOCKS代理，攻击者通过匿名代理对攻击目标发起HTTP请求。
匿名代理是一种比较丰富的资源，花几天时间获取代理并不是难事，因此攻击容易发起而且可以长期高强度的持续。
另一方面，HTTPFlood攻击在HTTP层发起，极力模仿正常用户的网页请求行为，与网站业务紧密相关，安全厂商很难提供一套通用的且不影响用户体验的方案。
在一个地方工作得很好的规则，换一个场景可能带来大量的误杀。
最后，HTTPFlood攻击会引起严重的连锁反应，不仅仅是直接导致被攻击的Web前端响应缓慢，还间接攻击到后端的Java等业务层逻辑以及更后端的数据库服务，增大它们的压力，甚至对日志存储服务器都带来影响。
有意思的是，HTTPFlood还有个颇有历史渊源的昵称叫做CC攻击。
CC是ChallengeCollapsar的缩写，而Collapsar是国内一家著名安全公司的DDoS防御设备。
从目前的情况来看，不仅仅是Collapsar，所有的硬件防御设备都还在被挑战着，风险并未解除。
慢速连接攻击
提起攻击，第一反应就是海量的流量、海量的报文。
但有一种攻击却反其道而行之，以慢著称，以至于有些攻击目标被打死了都不知道是怎么死的，这就是慢速连接攻击，最具代表性的是rsnake发明的Slowloris。
HTTP协议规定，HTTPRequest以\r\n\r\n结尾表示客户端发送结束，服务端开始处理。
那么，如果永远不发送\r\n\r\n会如何？
Slowloris就是利用这一点来做DDoS攻击的。
攻击者在HTTP请求头中将Connection设置为Keep-Alive，要求WebServer保持TCP连接不要断开，随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端，如a:
b\r\n，导致服务端认为HTTP头部没有接收完成而一直等待。
如果攻击者使用多线程或者傀儡机来做同样的操作，服务器的Web容器很快就被攻击者占满了TCP连接而不再接受新的请求。
很快的，Slowloris开始出现各种变种。
比如POST方法向WebServer提交数据、填充一大大Content-Length但缓慢的一个字节一个字节的POST真正数据内容等等。
关于Slowloris攻击，rsnake也给出了一个测试代码，参见http:
//ha.ckers.org/slowloris/slowloris.pl。
DDoS攻击进阶
混合攻击
以上介绍了几种基础的攻击手段，其中任意一种都可以用来攻击网络，甚至击垮阿里、XX、腾讯这种巨型网站。
但这些并不是全部，不同层次的攻击者能够发起完全不同的DDoS攻击，运用之妙，存乎一心。
高级攻击者从来不会使用单一的手段进行攻击，而是根据目标环境灵活组合。
普通的SYNFlood容易被流量清洗设备通过反向探测、SYNCookie等技术手段过滤掉，但如果在SYNFlood中混入SYN+ACK数据包，使每一个伪造的SYN数据包都有一个与之对应的伪造的客户端确认报文，这里的对应是指源IP地址、源端口、目的IP、目的端口、TCP窗口大小、TTL等都符合同一个主机同一个TCPFlow的特征，流量清洗设备的反向探测和SYNCookie性能压力将会显著增大。
其实SYN数据报文配合其他各种标志位，都有特殊的攻击效果，这里不一一介绍。
对DNSQueryFlood而言，也有独特的技巧。
首先，DNS可以分为普通DNS和授权域DNS，攻击普通DNS，IP地址需要随机伪造，并且指明服务器要求做递归解析；但攻击授权域DNS，伪造的源IP地址则不应该是纯随机的，而应该是事先收集的全球各地ISP的DNS地址，这样才能达到最大攻击效果，使流量清洗设备处于添加IP黑名单还是不添加IP黑名单的尴尬处境。
添加会导致大量误杀，不添加黑名单则每个报文都需要反向探测从而加大性能压力。
另一方面，前面提到，为了加大清洗设备的压力不命中缓存而需要随机化请求的域名，但需要注意的是，待解析域名必须在伪造中带有一定的规律性，比如说只伪造域名的某一部分而固化一部分，用来突破清洗设备设置的白名单。
道理很简单，腾讯的服务器可以只解析腾讯的域名，完全随机的域名可能会直接被丢弃，需要固化。
但如果完全固定，也很容易直接被丢弃，因此又需要伪造一部分。
其次，对DNS的攻击不应该只着重于UDP端口，根据DNS协议，TCP端口也是标准服务。
在攻击时，可以UDP和TCP攻击同时进行。
HTTPFlood的着重点，在于突破前端的cache，通过HTTP头中的字段设置直接到达WebServer本身。
另外，HTTPFlood对目标的选取也非常关键，一般的攻击者会选择搜索之类需要做大量数据查询的页面作为攻击目标，这是非常正确的，可以消耗服务器尽可能多的资源。
但这种攻击容易被清洗设备通过人机识别的方式识别出来，那么如何解决这个问题？
很简单，尽量选择正常用户也通过APP访问的页面，一般来说就是各种WebAPI。
正常用户和恶意流量都是来源于APP，人机差别很小，基本融为一体难以区分。
之类的慢速攻击，是通过巧妙的手段占
升级会员 