Windows ПК как генератор ARP флуда

    Доброго дня, %username%!

    Хочу поведать поучительную историю, которая случилась сегодня у меня на работе. Работаю я в одной очень известной компании предоставляющей, в числе прочих, услуги доступа ко всемирной паутине. И суть моей работы заключается в поддержании нормальной работы сети передачи данных. Сеть эта построена по классической структуре Ядро, Агрегация, Доступ. Коммутаторы доступа приблизительно на половину производства 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 флуда в данной ситуации, от себя же хочу пожелать всем специалистам сетевикам внимательности и ещё раз внимательности. Как говорится — семь раз отмерь, один раз отрежь.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 46

      +2
      На Win7, при неправильно указанном адресе шлюза, вываливает предупреждение, но дает сохранить.Так что, ваш коллега, скорее всего не обратил внимание и просто нажал сохранить.
        0
        Тогда это не баг, а диверсия. Хотелось бы понять логику разработчиков, заложивших такую потенциальную бомбу.
          0
          Бритва Хенлона. В данном случае просто не стали ставить дополнительную защиту от дурака.
          А кто не читает предупреждения, тот сам себе злобный буратино.
        0
        А можно узнать версию форточек? А то или я не заметил или вы не указали.
        А вообще — бага конечно, не иначе. Форточки это не тот инструмент которым положено отстреливать себе ноги.
          –4
          Забыл указать — Windows 7 максимальная. Я бы запретил сетевикам работать с виндой, но у компании и департамента ИБ иная точка зрения, увы.
            +6
            Никакого бага тут нет, ситуация, когда default gateway находится в другой подсети, хоть и странная, но реальная и возможная.
            Шлюз по умолчанию совсем не обязательно должен быть в той же подсети, что и хост.
            Важно, чтобы он был просто доступен (был маршрут до этого самого default-gateway).
              +1
              В каком RFC это описано?
                +2
                RFC 1620 — Internet Architecture Extensions for Shared Media например. Суть в том, что сегодня полно сценариев, когда 2 хоста находятся в одном L2 сегменте (SameSM), но в разных IP подсетях (LIS). При этом, один из хостов может быть шлюзом для другого. Чтобы это работало, необходимо лишь указать хосту, что шлюз находится с ним в одной shared media, т. е. вручную прописать на нем маршрут «в интерфейс» (link route), либо раздать его через DHCP option 121
                  +3
                  Неправильный вопрос, правильный звучит так «В каком RFC явно указывается что default gateway должен находиться в той же подсети что и сетевой интерфейс?»
                  Правильный ответ — ни в каком, читайте как работают протоколы роутинга и что такое дефолтный маршрут и зачем он нужен.
                  0
                  Да пусть любые воркараунды делает. Мне все равно.
                  Если оно досит сетевое оборудование, значит баг.
                0
                Windows стабильно игнорит ситуации, когда шлюз оказывается за пределами, определенными маской. Такое чувство, что в случае наличия такой ситуации ОС может подменить маску, выданную DHCP сервером на ту, которая позволит достучаться до шлюза. Уведомлений об этом обычно нет. Как по мне Windows таким образом создает прецедент безопасности, хотя такое поведение очень часто фиксит проблемные сети, где так или иначе шлюз оказывается недоступен вследствие неверной маски, что очень часто можно встретить как типовую ошибку.
                  0
                  Технически маску можно сделать вообще любую, хоть с такой дыркой 255.0.255.0 и всё будет работать (и не обязательно неправильно) в соответствии с протоколами маршрутизации и ARP.
                    0
                    Хотелось уточнить, что значит технически сделать?

                    Вбить в конфиг и сохранить в файл или построить работающую сеть, использующую оборудование и операционные системы реализующие стандартные сетевые технологии?

                    Как кратко записать маску 255.0.255.0? Например, 255.255.255.0 получаем маску /24, а в вашем случае какая краткая маска получится?
                      0
                      А не нужно её в CIDR записывать, и всё станет на свои места.

                        0
                        Всё гораздо проще с этими масками.
                        Ведь как работает маршрутизация на какой-то абстрактный target IP адрес:
                        1) сначала свой IP и target IP умножается на маску (бинарно).
                        2) в результате сравнивается то, что остаётся после умножения.
                        3) если результаты совпадают, то подсеть одна, посылается ARP-request target хосту и в результате пакет пересылается напрямую хосту с IP и MAC-адресом хоста.
                        4) Если не совпадают, пакет всё равно посылается хосту на с MAC-адресом маршрутизатора (для чего сначала отправляется ARP-request на маршрутизатор).

                        и да, всё будет работать с дырявыми масками, если вся сеть будет соответствующим образом настроена. проверялось лично лет 15 назад.
                          0
                          RFC прерывистые маски не запрещает, но на практике никто не тестирует с ними софт и есть веротяность наткнуться на баг. Недавно наткнулся на пропадение крипто-мапы на IOS после применения к ней ACL с опечаткой в маске.
                            0
                            Ключевое слово опечатка (ошибка). Если всё делать преднамеренно и на всей инфраструктуре, то работать будет.
                            В своё время мне довелось поработать тестировщиком у отечественного производителя VPN. Там иногда тестируется и не такое.
                      +5
                      А что вас смущает в том, что шлюз лежит вне диапазона сети? В линуксе я постоянно пользуюсь такими штуками.
                      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-адрес шлюза больше нигде не участвует в этом, собственно и ваш IP тоже, если маршрутизируем какую-то другую сеть (к примеру 10.200.10.0/24 с eth1).

                      И даже интереснее бывают проблемы с 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
                      а то когда одна сетевая карта разными МАСами в разных вланах смотрит в один физический сегмент на один и тот же шлюз, то трафик бывает идет не в тот влан
                        0
                        И даже больше скажу: если не шлюзе (роутере, компьютере) не включен arp_ignore, то при получении запроса arp who has
                        1) с несуществующего в этой сети IP
                        2) запрашивающий IP-адрес, который отсутствует на этой сетевой карте/влане, но пристутствует на хосте вообще
                        — роутер ответит

                        Часто пользуюсь командой, чтобы узнать примерно количество включенных роутеров в влане:
                        #arping -0 -I eth0.1234 192.168.0.1
                        #arping -0 -I eth0.1234 192.168.1.1

                        Посылает запросы с айпишника 0.0.0.0 в сегмент, и все роутеры с дефолтовыми 192.168.0-1.1 адресам отвечают как миленькие.
                          0
                          это на какой ОС такой ключик у arping?
                          [root@bsmanage ~]# arping -0
                          arping: invalid option — '0'
                          Usage: arping [-fqbDUAV] [-c count] [-w timeout] [-I device] [-s source] destination
                          -f: quit on first reply
                          -q: be quiet
                          -b: keep broadcasting, don't go unicast
                          -D: duplicate address detection mode
                          -U: Unsolicited ARP mode, update your neighbours
                          -A: ARP answer mode, update your neighbours
                          -V: print version and exit
                          -c count: how many packets to send
                          -w timeout: how long to wait for a reply
                          -I device: which ethernet device to use (eth0)
                          -s source: source ip address
                          destination: ask for what ip address

                          [root@bsmanage ~]# uname -a
                          Linux bsmanage.lds.net.ua 2.6.32-642.1.1.el6.x86_64 #1 SMP Tue May 31 21:57:07 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
                          [root@bsmanage ~]# cat /etc/*rele*
                          CentOS release 6.8 (Final)
                            0
                            Ubuntu

                            ARPing 2.09, by Thomas Habets <thomas@habets.pp.se>
                            usage: arping [ -0aAbdDeFpqrRuv ] [ -w ] [ -S <host/ip> ]
                            [ -T <host/ip ] [ -s ] [ -t ] [ -c ]
                            [ -i ] <host/ip/MAC | -B>
                            Options:

                            -0 Use this option to ping with source IP address 0.0.0.0. Use this
                            when you haven't configured your interface yet. Note that this
                            may get the MAC-ping unanswered. This is an alias for -S
                            0.0.0.0.

                            Без ключика 0 не хочет слать arping с интерфейса, на котором нет IPv4 адреса, а у меня таких интерфейсов сотни, на вланах с proxy_arp. Поэтому использую, потому как алиас "-S 0.0.0.0" писать дольше
                          –2
                          Меня смущает результат такого нестандартного использования шлюза, что я и описал в топике.
                            +1
                            А, не смущает полное отсутствие необходимости в шлюзе, к примеру, на ppp-интерфейсах (точка-точка, ppp/tun/tap/etc).
                            Формально он там обычно указывается, но можно и без него, абсолютно.
                            #ip ro add dev ppp0
                            при этом на ppp-интерфейсах на обоих сторонах тоннеля вообще можно IP не вешать, все прекрасно работает.

                            Да и на обычном компе можно шлюз не указывать, винда по умолчанию (если память не изменяет) в случае отсутствия шлюза в системе просто шлет в сеть запрос «arp who has IP-адрес-назначения». И если на роутере в сети, куда подключен этот интерфейс, включен proxy_arp то интернет прекрасно работает. Просто компьютер «думает» что у него весь интернет в локальной сети, и у всех компов в интернете один и тот же МАС — МАС роутера.
                            0
                            в eth0 будет послан arp who has 10.100.11.1 и после получения ответа все запросы


                            Каким образом броадкаст пакет из одной подсети (10.100.10.0/24) попадает в другую (10.100.11.0/24)?

                            и после получения ответа все запросы «на шлюз» будут направляться на этот МАС

                            Как обратится к по MAC в другую IP-подсеть?
                              0
                              >Каким образом броадкаст пакет из одной подсети (10.100.10.0/24) попадает в другую (10.100.11.0/24)?
                              Никаким, в ip route можно жестко указать маршрут на connected сеть через интерфейс, даже не имея собственного адреса в этой сети. Маршрут есть — этого достаточно. ARP система сгенерит сама, если nexthop=интерфейс.

                              >Как обратится к по MAC в другую IP-подсеть?
                              Никак, на MAC-уровне нет подсетей.
                            0
                            >> Управление всем сетевым железом вынесено в отдельный вилан, через него же оно всё и мониторится.

                            ловил «такие» штуки, после чего было решено дробить районы на свои виланы/группы,
                            ускоряет поиск сюрпризов в управляющей сети, вендоров больше двух :(
                              –1
                              Когда устройств за 2к и все на мониторинге у людей, которые по каждому чиху заводят инциденты — желание проводить ренамберинг на них в очередной раз как-то улетучивается 8)
                            • UFO just landed and posted this here
                                –5
                                Согласен почти со всем, но пользовательская ОС это не роутер. По моему мнению в ней всё должно быть однозначно.
                                  –4
                                  Чувак, ты явно в ударе, делать заключения аля «вы ничего не понимаете в сетях» на основании одного из высказываний. По моим сведениям, например Router OS для микротиков ведет себя иначе при такой ситуации.
                                    0
                                    Неужели не дает поставить шлюз вне пределов сети??? Нет под рукой микротика сейчас, чтобы проверить, но как-то не вертится в это берд.
                                      0
                                      Дает поставить, но только какой результат? В Windows ядро маршрутизирует трафик в этом случае, микротик по-моему в таком случае игнорил это, можете проверить, я проверял на случаях, когд DHCP сервер выдавал шлюз за пределами, дозволенными маской.
                                    • UFO just landed and posted this here
                                        0
                                        С какого перепугу УМЕНЬШЕНИЕ размера локальной сети (а ведь именно такая опечатка в маске привела к тому, что шлюз оказался за бортом) должна неправомерно УВЕЛИЧИТЬ количество хостов которые посчитали локальными? Вероятнее наоборот, что часть локальных узлов стали адресоваться через шлюз. Но так мы не объясним флуд.

                                        Предложу более простой сценарий — винда сохраняет МАС только тех, кто в своей сети, справедливо предполагая, что остальных она будет искать только через шлюз. Ну а МАС шлюза она не сохраняет специально _ОШИБОЧНО_ считая, что он всегда из своей сети, а значит уже сохранен. В результате любой запрос за пределы своей сетки вызывает ARP.

                                        У меня правда остается непонимание что за топология такая у которой есть шлюз (напомню, что мы говорим о сервисной сети для администрирования сетевого оборудования), и этот шлюз на один интерфейс отвечает на ARP, а на остальные пересылает его дальше. Но тут или я что-то не понял, или какая-то специфическая структура, или просто проморгали такую возможность. Ну или я не прав и есть другой сценарий.
                                        • UFO just landed and posted this here
                                            0
                                            Ну я диагноз по фотографии ставить не собирался. Я лишь сказал о том, что ваш диагноз по фотографии неверен, а свой привел лишь для иллюстрации того почему неверен ваш.
                                      0
                                      Плохо не то, что винда позволяет шлюз за пределами маски. Плохо то, что она при этом создает флуд, но не запрещает.
                                      Запретила бы, мол не делай такой шлюз, все бы подстроились, это ж Винда)
                                      Разрешала бы, и не спамила — все было бы тоже ок.
                                      Но разрешать и бажить — плохо.
                                        0
                                        >IP Unnumbered — маску ставят 255.255.255.255 (те всё слать шлюзу, совсем всё)

                                        Скажу больше, если оборудование поддерживает маску 0.0.0.0, то ему вообще не нужен шлюз ни в каком виде (при определенных усилиях, естественно). Оно будет считать, что все (совсем все) IP адреса находятся с ним в одной подсети и слать ARP запросы в поисках их MAC адресов. Достаточно завести в том же L2 сегменте хост-роутер с Proxy ARP, который будет отвечать на эти запросы и маршрутизировать трафик и, voilà, эти железяки уже в интернете.
                                        Конечно, это голая, но небезынтересная теория. Конечно никто не поддерживает маску /0 и конечно размеры ARP таблиц будут чудовищные))
                                        +1
                                        На чистой винде удалось воспроизвести подобное поведение?
                                          0
                                          Странно 2016 год, а коммутатор без блокировки ARP storm, обычно глючная карта даунит интерфейс как только широковещалка насчитает 300-500 пакетов в секунду. 5 минут перерыв и интерфейс поднимается 3-5 попыток и даунится интерфейс до операторского вмешательства… ну ладно мож просто не включили. но и в sys log наверняка много интересного упало… хотя я сам когда его смотрел последний раз… Да и втыкать что-то в производственное оборудование как-то не гуд, нет что ли постоянного терминального сервака для настройки обязательно физический доступ к стойке в машинном зале? Разве только с фигой в кармане…
                                            0
                                            Так судя по всему флуд на коммутаторы доступа прилетал из ядра сети (одмины же, имеют возможность), то есть с аплинкового порта. Включать шторм-контрол на аплинке — не лучшая идея.
                                            +4
                                            А с каких пор кривые руки\невнимательность стали багами ОС?
                                            Так-то в этих ваших линуксах можно и похлеще натворить, особенно не проверяя что ты там по настраивал.
                                              0
                                              Интересно, я когда-нибудь привыкну, что есть большая и меньшая половины?!..
                                                +1
                                                Учительница детям:
                                                — Я уже который раз объясняю, что половина не может быть большей или меньшей! Половины — они одинаковые, на то они и половины!
                                                Однако большая половина класса этого не понимает…
                                                  0
                                                  TCPDUMP запустили… А что в ARP-запросах было?
                                                    0
                                                    ip 10.220.198.111/23
                                                    GW 10.220.192.1/19
                                                    вполне рабочая конфигурация в отличие от
                                                    ip 10.220.198.111/23
                                                    GW 10.220.192.1/23
                                                    возможно у Вас просто неисправен интерфейс

                                                    Only users with full accounts can post comments. Log in, please.