“”/
актуальные новости и полезные материалы в telegram канале
 
Вход
18 июля 2024

KATA
Защита периметра. Подключение источника

Цикл "Kaspersky Symphony XDR"
Введение
Рады приветствовать вас в 5 статье блока KATA из цикла статей о Symphony XDR на портале TS University!

Теперь, когда компоненты системы развернуты, приступим к подключению источников. И, прежде чем начать тестирование, рассмотрим интерфейс старшего сотрудника службы безопасности.
Настройка источников
Источники могут быть нескольких типов:
  • SPAN. Сырой трафик
  • ICAP. Веб-трафик
  • SMTP/POP3. Почтовый трафик
  • API. Сторонние системы
Мы рассмотрим первые 3 источника.
Интеграция по API достаточно специализирована и может быть по-разному осуществлена в зависимости от сторонней системы (хотя в её корне и лежит REST API). Если вас интересует именно такая интеграция, рекомендуем обратиться к документации:

Стоит отметить решения Kaspersky Secure Mail Gateway, Kaspersky Security для Linux Mail Server и Kaspersky Web Traffic Security, которые также могут выступать в качестве источников. Технически эти интеграции используют API KATA. Про настройку интеграции KSMG с KATA вы можете почитать в статье на нашем портале:

Посмотрим на схему целевой тестовой лаборатории:
Войдем под учетной записью с ролью «Администратор» и перейдем в раздел «Серверы Sensor».
Ранее здесь всё было некликабельно. А теперь, после подключения лицензии, мы можем нажать на название сервера и перейти к настройкам источников.

Первое, что мы можем настроить, — это максимальный размер проверяемого файла.
По умолчанию установлено значение в 100 мегабайт. Обычно этого достаточно, но если необходимо, то вы можете его переопределить.
SPAN 
Под SPAN мы будем подразумевать зеркалирование физических или виртуальных портов коммутатора. В информационной безопасности это является хорошим способом следить за тем, что происходит в сети без нарушения её работы.

Самым простым вариантом будет использование технологии Port Mirroring на физическом коммутаторе в ядре сети. Вы можете отзеркалить трафик с ваших LAN и WAN портов в отдельный порт, выделенный под зеркалированный трафик, и соединить его с портом сервера центрального узла KATA.

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

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

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

Перейдем к настройке. В нашем случае на стенде размещен виртуализированный центральный узел KATA, поэтому нам необходимо пробросить сырой трафик в виртуальный порт виртуальной машины. Мы не станем пробрасывать физический порт. Вместо этого средствами гипервизора мы пробросим сырой трафик с одной из виртуальных машин с ОС Windows Server на сервере виртуализации. Этого будет достаточно, чтобы продемонстрировать пример.

Теперь перейдём к пункту «обработка SPAN-трафика».
На данный момент мы можем увидеть 2 интерфейса. Первый — управляющий, а второй — как раз тот, что мы выделили для SPAN-трафика. Вы можете их определить по MAC-адресу или IP-адресу, если он назначен.

Переключим тумблер «проверка SPAN-трафика» на интерфейсе ens192. Нас попросят задать номер потока и процессора. Деление на потоки дает возможность передать один зеркалированный SPAN-трафик, используя 2 сетевых интерфейса. Данный функционал используется довольно редко, когда пропускной способности одного интерфейса недостаточно.

Выбор процессора позволяет распределить нагрузку. Мы поставим «Автоматически».
Нажмем кнопку «Применить» и подождем несколько минут. Далее создадим какую-нибудь сетевую активность на хосте, с которого зеркалируется трафик.

Например, давайте откроем наш официальный канал на YouTube и запустим видео. Если ничего не забыли настроить, то в разделе Мониторинг в карточке «Обработано» для источника SPAN мы увидим приходящий трафик.
Настройка SPAN-источника завершена.
ICAP
Для начала давайте разберемся, что такое ICAP.

ICAP (Internet Content Adaptation Protocol) — это протокол, который используется для передачи объектов от веб-прокси серверов к решениям, занимающимся фильтрацией трафика и получения вердикта фильтрации. Этот протокол позволяет достаточно просто интегрировать несколько решений друг с другом.
Особенно удобен данный протокол в случаях, когда нет возможности настраивать параметры веб-прокси напрямую через конфигурационные файлы. Пример такой интеграции — NGFW и потоковые антивирусы, веб-контент фильтры или песочницы.

