RFC3164 日本語訳
3164 The BSD Syslog Protocol. C. Lonvick. August 2001. (Format: TXT=72951 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Lonvick Request for Comments: 3164 Cisco Systems Category: Informational August 2001
Lonvickがコメントのために要求するワーキンググループC.をネットワークでつないでください: 3164年のシスコシステムズカテゴリ: 情報の2001年8月
The BSD syslog Protocol
BSD syslogプロトコル
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes the observed behavior of the syslog protocol. This protocol has been used for the transmission of event notification messages across networks for many years. While this protocol was originally developed on the University of California Berkeley Software Distribution (BSD) TCP/IP system implementations, its value to operations and management has led it to be ported to many other operating systems as well as being embedded into many other networked devices.
このドキュメントはsyslogプロトコルの観測された振舞いについて説明します。 このプロトコルはイベント通知メッセージの伝達に何年間もネットワークの向こう側に使用されています。 このプロトコルはカリフォルニア大学バークレイ校Software Distribution(BSD)TCP/IPシステムの実現のときに元々開発されましたが、操作と管理への値は、それが他の多くのオペレーティングシステムに移植されて、他の多くのネットワークでつながれたデバイスに埋め込まれているように導きました。
Table of Contents
目次
1. Introduction....................................................2 1.1 Events and Generated Messages..................................3 1.2 Operations of the Message Receivers............................5 2. Transport Layer Protocol........................................5 3. Definitions and Architecture....................................5 4. Packet Format and Contents......................................7 4.1 syslog Message Parts...........................................8 4.1.1 PRI Part.....................................................8 4.1.2 HEADER Part of a syslog Packet..............................10 4.1.3 MSG Part of a syslog Packet.................................11 4.2 Original syslog Packets Generated by a Device.................12 4.3 Relayed syslog Packets........................................12 4.3.1 Valid PRI and TIMESTAMP.....................................13 4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP.............13 4.3.3 No PRI or Unidentifiable PRI................................14 5. Conventions....................................................14 5.1 Dates and Times...............................................15 5.2 Domain Name and Address.......................................15
1. 序論…2 1.1のイベントと発生しているメッセージ…3 メッセージ受信機の1.2の操作…5 2. 層のプロトコルを輸送してください…5 3. 定義とアーキテクチャ…5 4. パケット・フォーマットとコンテンツ…7 4.1syslog Message Parts…8 4.1 .1 PRIは離れています…8 4.1 .2 syslog PacketのHEADER Part…10 4.1 .3 syslog PacketのMSG Part…11 4.2 Deviceによるオリジナルのsyslog Packets Generated…12 4.3はsyslog Packetsをリレーしました…12 4.3 .1の有効なPRIとタイムスタンプ…13 4.3 .2 有効なPRIにもかかわらず、TIMESTAMPでない無効のTIMESTAMPがありません…13 4.3 .3 PRIでないUnidentifiable PRIがありません…14 5. コンベンション…14 5.1日付と回…15 5.2のドメイン名とアドレス…15
Lonvick Informational [Page 1] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[1ページ]RFC3164BSD syslogプロトコル2001年8月
5.3 Originating Process Information...............................15 5.4 Examples......................................................16 6. Security Considerations........................................18 6.1 Packet Parameters.............................................19 6.2 Message Authenticity..........................................19 6.2.1 Authentication Problems.....................................19 6.2.2 Message Forgery.............................................20 6.3 Sequenced Delivery............................................20 6.3.1 Single Source to a Destination..............................20 6.3.2 Multiple Sources to a Destination...........................21 6.3.3 Multiple Sources to Multiple Destinations...................21 6.3.4 Replaying...................................................22 6.4 Reliable Delivery.............................................22 6.5 Message Integrity.............................................22 6.6 Message Observation...........................................22 6.7 Message Prioritization and Differentiation....................23 6.8 Misconfiguration..............................................24 6.9 Forwarding Loop...............................................24 6.10 Load Considerations..........................................25 7. IANA Considerations............................................25 8. Conclusion and Other Efforts...................................25 Acknowledgements..................................................26 References........................................................27 Author's Address..................................................28 Full Copyright Statement..........................................29
5.3 プロセス情報を溯源します…15 5.4の例…16 6. セキュリティ問題…18 6.1 パケットパラメタ…19 6.2 メッセージの信憑性…19 6.2 .1 認証問題…19 6.2 .2 メッセージ偽造…20 6.3は配送を配列しました…20 6.3 .1 目的地にソースを選抜してください…20 6.3 .2 目的地への倍数ソース…21 6.3 .3 複数の目的地への倍数ソース…21 6.3 .4 再演します…22 6.4 信頼できる配送…22 6.5メッセージの保全…22 6.6 メッセージ観測…22 6.7のメッセージ優先順位づけと分化…23 6.8Misconfiguration…24 6.9推進輪…24 6.10 問題をロードしてください…25 7. IANA問題…25 8. 結論と他の取り組み…25の承認…26の参照箇所…27作者のアドレス…28 完全な著作権宣言文…29
1. Introduction
1. 序論
Since the beginning, life has relied upon the transmission of messages. For the self-aware organic unit, these messages can relay many different things. The messages may signal danger, the presence of food or the other necessities of life, and many other things. In many cases, these messages are informative to other units and require no acknowledgement. As people interacted and created processes, this same principle was applied to societal communications. As an example, severe weather warnings may be delivered through any number of channels - a siren blowing, warnings delivered over television and radio stations, and even through the use of flags on ships. The expectation is that people hearing or seeing these warnings would realize their significance and take appropriate action. In most cases, no responding acknowledgement of receipt of the warning is required or even desired. Along these same lines, operating systems, processes and applications were written to send messages of their own status, or messages to indicate that certain events had occurred. These event messages generally had local significance to the machine operators. As the operating systems, processes and applications grew ever more complex, systems were devised to categorize and log these diverse messages and allow the operations staff to more quickly
始め以来、寿命はメッセージの伝達を当てにされています。 自己意識している有機的なユニットのために、これらのメッセージは多くのいろいろなものをリレーできます。 メッセージは危険か食物の存在か他の生活必需品と、他の多くのものを示すかもしれません。 多くの場合、これらのメッセージは、他のユニットに有益であり、承認を全く必要としません。 人々がプロセスを相互作用して、作成したとき、この同じ原則は社会のコミュニケーションに適用されました。 例として、天気擾乱警報はいろいろなチャンネルで提供されるかもしれません--サイレンが吹いて、警告はテレビと放送局の上と、そして、船における旗の使用さえを通して配送されました。 期待はこれらの警告を聞くか、または見る人々がそれらの意味がわかって、適切な行動を取るだろうということです。 多くの場合、警告の受領通知を反応させるのは、必要でない、または望まれてさえいません。 これらの同じ系列に沿って、オペレーティングシステム、プロセス、およびアプリケーションは、あるイベントが起こったのを示すそれら自身の状態、またはメッセージに関するメッセージを送るために書かれました。 一般に、これらのイベントメッセージはローカルの意味を機械工に持っていました。 オペレーティングシステムとして、プロセスとアプリケーションはかつてより複雑になりました、とシステムがよりはやくこれらのさまざまのメッセージを分類して、登録するために工夫されて、操作スタッフを許容します。
Lonvick Informational [Page 2] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[2ページ]RFC3164BSD syslogプロトコル2001年8月
differentiate the notifications of problems from simple status messages. The syslog process was one such system that has been widely accepted in many operating systems. Flexibility was designed into this process so the operations staff have the ability to configure the destination of messages sent from the processes running on the device. In one dimension, the events that were received by the syslog process could be logged to different files and also displayed on the console of the device. In another dimension, the syslog process could be configured to forward the messages across a network to the syslog process on another machine. The syslog process had to be built network-aware for some modicum of scalability since it was known that the operators of multiple systems would not have the time to access each system to review the messages logged there. The syslog process running on the remote devices could therefore be configured to either add the message to a file, or to subsequently forward it to another machine.
簡単なステータスメッセージと問題の通知を区別してください。 syslogプロセスは多くのオペレーティングシステムで広く受け入れられたそのようなシステムの1つでした。柔軟性はこのプロセスに設計されました、したがって、操作スタッフには、メッセージの送信先がデバイスで動きながらプロセスから発信したのを構成する能力があります。 一次元では、syslogプロセスによって受け取られたイベントは、異なったファイルに登録して、また、デバイスのコンソールの上に表示できました。 別次元では、ネットワークの向こう側に別のマシンの上のsyslogプロセスにメッセージを転送するためにsyslogプロセスを構成できました。 複数のシステムのオペレータにはそこに登録されたメッセージを再検討するために各システムにアクセスする時間がないのが知られていたので、syslogプロセスはネットワークスケーラビリティの何らかの少量において意識していた状態で建てられなければなりませんでした。 したがって、メッセージをファイルに追加するか、または次に別のマシンにそれを送るために遠隔装置で動くsyslogプロセスは構成できました。
In its most simplistic terms, the syslog protocol provides a transport to allow a machine to send event notification messages across IP networks to event message collectors - also known as syslog servers. Since each process, application and operating system was written somewhat independently, there is little uniformity to the content of syslog messages. For this reason, no assumption is made upon the formatting or contents of the messages. The protocol is simply designed to transport these event messages. In all cases, there is one device that originates the message. The syslog process on that machine may send the message to a collector. No acknowledgement of the receipt is made.
最も安易な用語で、syslogプロトコルはマシンがIPネットワークの向こう側にイベントメッセージコレクタにイベント通知メッセージを送るのを許容するために輸送を提供します--また、syslogサーバとして、知られています。 各プロセス、アプリケーション、およびオペレーティングシステムがいくらか独自に書かれたので、syslogメッセージの内容への一様性がほとんどありません。 この理由で、仮定は全くメッセージの形式かコンテンツでされません。 プロトコルは、これらのイベントメッセージを輸送するように単に設計されています。 すべての場合には、メッセージを溯源する1台のデバイスがあります。 そのマシンの上のsyslogプロセスはメッセージをコレクタに送るかもしれません。 領収書の承認を全くしません。
One of the fundamental tenets of the syslog protocol and process is its simplicity. No stringent coordination is required between the transmitters and the receivers. Indeed, the transmission of syslog messages may be started on a device without a receiver being configured, or even actually physically present. Conversely, many devices will most likely be able to receive messages without explicit configuration or definitions. This simplicity has greatly aided the acceptance and deployment of syslog.
syslogプロトコルとプロセスの基本的な主義の1つはその簡単さです。 どんな厳しいコーディネートも送信機と受信機の間で必要ではありません。 本当に、syslogメッセージの伝達は構成されたか、または実際に物理的に存在してさえいる受信機なしでさえデバイスを始めるかもしれません。 逆に、多くのデバイスがたぶん明白な構成も定義なしでメッセージを受け取ることができるでしょう。 この簡単さはsyslogの承認と展開を大いに支援しました。
1.1 Events and Generated Messages
1.1 イベントと発生しているメッセージ
The writers of the operating systems, processes and applications have had total control over the circumstances that would generate any message. In some cases, messages are generated to give status. These can be either at a certain period of time, or at some other interval such as the invocation or exit of a program. In other cases, the messages may be generated due to a set of conditions being met. In those cases, either a status message or a message containing an alarm of some type may be generated. It was considered that the writers of
オペレーティングシステム、プロセス、およびアプリケーションの作家には、どんなメッセージも生成する事情の総コントロールがありました。 いくつかの場合、メッセージは、状態を与えるために生成されます。 ある期間、またはプログラムの実施か出口などのある他の間隔を置いて、これらはあることができます。 他の場合では、メッセージは満たされる1セットの条件のため生成されるかもしれません。 それらの場合では、タイプに関するアラームを含むステータスメッセージかメッセージのどちらかが生成されるかもしれません。 それが考えられた、それ、作家
Lonvick Informational [Page 3] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[3ページ]RFC3164BSD syslogプロトコル2001年8月
the operating systems, processes and applications would quantify their messages into one of several broad categories. These broad categories generally consist of the facility that generated them, along with an indication of the severity of the message. This was so that the operations staff could selectively filter the messages and be presented with the more important and time sensitive notifications quickly, while also having the ability to place status or informative messages in a file for later perusal. Other options for displaying or storing messages have been seen to exist as well.
オペレーティングシステム、プロセス、およびアプリケーションはいくつかの広いカテゴリの1つにそれらのメッセージを定量化するでしょう。 一般に、これらの広いカテゴリはそれらを生成した施設から成ります、メッセージの厳しさのしるしと共に。 これは操作スタッフが選択的にメッセージをフィルターにかけることができるためのそうです、そして、また、後の熟読のためのファイルに状態か通知メッセージを置く能力を持っている間、すばやくより重要、そして、時間の機密の通知を与えてください。 また、存在するのをメッセージを表示するか、または保存するための別の選択肢を見てあります。
Devices MUST be configured with rules for displaying and/or forwarding the event messages. The rules that have been seen are generally very flexible. An administrator may want to have all messages stored locally as well as to have all messages of a high severity forwarded to another device. They may find it appropriate to also have messages from a particular facility sent to some or all of the users of the device and displayed on the system console. However the administrator decides to configure the disposition of the event messages, the process of having them sent to a syslog collector generally consists of deciding which facility messages and which severity levels will be forwarded, and then defining the remote receiver. For example, an administrator may want all messages that are generated by the mail facility to be forwarded to one particular event message collector. Then the administrator may want to have all kernel generated messages sent to a different syslog receiver while, at the same time, having the critically severe messages from the kernel also sent to a third receiver. It may also be appropriate to have those messages displayed on the system console as well as being mailed to some appropriate people, while at the same time, being sent to a file on the local disk of the device. Conversely, it may be appropriate to have messages from a locally defined process only displayed on the console but not saved or forwarded from the device. In any event, the rules for this will have to be generated on the device. Since the administrators will then know which types of messages will be received on the collectors, they should then make appropriate rules on those syslog servers as well.
イベントメッセージを表示する、そして/または、転送するための規則でデバイスを構成しなければなりません。 一般に、見られた規則は非常にフレキシブルです。 管理者は、すべてのメッセージを局所的に保存させて、高い厳しさに関するすべてのメッセージを別のデバイスに転送して頂きたいかもしれません。 彼らは、デバイスのユーザのいくつかかすべてに送られて、システム操作卓で表示された特定の施設からまた、メッセージを持っているのが適切であることがわかるかもしれません。 管理者が、イベントメッセージの気質を構成するとどのように決めても、どの施設メッセージとどの厳しさレベルがリモート受信機を進められて、次に、定義するかを決めるのから一般に、syslogコレクタにそれらを送らせるプロセスは成ります。例えば、管理者は1人の特定のイベントメッセージコレクタに郵便施設によって生成されるすべてのメッセージを転送して欲しいかもしれません。 次に、管理者は、同時にまた、第3の受信機に送られたカーネルからの批判的に厳しいメッセージを持っている間に異なったsyslog受信機に送られたメッセージであるとすべてのカーネルを生成して頂きたいかもしれません。また、何人かの適切な人々に郵送することと同様にシステム操作卓でそれらのメッセージを表示させるのも適切であるかもしれません、同時に、デバイスのローカルディスクのファイルに送って。 逆に、デバイスからコンソールの上に表示するだけですが、保存しないか、または進めない局所的に定義されたプロセスからのメッセージを持っているのは適切であるかもしれません。 とにかく、これのための規則はデバイスで生成されなければならないでしょう。 次に、管理者が、どのタイプに関するメッセージがコレクタの上に受け取られるかを知るので、彼らはそして、それらの適切な規則をまた、syslogサーバにするべきです。
The contents of a message have also been at the discretion of its creator. It has been considered to be good form to write the messages so that they are informative to the person who may be reading them. It has also been considered good practice to include a timestamp and some indication of the sending device and the process that originated it in the messages. However, none of those are stringently required.
また、クリエイターの裁量にはメッセージの内容がありました。 それがメッセージを書くためにちゃんとした行儀作法であると考えられたので、それらを読んでいるかもしれない人にとって、それらは有益です。 また、それは、メッセージでそれを溯源した送付デバイスとプロセスのタイムスタンプといくつかのしるしを含むように良い習慣であると考えられました。 しかしながら、それらのいずれも厳しく必要ではありません。
It should be assumed that any process on any device might generate an event message. This may include processes on machines that do not have any local storage - e.g., printers, routers, hubs, switches, and
どんなデバイスの上のどんなプロセスもイベントメッセージを生成するかもしれないと思われるべきです。 そしてこれは少しの地方のストレージも持っていないマシンの上のプロセスを含むかもしれません--例えば、プリンタ、ルータ、ハブが切り換える。
Lonvick Informational [Page 4] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[4ページ]RFC3164BSD syslogプロトコル2001年8月
diskless workstations. In that case, it may be imperative that event messages are transported to a collector so that they may be recorded and hopefully viewed by an operator.
ディスクレスワークステーション。 その場合、イベントメッセージがそれらを記録できるようにコレクタに輸送されて、希望をいだいてオペレータによって見られるのは、必須であるかもしれません。
1.2 Operations of the Message Receivers
1.2 メッセージ受信機の操作
It is beyond the scope of this document to specify how event messages should be processed when they are received. Like the operations described in Section 1.1, they generally may be displayed to the appropriate people, saved onto disk, further forwarded, or any combination of these. The rules for determining the disposition of received messages have been seen to be identical to the rules for determining the disposition of locally generated messages.
それは、それらが受け取られているとき、イベントメッセージがどう処理されるべきであるかを指定するためにこのドキュメントの範囲を超えています。 一般に、セクション1.1で説明された操作のように、さらに進められたディスクに保存された適切な人々かこれらのどんな組み合わせにもそれらを表示するかもしれません。 局所的に生成しているメッセージの気質を決定するための規則と同じであることを受信されたメッセージの気質を決定するための規則を見てあります。
As a very general rule, there are usually many devices sending messages to relatively fewer collectors. This fan-in process allows an administrator to aggregate messages into relatively few repositories.
非常に一般的な規則として、比較的少ないコレクタにメッセージを送る通常多くのデバイスがあります。 このファン-インプロセスで、管理者は比較的わずかな倉庫へのメッセージに集めることができます。
2. Transport Layer Protocol
2. トランスポート層プロトコル
syslog uses the user datagram protocol (UDP) [1] as its underlying transport layer mechanism. The UDP port that has been assigned to syslog is 514. It is RECOMMENDED that the source port also be 514 to indicate that the message is from the syslog process of the sender, but there have been cases seen where valid syslog messages have come from a sender with a source port other than 514. If the sender uses a source port other than 514 then it is RECOMMENDED and has been considered to be good form that subsequent messages are from a single consistent port.
syslogは基本的なトランスポート層メカニズムとしてユーザデータグラムプロトコル(UDP)[1]を使用します。 syslogに割り当てられたUDPポートは514です。 また、ソースポートがメッセージが送付者のsyslogプロセスから来ているのを示す514であることがRECOMMENDEDですが、有効なsyslogメッセージが送付者から来たところで見られたケースが514以外のソースポートをもってありました。 送付者が514以外のソースポートを使用するなら、その後のメッセージが単一の一貫したポートから来ているのはRECOMMENDEDであり、ちゃんとした行儀作法であると考えられました。
3. Definitions and Architecture
3. 定義とアーキテクチャ
The following definitions will be used in this document.
以下の定義は本書では使用されるでしょう。
A machine that can generate a message will be called a
"device".
メッセージを生成することができるマシンは「デバイス」と呼ばれるでしょう。
A machine that can receive the message and forward it to
another machine will be called a "relay".
メッセージを受け取って、別のマシンにそれを送ることができるマシンは、「リレー」と呼ばれるでしょう。
A machine that receives the message and does not relay it to
any other machines will be called a "collector". This has been
commonly known as a "syslog server".
メッセージを受け取って、いかなる他のマシンにもそれをリレーしないマシンは「コレクタ」と呼ばれるでしょう。 これは「syslogサーバ」として一般的に知られています。
Any device or relay will be known as the "sender" when it sends
a message.
メッセージを送るとき、どんなデバイスやリレーも「送付者」として知られているでしょう。
Lonvick Informational [Page 5] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[5ページ]RFC3164BSD syslogプロトコル2001年8月
Any relay or collector will be known as the "receiver" when it
receives the message.
メッセージを受け取るとき、どんなリレーやコレクタも「受信機」として知られているでしょう。
The architecture of the devices may be summarized as follows:
デバイスのアーキテクチャは以下の通りまとめられるかもしれません:
Senders send messages to relays or collectors with no knowledge
of whether it is a collector or relay.
送付者はそれがコレクタかそれともリレーであるかに関する知識なしでリレーかコレクタにメッセージを送ります。
Senders may be configured to send the same message to multiple
receivers.
Sendersは、同じメッセージを複数の受信機に送るために構成されるかもしれません。
Relays may send all or some of the messages that they receive
to a subsequent relay or collector. In the case where they do
not forward all of their messages, they are acting as both a
collector and a relay. In the following diagram, these devices
will be designated as relays.
Relays may send all or some of the messages that they receive to a subsequent relay or collector. In the case where they do not forward all of their messages, they are acting as both a collector and a relay. In the following diagram, these devices will be designated as relays.
Relays may also generate their own messages and send them on to
subsequent relays or collectors. In that case it is acting as
a device. These devices will also be designated as a relay in
the following diagram.
Relays may also generate their own messages and send them on to subsequent relays or collectors. In that case it is acting as a device. These devices will also be designated as a relay in the following diagram.
The following architectures shown in Diagram 1 are valid while the first one has been known to be the most prevalent. Other arrangements of these examples are also acceptable. As noted above, in the following diagram relays may pass along all or some of the messages that they receive along with passing along messages that they internally generate.
The following architectures shown in Diagram 1 are valid while the first one has been known to be the most prevalent. Other arrangements of these examples are also acceptable. As noted above, in the following diagram relays may pass along all or some of the messages that they receive along with passing along messages that they internally generate.
Lonvick Informational [Page 6] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational [Page 6] RFC 3164 The BSD syslog Protocol August 2001
+------+ +---------+
|Device|---->----|Collector|
+------+ +---------+
+------+ +---------+ |Device|---->----|Collector| +------+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->----|Collector|
+------+ +-----+ +---------+
+------+ +-----+ +---------+ |Device|---->----|Relay|---->----|Collector| +------+ +-----+ +---------+
+------+ +-----+ +-----+ +---------+
|Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+------+ +-----+ +-----+ +---------+
+------+ +-----+ +-----+ +---------+ |Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector| +------+ +-----+ +-----+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->----|Collector|
| |-\ +-----+ +---------+
+------+ \
\ +-----+ +---------+
\-->--|Relay|---->----|Collector|
+-----+ +---------+
+------+ +-----+ +---------+ |Device|---->----|Relay|---->----|Collector| | |-\ +-----+ +---------+ +------+ \ \ +-----+ +---------+ \-->--|Relay|---->----|Collector| +-----+ +---------+
+------+ +---------+
|Device|---->----|Collector|
| |-\ +---------+
+------+ \
\ +-----+ +---------+
\-->--|Relay|---->----|Collector|
+-----+ +---------+
+------+ +---------+ |Device|---->----|Collector| | |-\ +---------+ +------+ \ \ +-----+ +---------+ \-->--|Relay|---->----|Collector| +-----+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->-------|Collector|
| |-\ +-----+ /--| |
+------+ \ / +---------+
\ +-----+ /
\-->--|Relay|-->--/
+-----+
+------+ +-----+ +---------+ |Device|---->----|Relay|---->-------|Collector| | |-\ +-----+ /--| | +------+ \ / +---------+ \ +-----+ / \-->--|Relay|-->--/ +-----+
Diagram 1. Some Possible syslog Architectures
Diagram 1. Some Possible syslog Architectures
4. Packet Format and Contents
4. Packet Format and Contents
The payload of any IP packet that has a UDP destination port of 514 MUST be treated as a syslog message. There MAY be differences between the format of an originally transmitted syslog message and the format of a relayed message. In essence, it is RECOMMENDED to transmit a syslog message in the format specified in this document, but it is not required. If a relay is able to recognize the message as adhering to that format then it MUST retransmit the message without making any changes to it. However, if a relay receives a
The payload of any IP packet that has a UDP destination port of 514 MUST be treated as a syslog message. There MAY be differences between the format of an originally transmitted syslog message and the format of a relayed message. In essence, it is RECOMMENDED to transmit a syslog message in the format specified in this document, but it is not required. If a relay is able to recognize the message as adhering to that format then it MUST retransmit the message without making any changes to it. However, if a relay receives a
Lonvick Informational [Page 7] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational [Page 7] RFC 3164 The BSD syslog Protocol August 2001
message but cannot discern the proper implementation of the format, it is REQUIRED to modify the message so that it conforms to that format before it retransmits it. Section 4.1 will describe the RECOMMENDED format for syslog messages. Section 4.2 will describe the requirements for originally transmitted messages and Section 4.3 will describe the requirements for relayed messages.
message but cannot discern the proper implementation of the format, it is REQUIRED to modify the message so that it conforms to that format before it retransmits it. Section 4.1 will describe the RECOMMENDED format for syslog messages. Section 4.2 will describe the requirements for originally transmitted messages and Section 4.3 will describe the requirements for relayed messages.
4.1 syslog Message Parts
4.1 syslog Message Parts
The full format of a syslog message seen on the wire has three discernable parts. The first part is called the PRI, the second part is the HEADER, and the third part is the MSG. The total length of the packet MUST be 1024 bytes or less. There is no minimum length of the syslog message although sending a syslog packet with no contents is worthless and SHOULD NOT be transmitted.
The full format of a syslog message seen on the wire has three discernable parts. The first part is called the PRI, the second part is the HEADER, and the third part is the MSG. The total length of the packet MUST be 1024 bytes or less. There is no minimum length of the syslog message although sending a syslog packet with no contents is worthless and SHOULD NOT be transmitted.
4.1.1 PRI Part
4.1.1 PRI Part
The PRI part MUST have three, four, or five characters and will be
bound with angle brackets as the first and last characters. The PRI
part starts with a leading "<" ('less-than' character), followed by a
number, which is followed by a ">" ('greater-than' character). The
code set used in this part MUST be seven-bit ASCII in an eight-bit
field as described in RFC 2234 [2]. These are the ASCII codes as
defined in "USA Standard Code for Information Interchange" [3]. In
this, the "<" character is defined as the Augmented Backus-Naur Form
(ABNF) %d60, and the ">" character has ABNF value %d62. The number
contained within these angle brackets is known as the Priority value
and represents both the Facility and Severity as described below.
The Priority value consists of one, two, or three decimal integers
(ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9").
The PRI part MUST have three, four, or five characters and will be bound with angle brackets as the first and last characters. The PRI part starts with a leading "<" ('less-than' character), followed by a number, which is followed by a ">" ('greater-than' character). The code set used in this part MUST be seven-bit ASCII in an eight-bit field as described in RFC 2234 [2]. These are the ASCII codes as defined in "USA Standard Code for Information Interchange" [3]. In this, the "<" character is defined as the Augmented Backus-Naur Form (ABNF) %d60, and the ">" character has ABNF value %d62. The number contained within these angle brackets is known as the Priority value and represents both the Facility and Severity as described below. The Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9").
The Facilities and Severities of the messages are numerically coded with decimal values. Some of the operating system daemons and processes have been assigned Facility values. Processes and daemons that have not been explicitly assigned a Facility may use any of the "local use" facilities or they may use the "user-level" Facility. Those Facilities that have been designated are shown in the following table along with their numerical code values.
The Facilities and Severities of the messages are numerically coded with decimal values. Some of the operating system daemons and processes have been assigned Facility values. Processes and daemons that have not been explicitly assigned a Facility may use any of the "local use" facilities or they may use the "user-level" Facility. Those Facilities that have been designated are shown in the following table along with their numerical code values.
Numerical Facility
Code
Numerical Facility Code
0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages (note 1)
0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages (note 1)
Lonvick Informational [Page 8] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational [Page 8] RFC 3164 The BSD syslog Protocol August 2001
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon (note 2)
10 security/authorization messages (note 1)
11 FTP daemon
12 NTP subsystem
13 log audit (note 1)
14 log alert (note 1)
15 clock daemon (note 2)
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)
5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon (note 2) 10 security/authorization messages (note 1) 11 FTP daemon 12 NTP subsystem 13 log audit (note 1) 14 log alert (note 1) 15 clock daemon (note 2) 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7)
Table 1. syslog Message Facilities
Table 1. syslog Message Facilities
Note 1 - Various operating systems have been found to utilize
Facilities 4, 10, 13 and 14 for security/authorization,
audit, and alert messages which seem to be similar.
Note 2 - Various operating systems have been found to utilize
both Facilities 9 and 15 for clock (cron/at) messages.
Note 1 - Various operating systems have been found to utilize Facilities 4, 10, 13 and 14 for security/authorization, audit, and alert messages which seem to be similar. Note 2 - Various operating systems have been found to utilize both Facilities 9 and 15 for clock (cron/at) messages.
Each message Priority also has a decimal Severity level indicator. These are described in the following table along with their numerical values.
Each message Priority also has a decimal Severity level indicator. These are described in the following table along with their numerical values.
Numerical Severity
Code
Numerical Severity Code
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages
0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages
Table 2. syslog Message Severities
Table 2. syslog Message Severities
Lonvick Informational [Page 9] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational [Page 9] RFC 3164 The BSD syslog Protocol August 2001
The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI part of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively. The only time a value of "0" will follow the "<" is for the Priority value of "0". Otherwise, leading "0"s MUST NOT be used.
The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI part of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively. The only time a value of "0" will follow the "<" is for the Priority value of "0". Otherwise, leading "0"s MUST NOT be used.
4.1.2 HEADER Part of a syslog Packet
4.1.2 HEADER Part of a syslog Packet
The HEADER part contains a timestamp and an indication of the hostname or IP address of the device. The HEADER part of the syslog packet MUST contain visible (printing) characters. The code set used MUST also be seven-bit ASCII in an eight-bit field like that used in the PRI part. In this code set, the only allowable characters are the ABNF VCHAR values (%d33-126) and spaces (SP value %d32).
The HEADER part contains a timestamp and an indication of the hostname or IP address of the device. The HEADER part of the syslog packet MUST contain visible (printing) characters. The code set used MUST also be seven-bit ASCII in an eight-bit field like that used in the PRI part. In this code set, the only allowable characters are the ABNF VCHAR values (%d33-126) and spaces (SP value %d32).
The HEADER contains two fields called the TIMESTAMP and the HOSTNAME. The TIMESTAMP will immediately follow the trailing ">" from the PRI part and single space characters MUST follow each of the TIMESTAMP and HOSTNAME fields. HOSTNAME will contain the hostname, as it knows itself. If it does not have a hostname, then it will contain its own IP address. If a device has multiple IP addresses, it has usually been seen to use the IP address from which the message is transmitted. An alternative to this behavior has also been seen. In that case, a device may be configured to send all messages using a single source IP address regardless of the interface from which the message is sent. This will provide a single consistent HOSTNAME for all messages sent from a device.
The HEADER contains two fields called the TIMESTAMP and the HOSTNAME. The TIMESTAMP will immediately follow the trailing ">" from the PRI part and single space characters MUST follow each of the TIMESTAMP and HOSTNAME fields. HOSTNAME will contain the hostname, as it knows itself. If it does not have a hostname, then it will contain its own IP address. If a device has multiple IP addresses, it has usually been seen to use the IP address from which the message is transmitted. An alternative to this behavior has also been seen. In that case, a device may be configured to send all messages using a single source IP address regardless of the interface from which the message is sent. This will provide a single consistent HOSTNAME for all messages sent from a device.
The TIMESTAMP field is the local time and is in the format of "Mmm dd hh:mm:ss" (without the quote marks) where:
The TIMESTAMP field is the local time and is in the format of "Mmm dd hh:mm:ss" (without the quote marks) where:
Mmm is the English language abbreviation for the month of the
year with the first character in uppercase and the other two
characters in lowercase. The following are the only acceptable
values:
Mmm is the English language abbreviation for the month of the year with the first character in uppercase and the other two characters in lowercase. The following are the only acceptable values:
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
dd is the day of the month. If the day of the month is less
than 10, then it MUST be represented as a space and then the
number. For example, the 7th day of August would be
represented as "Aug 7", with two spaces between the "g" and
the "7".
dd is the day of the month. If the day of the month is less than 10, then it MUST be represented as a space and then the number. For example, the 7th day of August would be represented as "Aug 7", with two spaces between the "g" and the "7".
Lonvick Informational [Page 10] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational [Page 10] RFC 3164 The BSD syslog Protocol August 2001
hh:mm:ss is the local time. The hour (hh) is represented in a
24-hour format. Valid entries are between 00 and 23,
inclusive. The minute (mm) and second (ss) entries are between
00 and 59 inclusive.
hh:mm:ss is the local time. The hour (hh) is represented in a 24-hour format. Valid entries are between 00 and 23, inclusive. The minute (mm) and second (ss) entries are between 00 and 59 inclusive.
A single space character MUST follow the TIMESTAMP field.
A single space character MUST follow the TIMESTAMP field.
The HOSTNAME field will contain only the hostname, the IPv4 address, or the IPv6 address of the originator of the message. The preferred value is the hostname. If the hostname is used, the HOSTNAME field MUST contain the hostname of the device as specified in STD 13 [4]. It should be noted that this MUST NOT contain any embedded spaces. The Domain Name MUST NOT be included in the HOSTNAME field. If the IPv4 address is used, it MUST be shown as the dotted decimal notation as used in STD 13 [5]. If an IPv6 address is used, any valid representation used in RFC 2373 [6] MAY be used. A single space character MUST also follow the HOSTNAME field.
The HOSTNAME field will contain only the hostname, the IPv4 address, or the IPv6 address of the originator of the message. The preferred value is the hostname. If the hostname is used, the HOSTNAME field MUST contain the hostname of the device as specified in STD 13 [4]. It should be noted that this MUST NOT contain any embedded spaces. The Domain Name MUST NOT be included in the HOSTNAME field. If the IPv4 address is used, it MUST be shown as the dotted decimal notation as used in STD 13 [5]. If an IPv6 address is used, any valid representation used in RFC 2373 [6] MAY be used. A single space character MUST also follow the HOSTNAME field.
4.1.3 MSG Part of a syslog Packet
4.1.3 MSG Part of a syslog Packet
The MSG part will fill the remainder of the syslog packet. This will usually contain some additional information of the process that generated the message, and then the text of the message. There is no ending delimiter to this part. The MSG part of the syslog packet MUST contain visible (printing) characters. The code set traditionally and most often used has also been seven-bit ASCII in an eight-bit field like that used in the PRI and HEADER parts. In this code set, the only allowable characters are the ABNF VCHAR values (%d33-126) and spaces (SP value %d32). However, no indication of the code set used within the MSG is required, nor is it expected. Other code sets MAY be used as long as the characters used in the MSG are exclusively visible characters and spaces similar to those described above. The selection of a code set used in the MSG part SHOULD be made with thoughts of the intended receiver. A message containing characters in a code set that cannot be viewed or understood by a recipient will yield no information of value to an operator or administrator looking at it.
The MSG part will fill the remainder of the syslog packet. This will usually contain some additional information of the process that generated the message, and then the text of the message. There is no ending delimiter to this part. The MSG part of the syslog packet MUST contain visible (printing) characters. The code set traditionally and most often used has also been seven-bit ASCII in an eight-bit field like that used in the PRI and HEADER parts. In this code set, the only allowable characters are the ABNF VCHAR values (%d33-126) and spaces (SP value %d32). However, no indication of the code set used within the MSG is required, nor is it expected. Other code sets MAY be used as long as the characters used in the MSG are exclusively visible characters and spaces similar to those described above. The selection of a code set used in the MSG part SHOULD be made with thoughts of the intended receiver. A message containing characters in a code set that cannot be viewed or understood by a recipient will yield no information of value to an operator or administrator looking at it.
The MSG part has two fields known as the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message. This has traditionally been a freeform message that gives some detailed information of the event. The TAG is a string of ABNF alphanumeric characters that MUST NOT exceed 32 characters. Any non-alphanumeric character will terminate the TAG field and will be assumed to be the starting character of the CONTENT field. Most commonly, the first character of the CONTENT field that signifies the
The MSG part has two fields known as the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message. This has traditionally been a freeform message that gives some detailed information of the event. The TAG is a string of ABNF alphanumeric characters that MUST NOT exceed 32 characters. Any non-alphanumeric character will terminate the TAG field and will be assumed to be the starting character of the CONTENT field. Most commonly, the first character of the CONTENT field that signifies the
Lonvick Informational [Page 11] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational [Page 11] RFC 3164 The BSD syslog Protocol August 2001
conclusion of the TAG field has been seen to be the left square
bracket character ("["), a colon character (":"), or a space
character. This is explained in more detail in Section 5.3.
conclusion of the TAG field has been seen to be the left square bracket character ("["), a colon character (":"), or a space character. This is explained in more detail in Section 5.3.
4.2 Original syslog Packets Generated by a Device
4.2 Original syslog Packets Generated by a Device
There are no set requirements on the contents of the syslog packet as it is originally sent from a device. It should be reiterated here that the payload of any IP packet destined to UDP port 514 MUST be considered to be a valid syslog message. It is, however, RECOMMENDED that the syslog packet have all of the parts described in Section 4.1 - PRI, HEADER and MSG - as this enhances readability by the recipient and eliminates the need for a relay to modify the message.
There are no set requirements on the contents of the syslog packet as it is originally sent from a device. It should be reiterated here that the payload of any IP packet destined to UDP port 514 MUST be considered to be a valid syslog message. It is, however, RECOMMENDED that the syslog packet have all of the parts described in Section 4.1 - PRI, HEADER and MSG - as this enhances readability by the recipient and eliminates the need for a relay to modify the message.
For implementers that do choose to construct syslog messages with the RECOMMENDED format, the following guidance is offered.
RECOMMENDED形式でsyslogメッセージを構成するのを選ぶimplementersのために、以下の指導を提供します。
If the originally formed message has a TIMESTAMP in the HEADER
part, then it SHOULD be the local time of the device within its
timezone.
元々形成されたメッセージがそうしたなら、TIMESTAMPはHEADERで離れて、次に、SHOULDです。タイムゾーンの中の装置の現地時間になってください。
If the originally formed message has a HOSTNAME field, then it
will contain the hostname as it knows itself. If it does not
have a hostname, then it will contain its own IP address.
元々形成されたメッセージにHOSTNAME分野があると、それは己を知っているようにホスト名を含むでしょう。 ホスト名がないと、それはそれ自身のIPアドレスを含むでしょう。
If the originally formed message has a TAG value, then that
will be the name of the program or process that generated the
message.
元々形成されたメッセージにTAG値があると、それはメッセージを発生させたプログラムか過程の名前になるでしょう。
4.3 Relayed syslog Packets
4.3 リレーされたsyslog Packets
When a relay receives a packet, it will check for a valid PRI. If the first character is not a less-than sign, the relay MUST assume that the packet does not contain a valid PRI. If the 3rd, 4th, or 5th character is not a right angle bracket character, the relay again MUST assume that the PRI was not included in the original message. If the relay does find a valid PRI part then it must check for a valid TIMESTAMP in the HEADER part. From these rules, there will be three general cases of received messages. Table 3 gives the general characteristics of these cases and lists the subsequent section of this document that describes the handling of that case.
リレーがパケットを受けるとき、それは有効なPRIがないかどうかチェックするでしょう。 最初のキャラクタが不等号でないなら、リレーは、パケットが有効なPRIを含まないと仮定しなければなりません。 3番目、4番目、または5番目のキャラクタが直角ブラケットキャラクタでないなら、リレーは、再びPRIがオリジナルのメッセージに含まれていなかったと仮定しなければなりません。 有効なPRIが部分であることがリレーによってわかるなら、それはHEADER部分の有効なTIMESTAMPがないかどうかチェックしなければなりません。 これらの規則から、受信されたメッセージの3つの一般的なケースが来ているでしょう。 テーブル3はそのケースの取り扱いについて説明するこのドキュメントのその後のセクションをこれらのケースとリストの一般的特色に与えます。
Case Section
Valid PRI and TIMESTAMP 4.3.1
Valid PRI but no TIMESTAMP or invalid TIMESTAMP 4.3.2
No PRI or unidentifiable PRI 4.3.3
セクションValid PRIとTIMESTAMPをケースに入れてください、4.3、.1Valid PRI、いいえTIMESTAMP、無効のTIMESTAMP4.3.2ノーPRIまたはunidentifiable PRI4.3.3
Table 3. Cases of Received syslog Messages
3を見送ってください。 Received syslog Messagesに関するケース
Lonvick Informational [Page 12] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[12ページ]RFC3164BSD syslogプロトコル2001年8月
4.3.1 Valid PRI and TIMESTAMP
4.3.1 有効なPRIとタイムスタンプ
If the relay does find a valid PRI and a valid TIMESTAMP, then it will check its internal configuration. Relays MUST be configured to forward syslog packets on the basis of their Priority value. If the relay finds that it is configured to forward the received packet, then it MUST do so without making any changes to the packet. To emphasize the point one more time, it is for this reason that it is RECOMMENDED that the syslog message originally transmitted adhere to the format described in Section 4.1.
リレーがそうするなら、有効なPRIと有効なTIMESTAMPを見つけてください、そして、次に、それは内部の構成をチェックするでしょう。 それらのPriority値に基づいてsyslogパケットを進めるためにリレーを構成しなければなりません。 容認されたパケットを進めるのが構成されているリレー掘り出し物であるなら、パケットへのどんな変更も行わないで、それはそうしなければなりません。 より多くの1回の間、ポイントを強調するために、それは元々送られたsyslogメッセージがセクション4.1で説明された形式を固く守るのが、RECOMMENDEDであるこの理由であります。
It should be noted here that the message receiver does not need to validate the time in the TIMESTAMP field. The assumption may be made that a device whose date has not been correctly set will still have the ability to send valid syslog messages. Additionally, the relay does not need to validate that the value in the HOSTNAME field matches the hostname or IP address of the device sending the message. A reason for this behavior may be found in Section 4.1.2.
ここにメッセージ受信機がTIMESTAMP分野で時間を有効にする必要はないと述べられるべきです。 それでも、日付が正しく決められていない装置が有効なsyslogメッセージを送る能力を持つという仮定はされるかもしれません。 さらに、リレーは、メッセージを送りながら、有効にするHOSTNAME分野の値が合っているどんな必要性にも装置のホスト名かIPアドレスをしません。 この振舞いの理由はセクション4.1.2で見つけられるかもしれません。
4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP
4.3.2 有効なPRIにもかかわらず、TIMESTAMPでない無効のTIMESTAMPがありません。
If a relay does not find a valid TIMESTAMP in a received syslog packet, then it MUST add a TIMESTAMP and a space character immediately after the closing angle bracket of the PRI part. It SHOULD additionally add a HOSTNAME and a space character after the TIMESTAMP. These fields are described here and detailed in Section 4.1.2. The remainder of the received packet MUST be treated as the CONTENT field of the MSG and appended. Since the relay would have no way to determine the originating process from the device that originated the message, the TAG value cannot be determined and will not be included.
リレーが容認されたsyslogパケットで有効なTIMESTAMPに当たらないなら、それはPRI部分の終わりの角ブラケット直後TIMESTAMPと間隔文字を加えなければなりません。 それ、SHOULDはTIMESTAMPの後にさらに、HOSTNAMEと間隔文字を加えます。 これらの分野は、セクション4.1.2でここで説明されて、詳しく述べられます。 容認されたパケットの残りをMSGのCONTENT分野として扱って、追加しなければなりません。 リレーには、メッセージを溯源した装置から由来している過程を決定する方法が全くないでしょう、TAG値は、決定できないで、したがって、含まれないでしょう。
The TIMESTAMP will be the current local time of the relay.
TIMESTAMPはリレーの現地時間の電流になるでしょう。
The HOSTNAME will be the name of the device, as it is known by the relay. If the name cannot be determined, the IP address of the device will be used.
それがリレーで知られているようにHOSTNAMEは装置の名前になるでしょう。 名前が決定できないと、装置のIPアドレスは使用されるでしょう。
If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after the PRI part, then it MUST check that the total length of the packet is still 1024 bytes or less. If the packet has been expanded beyond 1024 bytes, then the relay MUST truncate the packet to be 1024 bytes. This may cause the loss of vital information from the end of the original packet. It is for this reason that it is RECOMMENDED that the PRI and HEADER parts of originally generated syslog packets contain the values and fields documented in Section 4.1.
PRIが離れた後にリレーがTIMESTAMPか、TIMESTAMPとHOSTNAMEを加えるなら、パケットの全長がそれでも1024バイト以下であることはチェックしなければなりません。 パケットが1024バイトを超えたところまで広げられたなら、リレーは、1024バイトになるようにパケットに先端を切らせなければなりません。 これが、オリジナルのパケットの端からの極めて重要な情報の損失をもたらすかもしれません。 それは元々発生しているsyslogパケットのPRIとHEADER一部がセクション4.1に記録された値と分野を含むのが、RECOMMENDEDであるこの理由であります。
Lonvick Informational [Page 13] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[13ページ]RFC3164BSD syslogプロトコル2001年8月
4.3.3 No PRI or Unidentifiable PRI
4.3.3 PRIでないUnidentifiable PRIがありません。
If the relay receives a syslog message without a PRI, or with an unidentifiable PRI, then it MUST insert a PRI with a Priority value of 13 as well as a TIMESTAMP as described in Section 4.3.2. The relay SHOULD also insert a HOSTNAME as described in Section 4.3.2. The entire contents of the received packet will be treated as the CONTENT of the relayed MSG and appended.
リレーがPRIなしでunidentifiable PRIと共にsyslogメッセージを受け取るなら、それはセクション4.3.2で説明されるようにTIMESTAMPと同様に13のPriority値でPRIを挿入しなければなりません。 また、リレーSHOULDはセクション4.3.2で説明されるようにHOSTNAMEを挿入します。 容認されたパケットの全体のコンテンツをリレーされたMSGのCONTENTとして扱って、追加するでしょう。
An example of an unidentifiable PRI would be "<00>", without the double quotes. It may be that these are the first 4 characters of the message. To continue this example, if a relay does receive a syslog message with the first four characters of "<00>", then it will consult its configuration. If it is configured to forward syslog messages with a Priority value of 13 to another relay or collector, then it MUST modify the packet as described above. The specifics of doing this, including the RECOMMENDED insertion of the HOSTNAME, are given below.
unidentifiable PRIに関する例は二重引用符がなければ「<00>」でしょう。 多分、これらはメッセージの最初の4つのキャラクタです。 この例を続けるために、リレーが「<00>」の最初の4つのキャラクタと共にsyslogメッセージを受け取ると、それは構成に相談するでしょう。 13のPriority値があるsyslogメッセージを別のリレーかコレクタに転送するのが構成されているなら、それは上で説明されるようにパケットを変更しなければなりません。 HOSTNAMEのRECOMMENDED挿入を含むこれをする詳細を以下に与えます。
Originally received message
<00>...
Relayed message
<13>TIMESTAMP HOSTNAME <00>...
元々、メッセージ<00>を受けます… メッセージ<13>TIMESTAMP HOSTNAME<00>をリレーします…
If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after the PRI part, then it MUST check that the total length of the packet is still 1024 bytes or less. If the packet has been expanded beyond 1024 bytes, then the relay MUST truncate the packet to be 1024 bytes. This may cause the loss of vital information from the end of the original packet. It is for this reason that it is RECOMMENDED that the PRI and HEADER parts of originally generated syslog packets contain the values and fields documented in Section 4.1.
PRIが離れた後にリレーがTIMESTAMPか、TIMESTAMPとHOSTNAMEを加えるなら、パケットの全長がそれでも1024バイト以下であることはチェックしなければなりません。 パケットが1024バイトを超えたところまで広げられたなら、リレーは、1024バイトになるようにパケットに先端を切らせなければなりません。 これが、オリジナルのパケットの端からの極めて重要な情報の損失をもたらすかもしれません。 それは元々発生しているsyslogパケットのPRIとHEADER一部がセクション4.1に記録された値と分野を含むのが、RECOMMENDEDであるこの理由であります。
5. Conventions
5. コンベンション
Although Section 4 of this document specifies all requirements for the syslog protocol format and contents, certain conventions have come about over time for the inclusion of additional information within the syslog message. It must be plainly stated that these items are not mandated but may be considered by implementers for completeness and to give the recipient some additional clues of their origin and nature.
このドキュメントのセクション4はsyslogプロトコル形式とコンテンツのためのすべての要件を指定しますが、あるコンベンションは時間がたつにつれて頃にsyslogメッセージの中に追加情報の包含をしに来ました。 明らかに、これらの項目が強制されませんが、完全性、彼らの起源と自然のいくつかの追加手がかりを受取人に与えるとimplementersによって考えられるかもしれないと述べなければなりません。
Lonvick Informational [Page 14] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[14ページ]RFC3164BSD syslogプロトコル2001年8月
5.1 Dates and Times
5.1日付と回
It has been found that some network administrators like to archive their syslog messages over long periods of time. It has been seen that some original syslog messages contain a more explicit time stamp in which a 2 character or 4 character year field immediately follows the space terminating the TIMESTAMP. This is not consistent with the original intent of the order and format of the fields. If implementers wish to contain a more specific date and time stamp within the transmitted message, it should be within the CONTENT field. Implementers may wish to utilize the ISO 8601 [7] date and time formats if they want to include more explicit date and time information.
何人かのネットワーク管理者が、長期間の間、彼らのsyslogメッセージを格納するのが好きであることが見つけられました。 いくつかのオリジナルのsyslogメッセージが2キャラクタか4キャラクタ年の分野がすぐにTIMESTAMPを終えるスペースの後をつけるより明白なタイムスタンプを含むのが見られました。 これはオーダーの当初の意図と分野の形式と一致していません。 implementersが伝えられたメッセージの中により特定の期日とタイムスタンプを含みたいなら、CONTENT分野の中にそれはあるべきです。 より明白な日時の情報を含みたいなら、ImplementersはISO8601[7]日時の形式を利用したがっているかもしれません。
Additional methods to address this desire for long-term archiving have been proposed and some have been successfully implemented. One such method is that the network administrators may choose to modify the messages stored on their collectors. They may run a simple script to add the year, and any other information, to each stored record. Alternatively, the script may replace the stored time with a format more appropriate for the needs of the network administrators. Another alternative has been to insert a record into the file that contains the current year. By association then, all other records near that informative record should have been received in that same year. Neither of these however, addresses the issue of associating a correct timezone with each record.
長期の格納に関するこの願望を記述する追加方法は提案されました、そして、或るものは首尾よく実行されました。 そのような方法の1つはネットワーク管理者が、彼らのコレクタに格納されたメッセージを変更するのを選ぶかもしれないということです。 彼らは、1年、およびいかなる他の情報もそれぞれの格納された記録に追加するために簡単なスクリプトを走らせるかもしれません。 あるいはまた、スクリプトは格納された時間をネットワーク管理者の必要性には、より適切な形式に取り替えるかもしれません。 別の代替手段は本年度を含むファイルの中に記録を挿入することです。 そして、協会によって、その有益な記録における他のすべての記録が同じ年にそれに受け取られるべきでした。 どちらもしかしながら、これらでは、aを関連づける問題がタイムゾーンを修正するアドレスはそれぞれ記録します。
5.2 Domain Name and Address
5.2 ドメイン名とアドレス
To readily identify the device that originated the message, it may be a good practice to include its fully qualified domain name (FQDN) and its IP address within the CONTENT field. Traditionally, however, only the hostname has been included in the HOSTNAME field.
容易にメッセージを溯源した装置を特定するために、CONTENT分野の中に完全修飾ドメイン名(FQDN)とそのIPアドレスを含むのは、良い習慣であるかもしれません。 しかしながら、伝統的に、ホスト名だけがHOSTNAME分野に含まれています。
5.3 Originating Process Information
5.3 由来しているプロセス情報
It has also been considered to be a good practice to include some information about the process on the device that generated the message - if that concept exists. This is usually the process name and process id (often known as the "pid") for robust operating systems. The process name is commonly displayed in the TAG field. Quite often, additional information is included at the beginning of the CONTENT field. The format of "TAG[pid]:" - without the quote marks - is common. The left square bracket is used to terminate the TAG field in this case and is then the first character in the CONTENT field. If the process id is immaterial, it may be left off.
また、それは、その概念が存在しているならメッセージを発生させた装置の過程の何らかの情報を含むように良い習慣であると考えられました。 通常、これは、強健なオペレーティングシステムのための過程名と過程イド("pid"としてしばしば知られている)です。TAG分野に一般的に過程名を表示します。 かなりしばしば、追加情報はCONTENT分野の始めに含まれています。 形式、「[pid]にタグ付けをしてください」 - 引用符--コモンはそうですか? 左の角括弧はこの場合TAG分野を終えるのに使用されます、そして、次に最初のキャラクタがCONTENT分野にありますか? 過程イドが重要でないなら、それはやめられるかもしれません。
Lonvick Informational [Page 15] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[15ページ]RFC3164BSD syslogプロトコル2001年8月
In that case, a colon and a space character usually follow the TAG. This would be displayed as "TAG: " without the quotes. In that case, the colon is the first character in the CONTENT field.
その場合、通常、コロンと間隔文字はTAGに続きます。 「以下にタグ付けをする」とき、これを表示するでしょう。 「引用文。」 その場合、コロンはCONTENT分野において最初のキャラクタです。
5.4 Examples
5.4 例
As examples, these are valid messages as they may be observed on the wire between two devices. In the following examples, each message has been indented, with line breaks inserted in this document for readability.
例として、それらが2台の装置の間のワイヤの上に観測されるかもしれないようにこれらは有効なメッセージです。 以下の例では、ラインブレイクが本書では読み易さのために挿入されている状態で、各メッセージは字下がりにされました。
Example 1
例1
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick
on /dev/pts/8
<34>10月の11 22:14:15mymachine su: /dev/pts/8の上のlonvickのために失敗された'su根'
This example shows an authentication error in an attempt to acquire additional privileges. It also shows the command attempted and the user attempting it. This was recorded as an original message from the device called mymachine. A relay receiving this would not make any changes before sending it along as it contains a properly formatted PRI part and TIMESTAMP field in the HEADER part. The TAG value in this example is the process "su". The colon has terminated the TAG field and is the first character of the CONTENT field. In this case, the process id (pid) would be considered transient and anyone looking at this syslog message would gain no useful information from knowing the pid. It has not been included so the first two characters of the CONTENT field are the colon and a space character.
この例は追加特権を取得する試みにおける認証誤りを示しています。 また、それは、試みられたコマンドとユーザがそれを試みるのを示します。 装置からのオリジナルのメッセージが、mymachineと呼んだようにこれは記録されました。 HEADER部分の適切にフォーマットされたPRI部分とTIMESTAMP分野を含んでいるのでそれを送る前に、これを受けるリレーはどんな変更も行わないでしょう。 この例のTAG値は過程"su"です。 コロンは、TAG分野を終えて、CONTENT分野の最初のキャラクタです。 この場合、過程イド(pid)は一時的であると考えられるでしょう、そして、このsyslogメッセージを見ているだれもpidを知るのから役に立つ情報を全く獲得しないでしょう。 したがって、CONTENT分野の最初の2つのキャラクタが、それは含まれていなくて、コロンと間隔文字です。
Example 2
例2
Use the BFG!
BFGを使用してください!
While this is a valid message, it has extraordinarily little useful information. This message does not have any discernable PRI part. It does not contain a timestamp or any indication of the source of the message. If this message is stored on paper or disk, subsequent review of the message will not yield anything of value.
これは有効なメッセージですが、それには、異常に少ない役に立つ情報があります。 このメッセージには、少しのdiscernable PRI部分もありません。 それはメッセージの源のタイムスタンプかどんなしるしも含んでいません。 ディスク、メッセージのその後のレビューがそのようにこのメッセージが紙上で格納されるか、格納でなくなるなら、価値について何でももたらしてください。
This example is obviously an original message from a device. A relay MUST make changes to the message as described in Section 4.3 before forwarding it. The resulting relayed message is shown below.
この例は明らかに装置からのオリジナルのメッセージです。 リレーはそれを進める前にセクション4.3で説明されるようにメッセージへの変更を行わなければなりません。 結果として起こるリレーされたメッセージは以下に示されます。
<13>Feb 5 17:32:18 10.0.0.99 Use the BFG!
<13>2月5日の17:32: 18 10.0 .0 .99はBFGを使用します!
Lonvick Informational [Page 16] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[16ページ]RFC3164BSD syslogプロトコル2001年8月
In this relayed message, the entire message has been treated as the CONTENT portion of the MSG part. First, a valid PRI part has been added using the default priority value of 13. Next, a TIMESTAMP has been added along with a HOSTNAME in the HEADER part. Subsequent relays will not make any further changes to this message. It should be noted in this example that the day of the month is less than 10. Since single digits in the date (5 in this case) are preceded by a space in the TIMESTAMP format, there are two spaces following the month in the TIMESTAMP before the day of the month. Also, the relay appears to have no knowledge of the host name of the device sending the message so it has inserted the IPv4 address of the device into the HOSTNAME field.
このリレーされたメッセージでは、全体のメッセージはMSG部分のCONTENT部分として扱われました。 まず最初に、有効なPRI部分は、13のデフォルト優先順位の値を使用することで加えられます。 次に、TIMESTAMPはHOSTNAMEと共にHEADER部分で加えられます。 その後のリレーはこのメッセージへのどんな一層の変更も行わないでしょう。 この例に月の日が10未満であると述べられるべきです。 TIMESTAMP形式のスペースが日付(この場合、5)の一桁に先行するので、月の日前のTIMESTAMPの月の次の2つの空間があります。 また、リレーがメッセージを送りながら装置のホスト名に関する知識を全く持っていないように見えるので、それは装置のIPv4アドレスをHOSTNAME分野に挿入しました。
Example 3
例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 # %%
<165>8月24日の中部標準時5時34分0秒の1987mymachine myproc[10]: ドーナツを作る%%Itの時間。 %、%成分: ミックスはOK、ゼリー=OK#装置と等しいです: ミキサーはOKと等しく、ゼリー_インジェクタはOK、フライ料理人=OK#輸送と等しいです: Conveyer1はOKと等しく、Conveyer2=OK#%は%です。
This message does have a valid PRI part with a Priority value indicating that it came from a locally defined facility (local4) with a severity of Notice. The HEADER part has a proper TIMESTAMP field in the message. A relay will not modify this message before sending it. However, the HOSTNAME and TAG fields are not consistent with the definitions in Section 4. The HOSTNAME field would be construed to be "CST" and the beginning of the MSG part would be "1987".
このメッセージには、Priority値が、それがNoticeの厳しさの局所的に定義された能力(local4)から来たのを示している有効なPRI部分があります。 HEADER部分には、メッセージの適切なTIMESTAMP分野があります。 それを送る前に、リレーはこのメッセージを変更しないでしょう。 しかしながら、HOSTNAMEとTAG分野はセクション4との定義と一致していません。 HOSTNAME分野は"CST"になるように解釈されるでしょう、そして、エムエスジー部分の始まりは「1987」でしょう。
It should be noted that the information contained in the CONTENT of this example is not telemetry data, nor is it supervisory control or data acquisition information. Due to the security concerns listed in Section 6 of this document, information of that nature should probably not be conveyed across this protocol.
この例のCONTENTに含まれた情報が遠隔測定データでなく、それが監視制御かデータ取得情報でないことに注意されるべきです。 このドキュメントのセクション6に記載された安全上の配慮のため、たぶんこのプロトコルの向こう側にその自然の情報を伝えるべきではありません。
Example 4
例4
<0>1990 Oct 22 10:52:01 TZ-6 scapegoat.dmz.example.org 10.1.2.3
sched[0]: That's All Folks!
<0>1990年10月の22 10:52:01TZ-6 scapegoat.dmz.example.org10.1.2.3sched[0]: ザッツ・オール人々!
This example has a lot of extraneous information throughout. A human or sufficiently adaptable automated parser would be able to determine the date and time information as well as a fully qualified domain name (FQDN) [4] and IP address. The information about the nature of the event is, however, limited. Due to the indicated severity of the event, the process may not have been able to gather or send anything more informative. It may have been fortunate to have generated and sent this message at all.
この例には、あらゆる点で、多くの異質な情報があります。 人間の、または、十分融通のきく自動化されたパーサは完全修飾ドメイン名(FQDN)[4]とIPアドレスと同様に日時の情報を決定できるでしょう。 しかしながら、出来事の自然の情報は制限されます。 出来事の示された厳しさのため、過程は、集まることができませんでしたし、何でより有益なものを送ることができなかったかもしれません。 全くこのメッセージを発生して、送ったのは幸いであったかもしれません。
Lonvick Informational [Page 17] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[17ページ]RFC3164BSD syslogプロトコル2001年8月
This example is obviously an original message from a device. Since the first field in the HEADER part is not a TIMESTAMP in the format defined in Section 4.1.2, it MUST be modified by a relay. A relay will add a TIMESTAMP and SHOULD add a HOSTNAME as follows and will treat the entire received packet after the PRI part from the original packet as the CONTENT field of the new packet. The value used in the HOSTNAME field is only the hostname without the domain name as it is known by the relay. A TAG value will not be added to the relayed packet. While the inclusion of the domain name and IPv4 address in the original message is a noble endeavor, it is not consistent with the use of the field as described in Section 4.1.2.
この例は明らかにデバイスからのオリジナルのメッセージです。 HEADER部分における最初の分野がセクション4.1.2で定義された書式でのTIMESTAMPでないので、リレーでそれを変更しなければなりません。 PRIが新しいパケットのCONTENT分野としてオリジナルのパケットと別れた後に、リレーは、TIMESTAMPとSHOULDが以下のHOSTNAMEを加えると言い足して、全体の容認されたパケットを扱うでしょう。 それがリレーで知られているように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!
<0>10月の22 10:52:12身代わり1990年10月の22 10:52:01TZ-6 scapegoat.dmz.example.org10.1.2の.3sched[0]: ザッツ・オール人々!
6. Security Considerations
6. セキュリティ問題
An odor may be considered to be a message that does not require any acknowledgement. People tend to avoid bad odors but are drawn to odors that they associate with good food. The acknowledgement of the receipt of the odor or scent is not required and indeed it may be the height of discretion to totally ignore some odors. On the other hand, it is usually considered good civility to acknowledge the prowess of the cook merely from the ambiance wafting from the kitchen. Similarly, various species have been found to utilize odors to attract mates. One species of moth uses this scent to find each other. However, it has been found that bolas spiders can mimic the odor of the female moths of this species. This scent will then attract male moths, which will follow it with the expectation of finding a mate. Instead, when they arrive at the source of the scent, they will be eaten [8]. This is a case of a false message being sent out with inimical intent.
においは少しの承認も必要としないメッセージであると考えられるかもしれません。 人々は、悪いにおいを避ける傾向がありますが、それらが良い食物に関連づけるにおいに引きつけられます。 においかにおいの領収書の承認は必要ではありません、そして、本当に、それは、いくつかのにおいを完全に無視するためには思慮深さの高さであるかもしれません。 他方では、通常、それは、単に台所から漂うアンビアンスからコックの勇気を承認するために良い礼儀正しさであると考えられます。 同様に、多様な種は仲間を引き付けるのににおいを利用するのがわかりました。 ガの1つの種が、互いを見つけるのにこのにおいを使用します。 しかしながら、ボーラクモがこの種の雌のガのにおいをまねることができるのが見つけられました。 そして、このにおいは雄ガを引きよせるでしょう。(そのガは、仲間を見つけることへの期待でそれの後をつけるでしょう)。 においの源に到着すると、代わりに、それらは到着するでしょう。[8]を食べます。 これは反目している意図をもって出される誤ったメッセージのそうです。
In its local use, the syslog process places event notification messages into files on that system. This relies upon the integrity of the system for the protection of the messages. The subsequent configuration of the syslog process to use the syslog protocol to transport the messages to a remote collector was an extension of the delivery of event notification messages and it exhibits the same trust of the network. There are several security consequences of the fundamental simplicity of syslog and there are some concerns about the applicability of this protocol in situations that require robust delivery. Along the lines of the analogy, computer event messages may be sent accidentally, erroneously and even maliciously. At the time of this writing, however, there have not been any reports of any networked device consuming any other device.
地方の使用で、syslogプロセスはそのシステムのファイルの中にイベント通知メッセージを置きます。 これはメッセージの保護のシステムの保全を当てにされます。 リモートコレクタにメッセージを輸送するのにsyslogプロトコルを使用するsyslogプロセスのその後の構成はイベント通知メッセージとそれの配送の拡大がネットワークの同じ信頼を示すということでした。 syslogの基本的な簡単さのいくつかのセキュリティ結果があります、そして、このプロトコルの適用性に関するいくつかの心配が体力を要している配送を必要とする状況にあります。 類推の系列に沿って、偶然、誤って陰湿にさえコンピュータイベントメッセージを送るかもしれません。 しかしながら、この書くこと時点で、いかなる他のデバイスも消費するどんなネットワークでつながれたデバイスのどんなレポートもありませんでした。
Lonvick Informational [Page 18] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[18ページ]RFC3164BSD syslogプロトコル2001年8月
6.1 Packet Parameters
6.1 パケットパラメタ
As was described above, the message length MUST NOT exceed 1024 bytes. Attacks have seen where syslog messages are sent to a receiver that have message lengths greater than 1024 bytes. In some older versions of syslog, the receipt of syslog packets that had a message greater than 1024 bytes caused problems. syslog message receivers must not malfunction upon the receipt of packets where the message length is greater than 1024 bytes. Various behaviors have been seen on receivers that do receive messages greater than 1024 bytes. Some have been seen to log the entire contents of the message, while others have been seen to log only portions of the message. Still others have been known to discard the message altogether. Devices MUST NOT retransmit messages whose received length exceeds 1024 bytes.
上で説明されたように、メッセージ長は1024バイトを超えてはいけません。 攻撃は、syslogメッセージがどこで1024バイト以上のメッセージ長を持っている受信機に送られるかを見ました。 syslogのいくつかの旧式のバージョンでは、1024バイト以上のメッセージを持っていたsyslogパケットの領収書は問題を起こしました。syslogメッセージ受信機はメッセージ長が1024バイト以上であるパケットの領収書で誤動作してはいけません。 1024バイト以上のメッセージを受け取る受信機の上で様々な振舞いを見てあります。 或るものはメッセージの全体のコンテンツを登録するのを見られました、他のものがメッセージの部分だけを登録するのを見られましたが。 それでも、他のものが全体でメッセージを捨てるのが知られています。 デバイスは容認された長さが1024バイトを超えているメッセージを再送してはいけません。
Similarly, the receiver must rigidly enforce the correctness of the message body. syslog collectors must not malfunction if received messages do not have the less-than and greater-than characters around a valid Priority value. They MUST treat these messages as the unformatted CONTENT as was described in Section 4.3.3 if they relay it.
同様に、受信機はメッセージ本体の正当性を厳格に実施しなければなりません。そして、受信されたメッセージが誤動作しないならsyslogコレクタが誤動作してはいけない、 より少なさ、-、すばらしさ、-、有効なPriority値の周りのキャラクタ。 彼らはそれをリレーするならセクション4.3.3で説明されたunformatted CONTENTとしてこれらのメッセージを扱わなければなりません。
Also, received messages must contain printable text in the message as was described throughout Section 4. Devices must not malfunction if they receive a message containing characters other than the characters described above.
また、受信されたメッセージはセクション4中で説明されたメッセージの印刷可能なテキストを含まなければなりません。 彼らが上で説明されたキャラクタ以外のキャラクタを含むメッセージを受け取るなら、デバイスは誤動作してはいけません。
6.2 Message Authenticity
6.2 メッセージの信憑性
The syslog delivery mechanism does not strongly associate the message with the message sender. The receiver of that packet will not be able to ascertain that the message was indeed sent from the reported sender, or if the packet was sent from another device. It should be noted here that the message receiver does not need to verify that the HOSTNAME in the HEADER part match the name of the IP address contained in the Source Address field of the IP packet.
syslog排紙機構は強くメッセージ送付者にメッセージを関連づけません。 そのパケットの受信機は本当に、報告された送付者からメッセージを送って、別のデバイスからパケットを送ったかどうかがそうするのを確かめることができないでしょう。 ここにメッセージ受信機が、HEADER部分のHOSTNAMEがIPパケットのSource Address分野に保管されていたIPアドレスの名前に合っていることを確かめる必要はないと述べられるべきです。
6.2.1 Authentication Problems
6.2.1 認証問題
One possible consequence of this behavior is that a misconfigured machine may send syslog messages to a collector representing itself as another machine. The administrative staff may become confused that the status of the supposed sender of the messages may not be accurately reflected in the received messages. The administrators may not be able to readily discern that there are two or more machines representing themselves as the same machine.
この振舞いの1つの可能な結果はmisconfiguredマシンが別のマシンと称するコレクタにsyslogメッセージを送るかもしれないということです。 メッセージの想定された送付者の状態が正確に受信されたメッセージに反映されないかもしれないのが混乱して、管理職員はなるかもしれません。 管理者は、同じマシンと称する2台以上のマシンがあるのを容易に裁量できないかもしれません。
Lonvick Informational [Page 19] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[19ページ]RFC3164BSD syslogプロトコル2001年8月
It should also be noted that some cases of filling the HOSTNAME field in the HEADER part might only have local significance and that may only be ephemeral. If the device had obtained an IP address from a DHCP pool, then any association between an identifier and an actual source would not always hold true. The inclusion of a fully qualified domain name in the CONTENT may give the administrators the best chance of identifying the source of each message if it can always be associated with an IP address or if it can always be associated with a unique machine.
また、ローカルの意味がHEADER部分のHOSTNAME分野をいっぱいにするいくつかのケースにあるだけであるかもしれなく、それがはかないだけであるかもしれないことに注意されるべきです。 デバイスがDHCPプールからIPアドレスを得たなら、識別子と実際のソースとの少しの仲間もいつも有効であるというわけではないでしょう。 CONTENTでの完全修飾ドメイン名の包含はいつもIPアドレスにそれを関連づけることができるか、またはいつもユニークなマシンにそれを関連づけることができるならそれぞれのメッセージの源を特定するという絶好のチャンスを管理者に与えるかもしれません。
6.2.2 Message Forgery
6.2.2 メッセージ偽造
Malicious exploits of this behavior have also been noted. An attacker may transmit syslog messages (either from the machine from which the messages are purportedly sent or from any other machine) to a collector. In one case, an attacker may hide the true nature of an attack amidst many other messages. As an example, an attacker may start generating forged messages indicating a problem on some machine. This may get the attention of the system administrators who will spend their time investigating the alleged problem. During this time, the attacker may be able to compromise a different machine, or a different process on the same machine. Additionally, an attacker may generate false syslog messages to give untrue indications of status or of events. As an example, an attacker may stop a critical process on a machine, which may generate a notification of exit. The attacker may subsequently generate a forged notification that the process had been restarted. The system administrators may accept that misinformation and not verify that the process had indeed been restarted.
また、この振舞いの悪意がある功績は注意されました。 攻撃者はsyslogメッセージ(メッセージが表面上送られるマシンかいかなる他のマシンからの)をコレクタに送るかもしれません。 ある場合では、攻撃者は他の多くのメッセージの中に攻撃の本質を隠すかもしれません。 例として、攻撃者は、あるマシンの上に問題を示す偽造メッセージを生成し始めるかもしれません。 これは申し立てられた問題を調査するのに彼らの時間を費やすシステム管理者の注意を得るかもしれません。 この間に、攻撃者は同じマシンの上で異なったマシン、または異なったプロセスに感染することができるかもしれません。 さらに、攻撃者は状態かイベントの虚偽のしるしを与える誤ったsyslogメッセージを生成するかもしれません。 例として、攻撃者はマシンで重要なプロセスを止めるかもしれません。(それは、出口の通知を生成するかもしれません)。 攻撃者は次に、プロセスが再開されたという偽造通知を生成するかもしれません。 システム管理者は、その誤伝を受け入れて、本当に、プロセスが再開されたことを確かめないかもしれません。
6.3 Sequenced Delivery
6.3 配列された配送
As a general rule, the forensics of a network anomaly rely upon reconstructing the sequence of events. In a perfect world, the messages would be received on the syslog collector in the order of their generation from the other devices and anyone looking at these records would have an accurate picture of the sequence of events. Unfortunately, the syslog process and protocol do not ensure ordered delivery. This section details some of the problems that may be encountered from this.
概して、ネットワーク異常のフォレンジックはイベントの系列を再建するのを当てにします。 理想の世界では、彼らの世代の注文におけるsyslogコレクタの上に対向機器からメッセージを受け取るでしょう、そして、これらの記録を見ているだれでもイベントの系列の正確な画像を持っているでしょう。 残念ながら、syslogプロセスとプロトコルは命令された配送を確実にしません。 このセクションはこれから行きあたられるかもしれない問題のいくつかを詳しく述べます。
6.3.1 Single Source to a Destination
6.3.1 目的地への単独のソース
The syslog records are usually presented (placed in a file, displayed on the console, etc.) in the order in which they are received. This is not always in accordance with the sequence in which they were generated. As they are transported across an IP network, some out of order receipt should be expected. This may lead to some confusion as
通常、syslog記録はそれらが受け取られているオーダーに提示されます(コンソールの上に表示されたファイルなどに置かれます)。 いつもそれらが生成された系列によると、これはありません。 それらがIPネットワークの向こう側に輸送されていて、何らかの不適切な領収書が予想されるべきであるということであるので。 これは何らかの混乱に導くかもしれません。
Lonvick Informational [Page 20] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[20ページ]RFC3164BSD syslogプロトコル2001年8月
messages may be received that would indicate that a process has stopped before it was started. This may be somewhat rectified if the originating process had timestamped or numbered each of the messages before transmission. In this, the sending device should utilize an authoritative time source. It should be remembered, however, that not all devices are capable of receiving time updates, and not all devices can timestamp their messages.
それが始められる前にプロセスが止まったのを示すメッセージを受け取るかもしれません。 起因するプロセスがトランスミッションの前にそれぞれに関するメッセージにtimestampedしたか、または付番したなら、これはいくらか正されるかもしれません。 これでは、送付デバイスは正式の時間ソースを利用するはずです。 しかしながら、それは覚えていられるべきであり、デバイスはすべてのデバイス缶のタイムスタンプではなく、時間アップデートを受けながらできるすべてではなく、それがそれらのメッセージです。
6.3.2 Multiple Sources to a Destination
6.3.2 目的地への複数のソース
In syslog, there is no concept of unified event numbering. Single devices are free to include a sequence number within the CONTENT but that can hardly be coordinated between multiple devices. In such cases, multiple devices may report that each one is sending message number one. Again, this may be rectified somewhat if the sending devices utilize a timestamp from an authoritative source in their messages. As has been noted, however, even messages from a single device to a single collector may be received out of order. This situation is compounded when there are several devices configured to send their syslog messages to a single collector. Messages from one device may be delayed so the collector receives messages from another device first even though the messages from the first device were generated before the messages from the second. If there is no timestamp or coordinated sequence number, then the messages may be presented in the order in which they were received which may give an inaccurate view of the sequence of actual events.
syslogには、統一されたイベント付番の概念が全くありません。 単一のデバイスはCONTENTの中に無料で一連番号を含むことができますが、複数のデバイスの間でそれをほとんど調整できません。 そのような場合、複数のデバイスが、各々がメッセージ番号1を送ると報告するかもしれません。 一方、いくらか送付デバイスがそれらのメッセージで権威筋からのタイムスタンプを利用するなら、これは正されるかもしれません。 しかしながら、有名であったように、故障していた状態で単一のデバイスから独身のコレクタまでのメッセージさえ受け取るかもしれません。 それらのsyslogメッセージを独身のコレクタに送るために構成された数台のデバイスがあるとき、この状況は合成されます。 1台のデバイスからのメッセージは遅れるかもしれません、したがって、最初のデバイスからのメッセージが2番目からのメッセージの前に最初に、生成されましたが、コレクタは別のデバイスからメッセージを受け取ります。 どんなタイムスタンプも連携一連番号もなければ、メッセージは現実の出来事の系列の不正確な意見を与えるかもしれないそれらがどれであったかで受けられた注文に提示されるかもしれません。
6.3.3 Multiple Sources to Multiple Destinations
6.3.3 複数の目的地への複数のソース
The plethora of configuration options available to the network administrators may further skew the perception of the order of events. It is possible to configure a group of devices to send the status messages -or other informative messages- to one collector, while sending messages of relatively higher importance to another collector. Additionally, the messages may be sent to different files on the same collector. If the messages do not contain timestamps from the source, it may be difficult to order the messages if they are kept in different places. An administrator may not be able to determine if a record in one file occurred before or after a record in a different file. This may be somewhat alleviated by placing marking messages with a timestamp into all destination files. If these have coordinated timestamps, then there will be some indication of the time of receipt of the individual messages.
ネットワーク管理者にとって、利用可能な設定オプションの過剰はさらにイベントの注文の認知を歪曲するかもしれません。 1人のコレクタへの有益なメッセージを-何らかのステータスメッセージに送るためにデバイスのグループを構成するのは比較的高く重要なメッセージを別のコレクタに送る間、可能です。 さらに、同じコレクタの異なったファイルにメッセージを送るかもしれません。 それらが異なった場所に保たれて、メッセージがソースからのタイムスタンプを含んでいないなら、メッセージを注文するのは難しいかもしれません。 管理者は、1個のファイルでの記録が異なったファイルでの記録の前または後に現れたかどうか決定できないかもしれません。 これは、すべての目的ファイルにタイムスタンプをメッセージに付けながら入賞することによって、いくらか軽減されるかもしれません。 これらがタイムスタンプを調整したなら、個々のメッセージの収入の時期のいくつかのしるしがあるでしょう。
Lonvick Informational [Page 21] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[21ページ]RFC3164BSD syslogプロトコル2001年8月
6.3.4 Replaying
6.3.4 再演
Without any sequence indication or timestamp, messages may be recorded and replayed at a later time. An attacker may record a set of messages that indicate normal activity of a machine. At a later time, that attacker may remove that machine from the network and replay the syslog messages to the collector. Even with a TIMESTAMP field in the HEADER part, an attacker may record the packets and could simply modify them to reflect the current time before retransmitting them. The administrators may find nothing unusual in the received messages and their receipt would falsely indicate normal activity of the machine.
少しも系列指示やタイムスタンプがなければ、メッセージは、後で記録されて、再演されるかもしれません。 攻撃者はマシンの正常な活動を示す1セットのメッセージを記録するかもしれません。 後で、その攻撃者は、ネットワークからそのマシンを取り外して、syslogメッセージをコレクタに再演するかもしれません。 TIMESTAMP分野さえHEADER部分にある状態で、攻撃者は、パケットを記録するかもしれなくて、それらを再送する前の現在の時間に反射するように単にそれらを変更できました。 管理者は、受信されたメッセージとそれらの領収書で珍しいものは何も間違ってマシンの正常な活動を示さないのがわかるかもしれません。
6.4 Reliable Delivery
6.4 信頼できる配信
As there is no mechanism within either the syslog process or the protocol to ensure delivery, and since the underlying transport is UDP, some messages may be lost. They may either be dropped through network congestion, or they may be maliciously intercepted and discarded. The consequences of the drop of one or more syslog messages cannot be determined. If the messages are simple status updates, then their non-receipt may either not be noticed, or it may cause an annoyance for the system operators. On the other hand, if the messages are more critical, then the administrators may not become aware of a developing and potentially serious problem. Messages may also be intercepted and discarded by an attacker as a way to hide unauthorized activities.
配送を確実にするためにsyslogプロセスかプロトコルのどちらかの中にメカニズムが全くなくて、基本的な輸送がUDPであるので、いくつかのメッセージが失われるかもしれません。 ネットワークの混雑で下げられるかもしれないか、それらは、陰湿に妨害されて、捨てられるかもしれません。 1つ以上のsyslogメッセージの低下の結果は決定できません。 メッセージが簡単な状態最新版であるなら、それらの非領収書は気付かれないかもしれませんか、またはそれがシステムオペレーターに関するいらだちを引き起こすかもしれません。 他方では、メッセージが、より重要であるなら、管理者は開発していて潜在的に重大な問題を意識するようにならないかもしれません。 また、メッセージは、無許可の行為を隠す方法として攻撃者によって傍受されて、捨てられるかもしれません。
6.5 Message Integrity
6.5 メッセージの保全
Besides being discarded, syslog messages may be damaged in transit, or an attacker may maliciously modify them. In the case of a packet containing a syslog message being damaged, there are various mechanisms built into the link layer as well as into the IP [9] and UDP protocols which may detect the damage. An intermediary router may discard a damaged IP packet [10]. Damage to a UDP packet may be detected by the receiving UDP module, which may silently discard it. In any case, the original contents of the message will not be delivered to the collector. Additionally, if an attacker is positioned between the sender and collector of syslog messages, they may be able to intercept and modify those messages while in-transit to hide unauthorized activities.
捨てられること以外に、syslogメッセージがトランジットで破損するかもしれませんか、または攻撃者は陰湿にそれらを変更するかもしれません。 破損していて、syslogメッセージを含むパケットのケースには、リンクレイヤの中と、そして、IP[9]の中に造られた様々なメカニズムと損害を検出するかもしれないUDPプロトコルがあります。 仲介者ルータは破損しているIPパケット[10]を捨てるかもしれません。 UDPパケットへの損害は受信UDPモジュールで検出されるかもしれません。(静かに、それは、それを捨てるかもしれません)。 どのような場合でも、メッセージに関するオリジナルコンテンツはコレクタに提供されないでしょう。 さらに、それらは、無許可の行為を隠すためにトランジットである間、それらのメッセージを傍受して、攻撃者がsyslogメッセージの送付者とコレクタの間に置かれるなら、変更できるかもしれません。
6.6 Message Observation
6.6 メッセージ観測
While there are no strict guidelines pertaining to the event message format, most syslog messages are generated in human readable form with the assumption that capable administrators should be able to
イベントメッセージ・フォーマットに関係する厳格な指導目標が全くない間、ほとんどのsyslogメッセージが人間の読み込み可能なフォームで有能な管理者ができるべきである仮定で生成されます。
Lonvick Informational [Page 22] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[22ページ]RFC3164BSD syslogプロトコル2001年8月
read them and understand their meaning. Neither the syslog protocol nor the syslog application have mechanisms to provide confidentiality of the messages in transit. In most cases passing clear-text messages is a benefit to the operations staff if they are sniffing the packets off of the wire. The operations staff may be able to read the messages and associate them with other events seen from other packets crossing the wire to track down and correct problems. Unfortunately, an attacker may also be able to observe the human- readable contents of syslog messages. The attacker may then use the knowledge gained from those messages to compromise a machine or do other damage.
それらを読んでください、そして、彼らが意味するのを理解してください。 syslogプロトコルもsyslogアプリケーションも、メッセージの秘密性をトランジットに提供するメカニズムがありません。 彼らがワイヤからパケットをかいでいるなら、多くの場合、クリアテキストメッセージを通過するのは、操作スタッフへの利益です。 操作スタッフは、捜し出すワイヤを越える他のパケットと正しい問題から見られる他のイベントに、メッセージを読んで、それらを関連づけることができるかもしれません。残念ながら、また、攻撃者はsyslogメッセージの人間の読み込み可能なコンテンツを観測できるかもしれません。 そして、攻撃者はマシンに感染するか、または他の損害を与えるそれらのメッセージから獲得された知識を使用するかもしれません。
6.7 Message Prioritization and Differentiation
6.7 メッセージ優先順位づけと分化
While the processes that create the messages may signify the importance of the events through the use of the message Priority value, there is no distinct association between this value and the importance of delivery of the packet. As an example of this, consider an application that generates two event messages. The first is a normal status message but the second could be an important message denoting a problem with the process. This second message would have an appropriately higher Severity value associated with the importance of that event. If the operators had configured that both of these messages be transported to a syslog collector then they would, in turn, be given to UDP for transmission. Under normal conditions, no distinction would be made between them and they would be transmitted in their order.
メッセージを作成するプロセスはメッセージPriority価値の使用でイベントの重要性を意味するかもしれませんが、この値とパケットの配送の重要性とのどんな異なった協会もありません。 この例と、2イベントがメッセージであると生成するアプリケーションを考えてください。 1番目は正常なステータスメッセージですが、2番目はプロセスに関する問題を指示する重要なメッセージであるかもしれません。 この2番目のメッセージには、そのイベントの重要性に関連している適切により高いSeverity値があるでしょう。 オペレータが、これらのメッセージの両方がsyslogコレクタに輸送されるのを構成したなら、トランスミッションのために順番にそれらをUDPに与えるでしょう。 正常な状況では、それらの間で区別を全くしないでしょう、そして、彼らのオーダーでそれらを伝えるでしょう。
Again, under normal circumstances, the receiver would accept syslog messages as they are received. If many devices are transmitting normal status messages, but one is transmitting an important event message, there is no inherent mechanism within the syslog protocol to prioritize the important message over the other messages.
再び、通常の状況下で、それらが受け取られているとき、受信機はsyslogメッセージを受け入れるでしょう。 多くのデバイスが正常なステータスメッセージを伝えていますが、人が重大事件メッセージを送っているなら、他のメッセージの上で重要なメッセージを最優先させるために、syslogプロトコルの中にどんな固有のメカニズムもありません。
On a case-by-case basis, device operators may find some way to associate the different levels with the quality of service identifiers. As an example, the operators may elect to define some linkage between syslog messages that have a specific Priority value with a specific value to be used in the IPv4 Precedence field [9], the IPv6 Traffic Class octet [11], or the Differentiated Services field [12]. In the above example, the operators may have the ability to associate the status message with normal delivery while associating the message indicating a problem with a high reliability, low latency queue as it goes through the network. This would have the affect of prioritizing the essential messages before the normal status messages. Even with this hop-by-hop prioritization, this queuing mechanism could still lead to head of line blocking on the transmitting device as well as buffer starvation on the receiving
ケースバイケースで、デバイスオペレータは異なったレベルをサービスの質識別子に関連づける何らかの方法を見つけるかもしれません。 例として、オペレータは、IPv4 Precedence分野[9](IPv6 Traffic Class八重奏[11]、またはDifferentiated Services分野[12])で使用されるために特定の値で特定のPriority値を持っているsyslogメッセージの間のいくらかのリンケージを定義するのを選ぶかもしれません。 上記の例では、オペレータは高信頼性に関する問題を示すメッセージを関連づけている間にステータスメッセージを正常分娩に関連づける能力を持っているかもしれなくて、ネットワークに直面しているとき、低遅延は列を作ります。 これには、正常なステータスメッセージの前に不可欠のメッセージを最優先させる感情があるでしょう。 ホップごとのこの優先順位づけがあっても、この列を作りメカニズムはまだ受信でのバッファ飢餓と同様に伝えるデバイスにおける系列ブロッキングのヘッドに通じているかもしれません。
Lonvick Informational [Page 23] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[23ページ]RFC3164BSD syslogプロトコル2001年8月
device if there are many near-simultaneous messages being sent or received. This behavior is not unique to syslog but is endemic to all operations that transmit messages serially.
多くの近く同時のメッセージがあれば、デバイスは、送ったか、または受信されました。 この振舞いは、syslogにユニークではありませんが、順次メッセージを送るすべての操作に風土病です。
There are security concerns for this behavior. Head of line blocking of the transmission of important event messages may relegate the conveyance of important messages behind less important messages. If the queue is cleared appropriately, this may only add seconds to the transmission of the important message. On the other hand, if the queue is not cleared, then important messages may not be transmitted. Also at the receiving side, if the syslog receiver is suffering from buffer starvation due to large numbers of messages being received near-simultaneously, important messages may be dropped indiscriminately along with other messages. While these are problems with the devices and their capacities, the protocol security concern is that there is no prioritization of the relatively more important messages over the less important messages.
この振舞いのための安全上の配慮があります。 重大事件メッセージの伝達の系列ブロッキングのヘッドはそれほど重要でないメッセージの後ろで重要なメッセージの運送を左遷するかもしれません。 待ち行列が適切にクリアされるなら、これは重要なメッセージの伝達に秒を加えるだけであるかもしれません。 他方では、待ち行列がクリアされないなら、重要なメッセージは送られないかもしれません。 受信側でも、syslog受信機が-同時の状態で受け取られる多くのメッセージのためバッファ飢餓が欠点であるなら、重要なメッセージは他のメッセージと共に無差別に下げられるかもしれません。 これらはデバイスと彼らの能力に関する問題ですが、プロトコルセキュリティ関心はそれほど重要でないメッセージの上に比較的重要なメッセージの優先順位づけが全くないということです。
6.8 Misconfiguration
6.8 Misconfiguration
Since there is no control information distributed about any messages or configurations, it is wholly the responsibility of the network administrator to ensure that the messages are actually going to the intended recipient. Cases have been noted where devices were inadvertently configured to send syslog messages to the wrong receiver. In many cases, the inadvertent receiver may not be configured to receive syslog messages and it will probably discard them. In certain other cases, the receipt of syslog messages has been known to cause problems for the unintended recipient [13]. If messages are not going to the intended recipient, then they cannot be reviewed or processed.
どんなメッセージや構成に関しても分配された制御情報が全くないので、メッセージが実際に意図している受取人のものになっているのを保証するのは、完全にネットワーク管理者の責任です。 ケースはデバイスがsyslogメッセージを間違った受信機に送るためにうっかり構成されたところで有名です。多くの場合、不注意な受信機はsyslogメッセージを受け取るために構成されないかもしれません、そして、それはたぶんそれらを捨てるでしょう。 他のある場合では、syslogメッセージの領収書が故意でない受取人[13]のために問題を起こすのが知られています。 メッセージが意図している受取人のものになっていないなら、それらを見直すことができないか、処理できません。
6.9 Forwarding Loop
6.9 推進輪
As it is shown in Figure 1, machines may be configured to relay syslog messages to subsequent relays before reaching a collector. In one particular case, an administrator found that he had mistakenly configured two relays to forward messages with certain Priority values to each other. When either of these machines either received or generated that type of message, it would forward it to the other relay. That relay would, in turn, forward it back. This cycle did cause degradation to the intervening network as well as to the processing availability on the two devices. Network administrators must take care to not cause such a death spiral.
それが図1に示されるように、マシンはコレクタに届く前にその後のリレーにsyslogメッセージをリレーするために構成されるかもしれません。 ある特定の場合では、管理者は、彼が、あるPriority値があるメッセージを互いに転送するために2個のリレーを誤って構成したのがわかりました。 これらのマシンのどちらかがそのタイプに関するメッセージを受け取ったか、または生成したとき、それはもう片方のリレーにそれを送るでしょう。 そのリレーは順番にそれを送って戻すでしょう。 このサイクルは2台のデバイスで処理の有用性に関してまた、介入しているネットワークに原因退行をしました。 ネットワーク管理者は、そのようなデススパイラルを引き起こさないように注意しなければなりません。
Lonvick Informational [Page 24] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[24ページ]RFC3164BSD syslogプロトコル2001年8月
6.10 Load Considerations
6.10 負荷問題
Network administrators must take the time to estimate the appropriate size of the syslog receivers. An attacker may perform a Denial of Service attack by filling the disk of the collector with false messages. Placing the records in a circular file may alleviate this but that has the consequence of not ensuring that an administrator will be able to review the records in the future. Along this line, a receiver or collector must have a network interface capable of receiving all messages sent to it.
ネットワーク管理者はわざわざsyslog受信機の適切なサイズを見積もらなければなりません。 攻撃者は、誤ったメッセージでコレクタのディスクを満たすことによって、サービス妨害攻撃を実行するかもしれません。 円形のファイルでの記録を置くと、これは軽減するかもしれませんが、それには、管理者が将来記録を再検討できるのを確実にしない結果があります。 この系列に沿って、受信機かコレクタがネットワーク・インターフェースをそれに送られたすべてのメッセージは受け取ることができるようにしなければなりません。
Administrators and network planners must also critically review the network paths between the devices, the relays, and the collectors. Generated syslog messages should not overwhelm any of the network links.
また、管理者とネットワーク立案者は批判的にデバイスと、リレーと、コレクタの間のネットワーク経路を見直さなければなりません。 発生しているsyslogメッセージはネットワークリンクのいずれも圧倒するべきではありません。
7. IANA Considerations
7. IANA問題
The syslog protocol has been assigned UDP port 514. This port assignment will be maintained by IANA exclusively for this protocol.
UDPポート514はsyslogプロトコルに割り当てられました。 このポート課題は排他的にこのプロトコルのためにIANAによって維持されるでしょう。
The syslog protocol provides for the definition of named attributes to indicate the Severity of each message and the Facility that generated the message as described in Section 4. The name space identifiers for these attributes are defined as numbers. The protocol does not define the specific assignment of the name space for these numbers; the application developer or system vendor is allowed to define the attribute, its semantics, and the associated numbers. This name space will not be controlled to prevent collisions as systems are expected to use the same attributes, semantics and associated numbers to describe events that are deemed similar even between heterogeneous devices.
syslogプロトコルは、セクション4で説明されるようにそれぞれのメッセージのSeverityとメッセージを生成したFacilityを示すために命名された属性の定義に備えます。 これらの属性のための名前スペース識別子は数と定義されます。 プロトコルはこれらの数のためにスペースという名前の特定の課題を定義しません。 アプリケーション開発者かシステムベンダーが属性、意味論、および近接数を定義できます。 この名前スペースは、システムが異種のデバイスの間でさえ同様であると考えられるイベントについて説明するのに同じ属性、意味論、および近接数を使用すると予想されるとき衝突を防ぐために制御されないでしょう。
8. Conclusion and Other Efforts
8. 結論と他の取り組み
The syslog protocol may be effectively used to transport event notification messages across a network. In all cases, it is important that the syslog message receiver embody the principle of "be liberal in what you accept". It is highly recommended that the network operators who choose to use this understand the characteristics of the protocol and its security implications.
事実上、syslogプロトコルは、ネットワークの向こう側にイベント通知メッセージを輸送するのに使用されるかもしれません。 すべての場合では、syslogメッセージ受信機が「あなたが受け入れるものには自由主義者がいる」原則を具体化するのは、重要です。 これを使用するのを選ぶネットワーク・オペレータがプロトコルの特性とそのセキュリティ含意を理解しているのは、非常にお勧めです。
There have been attempts in the past to standardize the format of the syslog message. The most notable attempt culminated in a BOF at the Fortieth Internet Engineering Task Force meeting in 1997. This was the Universal Logging Protocol (ulp) BOF and the minutes of their meeting are on-line at the IETF Proceedings web site [14].
syslogメッセージの形式を標準化するために、過去の試みがありました。 最も注目に値する試みは1997年にFortiethインターネット・エンジニアリング・タスク・フォースのミーティングでBOFに終わりました。 これはUniversal Loggingプロトコル(ulp)BOFでした、そして、彼らのミーティングの議事録はIETF Proceedingsウェブサイト[14]でオンラインです。
Lonvick Informational [Page 25] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[25ページ]RFC3164BSD syslogプロトコル2001年8月
Many good thoughts came from that effort and interested implementers may want to find some of the notes or papers produced from that effort.
多くの良い考えがその取り組みから来ました、そして、関心があるimplementersはその取り組みから製作された注意か書類のいくつかを見つけたがっているかもしれません。
At the time of this writing, efforts are underway to allow the usage of international character sets in applications that have been traditionally thought of as being text-only. The HOSTNAME and TIMESTAMP fields described above are representative of this. Also, the entire CONTENT field has traditionally been printing characters and spaces in the code set known as US-ASCII. It is hoped that the proponents of these internationalization efforts will find a suitable way to allow the use of international character sets within syslog messages without being disruptive. It should also be hoped that implementers will allow for the future acceptance of additional code sets and that they may make appropriate plans. Again, it must be cautioned that the simplicity of the existing system has been a tremendous value to its acceptance. Anything that lessens that simplicity may diminish that value.
この書くこと時点で、取り組みは、テキストのみであるとして伝統的に考えられたアプリケーションに国際的な人物セットの使用法を許容するために進行中です。 分野が上で説明したHOSTNAMEとTIMESTAMPはこれを代表しています。 また、全体のCONTENT分野は、伝統的に米国のASCIIとして知られているコードセットの表示文字と空間です。 これらの国際化取り組みの提案者がsyslogメッセージの中で破壊的でなくて国際的な人物セットの使用を許す適当な方法を見つけることが望まれています。 また、implementersが追加コードセットの今後の承認を考慮して、適切なプランを立てることが望まれるべきです。 一方、既存のシステムの簡単さが承認への物凄い値であると警告しなければなりません。 その簡単さを少なくする何でもその値を減少させるかもしれません。
Acknowledgements
承認
The following people provided content feedback during the writing of this document:
以下の人々はこのドキュメントの書くことの間、満足しているフィードバックを提供しました:
Jon Knight <J.P.Knight@lboro.ac.uk>
Magosanyi Arpad <mag@bunuel.tii.matav.hu>
Balazs Scheidler <bazsi@balabit.hu>
Jon Callas <jon@counterpane.com>
Eliot Lear <lear@cisco.com>
Petter Reinholdtsen <pere@hungry.com>
Darren Reed <darrenr@reed.wattle.id.au>
Alfonso De Gregorio <dira@speedcom.it>
Eric Allman <eric@sendmail.com>
Andrew Ross <andrew@kiwi-enterprises.com>
George Maslyar <george.maslyar@primark.com>
Albert Mietus <albert@ons-huis.net>
Russ Allbery <rra@stanford.edu>
Titus D. Winters <titus@cs.hmc.edu>
Edwin P. Boon <Edwin.Boon@consul.com>
Jeroen M. Mostert <Jeroen.Mostert@consul.com>
Jon Knight <J.P.Knight@lboro.ac.uk> Magosanyi Arpad <mag@bunuel.tii.matav.hu> Balazs Scheidler <bazsi@balabit.hu> Jon Callas <jon@counterpane.com> Eliot Lear <lear@cisco.com> Petter Reinholdtsen <pere@hungry.com> Darren Reed <darrenr@reed.wattle.id.au> Alfonso De Gregorio <dira@speedcom.it> Eric Allman <eric@sendmail.com> Andrew Ross <andrew@kiwi-enterprises.com> George Maslyar <george.maslyar@primark.com> Albert Mietus <albert@ons-huis.net> Russ Allbery <rra@stanford.edu> Titus D. Winters <titus@cs.hmc.edu> Edwin P. Boon <Edwin.Boon@consul.com> Jeroen M. Mostert <Jeroen.Mostert@consul.com>
Eric Allman is the original inventor and author of the syslog daemon and protocol. The author of this memo and the community at large would like to express their appreciation for this work and for the usefulness that it has provided over the years.
エリック・オールマンは、syslogデーモンとプロトコルのオリジナルの発明者と作者です。 このメモの作者と一般社会はこの仕事と有用性に対するそれが数年間提供している彼らの感謝を申し上げたがっています。
Lonvick Informational [Page 26] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[26ページ]RFC3164BSD syslogプロトコル2001年8月
A large amount of additional information about this de-facto standard operating system feature may usually be found in the syslog.conf file as well as in the man pages for syslog.conf, syslog, syslogd, and logger, of many Unix and Unix-like devices.
通常、このデファクトの標準のオペレーティングシステム機能に関する多量の追加情報はsyslog.confファイルの中と、そして、多くのUnixの、そして、Unixのようなデバイスのsyslog.conf、syslog、syslogd、およびきこりのための男性ページで見つけられるかもしれません。
References
参照
1 Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
1 ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
2 Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
2 クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
3 USA Standard Code for Information Interchange, USASI X3.4-1968
3 米国の標準の情報交換用符号、USASI X3.4-1968
4 Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13,
RFC 1034, November 1987.
4Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
5 Mockapetris, P., "Domain names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
5Mockapetris、P.、「ドメイン名--、実装とSpecification、」、STD13、RFC1035、11月1987日
6 Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture",
RFC 2373, July 1998.
6 HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
7 Data elements and interchange formats - Information exchange -
Representation of dates and times, International Organization for
Standardization, Reference number ISO 8601 : 1988 (E), 1988
7つのデータ要素と置き換え形式--情報交換--日付と回、国際標準化機構の代理、Reference No.ISO8601: 1988(E)、1988
8 Stowe, M., et al, "Chemical Mimicry: Bolas Spiders Emit Components
of Moth Prey Species Sex Pheromones", Science, 1987
8 ストウ、M.、他、「化学物真似:」 「ボーラクモはガ犠牲種のセックスフェロモンのコンポーネントを放つ」科学、1987
9 Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
9 ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
10 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June
1995.
10 ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
11 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
11 デアリングとS.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月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.
12 ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
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
13 シスコシステムズの製品セキュリティインシデント応答チーム(PSIRT)、「通知をさばいてください」 「コクチマスIOS(r) Syslogはダウンする」1999年1月11日 http://www.cisco.com/warp/public/707/advisory.html
Lonvick Informational [Page 27] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[27ページ]RFC3164BSD syslogプロトコル2001年8月
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
14 ウォーカー、D.、IETF事務局、「第40インターネット・エンジニアリング・タスク・フォースの議事、ワシントン(DC)(米国)1997年12月8- 12の http://www.ietf.org/proceedings/97dec/index.html 」
Author's Address
作者のアドレス
Chris Lonvick Cisco Systems 12515 Research Blvd. Austin, TX, USA
クリスLonvickシスコシステムズ12515研究Blvd. オースチン(テキサス)(米国)
Phone: +1.512.378.1182 EMail: clonvick@cisco.com
以下に電話をしてください。 +1.512 .378 .1182 メール: clonvick@cisco.com
Lonvick Informational [Page 28] RFC 3164 The BSD syslog Protocol August 2001
Lonvick Informational[28ページ]RFC3164BSD syslogプロトコル2001年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Lonvick Informational [Page 29]
Lonvick情報です。[29ページ]
一覧
スポンサーリンク
