传统上，攻击者所面临的主要问题是网络带宽，由较小的网络规模和较慢的网络速度，无法使攻击者发出过多的请求，然而，类似"the ping of death"的攻击类型紧需要很少量的包就可以摧毁一个没有打过补丁的UNIX系统。当然，多数的DoS攻击还是需要相当大的带宽的，但是高带宽是大公司所拥有的，而以个人为主的黑客很难享用。为了克服这个缺点，恶意的攻击者开发了分布式的攻击。这样，攻击者就可以利用工具集合许多的网络带宽来对同一个目标发送大量的请求。

以下的两种情况最容易导致拒绝服务攻击：

· 由于程序员对程序错误的编制，导致系统不停的建立进程，最终耗尽资源，只能重新启动机器。不同的系统平台都会采取某些方法可以防止一些特殊的用户来占用过多的系统资源，我们也建议尽量采用资源管理的方式来减轻这种安全威胁。

· 还有一种情况是由磁盘存储空间引起的。假如一个用户有权利存储大量的文件的话，他就有可能只为系统留下很小的空间用来存储日志文件等系统信息。这是一种不良的操作习惯，会给系统带来隐患。这种情况下应该对系统配额作出考虑。

从安全的角度来看，本地的拒绝服务攻击可以比较容易的追踪并消除。而我们这篇文章主要是针对于网络环境下的DoS攻击。下面我们大体讨论一下较为常见的基于网络的拒绝服务攻击：

· Smurf (directed broadcast)。广播信息可以通过一定的手段（通过广播地址或其他机制）发送到整个网络中的机器。当某台机器使用广播地址发送一个ICMP echo请求包时（例如PING），一些系统会回应一个ICMP echo回应包，也就是说，发送一个包会收到许多的响应包。Smurf攻击就是使用这个原理来进行的，当然，它还需要一个假冒的源地址。也就是说在网络中发送源地址为要攻击主机的地址，目的地址为广播地址的包，会使许多的系统响应发送大量的信息给被攻击主机（因为他的地址被攻击者假冒了）。使用网络发送一个包而引出大量回应的方式也被叫做"放大器"，这些smurf放大器可以在www.netscan.org网站上获得，一些无能的且不负责任的网站仍有很多的这种漏洞。

· SYN flooding 一台机器在网络中通讯时首先需要建立TCP握手，标准的TCP握手需要三次包交换来建立。一台服务器一旦接收到客户机的SYN包后必须回应一个SYN/ACK包，然后等待该客户机回应给它一个ACK包来确认，才真正建立连接。然而，如果只发送初始化的SYN包，而不发送确认服务器的ACK包会导致服务器一直等待ACK包。由于服务器在有限的时间内只能响应有限数量的连接，这就会导致服务器一直等待回应而无法响应其他机器进行的连接请求。

· Slashdot effect 这种攻击手法使web服务器或其他类型的服务器由于大量的网络传输而过载，一般这些网络流量是针对某一个页面或一个链接而产生的。当然这种现象也会在访问量较大的网站上正常发生，但我们一定要把这些正常现象和拒绝服务攻击区分开来。如果您的服务器突然变得拥挤不堪，甚至无法响应再多的请求时，您应当仔细检查一下这个资源匮乏的现象，确认在10000次点击里全都是合法用户进行的，还是由5000个合法用户和一个点击了5000次的攻击者进行的。

拒绝服务一般都是由过载导致的，而过载一般是因为请求到达了极限。

拒绝服务攻击的发展

由于我们防范手段的加强，拒绝服务攻击手法也在不断的发展。

Tribe Flood Network (tfn) 和tfn2k引入了一个新概念：分布式。这些程序可以使得分散在互连网各处的机器共同完成对一台主机攻击的操作，从而使主机看起来好象是遭到了不同位置的许多主机的攻击。这些分散的机器由几台主控制机操作进行多种类型的攻击，如UDP flood, SYN flood等。

