Я не наш обычный сетевой парень ... Меня только что призвали помочь с этой проблемой, так что терпите меня.
У нас довольно большая (~ 4000 устройств?) Сеть, в основном состоящая из оборудования HP Procurve. Время от времени в течение последних двух недель мы наблюдали ужасные широковещательные штормы, которые практически все сносили. Я настроил Wireshark для создания дампов размером 3 МБ и кое-что уловил сегодня утром.
Есть тысячи запросов ping. Похоже, они приходят с MAC-адресов наших коммутаторов и точек доступа и отправляются на MAC-адрес многоадресной рассылки IPv4. Исходные 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]
9 раз из 10, когда я вижу что-то подобное, это где-то петля. Если это нечасто, кто-то что-то подключает, затем недоумевает, почему это не работает, а затем снова отключает его. Это убийство, которое нужно найти в лаборатории или среде разработки, поэтому я всегда стараюсь разделить их физически и с помощью брандмауэра.
Следующая по частоте проблема - это вирусная активность. Реже это шторм связующего дерева, а реже - фактически неисправное сетевое устройство.
Петли всегда были для меня самым низким плодом. Если связующее дерево не включено, вы можете изучить это; Некоторые коммутаторы HP даже имеют функции защиты от петель, которые отключают порт, если обнаруживают петлю на этом порту. Очень здорово увидеть в действии.
Я собираюсь вывалить на вас множество разрозненных мыслей и наблюдений, на случай, если какие-то из них смогут стимулировать ваше или чье-то мышление.
MAC-адрес назначения многоадресной рассылки соответствует одноадресному IPv4-адресу вашего брандмауэра.
Это как если бы какое-то программное обеспечение взяло IP-адрес вашего брандмауэра, сделало вид, что это многоадресный адрес, а затем следовало формуле для генерации соответствующего многоадресного MAC-адреса Ethernet. То есть он взял последние 23 бита IP-адреса и добавил их в конец OUI 01: 00: 5e.
Я смутно помню, что могут существовать протоколы, которые это делают (используют многоадресный адрес на основе одноадресного адреса), но мои смутные воспоминания говорят мне, что это с большей вероятностью будет сделано в IPv6, чем в IPv4. Мне придется исследовать это позже.
Обновить: Я думал об использовании IPv6 Neighbor Discovery (эквивалент IPv6 ARP) «многоадресного адреса запрошенного узла». Я не уверен, что это в значительной степени является лидером, потому что я не понимаю, почему кто-то захочет делать это для пингов IPv4.
Полезные данные захваченных многоадресных пакетов ping не похожи на обычные полезные данные ping; в них есть значимые данные, которые могут быть подсказкой.
Обычные полезные данные ping обычно содержат каждое значение байта от 0x00 до 0xff по порядку, поэтому в версии дампа ASCII вы увидите все символы по порядку. Эти захваченные вами эхо-запросы содержат значимые данные. Я вижу некоторые определенные 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? Вряд ли. Мне кажется, слишком много полей не в том месте.
Предполагалось, что это сообщение ICMP о недоступности пункта назначения в ответ на сообщение netbios-ns, но заголовок ICMP был написан неправильно (как «эхо-запрос» вместо «пункт назначения недоступен»)? Тоже маловероятно. Снова слишком много полей не в том месте.
Это что-то вроде вредоносного сообщения, в котором указывается, какие хосты заражены / разграблены, а какие атаковать дальше? Бритва Хэнлона, казалось бы, не учитывает это, но я думаю, что это правдоподобно.
Обновить: Если подумать, возможно, наиболее вероятно, что что-то просто повторно использует буфер для заполнения тела этого запроса ping. Таким образом, его содержимое может быть отвлекающим маневром.
TTL этих кадров всегда всего 2, или вы видите всплески убывания TTL?
Одинаковые значения TTL всегда будут указывать на то, что шторм пакетов является чем-то вроде петли моста второго уровня. Уменьшение TTL будет означать, что задействован уровень 3, уровень IP; Код шлюза NAT одного из личных беспроводных маршрутизаторов этого студента мог быть ошибочным, и при пересылке определенных кадров он не имеет бизнес-пересылки, что потенциально может создавать петлю.
То есть я предполагаю, что здесь могут взаимодействовать две отдельные проблемы. Один из них - это то, что отправляет эти странные эхо-запросы со значимой полезной нагрузкой на многоадресный MAC-адрес, но на одноадресный IPv4-адрес. Вторая проблема может заключаться в отдельном неисправном устройстве, которое видит те кадры, которые обычно не видит, и пересылает их обратно в сеть в дополнительное время, создавая цикл.
проверьте время рекламы по умолчанию для ваших протоколов маршрутизации.
и какую настройку связующего дерева вы используете на этих коммутаторах hp?
Не могли бы вы предоставить дополнительную информацию об IP-адресе назначения? Судя по вашему снимку, это адрес одноадресной рассылки. Можете ли вы подтвердить, что оно из того же / 16 (класс B), что и остальное ваше снаряжение?
Редактировать на основе комментария:
Не могли бы вы представить схему топологии? Если я вас правильно понял, у вас есть что-то вроде следующей физической топологии с вашими коммутаторами, подключенными к брандмауэру:
{
Router --- Firewall ---{ [multiple switches]
{
Еще несколько дополнительных вопросов:
Если у вас есть действующий контракт на поддержку, я бы подумал о том, чтобы открыть дело с HP и спросить их, в каком случае коммутаторы будут использовать многоадресный MAC-адрес при отправке трафика в известное одноадресное место назначения. Мне это кажется ошибкой.
Я не понимаю твой вопрос. Вы говорите, что у вас есть запросы ping, идущие на адреса многоадресной рассылки? Я никогда этого не видел, и мне интересно, как именно вы это определили, действительно ли это пакеты эхо-запроса ICMP, идущие на многоадресные адреса? Вы также заявили, что запросы ping, похоже, исходят от ваших коммутаторов, но затем вы продолжаете говорить, что исходные MAC-адреса не от ваших коммутаторов, поэтому я не понимаю, что вы на самом деле видите. Не могли бы вы подробнее рассказать, что именно вы видите в кадре? Может быть, даже опубликуйте пару строк захвата с указанием пакетов, о которых вы говорите. Спасибо.