Использование датчика на основе eBPF для Microsoft Defender для конечной точки в Linux

Расширенный фильтр пакетов Беркли (eBPF) для Microsoft Defender для конечной точки в Linux предоставляет дополнительные данные о событиях для операционных систем Linux. eBPF помогает решить несколько классов проблем, обнаруженных поставщиком событий AuditD, и является полезным в областях производительности и стабильности системы.

В числе основных преимуществ можно назвать следующие:

• Снижение шума журнала, связанного с auditD на уровне всей системы
• Оптимизированные правила событий для всей системы в противном случае вызывают конфликт между приложениями
• Уменьшение накладных расходов на мониторинг событий файла (чтение и открытие файла)
• Улучшена пропускная способность частоты событий и уменьшена занимаемая память
• Оптимизированная производительность для определенных конфигураций

Как работает eBPF

При использовании eBPF события, ранее полученные от поставщика событий AuditD, теперь передаются из датчика eBPF. Это помогает обеспечить стабильность системы, повышает загрузку ЦП и памяти, а также снижает нагрузку на диск. eBPF помогает снизить вероятность конфликтов между приложениями, так как пользовательские правила не требуются. Данные, связанные с eBPF, регистрируются в файле /var/log/microsoft/mdatp/microsoft_defender_core.log.

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

Предварительные требования к системе

Датчик eBPF для Microsoft Defender для конечной точки в Linux поддерживается в следующих минимальных версиях дистрибутива и ядра:

Использование eBPF

Датчик eBPF автоматически включается для всех клиентов по умолчанию для версий агента и более поздних версий 101.23082.0006 . Чтобы использовать эту функцию, клиентам необходимо выполнить обновление до поддерживаемой версии. Если датчик eBPF включен в конечной точке, Defender для конечной точки в Linux обновляет supplementary_events_subsystem на ebpf.

Если вы хотите вручную отключить eBPF, можно выполнить следующую команду:

sudo mdatp config ebpf-supplementary-event-provider --value [enabled/disabled]

Вы также можете обновить файл mdatp_managed.json:

{
    "features": {
        "ebpfSupplementaryEventProvider": "disabled"
    }
}

Подробный пример json-файла — Настройка параметров для Microsoft Defender для конечной точки в Linux см. по ссылке.

Вы также можете проверка состояние eBPF (включен или отключен) в конечных точках Linux с помощью расширенной охоты на портале Microsoft Defender. Ниже приведены шаги.

1. Перейдите на портал Microsoft Defender и выполните вход.

2. В области навигации перейдите в раздел Охота>Расширенная охота.

3. В разделе Расширенная охота перейдите к Управление уязвимостями Defender.

4. Выполните следующий запрос: DeviceTvmInfoGathering.

5. В выходных данных в столбце Дополнительные поля выберите Показать больше, а затем найдите состояние EBPF: true.

Неизменяемый режим AuditD

Для клиентов, использующих AuditD в неизменяемом режиме, перезагрузка требуется после включения eBPF, чтобы очистить правила аудита, добавленные Microsoft Defender для конечной точки. Это требование является ограничением в неизменяемом режиме AuditD, который замораживает файл правил и запрещает редактирование или перезапись. Эта проблема устранена с помощью перезагрузки.

После перезагрузки выполните следующую команду, чтобы проверка, если правила аудита были очищены:

% sudo auditctl -l

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

1. Переключитесь в режим ebpf.
2. Удалите файл /etc/audit/rules.d/mdatp.rules.
3. Перезагрузите компьютер.

Устранение неполадок и диагностика

Состояние работоспособности агента можно проверка, выполнив команду работоспособностиmdatp. Убедитесь, что датчик eBPF для Defender для конечной точки в Linux поддерживается, проверив текущую версию ядра с помощью следующей командной строки:

uname -a

Известные проблемы

1. Включение eBPF в версии RHEL 8.1 с SAP может привести к панике ядра. Чтобы устранить эту проблему, можно выполнить одно из следующих действий:

   • Используйте версию дистрибутива выше RHEL 8.1.
   • Переключитесь в режим AuditD, если вам нужно использовать RHEL версии 8.1.

2. Использование Oracle Linux 8.8 с ядром версии 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 может привести к панике ядра. Чтобы устранить эту проблему, можно выполнить одно из следующих действий:

   • Используйте версию ядра выше или ниже 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 в Oracle Linux 8.8, если вы хотите использовать eBPF в качестве дополнительного поставщика подсистемы. Минимальная версия ядра для Oracle Linux — RHCK 3.10.0, а UEK Oracle Linux — 5.4.
   • Переключитесь в режим AuditD, если требуется использовать ту же версию ядра

sudo mdatp config  ebpf-supplementary-event-provider  --value disabled

Следующие два набора данных помогают проанализировать потенциальные проблемы и определить наиболее эффективные варианты их решения.

1. Соберите диагностический пакет из средства клиентского анализатора с помощью следующих инструкций: Устранение проблем с производительностью для Microsoft Defender для конечной точки в Linux.

2. Соберите пакет диагностики отладки, когда Defender для конечной точки использует большое значение ресурсов, используя следующие инструкции: Microsoft Defender для конечной точки в ресурсах Linux.

Устранение проблем с производительностью

