HP 交换机发送多播 ping 请求

HP 交换机发送多播 ping 请求

我不是我们正常的网络人员...我刚刚被征召来帮助解决这个问题,所以请耐心等待。

我们有一个相当大的网络(约 4,000 台设备?),主要由 HP Procurve 设备组成。在过去的两周里,我们时不时会遇到一些严重的广播风暴,这些风暴几乎会破坏所有设备。我设置了 Wireshark 来执行 3MB 转储,今天早上我捕获了一些此类风暴。

有数千个 ping 请求。它们似乎来自我们的交换机和 AP 的 MAC 地址,并发送到 IPv4 多播 MAC。源 IP 地址确实不是与交换机和 AP 的 IP 地址相匹配……它们是分配给网络上的几个客户端的 IP 地址。目标 IP 地址始终是网关的 IP 地址。

我对此的看法是,这些 Procurve 设备上的固件要么被破解了,要么出了问题……或者有人在伪造地址并造成这种混乱。这两种情况似乎都不太可能,所以我想问您是否还有其他需要考虑的事情。

另外,我们的网络没有划分子网。(是的,我知道,我知道……不幸的是,这不是我的决定。)一切都是平坦的。

感谢您的时间。

编辑:以下是我捕获的两个连续数据包。我发布了完整的 Wireshark 摘要。抱歉,它有点混乱,但它更好地解释了我看到的内容。

No.     Time        Source                Destination           Protocol Info
  16885 2.094869    1.2.41.194        1.2.32.250        ICMP     Echo (ping) request

