# Auditd

**auditd** — это демон для аудита в Linux, который позволяет отслеживать и регистрировать события, связанные с безопасностью системы. Он является частью **Linux Audit Framework** и предоставляет мощные возможности для мониторинга изменений в системе, таких как доступ к файлам, выполнение команд, входы пользователей и многое другое.

По факту сейчас является стандартным логированием на Unix-системах.

{% embed url="<https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/security_guide/chap-system_auditing#chap-system_auditing>" %}
Руководство по auditd
{% endembed %}

## Основные возможности auditd

* **Мониторинг системных вызовов (syscalls)**: auditd может отслеживать вызовы системных функций, таких как `open`, `execve`, `chmod` и других.
* **Отслеживание файловых операций**: Логирование доступа к файлам, изменения прав доступа, удаления файлов.
* **Гибкая настройка правил**: Возможность создания правил для отслеживания конкретных событий.
* **Централизованное логирование**: Логи могут быть отправлены на удаленный сервер для анализа.

***

## Установка и запуск auditd

* **Установка**:

```bash
sudo apt install auditd  # Для Debian/Ubuntu
sudo yum install audit   # Для CentOS/RHEL
```

* **Запуск и включение в автозагрузку**:

```bash
sudo systemctl start auditd
sudo systemctl enable auditd
```

***

## Конфигурация auditd

* **Основной конфигурационный файл**: `/etc/audit/auditd.conf`.
  * В этом файле настраиваются параметры демона, такие как:
    * `log_file` — путь к файлу логов.
    * `max_log_file` — максимальный размер файла логов.
    * `num_logs` — количество файлов логов для ротации.
    * `flush` — режим записи логов (например, `incremental` или `data`).
* **Пример конфигурации**:

```ini
log_file = /var/log/audit/audit.log
max_log_file = 50
num_logs = 5
flush = incremental
```

***

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

* Правила аудита определяют, какие события будут отслеживаться. Они настраиваются с помощью утилиты `auditctl` или в файле `/etc/audit/rules.d/audit.rules`.
* **Основные типы правил**:
  * **Контроль файлов и директорий**:

```bash
auditctl -w /etc/passwd -p wa -k passwd_changes
```

```
* `-w` — путь к файлу или директории.
* `-p` — типы операций (`r` — чтение, `w` — запись, `x` — выполнение, `a` — изменение атрибутов).
* `-k` — ключ (метка) для фильтрации логов.
```

* **Контроль системных вызовов**:

```bash
auditctl -a always,exit -F arch=b64 -S open -k file_access
```

```
* `-a` — действие (например, `always,exit` — отслеживать завершение вызова).
* `-F` — фильтр (например, `arch=b64` — 64-битная архитектура).
* `-S` — имя системного вызова (например, `open`).
* `-k` — ключ (метка).
```

* **Контроль пользовательских действий**:

```bash
auditctl -a always,exit -F arch=b64 -S execve -k command_execution
```

```
Это правило отслеживает выполнение команд.
```

* **Постоянные правила**:
  * Чтобы правила сохранялись после перезагрузки, их нужно добавить в файл `/etc/audit/rules.d/audit.rules`.

### Рекомендации по настройке auditd

На GitHub есть несколько репозиториев с конфигурациями для `auditd`, которые могут служить отправной точкой или примером для настройки собственной системы аудита. Вот некоторые из них:

