RFC 5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols

Network Working Group                                        I. Chakeres
Request for Comments: 5498                                        CenGen
Category: Standards Track                                     March 2009

 

PDF

Значения, выделенные IANA для сетей MANET

IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols

Статус документа

Этот документ является проектом стандарта Internet (Internet Standards Track) и служит приглашением к дискуссии и внесению предложений с целью совершенствования протокола. Информацию о состоянии стандартизации и статусе протокола можно найти в текущей редакции документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

Авторские права

Авторские права (Copyright (c) 2009) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Тезисы

В документе рассмотрены несколько выделенных агентством IANA значений для использования в протоколах MANET1. К числу этих значений относятся номер порта UDP, номер протокола IP, групповой адрес для локального канала.

Оглавление

Исключено в версии HTML.

1. Введение

В этом документе приведены выделенные агентством IANA значения для использования одним или множеством протоколов, соответствующих [RFC5444]. Обязательными являются общепринятые значения для номера порта UDP, номера протокола IP и группового адреса для локального канала. Все интероперабельные протоколы, работающие с общепринятыми значениями, выделяемыми IANA, должны соответствовать [RFC5444]. В [RFC5444] описаны общие форматы, которые позволяют одному или множеству протоколов совместно использовать выделенные IANA значения, описанные в данном документе без возникновения неоднозначностей.

2. Используемые соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

3. Номер порта UDP

Маршрутизаторам MANET нужен общеизвестный номер порта UDP [IANA] для отправки и получения пакетов протоколов маршрутизации MANET. Для этого порта выбрано имя manet и номер UDP 269.

4. Номер протокола IP

Маршрутизаторам MANET нужен общеизвестный номер протокола IP [IANA] для отправки и получения пакетов протоколов маршрутизации MANET. Для этого протокола выбрано имя manet и номер IP 138.

5. Групповой адрес канального уровня для маршрутизаторов MANET

Маршрутизаторам MANET нужен общеизвестный групповой адрес link-local (LL) [RFC4291] для отправки и получения пакетов протоколов маршрутизации MANET. Для этого адреса выбрано имя LL-MANET-Routers.

Для IPv4 требуется общеизвестный адрес с зоной действия «локальный канал» (link-local). В качестве адреса LL-MANET-Routers выделено значение 224.0.0.109.

Для IPv6 требуется общеизвестный адрес с зоной действия «локальный канал» (link-local). В качестве адреса LL-MANET-Routers выделено значение FF02:0:0:0:0:0:0:6D.

6. Взаимодействие с IANA

В этом документе перечислены несколько выделяемых агентством IANA общепринятых значений для использования одним или множеством протоколов, соответствующих [RFC5444]. В частности, выделен номер порта UDP (Раздел 3), номер протокола IP (Раздел 4) и групповой адрес link-local (Раздел 5).

Действие 1:

Агентство IANA включает в реестр PORT NUMBERS (номера портов) запись

      sub-registry "WELL KNOWN PORT NUMBERS"
      Keyword Decimal Description     References
      ------- ------- -----------     ----------
      manet   269/udp MANET Protocols [RFC5498]

 

Действие 2:

Агентство IANA включает в реестр PROTOCOL NUMBERS (номера протоколов) запись

      sub-registry "WELL KNOWN PORT NUMBERS"
      Keyword Decimal Description     References
      ------- ------- -----------     ----------
      manet   138     MANET Protocols [RFC5498]

 

Действие 3:

Агентство IANA включает в реестр Internet Multicast Addresses (групповые адреса IP) запись

      sub-registry "224.0.0.0 - 224.0.0.255 (224.0.0/24) Local Network Control Block"
      224.0.0.109 LL-MANET-Routers   [RFC5498]

 

Действие 4:

Агентство IANA включает в реестр INTERNET PROTOCOL VERSION 6 MULTICAST ADDRESSES (групповые адреса IPv6) запись

      sub-registry "Fixed Scope Multicast Addresses"
      sub-sub-registry "Link-Local Scope"
      FF02:0:0:0:0:0:0:6D LL-MANET-Routers [RFC5498]

 

7. Вопросы безопасности

Этот документ лишь задает общепринятые значения для протоколов, соответствующих [RFC5444], и не содержится спецификации протоколов, передающих информацию через сеть. Каждый протокол, использующий описанные здесь значения, может иметь свои вопросы, связанные с безопасностью, но на эти вопросы не оказывает влияние применение описанных здесь значений, выделенных IANA.

Вопросы безопасности, связанные с возможным применением множества протоколов, использующих описанные здесь значения (например, номер порта UDP), должны решаться в спецификациях каждого протокола.

8. Благодарности

Fred Templin, Bill Fenner, Alexandru Petrescu, Sam Weiler, Ross Callon и Lars Eggert внесли значительный вклад в подготовку этого документа.

9. Литература

9.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, «Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format», RFC 5444, February 2009.

9.2. Дополнительная литература

[IANA] http://www.iana.org/

Адрес автора

Ian D Chakeres

CenGen

9250 Bendix Road North

Columbia MD 21045 USA

EMail: ian.chakeres@gmail.com

URI: http://www.ianchak.com/

Перевод на русский язык

Николай Малых

nmalykh@gmail.com


1Mobile Ad hoc NETwork — мобильная сеть специального назначения.




RFC 5427 Textual Conventions for Syslog Management

Network Working Group                                           G. Keeni
Request for Comments: 5427                          Cyber Solutions Inc.
Category: Standards Track                                     March 2009

Текстовые соглашения для управления Syslog

Textual Conventions for Syslog Management

PDF

Статус документа

Этот документ является проектом стандарта Internet (Internet Standards Track) и служит приглашением к дискуссии и внесению предложений с целью совершенствования протокола. Информацию о состоянии стандартизации и статусе протокола можно найти в текущей редакции документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

Авторские права

Авторские права (Copyright (c) 2009) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Этот документ может содержать материалы из документов IETF или участников IETF1, опубликованных или публично доступных до 10 ноября 2008 г. Лица, контролирующие авторские права на некоторые из таких материалов могли не предоставить IETF Trust прав на изменение таких материалов вне контекста стандартизации IETF2. Без получения соответствующей лицензии от лиц, контролирующих авторские права на такие материалы, этот документ не может быть изменен вне контекста стандартизации IETF, а также не могут открываться производные работы за пределами контекста стандартизации. Исключением является лишь форматирование документа для публикации в качестве RFC или перевод на другие языки.

Тезисы

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

Оглавление

Исключено в версии HTML.

 

1. Стандартная модель управления Internet

Подробный обзор документов, описывающих современную схему стандартного управления в Internet (Internet-Standard Management Framework), приведен в разделе 7 документа RFC 3410 [RFC3410].

Доступ к объектам управления выполняется через виртуальное информационное хранилище, называемое базой данных управления или MIB3. Доступ к объектам MIB обычно осуществляется по протоколу SNMP4. Объекты в MIB определяются с использованием механизмов, описанных в структуре SMI5. В этом документе описан модуль MIB, соответствующий спецификации SMIv2, описанной в STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] и STD 58, RFC 2580 [RFC2580].

2. Основы

Операционные системы, процесс и приложения, совокупно называемые далее «источники» (Facilities), генерируют сообщения, показывающие их состояние или происходящие события. Эти сообщения называют сообщениями syslog. В общем случае сообщения syslog наряду с другой информацией включают код, представляющий источник сообщения (Facility), и код, представляющий уровень важности сообщения (Severity). Коды Facility и Severity обычно используются для категоризации и отбора полученных сообщений при их обработке и отображении. Коды Facility полезны для отбора инициатора содержимого сообщений, но не всегда достаточно конкретны для четкой идентификации инициатора. Реализациям протокола syslog [RFC5424], содержащим структурированные элементы данных (SDE6), следует использовать эти SDE для определения элемента, служащего источником содержимого сообщения.

В этом документе определен набор текстовых соглашения (TC7), которые могут применяться для представления кодов Facility и Severity, обычно используемых в сообщениях syslog.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

