Системный журнал - Syslog

Системный журнал
Автор (ы) оригинала	Эрик Оллман
Первый выпуск	1980-е
Операционная система	Unix-подобный
Тип	Системный журнал
Веб-сайт	datatracker .ietf .org / wg / syslog / charter /

В вычислительном , системном журнале / ы ɪ с л ɒ ɡ / является стандартом для регистрации сообщений . Это позволяет разделить программное обеспечение, которое генерирует сообщения, систему, которая их хранит, и программное обеспечение, которое сообщает и анализирует их. Каждое сообщение помечается кодом объекта, указывающим тип системы, генерирующей сообщение, и ему назначается уровень серьезности.

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

При работе в сети системный журнал использует архитектуру клиент-сервер, в которой сервер системного журнала прослушивает и регистрирует сообщения, поступающие от клиентов.

История

Syslog был разработан в 1980-х Эриком Аллманом в рамках проекта Sendmail . Он был легко принят другими приложениями и с тех пор стал стандартным решением для ведения журналов в Unix-подобных системах. Различные реализации также существуют в других операционных системах, и это обычно встречается в сетевых устройствах, таких как маршрутизаторы .

Системный журнал изначально функционировал как стандарт де-факто без какой-либо официальной опубликованной спецификации, и существовало множество реализаций, некоторые из которых были несовместимы. Engineering Task Force Интернет документированы статус - кво в RFC 3164. Он был стандартизирован RFC 5424.

Различные компании пытались получить патенты на определенные аспекты реализации системного журнала. Это мало повлияло на использование и стандартизацию протокола.

Компоненты сообщения

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

Средство

Код объекта используется для указания типа системы, которая регистрирует сообщение. Сообщения с разными возможностями могут обрабатываться по-разному. Перечень имеющихся объектов определен стандартом:

Код объекта	Ключевое слово	Описание
0	керн	Сообщения ядра
1	Пользователь	Сообщения на уровне пользователя
2	Почта	Почтовая система
3	демон	Системные демоны
4	авторизация	Сообщения безопасности / аутентификации
5	системный журнал	Сообщения, генерируемые внутри syslogd
6	LPR	Подсистема линейного принтера
7	Новости	Подсистема сетевых новостей
8	uucp	Подсистема UUCP
9	cron	Подсистема Cron
10	authpriv	Сообщения безопасности / аутентификации
11	ftp	Демон FTP
12	нтп	Подсистема NTP
13	безопасность	Журнал аудита
14	консоль	Журнал оповещения
15	solaris-cron	Демон планирования
16–23	local0 - local7	Местные объекты

Сопоставление кода объекта и ключевого слова неодинаково в разных операционных системах и реализациях системного журнала.

Уровень опасности

Список степеней серьезности также определен стандартом:

Ценить	Строгость	Ключевое слово	Устаревшие ключевые слова	Описание	Состояние
0	Скорая медицинская помощь	`emerg`	`panic`	Система непригодна для использования	Состояние паники.
1	Тревога	`alert`		Действия должны быть предприняты немедленно	Состояние, которое следует исправить немедленно, например повреждение системной базы данных.
2	Критический	`crit`		Критические условия	Ошибки аппаратного устройства.
3	Ошибка	`err`	`error`	Условия ошибки
4	Предупреждение	`warning`	`warn`	Условия предупреждения
5	Уведомление	`notice`		Нормальные, но важные условия	Условия, которые не являются ошибочными, но могут потребовать особой обработки.
6	Информационная	`info`		Информационные сообщения
7	Отлаживать	`debug`		Сообщения уровня отладки	Сообщения, которые содержат информацию, обычно используемую только при отладке программы.

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

Серверный процесс, который обрабатывает отображение сообщений, обычно включает все более низкие (более серьезные) уровни, когда требуется отображение менее серьезных уровней. То есть, если сообщения разделены по индивидуальной серьезности, запись уровня предупреждения также будет включена при фильтрации сообщений Notice , Info и Debug .

Сообщение

В RFC 3164 компонент сообщения (известный как MSG) был определен как имеющий следующие поля: TAG , который должен быть именем программы или процесса, сгенерировавшего сообщение, и CONTENT, который содержит детали сообщения.

Описанный в RFC 5424, «MSG - это то, что в RFC 3164 называлось КОНТЕНТОМ. ТЕГ теперь является частью заголовка, но не как единое поле. ТЕГ был разделен на APP-NAME, PROCID и MSGID. Это не полностью напоминает использование TAG, но обеспечивает ту же функциональность для большинства случаев ». Популярные инструменты системного журнала, такие как Rsyslog, соответствуют этому новому стандарту.

Поле содержимого должно быть закодировано в наборе символов UTF-8, и следует избегать значений октетов в традиционном диапазоне управляющих символов ASCII .

Регистратор

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

Для отображения и мониторинга собранных журналов необходимо использовать клиентское приложение или получить доступ к файлу журнала непосредственно в системе. Основные инструменты командной строки - это tail и grep . Серверы журналов можно настроить для отправки журналов по сети (в дополнение к локальным файлам). Некоторые реализации включают программы отчетов для фильтрации и отображения сообщений системного журнала.

Сетевой протокол

При работе в сети syslog использует архитектуру клиент-сервер, в которой сервер прослушивает хорошо известный или зарегистрированный порт на предмет запросов протокола от клиентов. Исторически наиболее распространенным протоколом транспортного уровня для ведения сетевых журналов был протокол дейтаграмм пользователя (UDP), при этом сервер прослушивал порт 514. Поскольку в UDP отсутствуют механизмы управления перегрузкой, в реализациях требуется поддержка безопасности транспортного уровня, которая рекомендуется для общего использования при передаче. Порт протокола управления (TCP) 6514.

Ограничения

Поскольку каждый процесс, приложение и операционная система были написаны независимо, полезная нагрузка сообщения журнала не отличается единообразием. По этой причине не делается никаких предположений о его форматировании или содержании. Сообщение системного журнала отформатировано (RFC 5424 дает определение расширенной формы Бэкуса – Наура (ABNF)), но его поле MSG - нет.

Сетевой протокол - это симплексная связь , без каких-либо средств подтверждения доставки отправителю.

Перспективы

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

Положения, такие как Закон Сарбейнса-Оксли , PCI DSS , HIPAA и многие другие, требуют от организаций внедрения комплексных мер безопасности, которые часто включают сбор и анализ журналов из множества различных источников. Формат системного журнала доказал свою эффективность при консолидации журналов, поскольку существует множество инструментов с открытым исходным кодом и проприетарных инструментов для создания отчетов и анализа этих журналов. Существуют утилиты для преобразования из журнала событий Windows и других форматов журналов в системный журнал.

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

Стандартные Интернет-документы

Протокол системного журнала определяется документами запроса комментариев (RFC), опубликованными инженерной группой Интернета ( стандарты Интернета ). Ниже приводится список RFC, определяющих протокол системного журнала:

Протокол системного журнала BSD . RFC 3164 .(устарело протоколом Syslog . RFC 5424 .)
Надежная доставка системного журнала . RFC 3195 .
Протокол системного журнала . RFC 5424 .
Отображение транспорта TLS для системного журнала . RFC 5425 .
Передача сообщений системного журнала по UDP . RFC 5426 .
Текстовые соглашения для управления системным журналом . RFC 5427 .
Подписанные сообщения системного журнала . RFC 5848 .
Транспортное сопоставление безопасности транспортного уровня дейтаграмм (DTLS) для системного журнала . RFC 6012 .
Передача сообщений системного журнала по TCP . RFC 6587 .

Languages

In other projects