介绍拒绝服务（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.
更多的请看：http://www.QQread.com/windows/2003/index.Html
访问控制列表和日志会影响性能，但影响不会很大。当路由器运行的CPU负载达到80%时，或在高速接口上使用访问控制列表时，应小心谨慎。
跟踪
DoS数据包的源地址通常被设置为与攻击者毫无关联的地址，因而该地址对确认攻击者没有任何作用。识别攻击来源的唯一可靠方法是通过网络逐跳进行跟踪。这一过程包括重新配置路由器，检查日志信息，请求从攻击者到受害者的路径上的所有网络运营商予以合作。要确保成功合作，通常需要执法机构介入，假如要对攻击者采取措施，也必须有执法机构介入。
DoS泛洪的跟踪过程相对比较简单。从一台承载泛洪流量的已知路由器（称为A）开始，我们可以识别A接收流量的来源路由器（称为B）。然后登录B，找到B接受流量的来源路由器（称为C）。按照此过程继续查找，直至找到最终来源。
这种方法牵涉到下述几个问题：
"最终来源"实际上可能是攻击者把握权限的一台计算机，其拥有者和操作者可能是另外一位受害者。在此情况下，跟踪DoS泛洪只是第一个步骤。
攻击者知道他们可能被跟踪，因此他们的攻击的持续时间较短，我们可能没有足够的时间来跟踪泛洪。
攻击可能来自多个来源，尤其在攻击者相对较为老练的情况下。应尽可能多地确认来源，这一点非常重要。
通信问题减缓了跟踪过程。涉及到的一个或多个网络运营商可能没有精通技术的人员，这种情况经常发生。
即使我们找到了攻击者，但法律和政治方面的原因却使我们很难对其采取行动。
事实上，大部分尝试跟踪DoS攻击的努力都以失败告终。由于这个原因，很多网络运营商甚至可能拒绝尝试跟踪一个攻击，除非他们承受到某些压力。其它很多运营商只跟踪“严重”攻击，并且他们对“严重”的定义各不相同。有些运营商只有在执法机构介入时才会协助进行跟踪。
使用"log-input"进行跟踪
假如您要跟踪通过一台Cisco路由器来跟踪一个攻击，最有效的方法就是建立与攻击数据流匹配的访问控制列表条目，加上 log-input要害词，然后将访问控制列表提取出应用到接口上（攻击流量通过该接口向最终目标传送）。访问控制列表产生的日志条目将识别流量通过的路由器接口，假如接口是多点连接，它将提供它所接收流量的设备的第2层地址。第2层地址能够用于确认链中的下一台路由器，如通过使用show ip arp mac-address命令确认。
SYN泛洪
要跟踪SYN泛洪，您可以建立与以下类似的访问控制列表：
access-list 169 permit tcp any any established
access-list 169 permit tcp any host victim-host log-input
access-list 169 permit ip any any
该数据表将记录所有到目标主机的SYN数据包，包括非法SYN。要确认通往攻击者的最可能的真实路径，应仔细审查日志条目。通常来说，匹配数据包数量最多的来源就是泛洪来源。请记住，源IP地址本身并没有任何意义；您寻找的是源接口和源MAC地址。在某些时候，我们也许能够区分非法数据包和泛洪数据包，因为泛洪数据包可能含有无效的源地址，任何源地址无效的数据包很有可能是泛洪数据的一部分。
请记住，泛洪可能有多个来源，尽管这种情况与SYN泛洪相比比较罕见。
Smurf激励
要跟踪smurf激发数据流，可使用以下访问控制列表：
access-list 169 permit icmp any any echo log-input
access-list 169 permit ip any any
注重，第一个条目并非只限于发送到反射者地址的数据包。原因是大多数smurf攻击会使用多个反射者网络。假如您没有与最终目标保持联系，您可能无法知道所有的反射者地址。当您的跟踪更加接近攻击来源时，您可能开始发现，响应请求的目的地越来越多；这是一个好现象。
然而，假如您处理大量ICMP流量，可能会产生过多日志信息，使您难以阅读。假如发生此种情况，您可以将目的地的地址限定为已知被使用的反射者之一。另外一种有效策略是使用一个条目，利用255.255.255.0的子网掩码在互联网上非常普遍这一事实。鉴于攻击者寻找smurf反射者的方法，实际用于smurf攻击的反射者地址更可能和这个掩码匹配。以.0和.255结尾的主机地址在互联网上非常罕见，因而您可为smurf激励流建立相对比较非凡的识别符。
access-list 169 permit icmp any host known-reflector echo log-input
access-list 169 permit icmp any 0.0.0.255 255.255.255.0 echo log-input
access-list 169 permit icmp any 0.0.0.0 255.255.255.0 echo log-input
access-list 169 permit ip any any
您可以通过该访问控制列表清除您的日志中的“噪音”数据包，当您逐渐接近攻击者时，您还有很大机会发现其它的激励流。
不使用log-input进行跟踪
Cisco IOS 软件11.2版和更高版本,以及一些专为服务供给商市场开发的基于11.1的软件都支持log-input要害词。旧版本的软件不支持该要害词。假如您使用的路由器运行的是较旧的版本，您有三个可行的选择：
建立访问控制列表，不进行记录，但条目必须匹配可疑流量。依次在每个接口的输入端采用访问控制列表，观察计数器。寻找匹配率高的接口。这种方法的运行开销非常低，利于确认源接口。其最大的缺陷是无法提供链路层的源地址，因此它最适用于点到点线路。
使用log（而不是log-input）要害词创建访问控制列表条目。再次将访问控制列表应用到每个接口的进入端上。这种方法无法提供源MAC地址，但可用于查看IP数据，例如验证数据包流确实是攻击数据的一部分。对系统性能的影响的程度为中等或上等，新软件的性能强于旧软件。
使用debug ip packet detail来收集有关数据包的信息。这种方法可提供MAC地址，但对性能却产生了严重的影响。使用该方法易于出错，可能导致路由器无法使用。假如您使用该方法，应确保路由器以快速、自主或优化的方式交换攻击流量。使用访问控制列表，将调试限定在您真正需要的信息的范围内。将调试信息记录在本地日志缓冲区，但要关闭log到Telnet会话和控制台的调试信息的记录。假如可能，应安排人员守候路由器，确保必要时更换路由器电源。
请记住，debug ip packet无法显示有关快速交换数据包的信息，要获取这些信息，您必须使用clear ip cache命令。每个clear命令将为您提供一个或两个调试输出的数据包。
新闻热点
疑难解答