3. MIB для текстовых соглашений Syslog

   SYSLOG-TC-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, mib-2
                 FROM SNMPv2-SMI        -- [RFC2578]
       TEXTUAL-CONVENTION
                 FROM SNMPv2-TC;        -- [RFC2579]

   syslogTCMIB  MODULE-IDENTITY
       LAST-UPDATED "200903300000Z"     --  30 марта 2009 г.
       ORGANIZATION "IETF Syslog Working Group"
       CONTACT-INFO
       "                      Glenn Mansfield Keeni
                      Postal: Cyber Solutions Inc.
                              6-6-3, Minami Yoshinari
                              Aoba-ku, Sendai, Japan 989-3204.
                         Tel: +81-22-303-4012
                         Fax: +81-22-303-4015
                       EMail: glenn@cysols.com

         Support Group EMail: syslog@ietf.org
         "

       DESCRIPTION
           "Модуль MIB, содержащий текстовые соглашения для сообщений syslog.

            Copyright (c) 2009 IETF Trust и лица, указанные в качестве авторов
            кода. Все права защищены.

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

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

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

            - Названия Internet Society, IETF, IETF а также названия других
              конкретных участников не могут использоваться для одобрения или
              продвижения продукции, основанной на этой программе, без
              предварительного письменного разрешения.

            THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
            CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
            WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
            WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
            PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
            OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
            INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
            (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
            GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
            BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
            LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
            (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
            OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
            POSSIBILITY OF SUCH DAMAGE.

            Эта версия данного модуля MIB является частью 5427;
            правовые аспекты полностью приведены в этом RFC.
           "

       REVISION "200903300000Z"     --  30 March 2009
       DESCRIPTION
           "Исходная версия, опубликованная в RFC 5427."

       ::= { mib-2 173 }

   -- -------------------------------------------------------------
   -- Текстовые соглашения
   -- -------------------------------------------------------------

   SyslogFacility  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "В этих текстовых соглашениях перечислены объекты (Facility), 
            являющиеся источниками сообщений syslog.

            Значения Facility в сообщениях syslog задаются кодами в форме
            десятичных чисел. Для интероперабельности и совместимости с
            более ранними версиями данный документ задает нормативное отображение
            между метками, представляющими значения Facility, и соответствующими
            числовыми кодами. Метки могут применяться, например, в пользовательских
            интерфейсах приложений SNMP.

            Метка зачастую семантически бессмысленна, поскольку неразумно пытаться
            перечислить все возможные варианты Facility, а для многих демонов и
            процессов нет явно выделенного кода или метки Facility. Например, нет
            метки Facility, соответствующей сервису HTTP. Реализации служб HTTP
            могут генерировать сообщения, например, с метками local7 или uucp.
            Это обычная практика, поскольку инициаторы, трансляторы и коллекторы 
            могут настраиваться на подобающую обработку таких ситуаций. Для повышения
            точности приложение может также включать структурированные данные APP-NAME.

            Отметим, что механизмы операционной системы для настройки syslog
            (например, файл syslog.conf) еще не стандартизованы и могут применять
            разные наборы меток Facility и/или их отображений на коды Facility.

            В частности, метки, соответствующие кодам Facility 4, 10, 13 и 14,
            и коду для метки cron, существенно различаются в разных операционных
            системах. Для того, чтобы различать метки, соответствующие кодам 9 и 15,
            метке cron2 был присвоен код 15. Приведенный список не является полным
            и могут существовать другие отличия, которые могут появляться и впредь.

            Указанное здесь отображение ДОЛЖНО использоваться в интерфейсе MIB, хотя
            для конкретных реализаций syslog могут применяться иные отображения в других
            интерфейсах сетевого управления.
           "
       REFERENCE "Протокол Syslog (RFC5424), таблица 1"
       SYNTAX  INTEGER
            {

              kern            (0), -- сообщения ядра
              user            (1), -- сообщения пользовательского уровня
              mail            (2), -- сообщения почтовой системы
              daemon          (3), -- сообщения системных демонов
              auth            (4), -- проверка полномочий
              syslog          (5), -- внутренние сообщения syslogd
              lpr             (6), -- сообщения подсистемы печати
              news            (7), -- сообщения подсистемы сетевых новостей
              uucp            (8), -- сообщения подсистемы UUCP
              cron            (9), -- сообщения демона часов
              authpriv        (10),-- сообщения системы защиты и проверки полномочий
              ftp             (11),-- сообщения демона ftp
              ntp             (12),-- сообщения подсистемы NTP
              audit           (13),-- сообщения аудита
              console         (14),-- консольные сообщения
              cron2           (15),-- сообщения демона часов
              local0          (16),
              local1          (17),
              local2          (18),
              local3          (19),
              local4          (20),
              local5          (21),
              local6          (22),
              local7          (23)
            }

   SyslogSeverity  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "В этих текстовых соглашениях перечислены уровни важности (Severity)
            сообщений syslog.

            Уровни Severity в сообщениях syslog указываются десятичными числами.
            Для интероперабельности и совместимости си совместимости с более
            ранними версиями данный документ задает нормативное отображение
            между метками, представляющими значения Severity и соответствующими
            числовыми кодами. Метки могут применяться, например, в пользовательских
            интерфейсах приложений SNMP.

            Метка зачастую семантически бессмысленна, поскольку неразумно пытаться
            перечислить все возможные варианты Severity, а критерии, используемые
            инициаторами syslog, исторически зависят от реализации.

            Отметим, что механизмы операционной системы для настройки syslog
            (например, файл syslog.conf) еще не стандартизованы и могут применять
            разные наборы меток Severity  и/или их отображений на коды Severity.

            Например, приложение foobar может помечать сообщения как crit на 
            основе некого субъективного критерия. Оператор может настроить syslog на 
            пересылку сообщений, несмотря на то, что трактовка crit может различаться
            у разных инициаторов. Это обычная практика, поскольку инициаторы, 
            трансляторы и коллекторы могут настраиваться на подобающую обработку 
            таких ситуаций.
           "
       REFERENCE "Протокол Syslog (RFC5424): Таблица 2"
       SYNTAX  INTEGER
            {
              emerg           (0),  -- чрезвычайная ситуация, система не может использоваться
              alert           (1),  -- тревога, требуются незамедлительные действия
              crit            (2),  -- критическая ситуация
              err             (3),  -- ошибка
              warning         (4),  -- предупреждение
              notice          (5),  -- нормальная но важная ситуация (состояние)
              info            (6),  -- информационное сообщение
              debug           (7)   -- отладочное сообщение
            }
   END

4. Вопросы безопасности

Модуль не определяет каких-либо элементов управления, определены лишь текстовые соглашения, которые могут применяться другими модулями MIB для определения объектов управления. Значимые проблемы безопасности могут быть вызваны только модулями MIB, определяющими объекты управления. Следовательно, этот документ не оказывает влияния на безопасность Internet. Поскольку объекты, определенные с использованием описанных здесь TC, могут создавать проблемы безопасности, пользователям этих TC следует прочесть раздел «Вопросы безопасности» в [RFC5424].

5. Согласование с IANA

Модули MIB в этом документе используют приведенное в таблице значение OBJECT IDENTIFIER, выделенное IANA и включенное в реестр SMI Numbers.

Дескриптор

Значение OBJECT IDENTIFIER

syslogTCMIB

{ mib-2 173 }

6. Литература

6.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Textual Conventions for SMIv2», STD 58, RFC 2579, April 1999.

[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Conformance Statements for SMIv2», STD 58, RFC 2580, April 1999.

[RFC5424] Gerhards, R., «The Syslog Protocol», RFC 5424, March 2009.

6.2. Дополнительная литература

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, «Introduction and Applicability Statements for Internet-Standard Management Framework», RFC 3410, December 2002.

7. Благодарности

Этот документ является результатом работы группы Syslog. Автор благодарит Chris Lonvick, David Harrington, Juergen Schoenwaelder и Pasi Eronen за их комментарии и предложения.

Адрес автора

Glenn Mansfield Keeni

Cyber Solutions Inc.

6-6-3 Minami Yoshinari

Aoba-ku, Sendai 989-3204

Japan

Phone: +81-22-303-4012

EMail: glenn@cysols.com

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1В оригинале — IETF Contributions. Прим. перев.

2В оригинале — IETF Standards Process. Прим. перев.

3Management Information Base.

4Simple Network Management Protocol — простой протокол сетевого управления.

5Structure of Management Information — структура данных управления.

6Structured data element.

7Textual convention.




RFC 5426 Transmission of Syslog Messages over UDP

Network Working Group                                       A. Okmianski
Request for Comments: 5426                           Cisco Systems, Inc.
Category: Standards Track                                     March 2009

Передача сообщений Syslog по протоколу UDP

Transmission of Syslog Messages over UDP

PDF

Статус документа

Этот документ является проектом стандарта Internet (Internet Standards Track) и служит приглашением к дискуссии и внесению предложений с целью совершенствования протокола. Информацию о состоянии стандартизации и статусе протокола можно найти в текущей редакции документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

Авторские права

Авторские права (Copyright (c) 2009) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Этот документ может содержать материалы из документов IETF или участников IETF1, опубликованных или публично доступных до 10 ноября 2008 г. Лица, контролирующие авторские права на некоторые из таких материалов могли не предоставить IETF Trust прав на изменение таких материалов вне контекста стандартизации IETF2. Без получения соответствующей лицензии от лиц, контролирующих авторские права на такие материалы, этот документ не может быть изменен вне контекста стандартизации IETF, а также не могут открываться производные работы за пределами контекста стандартизации. Исключением является лишь форматирование документа для публикации в качестве RFC или перевод на другие языки.

Тезисы

Этот документ описывает транспортировку сообщений syslog на основе протоколов UDP/IPv4 и UDP/IPv6. Многоуровневая архитектура syslog обеспечивает поддержку любого числа транспортных протоколов. Однако для обеспечения интероперабельности реализации протокола syslog должны поддерживать описанное здесь транспортное отображение.

Оглавление

Исключено в версии HTML.

1. Введение

В информационном RFC 3164 [8] описаны имеющиеся реализации протокола syslog. Там описан как формат сообщений syslog, так и их передача по протоколу UDP [1]. В последствии был предложен проект стандарта (Standards-Track) для протокола syslog в RFC 5424 [2].

RFC 5424 задает многоуровневую архитектуру, обеспечивающую поддержку любого числа транспортных отображений для передачи сообщений syslog. Данный документ описывает транспортное отображение UDP для протокола syslog.

Описанный в этом документе транспорт может применяться для передачи сообщений как через IPv4 [3], так и через IPv6 [4].

Сетевые администраторы и архитекторы должны быть осведомлены о важных проблемах надежности и безопасности данного вида транспорта, связанных с использованием протокола UDP. Эти проблемы указаны в данной спецификации. Однако этот транспорт является облегченным и основан на популярном использовании UDP для syslog.

2. Соглашения об уровнях требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [5].

3. Транспортный протокол

3.1. Одно сообщение на дейтаграмму

Каждая дейтаграмма UDP должна содержать только одно сообщение syslog, которое может быть полным или усеченным. Форматирование и отсечка сообщений должны соответствовать RFC 5424 [2]. Включать в дейтаграммы дополнительные данные недопустимо.

3.2. Размер сообщения

Это транспортное отображение поддерживает передачу сообщений syslog размером до 65535 октетов минус размер заголовка UDP. Этот предел основан на максимальном размере дейтаграмм UDP в 65535 октетов, заданном в RFC 768 [1]. Для IPv4 максимальный размер данных (payload) составляет 65535 минус размер заголовков UDP и IP, поскольку IPv4 имеет 16-битовое поле размера, которое учитывает и размер заголовков.

В IPv4 получатели syslog должны быть способны принимать дейтаграммы размером до 480 октетов, включительно, а в IPv6 получатели syslog должны быть способны принимать дейтаграммы размером до 1180, включительно. Всем получателям syslog следует поддерживать возможность приема дейтаграмм размером до 2048, включительно. Рекомендуется принимать и более крупные сообщения.

Приведенные выше ограничения и рекомендации создают базу для взаимодействия. Минимальный поддерживаемый размер определен на основе минимального значения MTU, которое должны поддерживать хосты Internet — 576 октетов для IPv4 [3] и 1280 октетов для IPv6 [4]. Дейтаграммы, соответствующие этим ограничениям, имеют наилучшие шансы доставки, поскольку для них заведомо не требуется фрагментирования.

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

Фрагментация может быть нежелательной, поскольку она повышает риск потери сообщения в результате потери единственного фрагмента. Протокол syslog не имеет механизма подтверждений и, следовательно, — эффективного способа организации повторной передачи. Это не позволяет использовать в syslog средства определения MTU для пути на уровне пакетизации [9]. если значение MTU в сети неизвестно заранее, лучшим выходом будет предположить минимальное значение в 480 октетов для IPv4 b 1180 для IPv6.

3.3. Порты источника и адресата

Получатели syslog должны поддерживать прием дейтаграмм через общеизвестный порт UDP 514, но могут настраиваться на другой порт-получатель. Отправители syslog должны адресовать дейтаграммы с сообщениями syslog в порт UDP 514, но могут быть настроены на работу через иной порт. Отправители syslog могут использовать любой порт отправителя UDP для передачи сообщений.

3.4. IP-адрес источника

IP-адрес отправителя в дейтаграммах UDP не следует трактовать как адрес хоста-инициатора сообщения syslog. Отправителем сообщения syslog может оказаться транслятор. Адрес инициатора содержится в самом сообщении syslog.

3.5. Структура UDP/IP

Каждая дейтаграмма UDP/IP, передаваемая транспортным отправителем, должна полностью соответствовать структуре, указанной в UDP RFC 768 [1] и IPv4 RFC 791 [3] или IPv6 RFC 2460 [4] в зависимости от используемого протокола.

3.6. Контрольные суммы UDP

Отправителям syslog недопустимо отключать контрольные суммы UDP. Отправителям IPv4 syslog следует использовать контрольные суммы UDP при передаче сообщений. Отметим, что RFC 2460 [4] требует использования контрольных сумм UDP при передаче дейтаграмм UDP по протоколу IPv6.

Получателям syslog недопустимо отключать контрольные суммы UDP. Получателям IPv4 syslog следует проверять контрольные суммы UDP, а также следует воспринимать сообщения syslog с нулевой контрольной суммой. Отметим, что RFC 2460 [4] требует использования контрольных сумм UDP при передаче по протоколу IPv6.

4. Вопросы надежности

UDP представляет собой протокол с малыми издержками и без гарантии доставки. В этом разделе рассмотрены вопросы надежности UDP, которые следует принимать во внимание разработчикам и пользователям.

4.1. Потеря дейтаграмм

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

4.2. Повреждение сообщений

Дейтаграммы UDP/IP могут повреждаться в процессе доставки в результате программных, аппаратных или сетевых ошибок. Это транспортное отображение задает использование контрольных сумм UDP, позволяющие обнаружить поврежденные дейтаграммы, в дополнение к контрольным суммам, применяемым в IP и протоколах канального уровня (Layer 2). Однако контрольная сумма не гарантирует обнаружения ошибок, а данное транспортное отображение не поддерживает механизмов подтверждения или повторной передачи.

4.3. Контроль перегрузок

Поскольку syslog может создавать неограниченный объем данных, передача этих данных по протоколу UDP в общем случае проблематична, поскольку в UDP нет механизмов контроля перегрузок. Механизмы, реагирующие на перегрузки снижением скорости передачи трафика и обеспечивающее беспристрастное разделение ресурсов между потоками, использующими общий путь, имеют очень важное значение для стабильной работы Internet [6]. Именно по этой причине транспорт TLS для syslog [7] требуется от всех реализаций и рекомендуется для общего применения.

Единственным вариантом, где для syslog может использоваться транспорт UDP в качестве альтернативы транспорту TLS, являются управляемые сети, в которых явно обеспечиваются пути для трафика UDP syslog с использованием механизмов организации трафика типа ограничения скорости или резервирования пропускной способности. Во всех прочих средах следует использовать транспорт TLS [7].

4.4. Порядок доставки

Транспорт IP, используемый протоколом UDP, не гарантирует упорядоченной доставки дейтаграмм. Временные метки в каждом сообщении syslog могут применяться для восстановления порядка. Однако это не поможет в тех случаях, когда в одном интервале отсчета времени создается множество сообщений, отправитель не может создавать временные метки или сообщения приходят от разных хостов, часы которых не синхронизированы. Порядок доставки сообщений syslog с использованием данного транспорта не следует использовать в качестве основы для восстановления абсолютного или относительного порядка событий на создавших сообщения syslog хостах.

5. Вопросы безопасности

Использовать данную спецификацию в незащищенных сетях не рекомендуется. Некоторые вопросы безопасности syslog рассмотрены в RFC 5424 [2]. В этом разделе рассмотрены конкретные вопросы безопасности при доставке сообщений syslog по протоколу UDP. Некоторые из отмеченных ниже проблем безопасности можно смягчить за счет применения IPsec в соответствии с RFC 4301 [10].

5.1. Проверка подлинности отправителя и подмена сообщений

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

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

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

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

5.2. Раскрытие сообщений

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

5.3. Повторное использование сообщений

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

5.4. Ненадежность доставка

Как было отмечено в разделе 4. Вопросы надежности, транспорт UDP не является надежным и пакеты с дейтаграммами сообщений syslog могут теряться в процессе передачи без уведомления об этом. Потеря одного или множества сообщений syslog может иметь последствия для безопасности. Администраторы могут не узнать о возникновении и развитии той или иной потенциально серьезной проблемы. Сообщения могут также перехватываться и отбрасываться злоумышленниками для сокрытия своей деятельности.

5.5. Приоритизация и дифференцирование сообщений

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

5.6. Отказ служб

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

6. Согласование с IANA

Этот транспорт использует порт UDP 514 для syslog, как указано в реестре IANA для номеров портов.

7. Благодарности

Автор благодарит участников работы над документом: Chris Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova, Devin Kowatch, Richard Graveman и все другие люди, приславшие комментарии к разным версиям этого предложения.

8. Литература

8.1. Нормативные документы

[1] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

[2] Gerhards, R., «The Syslog Protocol», RFC 5424, March 2009.

[3] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[4] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[5] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[6] Floyd, S., «Congestion Control Principles», BCP 41, RFC 2914, September 2000.

[7] Miao, F. and Y. Ma, «TLS Transport Mapping for Syslog», RFC 5425, March 2009.

8.2. Дополнительная литература

[8] Lonvick, C., «The BSD Syslog Protocol», RFC 3164, August 2001.

[9] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[10] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.


Адрес автора

Anton Okmianski

Cisco Systems, Inc.

595 Burrard St., Suite 2123

Vancouver, BC V7X 1J1

Canada

Phone: +1-978-936-1612

EMail: aokmians@cisco.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1В оригинале — IETF Contributions. Прим. перев.

2В оригинале — IETF Standards Process. Прим. перев.




RFC 5425 Transport Layer Security (TLS) Transport Mapping for Syslog

Network Working Group                                       F. Miao, Ed.
Request for Comments: 5425                                    Y. Ma, Ed.
Category: Standards Track                            Huawei Technologies
                                                         J. Salowey, Ed.
                                                     Cisco Systems, Inc.
                                                              March 2009

Транспортное отображение TLS для Syslog

Transport Layer Security (TLS) Transport Mapping for Syslog

PDF

Статус документа

Этот документ является проектом стандарта Internet (Internet Standards Track) и служит приглашением к дискуссии и внесению предложений с целью совершенствования протокола. Информацию о состоянии стандартизации и статусе протокола можно найти в текущей редакции документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

Авторские права

Авторские права (Copyright (c) 2009) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Этот документ может содержать материалы из документов IETF или участников IETF1, опубликованных или публично доступных до 10 ноября 2008 г. Лица, контролирующие авторские права на некоторые из таких материалов могли не предоставить IETF Trust прав на изменение таких материалов вне контекста стандартизации IETF2. Без получения соответствующей лицензии от лиц, контролирующих авторские права на такие материалы, этот документ не может быть изменен вне контекста стандартизации IETF, а также не могут открываться производные работы за пределами контекста стандартизации. Исключением является лишь форматирование документа для публикации в качестве RFC или перевод на другие языки.

Тезисы

В этом документе описано использование защиты транспортного уровня (TLS3) для обеспечения защиты соединений, служащих для транспортировки сообщений syslog. Описаны угрозы безопасности syslog и способы использования TLS для преодоления таких угроз.

Оглавление

Исключено в варианте HTML.

1. Введение

В этом документе описано использование защиты транспортного уровня (TLS [RFC5246]) для обеспечения защиты соединений, служащих для транспортировки сообщений syslog. Описаны угрозы безопасности syslog и способы использования TLS для преодоления таких угроз.

1.1. Терминология

Ниже приведены определения используемых в документе терминов.

  • «инициатор» (originator) генерирует содержимое для передачи в сообщениях syslog;

  • «коллектор» (collector) собирает содержимое сообщений syslog для дальнейшего анализа;

  • «транслятор» (relay) пересылает сообщения, воспринимает сообщения от инициатора или других трансляторов и передает их коллекторам или другим трансляторам;

  • «транспортный отправитель» (transport sender) передает сообщения syslog заданному транспортному протоколу;

  • «транспортный получатель» (transport receiver) принимает сообщения syslog от заданного транспортного протокола;

  • клиент TLS — приложение, которое может инициировать соединение TLS, передавая серверу Client Hello;

  • сервер TLS — приложение, которое может принимать сообщения Client Hello от клиентов и отвечать на низ сообщениями Server Hello.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

2. Требования безопасности для Syslog

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

Имеется несколько угроз, которые требуется учитывать в плане безопасности syslog. Основные из них указаны ниже.

  • Маскировка. Неуполномоченный транспортный отправитель может передавать сообщения легитимному транспортному получателю или неуполномоченный транспортный получатель может попытаться обмануть легитимного траспортного отправителя с целью получения от того сообщений syslog.

  • Изменение. Атакующий, расположенный между транспортными отправителем и получателем, может изменять передаваемые сообщения syslog и после этого пересылать их транспортному получателю. Такие изменения могут сделать сообщения непонятными транспортному получателю или изменить его поведение нежелательным образом.

  • Раскрытие. Неуполномоченный элемент может просматривать содержимое сообщений syslog, получая несанкционированный доступ к информации. Некоторые данные в сообщениях syslog являются «деликатными» и могут помочь атакующему в его деятельности (например, пароли администраторов или уполномоченных пользователей).

Другая угроза описана ниже.

  • Изменение потока сообщений. Атакующий может удалить одно или несколько сообщений syslog из последовательности, повторно использовать сообщения или поменять порядок их доставки. Сам протокол syslog не поддерживает порядка сообщений. Однако события, указанные в сообщениях syslog, могут быть семантически связанными с событиями из других сообщений и порядок доставки может быть важен для понимания порядка событий.

Ниже перечислены угрозы, которые считаются менее важными для syslog и не рассматриваются в этом документе.

  • Отказ в обслуживании;

  • анализ трафика.

3. Применение TLS для защиты Syslog

TLS можно использовать в качестве защищенного транспорта с учетом всех перечисленных выше основных угроз:

  • защита конфиденциальности для предотвращения раскрытия содержимого сообщений;

  • контроль целостности для предотвращения изменения сообщений в процесс пересылки;

  • аутентификация сервера или взаимная аутентификация для предотвращения маскировки.

Примечание. Этот транспорт (т. е., TLS) защищает syslog поэтапно (hop-by-hop) и не связан с содержимым сообщений syslog. В частности, подтвержденная идентификация транспортного отправителя (например, имя субъекта в сертификате) не обязательно относится к полю HOSTNAME в сообщении syslog. Если нужна проверка подлинности источника сообщений syslog, можно использовать [SYS-SIGN].

4. Элементы протокола

4.1. Выделение портов

Транспортный отправитель syslog всегда является клиентом TLS, а транспортный получатель — всегда сервер TLS.

Порт TCP с номером 6514 выделен для использования по умолчанию при передаче сообщений syslog через TLS в соответствии с данным документом.

4.2. Инициирование

Транспортному отправителю следует инициировать соединение с транспортным получателем, а затем передать TLS Client Hello для начала согласования TLS. После завершения согласования TLS транспортный отправитель может передать первое сообщение MAY.

TLS обычно использует сертификаты [RFC5280] для аутентификации партнеров. Разработчики должны поддерживать TLS 1.2 [RFC5246] и требуется также поддержка обязательного для реализации шифра TLS_RSA_WITH_AES_128_CBC_SHA. Предполагается применимость данного документа для будущих версий TLS и в таких случаях должны поддерживаться обязательные для реализации в соответствующей версии шифры.

4.2.1. Проверка подлинности на основе сертификатов

Транспортный отправитель syslog (клиент TLS) и транспортный получатель syslog (сервер TLS) должны поддерживать аутентификацию на основе сертификатов. Это включает проверку самого сертификата и наличия у партнера соответствующего секретного ключа. Последняя часть выполняется TLS. Для обеспечения взаимодействия между клиентами и серверами нужно реализовать перечисленные ниже методы проверки приемлемости сертификатов.

  • Проверка пути сертификации. Партнер TLS имеет одну или множество доверенных привязок (обычно сертификаты корневых УЦ4), которые позволяют ему проверить связь между именем субъекта и открытым ключом. Нужны дополнительные правила для проверки полномочий транспортного отправителя и получателя syslog (т. е., проверки наличия полномочий у указанного именем субъекта), которые описаны в разделе 5. Проверка пути сертификации выполняется в соответствии с определением [RFC5280]. Этот метод полезен при наличии инфраструктуры открытых ключей (PKI5).

  • Соответствие конечного элемента сертификата. В конфигурации транспортного отправителя и получателя имеется информация, требуемая для идентификации действительных сертификатов его уполномоченных партнеров. Сертификаты конечных элементов могут быть самоподписанными и в этом случае проверка пути сертификации не требуется. Реализации должны поддерживать отпечатки сертификатов (параграф 4.2.2) и могут разрешать другие форматы сертификатов конечных элементов типа сертификатов в DER-представлении. Этот метод служит дополнением к PKI, которое проще в развертывании и обеспечивает достаточный уровень защиты.

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

Транспортным получателям и отправителям следует поддерживать механизмы для записи сертификатов конечных элементов с целью их сопоставления с принятыми или переданными данными.

4.2.2. Отпечатки сертификатов

Реализации клиента и сервера должны делать отпечатки своих сертификатов (certificate fingerprint) доступными через интерфейс управления. Метки для алгоритмов берутся из текстовых имен хэш-функций, определенных в реестре IANA Hash Function Textual Names, выделенном в [RFC4572].

Механизм генерации отпечатков заключается в том, что берется хэш сертификата в DER-представлении с использованием криптостойкого алгоритма и результат преобразуется в разделенные двоеточиями шестнадцатеричные байты, каждый из которых представлен двумя символами ASCII в верхнем регистре. Когда значение отпечатка отображается или задается в конфигурации перед ним добавляется метка ASCII для хэш-функции, за которой следует двоеточие. Реализации должны поддерживать SHA-1 в качестве алгоритма хэширования и использовать для его идентификации метку sha-1. Размер хэш-значения SHA-1 составляет 20 байтов, а соответствующий отпечаток будет содержать 65 символов. Пример такого отпечатка приведен ниже.

      sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D

Для проверки хэш-значение извлекается из отпечатка и сравнивается с хэш-значением, рассчитанным для полученного сертификата.

4.2.3. Криптографический уровень

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

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

4.3. Передача данных

Все сообщения syslog должны передаваться как прикладные данные TLS (application data). Возможно помещать множество сообщений syslog в одну запись TLS или разделять одно сообщение syslog для передачи в нескольких записях TLS. Прикладные данные определяются приведенным ниже выражением ABNF [RFC5234].

   APPLICATION-DATA = 1*SYSLOG-FRAME
   SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
   MSG-LEN = NONZERO-DIGIT *DIGIT
   SP = %d32
   NONZERO-DIGIT = %d49-57
   DIGIT = %d48 / NONZERO-DIGIT
   SYSLOG-MSG определено в протоколе syslog [RFC5424].

4.3.1. Размер сообщения

Размер сообщения представляет собой значение счетчика октетов SYSLOG-MSG в SYSLOG-FRAME. Транспортный получатель должен использовать размер сообщения для определения его границы. Верхнего предела для размера сообщений не задается. Однако для обеспечения интероперабельности данная спецификация указывает, что транспортный получатель должен быть способен обрабатывать сообщения размером до 2048 октетов, включительно. Транспортным получателям следует поддерживать обработку сообщений размером до 8192 октетов, включительно.

4.4. Закрытие сессий

Транспортный отправитель должен закрывать соответствующее соединение TLS, если через него больше не планируется доставка сообщений syslog. Он должен передать сигнал TLS close_notify перед закрытием соединения. Транспортный отправитель (клиент TLS) может выбрать отказ от ожидания сигнала close_notify от транспортного получателя и просто закрыть соединение, что приводит к неполному закрытию на стороне транспортного получателя (сервер TLS). После того, как транспортный отправитель получит сигнал close_от транспортного получателя, он должен ответить сигналом close_notify, если у него еще нет информации о том, что соединение уже закрыто транспортным отправителем (например, закрытие соединения указал протокол TCP).

Когда через соединение в течение продолжительного времени (интервал определяется приложением) не поступает сообщений syslog, транспортный получатель может закрыть соединение. Перед этим транспортный получатель (сервер TLS) должен предпринять попытку обмена сигналами close_notify с транспортным отправителем. Транспортные получатели, не готовые принимать никаких данных, могут закрыть соединение после отправки сигнала close_notify, что приводит к неполному закрытию соединения на стороне транспортного отправителя.

5. Правила безопасности

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

Если партнер не соответствует требованиям политики безопасности, согласование TLS должно прерываться с подобающим сигналом TLS.

5.1. Проверка полномочий на основе сертификата конечного элемента

В простейшем случае конфигурация транспортных отправителей и получателей включает данные, требуемые для идентификации приемлемых сертификатов своих уполномоченных партнеров.

Реализации должны поддерживать указание уполномоченных партнеров с использованием отпечатков сертификатов, как описано в параграфах 4.2.1 и 4.2.2.

5.2. Проверки полномочий по имени субъекта

Реализации должны поддерживать проверку пути сертификации [RFC5280]. Кроме того, они должны поддерживать указание уполномоченных партнеров с использованием локально заданных имен хостов и проверку соответствия имен, как описано ниже.

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

  • Символ-шаблон * (ASCII 42) разрешается использовать в поле dNSName расширения subjectAltName (и общем имени, если оно служит для сохранения имени хоста), но лишь в самой левой (наименее значимой) метке DNS в данном значении. Этому шабблону соответствует любая первая слева метка DNS в имени сервера. Т. е., субъект *.example.com соответствует именам сервером a.example.com и b.example.com, но не соответствует example.com и a.b.example.com. Реализации должны поддерживать шаблоны в сертификатах, как указано выше, но могут включать конфигурационную опцию для запрета этого.

  • Локально заданные имена могут включать символы-шаблоны, соответствующие диапазону значений. Тип поддерживаемых шаблонов может быть более гибким, нежели разрешается в именах субъектов для обеспечения возможности поддержки разных правил для различных сред. Например, правило может разрешать проверку полномочий на основе «доверенного корня» (trust-root-based), где все свидетельства, выпущенные конкретным УЦ (CA), считаются полномочными.

  • Если локально заданные имена являются национальными доменными именами, соответствующие требованиям реализации должны преобразовывать такие имена в формат ACE6 для сравнения в соответствии с правилами раздела 7 в [RFC5280].

  • Реализации могут поддерживать сопоставление заданных локально адресов IP со значениями iPAddress в расширении subjectAltName. В этос случае заданные локально адреса IP преобразуются в строки октетов, как указано в параграфе 4.2.1.6 [RFC5280]. Полученная строка октетов проверяется на совпадение со значением iPAddress в расширении subjectAltName.

5.3. Неаутентифицированный транспортный отправитель

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

5.4. Неаутентифицированный транспортный получатель

В некоторых средах конфиденциальность данных syslog не важна и сообщения можно отправлять любому транспортному получателю. Для этого транспортный отправитель может пропустить проверку подлинности транспортного получателя (воспринимая любой сертификат). Хотя такая политика проверяет подлинность и полномочия транспортного отправителя, она не обеспечивает защиты от угроз маскирования транспортного получателя, описанных в разделе 2, и переданные данные остаются уязвимыми для раскрытия и изменения. По этой причине использование такой политики в общем случае не рекомендуется.

5.5. Неаутентифицированный транспортный получатель и отправитель

В средах, где безопасность совсем не важна, проверка подлинности (параграфы 5.3 и 5.4) может быть пропущена для транспортного получателя и транспортного отправителя. Такая политика не защищает от угроз, описанных в разделе 2 и по этой причине не рекомендуется.

6. Вопросы безопасности

В этом разделе описаны проблемы безопасности, дополняющие рассмотренные в [RFC5246].

6.1. Правила проверки подлинности и полномочий

В разделе 5 рассмотрены разные правила безопасности, которые могут применяться. Отмеченные в разделе 2 угрозы можно преодолеть лишь в том случае, когда транспортный отправитель и транспортный получатель подобающим образом проверяются на предмет подлинности и полномочий, как описано в параграфах 5.1 и 5.2. Такую политику безопасности рекомендуется устанавливать по умолчанию.

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

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

Отказ от проверки подлинности и полномочий на обеих сторонах открывает их для атак MITM, маскировки и других типов, которые могут нарушить целостность и конфиденциальность данных. Такая конфигурация не рекомендуется.

6.2. Проверка имен

Политика проверки подлинности субъекта сертификата требует сравнения имени субъекта с заданными локально именами. Получение этих имен иными путями (типа запросов DNS) обычно неприемлема, поскольку открывает другие уязвимости защиты.

6.3. Надежность

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

7. Согласование с IANA

7.1. Номер порта

Агентство IANA выделило порт TCP с номером 6514 и именем syslog-tls из диапазона Registered Port Numbers. Этот порт используется по умолчанию для передачи сообщений syslog через TLS, как определено в этом документе.

8. Благодарности

Авторы благодарят Eric Rescorla, Rainer Gerhards, Tom Petch, Anton Okmianski, Balazs Scheidler, Bert Wijnen, Martin Schuette, Chris Lonvick и членов рабочей группы syslog за их участие в дискуссиях. Авторы также признательны Balazs Scheidler, Tom Petch и другим людям за их информацию об угрозах для syslog. Авторы благодарят David Harrington за подробный анализ содержимого и грамматики документа, а также Pasi Eronen за его вклад в разделы по аутентификации и проверке полномочий.

9. Литература

9.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC5234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008.

[RFC5424] Gerhards, R., «The Syslog Protocol», RFC 5424, March 2009.

9.2. Дополнительная литература

[RFC4572] Lennox, J., «Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)», RFC 4572, July 2006.

[SYS-SIGN] Kelsey, J., «Signed syslog Messages», Work in Progress7, October 2007.

Адреса авторов

Fuyou Miao (редактор)

Huawei Technologies

No. 3, Xinxi Rd

Shangdi Information Industry Base

Haidian District, Beijing 100085

P. R. China

Phone: +86 10 8288 2008

EMail: miaofy@huawei.com

URI: www.huawei.com

Yuzhi Ma (редактор)

Huawei Technologies

No. 3, Xinxi Rd

Shangdi Information Industry Base

Haidian District, Beijing 100085

P. R. China

Phone: +86 10 8288 2008

EMail: myz@huawei.com

URI: www.huawei.com

Joseph Salowey (редактор)

Cisco Systems, Inc.

2901 3rd. Ave

Seattle, WA 98121

USA

EMail: jsalowey@cisco.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com


1В оригинале — IETF Contributions. Прим. перев.

2В оригинале — IETF Standards Process. Прим. перев.

3Transport Layer Security

4Удостоверяющий центр — CA (certification authority). Прим. перев.

5Public Key Infrastructure.

6ASCII Compatible Encoding — совместимое с ASCII представление.

7Работа завершена и опубликована в RFC 5848. Прим. перев.




RFC 5424 The Syslog Protocol

Network Working Group                                        R. Gerhards
Request for Comments: 5424                                  Adiscon GmbH
Obsoletes: 3164                                               March 2009
Category: Standards Track

Протокол Syslog

The Syslog Protocol

PDF

Статус документа

Этот документ является проектом стандарта Internet (Internet Standards Track) и служит приглашением к дискуссии и внесению предложений с целью совершенствования протокола. Информацию о состоянии стандартизации и статусе протокола можно найти в текущей редакции документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

Авторские права

Авторские права (Copyright (c) 2009) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Этот документ может содержать материалы из документов IETF или участников IETF1, опубликованных или публично доступных до 10 ноября 2008 г. Лица, контролирующие авторские права на некоторые из таких материалов могли не предоставить IETF Trust прав на изменение таких материалов вне контекста стандартизации IETF2. Без получения соответствующей лицензии от лиц, контролирующих авторские права на такие материалы, этот документ не может быть изменен вне контекста стандартизации IETF, а также не могут открываться производные работы за пределами контекста стандартизации. Исключением является лишь форматирование документа для публикации в качестве RFC или перевод на другие языки.

Тезисы

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

Этот документ разрабатывался с учетом устройства традиционной системы syslog. Необходимость создания многоуровневой спецификации связана с тем, что для стандартизации надежных и безопасных расширения syslog остро не хватало документов типа Standards-Track и независимых от транспорта RFC. Без этого документа все прочие стандарты должны были бы определять свой формат пакетов syslog и механизм их доставки, что обязательно привело бы к проблемам совместимости. Многоуровневая архитектура обеспечивает прочную основу и позволяет за один раз создавать код для каждой функции syslog и вида транспорта.

Этот документ отменяет RFC 3164.

Оглавление

Исключено в версии HTML.

 

1. Введение

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

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

Документ не описывает форматов хранения сообщений syslog, поскольку это выходит за рамки протокола syslog и не требуется для интероперабельности.

При разработке документа принимались во внимание исходные цели традиционного протокола syslog. Потребность в разработке новой многоуровневой модели обусловлена тем, что для стандартизации надежных и безопасных расширения syslog остро не хватало документов типа Standards-Track и независимых от транспорта RFC. Без этого документа все прочие стандарты должны были бы определять свой формат пакетов syslog и механизм их доставки, что обязательно привело бы к проблемам совместимости. Многоуровневая архитектура обеспечивает прочную основу и позволяет за один раз создавать код для каждой функции syslog и вида транспорта.

Документ отменяет RFC 3164, который включал информацию о некоторых имеющихся реализациях протокола.

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

3. Определения

Syslog использует три уровня, перечисленных ниже.

  • «содержимое» (syslog content) — информация в сообщениях syslog;

  • «приложение» (syslog application) — генерация, интерпретация, маршрутизация и хранение сообщений syslog;

  • «транспорт» (syslog transport) — передача сообщений в «канал» и считывание из «канала».

На каждом концептуальном уровне выполняются некоторые функции, разделенные по ролям.

  • «инициатор» (originator) генерирует содержимое для передачи в сообщениях syslog;

  • «коллектор» (collector) собирает содержимое сообщений syslog для дальнейшего анализа;

  • «транслятор» (relay) пересылает сообщения, воспринимает сообщения от инициатора или других трансляторов и передает их коллекторам или другим трансляторам;

  • «транспортный отправитель» (transport sender) передает сообщения syslog заданному транспортному протоколу;

  • «транспортный получатель» (transport receiver) принимает сообщения syslog от заданного транспортного протокола.

На рисунке 1 показаны уровни и роли.

 +---------------------+    +---------------------+
 |  содержимое         |    |  содержимое         |
 |---------------------|    |---------------------|
 |  приложение syslog  |    |  приложение syslog  | (инициатор,
 |                     |    |                     |  коллектор, транслятор)
 |---------------------|    |---------------------|
 |  транспорт syslog   |    |  транспорт syslog   | (транспортный отправитель,
 |                     |    |                     |  транспортный получатель)
 +---------------------+    +---------------------+
           ^                          ^
           |                          |
            --------------------------

Рисунок 1. Уровни Syslog


4. Базовые принципы

Ниже перечислены принципы, применяемые к коммуникациям syslog.

  • Протокол syslog не обеспечивает подтверждения доставки сообщений. Хотя некоторые виды транспорта могут сообщать о состоянии передачи, концептуально протокол syslog является симплексным (односторонним).

  • Инициаторы и трансляторы можно настроить на передачу одного и того же сообщения множеству коллекторов и/или трансляторов.

  • Инициатор, транслятор и коллектор могут функционально размещаться в одной системе.

4.1. Примеры развертывания

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

            +----------+         +---------+
            |Инициатор |---->----|Коллектор|
            +----------+         +---------+
            +----------+         +----------+         +---------+
            |Инициатор |---->----|Транслятор|---->----|Коллектор|
            +----------+         +----------+         +---------+
            +----------+     +----------+            +----------+     +---------+
            |Инициатор |-->--|Транслятор|-->--..-->--|Транслятор|-->--|Коллектор|
            +----------+     +----------+            +----------+     +---------+
            +----------+         +----------+         +---------+
            |Инициатор |---->----|Транслятор|---->----|Коллектор|
            |          |-+       +----------+         +---------+
            +----------+  \
                           \     +----------+         +---------+
                            +->--|Транслятор|---->----|Коллектор|
                                 +----------+         +---------+
            +----------+         +---------+
            |Инициатор |---->----|Коллектор|
            |          |-+       +---------+
            +----------+  \
                           \     +----------+         +---------+
                            +->--|Транслятор|---->----|Коллектор|
                                 +----------+         +---------+

            +----------+         +----------+            +---------+
            |Инициатор |---->----|Транслятор|---->-------|Коллектор|
            |          |-+       +----------+        +---|         |
            +----------+  \                         /    +---------+
                           \     +----------+      /
                            +->--|Транслятор|-->--/
                                 +----------+
            +----------+         +----------+                   +---------+
            |Инициатор |---->----|Транслятор|---->--------------|Коллектор|
            |          |-+       +----------+           +-------|         |
            +----------+  \                            /        +---------+
                           \     +------------+       /
                            \    |+----------+|      /
                             +->-||Транслятор||->---/
                                 |+----------||    /
                                 ||Инициатор ||->-/
                                 |+----------+|
                                 +------------+

Рисунок 2. Некоторые варианты развертывания syslog.

5. Протокол транспортного уровня

Этот документ не задает какой-либо протокол транспортного уровня. Вместо этого описывается формат сообщений syslog, независимый от транспорта. Транспортные протоколы syslog определяются в других документах. Один из вариантов транспорта определен в [RFC5426] и согласуется с традиционным транспортом UDP. Этот транспорт нужен для поддержки интероперабельности, поскольку протокол UDP исторически применялся для передачи сообщений syslog.

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

5.1. Минимальные требования к транспортному отображению

Все реализации данной спецификации должны поддерживать транспорт на основе TLS, как описано в [RFC5425].

Все реализациям также следует поддерживать основанный на протоколе UDP транспорт, как описано в [RFC5426].

Реализациям рекомендуется использовать транспорт на базе 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 транспортным отображением. Сам по себе верхний предел не существует. Каждое транспортное отображение определяет нижний предел поддерживаемого максимального размера сообщений и это значение должно быть не менее 480 октетов.

Любой транспортный получатель должен обеспечивать восприятие сообщений размером до 480 октетов, включительно. Всем реализациям транспортных получателей следует воспринимать сообщения размером до 2048 октетов, включительно. Транспортные получатели могут принимать сообщения размером более 2048 октетов. Если транспортный получатель принимает сообщение, размер которого превышает поддерживаемое им значение, получателю следует отсечь часть данных в этом сообщении до приемлемого размера. Возможно также отбрасывание таких сообщений.

Если транспортный получатель отсекает часть сообщения, отбрасываться должна последняя часть сообщения (конец). Отсечка сообщения может вызвать повреждение кодировки UTF-8 или данных STRUCTURED-DATA. Транспортный получатель может отбросить такое сообщение или попытаться его обработать.

6.2. HEADER

В заголовке (HEADER) должен использоваться 7-битовый набор символов ASCII в 8-битовых полях, как описано в [RFC5234]. Код ASCII определен в USA Standard Code for Information Interchange [ANSI.X3-4.1968].

Формат заголовка должен обеспечивать некоторую совместимость со старыми системами BSD syslog (см. Приложение A.1).

6.2.1. PRI

В PRI должно быть от 3 до 5 символов, первый и последний из которых являются угловыми скобками. PRI начинается с левой скобки < (знак «меньше», %d60), за которым следует число и правая угловая скобка > (знак «больше», %d62). Число в угловых скобках называют приоритетом (Priority, PRIVAL) и представляет как источник (Facility), так и важность (Severity). Priority может включать от одной до трех десятичных цифр (ABNF DIGITS), которые могут принимать значения от %d48 (для 0) до %d57 (для 9).

Значения Facility и Severity не являются нормативными, но используются часто. Эти значения приведены ниже в таблице только для справки. Значения Facility должны относиться к диапазону от 0 до 23, включительно.

Таблица 1. Источники сообщений syslog

Код

Источник (значимость)

0

Сообщения ядра

1

Сообщения пользовательского уровня

2

Почтовая система

3

Системные службы (демоны)

4

Сообщения, связанные с защитой и предоставлением полномочий

5

Внутренние сообщения syslogd

6

Подсистема печати (line printer)

7

Подсистема сетевых новостей (network news)

8

Подсистема UUCP

9

Часы (демон)

10

Сообщения, связанные с защитой и предоставлением полномочий

11

Демон FTP

12

Подсистема NTP

13

Аудит (log audit)

14

Сигнал (log alert)

15

Часы (демон)

16

Локальное (local0)

17

Локальное (local1)

18

Локальное (local2)

19

Локальное (local3)

20

Локальное (local4)

21

Локальное (local5)

22

Локальное (local6)

23

Локальное (local7)

В каждом сообщении Priority также включает десятичные индикатор уровня важности (Severity). Значения важности и описания приведены в таблице. Severity должны относиться к диапазону от 0 до 7, включительно.

Таблица 2. Уровни важности сообщений syslog

Код

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

0

Emergency — чрезвычайная ситуация, система не может использоваться

1

Alert — тревога, требуются незамедлительные действия

2

Critical — критическая ситуация

3

Error — ошибка

4

Warning — предупреждение

5

Замечание, нормальная но важная ситуация (состояние)

6

Informational — информационное сообщение

7

Debug — отладочное сообщение

Значение Priority рассчитывается по формуле 8 * Facility + Severity. Например, для сообщения ядра (Facility=0) с уровнем важности Emergency (Severity=0) будет Priority = 0. А для сообщения local4 (Facility=20) с уровнем важности Notice (Severity=5) мы получим Priority = 165. В PRI сообщения syslog эти значения будут указываться в виде <0> и <165>, соответственно. За угловой скобкой число 0 указывается только для случая Priority = 0, а в остальных случаях использовать символ в начале поля недопустимо.

6.2.2. VERSION

Поле VERSION указывает версию спецификации протокола syslog. Номер версии должен увеличиваться для любой новой спецификации, меняющей любую часть формата HEADER. К таким изменениям относятся добавление или удаление полей, а также изменение синтаксиса или семантики имеющихся полей. Данный документ устанавливает VERSION = 1. Значения VERSION выделяются агентством IANA (параграф 9.1) по процедуре Standards Action, описанной в [RFC5226].

6.2.3. TIMESTAMP

Поле TIMESTAMP содержит формализованную временную метку [RFC3339].

Хотя [RFC3339] разрешает множество вариантов синтаксиса, данный документ вносит дополнительные ограничения. Поле TIMESTAMP должно соответствовать приведенным ниже требованиям:

  • символы T и Z должны использовать верхний регистр (заглавные буквы);

  • использование символа T обязательно;

  • недопустимо использовать високосные секунды.

Инициатору следует включать TIME-SECFRAC, если это позволяют точность часов и производительность. Параметр timeQuality SD-ID, описанный в параграфе 7.1, позволяет инициатору задать точность и достоверность временных меток.

Приложения syslog должны использовать NILVALUE в качестве TIMESTAMP при неспособности syslog получить системное время.

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, но время указно для часового пояса US Eastern Standard Time (с учетом летнего времени).

Пример 3

        2003-10-11T22:14:15.003Z

Это значение представляет 11 октября 2003 года, 10:14:15 после полудня и 3 мсек. следующей секунды для часового пояса UTC. Временная метка обеспечивает миллисекундное разрешение. Создатель метки может иметь более высокое разрешение, но ограничение дробной части секунд тремя цифрами не позволяет задать время с большей точностью.

Пример 4

         2003-08-24T05:14:15.000003-07:00

Это значение представляет 24 августа 2003 года, 05:14:15 до полудня и 3 мксек. Следующей секунды. Микросекундное разрешение указывается дополнительными цифрами в TIME-SECFRAC. Метка относится к часовому поясу -7 по отношению к UTC. Такая метка может быть создана для часового пояса US Pacific в период действия летнего времени.

Пример 5 — неприемлемая метка TIMESTAMP

         2003-08-24T05:14:15.000000003-07:00

Эта метка похожа на показанную в примере 4, но TIME-SECFRAC указывает время в наносекундах. В результате размер TIME-SECFRAC превышает дозволенные 6 цифр, что делает метку неприемлемой.

6.2.4. HOSTNAME

Поле HOSTNAME указывает машину, котоая была исходным отправителем сообщения syslog.

В поле HOSTNAME следует включать имя хоста или полное доменное имя инициатора в формате, заданном STD 13 [RFC1034]. Этот формат в данном документе называется FQDN3.

На практике не все приложения syslog способны предоставлять FQDN. По этой причине в полях HOSTNAME могут указываться другие значения. В данном документе содержатся предложения по использованию других значений в таких ситуациях. Приложению syslog следует выбирать наиболее конкретное (специфичное) значение из числа представленных ниже в порядке снижения предпочтений (специфичности):

  1. FQDN;

  2. статический адрес IP;

  3. имя хоста (hostname);

  4. динамический адрес IP;

  5. NILVALUE.

При использовании адреса IPv4 он должен указываться в форме десятичных чисел, разделенных точками, как указано в STD 13 [RFC1035]. Если используется адрес IPv6, он должен указываться в корректном текстовом представлении, как описано в параграфе 2.2 [RFC4291].

Приложениям syslog следует использовать в поле HOSTNAME одно и то же имя, пока это возможно.

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

6.2.5. APP-NAME

В полях APP-NAME следует указывать устройство или приложение, создавшее это сообщение. Поле представляет собой строку без дополнительной семантики и предназначено для фильтрации сообщений на трансляторах и коллекторах.

Если приложение syslog не знает своего имени для APP-NAME или не может предоставить такую информацию, можно использовать NILVALUE. Устройство может оказаться не способным предоставить эту информацию в силу ограничений локальной политики, а также в результате недоступности информации или ее неприменимости к данному устройству.

Это поле может присваиваться оператором.

6.2.6. PROCID

Значения PROCID, включаемые в сообщения, не имеют переносимого (за пределы локальной системы) смысла и могут лишь в некоторых случаях показывать прерывание работы syslog. Поле не имеет какого-либо конкретного синтаксиса и семантики — оно зависит от реализации и/или оператора. При отсутствии идентификатора может указываться значение NILVALUE.

Поле PROCID часто применяется для указания имени или идентификатора процесса, связанного с системой syslog. При недоступности имени и идентификатора может указываться значение NILVALUE. На встраиваемых системах без идентификаторов процесса в ОС в качестве PROCID может служить идентификатор перезагрузки.

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

PROCID может также применяться для идентификации сообщений, относящихся к той или иной группе. Например, агент SMTP MTA4 может помещать идентификатор транзакции SMTP в поле PROCID, что позволит коллекторам и трансляторам группировать сообщения по идентификатору транзакции SMTP.

6.2.7. MSGID

В поле MSGID следует указывать тип сообщения. Например, межсетевой экран может указывать в поле MSGID значение TCPIN для входящего трафика TCP и TCPOUT для исходящего. Сообщения с одинаковыми полями MSGID должны отражать события с одинаковой семантикой. Само поле MSGID является текстовой строкой без дополнительной семантики и предназначено для фильтрации сообщений на трансляторах и коллекторах.

Если приложение syslog не может предоставить какого-либо значения для этого поля, следует использовать NILVALUE.

Это поле может присваиваться оператором.

6.3. STRUCTURED-DATA

Механизм STRUCTURED-DATA обеспечивает представление информации в четко определенном, легко читаемом и интерпретируемом формате. Имеется множество вариантов использования этого механизма. Например, с его помощью можно указать метаданные о сообщении syslog или специфическую для приложения информацию типа счетчиков трафика или адресов IP.

Структура STRUCTURED-DATA может содержать множество структурированных элементов данных, которые обозначаются далее SD-ELEMENT.

Если структура не содержит структурированных элементов данных, в поле STRUCTURED-DATA должно помещаться значение NILVALUE.

Данные в STRUCTURED-DATA должны представляться в 7-битовой кодировке ASCII, как описано в [RFC5234]. Коды ASCII определены с USA Standard Code for Information Interchange [ANSI.X3-4.1968]. Исключением является поле PARAM-VALUE (параграф 6.3.3), в котором должна использоваться кодировка UTF-8.

Коллектор может игнорировать некорректно сформированные элементы STRUCTURED-DATA, транслятор должен пересылать такие поля STRUCTURED-DATA в неизменном виде.

6.3.1. SD-ELEMENT

Элемент данных SD-ELEMENT состоит из имени и пар «имя — значение». Имя обозначается SD-ID, пары «имя — значение» — SD-PARAM.

6.3.2. SD-ID

Регистр символов в SD-ID принимается во внимание и эти поля служат уникальными идентификаторами типа и назначения SD-ELEMENT. В одном сообщении недопустимо наличие одинаковых SD-ID.

Для имен SD-ID используются два формата, описанных ниже.

  • Имена, не содержащие символа @ (ABNF %d64), зарезервированы для распределения по процедуре IETF Review, описанной в BCP26 [RFC5226]. Определенные к настоящему моменту имена описаны в разделе 7. Имена такого формата применимы лишь после регистрации в IANA. В зарегистрированных именах недопустимо наличие символов @ (ABNF %d64), = (ABNF %d61), ] (ABNF %d93), » (ABNF %d34), пробелов и символов управления (символы ASCII с кодами 127 и от 0 до 32).

  • Кто угодно может определить дополнительные SD-ID, используя формат name@<private enterprise number> (например, ourSDID@32473). Формат имени слева от символа @ не задается, однако эти имена должны представлять строки печатных символов US-ASCII и в них недопустимо включать символы @ (ABNF %d64), = (ABNF %d61), ] (ABNF %d93), » (ABNF %d34), пробелов и символы управления. Справа от символа @ должен указываться фирменный номер (private enterprise number), как описано в параграфе 7.2.2. В этом документе в качестве такого номера используется строка 32473. Это значение было выделено IANA для использования в качестве примеров в документации. Разработчики должны использовать выделенное им значение номера при создании локально расширяемых имен 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 должна применяться кодировка UTF-8. Приложение syslog может ввести любую корректную последовательность UTF-8. Приложения syslog должны воспринимать любые корректные последовательности UTF-8 в «кратчайшей форме». Недопустимы отказы по причине наличия в PARAM-VALUE управляющих символов. Приложение syslog может менять сообщения с управляющими символами (например, заменяя октеты со значением 0 (USASCII NUL) четырьмя символами #000). По причинам, описанным в параграфе 3.1 UNICODE TR36 [UNICODE-TR36], инициатор должен представлять сообщения в «кратчайшей форме» (shortest form), а коллекторам недопустимо интерпретировать сообщения, не имеющие «кратчайшей формы» (non-shortest form).

В PARAM-VALUE для символов » (ABNF %d34), \ (ABNF %d92) и ] (ABNF %d93) должно использоваться escape-представление, требуемое для предотвращения ошибок при разборе. Использование escape-представления для символа ] не является строго обязательным, но данная спецификация требует это для предотвращения ошибок при реализации приложений syslog. Для из этих трех символов должно использоваться представление \», \\ и \], соответственно. Escape-представление символа \ применяется для согласованности с другими частями сообщений syslog, а также с традиционными приложениями syslog.