Теперь введем 2 понятия:
  • ICAP-клиент — это система, которая работает непосредственно с исходным трафиком и извлекает из него объекты. Задача клиента передать извлеченный файл сторонней системе по протоколу ICAP и, если это указано в настройках, получить вердикт. На основании вердикта ICAP-клиент может применить правила к трафику. Например, в случае антивирусной проверки веб-страницы веб-прокси сервер может отдать пользователю страницу блокировки или разорвать соединение;
  • ICAP-сервер — это решение, которое принимает объекты, производит их обработку и, если это указано в настройках, выдает вердикт. ICAP-сервер работает только с объектами, а не с исходным трафиком. Объектами часто выступают ссылки и файлы из трафика. ICAP-сервера помимо объектов могут принимать от ICAP-клиентов связанную информацию. Обычно это имена пользователей и ip-адреса. ICAP-сервер может заниматься, в том числе, журналированием доступа пользователей к определенным ресурсам, веб-фильтрацией и пр.

В случае с KATA, основная задача интеграции по ICAP — это потоковый антивирус, анализ YARA правилами и песочница для объектов, извлеченных веб-шлюзом.

KATA поддерживает 3 режима интеграции по ICAP-протоколу:
  • Мониторинг. В этом режиме KATA занимается получением объектов, но вердикт ICAP-клиентам не выдает;
  • Стандартная проверка. Репутация файлов и URL-адресов проверяется в базе KSN. Файлы проверяются антивирусным движком, YARA-правилами и в песочнице Sandbox. Особенность данного режима в том, что на время проверки в песочнице файлы не блокируются. Это позволяет быстрее отдать клиенту файл, но создает потенциальный риск в случае, если файл окажется вредоносным по итогам проверки. Если файл всё же был признан вредоносным, то у офицера безопасности появится обнаружение с указанием деталей для принятия мер по устранению угрозы;
  • Усиленная проверка. Аналогична стандартной проверке, но файл на время проверки в песочнице задерживается. На это время пользователь не может его загрузить на компьютер. Пользователю в окне браузера показывается страница-заглушка. Браузер разрешит загрузку файла, как только он будет проверен и признан безопасным. В противном случае страница обновится и будет показана страница блокировки.

Страницы проверки и блокировки можно изменять на свое усмотрение, загрузив их в формате HTML в «Проверка трафика ICAP» в параметрах системы KATA.
Также здесь можно задать максимальное время проверки для усиленного режима, чтобы в случае, если система перегружена, пользователь спустя время всё равно смог загрузить файл. По умолчанию максимальное время ожидания — 10 минут.
Приступим к подключению источника. В качестве ICAP-клиента будет выступать сервер с ОС Ubuntu 22.04 с развернутой службой Squid 6.10. Сервер будет выступать в качестве веб-прокси сервера c SSL инспекцией. То есть весь веб трафик от пользователей будет проходить через прокси и расшифровываться сертификатом сервера. Для того чтобы на тестовом клиентском ПК в браузере не показывалось предупреждение о небезопасном соединении, сертификат прокси сервера внесен в «Доверенные корневые центры сертификации».

У Лаборатории Касперского на форуме размещены указания по настройки прокси-сервера Squid. Ими и воспользуемся.

На компьютере достаточно в Параметрах добавить в настройки прокси-сервера адрес и порт сервера Squid.

После внесения необходимых изменений в конфигурационный файл Squid в разделе Мониторинг карточки «Обработано» мы должны увидеть поступающий трафик.
Если вы столкнулись со сложностями при интеграции Squid и KATA, есть 4 журнала, которые могут пригодиться при устранении проблем:

  1. Журнал доступа Squid на веб прокси сервере: /var/log/squid/access.log. В нем указывается информация по тому, какие клиентские узлы и к какому ресурсу запрашивают доступ. Соответственно можно также посмотреть статус запроса;
  2. Журнал службы Squid на веб прокси сервере: /var/log/squid/cache.log. В нем ведется журнал состояния самой службы Squid;
  3. Журнал службы ICAP на веб прокси сервере: /var/log/squid/icap.log.
  4. Журнал службы ICAP на сервере KATA: /var/log/kaspersky/services/preprocessor_icap/preprocessor_icap.log. В него записываются все запросы от ICAP-клиентов и вердикт проверки в зависимости от режима.

Настройка источника ICAP завершена.
Почтовый трафик
Для того чтобы обрабатывать объекты, которые пользователи получают и посылают в почтовых сообщениях, нам необходимо получать копии. Копии сообщений мы можем получать двумя способами: по протоколу SMTP и протоколу POP3.

Рассмотрим обе интеграции:
  • SMTP — протокол передачи почты. В интеграции по SMTP KATA выступает в качестве почтового сервера. Почтовые сообщения передаются в KATA в виде скрытой копии (BCC), которая настраивается на почтовом сервере или на почтовом шлюзе. Такой вид интеграции достаточно прост и зачастую предпочтителен;
  • POP3 — протокол получения почты с удаленного сервера. При интеграции по POP3 KATA подключается к почтовому серверу в качестве почтового клиента и забирает почту из ящика. Такой вид интеграции удобен, если ваши почтовые службы располагаются у облачных провайдеров и у вас нет желания или возможности давать доступ снаружи к серверу KATA. В таком виде интеграции на почтовом сервере создается выделенный технический почтовый ящик под KATA. Вся почта пользователей дублируется в этот почтовый ящик. Периодически KATA выгружает скопившуюся почту в ящике. И в ящике она не сохраняется.

