Леннарт Поттеринг (Lennart Poettering) представил в своём блоге Journal, дополнение к системному менеджеру systemd, призванное заменить собой службу syslog и другие сопутствующие сервисы журналирования событий. Разработка пока находится на начальной стадии, прототип с реализацией базовой функциональности можно найти в Git-репозитории systemd. Первую экспериментальную реализацию Journal планируется интегрировать в дистрибутив Fedora 17.

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

Journal будет частью systemd и не сможет использоваться обособленно. Все логи будут проиндексированы и храниться в бинарных файлах, к которым к сожалению будут неприменимы стандартные утилиты обработки текстовых данных, например, grep. Тем не менее, Journal не исключает параллельное использование традиционных syslog-служб, таких как rsyslog и syslog-ng. Каждая запись в БД Journal содержит набор параметров в формате "переменная=значение". С целью обеспечения структурирования информации, переменные могут создаваться произвольно. Кроме текстовых данных допускается прикрепление бинарных дополнений, которые могут содержать такие данные, как core-дампы, данные мониторинга SMART и диагностические дампы SCSI.

По своему формату БД Journal является комбинацией классических линейных логов и идей, используемых в репозитории Git. Как в случае с обычными логами, данные добавляются в конец БД с небольшим изменением служебных заголовков в начале файла. Данные хранятся в сжатом виде. Каждое поле в блоке данных сохраняется как независимый объект, что позволяет минимизировать потребление дискового пространства при наличии типовых значений (например, при сохранеии поля с именем хоста, если такое имя уже было в логе, вместо дублирования информации будет помещена ссылка). Сообщения от непривилегированных пользователей размещаются в отдельных файлах БД, привязанных к логину пользователя. Подобный подход позволяет ограничить доступ к логам только для их владельцев (для доступа к системным логам пользователь должен входить в специальную группу).

Для отправки подлежащих журналированию сообщений может быть использован стандартный API syslog(3), поэтому совместимость с приложениями будет сохранена. В будущем планируется реализовать ряд расширений, которые позволят из специализированных программ отправлять в лог не только строковые сообщения, но привязанные к ним метаданные и бинарные приложения. Каждая запись в логе имеет свой уникальный 128-разрядный идентификатор.

Для управления журналами будет подготовлен набор инструментов, которые позволят выполнять такие операции, как ротация, копирование, объединение и создание произвольных выборок. Ротация БД с журналом будет производиться автоматически, после превышения заданного лимита. С целью предотвращения утери логов дополнительно будет учитываться наличие свободного пространства на диске. Для защиты от атак, направленных на переполнение диска из-за разрастания лога, будут задействованы средства контроля за интенсивностью отправки сообщений (rate limit), при этом лимит будет автоматически корректироваться в зависимости от размера доступного места на диске. Выборку данных можно будет производить как по дате, так и по отдельным полям. Утилита для выборки данных автоматически будет охватывать и подвергнутые ротации файлы, т.е. весь архив логов будет виден как единое целое.

Кроме выполнения функций syslog, новая система сможет взять на себя ведение и других типов логов, таких как журнал входа в систему (wtmp), журнал начальной загрузки и логи системы аудита. Источником поступления сообщений может быть как стандартный интерфейс syslog(3), так и вызов printk() из ядра, а также различные специализированные API. В будущем рассматривается возможность перехвата сообщений от прошивок (логи UEFI) и задействование расширенных механизмов журналирования в ядре Linux. Начальная реализация Journal будет включать в себя только минимальную поддержку передачи логов по сети, которая будет ограничена простым копированием файлов БД на центральный хост при помощи scp, rsync или NFS. В будущем появятся более серьёзные средства для непрерывного приёма и отправки новых записей по сети.

Особенности Journal:

