RFC 5424 · март 2009
Протокол syslog
Автор: R. Gerhards, Adiscon GmbH. Категория: процесс стандартизации. Март 2009. Заменяет RFC 3164.
Статус документа
Этот документ определяет протокол процесса стандартизации Интернета для интернет-сообщества и приглашает к обсуждению и предложениям по улучшению. Состояние стандартизации и статус протокола приведены в текущем издании «Официальных стандартов протоколов Интернета» (STD 1). Распространение документа не ограничено.
Уведомление об авторских правах
Copyright (c) 2009 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.
На документ распространяются BCP 78 и Правовые положения IETF Trust, относящиеся к документам IETF, действовавшие на дату его публикации (http://trustee.ietf.org/license-info). Внимательно ознакомьтесь с ними: они описывают ваши права и ограничения в отношении документа.
Документ может содержать материалы из документов или вкладов IETF, опубликованных либо предоставленных для публичного доступа до 10 ноября 2008 года. Лица, обладающие авторскими правами на некоторые из этих материалов, могли не предоставить IETF Trust право разрешать изменения таких материалов вне процесса стандартизации IETF. Без получения надлежащей лицензии от обладателей авторских прав на такие материалы документ нельзя изменять вне процесса стандартизации IETF или создавать на его основе производные произведения вне этого процесса, кроме форматирования для публикации в качестве RFC или перевода на другие языки.
Аннотация
Документ описывает протокол syslog, используемый для передачи сообщений об уведомлениях о событиях. Протокол имеет многоуровневую архитектуру, позволяющую использовать любое количество транспортных протоколов для передачи сообщений syslog. Он также определяет формат сообщений, позволяющий структурированно предоставлять расширения, специфичные для производителя.
Документ написан с учётом первоначальных целей разработки традиционного syslog. Необходимость новой многоуровневой спецификации возникла потому, что стандартизации надёжных и защищённых расширений syslog мешает отсутствие независимого от транспорта RFC процесса стандартизации. Без этого документа каждому другому стандарту пришлось бы определять собственный формат пакета syslog и транспортный механизм, что со временем привело бы к трудноуловимым проблемам совместимости. Документ призван создать основу для расширений syslog. Многоуровневый подход также позволяет написать код для каждой функции syslog один раз вместо отдельной реализации для каждого транспорта.
Документ заменяет RFC 3164.
1. Введение
Документ описывает многоуровневую архитектуру syslog. Её цель — отделить содержимое сообщения от транспорта и обеспечить простое расширение каждого уровня.
Документ описывает стандартный формат сообщений syslog и концепцию отображений на транспортные протоколы. Он также описывает элементы структурированных данных для передачи легко разбираемой структурированной информации и допускает расширения производителей.
Документ не описывает формат хранения сообщений syslog: он выходит за рамки протокола syslog и не нужен для совместимости систем.
Документ написан с учётом первоначальных целей разработки традиционного syslog. Необходимость новой многоуровневой спецификации возникла потому, что стандартизации надёжных и защищённых расширений syslog мешает отсутствие независимого от транспорта RFC процесса стандартизации. Без него каждому другому стандарту пришлось бы определять собственный формат пакета syslog и транспортный механизм, что со временем привело бы к трудноуловимым проблемам совместимости. Документ создаёт основу для расширений syslog. Многоуровневая архитектура также позволяет написать код для каждой функции syslog один раз вместо отдельной реализации для каждого транспорта.
Документ заменяет RFC 3164 — информационный документ, описывающий некоторые существующие реализации.
2. Соглашения, используемые в документе
Ключевые слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY и OPTIONAL следует толковать согласно RFC 2119 [RFC2119].
3. Определения
Syslog использует три уровня:
— «содержимое syslog» — управляющая информация внутри сообщения syslog; — уровень «приложение syslog» отвечает за формирование, интерпретацию, маршрутизацию и хранение сообщений syslog; — уровень «транспорт syslog» передаёт сообщения в сеть и принимает их из сети.
На каждом концептуальном уровне выполняются определённые функции:
— «источник» (originator) создаёт содержимое syslog для передачи в сообщении; — «сборщик» (collector) собирает содержимое syslog для дальнейшего анализа; — «ретранслятор» (relay) пересылает сообщения, принимая их от источников или других ретрансляторов и отправляя сборщикам или другим ретрансляторам; — «транспортный отправитель» передаёт сообщения syslog определённому транспортному протоколу; — «транспортный получатель» получает сообщения syslog от определённого транспортного протокола.
На схеме 1 элементы разделены по уровням.
+---------------------+ +---------------------+
| содержимое | | содержимое |
|---------------------| |---------------------|
| приложение syslog | | приложение syslog | источник, сборщик,
| | | | ретранслятор
|---------------------| |---------------------|
| транспорт syslog | | транспорт syslog | транспортный отправитель,
| | | | транспортный получатель
+---------------------+ +---------------------+
^ ^
| |
--------------------------
Схема 1. Уровни syslog.
4. Основные принципы
К обмену syslog применяются следующие принципы:
— протокол syslog не подтверждает доставку сообщений. Хотя некоторые транспорты могут предоставлять сведения о состоянии, концептуально syslog — чисто однонаправленный протокол связи; — источники и ретрансляторы могут настраиваться на отправку одного сообщения нескольким сборщикам и ретрансляторам; — функции источника, ретранслятора и сборщика могут находиться в одной системе.
4.1. Примеры сценариев развёртывания
На схеме 2 показаны примеры сценариев развёртывания. Другие сочетания этих примеров также допустимы. Как отмечено, на схеме ретрансляторы могут отправлять все или некоторые полученные сообщения, а также сообщения, которые они создают сами. Прямоугольники обозначают приложения с поддержкой syslog. На схеме Originator — источник, Relay — ретранслятор, Collector — сборщик.
+----------+ +---------+ |Originator|---->----|Collector| +----------+ +---------+
+----------+ +-----+ +---------+ |Originator|---->----|Relay|---->----|Collector| +----------+ +-----+ +---------+
+----------+ +-----+ +-----+ +---------+ |Originator|-->--|Relay|-->--..-->--|Relay|-->--|Collector| +----------+ +-----+ +-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
| |-+ +-----+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +---------+
|Originator|---->----|Collector|
| |-+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->-------|Collector|
| |-+ +-----+ +---| |
+----------+ \ / +---------+
\ +-----+ /
+->--|Relay|-->--/
+-----+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->--------------|Collector|
| |-+ +-----+ +--| |
+----------+ \ / +---------+
\ +------------+ /
\ |+----------+| /
+->-||Relay ||->---/
|+----------|| /
||Originator||->-/
|+----------+|
+------------+
Схема 2. Некоторые возможные сценарии развёртывания syslog.
5. Протокол транспортного уровня
Документ не определяет транспортный протокол. Вместо этого он описывает формат сообщения syslog независимо от транспортного уровня. Транспорты syslog определены в других документах. Один из них определён в [RFC5426] и соответствует традиционному транспорту UDP. Он необходим для сохранения совместимости, поскольку исторически сообщения syslog передавались через UDP.
Любой транспортный протокол syslog НЕ ДОЛЖЕН (MUST NOT) намеренно изменять сообщение syslog. Если транспортному протоколу необходимо выполнить временные преобразования на стороне транспортного отправителя, транспортный протокол ОБЯЗАН (MUST) обратить их на стороне транспортного получателя так, чтобы ретранслятор или сборщик получил точную копию сообщения, созданного источником или ретранслятором. Иначе нарушится работа сквозных криптографических средств проверки, например подписей. Разумеется, сообщение может измениться из-за ошибок передачи или других проблем. Защита от таких изменений выходит за рамки документа.
5.1. Минимально необходимое отображение на транспорт
Все реализации спецификации ОБЯЗАНЫ (MUST) поддерживать транспорт на основе TLS согласно [RFC5425].
Всем реализациям спецификации также СЛЕДУЕТ (SHOULD) поддерживать транспорт на основе UDP согласно [RFC5426].
При развёртывании реализации спецификации РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать транспорт на основе TLS.
6. Формат сообщения syslog
Сообщение syslog имеет следующее определение ABNF [RFC5234]:
SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]
HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME
SP APP-NAME SP PROCID SP MSGID
PRI = "<" PRIVAL ">"
PRIVAL = 1*3DIGIT ; диапазон 0 .. 191
VERSION = NONZERO-DIGIT 0*2DIGIT
HOSTNAME = NILVALUE / 1*255PRINTUSASCII
APP-NAME = NILVALUE / 1*48PRINTUSASCII
PROCID = NILVALUE / 1*128PRINTUSASCII
MSGID = NILVALUE / 1*32PRINTUSASCII
TIMESTAMP = NILVALUE / FULL-DATE "T" FULL-TIME
FULL-DATE = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY
DATE-FULLYEAR = 4DIGIT
DATE-MONTH = 2DIGIT ; 01-12
DATE-MDAY = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 в зависимости
; от месяца и года
FULL-TIME = PARTIAL-TIME TIME-OFFSET
PARTIAL-TIME = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND
[TIME-SECFRAC]
TIME-HOUR = 2DIGIT ; 00-23
TIME-MINUTE = 2DIGIT ; 00-59
TIME-SECOND = 2DIGIT ; 00-59
TIME-SECFRAC = "." 1*6DIGIT
TIME-OFFSET = "Z" / TIME-NUMOFFSET
TIME-NUMOFFSET = ("+" / "-") TIME-HOUR ":" TIME-MINUTE
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME
PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING ; символы '"', '\' и
; ']' ДОЛЖНЫ экранироваться.
SD-NAME = 1*32PRINTUSASCII
; кроме '=', SP, ']', %d34 (")
MSG = MSG-ANY / MSG-UTF8
MSG-ANY = *OCTET ; не начинается с BOM
MSG-UTF8 = BOM UTF-8-STRING
BOM = %xEF.BB.BF
UTF-8-STRING = *OCTET ; строка UTF-8 согласно
; RFC 3629
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
NILVALUE = "-"
6.1. Длина сообщения
Ограничения размера сообщения syslog определяются используемым отображением syslog на транспорт. Самого по себе верхнего предела нет. Каждое отображение на транспорт определяет минимальную максимальную длину сообщения, которую требуется поддерживать; этот минимум максимума ОБЯЗАТЕЛЬНО (MUST) составляет не менее 480 октетов.
Любой транспортный получатель ОБЯЗАН (MUST) принимать сообщения длиной до 480 октетов включительно. Всем реализациям транспортного получателя СЛЕДУЕТ (SHOULD) принимать сообщения длиной до 2048 октетов включительно. Транспортные получатели МОГУТ (MAY) получать сообщения длиннее 2048 октетов. Получив сообщение длиннее поддерживаемого предела, транспортному получателю СЛЕДУЕТ (SHOULD) усечь полезную нагрузку; в качестве альтернативы он МОЖЕТ (MAY) отбросить сообщение.
Если транспортный получатель усекает сообщения, усечение ОБЯЗАТЕЛЬНО (MUST) происходит в конце сообщения. После усечения сообщение МОЖЕТ (MAY) содержать недопустимую кодировку UTF-8 или некорректные STRUCTURED-DATA. В этом случае транспортный получатель МОЖЕТ (MAY) отбросить сообщение или попытаться обработать максимально возможную его часть.
6.2. HEADER
Набор символов HEADER ОБЯЗАТЕЛЬНО (MUST) представляет собой семибитовый ASCII в восьмибитовом поле согласно [RFC5234]. Это коды ASCII, определённые в «USA Standard Code for Information Interchange» [ANSI.X3-4.1968].
Формат заголовка рассчитан на некоторую совместимость со старым syslog на основе BSD. Подробности приведены в приложении A.1.
6.2.1. PRI
Часть PRI ОБЯЗАНА (MUST) содержать три, четыре или пять символов и начинаться и заканчиваться угловыми скобками. PRI начинается с «<» — символа меньше, %d60, — затем следует число и «>» — символ больше, %d62. Число в угловых скобках называется значением приоритета Priority (PRIVAL) и представляет одновременно Facility и Severity. Оно состоит из одной, двух или трёх десятичных цифр ABNF DIGIT со значениями от %d48 для «0» до %d57 для «9».
Значения Facility и Severity не являются нормативными, но часто используются. Следующие таблицы приведены исключительно для информации. Значения Facility ОБЯЗАТЕЛЬНО (MUST) находятся в диапазоне от 0 до 23 включительно.
Код Facility 0 сообщения ядра 1 сообщения пользовательского уровня 2 почтовая система 3 системные демоны 4 сообщения безопасности/авторизации 5 сообщения, создаваемые внутри syslogd 6 подсистема построчного принтера 7 подсистема сетевых новостей 8 подсистема UUCP 9 демон часов 10 сообщения безопасности/авторизации 11 демон FTP 12 подсистема NTP 13 аудит журнала 14 предупреждение журнала 15 демон часов (примечание 2) 16 локальное использование 0 (local0) 17 локальное использование 1 (local1) 18 локальное использование 2 (local2) 19 локальное использование 3 (local3) 20 локальное использование 4 (local4) 21 локальное использование 5 (local5) 22 локальное использование 6 (local6) 23 локальное использование 7 (local7)
Таблица 1. Категории Facility сообщений syslog.
Приоритет каждого сообщения также имеет десятичный показатель уровня важности Severity. Они описаны ниже вместе с числовыми значениями. Значения Severity ОБЯЗАТЕЛЬНО (MUST) находятся в диапазоне от 0 до 7 включительно.
Код Severity 0 Emergency: система непригодна к использованию 1 Alert: необходимо немедленное действие 2 Critical: критические условия 3 Error: условия ошибки 4 Warning: предупреждающие условия 5 Notice: нормальное, но значимое условие 6 Informational: информационные сообщения 7 Debug: сообщения уровня отладки
Таблица 2. Уровни Severity сообщений syslog.
Значение Priority вычисляется умножением номера Facility на 8 с последующим прибавлением числового значения Severity. Например, сообщение ядра с Facility=0 и уровнем Emergency, Severity=0, имеет приоритет 0. Сообщение local use 4 с Facility=20 и уровнем Notice, Severity=5, имеет приоритет 165. В PRI сообщения syslog они записываются между угловыми скобками как <0> и <165> соответственно. Ноль непосредственно после «<» допустим только для значения приоритета 0. В остальных случаях ведущие нули НЕ ДОЛЖНЫ (MUST NOT) использоваться.
6.2.2. VERSION
Поле VERSION обозначает версию спецификации протокола syslog. Номер версии ОБЯЗАТЕЛЬНО (MUST) увеличивается при любой новой спецификации syslog, изменяющей какую-либо часть формата HEADER. Изменения включают добавление или удаление полей либо изменение синтаксиса или семантики существующих полей. Документ использует VERSION со значением 1. Значения VERSION назначаются IANA (раздел 9.1) методом Standards Action согласно [RFC5226].
6.2.3. TIMESTAMP
Поле TIMESTAMP — формализованная временная отметка на основе [RFC3339].
Хотя [RFC3339] допускает несколько вариантов синтаксиса, документ вводит дополнительные ограничения. Значение TIMESTAMP ОБЯЗАТЕЛЬНО (MUST) соответствует следующим ограничениям:
— символы T и Z ОБЯЗАТЕЛЬНО (MUST) записываются прописными буквами; — использование символа T ОБЯЗАТЕЛЬНО (REQUIRED); — високосные секунды НЕ ДОЛЖНЫ (MUST NOT) использоваться.
Источнику СЛЕДУЕТ (SHOULD) включать TIME-SECFRAC, если позволяют точность часов и производительность. Идентификатор структурированных данных timeQuality, описанный в разделе 7.1, позволяет источнику указать точность и достоверность временной отметки.
Приложение syslog ОБЯЗАНО (MUST) использовать NILVALUE в качестве TIMESTAMP, если оно не способно получить системное время.
6.2.3.1. Примеры
Пример 1: 1985-04-12T23:20:50.52Z
Это 20 минут и 50,52 секунды после 23 часов 12 апреля 1985 года по UTC.
Пример 2: 1985-04-12T19:20:50.52-04:00
Это то же время, что в примере 1, но выраженное по восточному стандартному времени США с учётом летнего времени.
Пример 3: 2003-10-11T22:14:15.003Z
Это 11 октября 2003 года, 22:14:15 и 3 миллисекунды следующей секунды по UTC. Отметка имеет миллисекундное разрешение. Фактическое разрешение источника могло быть лучше, но три цифры дробной части секунды этого не показывают.
Пример 4: 2003-08-24T05:14:15.000003-07:00
Это 24 августа 2003 года, 05:14:15 и 3 микросекунды следующей секунды. Дополнительные цифры TIME-SECFRAC указывают микросекундное разрешение. Местное время отметки отстаёт от UTC на семь часов. Такая отметка могла быть создана в тихоокеанском часовом поясе США в период летнего времени.
Пример 5 — недействительная TIMESTAMP: 2003-08-24T05:14:15.000000003-07:00
Пример почти совпадает с примером 4, но задаёт TIME-SECFRAC в наносекундах. В результате TIME-SECFRAC превышает допустимые шесть цифр и является недействительным.
6.2.4. HOSTNAME
Поле HOSTNAME идентифицирует машину, первоначально отправившую сообщение syslog.
Полю HOSTNAME СЛЕДУЕТ (SHOULD) содержать имя хоста и доменное имя источника в формате STD 13 [RFC1034]. В документе этот формат называется полностью определённым доменным именем (FQDN).
На практике не все приложения syslog способны предоставить FQDN, поэтому в HOSTNAME МОГУТ (MAY) присутствовать другие значения. Документ предусматривает их использование в таких ситуациях. Приложению syslog СЛЕДУЕТ (SHOULD) сначала предоставлять наиболее конкретное доступное значение. Порядок предпочтения содержимого HOSTNAME:
1. FQDN; 2. статический IP-адрес; 3. имя хоста; 4. динамический IP-адрес; 5. NILVALUE.
Если используется адрес IPv4, он ОБЯЗАТЕЛЬНО (MUST) записывается в десятичной форме с точками согласно STD 13 [RFC1035]. Если используется IPv6, ОБЯЗАТЕЛЬНО (MUST) применяется действительное текстовое представление согласно разделу 2.2 [RFC4291].
Приложениям syslog СЛЕДУЕТ (SHOULD) последовательно использовать одно значение HOSTNAME как можно дольше.
NILVALUE СЛЕДУЕТ (SHOULD) использовать только когда приложение syslog никак не может получить настоящее имя хоста. Такая ситуация считается крайне маловероятной.
6.2.5. APP-NAME
Полю APP-NAME СЛЕДУЕТ (SHOULD) идентифицировать устройство или приложение, создавшее сообщение. Это строка без дополнительной семантики, предназначенная для фильтрации сообщений ретранслятором или сборщиком.
NILVALUE МОЖНО (MAY) использовать, когда приложение syslog не знает своего APP-NAME или не может предоставить эту информацию. Устройство может быть не способно предоставить её по решению локальной политики, из-за отсутствия информации или её неприменимости к устройству.
Поле МОЖЕТ (MAY) назначаться оператором.
6.2.6. PROCID
PROCID — включаемое в сообщение значение без совместимого между реализациями значения, кроме того, что его изменение указывает на прерывность формирования сообщений syslog. Поле не имеет определённого синтаксиса или семантики; значение зависит от реализации и/или назначается оператором. Если значение не предоставлено, МОЖНО (MAY) использовать NILVALUE.
PROCID часто используется для передачи имени или идентификатора процесса, связанного с системой syslog. При отсутствии идентификатора процесса может использоваться NILVALUE. Во встроенной системе без идентификаторов процессов операционной системы PROCID может быть идентификатором перезагрузки.
PROCID позволяет анализаторам журналов обнаруживать прерывания формирования сообщений syslog по изменению идентификатора процесса syslog. Однако это ненадёжный признак перезапуска процесса: перезапущенному процессу syslog может быть назначен тот же идентификатор, что и предыдущему.
PROCID также позволяет определить принадлежность сообщений к группе. Например, почтовый агент передачи SMTP может поместить в PROCID идентификатор транзакции SMTP, чтобы сборщик или ретранслятор группировал сообщения по транзакции.
6.2.7. MSGID
Полю MSGID СЛЕДУЕТ (SHOULD) идентифицировать тип сообщения. Например, межсетевой экран может использовать MSGID TCPIN для входящего трафика TCP и TCPOUT для исходящего. Сообщения с одинаковым MSGID должны отражать события с одинаковой семантикой. Сам MSGID — строка без дополнительной семантики, предназначенная для фильтрации сообщений ретранслятором или сборщиком.
NILVALUE СЛЕДУЕТ (SHOULD) использовать, когда приложение syslog не предоставляет или не может предоставить значение.
Поле МОЖЕТ (MAY) назначаться оператором.
6.3. STRUCTURED-DATA
STRUCTURED-DATA предоставляет механизм выражения информации в чётко определённом, легко разбираемом и интерпретируемом формате данных. Сценариев применения несколько. Например, он может выражать метаданные о сообщении syslog или специфичные для приложения сведения, такие как счётчики трафика или IP-адреса.
STRUCTURED-DATA может содержать ноль, один или несколько элементов структурированных данных, называемых в документе SD-ELEMENT.
При отсутствии элементов структурированных данных поле STRUCTURED-DATA ОБЯЗАТЕЛЬНО (MUST) содержит NILVALUE.
Набор символов STRUCTURED-DATA ОБЯЗАТЕЛЬНО (MUST) представляет собой семибитовый ASCII в восьмибитовом поле согласно [RFC5234]. Это коды ASCII из «USA Standard Code for Information Interchange» [ANSI.X3-4.1968]. Исключение — поле PARAM-VALUE (раздел 6.3.3), в котором ОБЯЗАТЕЛЬНО (MUST) используется UTF-8.
Сборщик МОЖЕТ (MAY) игнорировать некорректные элементы STRUCTURED-DATA. Ретранслятор ОБЯЗАН (MUST) пересылать некорректные STRUCTURED-DATA без изменений.
6.3.1. SD-ELEMENT
SD-ELEMENT состоит из имени и пар «имя — значение» параметров. Имя называется SD-ID; пары «имя — значение» называются SD-PARAM.
6.3.2. SD-ID
SD-ID чувствительны к регистру и однозначно определяют тип и назначение SD-ELEMENT. Один SD-ID НЕ ДОЛЖЕН (MUST NOT) встречаться в сообщении более одного раза.
Существуют два формата имён SD-ID:
— имена без знака @ (ABNF %d64) зарезервированы для назначения через IETF Review согласно BCP 26 [RFC5226]. Сейчас это имена из раздела 7. Имена этого формата действительны только после регистрации в IANA. Зарегистрированные имена НЕ ДОЛЖНЫ (MUST NOT) содержать @ (ABNF %d64), знак равенства = (%d61), закрывающую квадратную скобку ] (%d93), кавычку " (%d34), пробельные или управляющие символы — код ASCII 127 и коды 32 и меньше; — любой может определить дополнительные SD-ID в формате name@<private enterprise number>, например ourSDID@32473. Формат части перед @ не определён, однако такие имена ОБЯЗАТЕЛЬНО (MUST) являются строками печатных символов US-ASCII и НЕ ДОЛЖНЫ (MUST NOT) содержать @ (%d64), = (%d61), ] (%d93), кавычку " (%d34), пробельные или управляющие символы. Часть после @ ОБЯЗАТЕЛЬНО (MUST) является частным номером предприятия согласно разделу 7.2.2. Во всём документе для таких номеров используется значение 32473, зарезервированное IANA как пример для документации. Разработчикам необходимо использовать собственный частный номер предприятия для параметра enterpriseId и создания локально расширяемых имён SD-ID.
6.3.3. SD-PARAM
Каждый SD-PARAM состоит из имени PARAM-NAME и значения PARAM-VALUE.
PARAM-NAME чувствителен к регистру. IANA контролирует все PARAM-NAME, кроме относящихся к SD-ID, имена которых содержат @. Область действия PARAM-NAME ограничена конкретным SD-ID, поэтому одинаково названные PARAM-NAME в разных SD-ID не являются одним и тем же параметром.
Для поддержки международных символов поле PARAM-VALUE ОБЯЗАТЕЛЬНО (MUST) кодируется в UTF-8. Приложение syslog МОЖЕТ (MAY) выдавать любую допустимую последовательность UTF-8. Приложение ОБЯЗАНО (MUST) принимать любую допустимую последовательность UTF-8 в «кратчайшей форме» и НЕ ДОЛЖНО (MUST NOT) отказывать при наличии управляющих символов в PARAM-VALUE. Приложение МОЖЕТ (MAY) изменять сообщения с управляющими символами, например заменять октет со значением 0 (USASCII NUL) четырьмя символами #000. По причинам, изложенным в разделе 3.1 UNICODE TR36 [UNICODE-TR36], источник ОБЯЗАН (MUST) кодировать сообщения в кратчайшей форме, а сборщик или ретранслятор НЕ ДОЛЖЕН (MUST NOT) интерпретировать сообщения в некратчайшей форме.
Внутри PARAM-VALUE символы кавычки " (ABNF %d34), обратной косой черты \ (%d92) и закрывающей квадратной скобки ] (%d93) ОБЯЗАТЕЛЬНО (MUST) экранируются во избежание ошибок разбора. Экранирование ] строго необходимо не было бы, но ОБЯЗАТЕЛЬНО (REQUIRED) по спецификации для предотвращения ошибок реализации приложений syslog. Каждый из трёх символов ОБЯЗАТЕЛЬНО (MUST) экранируется соответственно как \" , \\ и \]. Обратная косая черта применяется для экранирования управляющих символов ради согласованности с её использованием в других частях сообщения syslog и традиционном syslog.
Обратная косая черта, после которой не следует ни один из трёх указанных символов, считается недопустимой экранированной последовательностью. В этом случае обратная черта ОБЯЗАТЕЛЬНО (MUST) рассматривается как обычная обратная черта, а следующий символ — как обычный символ. Таким образом, недопустимая последовательность ОБЯЗАТЕЛЬНО (MUST) остаётся неизменной.
SD-PARAM МОЖЕТ (MAY) повторяться внутри SD-ELEMENT несколько раз.
6.3.4. Управление изменениями
После определения SD-ID и PARAM-NAME синтаксис и семантика этих объектов НЕ ДОЛЖНЫ (MUST NOT) изменяться. Если желательно изменить существующий объект, ОБЯЗАТЕЛЬНО (MUST) создаётся новый SD-ID или PARAM-NAME, а старый остаётся неизменным. В существующий SD-ID МОЖНО (MAY) добавлять НЕОБЯЗАТЕЛЬНЫЕ (OPTIONAL) PARAM-NAME.
6.3.5. Примеры
Все примеры раздела показывают только часть структурированных данных сообщения. В оригинале примеры перенесены на несколько строк для удобства чтения; каждый из них представляет собой одну строку. После каждого примера приведено описание.
Пример 1 — действительный: [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]
Это элемент структурированных данных с SD-ID exampleSDID@32473, не контролируемым IANA, и тремя параметрами.
Пример 2 — действительный: [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"]
Это тот же пример с добавлением второго элемента структурированных данных. Второй элемент следует непосредственно за первым; SP между ними нет.
Пример 3 — недействительный: [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] [examplePriority@32473 class="high"]
Пример почти совпадает со вторым, но содержит малозаметную ошибку: между элементами находится символ SP ("]SP["). Это недопустимо: поле STRUCTURED-DATA заканчивается после первого элемента, а второй интерпретируется как часть MSG.
Пример 4 — недействительный: [ exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"]
Пример почти совпадает со вторым, но содержит другую малозаметную ошибку: после открывающей скобки находится SP. SD-ID элемента структурированных данных ОБЯЗАТЕЛЬНО (MUST) следует непосредственно за открывающей скобкой, поэтому SP делает STRUCTURED-DATA недействительным. Приложение syslog МОЖЕТ (MAY) отбросить сообщение.
Пример 5 — действительный: [sigSig ver="1" rsID="1234" ... signature="..."]
Это действительный пример гипотетического SD-ID, назначенного IANA. Многоточия обозначают пропущенное для краткости содержимое.
6.4. MSG
Часть MSG содержит сообщение свободной формы со сведениями о событии.
Набору символов MSG СЛЕДУЕТ (SHOULD) быть Unicode в кодировке UTF-8 согласно [RFC3629]. Если приложение syslog не может закодировать MSG в Unicode, оно МОЖЕТ (MAY) использовать любую другую кодировку.
Приложению syslog СЛЕДУЕТ (SHOULD) избегать значений октетов меньше 32 — традиционного диапазона управляющих символов US-ASCII кроме DEL. Эти значения допустимы, но приложение syslog МОЖЕТ (MAY) изменять такие символы при получении. Например, оно может заменить их экранированной последовательностью: значение 0 может стать «\0». Приложению syslog НЕ СЛЕДУЕТ (SHOULD NOT) изменять другие значения октетов.
Если приложение syslog кодирует MSG в UTF-8, строка ОБЯЗАТЕЛЬНО (MUST) начинается с метки порядка байтов Unicode (BOM), которая для UTF-8 имеет запись ABNF %xEF.BB.BF. Приложение syslog ОБЯЗАНО (MUST) кодировать в кратчайшей форме и МОЖЕТ (MAY) использовать любую допустимую последовательность UTF-8.
Если приложение обрабатывает MSG, начинающийся с BOM, но содержащий UTF-8 не в кратчайшей форме, MSG НЕ ДОЛЖЕН (MUST NOT) интерпретироваться как закодированный в UTF-8 по причинам раздела 3.1 [UNICODE-TR36]. Рекомендации приведены в приложении A.8.
Также согласно UNICODE TR36 [UNICODE-TR36] приложение syslog НЕ ДОЛЖНО (MUST NOT) интерпретировать сообщения в некратчайшей форме и недействительные последовательности UTF-8.
6.5. Примеры
Ниже приведены примеры действительных сообщений syslog с последующим описанием каждого. Они основаны на сходных примерах [RFC3164] и могут быть знакомы читателям. Непечатаемая BOM Unicode обозначена как BOM.
Пример 1 — без STRUCTURED-DATA: <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - BOM'su root' failed for lonvick on /dev/pts/8
VERSION равен 1, Facility — 4, Severity — 2. Сообщение создано 11 октября 2003 года в 22:14:15 UTC и 3 миллисекунды следующей секунды. Источник — хост mymachine.example.com. APP-NAME — su, PROCID неизвестен, MSGID — ID47. MSG — «'su root' failed for lonvick...», закодированное в UTF-8; кодировку определяет BOM. STRUCTURED-DATA отсутствуют, что обозначено «-» в соответствующем поле.
Пример 2 — без STRUCTURED-DATA: <165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 8710 - - %% It's time to make the do-nuts.
VERSION снова равен 1, Facility — 20, Severity — 5. Сообщение создано 24 августа 2003 года в 05:14:15 со смещением −7 часов от UTC и 3 микросекунды следующей секунды. HOSTNAME — 192.0.2.1: приложение syslog не знало своего FQDN и использовало один из IPv4-адресов. APP-NAME — myproc, PROCID — 8710, например PID UNIX. STRUCTURED-DATA отсутствуют, что обозначено «-» в их поле. Конкретный MSGID отсутствует, что обозначено «-» в поле MSGID.
Сообщение — «%% It's time to make the do-nuts.». Поскольку BOM Unicode отсутствует, приложению syslog неизвестна кодировка части MSG.
Пример 3 — со STRUCTURED-DATA: <165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] BOMAn application event log entry...
Пример основан на первом, но содержит STRUCTURED-DATA: один элемент со значением [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]. Сам MSG — «An application event log entry...». BOM в начале MSG указывает на UTF-8.
Пример 4 — только STRUCTURED-DATA: <165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"]
Пример показывает действительное сообщение только с STRUCTURED-DATA, без части MSG.
7. Идентификаторы структурированных данных
В разделе определены первоначальные SD-ID, зарегистрированные IANA. Определение элементов структурированных данных приведено в разделе 6.3. Все определённые здесь SD-ID НЕОБЯЗАТЕЛЬНЫ (OPTIONAL).
Для значений некоторых параметров ниже задана максимальная длина. В каждом таком случае приложение syslog ОБЯЗАНО (MUST) быть готово принять заданное число символов в любых действительных кодовых точках UTF-8. Поскольку каждый символ может занимать до шести октетов, каждому приложению syslog РЕКОМЕНДУЕТСЯ (RECOMMENDED) быть готовым принять до шести октетов на символ.
7.1. timeQuality
Источник МОЖЕТ (MAY) использовать SD-ID timeQuality для описания своего представления о системном времени. Этот SD-ID СЛЕДУЕТ (SHOULD) записывать, если источник недостаточно синхронизирован с надёжным внешним источником времени или не знает, верны ли сведения о его часовом поясе. Основное назначение элемента — сообщить степень доверия источника к TIMESTAMP, описанному в разделе 6.2.3. Все параметры НЕОБЯЗАТЕЛЬНЫ (OPTIONAL).
7.1.1. tzKnown
Параметр tzKnown показывает, знает ли источник свой часовой пояс. Если знает, ОБЯЗАТЕЛЬНО (MUST) используется значение 1. Если сведения о часовом поясе сомнительны, ОБЯЗАТЕЛЬНО (MUST) используется 0. Если источник знает часовой пояс, но решает передавать время в UTC, ОБЯЗАТЕЛЬНО (MUST) используется 1, поскольку часовой пояс известен.
7.1.2. isSynced
Параметр isSynced показывает, синхронизирован ли источник с надёжным внешним источником времени, например по NTP. Если синхронизирован, ОБЯЗАТЕЛЬНО (MUST) используется 1; если нет — 0.
7.1.3. syncAccuracy
Параметр syncAccuracy показывает, какой точной источник считает синхронизацию своего времени. Это целое число, описывающее максимальное отклонение часов в микросекундах между интервалами синхронизации.
Если isSynced равен 0, параметр НЕ ДОЛЖЕН (MUST NOT) указываться. Если isSynced равен 1, но syncAccuracy отсутствует, сборщик или ретранслятор может считать предоставленное время достаточно точным для признания правильным. Параметр syncAccuracy ОБЯЗАТЕЛЬНО (MUST) записывается только если источник действительно знает надёжность внешнего источника времени. В большинстве случаев эти подробные сведения получаются через настройку оператором.
7.1.4. Примеры
Пример источника, не знающего свой часовой пояс и наличие синхронизации:
[timeQuality tzKnown="0" isSynced="0"]
Этим источник указывает, что его сведения о времени ненадёжны. Это может подсказать сборщику или ретранслятору использовать собственное локальное время вместо TIMESTAMP из сообщения для сопоставления сообщений разных источников.
Пример источника, знающего свой часовой пояс и правильную синхронизацию с надёжным внешним источником:
[timeQuality tzKnown="1" isSynced="1"]
Пример источника, знающего свой часовой пояс, наличие внешней синхронизации и её точность:
[timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"]
Отличие от предыдущего примера в том, что источник ожидает отклонения своих часов от официального времени не более чем на 60 секунд. Так, если источник сообщает 9:00:00, фактическое время не раньше 8:59:00 и не позже 9:01:00.
7.2. origin
SD-ID origin МОЖНО (MAY) использовать для указания источника сообщения syslog. Можно применять следующие параметры; все они НЕОБЯЗАТЕЛЬНЫ (OPTIONAL).
Указание любого из параметров прежде всего помогает анализаторам журналов и аналогичным приложениям.
7.2.1. ip
Параметр ip обозначает IP-адрес, который, как известно источнику, принадлежал ему при создании сообщения. Он ОБЯЗАТЕЛЬНО (MUST) содержит текстовое представление IP-адреса согласно разделу 6.2.4.
Параметр позволяет предоставить идентифицирующие сведения в дополнение к HOSTNAME. Он особенно полезен, если в сообщение включён IP-адрес хоста, тогда как HOSTNAME по-прежнему содержит FQDN. Он также полезен для описания всех IP-адресов хоста с несколькими сетевыми подключениями.
Если у источника несколько IP-адресов, он МОЖЕТ (MAY) указать один из них в параметре ip или включить несколько параметров ip в один элемент структурированных данных origin.
7.2.2. enterpriseId
Параметр enterpriseId ОБЯЗАТЕЛЬНО (MUST) является частным кодом предприятия SMI Network Management Private Enterprise Code, поддерживаемым IANA, с префиксом iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). Следующий за ним номер ОБЯЗАТЕЛЬНО (MUST) уникален и зарегистрирован в IANA согласно RFC 2578 [RFC2578]. Предприятие вправе назначать значения только в поддереве iso.org.dod.internet.private.enterprise.<private enterprise number>, назначенном ему IANA. enterpriseId ОБЯЗАТЕЛЬНО (MUST) содержит только значение из этого поддерева. Обычно необходим только частный номер предприятия, назначенный IANA, — одно число. Предприятие может использовать подидентификаторы ниже своего частного номера. Если подидентификаторы используются, они ОБЯЗАТЕЛЬНО (MUST) разделяются точками и представляются десятичными числами, например 32473.1.2. Идентификатор 32473.1.2 приведён только как пример и НЕ ДОЛЖЕН (MUST NOT) использоваться. Полный актуальный список частных номеров предприятий PEN ведёт IANA.
Указав частный номер предприятия, производитель позволяет обрабатывать сообщение более конкретным образом.
7.2.3. software
Параметр software однозначно идентифицирует программное обеспечение, сформировавшее сообщение. При его использовании также СЛЕДУЕТ (SHOULD) указывать enterpriseId, чтобы можно было определить ПО конкретного производителя. Параметр software не совпадает с полем заголовка APP-NAME: он ОБЯЗАТЕЛЬНО (MUST) всегда содержит имя ПО, сформировавшего сообщение, тогда как APP-NAME может содержать что-либо иное, включая значение, настроенное оператором.
software — строка. Она НЕ ДОЛЖНА (MUST NOT) превышать 48 символов.
7.2.4. swVersion
Параметр swVersion однозначно идентифицирует версию программного обеспечения, сформировавшего сообщение. При его использовании также СЛЕДУЕТ (SHOULD) предоставлять параметры software и enterpriseId.
swVersion — строка. Она НЕ ДОЛЖНА (MUST NOT) превышать 32 символа.
7.2.5. Пример
Пример с несколькими IP-адресами:
[origin ip="192.0.2.1" ip="192.0.2.129"]
Источник указывает, что имеет два IP-адреса: 192.0.2.1 и 192.0.2.129.
7.3. meta
Идентификатор SD-ID «meta» МОЖЕТ использоваться для передачи метаданных о сообщении. Можно применять перечисленные ниже параметры. Все параметры НЕОБЯЗАТЕЛЬНЫ. Если используется SD-ID «meta», СЛЕДУЕТ указать хотя бы один параметр.
7.3.1. sequenceId
Параметр «sequenceId» отслеживает порядок, в котором источник передаёт сообщения транспорту syslog для отправки. Это целое число, которое ДОЛЖНО устанавливаться равным 1 при запуске функции syslog и ДОЛЖНО увеличиваться с каждым сообщением до максимального значения 2147483647. По достижении этого значения следующее сообщение ДОЛЖНО отправляться с sequenceId, равным 1.
7.3.2. sysUpTime
Параметр «sysUpTime» МОЖЕТ использоваться для включения в сообщение параметра SNMP «sysUpTime». Его синтаксис и семантика определены в [RFC3418].
Поскольку syslog не поддерживает синтаксис SNMP «INTEGER» непосредственно, значение ДОЛЖНО представляться десятичным целым числом без десятичной точки с использованием только символов от «0» до «9».
Согласно RFC 3418 значение означает время в сотых долях секунды с последней повторной инициализации части системы, отвечающей за управление сетью. Разумеется, это относится к части управления, связанной с SNMP, которая МОЖЕТ отличаться от части, связанной с syslog.
7.3.3. language
Источник МОЖЕТ указать параметр «language», чтобы передать сведения о естественном языке, используемом внутри MSG. Если параметр указан, он ДОЛЖЕН содержать идентификатор языка согласно BCP 47 [RFC4646].
8. Вопросы безопасности
8.1. UNICODE
В этом документе для полей PARAM-VALUE и MSG используется кодировка UTF-8. С UNICODE связан ряд проблем безопасности. Разработчикам и операторам рекомендуется ознакомиться с UNICODE TR36 [UNICODE-TR36] (UTR36). Настоящий документ защищает от технических проблем, описанных в UTR36, ТРЕБУЯ для приложений syslog кодирование в «кратчайшей форме». Однако визуальная подмена за счёт сходства символов остаётся возможной. Документ стремится уменьшить её последствия, разрешая UNICODE только там, где ожидается и необходима местная письменность. Во всех остальных полях ТРЕБУЕТСЯ US-ASCII. Кроме того, поля PARAM-VALUE и MSG не следует использовать как основной источник идентификационных сведений, что дополнительно снижает риск визуальной подмены.
8.2. Управляющие символы
Документ не накладывает обязательных ограничений на содержимое MSG или PARAM-VALUE. Поэтому они МОГУТ содержать управляющие символы, в том числе NUL.
В некоторых языках программирования, особенно C и C++, символ NUL (ABNF %d00) традиционно имеет особое значение признака конца строки. Большинство реализаций этих языков предполагает, что строка не продолжается за первым символом NUL. Это прежде всего ограничение библиотек времени выполнения, которое часто переносится и на написанные на этих языках программы и скриптовые языки. Поэтому символы NUL необходимо учитывать с большой осторожностью и правильно обрабатывать. Злоумышленник может намеренно включить NUL, чтобы скрыть информацию после него. Неправильная обработка NUL может также нарушить проверку криптографических контрольных сумм, передаваемых внутри сообщения.
Многие распространённые текстовые редакторы также написаны на языках с этим ограничением. При записи в текстовые файлы рекомендуется кодировать символы NUL: если сохранить их без кодирования, файл может стать нечитаемым.
Другие управляющие символы тоже могут создавать проблемы. Например, злоумышленник может намеренно включить символы возврата на шаг, чтобы сделать части сообщения журнала нечитаемыми. Подобные проблемы существуют почти для всех управляющих символов.
Наконец, недопустимые последовательности UTF-8 могут использоваться злоумышленником для внедрения управляющих символов ASCII.
Эта спецификация разрешает приложению syslog изменять формат полученных управляющих символов. Риски безопасности, связанные с ними, были одной из важных причин этого ограничения. Источникам следует учитывать: если используется кодировка, отличная от ASCII и UTF-8, получатель может повредить сообщение при попытке отфильтровать управляющие символы ASCII.
8.3. Усечение сообщений
Злоумышленник может использовать усечение сообщения, чтобы скрыть важные сведения журнала. Сообщения, превышающие минимальный поддерживаемый размер, транспортный получатель может отбросить или усечь. При этом важные сведения могут быть потеряны.
Во избежание потери информации сообщения не должны превышать минимальный максимальный размер, требуемый разделом 6.1. Для наилучшей производительности и надёжности сообщения следует делать как можно меньше. Важную информацию следует помещать как можно ближе к началу сообщения, поскольку получатель транспорта с ограничением размера с меньшей вероятностью отбросит её.
Источнику следует ограничивать размер любых предоставленных пользователем данных в сообщении syslog. Иначе злоумышленник может предоставить большие объёмы данных в расчёте использовать возможную уязвимость.
8.4. Повторное воспроизведение
Протокол syslog не содержит механизма обнаружения повторного воспроизведения сообщений. Злоумышленник может записать набор сообщений, указывающих на нормальную работу машины, а затем вывести её из сети и воспроизвести сообщения для ретранслятора или коллектора. Даже при наличии поля TIMESTAMP в HEADER злоумышленник может записать пакеты и перед повторной отправкой изменить их, указав текущее время. Администраторы могут не заметить ничего необычного, и получение сообщений ошибочно укажет на нормальную работу машины.
Криптографическая подпись сообщений могла бы предотвратить изменение TIMESTAMP и тем самым такую атаку.
8.5. Надёжная доставка
Поскольку документ не описывает механизм гарантированной доставки, а используемый транспорт может быть ненадёжным (например, UDP), некоторые сообщения могут теряться. Они могут быть отброшены из-за перегрузки сети либо перехвачены и удалены злоумышленником. Последствия потери одного или нескольких сообщений syslog невозможно определить заранее. Если сообщения лишь сообщают о состоянии, их отсутствие может остаться незамеченным или создать неудобства операторам. Если же они важнее, администраторы могут не узнать о развивающейся, потенциально серьёзной проблеме. Злоумышленник также может перехватывать и удалять сообщения, чтобы скрыть несанкционированные действия.
В источниках и ретрансляторах syslog может быть полезно ограничение интенсивности передачи. Это способно уменьшить перегрузку при всплесках сообщений.
Надёжная доставка не всегда желательна. Она означает, что источник или ретранслятор syslog должен блокироваться, когда ретранслятор или коллектор больше не может принимать сообщения. В некоторых операционных системах, в частности Unix/Linux, источник или ретранслятор работает внутри высокоприоритетного системного процесса syslogd. Если этот процесс блокируется, вся система останавливается. То же происходит при взаимной блокировке syslogd и, например, DNS-сервера.
Для предотвращения таких проблем надёжную доставку можно реализовать так, чтобы намеренно отбрасывать сообщения, когда приложение syslog иначе заблокировалось бы. Преимущество в том, что источник или ретранслятор сознательно отбрасывает сообщение и может уведомить об этом ретранслятор или коллектор. Таким образом, получатель узнаёт о потере. При ненадёжной доставке сообщение просто потерялось бы без какого-либо указания на это.
8.6. Управление перегрузкой
Поскольку syslog способен генерировать неограниченные объёмы данных, передача через UDP в целом проблематична: в UDP нет механизмов управления перегрузкой. Для стабильной работы Интернета необходимы механизмы, которые реагируют на перегрузку снижением интенсивности трафика и обеспечивают определённую справедливость между потоками, использующими общий путь [RFC2914]. Поэтому реализация транспорта syslog поверх TLS ОБЯЗАТЕЛЬНА, и он РЕКОМЕНДУЕТСЯ для общего применения.
Транспорт syslog поверх UDP МОЖЕТ использоваться вместо TLS только в управляемых сетях, где сетевой путь явно подготовлен для трафика syslog по UDP с помощью управления трафиком, например ограничения скорости или резервирования пропускной способности. Во всех остальных средах СЛЕДУЕТ использовать транспорт TLS.
В любой реализации может возникнуть необходимость приостановить отправку сообщений источником или ретранслятором, например при заполнении внутренней очереди из-за ограничения скорости или медленной работы приложения syslog. В любом случае настоятельно РЕКОМЕНДУЕТСЯ не отбрасывать сообщения, а временно хранить их до появления возможности передачи. Если же отбрасывание неизбежно, РЕКОМЕНДУЕТСЯ отдавать предпочтение сообщениям с более высокой серьёзностью, отбрасывая менее серьёзные.
Меньшее числовое значение SEVERITY соответствует большей практической серьёзности. В такой ситуации сообщения, подлежащие отбрасыванию, СЛЕДУЕТ просто удалять. Приложение syslog может уведомить коллектор или ретранслятор об отбрасывании сообщений.
8.7. Целостность сообщений
Помимо потери, сообщения syslog могут быть повреждены при передаче или намеренно изменены злоумышленником. В таких случаях исходное содержимое не будет доставлено коллектору или ретранслятору. Кроме того, злоумышленник между отправителем и получателем транспорта может перехватывать и изменять сообщения в пути, чтобы скрыть несанкционированные действия.
8.8. Наблюдение сообщений
Хотя строгих правил для формата MSG нет, большинство сообщений syslog создаётся в читаемом человеком виде, исходя из того, что компетентные администраторы смогут прочесть и понять их. Протокол syslog не обеспечивает конфиденциальность сообщений при передаче. Во многих случаях открытый текст полезен обслуживающему персоналу при перехвате пакетов в сети: сотрудники могут прочесть сообщения и сопоставить их с другими событиями, наблюдаемыми в пакетах, чтобы найти и устранить неполадки. К сожалению, злоумышленник также может прочесть содержимое сообщений и использовать полученные сведения для компрометации машины или иного ущерба.
Операторам рекомендуется использовать безопасный транспорт, чтобы избежать этой проблемы.
8.9. Неправильная конфигурация
Поскольку управляющие сведения о сообщениях и конфигурациях не распространяются, именно администратор сети полностью отвечает за то, чтобы сообщения поступали нужным получателям. Известны случаи, когда приложения syslog по ошибке настраивались на отправку не тем ретрансляторам или коллекторам. Часто такие получатели не настроены на приём сообщений syslog и, вероятно, отбросят их. В других случаях известно, что получение сообщений вызывало проблемы у непредусмотренного получателя. Если сообщения не поступают нужному получателю, их нельзя просмотреть или обработать.
Надёжный транспорт может помочь выявить некоторые из этих проблем, например отправку системе, не настроенной на приём сообщений. Однако он не выявит отправку не той машине, которая принимает сообщения.
8.10. Петля пересылки
Как показано на схеме 2, машины могут быть настроены на передачу сообщений syslog через цепочку ретрансляторов до коллектора. В одном случае администратор по ошибке настроил два ретранслятора пересылать друг другу сообщения с определёнными значениями SEVERITY. При получении или создании такого сообщения любая из машин пересылала его другой, а та возвращала обратно. Этот цикл ухудшал работу промежуточной сети и доступность вычислительных ресурсов обоих устройств. Администраторы сети должны следить, чтобы не создавать подобную разрушительную петлю.
8.11. Нагрузка
Администраторы должны оценить необходимую ёмкость коллектора syslog. Злоумышленник может провести атаку типа «отказ в обслуживании», заполнив диск коллектора ложными сообщениями. Циклический файл может смягчить проблему, но при этом не гарантируется, что администратор сможет просмотреть записи в будущем. Аналогично сетевой интерфейс транспортного получателя должен быть способен принимать отправляемые ему сообщения.
Администраторам и проектировщикам сети также необходимо тщательно оценивать сетевые пути между источниками, ретрансляторами и коллекторами. Создаваемые сообщения syslog не должны перегружать сетевые соединения.
Для уменьшения влияния этой проблемы рекомендуется использовать транспорт с гарантированной доставкой.
8.12. Отказ в обслуживании
Как и в любой системе, злоумышленник может перегрузить транспортный получатель, отправляя больше сообщений, чем способны обработать инфраструктура или само устройство. Разработчикам следует предусмотреть средства снижения этой угрозы, например приём сообщений syslog только от известных IP-адресов.
9. Вопросы IANA
9.1. VERSION
IANA создала реестр значений VERSION «syslog Version Values», описанных в разделе 6.2.2. Номер версии ДОЛЖЕН увеличиваться для каждой новой спецификации протокола syslog, изменяющей какую-либо часть HEADER. К изменениям относятся добавление или удаление полей, а также изменение синтаксиса или семантики существующих полей.
Номера VERSION регистрируются методом Standards Action согласно [RFC5226]. IANA зарегистрировала значения VERSION, указанные в таблице 3.
VERSION ФОРМАТ 1 Определён в [RFC5424]
Таблица 3. Значения VERSION, зарегистрированные IANA
9.2. SD-ID
IANA создала реестр «syslog Structured Data ID Values» для значений идентификаторов структурированных данных (SD-ID) и связанных с ними значений PARAM-NAME, описанных в разделе 7.
Новые значения SD-ID и PARAM-NAME регистрируются методом IETF Review согласно [RFC5226].
После определения SD-ID и SD-PARAM их синтаксис и семантика НЕ ДОЛЖНЫ изменяться. Если требуется изменить существующий объект, ДОЛЖЕН быть создан новый SD-ID или SD-PARAM, а прежний должен оставаться неизменным.
Предусмотрены имена, расширяемые локально. IANA не будет регистрировать или контролировать имена, содержащие знак @ (ABNF %d64).
IANA зарегистрировала SD-ID и PARAM-NAME, приведённые в таблице 4.
SD-ID PARAM-NAME
timeQuality НЕОБЯЗАТЕЛЬНЫЙ
tzKnown НЕОБЯЗАТЕЛЬНЫЙ
isSynced НЕОБЯЗАТЕЛЬНЫЙ
syncAccuracy НЕОБЯЗАТЕЛЬНЫЙ
origin НЕОБЯЗАТЕЛЬНЫЙ
ip НЕОБЯЗАТЕЛЬНЫЙ
enterpriseId НЕОБЯЗАТЕЛЬНЫЙ
software НЕОБЯЗАТЕЛЬНЫЙ
swVersion НЕОБЯЗАТЕЛЬНЫЙ
meta НЕОБЯЗАТЕЛЬНЫЙ
sequenceId НЕОБЯЗАТЕЛЬНЫЙ
sysUpTime НЕОБЯЗАТЕЛЬНЫЙ
language НЕОБЯЗАТЕЛЬНЫЙ
Таблица 4. Зарегистрированные IANA SD-ID и их PARAM-NAME
10. Рабочая группа
С рабочей группой можно связаться через список рассылки syslog@ietf.org. На момент публикации сопредседателями рабочей группы были:
Chris Lonvick Cisco Systems Эл. почта: clonvick@cisco.com
David Harrington Huawei Technologies USA Эл. почта: dbharrington@comcast.net
11. Благодарности
Авторы благодарят Chris Lonvick, Jon Callas, Andrew Ross, Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado Colussi, Clement Mathieu, Didier Dalmasso и всех остальных, кто комментировал различные версии этого предложения.
12. Ссылки
12.1. Нормативные ссылки
[ANSI.X3-4.1968] American National Standards Institute, "USA Code
for Information Interchange", ANSI X3.4, 1968.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for
the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3418, December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5425] Fuyou, M., Yuzhi, M., and J. Salowey, "TLS
Transport Mapping for Syslog", RFC 5425, March
2009.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages
over UDP", RFC 5426, March 2009.
[UNICODE-TR36] Davis, M. and M. Suignard, "UNICODE Security
Considerations", July 2005.
12.2. Информационные ссылки
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001.
Приложение A. Рекомендации разработчикам
Сведения в этом разделе предназначены в помощь разработчикам. Хотя они считаются полезными, они не являются нормативными. Поэтому реализация НЕ ОБЯЗАНА следовать им, чтобы считаться соответствующей этой спецификации.
A.1. Связь с BSD Syslog
Хотя BSD syslog широко распространён, его формат никогда не был формально стандартизован. [RFC3164] описывает наблюдаемые форматы. Это информационный RFC, и практика показывает существование множества различных реализаций. Исследование при подготовке этого документа показало, что реализации syslog на разных платформах имеют очень мало общего. Единственное, в чём они все совпадают: сообщения начинаются с «<» PRIVAL «>». В остальном формат устаревших сообщений syslog непоследователен. Поэтому RFC 3164 не описывает конкретные элементы сообщения syslog. Он указывает, что любое сообщение, адресованное UDP-порту syslog, должно рассматриваться как сообщение syslog независимо от его формата или содержимого.
Этот документ сохраняет синтаксис и семантику значения PRI. Это позволит прежним реализациям syslog правильно классифицировать сообщения, созданные приложениями, соответствующими данной спецификации.
Большинство существующих реализаций используют UDP как транспортный протокол syslog. Эта спецификация поддерживает UDP, но не рекомендует его. Рекомендуется развёртывать обязательную поддержку TLS. Могут использоваться и другие транспортные протоколы.
RFC 3164 описывает поведение ретранслятора. Настоящий документ его не определяет; это может быть сделано в отдельном документе.
TIMESTAMP в RFC 3164 менее точен, чем временная метка, определённая здесь. В нём также отсутствуют год и сведения о часовом поясе. Если сообщение, оформленное согласно этому документу, нужно преобразовать в формат RFC 3164, предлагается использовать местный часовой пояс источника, а сведения о часовом поясе и год отбросить. Если полученное сообщение в формате RFC 3164 необходимо преобразовать в формат этого документа, следует добавить текущий год; МОЖЕТ использоваться часовой пояс ретранслятора или коллектора.
HOSTNAME в RFC 3164 определён менее точно, однако этот формат по-прежнему поддерживается здесь как один из альтернативных способов представления HOSTNAME.
Часть сообщения MSG в RFC 3164 описана как TAG и CONTENT. В настоящем документе MSG соответствует тому, что в RFC 3164 называлось CONTENT. TAG теперь является частью заголовка, но не отдельным полем: он разделён на APP-NAME, PROCID и MSGID. Это не полностью повторяет использование TAG, но в большинстве случаев обеспечивает ту же функциональность.
STRUCTURED-DATA в RFC 3164 не описаны. Если соответствующее этому документу сообщение содержит STRUCTURED-DATA и должно быть преобразовано в формат RFC 3164, STRUCTURED-DATA просто становится частью текста произвольной формы CONTENT из RFC 3164.
В целом этот документ стремится обеспечить легко разбираемый заголовок с чёткими границами полей, тогда как традиционный BSD syslog страдает от некоторых исторически сложившихся правил разделения полей, затрудняющих разбор.
A.2. Длина сообщения
Разработчикам следует учитывать ограничения размера сообщения из раздела 6.1 и стараться помещать самые важные данные в начале сообщения, в пределах минимальной гарантированной длины. Это позволит коллектору или ретранслятору получить их даже в случае усечения транспортным получателем на одном из промежуточных ретрансляторов.
Причина, по которой транспортным получателям syslog достаточно поддерживать приём сообщений размером до 480 октетов включительно, среди прочего связана со сложностями доставки в неисправной сети. Сообщения syslog могут использовать транспорт UDP с ограничением в 480 октетов, чтобы избежать накладных расходов на сеанс и фрагментации. В сети с неполадками вероятность успешной доставки одного сообщения в одном пакете выше, чем вероятность доставки двух его фрагментов. Поэтому больший размер может помешать оператору получить критически важные сведения о проблеме, тогда как небольшое сообщение может их донести. Рекомендуется, чтобы сообщения для диагностики не превышали 480 октетов. В подтверждение также отмечено, что некоторые реализации UDP вообще не поддерживают сообщения более 480 октетов. Такое поведение встречается очень редко и, возможно, уже не является проблемой.
В других случаях syslog используется для передачи заведомо объёмных сведений, например данных аудита. Поскольку верхний предел размера сообщения не установлен, приложения syslog могут реализовать любой необходимый размер и при этом соответствовать документу. В таких случаях оператор отвечает за то, чтобы все компоненты инфраструктуры syslog поддерживали требуемый размер. Спецификации транспорта могут рекомендовать конкретные ограничения размера сообщений, которые необходимо реализовать для соответствия им.
Разработчикам напоминается, что длина сообщения задаётся в октетах. Для строк UTF-8 длина в символах может существенно отличаться от длины в октетах.
Следует отметить, что MTU IPv6 примерно в 2,5 раза больше 480. Поэтому реализация, предназначенная исключительно для IPv6, может принять это значение в качестве большего минимального размера.
A.3. Значения серьёзности
В этом разделе приведены рекомендации по использованию Severity, описанного в разделе 6.2.1.
Все реализации должны стремиться назначать сообщениям наиболее подходящую степень серьёзности. Прежде всего сообщениям для отладки или тестирования программ следует назначать Severity 7. Значение 0 следует оставить для исключительно важных сообщений, например о серьёзном отказе оборудования или надвигающемся отключении питания. Реализация может использовать значения 0 и 7 для других целей, если это настроено администратором.
Поскольку оценка серьёзности весьма субъективна, ретранслятору или коллектору не следует предполагать, что все источники одинаково её определяют.
A.4. Точность TIME-SECFRAC
TIMESTAMP из раздела 6.2.3 поддерживает доли секунды. Это создаёт предпосылки для распространённой ошибки программирования — удаления начальных нулей дробной части. Например, TIMESTAMP «2003-10-11T22:13:14.003» может быть ошибочно записан как «2003-10-11T22:13:14.3». Это будет означать 300 миллисекунд вместо имевшихся в виду 3 миллисекунд.
A.5. Соглашение о регистре имён
Имена используются в разных местах документа, например для SD-ID и PARAM-NAME. В документе последовательно используется стиль lower camel case: каждое имя начинается со строчной буквы, а каждое следующее входящее в него слово — с прописной, без дефиса или другого разделителя. Пример — «timeQuality».
Хотя реализация вправе применять любое иное соглашение о регистре для экспериментальных имён, предлагается придерживаться описанного выше.
A.6. Приложения syslog без сведений о времени
В разделе 6.2.3 источникам, не имеющим сведений о времени, разрешено использовать NILVALUE. Это сделано для особого случая, когда приложение syslog вообще не знает времени. Можно спорить, встречаются ли такие приложения в современной ИТ-инфраструктуре. Однако обсуждение показало, что на практике они могут существовать, и для этого случая следует установить рекомендации.
Тем не менее реализации СЛЕДУЕТ передавать действительный TIMESTAMP, если базовая операционная система, система программирования и оборудование поддерживают часы. Правильный TIMESTAMP следует передавать, даже если получить системное время трудно. NILVALUE следует использовать только тогда, когда получить сведения о времени действительно невозможно. Это правило не должно служить оправданием небрежной реализации.
A.7. Замечания об SD-ID timeQuality
Рекомендуется, чтобы значением по умолчанию параметра «tzKnown» (раздел 7.1.1) было «0». Его следует менять на «1» только после явной настройки часового пояса администратором. Значение «1» может использоваться по умолчанию, если базовая операционная система предоставляет точные сведения о часовом поясе. При этом администратору всё равно рекомендуется проверить их правильность.
Важно не создавать ложного впечатления о точности с помощью SD-ID timeQuality (раздел 7.1). Источнику следует указывать определённую точность, только если ему действительно известно, что она находится в этих пределах. Обычно предполагается, что источник получает эти подробные сведения из настроек оператора. По умолчанию точность указывать не следует.
A.8. Кодировка UTF-8 и BOM
Этот документ определяет, что SD-PARAMS всегда должны кодироваться в UTF-8. Другие кодировки сообщения в части MSG, включая ASCIIPRINT, не допускаются устройством, соответствующим этой спецификации. Здесь необходимо рассмотреть два случая. Во-первых, соответствующее спецификации приложение syslog может не иметь возможности убедиться, что полученные от источника сведения закодированы в UTF-8. Если оно не может определить это с уверенностью, оно может не включать BOM в MSG. Если же у приложения есть веские основания считать, что содержимое сообщения закодировано в UTF-8, ему следует включить BOM. Во втором случае ретранслятор syslog может пересылать сообщение от устройства, не соответствующего этой спецификации. В этом случае устройство, вероятно, не включит BOM, если не удостоверилось, что полученное сообщение закодировано в UTF-8.
Адрес автора
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany
Эл. почта: rgerhards@adiscon.com
Перевод: RFCNET · rfcnet.ru
Original copyright notice
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Gerhards Standards Track [Page 1]
RFC 5424 The Syslog Protocol March 2009
Abstract
This document describes the syslog protocol, which is used to convey
event notification messages. This protocol utilizes a layered
architecture, which allows the use of any number of transport
protocols for transmission of syslog messages. It also provides a
message format that allows vendor-specific extensions to be provided
in a structured way.
This document has been written with the original design goals for
traditional syslog in mind. The need for a new layered specification
has arisen because standardization efforts for reliable and secure
syslog extensions suffer from the lack of a Standards-Track and
transport-independent RFC. Without this document, each other
standard needs to define its own syslog packet format and transport
mechanism, which over time will introduce subtle compatibility
issues. This document tries to provide a foundation that syslog
extensions can build on. This layered architecture approach also
provides a solid basis that allows code to be written once for each
syslog feature rather than once for each transport.
This document obsoletes RFC 3164.
Неофициальный перевод. При расхождениях см. оригинал.