# Логгирование

##### **Демоны логгирования**

WAF между логгером и фаером.

<table border="1" id="bkmrk-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D1%8B%D0%B5-rsyslog%2C-j" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>системные</td><td>rsyslog, journalctl</td></tr><tr><td>ИБ</td><td>auditd</td></tr><tr><td>WAF</td><td>modsecurity</td></tr></tbody></table>

##### **Системное логгирование**

Есть rsyslog и journalctl. journalctl постепенно заменяет rsyslog.

**Journalctl**

<table border="1" id="bkmrk-sudo-journalctl-%D0%9F%D1%80%D0%BE%D1%81" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>sudo journalctl</td><td>Просмотреть системный журнал</td></tr><tr><td>sudo journalctl -u ssh</td><td>Логи конкретной службы</td></tr><tr><td>sudo journalctl -f</td><td>Последние логи (как tail -f) </td></tr><tr><td>sudo journalctl -p err</td><td>Только ошибки</td></tr></tbody></table>

Journalctl по умолчанию сохраняет логи в ОП

**Rsyslog**

Rsyslog нужен, если:

- нужны обычные текстовые файлы /var/log/auth.log, /var/log/syslog;
- необходима ротацию логов через logrotate;
- нужно отправлять логи на внешний syslog-сервер (например, в SIEM).

Установка:

```
sudo apt install rsyslog
sudo systemctl enable --now rsyslog
```

Типы логов, настраивается.

<div class="table-scroll" id="bkmrk-%D0%9D%D0%B0%D0%B7%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%B6%D1%83%D1%80%D0%BD%D0%B0%D0%BB%D0%B0-%D0%A0%D0%B0%D1%81"><table align="center" border="1" cellpadding="1" cellspacing="1" style="width: 94.6429%; height: 301.766px;"><thead><tr style="height: 29.7969px;"><th style="width: 44.8363%; height: 29.7969px;">Название журнала</th><th style="width: 55.1637%; height: 29.7969px;">Расположение</th></tr></thead><tbody><tr style="height: 29.7969px;"><td style="width: 44.8363%; height: 29.7969px;">Аутентификация

</td><td style="width: 55.1637%; height: 29.7969px;">/var/log/auth.log</td></tr><tr style="height: 29.7969px;"><td style="width: 44.8363%; height: 29.7969px;">Ядро

</td><td style="width: 55.1637%; height: 29.7969px;">/var/log/kern.log</td></tr><tr style="height: 29.7969px;"><td style="width: 44.8363%; height: 29.7969px;">Демоны

</td><td style="width: 55.1637%; height: 29.7969px;">/var/log/daemon.log</td></tr><tr style="height: 29.7969px;"><td style="width: 44.8363%; height: 29.7969px;">Запуск

</td><td style="width: 55.1637%; height: 29.7969px;">/var/log/boot.log</td></tr><tr style="height: 46.5938px;"><td style="width: 44.8363%; height: 46.5938px;">Обновления

</td><td style="width: 55.1637%; height: 46.5938px;">/var/log/apt/history.log  
/var/log/dpkg.log</td></tr><tr style="height: 29.7969px;"><td style="width: 44.8363%; height: 29.7969px;">Cron

</td><td style="width: 55.1637%; height: 29.7969px;">/var/log/cron.log</td></tr><tr style="height: 29.7969px;"><td style="width: 44.8363%; height: 29.7969px;">Драйверы</td><td style="width: 55.1637%; height: 29.7969px;">/var/log/dmesg</td></tr></tbody></table>

</div>Размещение настроечных файлов

<table border="1" id="bkmrk-%2Fetc%2Frsyslog.conf-%D0%9E%D1%81" style="border-collapse: collapse; width: 100%; height: 331.75px;"><colgroup><col style="width: 25.0359%;"></col><col style="width: 74.9641%;"></col></colgroup><tbody><tr style="height: 46.5938px;"><td style="height: 46.5938px;">/etc/rsyslog.conf</td><td style="height: 46.5938px;">Основной файл настроек. Дополнительные файлы настроек подключаются в алфавитном порядке из /etc/rsyslog.d/\*.conf</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">/etc/rsyslog.d/50-default.conf</td><td style="height: 29.7969px;">Создается при установке. Базовые правила. Можно комментировать. Например ```
auth,authpriv.*         /var/log/auth.log
*.*;auth,authpriv.none  -/var/log/syslog
mail.*                  -/var/log/mail.log
cron.*                  -/var/log/cron.log
```

</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Рекомендованные файлы</td><td style="height: 29.7969px;">  
</td></tr><tr style="height: 82.9844px;"><td style="height: 82.9844px;">10-base.conf</td><td style="height: 82.9844px;">Базовые глобальные настройки ```
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
```

</td></tr><tr style="height: 82.9844px;"><td style="height: 82.9844px;">20-remote.conf</td><td style="height: 82.9844px;">Отправка логов на удалённый сервер ```
*.* @@syslog.example.com:514
```

</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">30-ssh.conf</td><td style="height: 29.7969px;">Логи от sshd ```
if ($programname == 'sshd' or $programname == 'sudo') then /var/log/security.log
& stop
```

</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">40-sudo.conf</td><td style="height: 29.7969px;">Логи sudo ```
if ($programname == 'sudo') then /var/log/sudo.log
```

</td></tr><tr><td>99-local.conf</td><td>Локальные мелкие правки, фильтры, формат вывода</td></tr></tbody></table>

**Структура логов:** timestamp hostname program identifier log level message content. Можно добавлять хост, с которого было отправлено сообщение.

**Типы событий:**

- kernel: загрузка модулей, аппаратные ошибки,
- authentication: попытки входа, изменения паролей
- service and daemon: работа системных служб и демонов. Запуск служб, ошибки и предупреждения
- network: подключение сетевых интерфейсов, обнаружение сетевых атак, изменения настроек сети
- system: общая системная информация о работе операционной системы. Запуск системы, события загрузки, ошибки файловых систем.
- logging: события журналирования. Создание и ротация журналов, ошибки записи в журналы.

**Конфигурация:** /etc/rsyslog.conf (/etc/syslog.conf). Каждая строка в формате &lt;фильтр&gt; &lt;действие&gt;. Фильтр определяет, какие сообщения должны быть обработаны, а действие определяет, что делать с этими сообщениями (например, записать их в определенный файл журнала). Пример конфигурации syslog:

```
# Маркировать сообщения ядра, которые требуют прямого вывода в файл /dev/console
kern.warning;*.err;authpriv.none;mail.crit       /dev/console

