tracert命令为何追踪不到路由？
tracert命令为何追踪不到路由？
09-02-16 &
arp -a看看有没有什么乱七八糟的东西。应该没什么吧
请登录后再发表评论!
arp -a看看有没有什么乱七八糟的东西。应该没什么吧
请登录后再发表评论!
能PING通  你的上级的路由地址么ping 不能 肯定中ARP欺骗啦
请登录后再发表评论!
先arp -d然后再arp -a就能看到你想看的东西了
请登录后再发表评论!|||||亿愿路由追踪分析器 v1.15.331 绿色版
您的位置：& > &亿愿路由追踪分析器 v1.15.331 绿色版
亿愿路由追踪分析器 v1.15.331 绿色版路由追踪软件
网友评分：
软件大小：7.36MB
软件语言：简体中文
软件类型：国产软件
软件类别：IP 工 具
更新时间：
软件授权：免费版
官方网站：
运行环境：XP/Win7/Win8/Vista
7.14MB/简体中文/5
3.18MB/简体中文/7
191KB/简体中文/4.7
505KB/简体中文/6.7
76.8KB/简体中文/8
亿愿路由追踪分析器（亿愿路由追踪工具）是一款绿色免费的由亿愿软件官方制作的提供给网管的路由追踪分析工具。软件功能强大，集成了PING和Tracert的功能，同时查询到每一个IP对应的真实地址；只要输入IP或者域名，就可以清楚显示跟踪路由的详细地址清单；不需要再进入到DOS窗口，操作非常方便。
tracert命令及用法
Tracert（跟踪路由）是路由跟踪实用程序，用于确定 IP 数据报访问目标所采取的路径。Tracert 命令用 IP 生存时间 (TTL) 字段和 ICMP 错误消息来确定从一个主机到网络上其他主机的路由。
Tracert 工作原理
通过向目标发送不同 IP 生存时间 (TTL) 值的&Internet 控制消息协议 (ICMP)&回应数据包，Tracert 诊断程序确定到目标所采取的路由。要求路径上的每个路由器在转发数据包之前至少将数据包上的 TTL 递减 1。数据包上的 TTL 减为 0 时，路由器应该将&ICMP 已超时&的消息发回源系统。
Tracert 先发送 TTL 为 1 的回应数据包，并在随后的每次发送过程将 TTL 递增 1，直到目标响应或 TTL 达到最大值，从而确定路由。通过检查中间路由器发回的&ICMP 已超时&的消息确定路由。某些路由器不经询问直接丢弃 TTL 过期的数据包，这在 Tracert 实用程序中看不到。
Tracert 命令按顺序打印出返回&ICMP 已超时&消息的路径中的近端路由器接口列表。如果使用 -d 选项，则 Tracert 实用程序不在每个 IP 地址上查询 DNS。
在下例中，数据包必须通过两个路由器（10.0.0.1 和 192.168.0.1）才能到达主机 172.16.0.99。主机的默认网关是 10.0.0.1，192.168.0.0 网络上的路由器的 IP 地址是 192.168.0.1。
C:&tracert 172.16.0.99 -d
Tracing route to 172.16.0.99 over a maximum of 30 hops
1 2s 3s 2s 10,0.0,1
2 75 ms 83 ms 88 ms 192.168.0.1
3 73 ms 79 ms 93 ms 172.16.0.99
Trace complete.
用 tracert 解决问题
可以使用 tracert 命令确定数据包在网络上的停止位置。下例中，默认网关确定 192.168.10.99 主机没有有效路径。这可能是路由器配置的问题，或者是 192.168.10.0 网络不存在（错误的 IP 地址）。
C:&tracert 192.168.10.99
Tracing route to 192.168.10.99 over a maximum of 30 hops
1 10.0.0.1 reports:Destination net unreachable.
Trace complete.
Tracert 实用程序对于解决大网络问题非常有用，此时可以采取几条路径到达同一个点。
Tracert 命令行选项
Tracert 命令支持多种选项，如下表所示。
tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name
-d指定不将 IP 地址解析到主机名称。
-h maximum_hops指定跃点数以跟踪到称为 target_name 的主机的路由。
-j host-list指定 Tracert 实用程序数据包所采用路径中的路由器接口列表。
-w timeout等待 timeout 为每次回复所指定的毫秒数。
target_name目标主机的名称或 IP 地址。
软件无法下载或下载后无法使用，请点击报错，谢谢！
请描述您所遇到的错误，我们将尽快予以修正，谢谢！
*必填项，请输入内容
本类下载排行用 Cisco 路由器识别与跟踪数据包风暴
[an error occurred while processing this directive]
新闻与刊物
商业解决方案
网络解决方案
服务与支持
思科网络技术学院
培训、活动与会议
合作伙伴与代理商
中国：简体中文
TAC中文文档
原文件的链接(英语)
此文档是由人工智能自动翻译系统翻译的,请随时参考。
用 Cisco 路由器识别与跟踪数据包风暴
     
     
     
     
     
     
     
     
     
     
     
     
     