Символ \, за которым не следует ни одного из указанных выше трех символов, рассматривается, как неприемлемая escape-последовательность. В таких случаях этот и следующий за ним символ должны трактоваться, как обычные символы. Таким образом, некорректная последовательность не изменяется.

SD-PARAM может неоднократно повторяться в одном SD-ELEMENT.

6.3.4. Контроль изменений

После определения SD-ID и PARAM-NAME менять синтаксис и семантику этих объектов недопустимо. Если нужно изменить существующий объект, должны создаваться новые SD-ID или PARAM-NAME , а старые сохраняться неизменными. К существующим SD-ID можно добавить необязательные (опциональные) PARAM-NAME.

6.3.5. Примеры

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

Пример 1 — корректно

           [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]

Этот пример показывает структурированный элемент данных с неконтролируемым IANA SD-ID типа exampleSDID@32473, имеющим три параметра.

Пример 2 — корректно

           [exampleSDID@32473 iut="3" eventSource="Application"
           eventID="1011"][examplePriority@32473 class="high"]

Аналогично примеру 1, но включает второй структурированный элемент данных, который следует сразу же за первым (без SP между ними).

Пример 3 — некорректно

           [exampleSDID@32473 iut="3" eventSource="Application"
           eventID="1011"] [examplePriority@32473 class="high"]

