RFC 5426

RFC 5426 (Передача сообщений Syslog через UDP) автор [[A. Okmianski|A. Okmianski]], пер. StLeutnant

Язык оригинала: английский. Название в оригинале: RFC 5426 (Transmission of Syslog Messages over UDP). — Опубл.: март 2009 года (перевод). Источник: RFC 5426

Network Working Group Request for Comments: 5426 Category: Standart Tracks

A. Okmianski Cisco Systems, Inc. March 2009

Передача сообщений Syslog через UDP

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

Настоящий документ описывает спецификацию протокола из семейства Стандартов Интернет для сообщества Интернет, требует обсуждения и внесения предложений для улучшения. Пожалуйста, обратитесь к действующей редакции «Internet Official Protocol Standards» (STD 1), чтобы отследить состояние и статус этого протокола. Распространение данного документа не ограничено.

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

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

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

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

Аннотация

Представленный документ описывает транспортный механизм для передачи сообщений системного журнала (далее, Syslog) через UDP/IPv4 или UDP/IPv6. Mногоуровневая архитектура протокола Syslog позволяет использовать множество разных транспортных механизмов. Однако, для обеспечения совместимости, от реализаций протокола Syslog требуется поддержка и данного вида транспорта.

Введение

Информационный RFC 3164 изложил сложившуюся к тому времени спецификацию протокола Syslog, фактически использующуюся в существовавших реализациях. В нём описывался не только формат сообщений Syslog, но и транспорт UDP. Впоследствии стандарт протокола Syslog был переопределен в RFC 5424.

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

Транспорт, обсуждаемый в данном документе, может использоваться для передачи сообщений Syslog как по протоколу IPv4, так и IPv6.

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

Соглашения, принятые в этом документе

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «МОЖЕТ», «РЕКОМЕНДУЕТСЯ» и «НЕ РЕКОМЕНДУЕТСЯ» в этом документе должны интерпретироваться в соответствии с RFC 2119.

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

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

Каждая датаграмма UDP ДОЛЖНА содержать ровно одно сообщение Syslog, которое МОЖЕТ быть полным или усечённым. Сообщение ДОЛЖНО быть представлено в формате, предложенном в RFC 5424, и усечено в соответствии с правилами, изложенными там же. Посторонние данные НЕ ДОЛЖНЫ присутствовать в полезной нагрузке датаграммы.

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

Этот транспортный механизм поддерживает передачу сообщений Syslog до максимального размера, вычисляемого как разница между 65535 и длиной заголовка UDP. Данное ограничение вытекает из максимально возможного для UDP размера пакета в 65535 октетов, декларированного в RFC 768. Для IPv4 максимальный размер полезной нагрузки в октетах вычисляется вычитанием из 65535 длины заголовка UDP и длины заголовка IP, поскольку в 16-битном поле длины в заголовке пакета IPv4 содержится его полная длина, включая заголовок.

Получатели сообщений Syslog, использующие IPv4, ДОЛЖНЫ быть способны получать датаграммы с сообщениями, размером вплоть до 480 октетов. Получатели сообщений Syslog, использующие IPv6, ДОЛЖНЫ быть способны получать датаграммы с сообщениями, размером вплоть до 1180 октетов. Всем получателям сообщений Syslog РЕКОМЕНДУЕТСЯ быть в состоянии получать датаграммы с сообщениями, размером вплоть до 2048 октетов. Способность получать более длинные сообщения приветствуется.

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

Отправителям сообщений Syslog РЕКОМЕНДУЕТСЯ ограничивать длину сообщений таким образом, чтобы размер датаграмм IP не превышал наименьший MTU, использующийся в сети. Это позволит избежать фрагментации датаграмм и возможных проблем, связанных с неправильным определением MTU.

Фрагментация может быть нежелательной, поскольку увеличивает риск потери всего сообщения из-за утраты всего одного фрагмента датаграммы. Syslog не имеет возможности подтверждения приема сообщений и, следовательно, не существует эффективных способов управления повторной передачей. Это делает невозможным использование для Syslog метода Packetization Layer Path MTU Discovery. Когда MTU сети не известен заранее, то безопасное решение заключается в ограничении длины сообщений до 480 октетов для IPv4 и 1180 октетов для IPv6.

Порты отправителя и получателя

Получатели сообщений Syslog ДОЛЖНЫ поддерживать принятие датаграмм на общеизвестный порт UDP 514, но МОГУТ иметь возможность настраиваться и на прослушивание других портов. Отправители сообщений Syslog ДОЛЖНЫ поддерживать отправку датаграмм на порт UDP 514, но МОГУТ иметь возможность настраиваться и на отправку на другие порты. Отправители сообщений Syslog МОГУТ использовать любой порт UDP в качестве источника для передачи сообщений.

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

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

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

Каждая UDP/IP-датаграмма, отправляемая на транспортном уровне, ДОЛЖНА полностью соответствовать структуре UDP RFC 768 и IPv4 RFC 791 или IPv6 RFC 2460, в зависимости от используемого протокола.

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

Отправители сообщений Syslog НЕ ДОЛЖНЫ отключать контрольные суммы UDP. Отправителям сообщений Syslog, использующим IPv4, РЕКОМЕНДУЕТСЯ использовать контрольные суммы UDP при отправке сообщений. Обратите внимание, что RFC 2460 делегирует использование контрольных сумм UDP при отправке датаграмм протоколу IPv6.

Получатели сообщений Syslog НЕ ДОЛЖНЫ отключать проверку контрольной суммы UDP. Получателям, использующим IPv4, РЕКОМЕНДУЕТСЯ проверять контрольные суммы UDP и признавать датаграммы с нулевой контрольной суммой. Обратите внимание, что RFC 2460 делегирует проверку контрольных сумм UDP при приеме датаграмм протоколу IPv6.

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

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

Потеря датаграмм

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

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

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

Управление нагрузкой

Поскольку Syslog может генерировать неограниченные объемы данных, то передача их по UDP, как правило, вызывает проблемы, так как в UDP отсутствуют механизмы управления нагрузкой. Механизмы управления нагрузкой, призванные реагировать на перегруженность каналов ограничением трафика и созданием справедливого распределения емкости канала между потоками, использующими одни и те же пути, имеют жизненно важное значение для стабильной работы Интернет. Именно поэтому для Syslog ТРЕБУЕТСЯ реализовывать транспорт TLS, который и РЕКОМЕНДУЕТСЯ для общего пользования.

Транспорт UDP для Sylog МОЖЕТ быть использован в качестве альтернативы транспорту TLS, только если оборудованием, управляющим сетями, для трафика UDP Syslog явно предусмотрен отдельный маршрут через инженерные механизмы управления трафиком, такие как ограничение скорости или резервирование емкости канала. Во всех других случаях ДОЛЖЕН быть использован транспорт TLS.

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

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

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

Использование данной спецификации в незащищенной сети НЕ РЕКОМЕНДУЕТСЯ. Несколько соображений, касающихся безопасности Syslog, обсуждаются в RFC 5424. В этом разделе рассматриваются вопросы безопасности, относящиеся именно к транспорту UDP для Syslog. Остроту некоторых проблем безопасности, поднятых в данном разделе, можно смягчить путем использования IPsec, как это определено в RFC 4301.

Аутентификация отправителя и подделка сообщений

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

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

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

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

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

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

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

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

Ненадежная доставка

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

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

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

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

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

Роль IANA

Рассматриваемый транспорт использует порт UDP 514 для Syslog, как это отмечено в реестре номеров портов IANA.

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

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