一、事件发生
春节长假刚过完,WEB就出现故障,下午1点吃完回来,立即将桌面解锁并习惯性的检查了Web服务器。通过Web服务器性能监视软件图像显示的向下滑行的红色曲线看到WEB出现问题了。
根据上述的问题,我马上开始核查Web服务器的日志,试试是否能检测到问题究竟什么时候开始,或者发现一些关于引起中断的线索。正当查询线索过程中。公司首席运营官(CIO)告诉我,他已经接到客户的投诉电话,报告说无法访问他们的网站。于是从台式机中敲入网站地址,试着从台式电脑访问他们的网站,但是看到的只是无法显示此页面的消息。
回想前几天也未对Web服务器做了任何改变也未对Web服务器做过任何改变,服务器曾经出现过的性能问题。在Web服务器的日志文件中没有发现任何可疑之处,因此接下来我去仔细查看防火墙日志,和路由器日志。仔细查看了防火墙日志,打印出了那台服务器出问题时的记录。并过滤掉正常的流量并保留下可疑的记录。表中显示了打印出来的结果。
表一 防火墙日志
之后在路由器日志上做了同样的工作并打印出了看上去异常的记录。
攻击期间的路由器日志
图一
解释:
IP packet sizedistribution 这个标题下的两行显示了数据包按大小范围分布的百分率。这里显示的内容表明:98.4%的数据包的大小在33字节到64字节之间(注意红色标记)。
正常路由日志
图二
IP packet sizedistribution 这个标题下的两行显示了数据包按大小范围分布的百分率。这里显示的内容表明:2%的数据包的大小在33字节到64字节之间。
注意网站的访问量直线下降。很明显,在这段时间没人能访问他的Web服务器。我开始研究到底发生了什么,以及该如何尽快地修复。
二、事件分析
我的Web服务器发生了什么?很有可能攻击,那么受到什么样的攻击呢?从这一攻击是对回显端口看,即是端口7,不断发送小的UDP数据包来实现。攻击看似发自两个策源地,可能是两个攻击者同时使用不同的工具。在任何情况下,超负荷的数据流都会拖垮Web服务器。然而攻击地址源不确定,不知道是攻击源本身是分布的,还是同一个地址伪装出许多不同的IP地址,这个问题比较难判断。假如源地址不是伪装的,是真实地址,则可以咨询ARIN I美国Internet号码注册处,从它的”whois”数据库查出这个入侵1P地址属于哪个网络。接下来只需联系那个网络的管理员就可以得到进一步的信息。
那么假如源地址是伪装的,追踪这个攻击者就麻烦得多。若使用的是Cisco路由器,则还需查询NetFlow高速缓存。NetFlow是Cisco快速转发(CEF)交换框架的特性之一。为了追踪这个伪装的地址,必须查询每个路由器上的NetFlow缓存,才能确定流量进入了哪个接口,然后通过这些路由器一次一个接口地往回一路追踪,直至找到那个IP地址源。然而这样做是非常难的,因为在Web Server和攻击者的发起pc之间可能经由许多路由器,而且属于不同的组织。另外,必须在攻击正在进行时做这些分析。
经过分析之后,将防火墙日志和路由器日志里的信息关联起来,发现了一些有趣的相似性,如表黑色标记处。攻击的目标显然是Web服务器192.68.0.175,端口为UDP 7,即回显端口。这看起来很像拒绝服务攻击(但还不能确定,因为攻击的分布很随意)。地址看起来多多少少是随意而分散的,只有一个源地址是固定不变的,其源端口号也没变。这很有趣。接着又将注意力集中到路由器日志上。
立刻发现,攻击发生时路由器日志上有大量的64字节的数据包,而此时Web服务器日志上没有任何问题。他还发现,案发时路由器日志里还有大量的”UDP-other”数据包,而Web服务器日志也一切正常。这种现象与基于UDP的拒绝服务攻击的假设还是很相符的。
攻击者正是用许多小的UDP数据包对Web服务器的回显(echo 7)端口进行洪泛式攻击,因此他们的下一步任务就是阻止这一行为。首先,我们在路由器上堵截攻击。快速地为路由器设置了一个过滤规则。因为源地址的来源很随机,他们认为很难用限制某个地址或某一块范围的地址来阻止攻击,因此决定禁止所有发给192.168.0.175的UDP包。这种做法会使服务器丧失某些功能,如DNS,但至少能让Web服务器正常工作。
路由器最初的临时DoS访问控制链表(ACL)
这样的做法为Web服务器减轻了负担,但攻击仍能到达web,在一定程度上降低了网络性能。 那么下一步工作是联系上游带宽提供商,想请他们暂时限制所有在他的网站端口7上的UDP入流量。这样做会显著降低网络上到服务器的流量。
三、针对DoS预防措施
对于预防及缓解这种带宽相关的DoS攻击并没有什么灵丹妙药。本质上,这是一种”粗管子打败细管子”的攻击。攻击者能”指使”更多带宽,有时甚至是巨大的带宽,就能击溃带宽不够的网络。在这种情况下,预防和缓解应相辅相成。
有许多方法可以使攻击更难发生,或者在攻击发生时减小其影响,具体如下:
- 网络入口过滤 网络服务提供商应在他的下游网络上设置入口过滤,以防止假信息包进入网络(而把它们留在Internet上)。这将防止攻击者伪装IP地址,从而易于追踪。
- 网络流量过滤 过滤掉网络不需要的流量总是不会错的。这还能防止DoS攻击,但为了达到效果,这些过滤器应尽量设置在网络上游。
- 网络流量速率限制 一些路由器有流量速率的最高限制。这些限制条款将加强带宽策略,并允许一个给定类型的网络流量匹配有限的带宽。这一措施也能预先缓解正在进行的攻击,同时,这些过滤器应尽量设置在网络上游(尽可能靠近攻击者);
- 入侵检测系统和主机监听工具 IDS能警告网络管理员攻击的发生时间,以及攻击者使用的攻击工具,这将能协助阻止攻击。主机监听工具能警告管理员系统中是否出现DoS工具
- 单点传送RPF 这是CEF用于检查在接口收到的数据包的另一特性。如果源IP地址CEF表上不具有与指向接收数据包时的接口一致的路由的话,路由器就会丢掉这个数据包。丢弃RPF的妙处在于,它阻止了所有伪装源IP地址的攻击。
针对DDoS预防措施
看了上面的实际案例我们也了解到,许多DDoS攻击都很难应对,因为搞破坏的主机所发出的请求都是完全合法、符合标准的,只是数量太大。借助恰当的ACL,我们可以阻断ICMP echo请求。但是,如果有自己的自治系统,就应该允许从因特网上ping你。不能ping通会使ISP或技术支持团队(如果有的话)丧失某些故障排解能力。也可能碰到具有Cisco TCP截获功能的SYN洪流:
如果能采用基于上下文的访问控制(Context Based Access Control,CBAC),则可以用其超时和阈值设置应对SYN洪流和UDP垃圾洪流。例如:
警告:建议不要同时使用TCP截获和CBAC防御功能,因为这可能导致路由器过载。
打开Cisco快速转发(Cisco Express Forwarding,CEF)功能可帮助路由器防御数据包为随机源地址的洪流。可以对调度程序做些设置,避免在洪流的冲击下路由器的CPU完全过载:
在做了这样的配置之后,IOS会用3s的时间处理网络接口中断请求,之后用1s执行其他任务。对于较早的系统,可能必须使用命令scheduler interval<milliseconds>。
四、总结
无论是出于报复、敲诈勒索、发起更大规模攻击,DoS或DDoS攻击都是一种不容轻视的威胁。非同一般的DoS攻击通常是某种不完整的漏洞利用,使系统服务崩溃,而不是将控制权交给攻击者。防范这种攻击的办法是及时打上来自厂商的补丁,或者对于Cisco系统,及时将操作系统升级到更新版本。同时,要关闭有漏洞的服务,或者至少要用访问控制列表限制访问。
常规的DoS攻击,特别是DDoS攻击,经常不是那么有章法,也更难防范。如果整个带宽都被蹩脚的ping洪流所耗尽,我们所能做的就很有限了。最后,必须与ISP和权力部门协作,尽可能从源头上阻止攻击。要用不同供应商、不同AS路径并支持负载均衡功能的不止一条到因特网的连接,但这与应对消耗高带宽的常规DoS/DDoS洪流的要求还相差很远。我们总是可以用CAR或NBAR来抛弃数据包或限制发动进攻的网络流速度,减轻路由器CPU的负担,减少对缓冲区和路由器之后的主机的占用。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
NSS实验室评估下一代防火墙
根据NSS实验室对下一代防火墙的评估发现,来自七家供应商的产品可有效保护企业免受恶意流量的侵害,而且总体拥有成 […]
-
阿里云成功防御国内最大规模Memcached DDoS反射攻击
上周,阿里云安全DDoS监控中心数据显示,利用Memcached 进行DDoS攻击的趋势快速升温。尽管如此, […]
-
物联网攻击哪家强?Hajime或盖Mirai风头
在近期关于物联网设备控制权的“争夺赛”中,Hajime蠕虫软件和Marai僵尸网络各有千秋,不过相比之下,Hajime更为隐秘,或盖Marai风头。
-
CLDAP反射攻击或是下一个强力DDoS攻击技术
如今,DDoS攻击活动规模越来越大,一种滥用CLDAP进行反射攻击的新方法可能会允许恶意攻击者使用较少的设备生成大量DDoS流量,企业需对其提高重视。