Этот пример похож на предыдущий, но включает небольшую ошибку — между двумя структрированными элементами данных имеется пропуск (]SP[). Это некорректно и приводит к тому, что поле STRUCTURED-DATA будет заканчиваться после первого элемента, а второй будет интерпретироваться, как часть поля MSG.

Пример 4 — некорректно

           [ exampleSDID@32473 iut="3" eventSource="Application"
           eventID="1011"][examplePriority@32473 class="high"]

Этот пример почти совпадает с примером 2, но включает другую ошибку — символ SP после начальной скобки. Структурированный элемент SD-ID должен следовать сразу же после открывающей скобки, поэтому наличие пропуска (SP) делает поле STRUCTURED-DATA неприемлемым. Приложение syslog может отбросить такое сообщение.

Пример 5 — корректно

           [sigSig ver="1" rsID="1234" ... signature="..."]

Пример 5 является корректным и показывает гипотетический SD-ID, выделенный IANA. Точки в этом примере применены для сокращения.

6.4. MSG

Компонента MSG содержит сообщение в свободной форме с информацией о событии.

В MSG следует использовать кодировку UNICODE в варианте UTF-8, как описано в [RFC3629]. Если приложение syslog не может представить MSG в Unicode, оно может воспользоваться любой другой кодировкой.