* [**Neo23x0/auditd**](https://github.com/Neo23x0/auditd)**:** Предоставляет базовую конфигурацию `auditd`, которая работает "из коробки" на большинстве дистрибутивов Linux, подходит для большинства случаев использования, производит разумный объем данных журнала, охватывает важную для безопасности деятельность и легко читается. Дополнительно, есть gist с примером конфигурации.
* [**armor/auditd-config**](https://github.com/armor/auditd-config)**:** Репозиторий с лучшими практиками конфигурации для `auditd`.
* [**softasap/sa-secure-auditd**](https://github.com/softasap/sa-secure-auditd)**:** Содержит примеры использования и настройки `auditd`, включая примеры правил и конфигураций.
* [**deep-security/auditd-config**](https://github.com/deep-security/auditd-config)**:** Конфигурационный файл `auditd`, разработанный для оценки MITRE ATT\&CK.

{% hint style="info" %}
Для того, чтобы мониторинг был наиболее эффективным, а у вас оставалось как можно меньше белых пятен, рекомендуется строить конфиг по правилу белых списков:

Логировать по умолчанию всё, и точечно исключать из логирования системную легитимную активность.
{% endhint %}

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

Чтобы запустить утилиту для отслеживания системных вызовов в Linux, используйте инструмент **strace**. Он позволяет наблюдать за тем, какие системные вызовы выполняет программа во время своего выполнения. Для запуска программы с использованием strace выполните команду:

```
strace имя_программы
```

***

## Просмотр логов auditd

* Логи auditd хранятся в файле `/var/log/audit/audit.log`.
* Для просмотра логов можно использовать утилиту `ausearch` или `aureport`.
* **Пример использования `ausearch`**:

```bash
ausearch -k passwd_changes
```

```
Этот команда ищет логи, связанные с изменением файла `/etc/passwd` (по метке).
```

* **Пример использования `aureport`**:

```bash
aureport --summary
```

```
Этот команда выводит сводный отчет по событиям.
```

***

## Формат логов auditd

При использовании **auditd** для отслеживания событий, таких как запуск процесса, в лог может быть записано **несколько записей**, которые относятся к одному действию. Количество записей зависит от настроенных правил аудита и типа события.

***

При запуске процесса (например, с помощью команды `execve`) в лог auditd могут быть записаны следующие записи:

1. **SYSCALL**: Запись о системном вызове `execve`.
2. **PATH**: Записи о доступе к файлам, связанным с процессом (например, исполняемый файл, библиотеки).
3. **CWD**: Запись о текущей рабочей директории процесса.
4. **PROCTITLE**: Запись о командной строке процесса.

Таким образом, на одно действие (запуск процесса) может приходиться **от 3 до 10+ записей** в зависимости от сложности процесса и настроенных правил.

**Вот пример лога для запуска команды `ls`:**

```
type=SYSCALL msg=audit(1696941296.123:456): arch=c000003e syscall=59 success=yes exit=0 a0=7ffd12345678 a1=7ffd12345678 a2=7ffd12345678 a3=7ffd12345678 items=2 ppid=1234 pid=5678 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ls" exe="/usr/bin/ls" key="command_execution"
type=EXECVE msg=audit(1696941296.123:456): argc=1 a0="ls"
type=CWD msg=audit(1696941296.123:456): cwd="/home/user"
type=PATH msg=audit(1696941296.123:456): item=0 name="/usr/bin/ls" inode=123456 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1696941296.123:456): item=1 name="/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2" inode=654321 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PROCTITLE msg=audit(1696941296.123:456): proctitle=6C7300
```

**Что можно извлечь из этого лога**

1. Команда `ls` была выполнена от имени пользователя root (uid=0).
   * **type=SYSCALL**: Указывает, что это запись о системном вызове.
   * **syscall=59**: Номер системного вызова. 59 соответствует `execve` — выполнению программы.
   * **auid=1000**: Идентификатор пользователя, который инициировал сессию.
   * **uid=0, gid=0, euid=0, suid=0, fsuid=0, egid=0, sgid=0, fsgid=0**: Идентификаторы пользователя и группы (реальные и эффективные). Здесь все равны 0, что указывает на выполнение от имени root.
   * **ppid=1234**: PID родительского процесса.
   * **pid=5678**: PID текущего процесса.

{% hint style="info" %}
Часто можно столкнуться с `auid=4294967295`. Это число эквивалентно `0xFFFFFFFF`, что является максимальным значением для беззнакового целого числа (unsigned int). В контексте auditd оно интерпретируется как `-1`, что означает "не установлено" (unset), то есть значение ещё не определено. Такое часто происходит с процессами, которые инициализируются до запуска демона auditd.
{% endhint %}

2. Команда была запущена из каталога `/home/user`.

* **type=CWD**: Указывает, что это запись о текущем рабочем каталоге.
* **cwd="/home/user"**: Текущий рабочий каталог, из которого была запущена команда.

3. Исполняемый файл `ls` находится по пути `/usr/bin/ls`.
   * **type=PATH**: Указывает, что это запись о пути к файлу.
   * **item=0**: Первый элемент (исполняемый файл `ls`).
     * **name="/usr/bin/ls"**: Путь к исполняемому файлу.
4. Динамический загрузчик, используемый для выполнения команды, — `/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2`.
   * **type=PATH**: Указывает, что это запись о пути к файлу.
   * **item=1**: Второй элемент (динамический загрузчик `ld-linux-x86-64.so.2`).
     * **name="/lib/x86\_64-linux-gnu/ld-linux-x86-64.so.2"**: Путь к динамическому загрузчику.
5. Событие было успешно зарегистрировано и выполнено без ошибок.
   * **type=SYSCALL**: Указывает, что это запись о системном вызове.
   * **success=yes**: Успешное выполнение системного вызова.
   * **exit=0**: Код завершения (0 означает успешное выполнение).

***

Записи, относящиеся к одному действию, объединяются по **уникальному идентификатору события**, который находится в поле `msg`. Этот идентификатор имеет формат:

```
msg=audit(ВРЕМЕННАЯ_МЕТКА:ИДЕНТИФИКАТОР)
```

* **Временная метка**: Время события в формате Unix-времени (секунды и миллисекунды).
* **Идентификатор**: Уникальный номер события.

***

Утилита `ausearch` автоматически группирует записи по идентификатору события. Например:

```bash
ausearch -k command_execution
```

Вывод будет содержать все записи, связанные с одним действием, сгруппированные по `msg`.

***

{% hint style="info" %}
Множество записей для одного действия может затруднить анализ. Хороший агент SIEM, как и `ausearch` должен уметь объединять разные записи в одно событие, а не заставлять писать вам сложные фильтры, чтобы разобраться в происходящем.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://vasilisa-l.gitbook.io/blue-team-cookbook/unix/unix-audit/auditd.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
