Всем привет! Меня зовут Михаил, я разработчик в команде, которая занимается созданием ОС Astra Linux.

Тема логирования в дистрибутивах Linux всегда живо обсуждается как среди наших клиентов и партнёров, так и внутри компании.

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

Описанные выше пробелы в знаниях сообщества побудили меня подумать над тем, как помочь коллегам сориентироваться в непростом хитросплетении путей, по которым запись лога проходит от исходной программы до конечного файла. Так мне пришла идея написать цикл статей, посвященный логированию в операционной системе Astra Linux Special Edition. 

Данная статья открывает серию. В ней я хотел бы кратко осветить основы организации процесса сбора логов. Следующий материал сбудет посвящен обзору syslog-ng в контексте применения в нашей ОС. Завершу статьей, посвященной нашей собственной разработке – подсистеме регистрации событий. Объединять запланированную трилогию в лонгрид нечитаемого объема кажется нелогичным, так как сейчас и без того существует путаница.

Итак, начинаем!

Откуда берутся логи?

Ну погоди, ещё не вечер,
Ещё не ясно ничего.
И верю я — наступит встреча
Под крышей дома твоего.

В Astra Linux Special Edition есть  два основных источника логов:

1. Syslog. Под данным термином понимается как стандарт сбора логов в POSIX системах, так и подсистема, реализующая указанный стандарт. Что входит в эту подсистему мы разберем ниже.

2. Подсистема аудита. В основе нее лежит отслеживание системных вызовов ядра.

Этапы процесса: как работает Syslog?

Сразу оговорюсь: все, что будет написано ниже, актуально для Astra Linux Special Edition, начиная с версии 1.7.1.

Итак, стандарт Syslog определяет:

1. Протокол отправки логов.

2. Формат записей, определяемый RFC5424.

3. Набор стандартных сокетов.

4. Демона логирования.

Шаг 1.

Большая часть сообщений Syslog отправляется в сокет /dev/log. Для системных сообщений ядра отведены также псевдофайл /proc/kmsg и сокет /dev/kmsg.

Шаг 2.

Из описанных выше сокетов сообщения попадают на обработку в системную службу systemd-journald. Она агрегирует логи в бинарном формате в каталоге /run/log/journal или в /var/log/journal, в зависимости от настроек. Далее просмотреть их можно, например, с помощью утилиты journalctl.

Шаг 3.

После обработки в systemd-journald сообщения отправляются в службу логирования syslog-ng. Это мощный и гибкий инструмент для обработки как стандартных, так и всевозможных нестандартных логов. Хоть сколько-нибудь подробное описание её возможностей в контексте применения в Astra Linux Special Edition заслуживает отдельной статьи — планирую ее опубликовать вслед за этой, о чем писал во введении. Здесь лишь поясню общие моменты.

Syslog-ng — это служба логирования, основные задачи которой агрегация и маршрутизация логов. В частности, syslog-ng может отправлять и принимать сообщения по сети и подходит для построения централизованных хранилищ логов. Syslog-ng работает как совместно с systemd-journald, так и без него. Если systemd-journald не установлен, информация будет браться из /dev/log и /proc/kmsg напрямую.

Миллион, миллион, миллион алых роз
Из окна, из окна, из окна видишь ты.

Шаг 4.

Один из основных результатов работы syslog-ng — формирование конечных файлов логов в каталоге /var/log: /var/log/syslog, /var/log/auth.log, /var/log/kern.log и т. д. Полный список сформированных по умолчанию логов можно посмотреть в конфигурационном файле /etc/syslog-ng/syslog-ng.conf.

Также syslog-ng выступает как ядро для подсистемы регистрации событий в Astra Linux Special Edition, начиная с версии 1.7.1. Подсистема регистрации событий является нашей собственной разработкой и, как я уже говорил, ей будет посвящена отдельная статья.

Подсистема аудита Linux: управление с помощью утилит и правил

Заяц—Волк! Заяц—Волк! Заяц...

Когда об аудите было коротко? Как показала практика, с термином «аудит» связана некоторая путаница. Поэтому ещё раз подчеркну: в этой статье будет сжато рассмотрена подсистема аудита Linux.

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

 В процессе отслеживания все записи подсистемы аудита попадают в файл /var/log/audit/audit.log. В Syslog также могут дублироваться записи двумя путями, в зависимости от настроек:

1. Через стандартные сокеты Syslog, описанные выше. В этом случае записи дублируются в файл /var/log/auth.log. В актуальных версиях Astra Linux настройки syslog-ng по умолчанию не пропускают записи аудита в указанный файл — это сделано для снижения нагрузки.

2. Syslog-ng может быть настроен также на прямой приём и дальнейшую обработку записей аудита.

Управление подсистемой аудита с базовым набором утилит

В состав пакета auditd входят следующие базовые утилиты, которые позволяют управлять подсистемой:

• auditctl — утилита управления демоном auditd. Она информирует о состоянии подсистемы аудита, а также позволяет добавлять и удалять правила.

• autrace — помогает отслеживать события, порождаемые процессами.

• ausearch — утилита для поиска событий в логах аудита.

• aureport — утилита для вывода отчётов о работе подсистемы аудита.

Также в состав Astra Linux Special Edition входят графические утилиты для настройки и чтения логов аудита: system-config-audit и ksystemlog.

Правила наблюдения в подсистеме аудита

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

Здесь стоит иметь в виду, что для разных архитектур процессоров набор системных вызовов от ядра может отличаться. Поэтому правила, актуальные, например, для архитектуры x86-64, не обязательно будут корректны для arm64. Проверить корректность того или иного правила можно так же с помощью утилиты auditctl.

Подсмотреть список доступных системных вызовов можно с помощью утилиты ausyscall. Для этого достаточно вызвать: «ausyscall --dump». На скриншоте ниже представлен пример того, как может выглядеть вывод утилиты.

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

Подводные камни подсистемы аудита Linux

Я — как айсберг в океане.
Всё плывёт в сплошном тумане.
Ничего вокруг не вижу:
Белый свет, как белый снег…

Один из недостатков — некоторая «тяжесть» подсистемы из-за дополнительных расходов на отслеживание системных вызовов ядра. Обычно это практически не заметно, но трекинг таких случаев может вести к лавинообразному росту нагрузки и перерасходу дискового пространства.

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

Сложность настройки подсистемы аудита можно также отнести к недостаткам.

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

Если есть потребность подробнее раскрыть тему приоритизации правил, напишите в комментариях. Такой разбор по объему ближе к самостоятельной статье.

Упомянутая подсистема регистрации событий Astra Linux Se призвана, в том числе, компенсировать часть недостатков подсистемы аудита, о которых я рассказал выше.

Заключение

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

Также хочу упомянуть, что изложенное выше касается в первую очередь сбора логов на локальном хосте. При этом, как указывалось ранее, для всех описанных в статье средств имеется возможность отправки и приема логов по сети. Это позволяет, например, выполнять интеграцию сбора и обработки логов в различные системы мониторинга. В частности, для мониторинга всех слоёв инфраструктуры командой «Группы Астра» разработан новый продукт  – Astra Monitoring.

Для тех, кто хочет копнуть глубже в направлении Syslog и аудита, рекомендую ознакомиться с различными тематическими статьями как на Хабре, так и на других ресурсах.

И напоследок ещё раз напомню, что описание применения syslog-ng заслуживает минимум одной отдельной статьи. То же касается и подсистемы регистрации событий. Так что продолжение следует...