Приложениям syslog следует избегать включения октетов со значениями меньше 32 (диапазон символов управления традиционной кодировки US-ASCII за исключением DEL). Эти значения разрешены, но приложения syslog могут менять такие символы при получении. Например, они могут быть заменены escape-последовательностями (т. е., 0 может смениться на \0). Приложениям syslog не следует менять значения каких-либо иных октетов.

Если приложение syslog представляет MSG в кодировке UTF-8, строка должна начинаться с маски BOM5, которая для UTF-8 представляет собой ABNF %xEF.BB.BF. Приложение syslog должно использовать «кратчайшую форму» (shortest form) и может применять любые корректные последовательности UTF-8.

Если приложение syslog обрабатывает строку MSG, начинающуюся с BOM и MSG содержит UTF-8 не в кратчайшей форме, недопустимо интерпретировать MSG, как строку в кодировке UTF-8 по причинам, указанным в параграфе 3.1 [UNICODE-TR36]. Рекомендации для таких случаев приведены в Приложении A.8.

В соответствии с UNICODE TR36 [UNICODE-TR36] приложению syslog недопустимо интерпретировать сообщения, которые не имеют кратчай1шей формы. Им недопустимо также интерпретировать некорректные последовательности UTF-8.

6.5. Примеры

Ниже приведены примеры корректных сообщений syslog, сопровожденные описаниями. Примеры основаны на похожих примерах из [RFC3164] и могут быть знакомы читателям. Непечатаемая маска Unicode BOM в примерах обозначена последовательностью 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 года в 10: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 года в 5:14:15 до полудня по времени -7 часов относительно UTC, плюс 3 мксек следующей секунды. Поле HOSTNAME содержит адрес 192.0.2.1, поскольку приложение syslog не знает имени FQDN и указало вместо него один из адресов IPv4. Поле APP-NAME имеет значение myproc, а PROCID = 8710 (это может быть, например, UNIX PID). STRUCTURED-DATA нет в сообщении, что показано символом «-» в поле STRUCTURED-DATA. Идентификатора сообщения (MSGID) нет и это показано символом «-» в поле MSGID.