Начнем с интеграции по SMTP.

Включим её в параметрах нашего сенсора.
Рассмотрим настройки, которые мы можем указать при включении интеграции:

  • Домены назначения. Все домены, для которых разрешается прием почты. Поддерживается отрицание. К примеру, можно получать почту для доменов второго уровня, но исключить некоторые домены третьего;
  • Клиенты. Хосты или подсети, для которых разрешается отправка писем в KATA. Это могут быть почтовые шлюзы или почтовые сервера, тикет-системы (которые шлют почту) и прочие;
  • Ограничение по размеру сообщения. По умолчанию: 10 мегабайт (это ограничение можно убрать);
  • Режим TLS-безопасности клиента и Запрос клиентского TLS-сертификата. Данные настройки дополнительно повышают безопасность и надежность при получении сервером KATA писем. Дополнительную информацию по настройке этих режимов можно найти в интернете или в онлайн-справке вендора.
Интересная особенность в настройке: вы можете использовать значение «Все» (указывается в виде символа звезда «*») в Доменах назначения и Клиентах, но не одновременно. Вам необходимо указать конкретно хотя бы один из параметров.
Укажем в качестве Домена назначения «tss.lab», а в Клиент – «*».
Остальные параметры менять не будем. Не забывайте применить настройки.

Для работы SMTP-интеграции нам понадобится создать для KATA MX запись на DNS-сервере. Домен этой MX-записи может быть любой, это не так важно (мы укажем kata.tss.lab). FQND сервера KATA тоже укажем как kata.tss.lab. А почту, приходящую из интернета, будем перенаправлять на адрес: например, sbx@kata.tss.lab (имя ящика может быть любым).
В качестве почтового сервера мы будем использовать Microsoft Exchange Server c ip-адресом 10.10.30.30.

Создадим тестовый ящик kata_smtp@tss.lab и транспортное правило, добавляющее в скрытую копию сообщения адрес sbx@kata.tss.lab. В транспортном правиле указано, что оно должно применяться в том случае, если получатель — kata_smtp@tss.lab. Но вы можете применять его ко всем сообщениями или к конкретной группе пользователей.

Также можно использовать условия, когда получатель или отправитель находятся внутри или вне организации Exchange. Таким образом, можно делать копию только входящей или только исходящей почты.
Перейдем к интеграции POP3.
Также рассмотрим настройки, которые доступны при включении интеграции:
  • Почтовый сервер — это тот сервер, на котором находится почтовый ящик для сбора копий писем;
  • Порт. Обычно используется 110/TCP для небезопасного соединения и 995/TCP для безопасного шифрованного соединения;
  • Принимать каждые. Периодичность сбора почты из ящика в KATA;
  • Использовать TLS шифрование. Рекомендуемая настройка для предотвращения перехвата корреспонденции;
  • Имя пользователя, пароль. Учетные данные технического почтового ящика, в который собирается копия писем;
  • TLS-сертификат. Вы можете указать, необходимо ли доверять сертификату сервера, даже если он отсутствует или используется самоподписанный. Рекомендуемое значение — «Принимать только доверенный»;
  • Набор шифров. Алгоритмы шифрования, разрешенные при установке TLS-соединения. К пункту есть подсказка, в которой можно прочитать подробнее про эту настройку.
На почтовом сервере создадим ящик с именем kata_service_mailbox@tss.lab. В него будет собираться копии почты пользователей.
В процессе сбора почты по протоколу POP3 KATA удаляет письма из самого ящика. В этом есть плюс: архивный ящик не будет бесконечно расти в размерах, и вам не надо контролировать удаление писем из него. Но есть и минус: в случае если поток почты большой, то при выходе сервера KATA из строя ящик очень быстро может наполниться письмами. И перед интеграцией необходимо продумать о квоте почтового ящика и как следить за объемом писем в нем в реальном времени.

Обычно для того, чтобы наполнять ящик копиями писем, создается транспортное правило, идентичное тому, что мы создавали при интеграции по SMTP (за исключением адреса получателя скрытой копии). В нашем случае адрес получателя должен быть kata_service_mailbox@tss.lab. Таким образом, письма, пришедшие пользователям, будут автоматически копироваться и сохраняться в ящике kata_service_mailbox@tss.lab. В качестве почтового ящика пользователя будем использовать user_mailbox@tss.lab.

