DDOS的攻击讲解和防护

在前几日，我们经营的某网站遭到了一次ddos进攻，我们的网站是一个公益性特性的网站，为各个生产商和白帽子之间构建一个平台以传送安全隐患等信息，我们并不清楚因为是什么原因会遭遇这种厚颜无耻的进攻。因为我们本身并不从事这种类型的进攻，这种进攻技术一般也是比较不光滑的，所以探讨得比较少，但是既然发生了这样的进攻我们感觉分享进攻发生后我们在这个过程初中到得东西，以及针对这种进攻我们的念头才能让此次进攻产生真正的价值，而并不是这样的进攻只是浪费大家的时间罢了。

　　另外，我们发现大型的企业都有遭到进攻的实例，但是大家遭到进攻之后的解决对策及学得的经验却分享都比较少，这造成每家都是自主的探求经验，仍然滞留在一家企业抵抗整个互联网技术的进攻的局势，而对于网络攻击确是本次进攻针对你，到时候进攻确是针对他了，而且进攻之后不论是技术还是资源也没有任何的耗损，这也是造成这种进攻经常并且明目张胆的原因。

　　我们来试着做一些改变：）

　　在进攻发生后，第一个现象是我们的网站登不上了，但是仍然可以浏览到管理界面，我们登录上来简单实行了指令：

　　netstat -antp

　　我们见到有大量的连接存在着，并且都是ESTABLISHED状态，正常状态下我们的网站流量没有那么高，如果有那么高我们相信中国的网络信息安全就有希望了，对于这样的情况其实处理就非常简单，这是一次四层的进攻，也就是所有ip都是真实的，由于迄今为止只是耗费了webserver的数据连接资源，所以我们只需要简单的将这些ip在网络层禁封就可以，非常简单，用下面的指令即可：

　　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

　　随后作为计划任务1分钟实行一次即可，迅速，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提供支持的，由于临时无法融洽进行相应的操作，后果如大家见到，我们的服务比较慢，基本上终止了服务，在一段时间之后网络攻击终止了进攻，服务才进行了修复，很恼火是么？但是同时我们得到了很多热情朋友的帮助，得到了更好的网络和服务器空间，在共享资源方面的能力得到了很大的提升，减轻了这行的问题，这里对他们表示感激。

继续秉持着80sec的”Know it互联网 then hack it互联网”，这里简单谈一下ddos攻击和防御能力方面的问题。ddos的全称分布式系统拒绝服务攻击，既然是拒绝服务一定由于一些原因而停止服务的，其中最重要的也是最常见的原因就是利用服务端方面资源的有限性，这种服务端的资源范围很广，可以简单的梳理一个乞求正常完成的过程：

　　1 用户在app客户端电脑浏览器输入乞求的具体地址

　　2 电脑浏览器分析该乞求，包括分析其中的dns以明确需要到达的远程服务器具体地址

　　3 明确具体地址后电脑浏览器和云端服务器的服务试着建立连接，试着建立连接的数据文件通过本地连接，中间无线路由最后艰辛到达目标网络再到达目标云端服务器

　　4 移动数据建立完成之后电脑浏览器根据乞求建立不同的数据文件并且将数据文件发送到云端服务器某个服务器端口

　　5 端口映射到系统进程，系统进程接受到数据文件之后进行内部的分析

　　6 乞求云端服务器内部的各种不同的资源，包括后web端接口文档以及一些数据库查询或者文件等

　　7 在思维逻辑处理完成之后数据文件按照之前建立的安全出口返回到用户电脑浏览器，电脑浏览器完成分析，乞求完成。

　　上面各个点都可以被用于进行ddos攻击，包括：

　　1 一些著名的app客户端遭劫持病毒性感染，你是否还记得预览网页搜索跳搜狗翻译的事情么？：）

　　2 某个大型互联网公司发生的dns遭劫持事件，或者直接大量的dns乞求直接攻击dns云端服务器，这里可以使用一些专业的第三方dns服务来缓解这个问题，如Dnspod