Текст сообщения %% It’s time to make the do-nuts. Не включает Unicode BOM и приложение 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...

Этот пример создан на основе примера 1, однако в нем содержится структура STRUCTURED-DATA с одним элементом [exampleSDID@32473 iut=»3″ eventSource=»Application» eventID=»1011″]. Само сообщение (MSG) является строкой An application event log entry… в кодировке UTF-8, указанной BOM.

Пример 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. Идентификаторы структурированных данных

В этом разделе описаны изначально зарегистрированные IANA значения SD-ID. Определение структурированных элементов данных приведено в параграфе 6.3. Все определенные здесь SD-ID являются необязательными (OPTIONAL).

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

7.1. timeQuality

Элемент timeQuality в SD-ID может использоваться инициатором для описания своего понимания системного времени. Этот SD-ID следует включать, если инициатор не имеет должной синхронизации с надежным внешним источником точного времени или не знает корректного часового пояса. Основным применением этого элемента структурированных данных является предоставления сведений об уровне доверия к значению TIMESTAMP (см. параграф 6.2.3). Все параметры этого элемента являются необязательными.

7.1.1. tzKnown

Параметр tzKnown показывает, известен ли инициатору часовой пояс. При известном часовом поясе должно указываться значение 1. Если информация о часовом поясе сомнительна, должно указываться значение 0. Если инициатор знает часовой пояс, но хочет указывать время в формате UTC, он должен указать значение 1 (часовой пояс известен).

