RFC 3164

Материал из Wikilivres.ru
Перейти к: навигация, поиск

RFC 3164 (Протокол BSD Syslog)
автор [[C. Lonvick|C. Lonvick]], пер. StLeutnant
Язык оригинала: английский. Название в оригинале: RFC 3164 (The BSD Syslog Protocol). — Опубл.: август 2001 года. Источник: RFC 3164


Network Working Group

Request for Comments: 3164
Category: Informational

С. Lonvick

Cisco Systems
August 2001

Протокол BSD Syslog


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

Этот документ предоставляет информацию для Общества Интернета. Здесь не описывается спецификация какого-либо Стандарта Интернет любого рода. Распространение данного документа[перевод 1] не ограничено.


Уведомление об авторских правах

Copyright (C) 2001. Все права принадлежат Обществу Интернета. Все права защищены.


Аннотация

Настоящий документ представляет собой обзор текущего состояния протокола Syslog. Этот протокол уже многие годы применяется для передачи по сети сообщений, уведомляющих о произошедших событиях. Хотя данный протокол изначально был разработан при реализации систем TCP/IP Berkeley Software Distribution (BSD) Калифорнийского Университета, но его значимость для функционирования и управления привела к тому, что он был перенесен на многие другие операционные системы, а также встроен во многие сетевые устройства.

Содержание

Введение

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

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

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

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

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

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

В самых упрощенных терминах, протокол Syslog обеспечил транспорт, позволяющий доставлять сообщения, уведомляющие о событиях, от устройств до коллекторов сообщений (так называемых, серверов Syslog) по сетям IP.

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

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

События и сообщения

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

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

Устройства ДОЛЖНЫ быть сконфигурированы в соответствии с правилами, определяющими порядок действий, например, отобразить сообщение о событии на экране и/или передать его по сети. Заметим, что правила эти обычно очень гибки. Администратор может захотеть сохранять локально все сообщения, но, вместе с тем, направлять другому устройству все сообщения высокой важности. Затем он может посчитать необходимым также отправлять некоторым или всем пользователям устройства сообщения от определенного субъекта и, одновременно, отображать их на системной консоли.

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

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

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

Действия получателя сообщений

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

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

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

Syslog использует UDP[1] в качестве базового механизма транспортного уровня. Для обслуживания протокола Syslog был выделен порт UDP 514. Для отправки сообщений РЕКОМЕНДУЕТСЯ тоже использовать порт 514, чтобы указать, что это сообщение от процесса отправителя Syslog, но не исключается передача допустимых сообщений Syslog отправителем с исходного порта, отличного от 514. Если отправитель использует исходный порт, отличный от 514, тогда ему РЕКОМЕНДУЕТСЯ (и, как полагали, это было хорошей идеей) отправлять последующие сообщения с этого единственного выбранного непротиворечивого порта.

Определения и архитектура

В настоящем документе используются следующие определения:

  • «устройство» — машина, генерирующая сообщения,
  • «ретранслятор» — машина, получающая сообщения и перенаправляющая их другим машинам,
  • «коллектор» или «сервер Syslog» — машина, только получающая сообщения и не перенаправляющая их другим машинам,
  • «отправитель» — любое устройство или ретранслятор, отправляющее сообщения,
  • «получатель» — любой коллектор или ретранслятор, получающий сообщения.

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

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

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

+----------+         +---------+
|Устройство|---->----|Коллектор|
+----------+         +---------+

+----------+         +------------+         +---------+
|Устройство|---->----|Ретранслятор|---->----|Коллектор|
+----------+         +------------+         +---------+

+----------+   +------------+        +------------+   +---------+
|Устройство|->-|Ретранслятор|->-..->-|Ретранслятор|->-|Коллектор|
+----------+   +------------+        +------------+   +---------+

+----------+         +------------+         +---------+
|Устройство|---->----|Ретранслятор|---->----|Коллектор|
|          |-+       +------------+         +---------+
+----------+  \
               \     +------------+         +---------+
                +->--|Ретранслятор|---->----|Коллектор|
                     +------------+         +---------+

+----------+         +---------+
|Устройство|---->----|Коллектор|
|          |-+       +---------+
+----------+  \
               \     +------------+         +---------+
                +->--|Ретранслятор|---->----|Коллектор|
                     +------------+         +---------+

+----------+         +------------+            +---------+
|Устройство|---->----|Ретранслятор|---->-------|Коллектор|
|          |-+       +------------+        +---|         |
+----------+  \                           /    +---------+
               \     +------------+      /
                +->--|Ретранслятор|-->--/
                     +------------+

Схема 1.  Некоторые возможные архитектуры Syslog

Формат пакетов и содержимого

Полезная нагрузка любого пакета IP, портом назначения которого является порт UDP 514, ДОЛЖНА быть обработана как сообщение Syslog. Формат первоначально переданного сообщения Syslog МОЖЕТ отличаться от формата ретранслированного сообщения. В основном РЕКОМЕНДУЕТСЯ передавать сообщения Syslog в формате, предлагаемом настоящим документом, но это не является обязательным требованием. Если ретранслятор в состоянии распознать, что сообщение придерживается предложенного в данном документе формата, то он ДОЛЖЕН передать его дальше, не производя в нем никаких изменений. Напротив, если ретранслятор, получив сообщение, не может различить его реализацию в надлежащем формате, то от него ТРЕБУЕТСЯ изменить сообщение так, чтобы оно соответствовало нужному формату, прежде, чем оно будет отправлено дальше. В Разделе 4.1 описывается РЕКОМЕНДУЕМЫЙ формат сообщений Syslog. В Разделе 4.2 изложены требования к исходным сообщениям, а в Разделе 4.3к ретранслированным сообщениям.

