Аномалии под контролем: всё о пользовательских правилах профилирования в PT NAD

В системе PT NAD, начиная с версии 12.0, появились Пользовательские Правила Профилирования (далее ППП).

Этот инструмент позволяет обучать правила на реальном сетевом трафике и формировать его профиль, а затем детектировать аномалии, выбивающиеся из этого профиля.

Более подробно с интерфейсом, настройками и администрированием системы поведенческого анализа сетевого трафика от Positive Technologies вы можете познакомиться в курсе PT NAD Getting Started.

С момента релиза механизм ППП не раз дорабатывался и совершенствовался.

В версии 12.4 (актуальной на момент написания статьи) появилась возможность при обучении разделять дневной и ночной трафик, что увеличивает точность обнаружения сетевых аномалий.

Мы протестировали работу ППП на нашем стенде в рамках различных сценариев и решили описать наш опыт и наши результаты в этой статье.

В нашем материале вы найдете:

Идея протестировать ППП родилась в наших головах достаточно давно, и в течение прошлого года мы сделали несколько подходов к данному снаряду.

Но каждый раз мы сталкивались с суровой действительностью: правила просто не обучались, всплывали ошибки «Недостаточно узлов» или «Недостаточный объем данных». И как бы много трафика мы не генерировали на нашем стенде, проблема оставалась.

В открытом доступе есть памятка от Positive Technologies и описание на справочном портале, но мы, к сожалению, не нашли там ответов на все наши вопросы.

К примеру: «Какое минимальное количество узлов необходимо для обучения правила?», «На какое максимальное количество кластеров разбиваются узлы?», «Как обрабатываются узлы, трафика от которых вообще не было на момент обучения?». И на наш самый главный вопрос: «Почему у нас на стенде правила не обучаются?».

Со всеми этими и другими вопросами мы обратились к специалистам Positive Technologies и теперь делимся тем, что нам удалось выяснить, а также тем, что получилось сделать на нашем стенде.

Большое спасибо Кириллу Шипулину, руководителю группы обнаружения атак PT ESC, который нам очень сильно помог во всем этом разобраться.

Начнем немного издалека.

PT NAD относится к решениям класса NTA, и как любая порядочная NTA-система он обладает комплексом различных методов анализа сетевого трафика:

• сигнатурным
• поведенческим (в том числе с применением машинного обучения)
• статистическим

За последние два в продукте отвечают правила для активностей.

Есть правила для активностей «из коробки» от команды специалистов из экспертного центра PT ESC. Они периодически обновляются и дополняются.

Но есть также возможность самостоятельно создавать пользовательские правила для активностей. До версии 12.0 (и появления ППП) такие правила назывались «Уведомления по фильтру», и название это говорит само за себя.

На созданный фильтр можно «навесить» простое условие срабатывания: если количество сессий или объем трафика за определенный период больше/меньше некоторого значения, то в ленте активностей появляется соответствующее уведомление (также можно настроить отправку уведомлений по электронной почте).

Пример создания/настройки уведомления по фильтру:

Пример настроенного уведомления по фильтру:

Строго говоря, уведомления по фильтру тогда не относились к правилам для активностей, хотя по своей сути ими являлись, пусть и очень упрощенными.

С появлением ППП ситуация изменилась. Название «уведомления по фильтру» ушло, и появились пользовательские правила для активностей. Механизм создания этих правил остался тот же, но теперь появилась возможность настроить обучение правила — и вот из обычного пользовательского правила для активностей мы получаем ППП.

Механизм обучения помогает решать сразу несколько проблем, которые нельзя было решить уведомлениями по фильтру:

1. Автоматическое определение границ срабатывания правила. В уведомлениях по фильтру эти значения приходилось задавать вручную. Это требует дополнительного времени и компетенций от оператора. ППП же определяет эти границы автоматически на основе имеющегося трафика.
2. Раздельный подход. Уведомления по фильтру работают достаточно просто: считают количество сессий или объем трафика по фильтру и проверяют, был ли преодолен установленный порог. Они не учитывают разный уровень активности различных узлов, а смотрят на их суммарную активность.

Это ограничение можно обойти, создавая отдельные фильтры и правила для каждого отдельного узла. Но поддерживать сотни, тысячи, а то и десятки тысяч правил — сомнительное удовольствие. Все их можно заменить одним ППП, которое при обучении разбивает все узлы на кластеры (максимум — три кластера) согласно их сетевой активности. Для каждого кластера определяются свои пороги срабатывания, и затем они назначаются всем узлам в кластере. Таким образом, у каждого узла есть свои границы, и как только его сетевая активность за них выходит, то правило срабатывает.

