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?

    • +10
    • 4,5k
    • 4
    TS Solution
    140,51
    Системный интегратор
    Поделиться публикацией

    Комментарии 4

      0
      >“Левые” DHCP сервера в сети. Еще одна болезнь многих больших сетей. Пользователь запустил VirtualBox или VMWare Workstation, при этом забыл выключить встроенный DHCP сервер,

      Ну, не обязательно. Бывает еще возомнившее о себе железо, wifi точки например; емнимс и даже как-то принтер встречался который после неудачно дернувшегося питания забыл настройки и решил что его призвание — поработать dhcp сервером.

        0
        Да, бывает и такое. Но на нашей практике это чаще юзеры «балуются»)
          0
          А использование DHCP snooping разве не является best practice? Что б таких случаев не было, по крайней мере на пользовательских портах.
            0
            Конечно это best practice. Только вот об этих функциях часто забывают.

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

      Самое читаемое