syslog (англ. system log — системный журнал) — стандарт отправки и регистрации сообщений о происходящих в системе событиях (то есть создания событийных журналов), использующийся в компьютерных сетях, работающих по протоколу IP. Термином «syslog» называют как ныне стандартизированный сетевой протокол syslog, так и программное обеспечение (приложение, библиотеку), которое занимается отправкой и получением системных сообщений.
| Syslog | |
|---|---|
| Название | Syslog Protocol |
| Уровень (по модели OSI) | Прикладной |
| Семейство | UDP/TCP |
| Порт/ID | 514/UDP, 601/TCP, 6514/UDP, 6514/TCP |
| Назначение протокола | Передача и регистрация сообщений о событиях |
| Спецификация | RFC 3164, RFC 3195, RFC 5424, RFC 5425, RFC 5426, RFC 5427, RFC 5674, RFC 5675, RFC 5676, RFC 5848, RFC 6012, RFC 6587 |
| Основные реализации (клиенты) | Встроен в большинство сетевых ОС и во множество сетевых устройств |
| Основные реализации (серверы) | Встроен в большинство сетевых ОС |
| Коды уровней важности сообщений | |
|---|---|
| 0 | (Emergency) система не работоспособна |
| 1 | (Alert) система требует немедленного вмешательства |
| 2 | (Critical) состояние системы критическое |
| 3 | (Error) сообщения об ошибках |
| 4 | (Warning) предупреждения о возможных проблемах |
| 5 | (Notice) сообщения о нормальных, но важных событиях |
| 6 | (Informational) информационные сообщения |
| 7 | (Debug) отладочные сообщения |
| Коды категорий субъектов, формирующих сообщения | |
|---|---|
| 0 | ядро операционной системы |
| 1 | программное обеспечение пользователя |
| 2 | почтовая система |
| 3 | системные службы (daemons) |
| 4 | сообщения безопасности (авторизации) |
| 5 | собственные сообщения syslogd |
| 6 | подсистема печати |
| 7 | подсистема новостных групп (телеконференций, NNTP) |
| 8 | подсистема UUCP |
| 9 | службы времени |
| 10 | сообщения безопасности (авторизации) |
| 11 | служба FTP |
| 12 | подсистема NTP |
| 13 | журнал аудита |
| 14 | аварийный журнал |
| 15 | службы времени |
| 16 | локальный 0 |
| 17 | локальный 1 |
| 18 | локальный 2 |
| 19 | локальный 3 |
| 20 | локальный 4 |
| 21 | локальный 5 |
| 22 | локальный 6 |
| 23 | локальный 7 |
Впервые стандарт реализован на платформе BSD Эриком Оллманом как часть проекта Sendmail[1], впоследствии, благодаря простоте и масштабируемости, получил широкое распространение на Unix- и Linux-платформах и реализован во многих сетевых устройствах.
Механизм
правитьСтандартом предусматривается, что источники формируют простые текстовые сообщения о происходящих в них событиях и передают их на обработку серверу Syslog (называемому «syslogd», «syslog daemon», либо же, «syslog server»), используя один из сетевых протоколов семейства IP (UDP или TCP). Формирование сообщений о событиях и их передача происходит по определённым правилам, называемым протоколом Syslog. Как правило сообщение имеет небольшой размер (до 1024 байт[2]) и отсылается в открытом виде. Тем не менее, при использовании специальных средств (таких, как Stunnel, sslio или sslwrap), возможно шифрование сообщений и отправка их по SSL/TLS.
Поскольку источники сообщений и сервер Syslog могут располагаться на разных машинах, это позволяет организовать сбор и хранение сообщений от множества географически разнесённых разнородных источников в едином хранилище (репозитории), что чрезвычайно важно для администраторов сетей, которые могут и не иметь физического доступа сразу ко всем устройствам и компьютерам в сети.
Также серверы Syslog, как правило, могут не только регистрировать сообщения, но и пересылать их другим серверам Syslog, основываясь на уровне важности сообщения (Severity) и категории сформировавшего сообщение субъекта (Facility), что позволяет организовать, например, иерархическую систему хранилищ. А это может помочь, например, снизить время реакции персонала на критические события. Допустим, что существует некая крупная сеть, состоящая из нескольких сегментов. В каждом сегменте есть свой сервер Syslog, получающий сообщения только от источников внутри своего сегмента. Если эти низовые серверы настроить так, чтобы они пересылали сообщения критического уровня важности и выше на один общий головной сервер, то администратору сети, контролирующему через него всю сеть, будет легче отследить возникновение критической ситуации, поскольку таких сообщений немного и они не утонут в потоке нужных, но менее важных сообщений.
Текущая версия протокола Syslog предлагает усовершенствованный формат сообщений, позволяющий использовать точную отметку времени создания сообщения и осуществлять надежную идентификацию источника сообщения, а также применять кодировку UTF-8 для текста сообщения, что позволяет решить проблему интернационализации. Необязательные дополнительные поля (структурированные данные) могут использоваться для передачи различной информации, например, о погрешности локальных часов источника сообщения и точности их синхронизации с внешними часами точного времени, о языке, на котором написано сообщение, и т. д. Ввиду отмены привязки к конкретному транспорту, протокол Syslog может использовать любой из описанных в отдельных RFC механизмов доставки сообщений, но предпочтение отдается транспортам TLS.
Стандартизация
правитьДолгое время syslog использовался как стандарт де-факто без каких-либо формальных спецификаций, из-за чего существовало множество реализаций, некоторые из которых были несовместимы друг с другом. Первые шаги по решению этой проблемы были предприняты в 2001 году — протокол syslog был описан в RFC 3164. Формальная спецификация, стандартизация содержания сообщений и механизм их передачи были выпущены в 2005 году.
Вышедший в августе 2001 года информационный RFC 3164 «The BSD Syslog Protocol» (Протокол BSD Syslog) описал сложившееся на момент публикации состояние. В результате проведенной работы по анализу существующих реализаций были определены место и значимость протокола Syslog в информационных системах, формализована структура сообщений, рассмотрены базовые модели развертывания и сформулированы возможные проблемы безопасности. В качестве транспортного механизма был заявлен UDP (порт 514) из семейства IPv4, а также введены некоторые ограничения, связанные с использованием данного транспорта.
В ноябре 2001 года вышел RFC 3195 «Reliable Delivery for Syslog» (Гарантированная доставка для Syslog), в котором предлагалось решение, позволяющее повысить надежность протокола Syslog за счет применения определённой реализации каркасов BEEP[3] в качестве носителя сообщений и использования TCP (порт 601) из семейства IPv4 в качестве транспорта.
Март 2009 года ознаменовался выходом целой группы RFC, предложивших достаточно серьёзные усовершенствования протокола Syslog.
RFC 5424 «The Syslog Protocol» (Протокол Syslog), во-первых, постулировал, что в качестве механизма доставки сообщений может быть использован любой транспорт, и поэтому из описания протокола были исключены определения транспортных механизмов и, соответственно, описание ограничений и проблем безопасности, напрямую связанных с конкретным транспортом. Во-вторых, предложил новый формат сообщения, предполагающий наличие в теле сообщения, кроме заголовка и текста, ещё и набор структурированных данных, элементы которых либо непосредственно зарегистрированы в IANA, либо управление ими делегируется предприятиям, зарегистрировавшим в IANA свой личный номер в соответствии со SMIv2. Кроме того, новый формат сообщения позволяет с большей точностью локализовать источник и время создания сообщения. В-третьих, продолжая процесс интернационализации, предложил использовать для текста сообщения кодировку UTF-8 в качестве предпочтительной.
RFC 5425 «Transport Layer Security (TLS) Transport Mapping for Syslog» (Механизм доставки для Syslog, обеспечивающий безопасность на транспортном уровне (TLS)) описал применение механизма TLS для доставки сообщений с использованием TCP (порт 6514) из семейства IPv4/v6 в качестве транспорта, его ограничения и проблемы безопасности.
RFC 5426 «Transmission of Syslog Messages over UDP» (Передача сообщений Syslog через UDP) описал механизм доставки сообщений, не использующий TLS, посредством UDP (порт 514) из семейства IPv4/v6 в качестве транспорта, его ограничения и проблемы безопасности.
RFC 5427 «Textual Conventions for Syslog Management» (Текстовые соглашения для управления Syslog) задал набор текстовых соглашений, описывающих важность (Severity) и категорию (Facility) сообщений Syslog в формате MIB, чтобы другие модули MIB могли их использовать в процессе определения управляемых объектов.
В октябре 2009 года увидела свет ещё одна группа RFC, связывающая управление объектами с протоколом Syslog.
RFC 5674 «Alarms in Syslog» (Аварийные сигналы в Syslog) открыл путь к использованию базы аварийных сигналов IETF (Alarm MIB) в сообщениях Syslog.
Задачи, решаемые RFC 5675 «Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages» (Механизм трансляции уведомлений протокола простого управления сетями (SNMP) в сообщения Syslog) и RFC 5676 «Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications» (Определения управляемых объектов для механизма трансляции сообщений Syslog в уведомления протокола простого управления сетями (SNMP)), понятны из названий документов.
Вышедший в мае 2010 года RFC 5848 «Signed Syslog Messages» (Подписанные сообщения Syslog) описал применение криптографической подписи в сообщениях Syslog.
В октябре 2010 года вышел RFC 6012 «Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog» (Механизм доставки для Syslog, обеспечивающий безопасность датаграмм на транспортном уровне (DTLS)), предложивший применение механизма TLS для доставки сообщений с использованием UDP (порт 6514) из семейства IPv4/v6 в качестве транспорта, его ограничения и проблемы безопасности.
Вышедший в апреле 2012 года RFC 6587 «Transmission of Syslog Messages over TCP» (Передача сообщений Syslog через TCP) описал сложившиеся механизмы доставки сообщений, не использующие TLS, посредством TCP из семейства IPv4/v6 в качестве транспорта, их ограничения и проблемы безопасности.
Таким образом, следующие стандарты RFC, изданные IETF, описывают протокол syslog[4]:
- RFC 3164 — The BSD Syslog Protocol, August 2001 (Протокол BSD Syslog, отменен RFC 5424)
- RFC 3195 — Reliable Delivery for Syslog, November 2001 (Гарантированная доставка для Syslog)
- RFC 5424[5] — The Syslog Protocol, March 2009 (Протокол Syslog)
- RFC 5425 — Transport Layer Security (TLS) Transport Mapping for Syslog, March 2009 (Механизм доставки для Syslog, обеспечивающий безопасность на транспортном уровне (TLS))
- RFC 5426[6] — Transmission of Syslog Messages over UDP, March 2009 (Передача сообщений Syslog через UDP)
- RFC 5427 — Textual Conventions for Syslog Management, March 2009 (Текстовые соглашения для управления Syslog)
- RFC 5674 — Alarms in Syslog, October 2009 (Аварийные сигналы в Syslog)
- RFC 5675 — Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages, October 2009 (Механизм трансляции уведомлений протокола простого управления сетями (SNMP) в сообщения Syslog)
- RFC 5676 — Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications, October 2009 (Определения управляемых объектов для механизма трансляции сообщений Syslog в уведомления протокола простого управления сетями (SNMP))
- RFC 5848 — Signed Syslog Messages, May 2010 (Подписанные сообщения Syslog)
- RFC 6012 — Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog, October 2010 (Механизм доставки для Syslog, обеспечивающий безопасность датаграмм на транспортном уровне (DTLS))
- RFC 6587 — Transmission of Syslog Messages over TCP, April 2012 (Передача сообщений Syslog через TCP)
Примечания
править- ↑ «One of the successful side projects from sendmail was syslog.» (Одним из успешных побочных проектов, выросших из sendmail, был syslog.) The Architecture of Open Source Applications, Volume I, Part 17, Sendmail (Eric Allman) Архивная копия от 27 декабря 2012 на Wayback Machine
- ↑ Это общее ограничение, введённое в RFC 3164, отменено в RFC 5424. Поскольку ограничения на длину сообщения зависят от транспорта, то они вынесены в отдельные RFC, описывающие транспортные механизмы.
- ↑ См. RFC 3080 «The Blocks Extensible Exchange Protocol Core».
- ↑ В настоящее время (январь 2013 года) рабочие группы IETF также работают над черновиками «Syslog Extension for Cloud Using Syslog Structured Data» Архивная копия от 4 марта 2016 на Wayback Machine и «Syslog Format for NAT Logging» Архивная копия от 23 декабря 2012 на Wayback Machine.
- ↑ RFC 5424 на русском языке. Дата обращения: 27 ноября 2014. Архивировано 19 декабря 2014 года.
- ↑ RFC 5426 на русском языке. Дата обращения: 27 ноября 2014. Архивировано 19 декабря 2014 года.
В статье не хватает ссылок на источники (см. рекомендации по поиску). |