При DDoS-атаке, как правило, генерируются подключения с огромного количества различных узлов, соответственно резко увеличивается количество различных клиентов, обращающихся к нашим серверам.

Поэтому в качестве отслеживаемого параметра выберем количество уникальных отправителей, а в качестве объектов отслеживания выберем серверы.

• Осталось выбрать чувствительность.

Чувствительность правила определяет, во сколько раз порог срабатывания будет выше среднего значения, определенного во время обучения. Низкая чувствительность  — в 100 раз, средняя — в 10 раз, высокая — в 2 раза.

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

• Опционально можно добавить дополнительную информацию, которая будет отображаться в карточке активности при срабатывании правила. Например, нам может быть интересно, а в каких странах преимущественно находятся клиенты/боты, атакующие наши сервера. 

• Также опционально можно добавить описание и рекомендации.

• Правило создано. Хотя радоваться еще рано: нужно дождаться завершения обучения правила.

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

Например, если правило обучается 14 дней, а метаданные хранятся только за последние 10 дней, то правило завершит обучение только через 4 дня. Если обучение завершилось успешно, то в карточке правила для активности можно будет посмотреть определенные пороги. Вот теперь уже точно успех!

Создаваемое правило:

Результаты обучения:

Эксфильтрация данных

С помощью ППП можно отслеживать аномально большие объемы передачи данных между узлами. Такие аномалии могут сигнализировать об эксфильтрации данных, особенно если подключение происходит между локальным хостом и внешним узлом.

Глобально, существует два возможных сценария:

1. Инициатором соединения является внешний узел. В этом сценарии с нашего узла просто выкачивают данные.
2. Инициатором соединения является локальный узел. С помощью различных техник и эксплуатации уязвимостей злоумышленники могут заставить наш локальный узел подключиться к внешнему узлу и загрузить на него данные.

Под каждый из сценариев нам потребуется отдельный фильтр и, соответственно, отдельное правило:

1. В первом сценарии наш локальный узел выступает в роли сервера, поэтому мы фиксируем превышение по входящему трафику.
2. А во втором сценарии все наоборот, поэтому отслеживаем превышение исходящего трафика.

Правило для сценария 1

Правило для сценария 2

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

В карточках активности можно увидеть график, иллюстрирующий причину срабатывания. Красным цветом отражен порог, полученный во время обучения. Этот порог относится именно к данному узлу и уже учитывает мультипликатор чувствительности правила. Серым цветом показана активность данного узла: показатели отслеживаемого параметра.

Срабатывание происходит, когда серый график поднимается выше красной линии.

Обнаруженная аномалия в сценарии 1

Обнаруженная аномалия в сценарии 2

HTTPS-DDoS
Как правило, DDoS-атаки связаны с резким увеличением количества подключений и/или объемом трафика (Low&Slow-атаки в расчет не берем). Также они часто проводятся с помощью огромных ботнетов, насчитывающих сотни тысяч устройств, а самые крупные из обнаруженных сетей ботов насчитывают миллионы устройств.

Поэтому кажется довольно логичным отслеживать аномалии по этим трем параметрам: количество сессий, объем трафика и количество уникальных клиентов.

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

Остальные же правила делаются аналогично с использованием того же самого фильтра — нужно только заменить отслеживаемый параметр на «количество сессий» и «объем общего трафика».

Правило по сессиям

Правило по клиентам

Далее сгенерировали HTTPS-флуд и получили сработки наших правил (для генерации использовали утилиту D-DoS).

Сработка правила по сессиям

Сработка правила по объему

Сработка правила по клиентам

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

Для этого у нас в инфраструктуре есть гипервизор с виртуальными рабочими местами, к которым пользователи подключаются по RDP. Доступ из внешней сети к нашим ВМ обеспечивается с помощью RA VPN. В такой схеме очень бы хотелось отслеживать аномалии в RDP-трафике, исходящем от VPN-клиентов. Возросшие объемы передаваемых данных или количество сессий могут говорить о возможных нарушениях безопасности.

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

В нашем примере 192.168.1.0/24 — подсеть VPN-клиентов, а 10.0.2.0/24 — подсеть VM, а созданный фильтр выбирает все RDP-подключения к VM, прошедшие через VPN-соединение.

Правило для активности

При обучении правила в стандартный профиль трафика попадали единичные RDP-сессии от клиентов к ВМ. В рамках теста мы сгенирировали RDP-сессию с передачей файла. Обученное правило обнаружило аномально большие объемы переданных данных в рамках RDP-сессии.