Если вы видите увеличение потребления ресурсов Microsoft Defender в конечных точках, важно определить процесс, точку подключения или файлы, которые вызывают большую часть использования ЦП или памяти. Затем можно применить необходимые исключения. Если после применения возможных исключений wdavdaemon антивирусной программы (родительский процесс) по-прежнему потребляет ресурсы, используйте команду ebpf-statistics, чтобы получить первое число системных вызовов:

sudo mdatp diagnostic  ebpf-statistics

Output
Monitor 20 seconds
Top file paths:
/var/log/microsoft/mdatp/microsoft_defender.log : 10
/var/log/microsoft/mdatp/rotated/microsoft_defender.log00001 : 2
/var/log/microsoft/mdatp/rotated/microsoft_defender.log : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374993 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374991 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374989 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374987 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374985 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374983 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374981 : 1

Top initiator paths:
/usr/bin/stress-ng : 50000
/opt/microsoft/mdatp/sbin/wdavdaemon : 13

Top syscall ids:
82 : 1699333
90 : 10
87 : 3

В предыдущих выходных данных видно, что stress-ng является главным процессом, генерирующим большое количество событий и может привести к проблемам с производительностью. Скорее всего, stress-ng создает системный вызов с идентификатором 82. Вы можете создать запрос в корпорации Майкрософт, чтобы исключить этот процесс. В будущем в рамках предстоящих улучшений у вас будет больше контроля за применением таких исключений в конце.

Исключения, применяемые к AuditD, не могут быть перенесены или скопированы в eBPF. Распространенные проблемы, такие как шумные журналы, паника ядра, шумные системные вызовы, уже учитываются внутренне eBPF. Если вы хотите добавить дополнительные исключения, обратитесь в корпорацию Майкрософт, чтобы применить необходимые исключения.

Вопросы и ответы. Переход на eBPF

1. Почему следует рассмотреть возможность перехода на eBPF?

Расширенный фильтр пакетов Беркли (eBPF) для Microsoft Defender для конечной точки в Linux служит эффективной альтернативой AuditD и решает различные проблемы, связанные с поставщиком событий AuditD, обеспечивая при этом значительные преимущества с точки зрения производительности и стабильности системы. Некоторые из ключевых преимуществ:

• Производительность: eBPF значительно повышает производительность за счет снижения затрат на системные ресурсы по сравнению с AuditD.

• Эффективность ресурсов: eBPF использует меньше ресурсов, что помогает поддерживать стабильность системы даже в условиях высокой нагрузки.

• Масштабируемость: архитектура eBPF более масштабируема, что делает ее лучшим выбором для сред с растущими или сложными рабочими нагрузками.

• Современная технология: eBPF представляет собой современную, перспективную технологию, которая соответствует будущим разработкам ядра Linux, обеспечивая лучшую долгосрочную поддержку.

2. Как продолжить использовать AuditD?

Если вы предпочитаете продолжать использовать AuditD, выполните следующие действия:

• Поддерживаемые версии. Вы можете оставаться в Defender для конечной точки в Linux версии 101.24072.0000, которая будет поддерживать AuditD в течение срока действия сборки, который составляет около девяти месяцев. Это обеспечивает достаточный период перехода для планирования перехода на eBPF. Дату истечения срока действия можно проверить, выполнив команду mdatp health на сервере Linux.

• план Long-Term. Хотя вы можете оставаться на сборке, мы рекомендуем запланировать переход на 101.24072.0000 eBPF в течение этого периода времени, чтобы вы могли воспользоваться преимуществами последних улучшений безопасности и производительности, а также получить постоянную поддержку.

При этом мы рекомендуем спланировать переход к использованию eBPF в качестве основного поставщика событий.

3. Что происходит, если eBPF не поддерживается в некоторых сценариях?

В случаях, когда eBPF не поддерживается:

• Netlink Fallback: система возвращается к использованию поставщика событий Netlink. Хотя Netlink продолжает записывать события процесса (например, exec, exit, fork, gidили tid), она не поддерживает события, связанные с файловой системой (например, , renameunlink) или события сокета.

• Влияние. Рабочие нагрузки не будут нарушены, но вы можете пропустить определенные события, связанные с файлами и сокетами, которые eBPF в противном случае будет записывать.

4. Как управлять исключениями с помощью обновленных версий?

Ниже приведены некоторые распространенные причины для размещения исключений для AuditD.

• Производительность, так как некоторые системные вызовы или процесс создают много шума

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

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

В случае с eBPF первые два варианта использования являются кандидатами для миграции. Журналы больше не являются проблемой с eBPF. Для первых двух вариантов использования можно выбрать один из следующих вариантов:

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

• Глобальные исключения. В обновленных версиях Defender для конечной точки в Linux исключениями можно управлять с помощью глобальных исключений. Глобальные исключения применяются как к антивирусной программе, так и к EDR и могут быть настроены с помощью управляемого json в настоящее время. Дополнительные сведения см. в статье Настройка и проверка исключений Microsoft Defender для конечной точки в Linux.

5. Что делать в случае возникновения проблем?

• Обратитесь в службу поддержки. Если во время или после перехода на eBPF возникли проблемы, обратитесь за помощью в службу технической поддержки. Мы стремимся обеспечить плавный переход и доступны для решения любых проблем, с которыми вы можете столкнуться.

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

См. также

• Устранение проблем с производительностью Microsoft Defender для конечной точки в Linux
• Microsoft Defender для конечной точки ресурсов Linux