audit-agent

Описание встроенного модуля аудита Linux auditd

Модуль auditd в Linux — это системный демон, который перехватывает системные вызовы от приложений и пользователей, оценивает их по набору предопределенных правил и записывает срабатывания правил в централизованный журнала аудита системных событий, который может использоваться администраторами или сотрудниками службы безопасности для целей аудита, мониторинга системы и расследований.

События аудита включают в себя вход пользователей в систему, доступ к файлам, сетевые подключения и другие системные действия. Администратор безопасности составляет набор правил аудита, которые определяют, какие события следует регистрировать. Правила аудита позволяют сосредоточиться на определенных действиях или поведении, которые могут указывать на угрозы безопасности или нарушения политик. Конфигурация располагается в файле /etc/audit/audit.rules, редактирование правила можно настроить в соответствии с требованиями организации, дополняя файл в папке /etc/audit/audit.d/audit.rules.

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

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

Администраторы могут использовать для запроса журналов, созданных модулем auditd, такие встроенные инструменты Linux, как ausearch и aureport. Эти инструменты предоставляют мощные возможности поиска, позволяют пользователям фильтровать события на основе определенных критериев, таких как диапазоны дат, идентификаторы пользователей или типы событий. Это облегчает сотрудникам службы безопасности анализ собранных данных и принятие соответствующих мер в ответ на любые обнаруженные проблемы.

Описание плагина

Плагин auditd-agent устанавливает подписку в ядре Linux для получения событий аудита по мере их возникновения, что позволяет реагировать быстрее, чем сбор логов аудита с использованием опроса файла в файловом коллекторе.

Агент может быть как эксклюзивным клиентом ядра в режиме unicast и динамически управлять правилами, так и совместно управлять в режиме multicast.

Служба аудита Linux может отправлять несколько сообщений для одного проверяемого события. Например, в ответ на системный вызов rename ядро отправит восемь отдельных сообщений. Каждое сообщение описывает отдельный аспект происходящей активности: сам системный вызов, пути к файлам, текущий рабочий каталог, название процесса. Агент auditd объединит все данные из каждого сообщения в одно событие.

Сообщения для одного события могут чередоваться с сообщениями из другого события. Плагин буферизует сообщения, чтобы объединить связанные сообщения в одно событие, даже если они приходят с чередованием или не по порядку.

Так как плагин auditd-agent напрямую подписывается на события в ядре, не требуется запуск службы auditd.

Рекомендуется остановить auditd системы при включённом плагине KOMRAD auditd-agent, если это разрешают правила вашей организации:

Проверить, запущен ли системный модуль:

sudo service auditd status

Остановить системный модуль:

sudo service auditd stop

Отключить загрузку системного модуля на старте:

sudo chkconfig auditd off

Чтобы сберечь ресурсы процессора и диска, можно также остановить сбор событий auditd в журнал Journald:

sudo systemctl mask systemd-journald-audit.socket

Конфигурация плагина

Пример:

auditd-agent:
  resolve_ids: true
  failure_mode: silent
  backlog_limit: 8192
  rate_limit: 0
  include_raw_message: false
  include_warnings: false
  receive_all_messages: false
  backpressure_strategy: auto
  immutable: false
  # загрузка правил из файлов. Необходим режим 'socket_type: unicast'
  audit_rule_files: ['/etc/audit/audit.d/*.rules']
  audit_rules: |
    # Вещи, которые влияют на identity.
    -w /etc/group -p wa -k identity
    -w /etc/passwd -p wa -k identity
    -w /etc/gshadow -p wa -k identity
    -w /etc/shadow -p wa -k identity

    # Попытки несанкционированного доступа к файлам (безуспешные).
    -a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access
    -a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access
    -a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access
    -a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access

Описание параметров конфигурации:

