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

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

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

Journalctl

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

Rsyslog

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

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

Установка: 

sudo apt install rsyslog
sudo systemctl enable --now rsyslog

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

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

auth,authpriv.*         /var/log/auth.log
*.*;auth,authpriv.none  -/var/log/syslog
mail.*                  -/var/log/mail.log
cron.*                  -/var/log/cron.log

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

*.* @@syslog.example.com:514

if ($programname == 'sshd' or $programname == 'sudo') then /var/log/security.log
& stop

if ($programname == 'sudo') then /var/log/sudo.log

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

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

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

Конфигурация: /etc/rsyslog.conf (/etc/syslog.conf). Каждая строка в формате <фильтр> <действие>. Фильтр определяет, какие сообщения должны быть обработаны, а действие определяет, что делать с этими сообщениями (например, записать их в определенный файл журнала). Пример конфигурации 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). 

Демон аудита auditd

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

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

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

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"
                  

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

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

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