操作系统和网络设备的缺陷在不断地被发现并被黑客所利用来进行恶意的攻击。如果我们清楚的认识到了这一点，我们应当使用下面的两步来尽量阻止网络攻击保护我们的网络：

A）尽可能的修正已经发现的问题和系统漏洞。

B）识别，跟踪或禁止这些令人讨厌的机器或网络对我们的访问。

我们先来讨论一下B），在B）中我们面临的主要问题是如何识别那些恶意攻击的主机，特别是使用拒绝服务攻击的机器。因为这些机器隐藏了他们自己的地址，而冒用被攻击者的地址。攻击者使用了数以千记的恶意伪造包来使我们的主机受到攻击。"tfn2k"的原理就象上面讲的这么简单，而他只不过又提供了一个形象的界面。假如您遭到了分布式的拒绝服务攻击，实在是很难处理。

解决此类问题的一些专业手段----包过滤及其他的路由设置

有一些简单的手法来防止拒绝服务式的攻击。最为常用的一种当然是时刻关注安全信息以期待最好的方法出现。管理员应当订阅安全信息报告，实时的关注所有安全问题的发展。：）

第二步是应用包过滤的技术，主要是过滤对外开放的端口。这些手段主要是防止假冒地址的攻击，使得外部机器无法假冒内部机器的地址来对内部机器发动攻击。

我们可以使用Cisco IOS来检查路由器的详细设置，当然，它也不仅限于Cisco的设备，但由于现在Cisco设备在网络中占有了越来越多的市场份额（83%），所以我们还是以它为例子，假如还有人有其他的例子，我们也非常高兴你能提出您的宝贵信息。

登陆到将要配置的路由器上，在配置访问控制列表之前先初始化一遍：

c3600(config)#access-list 100 permit ip 207.22.212.0 0.0.0.255 any

c3600(config)#access-list 100 deny ip any any

然后我们假设在路由器的S0口上进行ACL的设置，我们进入S0口，并进入配置状态：

c3600(config)#int ser 0

c3600(config-if)#ip access-group 100 out

通过显示access-list来确认访问权限已经生效：

c3600#sho access-lists 100

Extended IP access list 100

permit ip 207.22.212.0 0.0.0.255 any (5 matches)

deny ip any any (25202 matches)

对于应该使用向内的包过滤还是使用向外的包过滤一直存在着争论。RFC 2267建议在全球范围的互连网上使用向内过滤的机制，但是这样会带来很多的麻烦，在中等级别的路由器上使用访问控制列表不会带来太大的麻烦，但是已经满载的骨干路由器上会受到明显的威胁。

另一方面，ISP如果使用向外的包过滤措施会把过载的流量转移到一些不太忙的设备上。 ISP也不关心消费者是否在他们的边界路由器上使用这种技术。当然，这种过滤技术也并不是万无一失的，这依赖于管理人员采用的过滤机制。

我们经常会听到设备销售或集成商这样的推脱之词，他们总是说使用ACL会导致路由器和网络性能的下降。ACL确实会降低路由器的性能并加重CPU的负载，但这是微乎其微的。我们曾经在Cisco 2600 和3600系列路由器上作过实验：

以下是不使用和使用ACL时的对照表：

Test Speed w/o ACL (Mbps) w/ ACL (Mbps) w/o ACL (total time) w/ ACL (total time) % change

Cisco 2600 100Mbps -》 100 Mbps File transfers 36.17 Mbps 35.46 Mbps 88.5 90.2 2.50%

Cisco 3600 10Mbps -》 10Mbps File transfers 7.95 Mbps 8.0Mbps 397 395 0.30%

使用的路由器配置如下：

· Cisco 3640 (64MB RAM, R4700 processor, IOS v12.0.5T)

· Cisco 2600 (128MB RAM, MPC860 processor, IOS v12.0.5T)

