介绍
拒绝服务（DoS）攻击在互联网上非常普遍。应付此类攻击的第一个步骤是辨别该攻击究竟属于何种类型。很多常见DoS攻击是基于占用大量带宽的数据包泛洪或者其它重复的数据包流。

我们可以通过将很多DoS攻击流中的数据包与Cisco IOS软件的访问控制列表条目进行匹配，以隔离这些数据包。显而易见，这对过滤攻击非常有价值，并且能够帮助我们识别未知攻击，跟踪“欺骗”数据包流的真正来源。

某些时候，我们可将Cisco路由器的一些功能（如debug日志和IP记数）用于类似用途，尤其在遭遇新攻击或者非常规攻击的情况下。然而，随着Cisco IOS软件的最新版本的发布，访问控制列表和访问控制列表日志已经成为识别和追踪常见攻击的重要功能。

最常见的DoS攻击
我们可能受到多种类型的DOS攻击。既使我们忽略那些利用软件错误使用较小的数据流量来关闭系统的攻击，事实上仍然是任何通过网络传送的IP数据包都可以用来实施泛洪DoS攻击。遭受攻击时，您必须时刻考虑到这种攻击可能是一种非常规的攻击。

虽然我们提出上述告警，然而您还应该记住一点：很多攻击是相似的。攻击者会选择利用常见的攻击方法，原因在于这些方法特别有效，并且难以跟踪，或者因为可用工具较多。很多DoS攻击者缺乏创建自己的工具的技术或动力，而会使用在互联网上找到的程序；这些工具通常已经过期了或不流行了。

在撰写本文时（1999年7月），大部分向Cisco请求帮助的客户都遭受了"smurf"攻击。这种攻击的受害者分为两类：“最终目标”或“反射者”。攻击者将ICMP响应请求（"ping"）的激励数据发送到反射者子网的广播地址。这些数据包的源地址被伪装为最终目标的地址。反射者子网上的很多主机对攻击者发送的每个数据包作出了回应，从而使最终目标数据泛洪，并且消耗受害双方的带宽。

另外一种类似的攻击称为“fraggle”，它通过相同的方法来利用定向广播，但它采用的是UDP回应请求，来代替ICMP回应请求。Fraggle的扩散系数通常低于smurf，也没有smurf常用。

Smurf攻击通常会被察觉，因为网络链路将会超载。要获得有关这些攻击和防御措施的详细说明，请访问 http://users.quadrunner.com/chuegen/smurf.cgi.

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数据包。另外还有一种可能的方法，让上一级供应商使用服务质量和速率限制功能，以限制响应答复的可用带宽，可以无限期地保留合理的带宽限制。上述两种方法都要求上一级供应商的设备拥有必要的功能，某些时候他们可能没有足够的功能。

Smurf反射者
如果入流量由响应请求组成，而不是由响应答复组成（换句话说，如果第一个访问控制列表条目计算的匹配数量远高于合理预测的数量，而第二个条目没有发生这种情况），我们应该怀疑，我们的网络在smurf攻击中被用作反射者，或者遭受了一次ping泛洪攻击。在这两种情况下，如果攻击成功，我们的串行线的输出和输入端将被淹没。实际上，由于扩散因素的原因，输出端的超载比输入端更加严重。

我们可使用如下方法区别smurf攻击和简单的ping泛洪：



Smurf激励数据包会发到定向的广播地址，而并非单播地址，而普通ping泛洪通常使用单播地址。正如上文所述，我们可以在相应的访问控制列表条目上使用log-input关键词看到这些地址。

如果您被用作smurf反射者，则系统的以太网端的show interface命令会显示数量不成比例的输出广播，show ip traffic命令通常还会显示一些数量不成比例的被发送广播。标准的ping泛洪不会增加后台广播流量。

如果您被用作smurf反射者，发往互联网的出流量将多于来自互联网的入流量。一般而言，串行接口上的输出数据包多于输入数据包。即使激励流完全占用输入接口，响应流也将大于激励流，数据包丢弃将被计数。
与smurf攻击的最终目标相比，smurf反射者的选择范围更广。如果反射者要终止攻击，通常只需正确使用no ip directed-broadcast命令（或同等的non-IOS命令）。即使没有实时攻击，这些命令也可以使用在每个配置中。要获得有关防止您的Cisco设备在smurf攻击中被利用的更多信息，请参阅 提高Cisco路由器的安全性。要获得有关smurf攻击和保护非Cisco设备的基本信息，请访问 http://users.quadrunner.com/chuegen/smurf.cgi.

