介绍拒绝服务（DoS）攻击在上非常普遍。应付此类攻击的第一个步骤是辨别该攻击究竟属于何种类型。很多常见DoS攻击是基于占用大量带宽的数据包泛洪或者其它重复的数据包流。
我们可以通过将很多DoS攻击流中的数据包与 IOS软件的访问控制列表条目进行匹配，以隔离这些数据包。显而易见，这对过滤攻击非常有价值，并且能够帮助我们识别未知攻击，跟踪“欺骗”数据包流的真正来源。
某些时候，我们可将器的一些功能（如debug日志和IP记数）用于类似用途，尤其在遭遇新攻击或者非常规攻击的情况下。然而，随着Cisco IOS软件的最新版本的发布，访问控制列表和访问控制列表日志已经成为识别和追踪常见攻击的重要功能。
最常见的DoS攻击我们可能受到多种类型的DOS攻击。既使我们忽略那些利用软件错误使用较小的数据流量来关闭系统的攻击，事实上仍然是任何通过网络传送的IP数据包都可以用来实施泛洪DoS攻击。遭受攻击时，您必须时刻考虑到这种攻击可能是一种非常规的攻击。
虽然我们提出上述告警，然而您还应该记住一点：很多攻击是相似的。攻击者会选择利用常见的攻击方法，原因在于这些方法特别有效，并且难以跟踪，或者因为可用工具较多。很多DoS攻击者缺乏创建自己的工具的技术或动力，而会使用在上找到的程序；这些工具通常已经过期了或不流行了。
在撰写本文时（1999年7月），大部分向Cisco请求帮助的客户都遭受了"smurf"攻击。这种攻击的受害者分为两类：“最终目标”或“反射者”。攻击者将ICMP响应请求（"ping"）的激励数据发送到反射者子网的广播地址。这些数据包的源地址被伪装为最终目标的地址。反射者子网上的很多主机对攻击者发送的每个数据包作出了回应，从而使最终目标数据泛洪，并且消耗受害双方的带宽。
另外一种类似的攻击称为“fraggle”，它通过相同的方法来利用定向广播，但它采用的是UDP回应请求，来代替ICMP回应请求。Fraggle的扩散系数通常低于smurf，也没有smurf常用。
Smurf攻击通常会被察觉，因为网络链路将会超载。要获得有关这些攻击和防御措施的详细说明，请访问 .
SYN泛洪是另外一种常见攻击，该攻击使用TCP连接请求来泛洪目标机器。连接请求数据包的源地址和源TCP端口被打乱，目的是迫使目标主机为很多永无休止的连接维护 好状态信息。
SYN泛洪攻击通常会被察觉，因为目标主机（通常为HTTP和SMTP）将发生速度变得极慢、崩溃或者死机的现象。从目标主机返回的流量可能导致路由器发生故障；因为这种返回流量会流向被打乱的原数据包的源地址，它不具备“真正的”IP流量的位置属性，并可能使路由器缓存溢出。在Cisco路由器上，发生此问题的迹象通常是路由器的内存容量耗尽。
在Cisco接到的报告中，smurf和SYN泛洪攻击在泛洪DoS攻击中占据了绝大多数比例，因而迅速识别这两种攻击至关重要。幸运的是，我们可以使用Cisco访问控制列表轻而易举地识别上述两种攻击（以及一些“二级”攻击，例如ping泛洪）。
识别DoS的访问控制列表想象一台带有二个接口的路由器。ethernet 0连接到一个公司或小型ISP的内部局域网。Serial 0提供通过上一级ISP提供互联网连接。Serial 0上的输入数据包率被“固定”在整个链路带宽上，局域网上的主机运行缓慢，会发生崩溃和死机的现象或者表现出DoS攻击的其它迹象。路由器连接地点没有网络分析器，即使能够进行追踪，但工作人员却在读取分析器追踪方面缺乏经验或者根本没有经验。
现在，假定我们按照如下方法使用访问控制列表：
access-list 169 permit icmp any any echo
access-list 169 permit icmp any any echo-reply
access-list 169 permit udp any any eq echo
access-list 169 permit udp any eq echo any
access-list 169 permit tcp any any established
access-list 169 permit tcp any any
access-list 169 permit ip any any
interface serial 0
ip access-group 169 in
该访问控制列表根本没有过滤任何流量，所有条目均为许可。然而，由于它通过有效的方法对数据包进行了分类，因此该表可用于临时诊断三种类型的攻击：smurf、SYN泛洪和fraggle。
Smurf最终目标
如果发出show access-list命令，我们将看到与以下内容相似的输出：
Extended IP access list 169
permit icmp any any echo (2 matches)
permit icmp any any echo-reply (21374 matches)
permit udp any any eq echo
permit udp any eq echo any
permit tcp any any established (150 matches)
permit tcp any any (15 matches)
permit ip any any (45 matches)
显而易见，到达串行接口的大部分流量由ICMP响应答复数据包组成。这可能是smurf攻击的迹象，我们的站点是最终目标，而并非反射者。通过更改访问控制列表，我们能够轻易收集到有关攻击的更多信息，如以下信息：
interface serial 0
no ip access-group 169 in
no access-list 169
access-list 169 permit icmp any any echo
access-list 169 permit icmp any any echo-reply log-input
access-list 169 permit udp any any eq echo
access-list 169 permit udp any eq echo any
access-list 169 permit tcp any any established
access-list 169 permit tcp any any
access-list 169 permit ip any any
interface serial 0
ip access-group 169 in
我们在此处进行了更改，将log-input关键词添加到与可疑流量匹配的访问控制列表条目中（版本低于11.2的Cisco IOS 软件没有该关键词，我们可使用关键词“log”取代）。这样可使路由器记录与访问控制列表条目匹配信息。假定配置了logging buffered，我们可以通过使用show log命令看到产生的结果信息（由于速率限制，信息收集可能需要一段时间）。该信息可能类似于以下信息：
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.72 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.154 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.15 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.47 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.35 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.59 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.82 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.56 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.84 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.47 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.35 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.15 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.33 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
我们可以发现，响应答复数据包的源地址集中有几个地址前缀：192.168.212.0/24、192.168.45.0/24和172.16.132.0/24（显而易见，192.168.x.x and 172.16.x.x网络中的专用地址不在互联网上，这是一个实验室例证）。这正是smurf攻击的特征，源地址是smurf反射者的地址。我们可在相应的互联网“whois”数据库中查询这些地址块的主人，从而找到这些网络的管理者，并请求他们协助对付攻击。
应该记住，在smurf攻击中，这些反射者同是受害者，并非攻击者，这一点非常重要。在任何DoS泛洪中，很少有攻击者在IP数据包上使用自己的源地址。在任何有效的smurf攻击中，他们都不可能这样做。应该假定泛洪数据包的所有地址都是完全伪装的，或者就是某种类型的受害者。对smurf攻击的最终目标而言，最有效的方法是与反射者主人联系，要求他们重新配置其网络，以停止攻击或者要求他们帮助跟踪激发数据流。
由于smurf攻击对最终目标的损害通常是互联网的进入链路超载，因此，除与反射者联系之外，我们通常没有其它的应对措施；截止数据包到达目标控制下的任何机器时，大部分损害已经发生。
有一种权宜之计，就是要求上一级网络供应商过滤所有ICMP响应答复，或者过滤来自特定反射者的ICMP响应答复。这种类型的过滤器不能永久使用。即使对临时过滤器来说，也只应该过滤响应答复，而并非过滤所有ICMP数据包。另外还有一种可能的方法，让上一级供应商使用服务质量和速率限制功能，以限制响应答复的可用带宽，可以无限期地保留合理的带宽限制。上述两种方法都要求上一级供应商的设备拥有必要的功能，某些时候他们可能没有足够的功能。
[1]
--------------------next---------------------