Привет! Меня зовут Василий Жуковский, и я отвечаю за работу технической поддержки PT Network Attack Discovery (PT NAD) — системы поведенческого анализа трафика от Positive Technologies. Недавно коллеги из техпода PT Sandbox рассказали, какая работа проводится, пока вы ждете ответ на свое обращение. Вышло здорово, и я решил поддержать этот тренд. Сегодня расскажу, как мы работаем с обращениями и что «дарим» в дополнение к решению проблемы пользователя. За последние три года мы обработали более 3500 запросов, не считая вопросов в нашем телеграм-чате. Давайте рассмотрим пример одного такого обращения.

К нам обратились с запросом: ошибки в обработке трафика. И все, что предоставил пользователь, — вот такой скриншот.

Чтобы понять, что же произошло, нам потребуется проанализировать журналы и статистику работы продукта. Запрашиваем необходимые данные у клиента.

Когда мы провели первичный анализ, стало ясно, что в PT NAD подается примерно 2,5 Гбит/с трафика. Осталось убедиться, хватает ли ресурсов для обработки такого потока ????

Проверим, какой процессор установлен на сервере.

Проверим, хватит ли нам ОЗУ.

Смотрим, какие точки монтирования присутствуют и их объем.

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

Исходя из свободного места в разделе /pcaps, становится понятно, что для хранения копии сырого трафика его хватит примерно на три дня. Сырой трафик — это хорошо, но, чтобы он превратился в более полезный инструмент, его нужно индексировать (объединить все сессии).

Возвращаемся к документации и мысленно благодарим всех, кто принимает участие в написании великих инструментов. При скорости 2500 Мбит/с PT NAD запишет

метаданных трафика за один день. Из вывода df-h становится ясно, что у нас есть 25 ТБ под хранение данных, а значит, мы можем хранить трафик 20 дней.

Отлично, теперь заглянем в файлы настройки.

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

Что же, исправим это положение. Как мы видим, из конфигурационного файла трафик подается на портens5f2.Теперь давайте убедимся, поддерживает ли сетевая карта режим захвата пакетов DPDK. Для этого нам необходимо посмотреть файл ptdpictl devlist из набора журналов и найти сетевую карту, соответствующую указанному портуens5f2.

Отлично, режим поддерживается, а значит, механизм захвата можно переключить. Библиотека DPDK позволяет захватывать в PT NAD весь поступающий трафик со скоростью до 10 Гбит/c на один сетевой интерфейс. DPDK совместим с большинством сетевых карт и помогает унифицировать конфигурацию PT NAD.

Теперь можно заняться оптимизацией:

• В строке capture_if укажем интерфейс для захвата по его PCI-имени:capture_if: pci-3c-00-2

• В строке capture_channels укажем количество потоков для захвата:capture_channels: 1 Предполагая, что будем обрабатывать на пике менее 5 Гбит/с и менее 2 млн пакетов в секунду.

• В строке worker_threads укажем количество потоков обработки трафика: worker_threads: 14 Исходя из расчета 1 поток на 200 Мбит/с и учитывая, что на пике скорость может возрасти.

• В строке management_threads укажем количество потоков для обработки соединений: management_threads: 1 Предполагая, что общее количество активных соединений не будет превышать 5 млн.

Для применения настроек попросим пользователя выполнить перезапуск интерфейса с помощью команды sudo ptdpictl restart-net.

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

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

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

Оптимизация пошла на пользу, но и это еще не все — продолжим погружаться. Осталось понять, оптимально ли настроена база данных.

Мы видим, что в кластере присутствуют один master, один client и четыре ноды data. Так как Elasticsearch сохраняет метаданные трафика во фрагменты индекса, нужно рассчитать максимальное количество фрагментов, которое может быть создано. Размер каждого фрагмента не должен превышать 50 ГБ.

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

фрагментов (по четыре фрагмента на каждый узел данных).

Проведем оптимизацию:

• es_online_shards: 28

• es_store_days: 20 [количество дней для хранения данных]

Фиксируем, но не отправляем. Проверим, все ли параметры настроены оптимально.

Смотрим на параметр, отвечающий за получение обновлений правил и другого экспертного контента, и видим, что обновления выключены (updater.PTSecurity.gus.enabled: false).

Но мы же говорим про продукт сетевой безопасности, а правила обнаружения атак помогают эту безопасность обеспечить. Решительным действием возвращаем PT NAD способность получать новые пакеты экспертизы. Но было бы неправильным включить возможность загрузки обновлений, не настроив при этом автоматическое обновление базы знаний, поэтому: updater.PTSecurity.gus.enabled: true

Дополнительно можно использовать автоматическую загрузку сторонних правил Proofpoint ET Open. Для этого необходимо добавить следующую строку:updater.ETOpen.http.enabled: true

Наше дело предложить, а дальше решать вам ???? Стоит помнить, что сторонние правила обнаружения угроз, загруженные в PT NAD, могут создавать много ложноположительных срабатываний.

Дополнительно давайте проверим, установлена ли у клиента система мониторинга, которая помогает более удобно и оперативно проводить анализ работы продукта. Для этого необходимо заглянуть в файл dpkg -l из набора журналов и проверить установленные пакеты. Как мы видим, система мониторинга отсутствует. Обязательно порекомендуем настроить ее в соответствии с документацией.

Осталось собрать все наши рекомендации вместе и передать их клиенту.

Вы скажете: «Технические детали и разбор — это интересно, но как же цифры?» Они тоже будут!

Итак, анализ всех данных и подготовка рекомендаций заняли у нас около часа. Кажется, что долго? Посмотрите на это с другой стороны. По факту при обращении мы увидели продукт, который был установлен без какой-либо настройки в соответствии с документацией и возможностями сервера. Может ли PT NAD работать при таких условиях? Определенно. Будет ли он эффективен? Да. Покажет ли он максимальную эффективность? К сожалению, нет. А теперь представьте, что всего за час вы получили не только решение проблемы с ошибками, но и оптимальную конфигурацию PT NAD, которая будет выполнять свои функции на 100%.

Предложенные параметры позволяют использовать продукт с максимальной эффективностью, так сказать на все деньги. Например, мониторинг. Вроде мелочь, но, когда он есть, анализ проблемы с продуктом сокращается в разы. В рассмотренном примере мы проанализировали порядка 20 журналов и три конфигурационных файла, чтобы понять суть и причину запроса. А был бы мониторинг — время анализа сократилось бы в разы. Поменяли метод захвата трафика? Тоже мелочь, а по факту стабилизировали поток трафика и сессий, которые так нужны для обнаружения сложных сетевых угроз.

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

Спасибо за внимание! Надеюсь, вам было интересно заглянуть в внутреннюю кухню техподдержки PT NAD.