与最终目标相比，smurf反射者与攻击者的距离更近一步，因此它在跟踪攻击方面处于更加有利的位置。如果您要跟踪攻击，则需要与有关ISP进行合作。完成跟踪后，如果要采取行动，您还需要与相关执法机构进行合作。如果要跟踪攻击，应尽早要求执法机构介入。请参阅跟踪部分 以获得有关跟踪泛洪攻击的技术信息。

Fraggle
Fraggle攻击与smurf攻击类似，不同之处是它使用UDP响应请求作为激励流，而没有使用ICMP响应请求。在访问控制列表地第三第四行定义了识别fraggle攻击。受害者的应对措施也相同，不同之处在于：在大多数网络中，UDP回应业务的重要性低于ICMP回应，因此我们可以完全禁用它而不会带来较多地负面影响。

SYN泛洪
我们的访问控制列表的第五行和第六行分别是：


access-list 169 permit tcp any any established
access-list 169 permit tcp any any

第一行将任何TCP数据包与ACK位设置进行匹配。真正能够帮助我们识别攻击的是它能匹配任何不是TCP SYN的数据包。因此，第二行只需匹配非TCP SYN数据包。我们可以很容易地通过这些访问控制列表条目的计数器识别SYN泛洪；在正常流量中，非SYN TCP数据包的数量至少要比SYN多一倍，通常能够达到SYN的4或5倍。在SYN泛洪中，SYN的数量通常超出非SYN TCP数据包若干倍。

如果没有遭受攻击，唯一能够产生此种现象的条件是：真正的连接请求大量超载。一般来说，这种超载现象不会出人意料地发生，也不会象真正的SYN泛洪那样发送尽可能多的SYN数据包。此外，SYN泛洪通常包括地址完全无效的数据包，使用log-input关键词能够查看连接请求是否来自此类地址。

有一种攻击通常被称为"进程表攻击"，它与SYN泛洪有一些相似。在进程表攻击中，TCP连接实际上已经结束，在没有更多的协议流量时允许超时连接，而不会产生更多协议流量，而在SYN泛洪中，它们只会发送最初的连接请求。由于流程表攻击要求完成TCP初次交接（往往窃取通道），因此它通常必须通过攻击者真正进入的机器的IP地址来发动。因此，使用数据包日志能够轻易地将它和SYN泛洪区别开来。流程表中的所有SYN来自一个或多个地址，或者顶多来自一个或几个子网。

不幸的是，SYN泛洪的受害者能够采取的应对措施非常有限。遭受攻击的系统通常承担重要业务，攻击者也通常能够达到阻塞该系统入口的目的。很多路由器和防火墙产品，包括Cisco的产品，具备一些能够减轻SYN泛洪的影响的功能，但这些功能的有效性取决于环境。要获得更多信息，请参阅“Cisco IOS 防火墙功能设置”文档（Cisco IOS TCP拦截功能的文档）和 提高Cisco路由器的安全性。

我们也可能跟踪SYN泛洪，但跟踪过程要求攻击者和受害者之间的路径上的每一个ISP的协助。如果您决心尝试追踪SYN泛洪，应尽早与执法部门联系，并与您自己的上一级服务供应商合作。请参阅本文件的跟踪部分，以获得使用Cisco路由器进行跟踪的详细信息。

其它攻击
如果您确信自己受到攻击，并且能够通过IP源地址和目的地址、协议号和端口号来识别该攻击，那么您可使用访问控制列表来验证您的假设。您可以创建一个与怀疑流量匹配的访问控制列表条目，将其用于相应接口，观察匹配计数器或记录流量。

日志和计数器告警
请记住，访问控制列表条目上的计数器会计算所有与该条目的匹配。如果您在两个接口上都使用访问控制列表，那么您看到的计数将是总计数。

访问控制列表日志不会显示与条目匹配的每个数据包。日志受到速率限制，以防止CPU超载。日志显示的是适当的有代表性的例子，而并非完整的数据包追踪。请记住，有一些数据包是您无法看见的。

在一些软件版本中，访问控制列表日志只能在某些交换模式下工作。如果访问控制列表条目对大量匹配进行计数，但却没有进行记录，应尝试清除路由器缓存，以迫使数据包按照过程进行交换。在负载很高的多接口路由器上进行上述操作时，我们应该谨慎，大量数据流可能在重建缓存时被丢弃。在可能的情况下，应使用CEF。

访问控制列表和日志会影响性能，但影响不会很大。当路由器运行的CPU负载达到80%时，或在高速接口上使用访问控制列表时，应小心谨慎。