网站建设安全DDOS攻击与防御
另外,我们发现大型的企业都有遭受攻击的案例,但是大家遭受攻击之后的应对措施及学到的经验却分享都比较少,这导致各家都是自行的摸索经验,依然停留在一家企业对抗整个互联网的攻击的局面,而对于攻击者却是此次攻击针对你,下次攻击却是针对他了,而且攻击之后无论是技术还是资源都没有任何的损耗,这也是导致这种攻击频繁并且肆无忌惮的原因。
我们来尝试做一些改变:)
常见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分布,攻击工具的特征,甚至有能力的可以去分析背后的利益点及操作者,那么每一次攻击都能让大家的整体防御能力上升,让攻击者的攻击能力有损失,我们很愿意来做这个事情。
应急响应
在攻击发生后,第一个现象是我们的网站上不去了,但是依然可以访问到管理界面,我们登陆上去简单执行了命令:
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
然后作为计划任务一分钟执行一次即可,很快,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提供支持的,由于临时无法协调进行相应的操作,后果如大家看到,我们的服务很慢,基本上停止了服务,在一段时间之后攻击者停止了攻击,服务才进行了恢复,很憋屈是么?但是同时我们得到了很多热心朋友的帮助,得到了更好的网络和服务器资源,在网络资源方面的能力得到了很大的提升,缓解了这方面的问题,这里对他们表示感谢。
根源及反击
我困惑的是一点,攻击我们并不能得到实际的好处为什么还是有人来攻击,而且听说其他公司都有被攻击的情况,我觉得有一点原因就是攻击我们的确得不到什么好处,但是实际上攻击者也并不损失什么,无论是资源上还是法律风险上,他不会因为一次攻击而损失太多,而相比之下,服务提供者损失的东西却太多了,这从经济学角度来讲就是不平衡的,我们处于弱势。
一般而言,的确对于作恶者是没有什么惩罚措施,但是这次,我们觉得我们是可以做一些事情的,我们尝试挖掘背后的攻击者,甚至清除这个僵尸网络。
首先这次攻击起源于应用层的攻击,所以所有的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攻击案例将会减少很多,在针对目标发起攻击之前攻击者也会做更多的权衡,损失,利益和法律。
本文发布于北京网站建设公司中欧体育 中国//mkt0398.com/
推荐新闻
更多行业-
网站制作如何从用户体验的角度展开
网站能否得到用户的认可,其很大程度上是网站的内部因素决定的,就是网站的...
2012-10-26 -
企业简约风网站设计怎么样?
随着时代的变化,越来越多的用户喜欢简单的网站,简单大气的网站风格逐渐成...
2020-10-20 -
网站建设模糊搜索功能制作要求
要制作一个网站的模糊搜索功能,可以按照以下要求进行设计和开发 用户界...
2023-07-17 -
网页制作需要下载什么软件?网页设计需要什么软件
网页制作需要下载什么软件?DREAMWEAVER(网页制作) FLAS...
2012-05-29 -
网站设计的基本原则
网站设计流程一般为:确定网站目的->收集网站信息->网站信...
2014-06-21 -
网站收录下降到底意味着什么
得首先针对性找出原因并改正。力争网站建设的权重尽快的恢复进去。为了网站...
2012-06-22
预约专业咨询顾问沟通!
免责声明
非常感谢您访问我们的网站。在您使用本网站之前,请您仔细阅读本声明的所有条款。
1、本站部分内容来源自网络,涉及到的部分文章和图片版权属于原作者,本站转载仅供大家学习和交流,切勿用于任何商业活动。
2、本站不承担用户因使用这些资源对自己和他人造成任何形式的损失或伤害。
3、本声明未涉及的问题参见国家有关法律法规,当本声明与国家法律法规冲突时,以国家法律法规为准。
4、如果侵害了您的合法权益,请您及时与我们,我们会在第一时间删除相关内容!
联系方式:010-60259772
电子邮件:394588593@qq.com