Части сообщения Syslog

В содержимом наблюдаемых в настоящее время сообщений Syslog можно выделить три заметные части. Первую часть называют PRI (приоритет), вторую — HEADER (заголовок), а третьюMSG (сообщение). Полная длина пакета[перевод 3] НЕ ДОЛЖНА превышать 1024 байта. Ограничений на минимальную длину сообщений Syslog нет, хотя отправка пакета без содержимого бессмысленна и НЕ ДОЛЖНА выполняться.

PRI (приоритет)

Область PRI МОЖЕТ состоять из трех, четырех или пяти символов и должна содержать символы угловых скобок в первой и последней позициях. Область PRI начинается с символа „< (знак «меньше», %d60), за которым следует число, и заканчивается символом „> (знак «больше», %d62). При заполнении данной области ДОЛЖЕН использоваться набор символов 7-битной ASCII-кодировки[перевод 4], как это описано в RFC 2234[2]. Символы в такой кодировке еще называют «ASCII-кодами» в соответствии с определением, данным в «USA Standard Code for Information Interchange»[3]. Откуда следует, что символ „< в расширенной форме Бэкуса-Наура (ABNF)[перевод 5] имеет значение %d60, а символ „> — %d62. Число, заключенное в угловые скобки, называется Значением Приоритета и отображает одновременно Субъект (Facility) и Важность (Severity) сообщения, как это описано ниже. Значение Приоритета состоит из одного, двух или трех символов десятичных цифр (DIGIT, в терминах ABNF) с кодами от %d48 (для „0“) до %d57 (для „9“).

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

Код Категория субъекта
0 сообщения ядра
1 сообщения пользовательского уровня
2 почтовая система
3 системные службы (daemons)
4 сообщения безопасности/авторизации (см. [замечание 1])
5 внутренние сообщения, сгенерированные syslogd
6 подсистема печати
7 подсистема новостных групп (телеконференций, NNTP)
8 подсистема UUCP
9 служба времени (см. [замечание 2])
10 сообщения безопасности/авторизации (см. [замечание 1])
11 служба FTP
12 подсистема NTP
13 сообщения аудита (см. [замечание 1])
14 аварийные сообщения (см. [замечание 1])
15 служба времени (см. [замечание 2])
16 локального происхождения 0 (local0)
17 локального происхождения 1 (local1)
18 локального происхождения 2 (local2)
19 локального происхождения 3 (local3)
20 локального происхождения 4 (local4)
21 локального происхождения 5 (local5)
22 локального происхождения 6 (local6)
23 локального происхождения 7 (local7)
Таблица 1. Коды категорий субъектов сообщений Syslog

Замечания:

  1. 1,0 1,1 1,2 1,3 Как показывает практика, различные операционные системы использовали Субъекты с кодами 4, 10, 13 и 14 для сообщений безопасности/авторизации, аудита и аварийных сообщений, которые кажутся подобными.
  2. 2,0 2,1 Как показывает практика, различные операционные системы использовали Субъекты с кодами 9 и 15 для сообщений службы времени (cron/at).


Каждое Значение Приоритета отражает также и уровень Важности сообщения. В нижеследующей таблице перечислены десятичные числовые значения уровней Важности.

Код Уровни важности
0 Авария (Emergency): система неработоспособна
1 Тревога (Alert): система требует немедленного вмешательства
2 Критический (Critical): состояние системы критическое
3 Ошибка (Error): сообщения о возникших ошибках
4 Предупреждение (Warning): предупреждения о возможных проблемах
5 Замечание (Notice): сообщения о нормальных, но важных событиях
6 Информационный (Informational): информационные сообщения
7 Отладка (Debug): отладочные сообщения
Таблица 2. Уровни важности сообщений Syslog

Вычисление значения приоритета производится умножением числового кода Субъекта на 8 и последующим прибавлением числового уровня Важности. Например, сообщения ядра (Субъект=0) с уровнем важности «Авария» (Важность=0) получат приоритет 0. А сообщения «локального происхождения 4» (Субъект=20) с уровнем важности «Замечание» (Важность=5) получат приоритет 165. Данное числовое значение будет помещено в область PRI соответствующих сообщений Syslog внутри угловых скобок в виде подстроки „<0> в первом случае и „<165> во втором. Символ „0 может следовать сразу за символом „< только в одном случае — если приоритет равен 0. Во всех остальных случаях лидирующие „0 НЕ ДОЛЖНЫ использоваться.

HEADER (заголовок)

В области HEADER располагаются отметка времени и имя узла или IP-адрес устройства. Область HEADER ДОЛЖНА быть заполнена только отображаемыми (печатными) символами. При ее заполнении, так же как и для области PRI, ДОЛЖЕН использоваться набор символов 7-битной ASCII-кодировки. Из этого набора символов допустимыми являются только символы VCHAR (в терминах ABNF) с кодами %d33-126 и пробел (SP, %d32).