• socket_type - необязательный параметр, управляет типом сокета, который будет использован для получения событий от ядра. Два варианта - unicast (одноадресная рассылка) и multicast (многоадресная рассылка).
  unicast следует использовать, когда коллектор является основным демоном пользовательского пространства для получения событий аудита и управления правилами. Только один процесс может получать события аудита через «одноадресное» unicast соединение, поэтому любые другие демоны должны быть остановлены (например, остановить auditd, как указано выше).
  multicast можно использовать в версиях ядра 3.16 и новее. Используя многоадресную рассылку multicast, плагин будет получать широковещательную рассылку событий аудита, которая не является эксклюзивной для одного процесса. Это идеально подходит для ситуаций, когда системный модуль auditd работает и управляет правилами. Если указана многоадресная рассылка, но версия ядра ниже 3.16, плагин автоматически вернется к одноадресной передаче. По умолчанию плагин будет использовать многоадресную рассылку, если версия ядра 3.16 или новее и правила не определены. В противном случае будет использоваться одноадресная передача unicast.

• immutable — логический (булевый) параметр, делает конфигурацию аудита неизменяемой, применим лишь совместно с socket_type: unicast, так как плагину необходимы эксклюзивные права, чтобы иметь возможность сделать конфигурацию неизменяемой.\

  ВАЖНО

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

• resolve_ids — логический (булевый) параметр, включает разрешение числовых идентификаторов пользователей UID и групп GID до их имён, по умолчанию включен — true.

• failure_mode — определяет поведение ядра при критических сбоях: ошибки при отправке событий от auditd, исчерпание лимита в очереди необработанных событий, нехватка памяти для обработки событий, либо превышение предела скорости.
  Варианты: silent («тихий»), log («журнал») или panic («паника»). В тихом режиме silent ошибки игнорируются, в режиме журналирования log заставляет ядро записывать контрольные сообщения, используя printk, чтобы они отображались в системном журнале ОС, а panic заставляет ядро паниковать, чтобы предотвратить использование машины. По умолчанию установлено значение silent («тихий»).

• backlog_limit — контролирует предел числа событий аудита, который может накапливать буфер в ядре ОС.

• rate_limit — устанавливает предел числа сообщений в секунду, доставляемых ядром. По умолчанию 0, что значит отключение лимитирования событий от ядра. При установке любого значения, отличного от 0, часть событий может теряться. Рекомендуется более тонко настраивать правила аудита, а не просто включать лимитирование потока событий.

• include_raw_message — включает сохранение оригинальной строчки события в поле ECS.Event.Original.

• include_warnings — включает сохранение ошибок парсинга и нормализации события аудита в поле ECS.Error.Message, по умолчанию false, отключено.

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

• audit_rules — строка, которая передаёт набор правил аудита, которые необходимо установить в ядро. Формат — одно правило на строку. Строки, начинающиеся с # считаются комментариями и не парсятся. Формат строки с правилом аналогичен формату, используемому утилитой Linux auditctl.

• audit_rule_files — перечисляет список файлов, из которых необходимо загрузить правила аудита, поддерживается маска вида имя*имя. Формат строки с правилом аналогичен формату, используемому утилитой Linux auditctl.

• backpressure_strategy — устанавливает стратегию противодействия обратному давлению со стороны ядра (т.е. ситуации, когда процесс не справляется с потоком событий), возможные значения:

1. auto (по умолчанию): будет использовать стратегию kernel, если она поддерживается версией ядра, иначе userspace
2. kernel: устанавливает backlog_wait_time в ядре равным 0. Это заставляет ядро удалять сообщения аудита, если очередь переполняется, требуется ядро версии не ниже 3.14
3. userspace: отбрасывает события в моменты избыточной нагрузки. Если не установлен rate_limit, устанавливается на 5000. Пользователи должны проверять установку и изменять опцию rate_limit в соответствии со своими потребностями
4. both: использует стратегии kernel и userspace одновременно
5. none: в период повышенной нагрузки плагин не меняет своё поведение, может нести риски задержки сообщений аудита в очереди на неопределённый срок

Правила аудита

Правила аудита - это то, где вы настраиваете проверяемые действия. Эти правила настраиваются либо как системные вызовы, либо как файлы, которые следует отслеживать. Например, вы можете отслеживать все системные вызовы "connect" или записи файловой системы в /etc/passwd.

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

Ядро вычисляет правила в том порядке, в котором они были определены, поэтому сначала размещайте наиболее активные правила, чтобы ускорить вычисление.

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

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