Windows ПК как генератор ARP флуда
Хочу поведать поучительную историю, которая случилась сегодня у меня на работе. Работаю я в одной очень известной компании предоставляющей, в числе прочих, услуги доступа ко всемирной паутине. И суть моей работы заключается в поддержании нормальной работы сети передачи данных. Сеть эта построена по классической структуре Ядро, Агрегация, Доступ. Коммутаторы доступа приблизительно на половину производства D-Link, вторая (большая) половина от Huawei. Управление всем сетевым железом вынесено в отдельный вилан, через него же оно всё и мониторится.
И вот сегодня поутру стало твориться нечто неладное. Система управления и мониторинга железа стала выкидывать «портянки» событий «коммутатор *** офлайн»-«коммутатор *** онлайн». Причём сообщения эти приходили по сегментам сети, в которых установлены были коммутаторы производства Huawei. Беглый просмотр состояния шторм-контроля и загруженности интерфейсов на агрегации ничего не дал, ничего не сказали и логи. День обещал быть весёлым…
Звонок от службы мониторинга сети не добавил радости — завели инцидент по выпадению домовых узлов. При этом массовых жалоб от клиентов об ограничениях в получении услуги не поступало. Удалось даже найти клиента в проблемном сегменте, который отвечал на ICMP обнадёживающими 0,8-ю милисекундами. Попытки зайти на какой-либо коммутатор по телнету были сродни пытке: коннект либо отваливался по тайм-ауту, либо приходилось минутами ждать реакции на ввод логина/пароля и на команды. Отчаявшись посмотреть лог «полуживого» коммутатора я, для очистки совести, помучившись изрядно, перезагрузил его. Секунд 10 после старта коммутатор был жив, бодренько отвечая на ICMP запросы, но тут же «пинги» на глазах стали принимать совершенно неприличные значения в 800–1000 мс, а потом и вовсе пропали.
Тут до меня стало доходить, что процессоры, отнюдь не высокопроизводительные у коммутаторов, явно чем-то загружены и, по всей видимости, на все 100%. Запустив tcpdump на vlan-интерфейсе сервера мониторинга я нашел причину высокой загрузки CPU на коммутаторах. Аномально большое количество ARP трафика в вилане управления — несколько тысяч пакетов в секунду. Причина найдена, но вот как отыскать её источник? Было решено заблокировать вилан управления на всех портах агрегации и потом по очереди разблокировать его обратно пока не будет найден проблемный сегмент.
Я успел проделать эту операцию всего на двух узлах агрегации, как вдруг внезапно вся эта свистопляска прекратилась. Но очень подозрительным мне показалось то, что минутою раньше мой коллега, сидящий за соседним столом, вынул сетевой патчкорд из порта коммутатора который служил для доступа к оборудованию и его настройки. Я попросил коллегу снова подключить свой ноутбук в сеть — спустя 10 секунд «пинги» на коммутаторы опять взлетели до безобразных значений. Источник был найден, но этот ноутбук не один месяц использовался для обновления ПО и настройки сетевого оборудования, что же могло с ним такое случиться?
Для начала решили, хотя и наличествовал установленный антивирус, просканировать на наличие зловредов утилитами от доктора и лаборатории. Ничего существенного найдено не было. Попробовали загрузиться в Linux — сетевая молчала, никакого флуда. Обратно загрузили Windows — стойкий эффект, сразу же вилан наполнялся ARP флудом. Но буквально вчера с ноутбуком всё было в порядке! И тут я зачем-то полез в настройки сетевой карты… Коллега мой не часто занимается настройкой железа и обновлением ПО на нём, поэтому запомнить значения маски и шлюза для сети управления он не мог. И он допустил досадную ошибку в конфигурации сетевой карты — вместо 255.255.224.0 для маски подсети он указал 255.255.254.0!
Но что ещё более меня поразило, так это то, что несмотря на явно неправильную конфигурацию (шлюз в ней оказался за пределами сетевого сегмента из-за неверно указанной маски), операционка безропотно проглотила этот бред! Превратив ноутбук в генератор ARP трафика. Вот что было в настройках протокола ipv4:
IP адрес 10.220.198.111
Маска 255.255.254.0
Адрес шлюза 10.220.192.1
При такой маске подсеть ограничена IP адресами 10.220.198.1 — 10.220.199.254 и шлюз 10.220.192.1 лежит вне этого диапазона. Операционная система не должна разрешать присваивать адрес шлюза из другой сети. Это явный баг!
Был бы признателен если бы кто-то взял на себя труд объяснить механизм возникновения ARP флуда в данной ситуации, от себя же хочу пожелать всем специалистам сетевикам внимательности и ещё раз внимательности. Как говорится — семь раз отмерь, один раз отрежь.
Комментарии (8)
RazorBlade
6 июля 2016 в 15:00 (комментарий был изменён)
+1↑
↓
На Win7, при неправильно указанном адресе шлюза, вываливает предупреждение, но дает сохранить.Так что, ваш коллега, скорее всего не обратил внимание и просто нажал сохранить.
Yoda33
6 июля 2016 в 15:20
0↑
↓
Тогда это не баг, а диверсия. Хотелось бы понять логику разработчиков, заложивших такую потенциальную бомбу.
Mendel
6 июля 2016 в 15:20
0↑
↓
А можно узнать версию форточек? А то или я не заметил или вы не указали.
А вообще — бага конечно, не иначе. Форточки это не тот инструмент которым положено отстреливать себе ноги.-
Yoda33
6 июля 2016 в 15:24
0↑
↓
Забыл указать — Windows 7 максимальная. Я бы запретил сетевикам работать с виндой, но у компании и департамента ИБ иная точка зрения, увы. 6 июля 2016 в 16:20
+1↑
↓
Никакого бага тут нет, ситуация, когда default gateway находится в другой подсети, хоть и странная, но реальная и возможная.
Шлюз по умолчанию совсем не обязательно должен быть в той же подсети, что и хост.
Важно, чтобы он был просто доступен (был маршрут до этого самого default-gateway).
Wicron
6 июля 2016 в 16:29
0↑
↓
Windows стабильно игнорит ситуации, когда шлюз оказывается за пределами, определенными маской. Такое чувство, что в случае наличия такой ситуации ОС может подменить маску, выданную DHCP сервером на ту, которая позволит достучаться до шлюза. Уведомлений об этом обычно нет. Как по мне Windows таким образом создает прецедент безопасности, хотя такое поведение очень часто фиксит проблемные сети, где так или иначе шлюз оказывается недоступен вследствие неверной маски, что очень часто можно встретить как типовую ошибку.6 июля 2016 в 16:32
0↑
↓
Технически маску можно сделать вообще любую, хоть с такой дыркой 255.0.255.0 и всё будет работать (и не обязательно неправильно) в соответствии с протоколами маршрутизации и ARP.6 июля 2016 в 16:33
0↑
↓
А что вас смущает в том, что шлюз лежит вне диапазона сети? В линуксе я постоянно пользуюсь такими штуками.
ip addr add 10.100.10.2/24 dev eth0
ip ro add via 10.100.11.1 src 10.100.10.2 dev eth0
всего лишь заставит ОС в случае отсутствия известного маршрута до адреса назначения послать запрос через шлюз. Шлюз указан 10.100.11.1, и поэтому в eth0 безт послан arp who has 10.100.11.1 и после получения ответа все запросы «на шлюз» будут направляться на этот МАС. IP-адрес шлюза больше нигде не участвует в этом.И даже интереснее бывают проблемы с arp. Например, когда нужно маршрутизировать разные адреса клиентов через один и тот же шлюз, но в разных вланах.
ip ro add via 10.10.20.1 dev eth0.11 table vlan11
ip ro add via 10.10.20.1 dev eth0.12 table vlan12приходится сделать
sysctl -w net.ipv4.conf.eth0/11.rp_filter=0
sysctl -w net.ipv4.conf.eth0/11.arp_ignore=2
sysctl -w net.ipv4.conf.eth0/12.rp_filter=0
sysctl -w net.ipv4.conf.eth0/12.arp_ignore=2
, а то когда одна сетевая карта разными МАСами в разных вланах смотрит в один физический сегмент на один и тот же шлюз, то трафик бывает идет не в тот влан
