真实故事：网站遭遇DOS攻击



网站遭遇DOS攻击

一个、事件背景

    长假对于IT人员来说是个短暂的休整时期，可IT系统却一时也不能停。越是节假日，越可能出大问题，以下要讲述的就是一起遭受DOS攻击的案例。

    春节长假刚过完，小李公司的Webserver就出了故障。下午1点。吃完饭回来，小李习惯性的检查了Webserver。Webserver的流量监控系统显示下行的红色曲线，与此同一时候收到了邮件报警，能够推断server出现了状况。

    依据上述问题。小李立即開始核查Webserver的日志。尝试发现一些关于引起中断的线索。

正当查询线索过程中，部门经理告诉小李。他已经接到客户的投诉电话，说无法訪问他们的站点。

在Webserver的日志文件里没有发现不论什么可疑之处，因此接下来小李细致查看了防火墙日志和路由器日志。打印出了那台server出问题时的记录，并过滤掉正常的流量。保留下可疑的记录。

表1显示了打印出来的结果。

表 1  防火墙日志统计

源IP地址	目的IP地址	源port	目的port	协议
172.16.45.2	192.168.0.175	7843	7	17
10.18.18.18	192.168.0.175	19	7	17
10.168.45.3	192.168.0.175	34511	7	17
10.18.18.18	192.168.0.175	19	7	17
192.168.89.111	192.168.0.175	1783	7	17
10.18.18.18	192.168.0.175	19	7	17
10.231.76.8	192.168.0.175	29589	7	17
192.168.15.12	192.168.0.175	17330	7	17
10.18.18.18	192.168.0.175	19	7	17
172.16.43.131	192.168.0.175	8935	7	17
10.23.67.9	192.168.0.175	22387	7	17
10.18.18.18	192.168.0.175	19	7	17
192.168.57.2	192.168.0.175	6588	7	17
172.16.87.11	192.168.0.175	21453	7	17
10.18.18.18	192.168.0.175	19	7	17
10.34.67.89	192.168.0.175	45987	7	17
10.65.34.54	192.168.0.175	65212	7	17
192.168.25.6	192.168.0.175	52967	7	17
172.16.56.15	192.168.0.175	8745	7	17
10.18.18.18	192.168.0.175	19	7	17

    他在路由器日志上做了相同的工作并打印出了看上去异常的记录。在表5-1中是站点遭受攻击期间。经过规整化处理后的路由器日志信息。

为了获取很多其它信息，小李接着查看了路由器中NetFlow综合统计信息，详情例如以下：

    为了有參考基准，他还打印了在Webserver開始出现故障的前几周他保存的缓存数据（这些是正常状态的数据）。

正常路由日志，例如以下所看到的：

    IP packet size distribution 这个标题下的两行显示了数据包按大小范围分布的百分率。

这里显示的内容表明：仅仅有2%的数据包的大小在33～64字节之间。

    注意，站点的訪问量直线下降。非常明显。在这段时间没人能訪问他的Webserver。小李開始研究究竟发生了什么。以及该怎样尽快地修复故障。

二、疑难问答

1.小李的Webserver究竟发生了什么？可能的攻击类型是什么？

2.假设地址未伪装，那么小李怎样才干追踪到攻击者？

3.假设地址伪装过。那么他如何才干跟踪到攻击者？

三、事件推理

     小李的Webserver遭受到什么样的攻击呢？这一攻击是通过对回显port（echoport号为7），不断发送UDP数据包实现。攻击看似发自两个地方，可能是两个攻击者同一时候使用不同的工具。

在不论什么情况下，超负荷的数据流都会拖垮Webserver。然而攻击地址源不确定，不知道是攻击源本身是分布的，还是同一个真实地址伪装出很多不同的虚假IP地址。这个问题比較难推断。

假如源IP地址不是伪装的，则能够咨询ARINI美国Internet号码注冊处，从它的“Whois”数据库查出这个入侵IP地址属于哪个网络。接下来仅仅需联系那个网络的管理员就能够得到进一步的信息只是这对DOS攻击不太可能。

    假如源地址是伪装的，追踪这个攻击者就麻烦得多。若使用的是Cisco路由器。则还需查询NetFlow快速缓存。

