![](https://habrastorage.org/getpro/habr/upload_files/a02/f48/470/a02f484708edc5b528d3deef4c241bfb.png)
Всем привет! Меня зовут Михаил, я разработчик в команде, которая занимается созданием ОС Astra Linux.
Тема логирования в дистрибутивах Linux всегда живо обсуждается как среди наших клиентов и партнёров, так и внутри компании.
Практика показывает, что начинающие разработчики и инженеры часто не видят цельную картину, по каким путям в нашей ОС проходят логи. Не всегда есть понимание, какой именно компонент формирует тот или иной лог, какие именно настройки относятся к тому или иному компоненту. Например, под термином «аудит» может пониматься как подсистема аудита Linux, так и другие компоненты ОС, участвующие в формировании и обработке логов.
Описанные выше пробелы в знаниях сообщества побудили меня подумать над тем, как помочь коллегам сориентироваться в непростом хитросплетении путей, по которым запись лога проходит от исходной программы до конечного файла. Так мне пришла идея написать цикл статей, посвященный логированию в операционной системе Astra Linux Special Edition.
Данная статья открывает серию. В ней я хотел бы кратко осветить основы организации процесса сбора логов. Следующий материал сбудет посвящен обзору syslog-ng в контексте применения в нашей ОС. Завершу статьей, посвященной нашей собственной разработке – подсистеме регистрации событий. Объединять запланированную трилогию в лонгрид нечитаемого объема кажется нелогичным, так как сейчас и без того существует путаница.
Итак, начинаем!
Дисклеймер
Сразу хочу подчеркнуть, задача статьи — сформировать у читателя общее представление о цепочке, участвующей в формировании стандартных логов. И попробовать с моей стороны данным рассказом задать направление для самостоятельных исследований :) У меня нет цели детально пересказать многочисленные источники, освещающие подсистемы, на которых основывается сбор логов в Astra Linux. Об этом уже здесь сказано достаточно.
Откуда берутся логи?
Ну погоди, ещё не вечер,
Ещё не ясно ничего.
И верю я — наступит встреча
Под крышей дома твоего.
В Astra Linux Special Edition есть два основных источника логов:
Syslog. Под данным термином понимается как стандарт сбора логов в POSIX системах, так и подсистема, реализующая указанный стандарт. Что входит в эту подсистему мы разберем ниже.
Подсистема аудита. В основе нее лежит отслеживание системных вызовов ядра.
Этапы процесса: как работает Syslog?
Сразу оговорюсь: все, что будет написано ниже, актуально для Astra Linux Special Edition, начиная с версии 1.7.1.
Итак, стандарт Syslog определяет:
Протокол отправки логов.
Формат записей, определяемый RFC5424.
Набор стандартных сокетов.
Демона логирования.
![](https://habrastorage.org/getpro/habr/upload_files/3ec/8c4/0a8/3ec8c40a817be9b8ccfed5798b2c9e6c.png)
Шаг 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 напрямую.
Миллион, миллион, миллион алых роз
Из окна, из окна, из окна видишь ты.
![](https://habrastorage.org/getpro/habr/upload_files/132/536/9d0/1325369d0d1809ef07b41e0ca8e6dcba.png)
Шаг 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 также могут дублироваться записи двумя путями, в зависимости от настроек:
Через стандартные сокеты Syslog, описанные выше. В этом случае записи дублируются в файл /var/log/auth.log. В актуальных версиях Astra Linux настройки syslog-ng по умолчанию не пропускают записи аудита в указанный файл — это сделано для снижения нагрузки.
Syslog-ng может быть настроен также на прямой приём и дальнейшую обработку записей аудита.
![](https://habrastorage.org/getpro/habr/upload_files/987/438/76a/98743876a144fc6aba8303eb503ca6de.png)
Управление подсистемой аудита с базовым набором утилит
В состав пакета 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». На скриншоте ниже представлен пример того, как может выглядеть вывод утилиты.
![](https://habrastorage.org/getpro/habr/upload_files/60a/a52/9fd/60aa529fdddcd7cf447d469d2afd3d16.png)
Подсистема аудита является достаточно мощным средством для отслеживания событий безопасности системы, однако она не лишена недостатков.
Подводные камни подсистемы аудита Linux
Я — как айсберг в океане.
Всё плывёт в сплошном тумане.
Ничего вокруг не вижу:
Белый свет, как белый снег…
![](https://habrastorage.org/getpro/habr/upload_files/a9d/12d/e7a/a9d12de7ab0938895f0672bce1bdad6f.png)
Один из недостатков — некоторая «тяжесть» подсистемы из-за дополнительных расходов на отслеживание системных вызовов ядра. Обычно это практически не заметно, но трекинг таких случаев может вести к лавинообразному росту нагрузки и перерасходу дискового пространства.
Следующий недостаток — логи подсистемы аудита не удобно читать человеку. Чтобы разобраться, что именно происходит в логе в тот или иной момент времени, нужен определенный уровень квалификации. Как минимум, стоит иметь представление о системных вызовах ядра и как они работают. Различные утилиты для чтения лишь незначительно облегчают задачу.
Сложность настройки подсистемы аудита можно также отнести к недостаткам.
И ещё один подводный камень. При наличии двух и более корректных правил, применимых к одному и тому же системному вызову, подсистема сформирует запись для первого попавшегося ей правила. Второе и последующие правила при этом будут проигнорированы. Это сделано для оптимизации, но при достаточно большом количестве настроенных правил может вызывать путаницу.
Если есть потребность подробнее раскрыть тему приоритизации правил, напишите в комментариях. Такой разбор по объему ближе к самостоятельной статье.
Упомянутая подсистема регистрации событий Astra Linux Se призвана, в том числе, компенсировать часть недостатков подсистемы аудита, о которых я рассказал выше.
Заключение
В данной статье я изложил общую картину, какими средствами обрабатываются логи в Astra Linux Special Edition. Прекрасно понимаю всю глубину и обширность темы, но надеюсь при этом, что мне удалось достичь обозначенной во введении цели.
Также хочу упомянуть, что изложенное выше касается в первую очередь сбора логов на локальном хосте. При этом, как указывалось ранее, для всех описанных в статье средств имеется возможность отправки и приема логов по сети. Это позволяет, например, выполнять интеграцию сбора и обработки логов в различные системы мониторинга. В частности, для мониторинга всех слоёв инфраструктуры командой «Группы Астра» разработан новый продукт – Astra Monitoring.
Для тех, кто хочет копнуть глубже в направлении Syslog и аудита, рекомендую ознакомиться с различными тематическими статьями как на Хабре, так и на других ресурсах.
И напоследок ещё раз напомню, что описание применения syslog-ng заслуживает минимум одной отдельной статьи. То же касается и подсистемы регистрации событий. Так что продолжение следует...
Комментарии (10)
Johan_Palych
14.06.2024 13:27+4Для информации:
Date: Sat, 23 Mar 2024 09:30:49 +0100 Debian 10 "buster" moved to archive.debian.org
https://lists.debian.org/debian-devel-announce/2024/03/msg00003.html
Примеры подключения сторонних репозиториев(ALSE 1.7.5)
https://wiki.astralinux.ru/pages/viewpage.action?pageId=3276859
Уже совсем скоро будет только так:echo 'deb http://archive.debian.org/debian/ buster main contrib non-free' | sudo tee /etc/apt/sources.list.d/buster.list >/dev/null
Yura1975
14.06.2024 13:27Когда выпустите бесплатную для домашних пользователей версию?
jackcrane
14.06.2024 13:27магнит:?xt=urn:btih:E49625B9901C53E7A5D1DA5626437B9FC2DD ноль восемь один девять
Vanovsky714
14.06.2024 13:27Вот в целом несложно гуглится. Можно бесплатно скачать дистрибутив, ограничений на использование нет
jackcrane
14.06.2024 13:27+1"по каким путям в нашей ОС проходят логи"
"в нашей ОС" ? вы умрете не от скромности.
а "пути логов" (точнее роутинг сообщений) те же что и в во всех деривативх Debian (знакомо вам такое слово ?).
litos
Вот честно говоря, я не понимаю для чего в современых дистрибутивах логи пишутся как в бинарный journal физически лежащий в /var/log/journal/ так и в текстовые файлы логов. Хватило бы вполне журнала и утилиты journalctl для работы и также возможности отправки журнала на удаленный сервер сборщику, который бы раскладывал по каталогам с id машины
gafusss
Debian 12 достаточно современный?
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#changes-to-system-logging