7.1.2. isSynced

Параметр isSynced говорит о наличии синхронизации с надежным внешним источником синхронизации (например, по протоколу NTP). Если время инициатора синхронизировано, он должен указывать значение 1, в противном случае должно указываться значение 0.

7.1.3. syncAccuracy

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

При isSynced = 0 недопустимо указывать этот параметр. Если isSynced = 1, но параметр syncAccuracy не указан, коллектор или транслятор будет предполагать точность синхронизации достаточной. Параметр syncAccuracy должен указываться только в тех случаях, когда инициатор имеет данные о надежности внешнего источника точного времени. В большинстве случаев такую информацию извлекают из конфигурации оператора.

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

Элемент origin в SD-ID может служить для индикации инициатора сообщения syslog. Ниже описаны параметры элемента. Все эти параметры являются необязательными.

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

7.2.1. ip

Параметр ip указывает IP-адрес, известный инициатору в момент создания сообщения. Этот параметр должен содержать текстовое представление адреса IP, как описано в параграфе 6.2.4.

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

Если у инициатора множество адресов IP, он может включить в параметр ip один из таких адресов и может также указать множество параметров ip в одном элементе структурированных данных origin.

7.2.2. enterpriseId

Параметр enterpriseId должен содержать код SMI Network Management Private Enterprise Code, поддерживаемый IANA, с префиксом iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). Следующее за префиксом значение должно быть уникальным, а также должно быть зарегистрировано в IANA в соответствии с RFC 2578 [RFC2578]. Предприятия имеют полномочия выделять значения только в субдереве iso.org.dod.internet.private.enterprise.<private enterprise number>, выделенном IANA этому предприятию. Параметр enterpriseId должен содержать только значение из субдерева iso.org.dod.internet.private.enterprise.<private enterprise number>. В общем случае требуется лишь выделенный IANA номер (одно значение). Предприятие может использовать дополнительные субидентификаторы после выделенного предприятию номера. Такие субидентификаторы должны разделяться точками и представляться в десятичном формате. Примерм может служить номер 32473.1.2. Следует отметить, что идентификатор 32473.1.2 служит примером и применять его на практике недопустимо. Полный список актуальных номеров PEN6 поддерживается IANA.

Указывая идентификатор предприятия можно дополнительно конкретизировать обработку сообщения.

7.2.3. software

Параметр software служит уникальным идентификатором программы, создавшей сообщение. При использовании этого параметра следует указывать также enterpriseId для идентификации производителя программы. Параметр software не совпадает с полем заголовка APP-NAME и всегда должен содержать имя создавшей сообщение программы, тогда как в APP-NAME может включаться любое имя, включая заданное оператором значение.

Параметр software представляет собой строку. Недопустимо использовать в этой строке более 48 символов.

7.2.4. swVersion

Параметр swVersion уникально идентифицирует версию программы, создавшей сообщение. Если этот параметр используется, следует также указывать параметры software и enterpriseId.

Параметр swVersion представляет собой строку. Недопустимо использовать в этой строке более 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

Элемент meta в SD-ID может служить для предоставления мета-данных о сообщении. Параметры этого элемента описаны ниже, все параметры являются необязательными (OPTIONAL). При использовании элемента meta в SD-ID следует включить хотя бы один параметр.

7.3.1. sequenceId

Параметр sequenceId служит для отслеживания порядка, в котором инициатор отправляет сообщения транспорту syslog для передачи. Этот параметр является целым числом, для которого должно устанавливаться значение 1 при запуске функции syslog. Значение параметра должно увеличиваться для каждого последующего сообщения. Максимальное значение номера составляет 2147483647 и при достижении максимума следующее сообщение должно получать номер 1.

7.3.2. sysUpTime

Параметр sysUpTime может использоваться для включения в параметр SNMP sysUpTime в сообщении. Синтаксис и семантика параметра определены в [RFC3418].

Протокол syslog не поддерживает напрямую синтаксис SNMP INTEGER и значение должно представляться в десятичном формате (без десятичной точки) с использованием только символов 0, 1, 2, 3, 4, 5, 6, 7, 8 и 9.

Смысл параметра указан в RFC 3418, как «время (в сотых долях секунды) с момента, когда связанная с сетевым управленим часть системы была в последний раз реинициализирована». Это, естественно, относится к связанной с SNMP частью управления системой, которая может не совпадать с той частью системы управления, которая связана с syslog.

7.3.3. language

Параметр language может использоваться инициатором для указания естественного языка, применяемого в поле MSG. Если параметр используется, он должен содержать идентификатор языка, определенный в BCP 47 [RFC4646].

8. Вопросы безопасности

8.1. Кодировка UNICODE

Этот документ задает использование кодировки UTFдля полей PARAM-VALUE и MSG. С кодировкой UNICODE связано множество проблем безопасности. Всем разработчикам и операторам следует внимательно прочесть документ UNICODE TR36 [UNICODE-TR36] (UTR36), в котором рассмотрены эти проблемы. Данный документ защищает от технических проблем, описанных в UTR36, требуя применять «кратчайшую форму» (shortest form) кодирования для приложений syslog. Однако возможность путаницы, связанной с одинаковым изображением разных символов, сохраняется. Этот документ пытается минимизировать влияние данной проблемы, разрешая использовать UNICODE только там, где ожидаются и требуются локальные сценарии (script). Во всех прочих полях требуется использовать кодировку US-ASCII. Кроме того, поля PARAM-VALUE и MSG не следует рассматривать в качестве основного источника идентификационной информации и это позволит дополнительно снизить риск, связанный с одинаковым изображением разных символов.

8.2. Управляющие символы

Этот документ не вносит каких-либо обязательных для исполнения ограничений на содержимое MSG и PARAM-VALUE. Поэтому данные поля могут содержать символы управления, включая NUL.

В некоторых языках программирования (прежде всего, C и C++) символ NUL (ABNF %d00) традиционно применяется в качестве завершения строки. Большинство реализаций этих языков предполагают, что строка завершается первым NUL-символом. Это ограничение отражается прежде всего на использовании библиотек. Данное ограничение часто переносится на прикладные программы и языки сценариев, написанные с использованием упомянутых языков. Таким образом, символы NUL требуют внимательного отношения и аккуратной обработки. Атакующий может преднамеренно включить символы NUL для сокрытия расположенной после них информации. Некорректная обработка NUL-символов может также приводить к искажению контрольных сумм, передаваемых внутри сообщений.

Многие популярные текстовые редакторы также написаны на языках с упомянутым ограничением. Целесообразно кодировать NUL-символы при записи текстовых файлов. Если записывать эти символы без специального представления, файл может оказаться непригодным для чтения.

Другие символы управления также могут создавать проблемы. Например, атакующий может преднамеренно включать символы «забоя» (backspace), чтобы сделать часть сообщения не читаемой. Подобные проблемы возникают почти для всех управляющих символов.

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

Данная спецификация разрешает приложениям syslog переформатировать полученные управляющие символы. Это обусловлено, в частности, значительными рисками, связанными с управляющими символами. Инициаторам следует принимать во внимание, что при использовании ими кодировок, отличных от ASCII и UTF8, получатель может «повредить» сообщение при попытке отфильтровать управляющие символы ASCII.

8.3. Отсечка сообщений

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

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

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

8.4. Повторное использование сообщений

В протоколе syslog нет механизмов детектирования повторного применения сообщений (replay). Атакующий может записать набор сообщений, показывающих нормальную работу машины. Позднее он может удалить данную машину из сети и отправить собранные сообщения syslog транслятору или коллектору. Даже с учетом поля TIMESTAMP в заголовке (HEADER) атакующий может записать пакеты и просто изменить временные метки в соответствии с текущим временем, а потом повторно передать сообщения. Администраторы могут не заметить ничего необычного в полученных сообщениях и ошибочно трактовать их получение как признак нормальной работы машины.

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

8.5. Гарантии доставки

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

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

Гарантированная доставка сообщений желательна не всегда. Гарантированная доставка означает необходимость блокировки инициатора или транслятора когда коллектор или транслятор не способен больше воспринимать сообщения. В некоторых операционных системах (Unix/Linux) инициатор или транслятор syslog работает в рамках системного процесса с высоким приоритетом (syslogd). Если это процесс блокируется, система в целом «зависает». То же самое будет наблюдаться при взаимной блокировке между syslogd и, например, сервером DNS.

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

8.6. Контроль перегрузок

Поскольку syslog может генерировать неограниченный объем данных, передача этих данных по протоколу UDP в общем случае проблематична по причине слабого контроля перегрузок в UDP. Механизмы контроля насыщения, которые реагируют на перегрузку снижением скорости передачи и обеспечивают беспристрастное распределение пропускной способности между потоками одного пути, играют важную роль в обеспечении стабильной работы Internet [RFC2914]. Этим объясняется то, что транспорт TLS для syslog требуется реализовать и этот траспорт рекомендуется для общего применения.

Единственным случаем, где транспорт UDP для syslog может служить альтернативно для транспорта TLS, являются управляемые сети в которых могут быть явно обеспечены пути для трафика UDP syslog с помощью механизмов организации трафика (traffic engineering) типа ограничения скорости или резервирования пропускной способности. Во всех других следах следует применять транспорт TLS.

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

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