　　3 利用建立移动数据需要的资源共享攻击服务器带宽促进正常数据文件无法到达如udp的洪水攻击，消耗前端工程师设备的Cpu资源以促进数据文件不能有效上传如icmp和一些碎片包的洪水攻击，消耗云端服务器方建立正常连接需要的资源如syn flood?蛘呔褪钦加么罅康牧邮沟谜５牧游薹ǚ⑵穑┤缯獯?腡Cpu flood

　　4 利用webserver的一些特点进行攻击，对比nginx来讲，apache处理一个乞求的过程就比较好沉。

　　5 利用手机应用程序内部的一些特性攻击程序内部的资源如mysql，后端开发消耗资源大的插孔等等，这也就是传统上的Cc攻击。

　　这里涉及到功防的定义，但是实际上如果了解对方的攻击点和攻击方法，防御能力会变成简单的一个拼资源的过程，不要你最弱的地方去抗他人最強的地方，应该从最好的地方着手把解决困难掉，比如在无线路由等设备上解决网络层攻击就不是一个好的方法，同理，在网络层试着解决网络层的问题也是不可能的，简单来讲，目标是只让正常的数据和乞求进入到我们的服务，一个完善的防御能力体系管理应该考虑如下几个方面：

　　1 作为用户乞求的安全通道，必须有良好的dns防御能力

　　2 与你的价值相一致的服务器带宽资源，并且在核心节点上布局好网络层的防御能力防范措施，只允许你的正常应用的网络数据文件能够进入，比如遭禁除了80之外的所有数据文件

　　3 有支持你的服务价值的设备集群服务器来抵挡网络层的压力，有必要的话需要将一个.Com乞求继续融解，将连接建立的过程压力融解到其他的集群服务器里，这里仿佛已经有一般的企业防火墙能做这个事情，甚至将正常的.Com乞求分析过程都进行融解，保证到达后web端是正常的乞求，去祛除畸形的乞求，将正常的乞求的乞求频率等行为进行记录和监控，如果发生异常就在这里进行网络层的遭禁

　　每个公司都有自己对自己价值的评估从而决定安全投入上的大小，每一次攻击也会涉及到权益的存在，好似防御能力因为种种原因比如投入上的不足和实行过程中的遗憾，有着先天的缺陷一样，攻击也是有着先天的缺陷的，因为每一次攻击涉及到不同的环节，每个环节都可能由不同水平的人完成，他所拥有的资源，他使用的工具和技术都不会是完美的，所以才有可能进行防御能力，另外，相信进行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在2500也就是三十分钟，这个网站域名在所有的搜索引擎中都不存在记录，是一个韩国人在godady半年前才注册的，同时我们浏览这个域名指向服务器的3389，简单的通过5下shift就判断出它上面存在着一个典型性的windows侧门，好像我们找到它了，不是么？经过后续的观察，一段时间后这个域名指向到了127.0.0.1，我们相信了我们的参考答案,workgroup001.snow****.net，看上去好像对自己的僵尸网络管理很好嘛：）

　　这是一次典型性的ddos进攻，进攻之后我们获得了参加进攻的服务器目录和控制web端网站域名及ip，相信中国和韩国的cert对于清除此次的进攻源很有兴趣爱好，我们都是有一些损失，但是网络攻击也有损失了（大概包括一个僵尸网络及一个控制端网站域名，甚至可能包括一次内部的法律调研），我们不再不是公平的了，不是么？

　　如同一个朋友所说的，所有的防御力是缺憾的如同进攻是缺憾的一样，好的防御者在提高自己的防御力趋向完美的同时也要擅于找寻网络攻击的缺憾，找寻一次进攻中的系统漏洞，不要对进攻心存害怕，对于Ddos进攻来讲，进行一次进攻一样是存在系统漏洞的，如果我们能够善于利用其中的系统漏洞并且把握住后边的网络攻击那么相信之后的ddos进攻实例将会减少很多，在针对目标进行进攻之前网络攻击也会做更多的衡量，损失，权益和法律。