网站遭遇DOS***
(如果对DOS***原理不太理解，大家可以先看下面这段视频：http://www.tudou.com/programs/view/U0_G3LitPMY/)
一、事件背景
长假对于IT人员来说是个短暂的休整时期，可IT系统却一时也不能停，越是节假日，越可能出大问题，下面要讲述的就是一起遭受DOS***的案例。
春节长假刚过完，小李公司的Web服务器就出了故障。下午1点，吃完饭回来，小李习惯性的检查了Web服务器。Web服务器的流量监控系统显示下行的红色曲线，与此同时收到了邮件报警，可以判断服务器出现了状况。
根据上述问题，小李马上开始核查Web服务器的日志，尝试发现一些关于引起中断的线索。正当查询线索过程中，部门经理告诉小李，他已经接到客户的投诉电话，说无法访问他们的网站。
在Web服务器的日志文件中没有发现任何可疑之处，因此接下来小李仔细查看了防火墙日志和路由器日志。打印出了那台服务器出问题时的记录，并过滤掉正常的流量，保留下可疑的记录。表1显示了打印出来的结果。
表 1 防火墙日志统计
源IP地址 | 目的IP地址 | 源端口 | 目的端口 | 协议 |
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综合统计信息，详情如下：
为了有参考基准，他还打印了在Web服务器开始出现问题的前几周他保存的缓存数据（这些是正常状态的数据）。正常路由日志，如下所示：
IP packet size distribution 这个标题下的两行显示了数据包按大小范围分布的百分率。这里显示的内容表明：只有2%的数据包的大小在33～64字节之间。
注意，网站的访问量直线下降。很明显，在这段时间没人能访问他的Web服务器。小李开始研究到底发生了什么，以及该如何尽快地修复故障。
二、疑难问答
1.小李的Web服务器到底发生了什么？可能的***类型是什么？
2.如果地址未伪装，那么小李如何才能追踪到***者？
3.如果地址伪装过，那么他怎样才能跟踪到***者？
三、事件推理
小李的Web服务器遭受到什么样的***呢？这一***是通过对回显端口（echo端口号为7），不断发送UDP数据包实现。***看似发自两个地方，可能是两个***者同时使用不同的工具。在任何情况下，超负荷的数据流都会拖垮Web服务器。然而***地址源不确定，不知道是***源本身是分布的，还是同一个真实地址伪装出许多不同的虚假IP地址，这个问题比较难判断。假如源IP地址不是伪装的，则可以咨询ARINI美国Internet号码注册处，从它的“Whois”数据库查出这个***IP地址属于哪个网络。接下来只需联系那个网络的管理员就可以得到进一步的信息不过这对DOS***不太可能。
假如源地址是伪装的，追踪这个***者就麻烦得多。若使用的是Cisco路由器，则还需查询NetFlow高速缓存。但是为了追踪这个伪装的地址，必须查询每个路由器上的NetFlow缓存，才能确定流量进入了哪个接口，然后通过这些路由器接口，逐个往回追踪，直至找到那个IP地址源。然而这样做是非常难的，因为在Web Server和***者的发起PC之间可能有许多路由器，而且属于不同的组织。另外，必须在***正在进行时做这些分析。如果不是由司法部门介入很难查到源头。
经过分析之后，将防火墙日志和路由器日志里的信息关联起来，发现了一些有趣的相似性，如表5-1中粗黑体黑色标记处。***的目标显然是Web服务器（192.168.0.175，端口为UDP 7。这看起来很像拒绝服务***(但还不能确定，因为***的源IP地址分布随机）。地址看起来是随机的，只有一个源地址固定不变，其源端口号也没变。这很有趣。他接着又将注意力集中到路由器日志上。
他发现，***发生时路由器日志上有大量的64字节的数据包，而此时Web服务器日志上没有任何问题。他还发现，案发时路由器日志里还有大量的“UDP-other”数据包，而Web服务器日志也一切正常。这种现象与基于UDP的拒绝服务***的假设还是很相符的。
此时，可假设***者正是用许多小的UDP数据包对Web服务器的回显(echo 7)端口进行洪泛式***，因此小李他们的下一步任务就是阻止这一***行为。首先，小李在路由器上堵截***。快速地为路由器设置了一个过滤规则。因为源地址的来源随机，他们认为很难用限制某个地址或某一块范围的地址来阻止***，因此决定禁止所有发给192.168.0.175的UDP包。这种做法会使服务器丧失某些功能，如DNS，但至少能让Web服务器正常工作。
路由器最初的临时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
这样的做法为Web服务器减轻了负担，但***仍能到达Web，在一定程度上降低了网络性能。 那么下一步工作是联系上游带宽提供商，想请他们暂时限制所有在小李的网站端口7上的UDP进入流量，这样做会显著降低网络上到服务器的流量。
四 、针对措施
对于预防及缓解这种带宽相关的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.小李的服务器遭到了DOS***，***是通过对端口7不断发送小的UDP数据包实现的。这次***看起来源自两个地方，很可能是两个***者使用不同的工具。大量的数据流很快拖垮Web服务器。难点在于***地址源不确定，***源本身是分布的，还是同一个地址伪装出的许多不同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的负担，减少对缓冲区和路由器之后的主机的占用。