Транспортное правило будет выглядеть следующим образом:
В Microsoft Exchange служба POP3 отключена по умолчанию. Её необходимо запустить и установить автоматический запуск службы при запуске Windows.
На этом интеграция по POP3 завершена.
Интерфейс старшего сотрудника службы безопасности
Так же, как и в случае с интерфейсом администратора, первое, что нас встречает, — это панель мониторинга.
Здесь будет показываться статистика по обнаружениям. Виджеты можно менять: убирать, добавлять, менять местами. Статистику можно посмотреть за день, неделю или месяц. Можно включить показ статистики с учетом закрытых обнаружений.

Далее вкладка «Обнаружения».
Здесь будет располагаться список обнаружений со всех подключенных источников. По умолчанию показываются только обнаружения со статусом «Новое» и «В обработке». Закрытые обнаружения тоже можно увидеть (как и в случае с панелью мониторинга) если переключить тумблер в правом верхнем углу страницы.

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

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

Перейдем к следующему разделу «Пользовательские правила».

Оно состоит из 3 подразделов:
  • IDS
  • YARA
  • Sandbox
С подразделом Sandbox мы уже знакомились в интерфейсе администратора.

Он тут идентичен:
Перейдем к рассмотрению правил IDS.

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

Дополнительную информацию можно изучить в онлайн-справке.

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

Дополнительную информацию можно изучить в онлайн-справке.
Теперь перейдем в Хранилище.

Здесь мы можем загружать файлы для ручной проверки. Если, например, вы получили обнаружение в сторонней системе и извлекли файл, то можно его подгрузить сюда, и он будет проверен антивирусным движком, YARA-правилами и песочницей. И после анализа вы получите вердикт.
Далее Отчеты.

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

На основании шаблона можно получать отчеты за период времени, который требуется.
Посмотрим на раздел Серверы Sensor.
Как и в случае с интерфейсом администратора вы можете перейти к настройке локального сенсора. Отличие в том, что доступен только раздел SPAN и менять настройки в нем нельзя.
Зато можно выгрузить трафик в виде pcap-файла по заданным критериям и фильтрам. Для работы этой функции предварительно должна быть включена запись сырого трафика в настройках «Обработка SPAN-трафика» под учетной записью с ролью Администратор.
Перейдем к Параметрам.

Кратко пробежимся по ним:

  • Репутационная база KPSN. Здесь можно указать, заносить ли объекты, обнаруженные Sandbox, в статус недоверенных в KPSN. В таком случае все смежные системы, использующие KPSN, будут блокировать запуск и скачивание таких объектов. Что такое KPSN вы можете увидеть в предыдущей статье.
  • Уведомления.. Здесь настройки похожи на те, что мы видели в интерфейсе администратора, но помимо уведомлений о работе приложения, старший сотрудник службы безопасности может настраивать уведомления по обнаружениям. Однако, в отличие от администратора, он не может конфигурировать параметры почтового сервера.
  • Статус VIP. Новые обнаружения с VIP статусом видны только пользователю с ролью старшего сотрудника службы безопасности. При этом стоит отметить, что старший сотрудник может назначить обработку обнаружения пользователю с ролью «Сотрудник службы безопасности» и тогда обнаружение со статусом VIP будет видно и ему.
  • В этом разделе параметров можно назначать правила, по которым обнаружению будет присваиваться статус VIP. Критериями для правила могут быть IP-адрес, имя хоста и email. Так же список правил можно экспортировать и импортировать.
  • Исключения.
  • Можно задавать исключения объектов из проверки по хэшу файла, формату файла, маске URL, email-адресу получателя/отправителя, ip или подсети источника/назначения и агента пользователя.
  • IDS-исключения. Здесь ведется их список, и именно здесь можно убрать исключение. Назначение исключений осуществляется через раздел Обнаружения.
  • ICAP-исключения. Аналогично исключениям проверки здесь можно создать исключения для объектов ICAP создавая правила со следующими критериями: формат, агент пользователя, MD5 хэш, маска URL и ip или подсеть источника.
  • Серверы Sandbox. Идентичен параметру «Серверы Sandbox» в интерфейсе администратора, который мы рассматривали в предыдущей статье. Особенность этого параметра с ролью старшего сотрудника ИБ в том, что он не может подключать или отключать сервера, но может смотреть, какие доступны виртуальные машины и на каких серверах, а также задавать какие ОС будут использоваться при проверке, а какие нет.
  • Пароли к архивам. Идентичен параметру «Пароли к архивам» в интерфейсе администратора, который мы рассматривали в предыдущей статье.
  • Лицензия. Идентичен параметру «Лицензия» в интерфейсе администратора, который мы рассматривали в предыдущей статье (за исключением того, что старший сотрудник ИБ не может ничего менять, только просматривать).
Заключение
Итак, в этой статье цикла мы с вами рассмотрели различные источники, подключили их и посмотрели, как выглядит интерфейс старшего сотрудника службы безопасности.

В следующем материале блока мы начнем тестировать платформу в различных сценариях.

Оставайтесь с нами!