由表我们可以看出，在使用ACL前后对路由器性能的影响并不是很大。

使用DNS来跟踪匿名攻击

也许大家仍旧保存着侥幸心理，认为这些互连网上给我们带来无数麻烦DoS漏洞或许随着路由器包过滤，网络协议升级到IPv6或者随时的远程响应等手段变得越来越不重要。但从一个具有责任感的网管的观点来看，我们的目标并不是仅仅阻止拒绝服务攻击，而是要追究到攻击的发起原因及操作者。

当网络中有人使用假冒了源地址的工具（如tfn2k）时，我们虽然没有现成的工具来确认它的合法性，但我们可以通过使用DNS来对其进行分析：

假如攻击者选定了目标www.technotronic.com，他必须首先发送一个DNS请求来解析这个域名，通常那些攻击工具工具会自己执行这一步，调用gethostbyname()函数或者相应的应用程序接口，也就是说，在攻击事件发生前的DNS请求会提供给我们一个相关列表，我们可以利用它来定位攻击者。

使用现成工具或者手工读取DNS请求日志，来读取DNS可疑的请求列表都是切实可行的，然而，它有三个主要的缺点：

l 攻击者一般会以本地的DNS为出发点来对地址进行解析查询，因此我们查到的DNS请求的发起者有可能不是攻击者本身，而是他所请求的本地DNS服务器。尽管这样，如果攻击者隐藏在一个拥有本地DNS的组织内，我们就可以把该组织作为查询的起点。

l 攻击者有可能已经知道攻击目标的IP地址，或者通过其他手段（host, ping）知道了目标的IP地址，亦或是攻击者在查询到IP地址后很长一段时间才开始攻击，这样我们就无法从DNS请求的时间段上来判断攻击者（或他们的本地服务器）。

l DNS对不同的域名都有一个却省的存活时间，因此攻击者可以使用存储在DNS缓存中的信息来解析域名。为了更好做出详细的解析记录，您可以把DNS却省的TTL时间缩小，但这样会导致DNS更多的去查询所以会加重网络带宽的使用。

在许多情况下，只要您拥有足够的磁盘空间，记录所有的DNS请求并不是一种有害的做法。在BIND8.2中做记录的话，可以在named.conf中假如下面的几行：

logging {

channel requestlog { file "dns.log"; };

category queries { requestlog; };

};

使用 ngrep来处理tfn2k 攻击

根据使用DNS来跟踪tfn2k驻留程序的原理，现在已经出现了称为ngrep的实用工具。经过修改的ngrep（参见附录）可以监听大约五种类型的tfn2k拒绝服务攻击(targa3, SYN flood, UDP flood, ICMP flood 和 smurf)，它还有一个循环使用的缓存用来记录DNS和ICMP请求。如果ngrep发觉有攻击行为的话，它会将其缓存中的内容打印出来并继续记录ICMP回应请求。假如攻击者通过ping目标主机的手段来铆定攻击目标的话，在攻击过程中或之后记录ICMP的回应请求是一种捕获粗心的攻击者的方法。由于攻击者还很可能使用其他的服务来核实其攻击的效果（例如web），所以对其他的标准服务也应当有尽量详细的日志记录。

还应当注意，ngrep采用的是监听网络的手段，因此，ngrep无法在交换式的环境中使用。但是经过修改的ngrep可以不必和你的DNS在同一个网段中，但是他必须位于一个可以监听到所有DNS请求的位置。经过修改的ngrep也不关心目标地址，您可以把它放置在DMZ网段，使它能够检查横贯该网络的tfn2k攻击。从理论上讲，它也可以很好的检测出对外的tfn2k攻击。

运行 ngrep, 您将看到：

[root@lughnasad ngrep]# ./ngrep

Ngrep with TFN detection modifications by wiretrip / www.wiretrip.net

Watching DNS server: 10.0.0.8

interface: eth0 (10.0