Тема удаленного доступа сейчас на подъеме, но обычно при ее описанию речь идет либо о решениях, устанавливаемых на устройствах сотрудников (например, описанный вчера 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 мы рассмотрим отдельно), что требует особого внимания со стороны служб информационной безопасности.

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


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