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

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

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

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

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

Агент мониторинга Azure (AMA) поддерживает сообщения системного журнала, отформатированные в соответствии с RFC 3164 (BSD Syslog) и RFC 5424 (IETF Syslog).

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

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

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

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

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

Схема сбора системного журнала из одного источника.

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

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

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

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

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

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

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

Примечание.

При приеме данных системного журнала с помощью средства пересылки журналов и агента мониторинга Azure (AMA) между полями и EventTime могут возникать TimeGenerated несоответствия.

  • TimeGenerated отражает время в формате UTC, когда сообщение системного журнала было обработано компьютером, на котором размещен сервер пересылки журналов или сборщик.
  • EventTime извлекается из заголовка системного журнала, который не содержит сведения о часовом поясе и преобразуется в utc с помощью смещения локального часового пояса сервера пересылки или сборщика.

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

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

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

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

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

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

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

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

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

Использование одного средства для сообщений системного журнала и 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"

Дальнейшие действия

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

  • Last updated on