Область HEADER содержит два поля, называемых TIMESTAMP (отметка-времени) и HOSTNAME (имя-узла). Поле TIMESTAMP начинается сразу за символом „>“, замыкающим область PRI; единственный пробел ДОЛЖЕН отделять поле TIMESTAMP от поля HOSTNAME. Поле HOSTNAME будет содержать имя узла, которое устройство может узнать из своих собственных настроек. Если у узла нет имени, то это поле будет содержать собственный IP-адрес устройства. Если у устройства несколько IP-адресов, то оно, как обычно замечалось, использовало IP-адрес того интерфейса, с которого передавало сообщение. Также было отмечено и иное поведение. В этом случае устройство могло быть сконфигурировано так, чтобы заносить во все сообщения единственный исходный IP-адрес независимо от интерфейса, с которого отправляется сообщение. Это обеспечивает единственное непротиворечивое значение поля HOSTNAME для всех сообщений, отправляемых данным устройством.

Поле TIMESTAMP содержит локальное время в форматеMmm dd hh:mm:ss(без ограничивающих кавычек), где

  • Mmm — сокращенное название месяца на английском языке, где первая буква — заглавная, а две остальные — прописные. Допустимы только следующие значения:
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
  • dd — номер дня в месяце. Если он меньше 10, то ДОЛЖЕН быть представлен в форме, где первым символом следует пробел, а затем — цифра. Например, 7 августа будет представлено как подстрока Aug 7“, где два пробела отделяют цифру от аббревиатуры месяца
  • hh:mm:ss — локальное время. Часы hh указываются в 24-часовом формате. Допустимы значения от 00 до 23 включительно. Допустимые значения для минут mm и секунд ss лежат в диапазоне от 00 до 59 включительно.

Непосредственно за полем TIMESTAMP ДОЛЖЕН следовать единственный пробел, отделяющий его от поля HOSTNAME.

Поле HOSTNAME содержит либо имя узла, либо IPv4- или IPv6-адрес источника сообщения. Имя узла предпочтительнее. Если используется имя узла, то в поле HOSTNAME ДОЛЖНО находиться имя узла для устройства, как оно определено в STD 13[4]. Надо отметить, что оно НЕ ДОЛЖНО содержать встроенных пробелов. Имя домена НЕ ДОЛЖНО включаться в поле HOSTNAME. Если используется IPv4-адрес, то он ДОЛЖЕН быть записан в десятично-точечной нотации, как это отражено в STD 13[5]. Если используется IPv6-адрес, то он МОЖЕТ быть записан в любой допустимой форме, определенной в RFC 2373[6]. Непосредственно за полем HOSTNAME ДОЛЖЕН следовать единственный пробел, отделяющий его от области MSG.

MSG (сообщение)

Область MSG заполняет остаток пакета Syslog. Обычно она содержит некоторую дополнительную информацию о процессе, который сгенерировал сообщение, и сам текст сообщения. В этой области нет никакого конечного разделителя. Область MSG ДОЛЖНА содержать только отображаемые (печатные) символы. Традиционно и наиболее часто при ее заполнении, так же как и для областей PRI и HEADER, используется набор символов 7-битной ASCII-кодировки. Из этого набора символов допустимыми являются только символы VCHAR (в терминах ABNF) с кодами %d33-126 и пробел (SP, %d32). С другой стороны, никакая индикация относительно набора символов, используемого в пределах MSG, не требуется и не ожидается. Другие кодовые наборы МОГУТ использоваться, пока символы, помещаемые в область MSG, являются исключительно отображаемыми (печатными) символами и располагаются в интервале кодов, подобно описанным выше. Выбор набора символов, используемого в области MSG, РЕКОМЕНДУЕТСЯ делать в расчете на предполагаемого получателя. Сообщение, содержащее текст в кодовом наборе, символы которого не могут быть отображены у получателя или поняты им, не несет ни какой информации, имеющей значение для оператора или администратора, просматривающего такое сообщение.

