Относительно недавно мы публиковали статью “Сетевой мониторинг и выявления аномальной сетевой активности с помощью решений Flowmon Networks”. Там мы кратко рассмотрели возможности этого продукта и процесс установки. Неожиданно для нас, после статьи и вебинара, поступило большое кол-во запросов на тестирование Flowmon. И первые же пилотные проекты выявили несколько типовых проблем с сетью, которые не увидишь без использования NetFlow. Сразу стоит отметить, что в рамках тестирования продукта наиболее интересные результаты получались благодаря модулю определения аномалий (ADS). После короткого “обучения” (хотя бы неделю) мы начинали фиксировать различные инциденты. В этой статье мы рассмотрим самые частые из них.
1. Кто-то сканирует сеть
Абсолютно в каждом пилоте мы обнаруживали хосты, которые сканируют сеть. Хосты, которые не должны этого делать. В паре случаев оказалось, что это “специфическое” ПО и проблему решали обычными правилами на межсетевом экране. Однако, в большинстве случаев в компании обнаруживался какой-нибудь “удалец”, который играется с Kali Linux, проходя PenTest курсы (что весьма похвально!). Только один раз был найден действительно зараженный ПК, который в автоматическом режиме вел сканирование сети.
2. Большие потери по сети (скачалось 60мб, до юзера дошло 10)
Довольно часто можно обнаружить проблемы с потерями на определенных участках сети. В инциденте Flowmon может значиться, что с целевой системы было скачано 60мб, в то время, как обращавшийся пользователь получил всего 10мб. Да, иногда пользователи действительно говорят правду, что какое-то приложение очень медленно работает. Flowmon может быть полезен в таких случаях.
3. Множество подключений с периферийных устройств (принтеров, камер) к серверам
Обнаруживаем данный инцидент практически каждый раз. Сделав простейший фильтр можно увидеть, что к контроллеру домена идут периодические запросы от периферийных устройств. Начав расследование часто приходили к выводу, что этих коннектов/запросов быть не должно. Хотя бывают и “легальные” вещи. В любом случае, после этого “безопасники” ВДРУГ обнаруживают, что у них есть целый класс устройств, за которыми тоже нужно следить и хотя бы вынести в отдельный сегмент.
4. Подключение к серверам по нестандартным портам
Тоже частый кейс. Для примера, обнаруживается DNS сервер к которому идут запросы не только по 53 порту, но и по куче других. Тут сразу вырисовываются две проблемы:
- Кто-то разрешил на МЭ другие порты до DNS сервера;
- На DNS сервере подняты другие службы/сервисы.
Обе проблемы требуют разбирательства.
5. Подключения к другим странам
Обнаруживается почти в каждом пилоте. Особенно это интересно для какого-нибудь сегмента с камерами или СКУД системами. Оказываются, некоторые китайские устройства настойчиво “стучатся” к себе на родину или куда-нибудь в Бангладеш.
6. Перед увольнением сотрудника резко возрастает его трафик
Это мы обнаружили в двух последних пилотах. В разбирательствах мы не принимали участия, но скорее всего пользователь просто делал бэкапы какой-то рабочей информации. Разрешено ли это политикой компаний нам неизвестно.
7. Множественные DNS запросы от пользовательского хоста
Данная проблема часто является признаком зараженного ПК, либо “особенностями” какого-то специфического ПО. В любом случае это полезная информация для размышления, особенно когда компьютер пользователя генерирует под 1000 DNS запросов в час.
8. “Левые” DHCP сервера в сети
Еще одна болезнь многих больших сетей. Пользователь запустил VirtualBox или VMWare Workstation, при этом забыл выключить встроенный DHCP сервер, от чего периодически ложится какой-нибудь сегмент сети. Анализ NetFlow здесь очень быстро помогает выявить нашего нарушителя.
9. “Петли” в локальной сети
“Петли” обнаруживаются почти в каждом пилотном проекте, где есть возможность завернуть NetFlow/sFlow/jFlow/IPFIX с коммутаторов доступа, а не только с ядра. В некоторых компаниях коммутаторы успешно справляются с этими петлями (в виду грамотной настройки оборудования) и их особо никто не замечает. А в некоторых — всю сеть периодически штормит и никто не может понять, что происходит. Flowmon здесь будет очень полезен.
Заключение
Подобный анализ сети может быть полезным практически для любой компании. Особенно если учесть, что он может быть выполнен в рамках бесплатного триального периода. Здесь мы уже рассказывали, как развернуть решение самостоятельно. Но вы всегда можете обратиться к нам за помощью по настройке, анализу результатов или же просто по продлению триального режима!
Если вам интересны подобные материалы, то следите за обновлениями (Telegram, Facebook, VK, TS Solution Blog)!
hjornson
>“Левые” DHCP сервера в сети. Еще одна болезнь многих больших сетей. Пользователь запустил VirtualBox или VMWare Workstation, при этом забыл выключить встроенный DHCP сервер,
Ну, не обязательно. Бывает еще возомнившее о себе железо, wifi точки например; емнимс и даже как-то принтер встречался который после неудачно дернувшегося питания забыл настройки и решил что его призвание — поработать dhcp сервером.
cooper051 Автор
Да, бывает и такое. Но на нашей практике это чаще юзеры «балуются»)
freejoins
А использование DHCP snooping разве не является best practice? Что б таких случаев не было, по крайней мере на пользовательских портах.
cooper051 Автор
Конечно это best practice. Только вот об этих функциях часто забывают.