9 типовых проблем в сети, которые можно обнаружить с помощью анализа NetFlow (на примере Flowmon)

9 типовых проблем в сети, которые можно обнаружить с помощью анализа NetFlow (на примере Flowmon)


Относительно недавно мы публиковали статью “ Сетевой мониторинг и выявления аномальной сетевой активности с помощью решений Flowmon Networks ”. Там мы кратко рассмотрели возможности этого продукта и процесс установки. Неожиданно для нас, после статьи и вебинара , поступило большое кол-во запросов на тестирование Flowmon . И первые же пилотные проекты выявили несколько типовых проблем с сетью, которые не увидишь без использования NetFlow. Сразу стоит отметить, что в рамках тестирования продукта наиболее интересные результаты получались благодаря модулю определения аномалий (ADS). После короткого “обучения” (хотя бы неделю) мы начинали фиксировать различные инциденты. В этой статье мы рассмотрим самые частые из них.

1. Кто-то сканирует сеть


Абсолютно в каждом пилоте мы обнаруживали хосты, которые сканируют сеть. Хосты, которые не должны этого делать. В паре случаев оказалось, что это “специфическое” ПО и проблему решали обычными правилами на межсетевом экране. Однако, в большинстве случаев в компании обнаруживался какой-нибудь “удалец”, который играется с Kali Linux, проходя PenTest курсы (что весьма похвально!). Только один раз был найден действительно зараженный ПК, который в автоматическом режиме вел сканирование сети.

2. Большие потери по сети (скачалось 60мб, до юзера дошло 10)


Довольно часто можно обнаружить проблемы с потерями на определенных участках сети. В инциденте Flowmon может значиться, что с целевой системы было скачано 60мб, в то время, как обращавшийся пользователь получил всего 10мб. Да, иногда пользователи действительно говорят правду, что какое-то приложение очень медленно работает. Flowmon может быть полезен в таких случаях.

3. Множество подключений с периферийных устройств (принтеров, камер) к серверам


Обнаруживаем данный инцидент практически каждый раз. Сделав простейший фильтр можно увидеть, что к контроллеру домена идут периодические запросы от периферийных устройств. Начав расследование часто приходили к выводу, что этих коннектов/запросов быть не должно. Хотя бывают и “легальные” вещи. В любом случае, после этого “безопасники” ВДРУГ обнаруживают, что у них есть целый класс устройств, за которыми тоже нужно следить и хотя бы вынести в отдельный сегмент.

4. Подключение к серверам по нестандартным портам


Тоже частый кейс. Для примера, обнаруживается DNS сервер к которому идут запросы не только по 53 порту, но и по куче других. Тут сразу вырисовываются две проблемы:

  1. Кто-то разрешил на МЭ другие порты до DNS сервера;
  2. На 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 )!

Только зарегистрированные пользователи могут участвовать в опросе. Войдите , пожалуйста.

Используете ли вы анализаторы NetFlow/sFlow/jFlow/IPFIX?

Alt text