Windows ПК як генератор ARP флуда +13
- 06.07.16 11:15 •
- Yoda33 •
- # 304868 •
- Хабрахабр •
- 46 •
- 15800
- такий же як Forbes, тільки краще.
Доброго дня,% username%!
Хочу розповісти повчальну історію, яка трапилася сьогодні в мене на роботі. Працюю я в одній дуже відомій компанії надає, в числі інших, послуги доступу до всесвітньої павутини. І суть моєї роботи полягає в підтримці нормальної роботи мережі передачі даних. Мережа ця побудована за класичною структурі Ядро, Агрегація, Доступ. Комутатори доступу приблизно на половину виробництва D-Link, друга (більша) частина від 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:
Був би вдячний якби хтось взяв на себе працю пояснити механізм виникнення ARP флуду в даній ситуації, від себе ж хочу побажати всім фахівцям мережевикам уважності і ще раз уважності. Як то кажуть - сім разів відміряй, один раз відріж.
RFC 1620 - Internet Architecture Extensions for Shared Media наприклад. Суть в тому, що сьогодні повно сценаріїв, коли 2 хоста знаходяться в одному L2 сегменті (SameSM), але в різних IP подсетях (LIS). При цьому, один з вузлів може бути шлюзом для іншого. Щоб це працювало, необхідно лише вказати хосту, що шлюз знаходиться з ним в одній shared media, т. Е. Вручну прописати на ньому маршрут «в інтерфейс» (link route), або роздати його через DHCP option 121