Frame 16885 (98 bytes on wire, 98 bytes captured)
    Arrival Time: Aug 31, 2010 07:59:11.185552000
    [Time delta from previous captured frame: 0.000123000 seconds]
    [Time delta from previous displayed frame: 0.000123000 seconds]
    [Time since reference or first frame: 2.094869000 seconds]
    Frame Number: 16885
    Frame Length: 98 bytes
    Capture Length: 98 bytes
    [Frame is marked: True]
    [Protocols in frame: eth:ip:icmp:data]
    [Coloring Rule Name: ICMP]
    [Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: Procurve_44:0f:26 (00:1f:fe:44:0f:26), Dst: IPv4mcast_62:20:fa (01:00:5e:62:20:fa)
    Destination: IPv4mcast_62:20:fa (01:00:5e:62:20:fa)
        Address: IPv4mcast_62:20:fa (01:00:5e:62:20:fa)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Procurve_44:0f:26 (00:1f:fe:44:0f:26)
        Address: Procurve_44:0f:26 (00:1f:fe:44:0f:26)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 1.2.41.194 (1.2.41.194), Dst: 1.2.32.250 (1.2.32.250)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 84
    Identification: 0x7718 (30488)
    Flags: 0x00
        0.. = Reserved bit: Not Set
        .0. = Don't fragment: Not Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 2
        [Expert Info (Note/Sequence): "Time To Live" only 2]
            [Message: "Time To Live" only 2]
            [Severity level: Note]
            [Group: Sequence]
    Protocol: ICMP (0x01)
    Header checksum: 0xd710 [correct]
        [Good: True]
        [Bad : False]
    Source: 1.2.41.194 (1.2.41.194)
    Destination: 1.2.32.250 (1.2.32.250)
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0 ()
    Checksum: 0xf112 [correct]
    Identifier: 0xdffd
    Sequence number: 0 (0x0000)
    Data (56 bytes)

0000  f8 17 44 fa 62 8d 00 00 80 11 42 da 8f e2 27 66   ..D.b.....B...'f
0010  8f e2 4e 0d 00 89 00 89 00 3a 2d df 00 00 00 00   ..N......:-.....
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030  00 00 00 00 00 00 00 00                           ........
        Data: F81744FA628D0000801142DA8FE227668FE24E0D00890089...
        [Length: 56]

No.     Time        Source                Destination           Protocol Info
  16886 2.094991    1.2.44.101        1.2.32.250        ICMP     Echo (ping) request

Frame 16886 (98 bytes on wire, 98 bytes captured)
    Arrival Time: Aug 31, 2010 07:59:11.185674000
    [Time delta from previous captured frame: 0.000122000 seconds]
    [Time delta from previous displayed frame: 0.000122000 seconds]
    [Time since reference or first frame: 2.094991000 seconds]
    Frame Number: 16886
    Frame Length: 98 bytes
    Capture Length: 98 bytes
    [Frame is marked: True]
    [Protocols in frame: eth:ip:icmp:data]
    [Coloring Rule Name: ICMP]
    [Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: HewlettP_05:5e:70 (00:17:a4:05:5e:70), Dst: IPv4mcast_62:20:fa (01:00:5e:62:20:fa)
    Destination: IPv4mcast_62:20:fa (01:00:5e:62:20:fa)
        Address: IPv4mcast_62:20:fa (01:00:5e:62:20:fa)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: HewlettP_05:5e:70 (00:17:a4:05:5e:70)
        Address: HewlettP_05:5e:70 (00:17:a4:05:5e:70)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 1.2.44.101 (1.2.44.101), Dst: 1.2.32.250 (1.2.32.250)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 84
    Identification: 0x7718 (30488)
    Flags: 0x00
        0.. = Reserved bit: Not Set
        .0. = Don't fragment: Not Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 2
        [Expert Info (Note/Sequence): "Time To Live" only 2]
            [Message: "Time To Live" only 2]
            [Severity level: Note]
            [Group: Sequence]
    Protocol: ICMP (0x01)
    Header checksum: 0xd46d [correct]
        [Good: True]
        [Bad : False]
    Source: 1.2.44.101 (1.2.44.101)
    Destination: 1.2.32.250 (1.2.32.250)
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0 ()
    Checksum: 0xf112 [correct]
    Identifier: 0xdffd
    Sequence number: 0 (0x0000)
    Data (56 bytes)

0000  f8 17 44 fa 62 8d 00 00 80 11 42 da 8f e2 27 66   ..D.b.....B...'f
0010  8f e2 4e 0d 00 89 00 89 00 3a 2d df 00 00 00 00   ..N......:-.....
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030  00 00 00 00 00 00 00 00                           ........
        Data: F81744FA628D0000801142DA8FE227668FE24E0D00890089...
        [Length: 56]

答案1

我将向你倾倒大量不连贯的想法和观察,希望其中任何一个能够激发你或其他人的思考。

  1. 多播目标 MAC 地址对应于防火墙的单播 IPv4 地址。
    就好像某个软件获取了防火墙的 IP 地址,假装它是一个多播地址,然后按照公式生成相应的以太网多播 MAC 地址。也就是说,它获取了 IP 地址的最后 23 位,并将其附加到 01:00:5e OUI 的末尾。

    我依稀记得可能有协议可以做到这一点(使用基于单播地址的多播地址),但我依稀记得这在 IPv6 中比在 IPv4 中更有可能实现。我以后得再研究一下。

    更新:我考虑过 IPv6 邻居发现 (IPv6 的 ARP 等效项) 使用“请求节点多播地址”。但我不确定这是否是一个很大的线索,因为我不明白为什么有人会想对 IPv4 ping 这样做。

  2. 您捕获的那些多播 ping 数据包的有效负载看起来不像典型的 ping 有效负载;它们其中包含有意义的数据,这可能是一个线索。

    正常的 ping 负载通常按顺序包含从 0x00 到 0xff 的每个字节值,因此在转储的 ASCII 版本中,您将按顺序看到每个字符。您捕获的这些 ping 似乎包含有意义的数据。我看到一些确定的 IP 地址和一些可能的端口号:

    0000 f8 17 44 fa 62 8d 00 00 80 11 42 da 8f e2 27 66 ..D.b.....B...'f
    0010 8f e2 4e 0d 00 89 00 89 00 3a 2d df 00 00 00 00 ..N......:-.....

    在偏移量 处0x000c,我看到8f e2 27 66,即 IP 地址[your class B].39.102。对其进行反向 DNS 查找显示justin.[your school].edu。该主机名对您有意义吗?追踪该主机是什么,以及它正在运行什么软件和服务(以及可能是否被感染或被攻击)可能会提供有关此流量的线索。

    紧接着,在偏移量处0x0010,我看到了8f e2 4e 0d,它是 IP 地址[your class B].78.13,我无法获得反向 DNS 结果,但也许您可以从您所在的位置找出它是什么。

    在这些 IP 地址之后,我看到了我猜测的两个端口号00 89(==137,NetBIOS 名称服务),然后00 89再次。

    这可能是一条 netbios-ns 消息,不知为何被写成了 ICMP 而不是 UDP?似乎不太可能。我觉得有太多字段写错了位置。

    这是否应该是响应 netbios-ns 消息的 ICMP 目标不可达消息,但 ICMP 标头写错了(写成了“回显请求”,而不是“目标不可达”)?似乎也不太可能。太多字段又写错了位置。

    这是某种恶意软件消息吗,用于协调哪些主机被感染/被攻击以及下一步要攻击哪些主机?汉隆剃刀似乎不相信这一点,但我认为这是合理的。

    更新:仔细想想,最有可能的可能是某些东西只是重新使用缓冲区来填充此 ping 请求的主体。因此,它的内容可能是个幌子。

  3. 这些帧的 TTL 是否总是只有 2,还是您看到突发的下降 TTL?
    TTL 始终相同表明数据包风暴是纯粹的第 2 层桥接环路。TTL 递减表明第 3 层(IP 层)参与其中;某个学生的个人无线路由器的 NAT 网关代码可能存在错误,并转发了某些与它无关的帧,从而可能形成环路。

    也就是说,我认为这里可能有两个不同的问题在相互作用。一个是向多播 MAC 地址发送这些带有有意义负载的奇怪 ping,但单播 IPv4 地址却不是。第二个问题可能是单独的错误设备看到了那些它通常看不到的帧,并将它们额外转发回网络,从而形成循环。

答案2

当我看到类似情况时,十有八九是某个地方出现了循环。如果这种情况不常见,那么有人插上电源,然后困惑为什么它不工作了,然后又拔掉了电源。在实验室或开发环境中发现这种情况是很难的,这就是为什么我总是坚持在物理上和防火墙上将两者分开。

其次最常见的问题是某种病毒活动。生成树风暴发生的频率较低,网络设备实际损坏的频率也较低。

对我来说,环路一直是唾手可得的。如果未启用生成树,您可能需要研究这一点;一些 HP 交换机甚至具有环路保护功能,如果检测到端口上有环路,则会关闭该端口。看到实际效果非常酷。

答案3

检查路由协议的默认广告时间。

并且您在这些 hp 交换机上使用什么生成树设置?

答案4

我不明白你的问题。你说你有发往多播地址的 ping 请求?我从未见过这种情况,我想知道你是如何确定的,它们实际上是发往多播地址的 ICMP 回应请求数据包吗?你还说 ping 请求似乎来自你的交换机,但你接着说源 MAC 地址不是来自你的交换机,所以我对你实际看到的内容感到困惑。你能告诉我们你在捕获中到底看到了什么吗?也许甚至可以发布一两行捕获内容来显示你所指的数据包。谢谢。

相关内容