拒绝服务（DoS）攻击在互联网上非常普遍。 应付此类攻击的第一个步骤是辨别该攻击究竟属于何种类型。 很多常见DoS攻击是基于占用大量带宽的数据包泛洪或者其它重复的数据包流。
信息包在许多DoS攻击流可以通过他们查出与Cisco IOS相符？ 软件访问列表条目。 显而易见，这对过滤攻击非常有价值，并且能够帮助我们识别未知攻击，跟踪“欺骗”数据包流的真正来源。
某些时候，我们可将Cisco路由器的一些功能（如debug日志和IP记数）用于类似用途，尤其在遭遇新攻击或者非常规攻击的情况下。 然而，随着Cisco IOS软件的最新版本的发布，访问控制列表和访问控制列表日志已经成为识别和追踪常见攻击的重要功能。
本文档没有任何特定的前提条件。
本文不限于特定的软硬件版本。
有关文件规则的更多信息请参见“ Cisco技术提示规则”。
我们可能受到多种类型的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泛洪）。
想象一台带有二个接口的路由器。 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。
如果发出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
这里更改是日志输入关键字被添加到匹配不可信数据流的访问列表条目。 (Cisco IOS软件早于版本11.2缺乏此关键字，并且我们会使用关键字“日志”。)这将导致路由器日志信息关于匹配列表项的信息包。 假定配置了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和172.16.x.x网络不会在互联网; 这的Smurf攻击是非常典型的这是实验室例证。)，并且源地址是Smurf反射器的地址。 我们可在相应的互联网“whois”数据库中查询这些地址块的主人，从而找到这些网络的管理者，并请求他们协助对付攻击。
应该记住，在smurf攻击中，这些反射者同是受害者，并非攻击者，这一点非常重要。 在任何DoS泛洪中，很少有攻击者在IP数据包上使用自己的源地址。在任何有效的smurf攻击中，他们都不可能这样做。 应该假定泛洪数据包的所有地址都是完全伪装的，或者就是某种类型的受害者。 对smurf攻击的最终目标而言，最有效的方法是与反射者主人联系，要求他们重新配置其网络，以停止攻击或者要求他们帮助跟踪激发数据流。
由于对Smurf攻击的最后目标的损伤通过超载流入的连接通常造成从互联网，经常没有除之外与反射器联系的无响应; 当信息包到达在所有机器在目标的控制之下的时候，大多数损害已经造成了。
有一种权宜之计，就是要求上一级网络供应商过滤所有ICMP响应答复，或者过滤来自特定反射者的ICMP响应答复。 这种类型的过滤器不能永久使用。 即使对临时过滤器来说，也只应该过滤响应答复，而并非过滤所有ICMP数据包。 另一种可能性是有上行提供商使用服务质量和速率限制功能限制带宽可用对ECHO回复; 合理的带宽限制可以配置到位确定。 上述两种方法都要求上一级供应商的设备拥有必要的功能，某些时候他们可能没有足够的功能。
如果入流量由响应请求组成，而不是由响应答复组成（换句话说，如果第一个访问控制列表条目计算的匹配数量远高于合理预测的数量，而第二个条目没有发生这种情况），我们应该怀疑，我们的网络在smurf攻击中被用作反射者，或者遭受了一次ping泛洪攻击。 在这两种情况下，如果攻击成功，我们的串行线的输出和输入端将被淹没。 实际上，由于扩散因素的原因，输出端的超载比输入端更加严重。
我们可使用如下方法区别smurf攻击和简单的ping泛洪：
Smurf激励数据包会发到定向的广播地址，而并非单播地址，而普通ping泛洪通常使用单播地址。 我们在适当的访问列表条目能使用日志输入关键字看到地址，正如前面的部分所描述。
如果您被用作smurf反射者，则系统的以太网端的show interface命令会显示数量不成比例的输出广播，show ip traffic命令通常还会显示一些数量不成比例的被发送广播。 标准的ping泛洪不会增加后台广播流量。
如果您被用作smurf反射者，发往互联网的出流量将多于来自互联网的入流量。 一般而言，串行接口上的输出数据包多于输入数据包。 即使激励流完全占用输入接口，响应流也将大于激励流，数据包丢弃将被计数。
与smurf攻击的最终目标相比，smurf反射者的选择范围更广。 如果反射者要终止攻击，通常只需正确使用no ip directed-broadcast命令（或同等的non-IOS命令）。 这些命令在每种配置属于，即使没有主动攻击; 欲知关于防止您的Cisco设备的更多信息用于Smurf攻击，请参阅。 关于更多概要关于一般来说， Smurf攻击和对于关于保护的非Cisco设备的信息，请参阅。
与最终目标相比，smurf反射者与攻击者的距离更近一步，因此它在跟踪攻击方面处于更加有利的位置。 如果您要跟踪攻击，则需要与有关ISP进行合作。完成跟踪后，如果要采取行动，您还需要与相关执法机构进行合作。 如果要跟踪攻击，应尽早要求执法机构介入。 请参阅跟踪部分 以获得有关跟踪泛洪攻击的技术信息。
Fraggle攻击与smurf攻击类似，不同之处是它使用UDP响应请求作为激励流，而没有使用ICMP响应请求。 在访问控制列表地第三第四行定义了识别fraggle攻击。 受害者的应对措施也相同，不同之处在于：在大多数网络中，UDP回应业务的重要性低于ICMP回应，因此我们可以完全禁用它而不会带来较多地负面影响。
我们的访问控制列表的第五行和第六行分别是：
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泛洪中，SYN的数量通常超出非SYN TCP数据包若干倍。
如果没有遭受攻击，唯一能够产生此种现象的条件是：真正的连接请求大量超载。 一般来说，这种超载现象不会出人意料地发生，也不会象真正的SYN泛洪那样发送尽可能多的SYN数据包。 并且， SYN溢出完全地经常包含信息包和无效的源地址一起; 使用日志输入关键字，发现是可能的连接请求是否来自这样地址。
有一种攻击通常被称为"进程表攻击"，它与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%时，或在高速接口上使用访问控制列表时，应小心谨慎。
DoS数据包的源地址通常被设置为与攻击者毫无关联的地址，因而该地址对确认攻击者没有任何作用。 识别攻击来源的唯一可靠方法是通过网络逐跳进行跟踪。 这一过程包括重新配置路由器，检查日志信息，请求从攻击者到受害者的路径上的所有网络运营商予以合作。 要确保成功合作，通常需要执法机构介入，如果要对攻击者采取措施，也必须有执法机构介入。
DoS泛洪的跟踪过程相对比较简单。 从一台承载泛洪流量的已知路由器（称为A）开始，我们可以识别A接收流量的来源路由器（称为B）。 然后登录B，找到B接受流量的来源路由器（称为C）。 按照此过程继续查找，直至找到最终来源。
这种方法牵涉到下述几个问题：
"最终来源"实际上可能是攻击者掌握权限的一台计算机，其拥有者和操作者可能是另外一位受害者。 在此情况下，跟踪DoS泛洪只是第一个步骤。
攻击者知道他们可以被跟踪和只有限时间内通常继续他们的攻击; 可能不有足够时间实际上跟踪溢出。
攻击可能来自多个来源，尤其在攻击者相对较为老练的情况下。 应尽可能多地确认来源，这一点非常重要。
通信问题减缓了跟踪过程。 涉及到的一个或多个网络运营商可能没有精通技术的人员，这种情况经常发生。
即使我们找到了攻击者，但法律和政治方面的原因却使我们很难对其采取行动。
事实上，大部分尝试跟踪DoS攻击的努力都以失败告终。 由于这个原因，很多网络运营商甚至可能拒绝尝试跟踪一个攻击，除非他们承受到某些压力。 其它很多运营商只跟踪“严重”攻击，并且他们对“严重”的定义各不相同。 有些运营商只有在执法机构介入时才会协助进行跟踪。
如果您要跟踪通过一台Cisco路由器来跟踪一个攻击，最有效的方法就是建立与攻击数据流匹配的访问控制列表条目，加上 log-input关键词，然后将访问控制列表提取出应用到接口上（攻击流量通过该接口向最终目标传送）。 访问控制列表产生的日志条目将识别流量通过的路由器接口，如果接口是多点连接，它将提供它所接收流量的设备的第2层地址。 第2层地址能够用于确认链中的下一台路由器，如通过使用show ip arp mac-address命令确认。
要跟踪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激发数据流，可使用以下访问控制列表：
access-list 169 permit icmp any any echo log-input
access-list 169 permit ip any any
注意，第一个条目并非只限于发送到反射者地址的数据包。 原因是大多数smurf攻击会使用多个反射者网络。 如果您没有与最终目标保持联系，您可能无法知道所有的反射者地址。 作为您的跟踪获得离攻击较近的来源，您可以开始发现ECHO请求去越来越多的目的地; 这是好的迹象。
然而，如果您处理大量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
您可以通过该访问控制列表清除您的日志中的“噪音”数据包，当您逐渐接近攻击者时，您还有很大机会发现其它的激励流。
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命令将为您提供一个或两个调试输出的数据包。
网络专业人士连接是网络专业人士的一个论坛，它共享网络解决方案、产品和技术的相关问题、建议和信息。 功能链路是此技术可用的一些最近的会话。
Net Pro论坛-专题对话为安全
安全： 入侵检测[Systems]
安全： AAA
安全： 常规
安全： 防火墙
声明：此文档是由为思科 TAC 网页内容翻译所开发的英汉机器自动翻译系统翻译的。在有疑问或作出重要的技术支持决策时,请随时参考英文原文。Updated:
Sep 14, 2004Document ID: 13609
[an error occurred while processing this directive]
[an error occurred while processing this directive]