# Записывать все сообщения уровня emergency и выше в файл /var/log/emergency.log
*.emerg                         /var/log/emergency.log

# Записывать все сообщения уровня info и выше в файл /var/log/messages
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# Записывать все сообщения уровня notice и выше в файл /var/log/messages
*.notice                        /var/log/messages

# Записывать все сообщения уровня warning и выше в файл /var/log/messages
*.warn                          /var/log/messages

# Записывать все сообщения уровня error и выше в файл /var/log/errors.log
*.err                           /var/log/errors.log

# Записывать все сообщения уровня crit и выше в файл /var/log/critical.log
*.crit                          /var/log/critical.log

# Записывать все сообщения уровня alert и выше в файл /var/log/alert.log
*.alert                         /var/log/alert.log

# Записывать все сообщения уровня debug и выше в файл /var/log/debug.log
*.debug                         /var/log/debug.log

# Записывать все сообщения от локальных7 в файл /var/log/local7.log
local7.*                        /var/log/local7.log
```

Для изменения формата сообщений изменяем файл sudo nano /etc/rsyslog.conf

```
$template RFC3164fmt,"<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg%\n" #добавляем шаблон
auth,authpriv.*                 /var/log/auth.log;RFC3164fmt #привязываем шаблон к лог файлу
```

Приоритет syslog считается по формуле facility \* 8 + severity. Facility имеет заданные значения, и определяет к какому типу относится событие. Например, facility #0 относится к событиям ядра, а #4 - к событиям систем безопасности.

Severity отвечает за уровень критичности событий, где 0 это максимум(emergency), а уровень 7 - малоинформативные данные, используемые для отладки(debug).

В нашем примере число 38 получается за счет facility 4 и severity 6 (info).

**Журнал аутентификации**

/var/log/auth.log Содержит информацию об аутентификации пользователей, включая входы в систему, попытки неудачной аутентификации и другие аутентификационные события.

Типы событий в журнале auth.log

**Успешная аутентификация** (Successful Authentication). Это может быть вход через SSH, консоль, графический интерфейс и т. д.

```
Feb 11 14:23:45 server sshd[1234]: Accepted password for user123 from 192.168.1.100 port 12345 ssh2
```

**Неудачная аутентификация** (Failed Authentication). Это может быть вызвано неправильным паролем, недействительным пользователем и т. д.

```
Feb 11 14:30:10 server sshd[1234]: Failed password for invaliduser from 192.168.1.50 port 54321 ssh2
```

**Изменение пароля** (Password Changes). Это позволяет отслеживать изменения паролей и управлять безопасностью.

```
Feb 11 15:45:32 server passwd[5678]: password for user123 has been changed
```

**Изменение параметров аутентификации** (Authentication Configuration Changes).

```
Feb 11 16:12:20 server login[9876]: PAM (login) session opened for user123 by (uid=0)
```

**Запуск или остановка служб аутентификации** (Start/Stop of Authentication Services).

```
Feb 11 17:00:05 server systemd: Starting OpenSSH server daemon...
```

**События, связанные с аутентификацией.** Проблемы с файлами авторизации, недоступность источников аутентификации, ...

```
Feb 11 18:30:15 server su: pam_unix(su:session): session opened for user456 by user123(uid=1000)
```

**Журнал ядра**

/var/log/kern.log Содержит сообщения ядра Linux, такие как сообщения об ошибках, предупреждения и другую важную информацию о работе ядра.

Типы событий

**Сообщения ядра** (Kernel Messages). Основные сообщения. Загрузка ядра, проблемах с аппаратным обеспечением, ошибках файловых систем, сетевых событиях, а также другие системные события, связанные с работой ядра.

```
Feb 11 08:30:15 server kernel: [    0.000000] Linux version 5.10.0-14-generic (buildd@lcy01-amd64-017) (gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #15-Ubuntu SMP Fri Dec 31 14:49:08 UTC 2021 (Ubuntu 5.10.0-14.15-generic 5.10.21)
```

**Сообщения о загрузке и выгрузке модулей ядра** (Kernel Module Loading and Unloading). Полезно для отслеживания загрузки различных драйверов и модулей ядра.

```
Feb 11 08:31:45 server kernel: [    3.141592] Module 'nvidia-drm' is loaded.
```

**Сообщения об ошибках ввода-вывода** (I/O Errors). Если возникают проблемы с вводом-выводом, такие как ошибки чтения или записи на диске, это может быть отражено в kern.log. Помогает отслеживать проблемы с дисками и файловыми системами.

```
Feb 11 09:12:20 server kernel: [  405.837234] ata1: EH complete
```

**Сообщения об ошибках памяти** (Memory Errors). Например ошибка ECC (Error-Correcting Code) или ошибка доступа к памяти.

```
Feb 11 09:55:10 server kernel: [ 1025.556789] EDAC MC0: 1 CE error on CPU0 memory controller (channel 0 /channel 1 = 0x1/0x0): 0x0000 (corrected)
```

**Сообщения о загрузке и выгрузке ядра** (Kernel Boot and Shutdown Messages). Включает сообщения о запуске служб и драйверов. Это полезно для отслеживания процесса загрузки и выявления проблем.

```
Feb 11 10:00:05 server kernel: [    0.000000] Initializing cgroup subsys cpuset
```

**Другие системные сообщения ядра** (Other Kernel System Messages). В kern.log также могут записываться другие системные сообщения, связанные с работой ядра, такие как события управления питанием, управления процессором и т.д.  
Feb 11 10:15:30 server kernel: \[ 765.320123\] ACPI: Battery Slot \[BAT0\] (battery present)

**Журнал демонов**

/var/log/daemon.log Сообщения системных служб и демонов, таких как сервисы SSH, FTP, DHCP и другие.

Типы событий

**Запуск и остановка демонов** (Daemon Start and Stop).

```
Feb 11 08:30:15 server systemd[1]: Started OpenSSH server daemon.
```

**Сообщения об ошибках служб** (Service Error Messages). Могут содержать информацию о проблемах с конфигурацией, недоступности ресурсов и других критических ситуациях.

```
Feb 11 09:45:20 server apache2[1234]: [error] (28)No space left on device: Cannot create SSLMutex
```

**Информационные сообщения** (Informational Messages). Содержат отчеты о выполненных действиях, успешных операциях и других системных событиях.

```
Feb 11 10:00:05 server cron[5678]: (CRON) INFO (Running @reboot jobs)
```

**Сообщения об ошибках в работе демонов** (Daemon Error Messages). Содержат информацию о сбоях, падениях и других аномальных ситуациях, происходящих в процессе выполнения служб.

```
Feb 11 11:15:30 server postfix[9876]: fatal: parameter "smtpd_sender_login_maps": file too large
```

**Сообщения о подключении и отключении к демонам** (Connection and Disconnection Messages). Отслеживают активность пользователя или других систем, пытающихся взаимодействовать с демоном.

```
Feb 11 12:30:45 server sshd[2345]: Accepted publickey for user123 from 192.168.1.100 port 12345 ssh2: RSA SHA256:abc123
```

**Другие системные сообщения** (Other System Messages). Не подпадающие под вышеперечисленные категории, но относящиеся к работе демонов и служб в системе. Это может включать сообщения о перезагрузках, обновлениях и других системных событиях.

```
Feb 11 13:45:10 server systemd[1]: Reloading.
```

**Журнал запуска**

/var/log/boot.log Содержит информацию о процессе загрузки системы, включая загрузку ядра и инициализацию устройств.

Типы событий

**Сообщения ядра** (Kernel Messages). Сообщения, генерируемые ядром Linux во время загрузки. Информация об оборудовании, обнаруженном ядром, настройка ядра, загрузка драйверов и другие системные события, происходящие во время загрузки.

```
[    0.000000] Linux version 5.4.0-91-generic (buildd@lgw01-amd64-035) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #102-Ubuntu SMP Fri Aug 13 23:50:30 UTC 2021 (Ubuntu 5.4.0-91.102-generic 5.4.143)
```

**Сообщения об инициализации системных служб** (Service Initialization Messages). Запуск системных служб и демонов, которые запускаются во время загрузки операционной системы.

```
[    4.105167] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
```

**Сообщения об ошибке загрузки** (Boot Error Messages).

```
[FAILED] Failed to start Network Time Synchronization.
```

**Информация о загрузочных скриптах и конфигурации** (Boot Scripts and Configuration Information). Выполнение загрузочных скриптов, настройках загрузчика и других параметрах конфигурации, применяемых при загрузке системы.

```
[    0.820671] ACPI: Core revision 20200326
```

**Сообщения об успешном завершении загрузки** (Boot Completion Messages). В конце файла boot.log обычно содержится информация о завершении процесса загрузки. Это может включать сообщения об успешном запуске всех требуемых служб и демонов.

```
[    5.091481] systemd[1]: Started Daily apt download activities.
```

**Другие системные сообщения** (Other System Messages). Например, изменения параметров ядра или настройках безопасности.

```
[    6.220215] random: crng init done
```

**Журнал обновлений**

APT (Advanced Package Tool), основной лог: /var/log/apt/ Файл журнала: /var/log/apt/history.log Старые логи обновления: /var/log/apt/term.log

**Структура записи:**

<table border="1" id="bkmrk-start-date-commandli" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 37.2025%;"></col><col style="width: 62.9167%;"></col></colgroup><tbody><tr><td>Start-Date</td><td>  
</td></tr><tr><td>Commandline:</td><td>Commandline: apt install some-package

Commandline: apt remove some-package

Commandline: apt upgrade

Commandline: apt-get autoremove

</td></tr><tr><td>Requested-By</td><td>Requested-By: user123 (1000)</td></tr><tr><td>&lt;Type of operation&gt;</td><td>Install: some-package:amd64 (version)

Remove: some-package:amd64 (version),

Upgrade: some-package:amd64 (old-version -&gt; new-version),

</td></tr><tr><td>End-Date</td><td>  
</td></tr></tbody></table>

Пример установки пакета:

```
Start-Date: 2023-08-15  15:30:45
Commandline: apt install some-package
Requested-By: user123 (1000)
Install: some-package:amd64 (version), another-package:amd64 (version),
End-Date: 2023-08-15  15:31:10
```

DPKG (Debian Package Manager)

Пример dpkg.log:

```
2024-02-10 15:21:05 status installed firefox:amd64 100.0.0-0ubuntu1
2024-02-10 15:21:05 status installed firefox-locale-en:amd64 100.0.0-0ubuntu1
```

Запись в логе содержит статус установки, времени и дате операции, версии и архитектуре установленных пакетов.

Журнал установки: /var/log/dpkg.log

Каждая запись в этом файле содержит дату и время операции (например, 2023-08-15 15:38:55), за которыми следует описание операции и подробности о пакете. Например, "installed" указывает на установку пакета, "remove" на удаление, "upgrade" на обновление, "configure" на настройку, а "status" отображает текущее состояние пакета. Далее указывается имя пакета, его архитектура (например, amd64), его версия и новая версия (если применимо). В случае ошибок установки или зависимостей также выводятся соответствующие сообщения об ошибках. Пример ошибки:

```
2023-08-15 15:38:55 configure some-package:amd64 version <none>
dpkg: dependency problems prevent configuration of some-package:
some-package depends on another-package (>= required-version); however:
Package another-package is not installed.
```

YUM (Yellowdog Updater Modified) и DNF (Dandified YUM) (Fedora, CentOS и др.)

Основной лог: /var/log/yum.log

Каждая запись начинается со времени лога - например, Oct 05 18:00:19. После временной метки указывается действие, например, "Installed" для установки пакета, "Erased" для удаления и т. д. Затем идет имя пакета, его версия и, если применимо, старая версия (для обновлений). В случае ошибки указывается сообщение об ошибке.

Pacman, используемый (Arch Linux)

Основной лог: /var/log/pacman.log

В каждой записи \[YYYY-MM-DD HH:MM\] обозначает дату и время операции. После этого указывается действие, такое как "installed" для установки пакета, "removed" для удаления и т. д. Затем идет имя пакета, его версия и, если применимо, старая версия (для обновлений). В случае ошибок указывается сообщение об ошибке.

**Журнал cron**

/var/log/cron.log Запланированные задания, успешные и неудачные выполнения, сообщения или ошибки, связанные с выполнением этих заданий.

```
Feb 10 15:00:01 DEVICE_NAME CRON[1234]: (root) CMD (/usr/bin/php /path/to/script.php)
```

**Журнал драйверов**

/var/log/dmesg Сообщения, сгенерированные ядром во время загрузки системы, информация о оборудовании и драйверах.

```
[    0.000000] Linux version 5.4.0-91-generic (buildd@lcy01-amd64-016) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #102-Ubuntu SMP Fri Nov 5 16:31:28 UTC 2021 (Ubuntu 5.4.0-91.102-generic 5.4.154)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-91-generic root=UUID=12345678-1234-1234-1234-1234567890ab ro quiet splash
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Hygon HygonGenuine
[    0.000000]   Centaur CentaurHauls
[    0.000000]   zhaoxin   Shanghai
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
...
[    1.234567] sd 0:0:0:0: [sda] Attached SCSI disk
[    1.345678] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[    1.456789] random: crng init done
[    1.567890] random: 7 urandom warning(s) missed due to ratelimiting
```

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

##### **ИБ аудит**

auditd — демон аудита, используется для отслеживания и регистрации действий в системе (запуск процессов, доступ к файлам и директориям, изменения конфигурации). Записывает обычно в */var/log/audit/*. Основные файлы, используемые auditd:

- **audit.log** — основной журнал аудита. Подробная информация о событиях (время, тип, идентификатор процесса, действие, выполненное пользователем, и другие детали).
- **audit.log.\[N\]** — это архивные файлы аудита, которые содержат старые записи аудита. Например, audit.log.1

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

```
```bash
type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ls" exe="/bin/ls" key="audit-wazuh-r"
```<button class="copy-code-btn st-button_style_none copy-code-btn__code-block" title="Скопировать код" type="button"><svg fill="none" height="24" viewbox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg"><path d="M19.2 3H10.2C9.2073 3 8.4 3.8073 8.4 4.8V8.4H4.8C3.8073 8.4 3 9.2073 3 10.2V19.2C3 20.1927 
                      3.8073 21 4.8 21H13.8C14.7927 21 15.6 20.1927 15.6 19.2V15.6H19.2C20.1927 15.6 21 14.7927 21 13.8V4.8C21 3.8073 
                      20.1927 3 19.2 3ZM4.8 19.2V10.2H13.8L13.8018 19.2H4.8ZM19.2 13.8H15.6V10.2C15.6 9.2073 14.7927 8.4 13.8 8.4H10.2V4.8H19.2V13.8Z" fill="#777777"></path></svg>
                  </button>
```

<div class="table-scroll" id="bkmrk-%D0%9F%D0%BE%D0%BB%D0%B5-%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-type-%D0%A2"><table border="1" cellpadding="1" cellspacing="1" style="width: 94.7619%;"><thead><tr><th style="width: 24.6106%;">Поле</th><th style="width: 75.3894%;">Описание</th></tr></thead><tbody><tr><td style="width: 24.6106%;">type</td><td style="width: 75.3894%;">Тип события аудита, например, SYSCALL, CWD, EXECVE, SOCKET, и т. д.</td></tr><tr><td style="width: 24.6106%;">msg</td><td style="width: 75.3894%;">Общее сообщение аудита</td></tr><tr><td style="width: 24.6106%;">audit(timestamp:serial)</td><td style="width: 75.3894%;">Временная метка и серийный номер события аудита</td></tr><tr><td style="width: 24.6106%;">arch</td><td style="width: 75.3894%;">Архитектура процессора</td></tr><tr><td style="width: 24.6106%;">syscall</td><td style="width: 75.3894%;">Имя системного вызова, связанного с событием</td></tr><tr><td style="width: 24.6106%;">success</td><td style="width: 75.3894%;">Успешность выполнения системного вызова</td></tr><tr><td style="width: 24.6106%;">exit</td><td style="width: 75.3894%;">Код завершения системного вызова</td></tr><tr><td style="width: 24.6106%;">a0-a3  
 </td><td style="width: 75.3894%;">Регистры системного вызова</td></tr><tr><td style="width: 24.6106%;">items</td><td style="width: 75.3894%;">Количество элементов в событии аудита.</td></tr><tr><td style="width: 24.6106%;">ppid</td><td style="width: 75.3894%;">Идентификатор родительского процесса</td></tr><tr><td style="width: 24.6106%;">pid</td><td style="width: 75.3894%;">Идентификатор процесса</td></tr><tr><td style="width: 24.6106%;">auid</td><td style="width: 75.3894%;">Идентификатор аудита пользователя.</td></tr><tr><td style="width: 24.6106%;">uid</td><td style="width: 75.3894%;">Идентификатор пользователя.</td></tr><tr><td style="width: 24.6106%;">gid</td><td style="width: 75.3894%;">Идентификатор группы.</td></tr><tr><td style="width: 24.6106%;">euid/suid/fsuid</td><td style="width: 75.3894%;">Эффективный, фактический и файловый идентификаторы пользователя.</td></tr><tr><td style="width: 24.6106%;">egid/sgid/fsgid</td><td style="width: 75.3894%;">Эффективный, фактический и файловый идентификаторы группы.</td></tr><tr><td style="width: 24.6106%;">tty  
 </td><td style="width: 75.3894%;">Терминал, связанный с процессом</td></tr><tr><td style="width: 24.6106%;">ses</td><td style="width: 75.3894%;">Идентификатор сеанса аудита</td></tr><tr><td style="width: 24.6106%;">comm</td><td style="width: 75.3894%;">Имя исполняемого файла</td></tr><tr><td style="width: 24.6106%;">exe</td><td style="width: 75.3894%;">Путь к исполняемому файлу</td></tr><tr><td style="width: 24.6106%;">key</td><td style="width: 75.3894%;">Ключ, связанный с событием аудита</td></tr></tbody></table>

</div>Это общий формат, и поля могут варьироваться в зависимости от типа события и конфигурации auditd.

**Типы событий auditd**

**SYSCALL**: системные вызовы, которые выполняются в системе, такие как открытие файлов, чтение и запись данных, создание процессов и многое другое.

```
type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ls" exe="/bin/ls" key="audit-wazuh-r"
```

Лог показывает успешное (success=yes) выполнение системного вызова (syscall=2), который в данном случае может быть open(), поскольку syscall=2 обычно связан с открытием файлов. Процесс с pid=29943, запущенный пользователем с auid=1000, выполняет команду ls (comm="ls" exe="/bin/ls") в текущем терминале (tty=pts0).

**CWD**: изменение текущего рабочего каталога процесса.

```
type=CWD msg=audit(1625525281.877:123):  cwd="/home/user"
```

Лог указывает на текущий рабочий каталог процесса, который в данном случае - /home/user.

**EXECVE**: запуск нового исполняемого файла с помощью системного вызова execve.

```
type=EXECVE msg=audit(1625525281.877:123): argc=3 a0="/bin/ls" a1="-la" a2="/etc"
```

Лог показывает запуск нового процесса с помощью системного вызова execve(). Процесс запускается с аргументами командной строки: /bin/ls -la /etc.

**SOCKET**: сетевые операции, такие как создание сокетов, отправка и получение данных через сокеты и т. д.

```
type=SOCKET msg=audit(1625525281.877:123): saddr=192.168.1.200 sport=12345 daddr=192.168.1.2 dport=22
```

Лог показывает на сетевое событие, где произошло установление соединения между IP-адресами 192.168.1.100 и 192.168.1.2 на портах 12345 и 22 соответственно.

**FILE**: действия с файлами и директориями, такие как открытие, чтение, запись, удаление и изменение атрибутов файлов.

type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ls" exe="/bin/ls" key="audit-wazuh-r" name="/etc/passwd"

В этой записи показана успешная попытка доступа к файлу /etc/passwd с помощью системного вызова open(). Процесс с pid=29943, запущенный пользователем с auid=1000, выполняет команду ls, которая пытается получить доступ к файлу /etc/passwd.

**USER\_AUTH**: аутентификационные события, такие как входы пользователей в систему, смены паролей и другие операции аутентификации.

type=USER\_AUTH msg=audit(1625525281.877:123): pid=12345 uid=0 auid=1000 ses=2 subj=unconfined\_u:unconfined\_r:unconfined\_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="user123" exe="/usr/sbin/sshd" hostname=192.168.1.2 addr=192.168.1.3 terminal=ssh res=success'

Лог отображает успешную аутентификацию пользователя. Пользователь с идентификатором uid=0 (обычно root) успешно прошел аутентификацию с помощью SSH.

**USER\_ROLE\_CHANGE**: изменения роли пользователя.

type=USER\_ROLE\_CHANGE msg=audit(1625525281.877:123): pid=12345 uid=0 auid=1000 ses=2 subj=unconfined\_u:unconfined\_r:unconfined\_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined\_u:unconfined\_r:unconfined\_t:s0-s0:c0.c1023 exe="/usr/sbin/sshd" hostname=192.168.1.2 addr=192.168.1.3 terminal=ssh res=success'

Лог указывает на успешное изменение роли пользователя. Пользователь с auid=1000 (идентификатор аудита пользователя) изменил свою роль. В данном случае, изменение роли прошло успешно (res=success).

**LOGIN/LOGOUT**: вход и выход пользователей из системы.

type=USER\_LOGIN msg=audit(1625525281.877:123): pid=12345 uid=0 auid=1000 ses=2 subj=unconfined\_u:unconfined\_r:unconfined\_t:s0-s0:c0.c1023 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=192.168.1.2 addr=192.168.1.3 terminal=ssh res=success'

Лог показывает успешный вход пользователя в систему. Пользователь с uid=0 (обычно root) успешно вошел в систему с использованием SSH.

**PROCTITLE**: изменения заголовков процесса.

type=PROCTITLE msg=audit(1625525281.877:123): proctitle="/bin/ls -la /etc"

Запись показывает аргументы командной строки процесса. Процесс с pid=123 запускает команду /bin/ls -la /etc.

**SYSTEM\_BOOT/SHUTDOWN**: события загрузки и выключения системы.

type=SYSTEM\_BOOT msg=audit(1625525281.877:123): kernel time=1234567890

Эта запись указывает на событие загрузки системы. Время загрузки ядра равно 1234567890, в формате UNIX времени.

**Отличия auditd от журналов в Linux**

1. auditd предназначен для аудита событий безопасности, а именно для мониторинга и анализа активности на системе с целью обнаружения и предотвращения угроз безопасности, когда как обычные журналы, такие как `/var/log/syslog`, обычно используются для отслеживания работы системы, включая запуск и остановку служб, сообщения о состоянии аппаратного обеспечения и другие системные события.
2. auditd обычно настраивается администратором системы для мониторинга конкретных событий безопасности в соответствии с требованиями безопасности системы, в то время как обычные журналы логов создаются и используются системой по умолчанию для регистрации различных событий и действий на системе.

**Механизмы защиты auditd**

**Проверка подписи конфигурационных файлов**

Обнаруживает изменения в конфигурационных файлах, указывающие на потенциальные нарушения. Настройка проверки подписи конфигурационных файлов в auditd выполняется с использованием инструментов, таких как auditctl и keyctl. Общий подход к настройке можно описать следующим образом:

- Генерация ключей для подписи. Сначала необходимо сгенерировать ключи для подписи конфигурационных файлов. Эти ключи будут использоваться для создания и проверки цифровых подписей файлов. Команда генерирует ключ с именем auditd\_signing\_key

```
keyctl add key auditd_signing_key "asymmetric" "trusted:kernel" "new 0" @u
```

- Подписание конфигурационных файлов. Команда подписывает файл /etc/audit/audit.rules с использованием созданного ключа и сохраняет подпись в файл /etc/audit/audit.rules.sig.

```
openssl dgst -sha256 -sign /etc/audit/private/auditd_signing_key -out /etc/audit/audit.rules.sig /etc/audit/audit.rules
```

- Настройка проверки подписи.   
    ```
    auditctl -b 1024 -S verify -k auditd_conf -F subj_type=auditd_t
    ```

Команда настраивает проверку подписи для конфигурационных файлов auditd. Она устанавливает ограничение длины подписи до 1024 байт, определяет тип события verify, связывает событие с ключевой меткой auditd\_conf и определяет тип подсубъекта auditd\_t для указания на процесс auditd.

**Ограничение доступа к сокетам и файлам**

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

```
# Разрешить доступ к сокетам auditd
sudo semanage permissive -a auditd_t
# Разрешить доступ к файлам auditd
sudo semanage fcontext -a -t auditd_exec_t "/путь/к/auditd(/.*)?"
sudo restorecon -R -v /путь/к/auditd
semanage permissive -a auditd_t
```

semanage: утилита для управления SELinux.

  
permissive: параметр указывает, что типу процесса разрешается выполнение в режиме "поощряемой допускающей политики", что означает, что SELinux регистрирует попытки доступа, но не блокирует их.  
-a auditd\_t: указывает, что типу процесса auditd\_t (тип, используемый для auditd) разрешается выполнение в режиме "поощряемой допускающей политики".  
 semanage permissive -a auditd\_t позволяет разрешить типу процесса auditd\_t выполняться в режиме "поощряемой допускающей политики", что позволяет SELinux регистрировать попытки доступа к ресурсам, связанным с auditd, но не блокирует их.

semanage fcontext -a -t auditd\_exec\_t "/путь/к/auditd(/.\*)?"

fcontext: команда для управления контекстами файлов.  
-a: параметр указывает на добавление нового контекста файла.  
-t auditd\_exec\_t: указывает новый контекст файла как auditd\_exec\_t, что означает, что файл должен быть выполнимым и относиться к типу auditd\_t.  
"/путь/к/auditd(/.\*)?": это регулярное выражение, которое указывает на применение этого контекста ко всем файлам и директориям внутри /путь/к/auditd.  
Эта команда добавляет новый контекст файла для всех файлов и директорий в указанном пути (/путь/к/auditd) и его поддиректориях. Это обеспечивает правильный контекст SELinux для файлов, используемых auditd.

restorecon -R -v /путь/к/auditd

restorecon: команда для восстановления контекста SELinux файлов и директорий.  
-R: рекурсивно применяет команду ко всем файлам и поддиректориям указанного пути.  
-v: подробный вывод, который показывает изменения, внесенные командой.  
Эта команда рекурсивно восстанавливает контекст SELinux для всех файлов и директорий в указанном пути (/путь/к/auditd) и его поддиректориях, учитывая новый контекст, установленный ранее с помощью semanage fcontext.

**Отслеживание изменений конфигурации**  
auditd может логировать события, связанные с изменениями его собственной конфигурации, что позволяет обнаруживать попытки изменения параметров аудита без разрешения. Создайте файл правил аудита, который будет отслеживать изменения в конфигурационных файлах auditd. Например, файл с именем auditd-config.rules и запишите в него правило:

-w /etc/audit/audit.rules -p wa -k auditd\_config

В этом примере:

-w /etc/audit/audit.rules: указывает путь к конфигурационному файлу audit.rules, который нужно отслеживать.  
-p wa: определяет, какие операции нужно отслеживать. В данном случае, w означает запись (write), a - изменение атрибутов (attribute).  
-k auditd\_config: присваивает ключевую метку (tag) событию для легкого поиска.  
Загрузите правила аудита в систему с помощью утилиты auditctl:

sudo auditctl -R /etc/audit/audit.rules

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

sudo ausearch -k auditd\_config

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

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

Правила аудита (audit rules) определяют, какие события и действия в операционной системе должны записаны в журнал аудита. Может быть определено:

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

Правила аудита обычно хранятся в файле конфигурации audit.rules.

**Ключи правил**

<table border="1" id="bkmrk--a-%D0%94%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B5-%D0%B4%D0%BB%D1%8F-%D1%81%D0%BE%D0%B1%D1%8B" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 12.4082%;"></col><col style="width: 87.5918%;"></col></colgroup><tbody><tr><td>-a</td><td>Действие для события, соответствующего правилу. Возможные значения включают:

- always: Применять правило всегда.
- never: Никогда не применять правило.
- exit: Применять правило только при выходе из процесса.
- creat,open,openat,truncate,ftruncate,unlink,mkdir,rmdir

</td></tr><tr><td>-F</td><td>Условия, которым должны соответствовать аудитируемые события. Ключ -F может повторяться.

```
-F path=/etc/passwd: Определяет путь к файлу.
-F perm=w: Определяет разрешение (например, запись в файл).
-F uid=0: Определяет идентификатор пользователя.
-F arch=b64: 64-битные приложения
-F key=file_modification: Присваивает ключевую метку событию для легкого поиска.
```

</td></tr><tr><td>-S</td><td>Системные вызовы, которые должны быть аудиторованы.

- open: Отслеживать системные вызовы открытия файлов.
- execve: Отслеживать системные вызовы выполнения новых программ.

</td></tr><tr><td>-C</td><td>Условия по контексту, таким как идентификатор пользователя (UID) или группы (GID).

-C uid=0: Определяет аудитируемые события для пользователя с UID 0 (root).  
-C gid=adm: Определяет аудитируемые события для группы с именем "adm".

</td></tr><tr><td>-k</td><td>Присваивает ключевую метку событию, что позволяет идентифицировать события.</td></tr><tr><td>  
</td><td>  
</td></tr><tr><td>  
</td><td>  
</td></tr><tr><td>  
</td><td>  
</td></tr></tbody></table>

**Примеры правил**

Отслеживание доступа к файлам

```
-a always,exit -F path=/etc/shadow -F perm=r -k sensitive_files_access
```

Отслеживание запуска привилегированных команд

```
-a always,exit -F arch=b64 -S execve -C uid=0 -k privileged_commands
```

Отслеживание изменений файловой системы

```
-a always,exit -F arch=b64 -S creat,open,openat,truncate,ftruncate,unlink,mkdir,rmdir -F key=file_modification
```

**Пример настройки правил в целом**

Мы уже рассматривали анализ логов auditd ранее в курсе. Теперь давайте рассмотрим стандартную конфигурацию audtid, где уже собрано большинство полезных правил: [https://github.com/Neo23x0/auditd/blob/master/audit.rules](https://github.com/Neo23x0/auditd/blob/master/audit.rules)

Первым делом мы удаляем все существующие правила командой `<samp>-D</samp>`:

![](https://ucarecdn.com/6a09ff2d-d683-4769-a894-e660c8392bc1/)

Затем настраиваем размер буфера в байтах:

![](https://ucarecdn.com/c998805c-7df5-4ce3-9f39-b704a4b792e8/)

Этот параметр очень важен в сочетании со следующим, `<samp>-f</samp>`. Параметр -f (failure) отвечает за поведение системы в случае отказа модуля auditd, в значении 0 при отказе auditd ничего не происходит, в значении 1 выводится сообщение об ошибке, и в значении 2 система прекращает работу.

![](https://ucarecdn.com/84aa5c6b-904d-4687-962d-ccf95dfe88e4/)

Параметр `<samp>-i</samp>` позволяет игнорировать некоторые ошибки, например отсутствие файлов, которые мы указали в правилах мониторинга.

Следующим шагом идет мониторинг доступа к логам и исполняемым файлам auditd. Поскольку в логах могут содержаться очень чувствительные данные (например, пароли, или команды, выполняющиеся в cron от имени администратора) необходимо отслеживать обращения к логам auditd, как успешные, так и неуспешные.

![](https://ucarecdn.com/e248efca-c400-4356-be85-dcb2bad8c120/)

Давайте рассмотрим правила мониторинга файлов на этом примере.

Формат правила для мониторинга файлов и директорий выглядит следующим образом:

```
```css
auditctl -w путь_к_файлу -p разрешения -k имя_ключа
```<button class="copy-code-btn st-button_style_none copy-code-btn__code-block" title="Скопировать код" type="button"><svg fill="none" height="24" viewbox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg"><path d="M19.2 3H10.2C9.2073 3 8.4 3.8073 8.4 4.8V8.4H4.8C3.8073 8.4 3 9.2073 3 10.2V19.2C3 20.1927 
                      3.8073 21 4.8 21H13.8C14.7927 21 15.6 20.1927 15.6 19.2V15.6H19.2C20.1927 15.6 21 14.7927 21 13.8V4.8C21 3.8073 
                      20.1927 3 19.2 3ZM4.8 19.2V10.2H13.8L13.8018 19.2H4.8ZM19.2 13.8H15.6V10.2C15.6 9.2073 14.7927 8.4 13.8 8.4H10.2V4.8H19.2V13.8Z" fill="#777777"></path></svg>
                  </button>
```

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

Итого, мы отслеживаем запись(w), чтение(r) и изменение аттрибутов(a) для каталогов `/var/log/audit` и `/var/audit`.

Продолжим:

![](https://ucarecdn.com/afb53725-bc08-4c8e-8f3f-0277034e1f22/)

Здесь мы отслеживаем изменение конфигурации auditd.

![](https://ucarecdn.com/4aa5176d-2960-44aa-b679-c76e28f6b5a6/)

А здесь выполнение (ключ `-x`, execute) команд, которые могут повлиять на конфигурацию auditd: auditctl, auditd, augenrules.

Продолжим изучать файл конфигурации auditd:

![](https://ucarecdn.com/1e869582-3f42-4962-a0d4-58b0507770fd/)

Рассмотрим правило отслеживания системных вызовов на этом примере. В общем случае правило выглядит так:

```
```r
auditctl  -a действие,фильтр [ -F arch=архитектура_системы -S имя_системного_вызова] -F поле=значение  -k имя_ключа
```<button class="copy-code-btn st-button_style_none copy-code-btn__code-block" title="Скопировать код" type="button"><svg fill="none" height="24" viewbox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg"><path d="M19.2 3H10.2C9.2073 3 8.4 3.8073 8.4 4.8V8.4H4.8C3.8073 8.4 3 9.2073 3 10.2V19.2C3 20.1927 
                      3.8073 21 4.8 21H13.8C14.7927 21 15.6 20.1927 15.6 19.2V15.6H19.2C20.1927 15.6 21 14.7927 21 13.8V4.8C21 3.8073 
                      20.1927 3 19.2 3ZM4.8 19.2V10.2H13.8L13.8018 19.2H4.8ZM19.2 13.8H15.6V10.2C15.6 9.2073 14.7927 8.4 13.8 8.4H10.2V4.8H19.2V13.8Z" fill="#777777"></path></svg>
                  </button>
```

Где:

- ***Действие и фильтр** определяют, какое событие будет регистрироваться*. *Действие(action) может быть либо* `always` , либо `never`. Параметр *filter* определяет какой фильтр событий ядра будет применяться к данному правилу. Возможные значения фильтра: `task`, `exit`, `user`, and `exclude`. В большинстве случаев используется фильтр `exit`, когда событие записывается при завершении системного вызова.
- ***system\_call**(имя\_системного\_вызова)* позволяет применить фильтр на основании системного вызова. Мы можем указать несколько системных вызовов используя ключ -S.
- ***-F*** — *фильтр, позволяющий нам отслеживать определенные события, которые нам интересны*. Фильтров может быть несколько, они указываются в формате "ключ"\[!=&gt;&lt;\]"значение", например, path=/usr/bin/ls или auid&gt;=1000.
- **-k имя\_ключа** — *опциональный, но очень полезный параметр, позволяющий добавить метку для отслеживаемого события*.

Итак, на примере выше мы мониторим события запуска (-F perm=x) команд auditd (ausearch, aureport, и т.д) после их выполнения (exit) и помечаем эти события меткой audittools.

> *Использование ключа -a never позволяет исключать события из мониторинга. Необходимо учитывать, что правила читаются сверху вниз, поэтому правила-исключения лучше помещать в начало файла конфигурации auditd.*

Далее идут исключения:

![](https://ucarecdn.com/f84b31ad-dc4f-41fe-9535-54686ef8477f/)

Мы видим два типа исключений -a never и -a always,exclude.

![](https://ucarecdn.com/bb55acf7-630c-41d6-a3ac-2a0cc54b1b7c/)

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

![](https://ucarecdn.com/063c056d-9f37-4431-8712-eff9b91ff540/)

Мониторинг доступа к базам данных пользователей системы и паролям, а также к файлу sudoers.

![](https://ucarecdn.com/f2c3b2ba-a790-4720-a77e-e0dc5250ac45/)

Отслеживание выполнения команды passwd.

![](https://ucarecdn.com/66752cd0-025b-4ebf-977d-2ce1eb9ce4b9/)

С помощью мониторинга системного вызова *connect* мы можем отслеживать сетевые соединения, и даже ловить remote shell.

В примере выше мы получим запись в лог, если процесс bash успешно откроет сетевое подключение.

> Мониторинг всех сетевых подключений может генерировать огромное количество событий, особенно на серверах, которые предоставляют публичные сервисы, например, веб-сервера. Такие правила необходимо использовать с осторожностью, особенно, если у нас включен параметр -f=2 который вешает систему при переполнении очереди событий auditd.

Идем дальше.

![](https://ucarecdn.com/76a3eb1d-d381-485c-9521-9f407ec39a9a/)

Тут мы отслеживаем неуспешные(succes=0) попытки доступа к системным директориям.

 ![](https://ucarecdn.com/1a339a91-0215-48b0-990b-8599ff6b1092/)

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

![](https://ucarecdn.com/31548367-7b01-48ca-81d5-ce4eca161df6/)

Запуск программ sssd пользователями.

> В описании правил можно часто встретить auid!=4294967295. Это число транслируется системой в -1, и означает, что UID еще не установлен системой. Вместо 4294967295 можно использовать число "-1" или значение "unset".

![](https://ucarecdn.com/91e96db2-6b72-40fe-a189-9afc04af8620/)

Отслеживание запуска команд от пользователя www-data. Применимо к веб-серверам, euid(effective uid) может отличаться. Правило может помочь обнаружить взлом веб-сервера(например, пользователь www-data запускает bash), но также может генерировать большое количество ложно-положительных срабатываний, если от имени веб-сервера запускаются какие-либо скрипты.

![](https://ucarecdn.com/c12f4397-b6e5-43bf-a19f-ad2e3d62e9ca/)

Отслеживание выполнения команд от пользователя root(euid=0). Это правило может генерировать очень много событий, следует использовать с осторожностью.

![](https://ucarecdn.com/4ee37f4f-893b-46ea-a052-31baf855b8e1/)

Удаление файлов пользователями системы(auid&gt;=1000).

И, последней строчкой мы можем добавить правило, запрещающее дальнейшее изменение праил auditd. За это отвечает ключ -e (enable). Значение 0 позволяет выключить мониторинг, значение 1 - включить, а значение 2 делает конфигурацию неизменяемой.

![](https://ucarecdn.com/aaf7a902-420a-4b43-b8be-c57966175b65/)