В дальнейшем при работе с данным инцидентом по IP-адресам можно определить, кто и куда подключался, по журналам событий определить действия пользователей на ВМ в обозначенный период времени, обнаружить передачу файла через буфер обмена, разобраться в ситуации.

Сработка правила:

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

Все неочевидные механики, подводные камни, на которые мы наткнулись, находятся здесь. Если у вас возник вопрос о ППП и в предыдущих главах вы не нашли на него ответа, то, вероятно, он будет здесь. По крайней мере, мы очень на это надеемся.

Необходимые для обучения условия

Первые наши попытки обучить ППП заканчивались ошибками о недостаточном количестве узлов или недостаточном объеме трафика. Хорошо, принято. А сколько их (узлов или объёма) нужно?

В минимальном варианте для обучения правила необходимо не менее четырех отслеживаемых объектов, и каждый из этих объектов должен проявить активность хотя бы в двух разных часовых промежутках за выбранный период обучения.

Если немного упростить, то выглядит это примерно так: PT NAD раз в час проверяет трафик по фильтру правила за последний час, и по результатам проверки он делает записи в таблицу со столбцами: «Отслеживаемый объект», «Значение отслеживаемого параметра», «Время».

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

Соответственно, если в качестве объектов отслеживания выбраны пары «клиент-сервер», то может быть достаточно и трех узлов, так как они могут составить целых шесть таких пар. Но также может не хватить и ста, и тысячи, и любого другого количества узлов, если они не относятся к объектам отслеживания. Например, куча различных клиентов подключаются к двум-трем серверам. Если в качестве объектов отслеживания выбраны серверы, то правило не обучится, так как их нужно минимум четыре штуки.

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

В таком случае стоит проверить, а есть ли у ваших узлов свои карточки. Если в качестве объекта отслеживания выбран «клиент», «сервер» или «клиент или сервер», то при обучении будут учитываться только сессии, в которых у объекта отслеживания есть собственная карточка узла. Для объектов отслеживания «пара клиент-сервер» и "вся сеть" это ограничение не действует, учитываются все сессии, попадающие под фильтр правила.

Сессии vs Уникальные сессии

В качестве отслеживаемого параметра среди прочих вариантов можно выбрать «количество сессий» или «количество уникальных сессий». В чем отличие? Какими параметрами определяется уникальность сессии?

Есть широко употребимый в сетевом оборудовании 5-tuple (src ip, dst ip, src port, dst port, proto), с помощью которого идентифицируются различные сессии.

В PT NAD для идентификации используется лишь его часть — только IP-адреса источника и получателя, т. е. «количество уникальных сессий» — количество различных пар «клиент-сервер».

О времени

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

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

При этом отсчет времени для проверки срабатываний для каждого правила начинается отдельно — с момента завершения обучения. Например, если правило завершило обучение в 13:38, то оно будет проводить проверки на превышение порога каждую 38-ю минуту каждого часа.

Время окончания периода обучения:

Время срабатывания правила:

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

Период переобучения правила (сравнить даты и время со скриншотом)

Новый трафик
А что будет, если в трафике появится объект отслеживания, которого не было в период обучения правила?

Например, правило обучено контролировать объемы SNMP-трафика в сети, и вдруг SNMP-менеджер стал опрашивать устройство, к которому ранее запросы не отправлял. Какие пороги к будут применяться к данной активности?

Тут можно предположить две более-менее разумные версии:

1. Объектам, не проявлявшим никакой активности во время обучения, присваивается порог равный нулю. Если такая активность появится, то правило сработает при любом значении отслеживаемого параметра (количество сессий, объем данных и т. д.).
2. Объекты, не проявлявшие никакой активности во время обучения, попадают в низкоактивный кластер, и им присваиваются соответствующие пороги. Поэтому при появлении такой активности срабатывание произойдет, только если она превысит данный порог.

Каждый подход обладает своими преимуществами и недостатками.

В PT NAD же используется именно второй вариант.

Механизм ППП в PT NAD — важная составляющая инструментария для проведения поведенческого анализа, заложенного в продукте. Он позволяет без особых усилий подстроить параметры обнаружения под каждую отдельную сетевую инфраструктуру и под каждый отдельный профиль трафика.

По нашим наблюдениям, данный инструмент не пользуется большой популярностью. Вероятно, одна из проблем — недостаточная освещенность и объясненность механизма ППП.

Это большое упущение, и этой статьей мы хотели сделать его более понятным и привлечь к нему побольше внимания.