• Упрощение: небольшой размер кода с минимальным числом зависимостей;
• Автоматизация работы без необходимости ручного обслуживания: ведение журнала критически важная функциональность для отладки и мониторинга систем, поэтому работа должна вестись с оглядкой на возникновение внештатных ситуаций. Например, следует контролировать расходование свободного места в разделе /var и применять соответствующие методики ротации логов и ограничения интенсивности записи в лог;
• Устойчивость: файлы с логами должны быть непосредственно доступны для администраторов и пригодны для простого копирования по сети с использованием штатных средств, таких как scp, без нарушения целостности, даже если лог скопирован не полностью. Возможность анализа лога должна быть доступна без необходимости запуска демона журналирования, обслуживающего БД с логами;
• Переносимость: файлы с логами не должны зависеть от типа системы и CPU. Например, БД с логом, созданная на встраиваемом устройстве на базе архитектуры ARM, должна быть просмотрена и на компьютере с другим порядком следования байт;
• Производительность: все операции по добавлению данных в лог и просмотру лога должны выполняться с максимальной скоростью;
• Интеграция: Новая система ведения логов должна плотно интегрироваться с другими системными компонентами;
• Минимальное потребление ресурсов: файлы с журналами должны занимать минимальное место на диске, даже с учетом того, что объем генерируемых данных может быть существенно больше, чем при использовании классических журналов;
• Хранилище информации о событиях общего назначения: должно поддерживаться помещение в журнал разных типов записей, независимо от их формата и размера;
• Унификация: различные виды технологий журналирования должны быть унифицированы, все события должны храниться в едином типе хранилища и должны быть доступны для связанного анализа. Например, часто запись от прошивки следует за записью от ядра Linux и связана с какими-то действиями на уровне пользователя - важно, чтобы связь между этими тремя событиями можно было отследить;
• Поддержка высокоуровневых инструментов: должен присутствовать удобный API, который можно использовать в программах мониторинга, восстановления после сбоев, генераторах отчетов о причинах краха и различных утилитах для просмотра логов;
• Масштабируемость: система должна одинаково хорошо работать на обычных компьютерах, на больших кластерах и на встраиваемых системах с ограниченными ресурсами, справляясь с любыми размерами журналов и интенсивностью потока событий;
• Универсальность: возможность расширения для поддержки специфичных требований отдельных приложений (формат должен быть расширяем);
• Поддержка кластеризации и сетевых функций: обеспечение единой службы журналирования для больших инфраструктур, состоящих из множества хостов;
• Безопасность: файлы с логами должны быть аутентифицированными для гарантии отсутствия изменения уже сохранённых данных.

Среди основных проблем syslog, которые попытались решить разработчики Journal, отмечаются:

• Данные сообщений не аутентифицированы. Например, любой локальный процесс может указать что он Apache с PID 4321, а syslog поверит этому и сохранит сведения в лог;
• Данные помещаются в лог в свободной и неструктурированной форме, что требует написания специальных парсеров для автоматизированного разбора логов, учитывающих множество возможных форм представления данных;
• Время записи сохраняется без учета часового пояса;
• На одной машине разными службами одновременно ведётся несколько разных журналов, таких как utmp/wtmp, lastlog, audit, логи ядра, логи прошивок, логи отдельных приложений. Подобная организация существенно затрудняет выявление связей между элементами разных логов;
• Чтение лога является очень простым, но в то же время крайне неэффективным процессом. Так как отсутствует индексация, всегда требуется полный перебор лога;
• Сетевой протокол syslog очень ограничен, например, не гарантирует доставку и не учитывает потерю пакетов;
• Атакующие могут легко отредактировать лог для сокрытия своих действий;
• Отсутствуют гибкие средства контроля доступа к логам;
• Ограничены возможности по сохранению в логе дополнительных метаданных;
• При ротации логов не учитывается свободное место и нет эффективной защиты от проведения DoS-атак через наводнение логов;
• Сжатие логов производится только после ротации, активный лог находится в несжатом виде, а архивный сжат целиком, а не на уровне отдельных записей;
• Классический Syslog непригоден для журналирования событий на раннем этапе загрузки системы;
• В лог не могут помещаться бинарные данные.

Источник: http://www.opennet.ru/opennews/art.shtml?num=32347