Кейсы для применения средств анализа сетевых аномалий: контроль удаленного доступа

    Тема удаленного доступа сейчас на подъеме, но обычно при ее описанию речь идет либо о решениях, устанавливаемых на устройствах сотрудников (например, описанный вчера Cisco AnyConnect), либо о решениях, устанавливаемых на периметре. Такое впечатление, что именно эти два набора защитных средств позволяют полностью исключить угрозы со стороны удаленных пользователей, подключающихся к корпоративной или ведомственной инфраструктуре. В этой заметке я хотел бы рассмотреть применение средств класса NTA (Network Traffic Analysis) для мониторинга удаленного доступа.

    image

    Надо сразу отметить, что мониторинг удаленного доступа мало чем отличается от каких-то иных узлов. Например, в прошлой заметке, когда мы ловили кампанию DNSpionage и Sea Turtle, мы начинали с группирования DNS-серверов в группу, которую и ставили на контроль, а также которая служила для нас эталоном и появление любых узлов, выполняющих функции DNS-сервера, но не входящих в нужную группу, автоматически считалось бы аномалией. С удаленным доступом все тоже самое — сначала мы должны объединить в группу все внутренние IP-адреса удаленных пользователей, а также все узлы, к которым эти пользователи могут подключаться (например, RDP-прокси, терминальный сервер, сервер электронной почты, файловый сервер, рабочие места, к которым удаленно подключаются пользователи, или виртуалки, доступ к которым осуществляется по VDI, и т.п.).

    image

    В качестве иллюстрации мы будем использовать решение Cisco Stealthwatch Enterprise, в котором мы создаем группу «Remote VPN IP Pool».

    image

    Дальше мы просто анализируем всю активность, фиксируемую применительно к данной группе.

    image

    Обратите внимание, что система нам уже показывает 4 нарушения политик безопасности. Но мы сейчас посмотрим немного в другую сторону. Виджет «Top Applications» позволяет увидеть нам весь входящий и исходящий трафик, сгруппированный по типам приложений/протоколов.

    image

    Дальше мы можем углубляться на нужную глубину с целью получения деталей того, кто и с кем общается, в каком направлении и в каком объеме.

    image

    Например, вот так будет выглядеть результат анализа сетевого трафика по протоколу HTTP, связанного с группой удаленных узлов.

    image

    Дальше мы можем воспользоваться дашбордом Host Summary, который покажет активность по каждому из интересующих нас узлов:
    • с кем узел взаимодействует
    • применяемые политики мониторинга
    • используемые хостом приложения и активность такого использования.


    image

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

    image

    Обратите внимание, что в данном сценарии мы не пользовались описанной вчера возможностью, присущей Ciscco AnyConnect, а именно сбором данных об активности приложений на узле и передачи ее на Cisco Stealthwatch Enterprise. В этом случае у нас было бы еще больше информации по активности удаленных узлов.

    image

    Сгруппировав узлы, обеспечивающую работу удаленного доступа, мы можем применять к ним различные политики для анализа. Например, достаточно часто, несмотря на предварительное планирование, нам не хватает пропускной способности, из-за избыточного использования ресурсов, что снижает и производительность, и может потребовать увеличения ресурсов для удаленного доступа. А причина может быть как в некорректной настройке узлов удаленного доступа, так и в использовании на них неразрешенного ПО или иных злоупотреблений, в том числе и без ведома владельца удаленного компьютера.

    Итак, как для этой задачи мы можем использовать решение класса NTA по анализу сетевых аномалий. Для интересующей нас группы узлов мы запускаем отчет Host Group Application Traffic.

    image

    По умолчанию мы видим вкладку с входящим и исходящим трафиком для выбранной группы узлов. На ней отображено, что за последние 4 часа у нас исходящий трафик преимущественно занят передачей файлов по P2P.

    image

    Дальше мы можем получить еще больше деталей по исходящему трафику:

    image

    Интересную статистику мы видим в результате — на первом месте по объему переданного трафика (17,7 ГБ) у нас находится приложение, которое передало столько данных по 53-му UDP-порту (это протокол DNS).

    image

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

    image

    Самое интересное в этой истории, конечно, заключается в том, что у нас пиринговое приложение использует DNS-протокол как транспорт для передачи данных, что может говорить об утечке информации или иной вредоносной активности, которая похожа на уже описанные мной ранее примеры с использованием NTA-решения для борьбы с утечками или обнаружения кампаний DNSpionage и Sea Turtle.

    image

    При наличии в вашей инфраструктуре решения Cisco ISE вы можете получить данные не только об узле, но и о пользователе, который нарушает требования политики безопасности. В этом случае вы можете более оперативно провести расследование инцидента и среагировать на него.

    image

    Также с помощью NTA-решения вы можете зафиксировать избыточное использование пропускной способности на том или иной интерфейсе вашего сетевого оборудования, в том числе и ответственного за предоставление удаленного доступа. Для этого достаточно запустить (а также настроить соответствующий триггер) отчет для нужных вам интерфейсов:

    image

    Решение Cisco Stealthwatch Enterprise, выбранное для демонстрации возможностей NTA, позволяет вам получить утилизацию по каждому интерфейсу:

    image

    в том числе и детали по ним, в том числе, устройства и пользователи, ответственные за использование излишней пропускной способности:

    image

    Вроде ничего сложного в этом сценарии нет и мне просто хотелось показать, насколько легко решение по анализу сетевых аномалий может быть настроено для мониторинга сегмента удаленного доступа и выявления различных аномалий и угроз, которые могут из него исходить. Ключевых идей в этом сценарии две. Во-первых, вы должны знать, какие узлы у вас работают удаленно, а какие располагаются внутри вашей корпоративной сети и какую роль они выполняют. Вообще знание того, что из себя представляет ваша сеть и что в ней является нормой является залогом успеха при внедрении решений класса NTA, ярким примером которых является Cisco Stealthwatch. Во-вторых, несмотря на то, что мы говорим о контроле узлов удаленного доступа, трафик с них должен где-то «приземляться» и это «где-то» обычно находится внутри корпоративной сети (кейс про мониторинг удаленного доступа в архитектуре Desktop-as-a-Service, DaaS мы рассмотрим отдельно), что требует особого внимания со стороны служб информационной безопасности.

    Дополнительная информация:


    Cisco
    Cisco – мировой лидер в области сетевых технологий

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

      0
      Кейсы для юзинга тулов анализа аномалий в нете: контроль аксеса дедиков
        +2
        Будь я помоложе, писал бы именно так
        0
        Кейсы — это старые чемоданы без ручки?
          0
          Почему старые? И почему без ручки?
            0

            Попробуйте заголовок переформулировать без англицизмов. Интересно прочитать как вы это можете сделать

              0
              Термин «кейс» уже вошел в русский язык достаточно прочно. «Кейс-ориентированное обучение» и т.п. Можно перевести как «сценарий», но так уж повелось, что термин «use case», который как раз и означает «сценарий использования» в среде безопасников, которые занимаются мониторингом, стал часто сокращаться до обычного «кейс»
                0

                Да не надо объяснять почему и как слово используется. Мне его смысл понятен. Его не использует сейчас только ленивый. Оно действительно прочно вошло.
                Но попробуйте просто написать сейчас тот же заголовок русскими словами. Может самому понравится.

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

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