Тема удаленного доступа сейчас на подъеме, но обычно при ее описанию речь идет либо о решениях, устанавливаемых на устройствах сотрудников (например, описанный вчера Cisco AnyConnect), либо о решениях, устанавливаемых на периметре. Такое впечатление, что именно эти два набора защитных средств позволяют полностью исключить угрозы со стороны удаленных пользователей, подключающихся к корпоративной или ведомственной инфраструктуре. В этой заметке я хотел бы рассмотреть применение средств класса NTA (Network Traffic Analysis) для мониторинга удаленного доступа.
Надо сразу отметить, что мониторинг удаленного доступа мало чем отличается от каких-то иных узлов. Например, в прошлой заметке, когда мы ловили кампанию DNSpionage и Sea Turtle, мы начинали с группирования DNS-серверов в группу, которую и ставили на контроль, а также которая служила для нас эталоном и появление любых узлов, выполняющих функции DNS-сервера, но не входящих в нужную группу, автоматически считалось бы аномалией. С удаленным доступом все тоже самое — сначала мы должны объединить в группу все внутренние IP-адреса удаленных пользователей, а также все узлы, к которым эти пользователи могут подключаться (например, RDP-прокси, терминальный сервер, сервер электронной почты, файловый сервер, рабочие места, к которым удаленно подключаются пользователи, или виртуалки, доступ к которым осуществляется по VDI, и т.п.).
В качестве иллюстрации мы будем использовать решение Cisco Stealthwatch Enterprise, в котором мы создаем группу «Remote VPN IP Pool».
Дальше мы просто анализируем всю активность, фиксируемую применительно к данной группе.
Обратите внимание, что система нам уже показывает 4 нарушения политик безопасности. Но мы сейчас посмотрим немного в другую сторону. Виджет «Top Applications» позволяет увидеть нам весь входящий и исходящий трафик, сгруппированный по типам приложений/протоколов.
Дальше мы можем углубляться на нужную глубину с целью получения деталей того, кто и с кем общается, в каком направлении и в каком объеме.
Например, вот так будет выглядеть результат анализа сетевого трафика по протоколу HTTP, связанного с группой удаленных узлов.
Дальше мы можем воспользоваться дашбордом Host Summary, который покажет активность по каждому из интересующих нас узлов:
Аналогичным образом мы можем отслеживать всю активность с узлами, входящими в группу, с которой будут взаимодействовать удаленные пользователи.
Обратите внимание, что в данном сценарии мы не пользовались описанной вчера возможностью, присущей Ciscco AnyConnect, а именно сбором данных об активности приложений на узле и передачи ее на Cisco Stealthwatch Enterprise. В этом случае у нас было бы еще больше информации по активности удаленных узлов.
Сгруппировав узлы, обеспечивающую работу удаленного доступа, мы можем применять к ним различные политики для анализа. Например, достаточно часто, несмотря на предварительное планирование, нам не хватает пропускной способности, из-за избыточного использования ресурсов, что снижает и производительность, и может потребовать увеличения ресурсов для удаленного доступа. А причина может быть как в некорректной настройке узлов удаленного доступа, так и в использовании на них неразрешенного ПО или иных злоупотреблений, в том числе и без ведома владельца удаленного компьютера.
Итак, как для этой задачи мы можем использовать решение класса NTA по анализу сетевых аномалий. Для интересующей нас группы узлов мы запускаем отчет Host Group Application Traffic.
По умолчанию мы видим вкладку с входящим и исходящим трафиком для выбранной группы узлов. На ней отображено, что за последние 4 часа у нас исходящий трафик преимущественно занят передачей файлов по P2P.
Дальше мы можем получить еще больше деталей по исходящему трафику:
Интересную статистику мы видим в результате — на первом месте по объему переданного трафика (17,7 ГБ) у нас находится приложение, которое передало столько данных по 53-му UDP-порту (это протокол DNS).
Дальше вы можете провести более глубокое расследование с целью изучения тех узлов, с которыми взаимодействовал интересующий вас узел.
Самое интересное в этой истории, конечно, заключается в том, что у нас пиринговое приложение использует DNS-протокол как транспорт для передачи данных, что может говорить об утечке информации или иной вредоносной активности, которая похожа на уже описанные мной ранее примеры с использованием NTA-решения для борьбы с утечками или обнаружения кампаний DNSpionage и Sea Turtle.
При наличии в вашей инфраструктуре решения Cisco ISE вы можете получить данные не только об узле, но и о пользователе, который нарушает требования политики безопасности. В этом случае вы можете более оперативно провести расследование инцидента и среагировать на него.
Также с помощью NTA-решения вы можете зафиксировать избыточное использование пропускной способности на том или иной интерфейсе вашего сетевого оборудования, в том числе и ответственного за предоставление удаленного доступа. Для этого достаточно запустить (а также настроить соответствующий триггер) отчет для нужных вам интерфейсов:
Решение Cisco Stealthwatch Enterprise, выбранное для демонстрации возможностей NTA, позволяет вам получить утилизацию по каждому интерфейсу:
в том числе и детали по ним, в том числе, устройства и пользователи, ответственные за использование излишней пропускной способности:
Вроде ничего сложного в этом сценарии нет и мне просто хотелось показать, насколько легко решение по анализу сетевых аномалий может быть настроено для мониторинга сегмента удаленного доступа и выявления различных аномалий и угроз, которые могут из него исходить. Ключевых идей в этом сценарии две. Во-первых, вы должны знать, какие узлы у вас работают удаленно, а какие располагаются внутри вашей корпоративной сети и какую роль они выполняют. Вообще знание того, что из себя представляет ваша сеть и что в ней является нормой является залогом успеха при внедрении решений класса NTA, ярким примером которых является Cisco Stealthwatch. Во-вторых, несмотря на то, что мы говорим о контроле узлов удаленного доступа, трафик с них должен где-то «приземляться» и это «где-то» обычно находится внутри корпоративной сети (кейс про мониторинг удаленного доступа в архитектуре Desktop-as-a-Service, DaaS мы рассмотрим отдельно), что требует особого внимания со стороны служб информационной безопасности.
Надо сразу отметить, что мониторинг удаленного доступа мало чем отличается от каких-то иных узлов. Например, в прошлой заметке, когда мы ловили кампанию DNSpionage и Sea Turtle, мы начинали с группирования DNS-серверов в группу, которую и ставили на контроль, а также которая служила для нас эталоном и появление любых узлов, выполняющих функции DNS-сервера, но не входящих в нужную группу, автоматически считалось бы аномалией. С удаленным доступом все тоже самое — сначала мы должны объединить в группу все внутренние IP-адреса удаленных пользователей, а также все узлы, к которым эти пользователи могут подключаться (например, RDP-прокси, терминальный сервер, сервер электронной почты, файловый сервер, рабочие места, к которым удаленно подключаются пользователи, или виртуалки, доступ к которым осуществляется по VDI, и т.п.).
В качестве иллюстрации мы будем использовать решение Cisco Stealthwatch Enterprise, в котором мы создаем группу «Remote VPN IP Pool».
Дальше мы просто анализируем всю активность, фиксируемую применительно к данной группе.
Обратите внимание, что система нам уже показывает 4 нарушения политик безопасности. Но мы сейчас посмотрим немного в другую сторону. Виджет «Top Applications» позволяет увидеть нам весь входящий и исходящий трафик, сгруппированный по типам приложений/протоколов.
Дальше мы можем углубляться на нужную глубину с целью получения деталей того, кто и с кем общается, в каком направлении и в каком объеме.
Например, вот так будет выглядеть результат анализа сетевого трафика по протоколу HTTP, связанного с группой удаленных узлов.
Дальше мы можем воспользоваться дашбордом Host Summary, который покажет активность по каждому из интересующих нас узлов:
- с кем узел взаимодействует
- применяемые политики мониторинга
- используемые хостом приложения и активность такого использования.
Аналогичным образом мы можем отслеживать всю активность с узлами, входящими в группу, с которой будут взаимодействовать удаленные пользователи.
Обратите внимание, что в данном сценарии мы не пользовались описанной вчера возможностью, присущей Ciscco AnyConnect, а именно сбором данных об активности приложений на узле и передачи ее на Cisco Stealthwatch Enterprise. В этом случае у нас было бы еще больше информации по активности удаленных узлов.
Сгруппировав узлы, обеспечивающую работу удаленного доступа, мы можем применять к ним различные политики для анализа. Например, достаточно часто, несмотря на предварительное планирование, нам не хватает пропускной способности, из-за избыточного использования ресурсов, что снижает и производительность, и может потребовать увеличения ресурсов для удаленного доступа. А причина может быть как в некорректной настройке узлов удаленного доступа, так и в использовании на них неразрешенного ПО или иных злоупотреблений, в том числе и без ведома владельца удаленного компьютера.
Итак, как для этой задачи мы можем использовать решение класса NTA по анализу сетевых аномалий. Для интересующей нас группы узлов мы запускаем отчет Host Group Application Traffic.
По умолчанию мы видим вкладку с входящим и исходящим трафиком для выбранной группы узлов. На ней отображено, что за последние 4 часа у нас исходящий трафик преимущественно занят передачей файлов по P2P.
Дальше мы можем получить еще больше деталей по исходящему трафику:
Интересную статистику мы видим в результате — на первом месте по объему переданного трафика (17,7 ГБ) у нас находится приложение, которое передало столько данных по 53-му UDP-порту (это протокол DNS).
Дальше вы можете провести более глубокое расследование с целью изучения тех узлов, с которыми взаимодействовал интересующий вас узел.
Самое интересное в этой истории, конечно, заключается в том, что у нас пиринговое приложение использует DNS-протокол как транспорт для передачи данных, что может говорить об утечке информации или иной вредоносной активности, которая похожа на уже описанные мной ранее примеры с использованием NTA-решения для борьбы с утечками или обнаружения кампаний DNSpionage и Sea Turtle.
При наличии в вашей инфраструктуре решения Cisco ISE вы можете получить данные не только об узле, но и о пользователе, который нарушает требования политики безопасности. В этом случае вы можете более оперативно провести расследование инцидента и среагировать на него.
Также с помощью NTA-решения вы можете зафиксировать избыточное использование пропускной способности на том или иной интерфейсе вашего сетевого оборудования, в том числе и ответственного за предоставление удаленного доступа. Для этого достаточно запустить (а также настроить соответствующий триггер) отчет для нужных вам интерфейсов:
Решение Cisco Stealthwatch Enterprise, выбранное для демонстрации возможностей NTA, позволяет вам получить утилизацию по каждому интерфейсу:
в том числе и детали по ним, в том числе, устройства и пользователи, ответственные за использование излишней пропускной способности:
Вроде ничего сложного в этом сценарии нет и мне просто хотелось показать, насколько легко решение по анализу сетевых аномалий может быть настроено для мониторинга сегмента удаленного доступа и выявления различных аномалий и угроз, которые могут из него исходить. Ключевых идей в этом сценарии две. Во-первых, вы должны знать, какие узлы у вас работают удаленно, а какие располагаются внутри вашей корпоративной сети и какую роль они выполняют. Вообще знание того, что из себя представляет ваша сеть и что в ней является нормой является залогом успеха при внедрении решений класса NTA, ярким примером которых является Cisco Stealthwatch. Во-вторых, несмотря на то, что мы говорим о контроле узлов удаленного доступа, трафик с них должен где-то «приземляться» и это «где-то» обычно находится внутри корпоративной сети (кейс про мониторинг удаленного доступа в архитектуре Desktop-as-a-Service, DaaS мы рассмотрим отдельно), что требует особого внимания со стороны служб информационной безопасности.
Дополнительная информация:
- Обнаружение утечек информации с помощью средств анализа сетевых аномалий
- Обнаружение кампании DNSpionage с помощью средств анализа сетевых аномалий
- Обнаружение распространения вредоносного кода с помощью средств анализа сетевых аномалий
- Обнаружение атак через плагины браузеров с помощью средств анализа сетевых аномалий
- Бесплатное предложение Cisco по организации защищенного удаленного доступа
- Описание решения для защищенного удаленного доступа Cisco AnyConnec
- Flow-протоколы как инструмент мониторинга безопасности внутренней сети
- Как Cisco мониторит безопасность в своей внутренней сети?