现在，假定我们按照如下方法使用访问控制列表：


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