Область MSG содержит два поля, называемых TAG (признак) и CONTENT (содержимое). В поле TAG помещается имя программы или процесса, сгенерировавшего сообщение. Поле CONTENT содержит детализированное сообщение. Традиционно, это текст в свободной форме, передающий некоторую детальную информацию о произошедшем событии. Поле TAG представляет собой строку алфавитно-цифровых символов (в терминах ABNF), длина которой НЕ ДОЛЖНА превышать 32 символа. Любой не алфавитно-цифровой символ завершает поле TAG и сигнализирует о начале поля CONTENT. Наиболее часто в качестве первого символа поля CONTENT, отмечающего завершение поля TAG, используются левая квадратная скобка („[“), двоеточие („:“) и пробел (SP, %d32). Детально это обсуждается в Разделе 5.3.

Изначальные пакеты Syslog, создаваемые устройством

Никаких требований к содержимому пакета Syslog, когда он первоначально формируется устройством, не предъявляется. Здесь следует еще раз повторить, что полезная нагрузка любого пакета IP, предназначенного порту UDP 514, ДОЛЖНА полагаться допустимым сообщением Syslog. Однако, РЕКОМЕНДУЕТСЯ, чтобы пакет Syslog содержал все части, описанные в Разделе 4.1 — PRI, HEADER и MSG — поскольку это улучшает удобочитаемость для получателя и избавляет ретранслятор от необходимости изменять сообщение.

Разработчикам, которые действительно хотят создавать сообщения Syslog в РЕКОМЕНДУЕМОМ формате, предлагается руководствоваться следующим:

  • Если в первоначальном сообщении формируется поле TIMESTAMP в области HEADER, то для его заполнения РЕКОМЕНДУЕТСЯ использовать локальное время устройства в его часовом поясе.
  • Если в первоначальном сообщении формируется поле HOSTNAME, то для его заполнения используется имя узла, присвоенное данному устройству. Если имя узла неизвестно, то используется собственный IP-адрес устройства.
  • Если в первоначальном сообщении формируется поле TAG, то для его заполнения используется имя программы или процесса, сгенерировавших сообщение.

Ретранслированные пакеты Syslog

Когда ретранслятор получает пакет Syslog, то он проверяет содержимое области PRI на допустимость. Если первый символ не является знаком «меньше», то ретранслятор ДОЛЖЕН предположить, что пакет не содержит допустимый PRI. Если 3-ий, 4-ый или 5-ый символ не является символом правой угловой скобки (знак «больше»), то ретранслятор снова ДОЛЖЕН предположить, что PRI не был включен в исходное сообщение. Если ретранслятор действительно находит допустимой область PRI, то тогда он должен проверить на допустимость поле TIMESTAMP в области HEADER. Из этих правил следует вывод трех общих случаев полученных сообщений. Таблица 3 дает общие характеристики этих случаев и перечисляет соответствующие разделы этого документа, в которых описывается обработка каждого случая.

Случай Раздел
Допустимые PRI и TIMESTAMP 4.3.1
Допустимый PRI, но недопустимый или отсутствует TIMESTAMP 4.3.2
PRI отсутствует или не идентифицируется 4.3.3
Таблица 3. Случаи полученных сообщений Syslog

Допустимые PRI (приоритет) и TIMESTAMP (отметка-времени)

Если ретранслятор действительно находит PRI и TIMESTAMP допустимыми, то он проверяет свою внутреннюю конфигурацию. Ретрансляторы ДОЛЖНЫ быть настроены таким образом, чтобы осуществлять пересылку пакетов Syslog на основе их Значения Приоритета. Если ретранслятор находит, что, согласно конфигурации, полученный пакет необходимо переслать, то он ДОЛЖЕН сделать это, не производя никаких изменений в пакете. Чтобы подчеркнуть мысль еще раз, повторим, что именно по этой причине РЕКОМЕНДУЕТСЯ, чтобы изначально создаваемое сообщение Syslog придерживалось формата, описанного в Разделе 4.1.

Здесь надо отметить, что получателю сообщения не требуется проверять правильность значения времени в поле TIMESTAMP. Надо исходить из предположения, что устройство, у которого не были правильно настроены часы, все же должно иметь возможность отправлять допустимые сообщения Syslog. Также ретранслятору не требуется проверять, что значение в поле HOSTNAME соответствует имени узла или IP-адресу устройства, отправляющего сообщение. Описание причины такого поведения может быть найдено в Разделе 4.1.2.

Допустимый PRI (приоритет), но недопустимый или отсутствует TIMESTAMP (отметка-времени)

Если ретранслятор не находит допустимое поле TIMESTAMP в полученном пакете Syslog, то он ДОЛЖЕН добавить поле TIMESTAMP и пробел сразу после заключительной угловой скобки области PRI. Также РЕКОМЕНДУЕТСЯ дополнительно добавить поле HOSTNAME и пробел сразу после поля TIMESTAMP. Эти поля описаны здесь и детализированы в Разделе 4.1.2. Остаток от полученного пакета ДОЛЖЕН быть обработан и добавлен, как поле CONTENT области MSG. Так как у ретранслятора нет никакой возможности определить процесс, породивший сообщение на устройстве, которое выступало источником сообщения, значение поля TAG не может быть определено и не будет включено.

В поле TIMESTAMP будет помещено текущее локальное время ретранслятора.

В поле HOSTNAME помещается имя узла для устройства, отправившего сообщение, если только его может определить ретранслятор. Если имя узла не может быть определено, то будет использоваться IP-адрес устройства.

Если ретранслятор добавляет поле TIMESTAMP или поля TIMESTAMP и HOSTNAME после области PRI, то он ДОЛЖЕН проверить, что полная длина пакета все еще не превышает 1024 байта. Если длина расширенного пакета будет больше 1024 байт, то ретранслятор ДОЛЖЕН усечь пакет до 1024 байт. Это может вызвать потерю важной информации в конце исходного пакета. Именно по этой причине РЕКОМЕНДУЕТСЯ, чтобы области PRI и HEADER первоначально сгенерированных пакетов Syslog содержали значения и поля, задокументированные в Разделе 4.1.

PRI (приоритет) отсутствует или не идентифицируется

Если ретранслятор получает сообщение Syslog с отсутствующей или неидентифицируемой областью PRI, то он ДОЛЖЕН добавить область PRI, использовав Значение Приоритета 13, а также поле TIMESTAMP так, как это описано в Разделе 4.3.2. Ретранслятор также ДОЛЖЕН добавить и поле HOSTNAME так, как это описано в Разделе 4.3.2. Все содержимое полученного пакета будет обработано и добавлено как поле CONTENT области MSG в пересылаемом пакете.

Примером неидентифицируемой области PRI могла бы быть подстрока „<00>(без ограничивающих кавычек). Может случиться так, что эта подстрока и есть первые 4 символа сообщения. Продолжая этот пример, если ретранслятор действительно получит сообщение Syslog, где первые четыре символа — „<00>“, то он будет вынужден свериться со своими настройками. Если конфигурация предписывает пересылать сообщения Syslog со Значением Приоритета 13 другому ретранслятору или коллектору, то ретранслятор ДОЛЖЕН изменить содержимое пакета так, как описано выше. Специфические особенности выполнения этого действия, включая РЕКОМЕНДУЕМУЮ вставку поля HOSTNAME, даны ниже.

Оригинальное полученное сообщение

<00>...

Пересылаемое (ретранслируемое) сообщение

<13>TIMESTAMP HOSTNAME <00>...

Если ретранслятор добавляет поле TIMESTAMP или поля TIMESTAMP и HOSTNAME после области PRI, то он ДОЛЖЕН проверить, что полная длина пакета все еще не превышает 1024 байта. Если длина расширенного пакета будет больше 1024 байт, то ретранслятор ДОЛЖЕН усечь пакет до 1024 байт. Это может вызвать потерю важной информации в конце исходного пакета. Именно по этой причине РЕКОМЕНДУЕТСЯ, чтобы области PRI и HEADER первоначально сгенерированных пакетов Syslog содержали значения и поля, задокументированные в Разделе 4.1.

Соглашения

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

Даты и время

Известно, что некоторым администраторам сети нравится архивировать сохраненные сообщения Syslog за большие промежутки времени. Также отмечается, что некоторые исходные сообщения Syslog содержат более точную отметку времени, в которой 2- или 4-символьное значение года следует сразу за пробелом, завершающим поле TIMESTAMP. Это противоречит исходному определению порядка и формата полей. Если разработчики хотят, чтобы передаваемое сообщение содержало более определенную дату и отметку времени, то эти данные должны помещаться в поле CONTENT. Если разработчики хотят включать более точную информацию о дате и времени, то желательно использовать форматы даты и времени ISO 8601[7].

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

Доменные имена и адреса

Чтобы с уверенностью идентифицировать устройство, которое сгенерировало сообщение, считается хорошей практикой включать в поле CONTENT полностью определенное доменное имя (FQDN) устройства и его IP-адрес. Традиционно, однако, в поле HOSTNAME помещается только имя узла данного устройства.

Информация о порождающих процессах

Также считается хорошей практикой включать в сообщение некоторую информацию о процессе, который вызвал генерацию сообщения (если такое понятие существует для данного устройства). Обычно, это имя процесса и идентификатор процесса (часто известный как pid) для многозадачных операционных систем. Имя процесса обычно отображается в поле TAG. Достаточно часто дополнительная информация включается в начало поля CONTENT. Формат „TAG[pid]:(без ограничивающих кавычек) довольно широко распространен. В этом случае левая квадратная скобка используется, чтобы завершить поле TAG и является поэтому первым символом поля CONTENT. Если идентификатор процесса является несущественным, он может быть пропущен. В таком случае двоеточие и пробел обычно следуют за полем TAG, что отображается как „TAG: (без ограничивающих кавычек). В этом случае первым символом поля CONTENT является двоеточие.

Примеры

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

Пример 1.

<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick
  on /dev/pts/8

Этот пример содержит сообщение об ошибке аутентификации при попытке получить дополнительные полномочия. Он также демонстрирует имя выполненной команды и пользователя, сделавшего эту попытку. Данное сообщение было получено как исходное сообщение от устройства с именемmymachine“. Ретранслятор, получивший это сообщение, не произвел бы никаких изменений в нем перед пересылкой дальше, поскольку сообщение содержит должным образом отформатированную область PRI и поле TIMESTAMP в области HEADER. Значение поля TAG в этом примере — имя процесса „su“. Двоеточие завершает поле TAG и является первым символом поля CONTENT. В данном случае идентификатор процесса (pid) относится к временному процессу, который запустился, отработал и завершился, и любой просматривающий это сообщение Syslog не получит полезной информации от знания pid. Поэтому pid не был включен в сообщение и первые два символа поля CONTENT — двоеточие и пробел.

Пример 2.

Use the BFG!

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

В данном примере, очевидно, представлено исходное сообщение от устройства. Ретранслятор ДОЛЖЕН произвести изменения в сообщении так, как это описано в Разделе 4.3, прежде, чем переслать его дальше. Пересылаемое в результате сообщение показано ниже.

<13>Feb  5 17:32:18 10.0.0.99 Use the BFG!

В пересылаемом сообщении все содержимое исходного сообщения было обработано как поле CONTENT области MSG. Во-первых, была добавлена допустимая область PRI, используя по умолчанию число 13 в качестве Значения Приоритета. Затем были добавлены поля TIMESTAMP и HOSTNAME в области HEADER. Поэтому следующие, встретившиеся на маршруте, ретрансляторы не будут изменять это сообщение. Нужно отметить, что в этом примере день месяца — меньше 10. Так как единственной цифре в дате (5 в этом случае) предшествует пробел в соответствии с форматом поля TIMESTAMP, то перед цифрой дня месяца присутствуют два пробела после аббревиатуры месяца. Кроме того, ретранслятор, кажется, не сумел определить имя узла устройства, отправившего исходное сообщение, и поэтому вставил IPv4-адрес устройства в поле HOSTNAME.

Пример 3.

<165>Aug 24 05:34:00 CST 1987 mymachine myproc[10]: %% It's time
  to make the do-nuts. %% Ingredients: Mix=OK, Jelly=OK # Devices:
  Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport: Conveyer1=OK,
  Conveyer2=OK # %%

У этого сообщения действительно есть допустимое поле PRI, Значение Приоритета в котором указывает, что прибыло оно от Субъекта локального происхождения (local4) со степенью Важности «Замечание». У сообщения в области HEADER есть надлежащее поле TIMESTAMP. Ретранслятор не будет изменять это сообщение прежде, чем переслать его дальше. Однако, поля HOSTNAME и TAG не являются непротиворечивыми в соответствии с определениями, данными в Разделе 4. В качестве поля HOSTNAME будет принято значение „CST“, а началом области MSG будет „1987“.

Нужно отметить, что информация, содержащаяся в поле CONTЕNT этого примера, не является телеметрическими данными, но представляет собой либо информацию диспетчерского управления, либо собранные данные. Из-за проблем безопасности, перечисленных в Разделе 6 этого документа, информация такой природы не должна, вероятно, передаваться посредством этого протокола.

Пример 4.

<0>1990 Oct 22 10:52:01 TZ-6 scapegoat.dmz.example.org 10.1.2.3
  sched[0]: That's All Folks!

В этом примере присутствует много посторонней информации. Человек или достаточно адаптируемый автоматизированный синтаксический анализатор был бы в состоянии определить дату и время, так же как и полностью определенное доменное имя (FQDN)[4] и IP-адрес. Информация о природе события, однако, ограничена. Из-за обозначенной серьезности события, процесс, возможно, не был в состоянии собрать или отправить что-либо более информативное. Возможно, вообще было большой удачей сгенерировать и отправить это сообщение.

Очевидно, что в этом примере приведено исходное сообщение от устройства. Так как первое поле в области HEADER не соответствует формату поля TIMESTAMP, определенному в Разделе 4.1.2, то сообщение ДОЛЖНО быть изменено ретранслятором. Ретранслятор ДОЛЖЕН добавить поля TIMESTAMP и HOSTNAME соответствующим образом и обработать весь полученный пакет после области PRI исходного пакета как поле CONTENT нового пакета. В поле HOSTNAME будет помещено только имя узла без доменного имени, как его сумел определить ретранслятор. Значение поля TAG не будет добавлено к переданному пакету. В то же время, включение доменного имени и адреса IPv4 в исходное сообщение — благородное усилие и не противоречит использованию поля, как это описано в Разделе 4.1.2.

<0>Oct 22 10:52:12 scapegoat 1990 Oct 22 10:52:01 TZ-6
  scapegoat.dmz.example.org 10.1.2.3 sched[0]: That's All Folks!

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

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

Известно, что различные виды насекомых используют запахи для привлечения партнёров противоположного пола. Так мужские и женские особи одного из видов моли находят друг друга по специфическому запаху. Однако, было обнаружено, что пауки-боладоры[перевод 6] могут подражать запаху женских особей моли данной разновидности. Этот запах привлекает мужские особи моли, которые следуют за ним, ожидая обнаружить партнёршу. Но, когда они находят источник запаха, то их просто съедают[8]. Это — случай ложного сообщения, отсылаемого с недружелюбным намерением.

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

Параметры пакетов

Как было описано выше, длина сообщения НЕ ДОЛЖНА превышать 1024 байта. Зафиксированы атаки на протокол, когда получателю отправлялись сообщения Syslog длиной больше 1024 байт. В некоторых старых реализациях Syslog получение пакетов, длина сообщения в которых превысила 1024 байта, вызывало проблемы. Получатели сообщения Syslog не должны функционировать неправильно после получения пакетов с сообщениями длиной больше 1024 байт. Также было отмечено различное поведение получателей, которые действительно получают сообщения длиной больше 1024 байт. В некоторых реализациях регистрируется все содержимое сообщений, в то время как в других — только часть сообщения. В третьих реализациях отбрасывается все сообщение целиком. Устройства НЕ ДОЛЖНЫ ретранслировать сообщения, длина которых превышает 1024 байта.

Точно так же получатель должен жестко проверять правильность текста сообщений. Коллекторы Syslog не должны неправильно функционировать, если в полученном сообщении отсутствуют угловые скобки (знаки „< и „>“) вокруг допустимого Значения Приоритета. Они ДОЛЖНЫ обработать это сообщение как бесформатное поле CONTENT так, как это было описано в Разделе 4.3.3, перед тем как переслать его следующему коллектору.

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

Подлинность сообщений

Механизм доставки Syslog не устанавливает строгого соответствия сообщения с отправителем сообщения. Получатель пакета не в состоянии установить было ли сообщение действительно отправлено отправителем, о котором говорится в сообщении, или пакет был отправлен другим устройством. Здесь надо отметить, что получатель сообщения не должен проверять соответствует ли поле HOSTNAME в области HEADER IP-адресу, содержащемуся в поле Source Address пакета IP.

Проблемы проверки подлинности

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

Нужно также отметить, что в некоторых случаях для заполнения поля HOSTNAME в области HEADER может использоваться локальное значение и оно может быть несколько эфемерным. Если устройство получило IP-адрес из пула DHCP, то любая ассоциация между идентификатором и фактическим источником не всегда будет верной. Включение полностью определенного доменного имени в CONTENT может дать администраторам лучшую возможность идентификации источника каждого сообщения, так как его всегда можно связать с IP-адресом или с уникальной машиной.

Подделка сообщений

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

Последовательность доставки

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

От единственного источника единственному получателю

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

От множества источников единственному получателю

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

От множества источников множеству получателей

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

Повторное воспроизведение

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

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

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

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

Помимо потери, сообщения Syslog могут быть повреждены в процессе доставки или их может злонамеренно изменить злоумышленник. На случай повреждения пакета, содержащего сообщение Syslog, существуют различные механизмы, встроенные в транспортные уровни, как в IP[9], так и в UDP, которые могут обнаружить повреждение. Поврежденный пакет IP может отбросить промежуточный маршрутизатор[10]. Во время приёма повреждение пакета UDP может быть обнаружено модулем, обслуживающим протокол UDP, который также может тихо отбросить его. В любом случае, исходное содержимое сообщения не будет доставлено коллектору. Дополнительно, если злоумышленник расположится между отправителем и коллектором сообщений Syslog, то он может перехватить и изменить сообщения, чтобы скрыть несанкционированные действия.

Несанкционированный просмотр сообщений

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

Приоритеты и дифференциация сообщений

Хотя процессы, создающие сообщения, могут указать важность событий с помощью поля Значение Приоритета в сообщении, нет никакой прямой зависимости между этим значением и важностью доставки пакета по сети. Например, рассмотрим приложение, которое генерирует два сообщения о событиях. Первое является обычным сообщением о состоянии, а второе может быть важным сообщением, обозначающим проблему с процессом. У этого второго сообщения будет, соответственно, более высокое значение Важности, связанное с событием. Если операторы сконфигурировали устройство так, что оба этих сообщения должны быть отправлены коллектору Syslog, то они будут переданы по UDP поочередно. В нормальных условиях между ними не было бы сделано никаких различий и они были бы переданы в порядке возникновения.

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

В зависимости от конкретного случая, операторы устройства могут найти некоторые способы, чтобы связать разные уровни важности с качеством обслуживания. Например, для сообщений Syslog с особыми Значениями Приоритета операторы могут назначить определенные значения, которые будут использоваться в поле Precedence пакетов IPv4[9], в октете Traffic Class пакетов IPv6[11] или в поле Differentiated Services[12]. Тогда, в вышеупомянутом примере, у операторов появляется возможность назначить сообщению о состоянии обычную доставку, а сообщению, указывающему на проблему, доставку высокой надежности и низкую задержку при прохождении по сети. Это позволило бы выполнять преимущественную доставку важных сообщений в соответствии с их приоритетами. Но даже с такой расстановкой по приоритетам на транзитных участках[перевод 7] механизм организации очередей все же может привести к блокировке линий устройства передачи или к переполнению буферов приемного устройства, если есть много почти одновременно отправляемых или получаемых сообщений. Такое поведение не является уникальным для Syslog, поскольку свойственно для всех операций, осуществляющих передачу сообщений последовательно.

И это вызывает проблемы безопасности. Блокировка линии во время передачи важного сообщения может привести к перестановке его в очереди вслед за менее важными сообщениями. Если же очередь очищается, то это, соответственно, может только увеличить задержку передачи важного сообщения. С другой стороны, если очередь не очищать, то важные сообщения могут не быть переданными. На стороне же получателя сообщений Syslog, если он страдает от переполнения буферов из-за большого количества сообщений, получаемых почти одновременно, важные сообщения могут быть отброшены без разбора, наряду с другими сообщениями. Поскольку это проблемы сетевых устройств и сетевых ресурсов, то на безопасности протокола сказывается невозможность установки приоритета более важных сообщений относительно менее важных.

Ошибки конфигурирования

Так как не распространяется никакой управляющей информации о каких-либо сообщениях или конфигурациях, администратор сети обязан полностью гарантировать, что сообщения фактически направляются предполагаемому получателю. Однако, отмечались случаи, когда устройства были непреднамеренно сконфигурированы так, чтобы отправлять сообщения Syslog неправильному получателю. Во многих случаях такой получатель может не быть сконфигурирован для получения сообщений Syslog и, вероятно, отбросит их. Известен случай, когда приход неожидаемых сообщений Syslog вызывал проблемы у получателя[13][перевод 8]. Если сообщения не попадают к предполагаемому получателя, то они не могут быть им просмотрены или обработаны.

Зацикливание пересылок

Как показано на рисунке 1, машины могут быть настроены так, что сообщения Syslog пройдут через один или несколько промежуточных ретрансляторов прежде, чем достигнут коллектора. Известны случаи неправильной конфигурации соседних ретрансляторов, когда им предписывалось пересылать сообщения с определенными Значениями Приоритета друг другу. Когда любая из этих машин получала или генерировала сообщение данного типа, то пересылала его соседней. Та, в свою очередь, отправляла это сообщение обратно. Этот бесконечный цикл действительно вызвал перегрузку участка сети и отказ от обслуживания на этих двух устройствах. Администраторы сети должны заботиться о том, чтобы конфигурация не позволяла образовываться таким «мертвым петлям».

Оценка нагрузки

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

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

Соглашения с IANA

Для обслуживания протокола Syslog выделен порт UDP 514. В дальнейшем IANA будет сохранять присвоение данного порта исключительно для этого протокола.

Протокол Syslog предусматривает определение именованных атрибутов, чтобы обозначить Важность (Severity) каждого сообщения и указать Субъект (Facility), сгенерировавший его, как описано в Разделе 4. В качестве идентификаторов в пространстве имен для этих атрибутов определены числа. Протокол не задает определенные назначения из пространства имен для этих чисел; разработчику приложений или систем разрешают самому определить атрибут, его семантику и связанные с ним числа. Этим пространством имен не будут управлять, чтобы предотвратить коллизии, поскольку системы, как ожидается, будут использовать те же самые атрибуты, семантику и связанные с ними числа для описания событий, которые считаются подобными даже среди разнородных устройств.

Заключение и прочие соображения

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

В прошлом были попытки стандартизации формата сообщений Syslog. Самая известная попытка достигла высшей точки внесением BOF[перевод 10] на встрече Fortieth Internet Engineering Task Force в 1997 году. Тогда рассматривался BOF, посвященный Universal Logging Protocol (ulp), и протоколы этой встречи можно найти на веб-сайте IETF[14]. Это предложение породило много хороших мыслей, заинтересовавших разработчиков, что можно увидеть из некоторых примечаний и документов, появившихся в результате этого обсуждения.

Во время написания данного документа усилия направлены на то, чтобы позволить приложениям, которые традиционно задумывались как чисто текстовые, использовать наборы интернациональных символов на стадии реализации. Поля HOSTNAME и TIMESTAMP, описанные выше, являются типичными объектами для такой работы. Кроме того, всё поле CONTENT традиционно содержит символы в кодовом наборе, известном как US-ASCII. Надеемся, что сторонники усилий по интернационализации найдут подходящий способ позволить использование наборов интернациональных символов в сообщениях Syslog, не подрывая протокол. Нужно также надеяться, что разработчики учтут будущее принятие дополнительных кодовых наборов и смогут соответственно скорректировать планы. Снова нужно предостеречь, что простота существующей системы имела огромное значение к ее принятию. Что-либо, что уменьшит эту простоту, может уменьшить и это значение.

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

Следующие люди внесли замечания по содержанию этого документа во время его написания:

  • Jon Knight
  • Magosanyi Arpad
  • Balazs Scheidler
  • Jon Callas
  • Eliot Lear
  • Petter Reinholdtsen
  • Darren Reed
  • Alfonso De Gregorio
  • Eric Allman
  • Andrew Ross
  • George Maslyar
  • Albert Mietus
  • Russ Allbery
  • Titus D. Winters
  • Edwin P. Boon
  • Jeroen M. Mostert

Eric Allman — фактический изобретатель и автор протокола и демона Syslog. Автор этой записки и общество в целом хотели бы выразить высокую оценку его работы.

Большое количество дополнительной информации об этой фактической стандартной функции операционной системы обычно можно найти в файле syslog.conf, а так же в справке для syslog.conf, syslog, syslogd и logger многих Unix и Unix-подобных устройств.

Список литературы

  1. Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.
  2. Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.
  3. USA Standard Code for Information Interchange, USASI X3.4-1968
  4. 4,0 4,1 Mockapetris, P., «Domain Names - Concepts and Facilities», STD 13, RFC 1034, November 1987.
  5. Mockapetris, P., «Domain names - Implementation and Specification», STD 13, RFC 1035, November 1987.
  6. Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 2373, July 1998.
  7. Data elements and interchange formats - Information exchange - Representation of dates and times, International Organization for Standardization, Reference number ISO 8601 : 1988 (E), 1988
  8. Stowe, M., et al, «Chemical Mimicry: Bolas Spiders Emit Components of Moth Prey Species Sex Pheromones», Science, 1987
  9. 9,0 9,1 Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.
  10. Baker, F., «Requirements for IP Version 4 Routers», RFC 1812, June 1995.
  11. Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.
  12. Nichols, K., Blake, S., Baker, F. and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.
  13. Cisco Systems Product Security Incident Response Team (PSIRT), «Field Notice: Cisco IOS(r) Syslog Crash», January 11, 1999 http://www.cisco.com/warp/public/707/advisory.html
  14. Walker, D., IETF Secretariat, «Proceedings of the Fortieth Internet Engineering Task Force, Washington, DC, USA, December 8-12, 1997» http://www.ietf.org/proceedings/97dec/index.html

Полное заявление об авторских правах

Copyright (C) 2001. Все права принадлежат Обществу Интернета. Все права защищены.

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

Ограниченные полномочия, предоставленные выше, не ограничены сроком действия и не будут отменяться Обществом Интернета и/или его преемниками.

Настоящий документ и информация, содержащаяся в нём, предоставляются по принципу «КАК ЕСТЬ». ОБЩЕСТВО ИНТЕРНЕТА И ИНЖЕНЕРНЫЙ СОВЕТ ИНТЕРНЕТ ОТКАЗЫВАЮТСЯ ОТ ЛЮБЫХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ ЛЮБЫМИ ГАРАНТИЯМИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ БУДЕТ НАРУШАТЬ ПРАВА ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.

Благодарность

Финансирование функций RFC Editor в настоящее время обеспечивается Обществом Интернета.

Примечания переводчика

  1. Информацию о текущем статусе этого документа, о любых его изменениях и о том, как обеспечить обратную связь, можно получить на странице http://www.rfc-editor.org/info/rfc3164.
  2. В оригинале — «self-aware organic unit»
  3. Здесь под понятием «пакета», по всей дальнейшей логике, авторами документа подразумевается само сообщение Syslog, состоящее из перечисленных частей, которое в дальнейшем периодически называется «пакетом Syslog».
  4. В 8-битном байте используются младшие 7 бит, старший бит всегда равен 0.
  5. От англ. Augmented Backus-Naur Form
  6. лат. Mastophora cornigera
  7. В оригинале — «hop-by-hop»
  8. В настоящее время документ перемещён по следующему адресу http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-19990111-ios-syslog
  9. В оригинале — «be liberal in what you accept».
  10. От англ. Birds of a Featherтак в IETF называют предложения о возможном направлении усилий предварительной рабочей группы IETF