可是为了追踪这个伪装的地址，必须查询每一个路由器上的NetFlow缓存，才干确定流量进入了哪个接口，然后通过这些路由器接口。逐个往回追踪，直至找到那个IP地址源。

然而这样做是非常难的。由于在Web Server和攻击者的发起PC之间可能有很多路由器。并且属于不同的组织。另外。必须在攻击正在进行时做这些分析。

假设不是由司法部门介入非常难查到源头。

     经过分析之后，将防火墙日志和路由器日志里的信息关联起来，发现了一些有趣的相似性。如表5-1中粗黑体黑色标记处。攻击的目标显然是Webserver（192.168.0.175，port为UDP 7。这看起来非常像拒绝服务攻击(但还不能确定，由于攻击的源IP地址分布随机）。地址看起来是随机的，仅仅有一个源地址固定不变。其源port号也没变。这非常有趣。他接着又将注意力集中到路由器日志上。

    他发现，攻击发生时路由器日志上有大量的64字节的数据包，而此时Webserver日志上没有不论什么问题。他还发现，案发时路由器日志里还有大量的“UDP-other”数据包，而Webserver日志也一切正常。这样的现象与基于UDP的拒绝服务攻击的如果还是非常相符的。

    此时，可如果攻击者正是用很多小的UDP数据包对Webserver的回显(echo 7)port进行洪泛式攻击，因此小李他们的下一步任务就是阻止这一攻击行为。首先，小李在路由器上堵截攻击。高速地为路由器设置了一个过滤规则。由于源地址的来源随机，他们觉得非常难用限制某个地址或某一块范围的地址来阻止攻击。因此决定禁止全部发给192.168.0.175的UDP包。

这样的做法会使server丧失某些功能，如DNS，但至少能让Webserver正常工作。

路由器最初的暂时DOS訪问控制链表(ACL)例如以下：

access-list 121 remark Temporary block DoS attack on web server 192.168.0.175

access-list 105 deny udp any host 192.168.0.175

access-list 105 permit ip any any

    这种做法为Webserver减轻了负担，但攻击仍能到达Web。在一定程度上减少了网络性能。

那么下一步工作是联系上游带宽提供商，想请他们临时限制全部在小李的站点port7上的UDP进入流量，这样做会显著减少网络上到server的流量。

四 、针对措施

    对于预防及缓解这样的带宽相关的DOS攻击并没有什么灵丹妙药。本质上，这是一种“粗管子打败细管子”的攻击。攻击者能“指使”很多其它带宽。有时甚至是巨大的带宽，就能击溃带宽不够的网络。在这样的情况下。预防和缓解应相辅相成。

    有很多方法能够使攻击更难发生，或者在攻击发生时减小其影响，详细例如以下：

    网络入口过滤网络服务提供商应在他的下游网络上设置入口过滤，以防止假信息包进入网络。

这将防止攻击者伪装IP地址。从而易于追踪。网络流量过滤软件过滤掉网络不须要的流量总是不会错的。这还能防止DOS攻击，但为了达到效果，这些过滤器应尽量设置在网络上游。

   网络流量速率限制。一些路由器有流量速率的最高限制。

这些限制条款将加强带宽策略。并同意一个给定类型的网络流量匹配有限的带宽。

这一措施也能预先缓解正在进行的攻击。

    入侵检測系统和主机监听工具。IDS能警告网络管理员攻击的发生时间，以及攻击者使用的攻击工具。这将能协助阻止攻击。主机监听工具能警告管理员系统中是否出现DOS工具

单点传送RPF（Reverse Path Forwarding），这是CEF（路由器的Cisco Express Forwarding功能简称）用于检查在接口收到的数据包的还有一特性。假设源IP地址CEF表上不具有与指向接收数据包时的接口一致的路由，路由器就会丢掉这个数据包。丢弃RPF的妙处在于，它阻止了全部伪装源IP地址的攻击。

1）检測DOS攻击

    利用主机监測系统和IDS系统联合分析。能够非常快发现问题，比如通过EtherApe工具(一款监视连接的开源工具)，当然，利用Sniffer Pro以及科莱网络分析工具能够达到相同效果。Sniffer能实时显示网络连接情况，假设遇到DOS攻击,从它内部密密麻麻的连线。以及IP地址就能初步判定攻击类型。这时能够採用Ossim系统中的流量监控软件比如Ntop。以及IDS系统来细致推断。后两者将在《Unix/Linux网络日志分析与流量监控》一书中具体解说。最快捷的方式还是命令行，我们输入下面命令：

# netstat -an|grep SYN_RECV|wc –l

    通过结果能够发现网络中存在大量TCP同步数据包，而成功建立TCP连接的却寥寥无几，依据TCP三次握手原理分析可知，这肯定不是正常现象，网络肯定存在问题。须要进一步查实，假设数值非常高，比如达到上千数值，那么非常有可能是受到了攻击。如图1所看到的。

图 1 Ossim发现DOS攻击

在图1中OSSIM系统中的Snort检測到DOS攻击并以图形方式显示出大量告警信息。比如，某站点在受到DOS攻击时TCP连接例如以下：

我们统计“SYN_RECV”状态的数量。命令例如以下：

#netstat –na |grep SYN_RECV |wc –l

1989

这么大数值，在配合上面5-1图形能够推断站点受到DOS攻击。

小技巧：还能够用以下的Shell命令。显示哪个IP连接最多。

#netstat -nta |awk ‘{print $5}’ |cut –d:f1 |sort|uniq –c |sort –n

1 192.168.150.10

2 192.168.150.20

… …

1987 192.168.150.200

这条命令得到的信息更具体。

数值达到1989，有近两千条。这明显说明受到了DOS攻击。 这时我们利用Wireshark工具进行数据包解码能够法相很多其它问题，当前通讯全都是採用TCP协议。查看TCP标志发送全部的数据包均为SYN置1，即TCP同步请求数据包，而这些数据包往往指向同一个IP地址。至此能够验证上面的推断：这台主机遭受到DOS攻击，而攻击方式为SYN Flood攻击。

五、疑难解答

1.小李的server遭到了DOS攻击。攻击是通过对port7不断发送小的UDP数据包实现的。

这次攻击看起来源自两个地方，非常可能是两个攻击者使用不同的工具。

大量的数据流非常快拖垮Webserver。难点在于攻击地址源不确定，攻击源本身是分布的。还是同一个地址伪装出的很多不同IP地址不好确定。

2.如果地址不是伪装的。小李查询ARIN。从它的Whois数据库中查出这个入侵IP地址属于哪个网络。

3.假设IP地址是伪装的，这样的追踪比較麻烦，须要查询每台路由器上的NetFlow数据，才干确定流量进出在哪些接口，然后对这些路由器一次一个接口的往回逐跳追踪查询，直到找到发起的IP地址源。可是这样做涉及多个AS（自治系统）。假设在国内寻找其攻击源头

的过程往往涉及非常多运营商，以及司法机关。工作量和时间都会延长。假设涉及跨国追查工作就更加复杂。最困难的是必须在攻击期间才干做准确分析。一旦攻击结束就仅仅好去日志系统里查询了。

看了上面的实际案例我们也了解到，很多DoS攻击都非常难应对。由于搞破坏的主机所发出的请求都是全然合法、符合标准的，仅仅是数量太大。我们能够先在路由器上借助恰当的ACL阻断ICMP echo请求。

Router(config)#ip tcp intercept list 101

Router(config)#ip tcp intercept max-incomplete high 3500

Router(config)#ip tcp intercept max-incomplete low 3000

Router(config)#ip tcp intercept one-minute high 2500

Router(config)#ip tcp intercept one-minute low 2000

Router(config)#access-list 101 permit any any

假设能採用基于上下文的訪问控制(Context Based Access Control,CBAC)，则能够用其超时和阈值设置应对SYN洪流和UDP垃圾洪流。

比如：

Router(config)# ip inspect tcp synwait-time 20

Router(config)# ip inspect tcp idle-time 60

Router(config)# ip inspect udp idle-time 20

Router(config)# ip inspect max-incomplete high 400

Router(config)# ip inspect max-incomplete low 300

Router(config)# ip inspect one-minute high 600

Router(config)# ip inspect one-minute low 500

Router(config)# ip inspect tcp max-incomplete host 300 block-time 0

警告：建议不要同一时候使用TCP截获和CBAC防御功能，由于这可能导致路由器过载。

    打开Cisco高速转发(Cisco Express Forwarding，CEF)功能可帮助路由器防御数据包为随机源地址的洪流。能够对调度程序做些设置，避免在洪流的冲击下路由器的CPU全然过载：

Router(config)#scheduler allocate 3000 1000

    在配置之后。IOS会用3秒的时间处理网络接口中断请求。之后用1秒运行其它任务。对于较早的系统。可能必须使用命令scheduler interval<milliseconds>。

还有一种方法是利用Iptables预防DOS脚本

#!/bin/bash

netstat -an|grep SYN_RECV|awk '{print$5}'|awk -F: '{print$1}'|sort|uniq -c|sort -rn|awk '{if ($1 >1) print $2}'

for i in $(cat /tmp/dropip)

do

/sbin/iptables -A INPUT -s $i -j DROP

echo “$i kill at `date`” >>/var/log/ddos

done

   该脚本会对处于SYN_RECV而且数量达到5个的IP做统计。而且把写到Iptables的INPUT链设置为拒绝。

六、案例总结

    不管是出于何种目的而发起更大规模攻击或其它目的DOS/DDoS攻击都必须重视。防范这样的攻击的办法主要有及时打上来自厂商的补丁。

同一时候，要关闭有漏洞的服务，或者用訪问控制列表限制訪问。

常规的DOS攻击。特别是DDOS攻击更难防范。假设整个带宽都被Ping洪流耗尽，我们能做的就非常有限了。

针对DOS攻击。首先要分析它的攻击方式，是ICMP Flood 、UDP Flood和SYN Flood等流量攻击，还是类似于TCP Flood、CC等方式，然后再寻找相对有效的应对策略。对于这样的攻击能够採取以下介绍的几种方法：

1）.利用“蜜网”防护,加强对攻击工具和恶意样本的第一时间分析和响应。

大规模部署蜜网设备以便追踪僵尸网络的动态,捕获恶意代码。

部署站点执行监控设备,加强对网页挂马、訪问重定向机制和域名解析的监控,切断恶意代码的主要感染途径。

採用具备沙箱技术和各种脱壳技术的恶意代码自己主动化分析设备,加强对新型恶意代码的研究,提高研究的时效性。

2).利用Ossim系统提供的Apache Dos防护策略能够起到监控的作用。

