Поделиться через

Системный журнал и общий формат событий (CEF) через соединители AMA для Microsoft Sentinel

  • Статья

Системный журнал с помощью AMA и общего формата событий (CEF) через соединители данных AMA для фильтров Microsoft Sentinel и приема сообщений системного журнала, включая сообщения в формате Common Event Format (CEF), с компьютеров Linux и из сетевых устройств и устройств безопасности. Эти соединители устанавливают агент Azure Monitor (AMA) на любом компьютере Linux, с которого требуется собирать сообщения системного журнала и (или) CEF. Этот компьютер может быть источником сообщений, или это может быть пересылка, которая собирает сообщения с других компьютеров, таких как сетевые или устройства безопасности. Соединитель отправляет инструкции агентов на основе определяемого вами правила сбора данных (DCR ). Контроллеры домена указывают системы для отслеживания и типов журналов или сообщений для сбора. Они определяют фильтры, применяемые к сообщениям до их приема, для повышения производительности и повышения эффективности запросов и анализа.

Системный журнал и CEF — это два распространенных формата для ведения журнала данных с разных устройств и приложений. Они помогают системным администраторам и аналитикам безопасности отслеживать и устранять неполадки сети и выявлять потенциальные угрозы или инциденты.

Что такое Системный журнал?

Системный журнал — это стандартный протокол для отправки и получения сообщений между различными устройствами или приложениями по сети. Изначально она была разработана для систем Unix, но теперь она широко поддерживается различными платформами и поставщиками. Сообщения системного журнала имеют предопределенную структуру, состоящую из приоритета, метки времени, имени узла, имени приложения, идентификатора процесса и текста сообщения. Сообщения системного журнала можно отправлять по протоколу UDP, TCP или TLS в зависимости от конфигурации и требований к безопасности.

Агент Azure Monitor поддерживает syslog RFCs 3164 и 5424.

Что такое общий формат событий (CEF)?

CEF или Общий формат событий — это нейтральный от поставщика формат для ведения журнала данных с сетевых и устройств безопасности, таких как брандмауэры, маршрутизаторы, решения обнаружения и реагирования, а также системы обнаружения вторжений, а также другие виды систем, таких как веб-серверы. Расширение Системного журнала было разработано специально для решений для управления сведениями о безопасности и событиями (SIEM). Сообщения CEF имеют стандартный заголовок, содержащий такие сведения, как поставщик устройства, продукт устройства, версия устройства, класс событий, серьезность события и идентификатор события. Сообщения CEF также имеют переменное число расширений, которые предоставляют дополнительные сведения о событии, таких как исходные и конечные IP-адреса, имя пользователя, имя файла или действие, выполняемое.

Коллекция сообщений Системного журнала и CEF с помощью AMA

На следующих схемах показана архитектура сбора сообщений Syslog и CEF в Microsoft Sentinel с помощью системного журнала с помощью AMA и общего формата событий (CEF) через соединители AMA .

На этой схеме показаны сообщения системного журнала, собираемые с одной отдельной виртуальной машины Linux, на которой установлен агент Azure Monitor (AMA).

Схема коллекции Syslog из одного источника.

Процесс приема данных с помощью агента Azure Monitor использует следующие компоненты и потоки данных:

  • Источники журналов — это различные виртуальные машины Linux в вашей среде, которые создают сообщения системного журнала. Эти сообщения собираются локальной управляющей программой системного журнала на TCP или UDP-порте 514 (или другом порту на ваш выбор).

  • Локальная управляющая программа системного журнала ( rsyslog либо syslog-ng) собирает сообщения журнала на TCP или UDP-порте 514 (или другом порту на ваш выбор). Затем управляющая программа отправляет эти журналы агенту Azure Monitor двумя способами в зависимости от версии AMA:

    • AMA версии 1.28.11 и более поздних версий получают журналы на TCP-порте 28330.
    • Более ранние версии AMA получают журналы через сокет домена Unix.

    Если вы хотите использовать порт, отличный от 514 для получения сообщений Syslog/CEF, убедитесь, что конфигурация порта в управляющей программе Системного журнала соответствует тому, что приложение создает сообщения.

  • Агент Azure Monitor, установленный на каждой виртуальной машине Linux, из которой требуется собирать сообщения системного журнала, путем настройки соединителя данных. Агент анализирует журналы и отправляет их в рабочую область Microsoft Sentinel (Log Analytics).

  • Рабочая область Microsoft Sentinel (Log Analytics): сообщения системного журнала, отправленные здесь, отображаются в таблице Системного журнала, где можно запрашивать журналы и выполнять аналитику для их обнаружения и реагирования на угрозы безопасности.

Процесс установки для сбора сообщений журнала

В Центре содержимого в Microsoft Sentinel установите соответствующее решение для системного журнала или общего формата событий. На этом шаге устанавливается соответствующие соединители данных Syslog через AMA или общий формат событий (CEF) через соединитель данных AMA. Дополнительные сведения см. в статье "Обнаружение и управление содержимым Microsoft Sentinel вне поля".

В процессе установки создайте правило сбора данных и установите агент Azure Monitor (AMA) в средство пересылки журналов. Выполните эти задачи с помощью портала Azure или Microsoft Defender или с помощью API приема журналов Azure Monitor.

  • При настройке соединителя данных для Microsoft Sentinel на портале Azure или Microsoft Defender можно создавать, управлять и удалять контроллеры домена на рабочую область. AMA устанавливается автоматически на виртуальных машинах, которые выбраны в конфигурации соединителя.

  • Кроме того, отправьте HTTP-запросы в API приема журналов. С помощью этой установки можно создавать, управлять и удалять контроллеры домена. Этот параметр является более гибким, чем портал. Например, с помощью API можно фильтровать по определенным уровням журнала. На портале Azure или Defender можно выбрать только минимальный уровень журнала. Недостатком использования этого метода является то, что перед созданием DCR необходимо вручную установить агент Azure Monitor в средстве пересылки журналов.

После создания DCR и AMA ЗАПУСТИТЕ сценарий установки на сервере пересылки журналов. Этот скрипт настраивает управляющая программа Системного журнала для прослушивания сообщений с других компьютеров и открытие необходимых локальных портов. Затем настройте устройства безопасности или устройства по мере необходимости.

Дополнительные сведения см. в следующих статьях:

Предотвращение дублирования данных

Использование одного и того же средства для сообщений Системного журнала и CEF может привести к дублированию данных между таблицами CommonSecurityLog и Syslog.

Чтобы избежать этого сценария, используйте один из следующих методов:

  • Если исходное устройство включает настройку целевого объекта: на каждом исходном компьютере, который отправляет журналы в средство пересылки журналов в формате CEF, измените файл конфигурации системного журнала, чтобы удалить средства, используемые для отправки сообщений CEF. Таким образом, объекты, отправленные в CEF, также не отправляются в Системном журнале. Убедитесь, что для каждого настраиваемого DCR используется соответствующее средство для CEF или Syslog соответственно.

    Чтобы просмотреть пример того, как упорядочить DCR для приема сообщений syslog и CEF из одного агента, перейдите к потокам Syslog и CEF в одном DCR.

  • Если изменение объекта для исходного устройства неприменимо: после создания DCR добавьте преобразование времени приема, чтобы отфильтровать сообщения CEF из потока Системного журнала, чтобы избежать дублирования. См. руководство по изменению правила сбора данных (DCR). Добавьте преобразование KQL, аналогичное следующему примеру:

    "transformKql": "  source\n    |  where ProcessName !contains \"CEF\"\n"

Следующие шаги

Настройка соединителей данных