8.7. Целостность сообщений

Помимо того, что сообщения syslog могут быть отвергнуты, они могут повреждаться при передаче или изменяться атакующими. В таких случаях исходное содержимое сообщения не попадет к коллекторам и трансляторам. Кроме того при расположении атакующего между транспортным отправителем и транспортным получателем сообщений syslog этот атакующий может перехватывать и изменять сообщения «на лету» для сокрытия несанкционированных действий.

8.8. Просмотр сообщений

Несмотря на отсутствие строгих рекомендаций по формату MSG, большинство сообщений syslog создается в понятной человеку форме с расчетом на то, что способные администраторы смогут читать и понимать эти сообщения. В протоколе syslog нет механизмов защиты конфиденциальности передаваемых сообщений. В большинстве случаев передача сообщений в форме открытого текста обеспечивает преимущества для сотрудников оператора, если они собирают пакеты из линии. Сотрудники оператора могут читать сообщения и сопоставлять их с другими событиями, которые видны из проходящих в линии пакетов, для отслеживания и решения проблем. К сожалению, атакующие также могут видеть содержимое понятных человеку сообщений syslog. Злоумышленники могут использовать полученную информацию для компрометации машины или других нарушений работы.

Для предотвращения этой проблемы операторам рекомендуется использовать защищенное транспортное отображение.

8.9. Неприемлемая конфигурация

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

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

8.10. Петли в пересылке

Как показано на рисунке 2, машины могут быть настроены на пересылку сообщений syslog последующим трансляторам с целью доставки коллектору. В одной реальной ситуации администратор обнаружил, что он ошибочно настроил два транслятора на пересылку сообщений с некоторыми значениями SEVERITY от одного к другому и обратно. Когда любая из этих машин получит или создаст сообщение соответствующего типа, она будет пересылать его другому транслятору. Тот, в свою очередь, перешлет его обратно. Этот (бесконечный) цикл пересылки будет перегружать промежуточную сеть и сами машины. Администраторам следует соблюдать осторожность, чтобы таких петель не возникало.

8.11. Вопросы загрузки

Сетевые администраторы должны найти время для оценки емкости коллектора syslog. Атакующий может организовать DoS-атаку7, заполняя дисковое пространство коллектора ложными сообщениями. Организация циклической перезаписи позволяет решить эту проблемы, но при этом администратор утратит возможность видеть достаточно старые8 записи.Транспортный получатель должен иметь сетевой интерфейс, способный принимать отправленные ему сообщения.

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

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

8.12. Отказ в обслуживании

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

9. Согласование с IANA

9.1. VERSION

Агентство IANA создало реестр syslog Version Values значений VERSION, описанных в параграфе 6.2.2. Номера версий должны увеличиваться для каждой новой спецификации протокола syslog, в которой меняется какая-либо из частей заголовка (HEADER). Изменения включают добавление или удаление полей, а также смену синтаксиса или семантики имеющихся полей.

Значения VERSION должны регистрироваться в соответствии с процедурой Standards Action, как описано в [RFC5226]. Зарегистрированное IANA значение VERSION приведено в таблице 3.

Таблица 3. Зарегистрированное IANA значение VERSION

Версия

Формат

1

Определен в [RFC5424]

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.

Таблица 4. Зарегистрированные IANA значения SD-ID и их PARAM-NAME

SD-ID

PARAM-NAME

Тип

timeQuality

OPTIONAL

tzKnown

OPTIONAL

isSynced

OPTIONAL

syncAccuracy

OPTIONAL

origin

OPTIONAL

ip

OPTIONAL

enterpriseId

OPTIONAL

software

OPTIONAL

swVersion

OPTIONAL

meta

OPTIONAL

sequenceId

OPTIONAL

sysUpTime

OPTIONAL

language

OPTIONAL

10. Рабочая группа

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

syslog@ietf.org

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

Chris Lonvick

Cisco Systems

EMail: clonvick@cisco.com

David Harrington

Huawei Technologies USA

EMail: 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], относящемся к серии информационных (Informational RFC), и практика показывает наличие множества разных реализаций. Исследования в процессе создания этого документа показали, что у разных реализаций syslog на различных платформах очень мало общего. Единственное, на что все реализации согласны, — начинать сообщения с «<» PRIVAL «>». Во всем остальном унаследованные сообщения syslog не используют согласованного формата. По этой причине в RFC 3164 не описаны конкретные элементы сообщений syslog. В документе сказано, что любые сообщения, адресованные в порт syslog UDP, должны трактоваться как сообщения syslog, независимо от их формата и содержимого.

Данный документ сохраняет синтаксис и семантику значения PRI. Это позволит унаследованным реализациям syslog сохранить совместимость генерируемых сообщений syslog с данной спецификацией .

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

RFC 3164 описывает поведение трансляторов, а данный документ не задает этого поведения. Оно может быть описано в отдельном документе.

Поле TIMESTAMP, описанное в RFC 3164, обеспечивает меньшую точность по сравнению с метками, описанными в данном документе. В нем также не хватает информации о годе и часовом поясе. Если соответствующий этому документу формат нужно преобразовать в формат RFC 3164, предлагается использовать локальный часовой пояс отправителя, отбрасывая информацию о часовом поясе и годе. Если нужно преобразовать полученное сообщение RFC 3164 в заданный этим документом формат, следует добавить текущий год и часовой пояс, который может использоваться транслятором или коллектором.

Поле HOSTNAME в RFC 3164 менее конкретно, но его формат поддерживается данным документом в качестве одного из дополнительных представления HOSTNAME.

Часть MSG описана как TAG и CONTENT в RFC 3164. В данном документе MSG представляет собой то, что обозначено CONTENT в RFC 3164. TAG сейчас является частью заголовка, не представляя собой отдельного поля. Значение TAG разделено между полями APP-NAME, PROCID и MSGID. Это несколько отличается отличается от использования TAG, но в большинстве случаев обеспечивает ту же функциональность.

В RFC 3164 структурированные данные (STRUCTURED-DATA) не описаны. Если соответствующее этому документу сообщение, содержащее STRUCTURED-DATA, нужно преобразовать в соответствии с RFC 3164, STRUCTURED-DATA просто становится частью текста в свободном формате RFC 3164 CONTENT.

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

A.2. Размер сообщений

Разработчикам следует помнить об ограничениях размера сообщений, отмеченных в параграфе 6.1, и пытаться разместить наиболее важные детали сообщения в его начале (в пределах минимально гарантируемого размера). Это обеспечит доступ к таким данных трансляторов и коллекторов даже в тех случаях, когда транспортный получатель на трансляторе по пути доставки использует отсечку для сообщения.

Причина того, что от транспортных получателей syslog требуется поддержка приема сообщений размером лишь до 480 октетов (включительно), заключается, наряду с другими причинами, в сложностях проблемы доставки в старых сетях. Сообщения syslog могут использовать транспортное отображение UDP с ограничением в 480 октетов для предотвращения сеансовых издержек и фрагментации сообщений. В сетях с проблемами вероятность успешной доставки однопакетного сообщения выше, нежели вероятность доставки фрагментов сообщения в двух пакетах. Следовательно, увеличение размера сообщений может лишить оператора части критически важной информации при возникновении проблемы тогда, как использование мелких сообщений обеспечит доставку этой информации. Рекомендуется для сообщений, связанных с поиском неполадок ограничивать размер 480 октетами. Следует также отметить, что некоторые реализации UDP не поддерживают сообщений размером более 480 октетов. Такое поведение встречается весьма редко и может уже не создавать проблемы.

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

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

Следует отметить, что IPv6 MTU примерно в 2,5 раза превышает 480. Реализации, предназначенные для применения исключительно в средах IPv6, могут учесть этот факт при ограничении размера сообщений.

A.3. Значения важности

В этом разделе приведены рекомендации по использованию значений важности (Severity) описанных в параграфе 6.2.1.

Все реализациям следует пытаться выделять наиболее подходящие значения важности для их сообщений. Наиболее важно присваивать сообщениям, предназначенным для включения отладки или тестирования программ присваивать значение Severity = 7. Severity 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 case9. Каждое имя начинается с маленькой буквы (нижний регистр), а каждое новое слово, встроенное в имя, начинается с заглавной буквы без использования дефиса или другого разделителя. Примером этого может служить timeQuality.

Хотя разработчики свободны при выборе регистра символов в экспериментальных именах, предполагается, что они будут следовать принятому здесь соглашению.

A.6. Приложения Syslog, не знающие времени

В параграфе 6.2.3 разрешено использование значения NILVALUE в качестве временной метки инициаторами, не имеющими часов. Можно возразить, что таких приложений уже не найти в современных инфраструктурах IT. Однако обсуждение этого вопроса показывает, что такие устройства еще могут встречаться на практике и поэтому следует обеспечить возможность работы с ними.

Однако реализациям следует указывать действительное время в TIMESTAMP, если операционная система, программа или оборудование включают часы. Действительное время в TIMESTAMP следует указывать даже в тех случаях, когда сложно получить системное время. Значение NILVALUE следует указывать лишь в тех случаях, когда просто нет возможности определить текущее время. Это разрешение не следует использовать в качестве оправдания для ленивых разработчиков.

A.7. Замечания по timeQuality SD-ID

Рекомендуется по умолчанию использовать значение 0 для параметра tzKnown (параграф 7.1.1). Следует указывать значение 1 лишь в тех случаях, когда администратор указал в конфигурации конкретный часовой пояс. Можно использовать значение 1 по умолчанию, если операционная система предоставляет точную информацию о часовом поясе. Однако и в таких случаях администратору следует убедиться в корректности данных о часовом поясе.

Важно не порождать заблуждений о точности временных меток в timeQuality SD-ID ( параграф 7.1). Инициатору следует указывать только такую точность, в которой он уверен. В общем случае предполагается, что администратор может выяснить точность часов по конфигурации оператора. По умолчанию точность часов указывать не следует.

A.8. Кодировка UTF-8 и BOM

В этом документе указано, что информация SD-PARAMS всегда должна представляться в кодировке UTF-8. Использование других кодировок в разделе MSG (включая кодировку ASCIIPRINT) не разрешается для устройств, соответствующих данной спецификации. Здесь нужно рассмотреть два особых случая. Во-первых, соответствующие данной спецификации приложения syslog, могут оказаться не способны убедиться в том, что представленная инициатором информация использует кодировку UTF-8. Если нет возможности с уверенностью определить это, приложение syslog может выбрать отказ от включения BOM в MSG. Если приложение syslog имеет достоверное указание того, что содержимое сообщения представлено в кодировке UTF-8, ему следует включать BOM. В другом случае транслятор syslog может пересылать сообщения от устройств, которые не соответствуют данной спецификации. В этой ситуации устройство явно не будет включать BOM, пока не будет уверенности в том, что полученное сообщение использует кодировку UTF-8.

Адрес автора

Rainer Gerhards

Adiscon GmbH

Mozartstrasse 21

Grossrinderfeld, BW 97950

Germany

EMail: rgerhards@adiscon.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com


1В оригинале — IETF Contributions. Прим. перев.

2В оригинале — IETF Standards Process. Прим. перев.

3Fully Qualified Domain Name — полное доменное имя.

4Mail transfer agent – агент передачи электронной почты.

5Unicode byte order mask – маска порядка байтов Unicode.

6Private Enterprise Numbers.

7Denial of Service — отказ в обслуживании.

8Больше продолжительности цикла. Прим. перев.

9Стиль верблюда.