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

Соединители данных Syslog через AMA и Common Event Format (CEF) через AMA для Microsoft Sentinel фильтруют и принимают сообщения Syslog, включая сообщения в формате Common Event Format (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-адреса, имя пользователя, имя файла или предпринятое действие.

Сбор сообщений Syslog и CEF с помощью AMA

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

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

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

В процессе приема данных с помощью агента мониторинга 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, где можно запрашивать журналы и выполнять аналитику для обнаружения угроз безопасности и реагирования на них.

Примечание.

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

  • 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 можно создавать, управлять и удалять DCR для каждой рабочей области отдельно. AMA устанавливается автоматически на виртуальных машинах, которые выбраны в конфигурации соединителя.

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

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

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

Исключение дублирования при приеме данных

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

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

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

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

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

    Примечание.

    Начиная с версии AMA 1.41, поле ProcessName может ненадёжно содержать значение "CEF" для сообщений от поставщиков, не соблюдающих формат заголовка syslog RFC 3164/RFC 5424. Чтобы убедиться, что сообщения CEF правильно фильтруются, проверьте оба ProcessName и SyslogMessage.

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

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

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

  • Last updated on