3）.利用云计算和虚拟化等新技术平台。提高对新型攻击尤其是应用层攻击和低速率攻击的检測和防护的效率。国外己经有学者開始利用Hadoop平台进行Http Get Flood的检測算法研究。

4）.利用IP信誉机制。

在信息安全防护的各个环节引入信誉机制,提高安全防护的效率和精确度。比如相应用软件和文件给予安全信誉评价。引导网络用户的下载行为，通过公布权威IP信誉信息，指导安全设备自己主动生成防护策略，详情见《Unix/linux网络日志分析与流量监控》2.1节。

5）.採用被动策略即购买大的带宽，也能够有效减缓DDOS攻击的危害。

6）.构建分布式的系统，将自己的业务部署在多地机房。将各地区的訪问分散到相应的机房，考虑部署CDN，在重要IDC节点机房部署防火墙（比如Cisco、Juniper防火墙等）这样即使有攻击者进行DOS攻击，破坏范围可能也不过当中的一个机房，不会对整个业务造成影响。

7）.假设规模不大，机房条件一般。那能够考虑在系统中使用一些防DDos的小工具。如DDoS Deflate。它的官网地址是http://deflate.medialayer.com ,它是一款免费的用来防御和减轻DDOS攻击的脚本，通过系统内置的netstat命令。来监測跟踪创建大量网络连接的IP地址，在检測到某个结点超过预设的限制时，该程序会通过APF或IPTABLES禁止或阻挡这些IP。

当然此工具也不过减轻，并不能所有防止攻击。

    最后还要用不同供应商、不同AS路径并支持负载均衡功能的不止一条到因特网的连接，但这与应对消耗高带宽的常规DOS/DDOS洪流的要求还有差距。我们总是能够用CAR（Committed Access Rate，承诺訪问速率）或NBAR(Network-Based Application Recognition，网络应用识别)来抛弃数据包或限制发动进攻的网络流速度，减轻路由设备CPU负担。降低主机缓冲器的占用和路由器后。

版权声明：本文博客原创文章。博客，未经同意，不得转载。