Network Working Group C. Lonvick
Request for Comments: 3164 Cisco Systems
Category: Informational August 2001
The BSD syslog Protocol
Status of this 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.
著作権（C）インターネット協会（2001）。全著作権所有。
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プロトコルの観測された動作について説明します。このプロトコルは、何年もの間、ネットワークを介したイベント通知メッセージを送信するために使用されてきました。このプロトコルは、もともとカリフォルニア大学バークレー校のソフトウェア配布（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
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
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 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のプロセスは、広く多くのオペレーティングシステムに受け入れられてきたようなシステムの一つでした。運用スタッフは、デバイス上で実行中のプロセスから送信されたメッセージの送信先を設定する機能を持っているので、柔軟性は、このプロセスに設計されました。一次元では、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サーバとして知られている - その最も単純な用語では、syslogプロトコルは、イベント・メッセージのコレクタにIPネットワークを介してイベント通知メッセージを送信するためにマシンを許可するトランスポートを提供します。各プロセス、アプリケーション、およびオペレーティングシステムが多少独立に書かれたので、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プロトコルおよびプロセスの基本的な教義の一つは、そのシンプルさです。何厳しい調整は送信機と受信機の間で必要とされません。実際には、syslogメッセージの送信は、受信機が設定されることなく、デバイス上で開始することができる、あるいは、実際に物理的に存在します。逆に、多くのデバイスは、最も可能性の明示的な設定や定義せずにメッセージを受信することができるようになります。このシンプルさが大幅シスログの受け入れと展開を支援しています。
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 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.
オペレーティング・システム、プロセスとアプリケーションの作家は、任意のメッセージを生成する状況を完全に制御を持っていました。いくつかのケースでは、メッセージは、ステータスを与えるために生成されます。これらは、プログラムの起動または終了として一定の周期で、またはいくつかの他の間隔のいずれかであることができます。他の場合には、メッセージが原因満たされる条件のセットを生成することができます。そのような場合、ステータスメッセージまたはいくつかのタイプの警報を含むメッセージのいずれかを生成することができます。これは、オペレーティング・システム、プロセスとアプリケーションの作家は、いくつかの広いカテゴリーのいずれかに自分のメッセージを定量化するであろうと考えられました。これらの広いカテゴリーは、一般に、メッセージの重大度の表示と共に、それらを生成した施設から成ります。これは、後で閲覧するためにファイルにステータスや情報メッセージを配置する機能を持ちながら、運用スタッフは、選択的にメッセージをフィルタリングでき、迅速に、より重要な、時間に敏感な通知を提示するようにしました。メッセージを表示したり、保存するための他のオプションも同様に存在すると見られています。
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のコレクタに送信したのプロセスは、一般に、ファシリティメッセージと重大度レベルが転送されるかを決定し、次に遠隔受信機を定義から成ります。たとえば、管理者は、メール機能によって生成されるすべてのメッセージは、ある特定のイベントメッセージのコレクタに転送することができます。その後、管理者は、すべてのカーネルはまた、第三の受信機に送信されたカーネルから批判的に深刻なメッセージを持つ、同時に、一方で別の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 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.
任意のデバイス上の任意のプロセスは、イベント・メッセージを生成する可能性があることを前提としなければなりません。例えば、プリンタ、ルータ、ハブ、スイッチ、ディスクレスワークステーション - これは、任意のローカルストレージを持たないマシン上のプロセスを含むことができます。その場合、記録され、うまくいけば、オペレータが見ることができるように、イベント・メッセージは、コレクタに輸送されることが必須であってもよいです。
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.
非常に一般的なルールとして、比較的少数のコレクターにメッセージを送信し、通常は多くのデバイスがあります。このファンインプロセスは、比較的少数のリポジトリにメッセージを集約するには、管理者ができます。
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.
シスログは、基礎となるトランスポート層機構として[1]ユーザデータグラムプロトコル（UDP）を使用します。 syslogに割り当てられたUDPポートは送信元ポートは、メッセージが送信者のsyslogプロセスからのものであることを示すために、514をすることが推奨されますが、場合によっては、有効なsyslogメッセージがから来ているところが見られている514です送信者が514以外の送信元ポートを使用する場合514以外のソースポートと送信者は、それが推奨され、後続のメッセージが単一の一貫したポートからのものであることを良い形であると考えられています。
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.
それは、メッセージを送信するときに、任意のデバイスまたはリレーは、「送信者」として認識されるようになります。
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.
送信者は、複数の受信者に同じメッセージを送信するように構成されてもよいです。
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.
リレーは、独自のメッセージを生成し、その後のリレーやコレクターにそれらを送ることができます。その場合、デバイスとして機能しています。また、これらのデバイスは、以下の図のリレーとして指定されます。
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.
最初のものは最も普及していることが知られているが図1に示されている次のアーキテクチャが有効です。これらの例の他の構成も許容されています。上述したように、次の図のリレーでは、彼らが内部で生成したメッセージに沿って通過するとともに受信メッセージの全部または一部に沿って通過してもよいです。
+------+ +---------+
|Device|---->----|Collector|
+------+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->----|Collector|
+------+ +-----+ +---------+
+------+ +-----+ +-----+ +---------+
|Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+------+ +-----+ +-----+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->----|Collector|
| |-\ +-----+ +---------+
+------+ \
\ +-----+ +---------+
\-->--|Relay|---->----|Collector|
+-----+ +---------+
+------+ +---------+
|Device|---->----|Collector|
| |-\ +---------+
+------+ \
\ +-----+ +---------+
\-->--|Relay|---->----|Collector|
+-----+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->-------|Collector|
| |-\ +-----+ /--| |
+------+ \ / +---------+
\ +-----+ /
\-->--|Relay|-->--/
+-----+
Diagram 1. Some Possible syslog Architectures
図1.いくつかの可能性のsyslogアーキテクチャ
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 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.
514のUDP宛先ポートを有する任意のIPパケットのペイロードは、syslogメッセージとして扱わなければなりません。元の送信Syslogメッセージのフォーマットと中継されたメッセージのフォーマット間の違いがあるかもしれません。本質的には、この文書で指定された形式でSyslogメッセージを送信するために推奨されるが、必須ではありません。リレーは、そのフォーマットに付着し、メッセージを認識することができる場合、それはそれに変更を加えることなく、メッセージを再送信しなければなりません。リレーは、メッセージを受信するが、フォーマットの適切な実装を見分けることができない場合は、それを再送信する前にそのフォーマットに適合するようにメッセージを変更する必要があります。 4.1節は、syslogメッセージのための推奨フォーマットを記述します。 4.2節は、最初に送信されたメッセージのための要件を説明し、4.3節では、中継されたメッセージのための要件について説明します。
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.
ワイヤ上で見Syslogメッセージの完全な形式は、3つの識別可能な部分があります。最初の部分は、PRIと呼ばれ、第二の部分は、ヘッダであり、そして第三の部分はMSGです。パケットの全長は1024バイト以下でなければなりません。無内容でのsyslogパケットを送信することは価値がないと送信されませんが、Syslogメッセージの最低の長さはありません。
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").
PRIの部分が3つ、4つまたは5つの文字を持たなければならないし、最初と最後の文字として角括弧でバインドされます。 PRI部が始まる先頭の「<」が続く数、続いて（「小なり」の文字）、「>」（「より大」の文字）。 RFC 2234に記載されているようにこの部分で使用されるコードセットは8ビットのフィールドで7ビットのASCIIでなければなりません[2]。これらは、[3]「情報交換用米国標準コード」で定義されたASCIIコードです。これでは、「<」の文字は、拡張バッカス・ナウアフォーム（ABNF）％のD60として定義され、「>」文字がABNF値％のD62を有しています。これらの角括弧内に含まれる番号は、優先値として知られており、後述のように施設及び重症度の両方を表しています。プライオリティ値は（「9」の場合）％のD57を介して（「0」の場合）％のD48の値を使用して一、二、または三進整数（ABNF桁）から成ります。
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
0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages (note 1)
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)
syslogdの6ラインプリンタサブシステム7ネットワークニュースサブシステム8 UUCPサブシステム9クロックデーモン（注2）10セキュリティ/認証メッセージ（注1）11 FTPデーモン12 NTPサブシステム13ログ監査（注1）14ログアラート（によって内部的に生成5件のメッセージ注1）15クロック・デーモン（注2）16ローカル使用0（LOCAL0）17ローカル使用1（LOCAL1）18ローカル使用2（LOCAL2）19ローカル使用3（LOCAL3）20ローカル使用4（LOCAL4）21ローカル使用5（ local5）22ローカル使用6（local6）23ローカル使用7（local7を）
Table 1. syslog Message Facilities
表1のsyslogメッセージの施設
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.
注1 - 様々なオペレーティング・システムは、セキュリティ/認証、監査、および類似すると思われる警告メッセージのための施設4、10、13及び14を利用することが見出されています。注2 - 様々なオペレーティング・システムは、クロック（クーロン/時）メッセージのための設備9及び15の両方を利用することが見出されています。
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
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緊急：システムが使用不可能1回の警告である：臨界条件3エラー：エラーの状態4警告：警告状態5注意事項：正常だが重大な状態6情報：情報メッセージ7デバッグ：デバッグレベルのメッセージアクションがすぐに2クリティカルを取らなければなりません
Table 2. syslog Message Severities
表2のsyslogメッセージの重大度
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.
優先順位値は、最初の8により施設数を乗算した後、重要度の数値を加算することにより算出されます。たとえば、注意の重症度、緊急（重要度= 0）の重症度とカーネルメッセージ（ファシリティ= 0）は、また、0の優先順位の値を有するであろう「局所使用4」メッセージ（ファシリティ= 20）（重大度= 5）、これらの値はそれぞれ<0>および<165>のように角括弧の間に置かれることになる、シスログメッセージのPRI部分に165の優先度値を有するであろう。唯一の時間は、「0」の値は、「<」、「0」の優先順位値のためであるに従います。それ以外の場合は、先頭の「0」を使用してはいけません。
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).
ヘッダ部は、タイムスタンプと、デバイスのホスト名またはIPアドレスの表示を含みます。 syslogのパケットのヘッダ部分には、目に見える（印刷）文字を含まなければなりません。使用されるコードセットはまた、PRI部分に使用されるような8ビットのフィールドでは7ビットのASCIIでなければなりません。このコード・セットでは、唯一の可能な文字は、ABNF VCHAR値（％のd33-126）とスペース（SP値％の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.
HEADERはTIMESTAMPとHOSTNAMEと呼ばれる2つのフィールドが含まれています。 PRI部と、単一の空白文字からすぐ後ろに続くTIMESTAMPは「>」TIMESTAMPとHOSTNAMEフィールドのそれぞれに従わなければなりません。それは自分自身を知っているようHOSTNAMEは、ホスト名が含まれます。それは、ホスト名を持っていない場合、それは自身のIPアドレスが含まれています。デバイスに複数のIPアドレスがある場合、通常、メッセージが送信されたIPアドレスを使用するように見られています。この動作に代わるものも見られました。その場合には、デバイスに関係なくメッセージが送信されたインターフェースの単一のソースIPアドレスを使用してすべてのメッセージを送信するように構成されてもよいです。これは、デバイスから送信されたすべてのメッセージに対して単一の一貫性のHOSTNAMEを提供します。
The TIMESTAMP field is the local time and is in the format of "Mmm dd hh:mm:ss" (without the quote marks) where:
TIMESTAMPフィールドは、現地時間であるとのフォーマットである「うーんHHをddは：MM：SS」（引用符なし）ここで、
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
月、2月、月、4月、月、6月、7月、8月、9月、10月、11月、12月
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は月の日です。月の日が10未満であれば、それはスペースと、その後数として表現されなければなりません。例えば、8月の7日目には、「G」と「7」の間に2つのスペースで、「8月7日」と表現されます。
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のは現地時間です。時間（HH）は、24時間形式で表されています。有効なエントリは、00と23の間に含まれています。分（MM）及び第二（SS）のエントリは、00と59包括の間です。
A single space character MUST follow the TIMESTAMP field.
単一のスペース文字はTIMESTAMPフィールドに従わなければなりません。
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.
HOSTNAMEフィールドは、ホスト名のみ、IPv4アドレス、またはメッセージの発信元のIPv6アドレスが含まれています。好適な値は、ホスト名です。ホスト名が使用されている場合、ホスト名フィールドは、STD 13 [4]で指定されるようにデバイスのホスト名を含まなければなりません。任意の埋め込みスペースを含んではならないことに留意すべきです。ドメイン名は、HOSTNAMEフィールドに含んではいけません。 IPv4アドレスを使用する場合STD 13で使用されるように、[5]、ドット十進表記として示されなければなりません。 IPv6アドレスを使用する場合は、RFC 2373で使用される任意の有効な表現は、[6]は使用されるかもしれません。単一の空白文字もHOSTNAMEフィールドに従わなければなりません。
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.
MSG部分は、syslogパケットの残りの部分を記入します。これは通常、メッセージ、およびそのメッセージのテキストを生成したプロセスのいくつかの追加情報が含まれています。この部分への終わりの区切り文字はありません。 syslogパケットのMSGの一部が見える（印刷）文字を含まなければなりません。コード伝統的に設定し、最も頻繁に使用されるも、PRIとヘッダ部に使用されるような8ビットのフィールドでは7ビットのASCIIとなっています。このコード・セットでは、唯一の可能な文字は、ABNF VCHAR値（％のd33-126）とスペース（SP値％のD32）です。しかし、MSG内で使用されるコードセットの兆候が必要とされない、またそれが期待されています。他のコードセットは、MSGで使用される文字が排他的に上記と同様の可視文字やスペースである限り、使用されるかもしれません。 MSG部に使用されるコードセットの選択は、意図された受信機の考えでなされるべきです。受信者によって閲覧または理解することができないコードセットの文字を含むメッセージは、それを見て、オペレータまたは管理者に価値のない情報を得ないであろう。
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 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.
MSG部分は、タグフィールドとCONTENTフィールドとして知られている2つのフィールドがあります。 TAGフィールドの値は、メッセージを生成したプログラムまたはプロセスの名前であろう。 CONTENTは、メッセージの詳細が含まれています。これは、伝統的にイベントのいくつかの詳細な情報を提供する自由形式のメッセージとなっています。 TAGが32文字を超えることはできませんABNF英数字の文字列です。任意の英数字以外の文字は、タグ・フィールドを終了し、CONTENTフィールドの開始文字と見なされます。 、またはスペース文字：最も一般的には、タグフィールドの結論を意味CONTENTフィールドの最初の文字は左括弧文字（「[」）、コロン（「」）であると見られています。これは、5.3節で詳しく説明されています。
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.
もともとは、デバイスから送信されたとしてのsyslogパケットの内容には、設定された要件はありません。 UDPポート514宛てのすべてのIPパケットのペイロードが有効なのsyslogメッセージであることを考えなければなりませんことを、ここで改めて強調されなければなりません。 PRI、HEADERとMSG - - これは、受信者によって読みやすさを向上させ、メッセージを変更するためにリレーする必要がなくなるように、しかし、syslogのパケットは4.1節で説明した部分のすべてを持っていることが推奨されます。
For implementers that do choose to construct syslog messages with the RECOMMENDED format, the following guidance is offered.
推奨される形式でsyslogメッセージを構築することを選択しない実装の場合は、以下のガイダンスが提供されています。
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.
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.
最初に形成されたメッセージは、タグ値を有する場合、そのメッセージを生成したプログラムまたはプロセスの名前であろう。
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が含まれていないと仮定しなければなりません。第三、第四、または第五文字が直角ブラケット文字でない場合、リレーは再びPRIは、元のメッセージに含まれていなかったと仮定しなければなりません。リレーは、有効なPRI部分を見つけない場合、それはヘッダ部に有効な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
Table 3. Cases of Received syslog Messages
受信したsyslogメッセージの表3ケース
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を見つけない場合、それはその内部構成をチェックします。リレーは、その優先順位値に基づいたsyslogパケットを転送するように設定する必要があり。リレーは、受信したパケットを転送するように設定されていることを見つけた場合、それはパケットを変更することなく行う必要があります。ポイントをもう一度強調するために、最初に送信されたsyslogメッセージは、セクション4.1で説明したフォーマットに準拠することが推奨されるのはこのためです。
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に見ることができます。
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が見つからない場合、それはTIMESTAMPとPRI部分の閉鎖角括弧の直後に空白文字を追加しなければなりません。それは、さらに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部の後、それは、パケットの全長が依然として1024バイト以下であることを確認しなければなりません。パケットが1024のバイトを超えて拡張されている場合、リレーは1024バイトにパケットを切り詰めなければなりません。これは、元のパケットの終わりからの重要な情報の損失を引き起こす可能性があります。それは、最初に生成されたsyslogパケットのPRIとHEADER部分は、セクション4.1に記載の値とフィールドが含まれていることが推奨されるのはこのためです。
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せず、又は不能PRIとシスログメッセージを受信した場合、セクション4.3.2に記載したように、それは13の優先値、並びにTIMESTAMPとPRIを挿入する必要があります。 4.3.2項で説明したようにリレーもHOSTNAMEを挿入する必要があります。受信したパケットの内容全体が中継MSGおよび添付のコンテンツとして扱われます。
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.
識別不能PRIの例は、二重引用符なしで、「<00>」になります。これらは、メッセージの最初の4つの文字があることかもしれません。リレーは、「<00>」の最初の4つの文字でSyslogメッセージを受信した場合、この例を続行するには、それはその設定を協議します。別のリレーまたはコレクタ13の優先順位値とsyslogメッセージを転送するように構成されている場合、上記のように、それはパケットを変更する必要があります。 HOSTNAMEの推奨挿入含めて、これを行うの詳細は、以下のとおりです。
Originally received message <00>... Relayed message <13>TIMESTAMP HOSTNAME <00>...
元々受信されたメッセージ<00> ...中継されたメッセージ<13> TIMESTAMPホスト名<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部の後、それは、パケットの全長が依然として1024バイト以下であることを確認しなければなりません。パケットが1024のバイトを超えて拡張されている場合、リレーは1024バイトにパケットを切り詰めなければなりません。これは、元のパケットの終わりからの重要な情報の損失を引き起こす可能性があります。それは、最初に生成されたsyslogパケットのPRIとHEADER部分は、セクション4.1に記載の値とフィールドが含まれていることが推奨されるのはこのためです。
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メッセージ内の追加情報を含めるために時間をかけて約来ました。はっきりこれらの項目が義務付けされていないことを記載しなければならないが、完全性のため、実装によって考慮することができる者と受信者に彼らの起源と自然のいくつかの追加の手がかりを与えます。
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を終了スペースを追従するより明示的なタイムスタンプを含んでいることが確認されています。これは、フィールドの順序およびフォーマットの本来の意図と一致しません。実装者は、送信されたメッセージ内の複数の特定の日付とタイムスタンプが含まれているしたい場合は、CONTENTフィールド内でなければなりません。彼らは、より明示的な日付と時刻の情報を含めたい場合は実装者は、[7]、日付と時刻の形式ISO 8601を利用することを望むかもしれません。
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.
長期保存のために、この欲求に対処するための追加の方法が提案されており、一部は正常に実装されています。そのような方法の一つは、ネットワーク管理者は、それらのコレクタに保存されたメッセージを修正することを選択するかもしれないということです。彼らは、格納された各レコードに、年、およびその他の情報を追加するために簡単なスクリプトを実行することができます。あるいは、スクリプトはネットワーク管理者のニーズに、より適切なフォーマットで格納された時間に取って代わることができます。別の方法としては、現在の年が含まれているファイルにレコードを挿入することでした。その後、協会が、その有益な記録の近くに他のすべてのレコードは、その同じ年に受信されている必要があります。これらはいずれも、しかし、各レコードに正しいタイムゾーンを関連付けるの問題を解決します。
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.
容易にメッセージを発信したデバイスを識別するために、その完全修飾ドメイン名（FQDN）とCONTENTフィールド内のIPアドレスを含めることをお勧めかもしれません。伝統的に、しかし、唯一のホスト名がHOSTNAMEフィールドに含まれています。
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」として知られている）プロセス名とプロセスIDです。プロセス名は、一般的にタグフィールドに表示されます。かなり頻繁に、追加情報がCONTENT欄の先頭に含まれています。 「TAG [PID]：」の形式 - 引用符なしで - 一般的です。左角括弧は、この場合、TAGフィールドを終了するために使用され、次いでCONTENTフィールドの最初の文字です。プロセスIDが重要でない場合は、中断されてもよいです。
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フィールドの最初の文字です。
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日夜09時14分15秒MYMACHINE SU： 'SUルート' DEV / / 8 PTS /上lonvickに失敗しました
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と呼ばれる装置から元のメッセージとして記録しました。これを受け、リレーは、ヘッダ部に適切にフォーマットされたPRI部分とTIMESTAMPフィールドが含まれているとして、それに沿って送信する前に変更を加えることはありません。この例では、タグ値は、プロセス「SU」です。コロンは、タグフィールドを終了し、CONTENTフィールドの最初の文字でいます。この場合は、プロセスID（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.
これは有効なメッセージであるが、それは非常に有用な情報をほとんど持っています。このメッセージは、任意の識別可能な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日夜五時32分18秒10.0.0.99 BFGを使用してください！
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部のコンテンツ部分として扱われてきました。まず、有効なPRI部は、タイムスタンプがヘッダ部にホスト名に沿って追加された、13のデフォルトの優先度値を使用して追加されています。後続のリレーは、このメッセージにさらに変更をすることはありません。月の日を日付（この場合は5）で一桁はタイムスタンプ形式でスペースで10未満で先行されているので、TIMESTAMPの月次の二つのスペースがあることが、この例では注目すべきです月の前日。また、リレーは、HOSTNAMEフィールドにデバイスのIPv4アドレスを挿入しているので、メッセージを送信するデバイスのホスト名の知識がないように見えます。
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日午前五時34分00秒CST 1987 MYMACHINEのMYPROC [10]：%%これは、DO-ナットを作るための時間です。 %%成分：ミキサー= OK、Jelly_Injector = OK、Frier = 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".
このメッセージは、お知らせの重症度と局所的に定義された施設（LOCAL4）から来たことを示すプライオリティ値を持つ有効なPRIの一部を持っています。ヘッダ部分は、メッセージに適切なTIMESTAMPフィールドがあります。リレーは、それを送信する前にこのメッセージを変更しません。しかし、HOSTNAMEおよびTAGフィールドは、セクション4でHOSTNAMEフィールドが「CST」と解釈されるだろう定義と一致していないとMSG部の先頭には「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.
なお、本実施例のコンテンツに含まれる情報は、データを遠隔測定されていない、またそれは、監視制御やデータ取得情報であることに留意すべきです。これによってドキュメントのセクション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分01秒TZ-6 scapegoat.dmz.example.org 10.1.2.3 schedの[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アドレスを決定することができるであろう。イベントの性質に関する情報は、しかし、限られています。イベントの指定の重症度に、プロセスが集まる以上の有益な何かを送ることができていない可能性があります。生成され、すべてでこのメッセージを送信していることが幸運であったかもしれません。
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.
この例では、明らかにデバイスから元のメッセージです。ヘッダ部の最初のフィールドは、セクション4.1.2で定義されたフォーマットのタイムスタンプではないので、リレーによって修正されなければなりません。リレーは、TIMESTAMPを追加し、次のようにホスト名を追加すべきであり、新しいパケットのCONTENTフィールドとして元のパケットからPRI部分の後に全体受信したパケットを処理します。 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!
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.
匂いは、任意の承認を必要としないメッセージであるとみなすことができます。人々は悪臭を避ける傾向にあるが、彼らは良い食べ物と関連付ける匂いに描かれています。匂いや香りの受領の確認が必要とされず、実際、完全にいくつかの匂いを無視する裁量の高さかもしれません。一方、通常の台所から漂う雰囲気から単に料理の腕前を確認するためには良い礼儀と考えられています。同様に、様々な種が仲間を引き付けるために臭いを利用することが見出されています。蛾の一種は、お互いを見つけるために、この香りを使用しています。しかし、ナゲナワグモは、この種のメスの蛾の臭いを模倣することが判明しました。この香りはその後、仲間を見つけることを期待して、それに続く男性蛾を、引き付けます。彼らは香りの元に到着したときその代わり、彼らが食べられます[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プロセスの後続の構成は、イベント通知メッセージの配信の拡張であり、それは、ネットワークの同一の信頼性を示します。シスログの基本的なシンプルさのいくつかのセキュリティ上の影響はありかつ堅牢な配信を必要とする状況では、このプロトコルの適用性に関するいくつかの懸念があります。アナロジーの線に沿って、コンピュータのイベントメッセージが誤ってとしても悪意を持って、誤って送信されることがあります。この記事の執筆時点では、しかし、他のデバイスを消費するすべてのネットワークデバイスのいずれかの報告がされていません。
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パケットの受信は、問題を引き起こしました。シスログメッセージ受信機はメッセージの長さが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コレクターが誤動作してはなりません。彼らはそれを中継した場合、セクション4.3.3で説明したように彼らは、未フォーマットのコンテンツとして、これらのメッセージを扱わなければなりません。
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節全体で述べたようにまた、受信したメッセージには、メッセージで印刷可能なテキストが含まれている必要があります。
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の配信メカニズムは強く、メッセージの送信者とメッセージを関連付けることはありません。そのパケットの受信機は、パケットが別のデバイスから送信された場合は、メッセージが実際に報告された送信者から送られた、またはされたことを確認することができません。メッセージの受信機はヘッダ部にホスト名がIPパケットの送信元アドレスフィールドに含まれるIPアドレスの名前と一致していることを確認する必要はありませんことに留意されたいです。
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.
この動作の一つの可能な結果が誤って設定マシンを別のマシンとしての地位を表すコレクタにsyslogメッセージを送信することです。管理スタッフは、メッセージの送信者はずの状況を正確に受信したメッセージには反映されないことが混乱してしまうことがあります。管理者が容易に同じマシンとして自分自身を表す2台の以上のマシンが存在することを識別することができないかもしれません。
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.
また、ヘッダ部にHOSTNAMEフィールドを充填する場合は、ローカルな意味を持っている可能性があり、それが唯一の短命であってもよいことに留意する必要があります。デバイスはDHCPプールからIPアドレスを取得した場合には、識別子と実際のソースとの間の関連は常に成り立たないでしょう。 CONTENTで完全修飾ドメイン名を含めることは、管理者は、それが常にIPアドレスまたはそれは常にユニークなマシンに関連することができた場合に関連付けることができる場合は、各メッセージの送信元を特定する最善の機会を与えることができます。
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メッセージを生成することがあります。一例として、攻撃者は、出口の通知を生成することができるマシン上で重要なプロセスを停止することができます。攻撃者は、その後、プロセスが再開されていた偽造通知を生成してもよいです。システム管理者は、その誤った情報を受け入れ、プロセスが実際に再起動されたことを確認しない場合があります。
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のプロセスやプロトコルが注文した配信を保証しません。このセクションでは、このことから発生する可能性のある問題のいくつかを詳しく説明します。
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 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.
syslogの記録は通常、それらが受信された順序で（、ファイルに配置されたコンソールに表示、など）を提示されています。これは、それらが生成された順序に従って、常にではありません。それらはIPネットワークを横切って輸送されると、受注のいくつかのアウトが予想されなければなりません。それが開始された前に、プロセスが停止したことを示すだろうとのメッセージを受信することができるので、これはいくつかの混乱につながる可能性があります。発信プロセスがタイムスタンプまたは送信前にメッセージのそれぞれの番号を付けた場合、これは幾分整流することができます。この中で、送信側デバイスは、信頼できるタイムソースを利用すべきです。ないすべてのデバイスが、時間の更新を受信することが可能であり、すべてのデバイスは、彼らのメッセージをタイムスタンプすることができていること、しかし、忘れてはなりません。
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に、統一されたイベントの番号付けの概念はありません。シングルデバイスは、コンテンツ内のシーケンス番号を含めることは自由ですが、それはほとんど複数のデバイス間で調整することはできません。このような場合には、複数のデバイスは、それぞれがメッセージ番号いずれかを送信していることを報告することができます。送信装置は、それらのメッセージに信頼できるソースからのタイムスタンプを利用する場合は、再度、これは多少修正することができます。指摘したように、しかし、単一のコレクタに単一のデバイスからもメッセージが順序から外れて受信されてもよいです。単一コレクタに自分のsyslogメッセージを送信するように設定複数のデバイスがある場合、この状況は悪化します。コレクタは、第一の装置からのメッセージは、第二のメッセージの前に生成された最初のにもかかわらず、他の装置からメッセージを受信するように、一つの装置からのメッセージを遅延させることができます。何のタイムスタンプや協調シーケンス番号が存在しない場合、メッセージは、実際のイベントのシーケンスの不正確な表示を与える可能性があり、それらが受信された順序で提示されてもよいです。
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つのコレクタに他の有益なメッセージ - -ORステータスメッセージを送信するためにデバイスのグループを設定することが可能です。さらに、メッセージは、同じコレクタ上の異なるファイルに送信することができます。メッセージはソースからのタイムスタンプが含まれていない場合、彼らが別の場所に保管されている場合は、メッセージを注文することは困難です。 1つのファイルにレコードが異なるファイル内のレコードの前または後に発生した場合、管理者が決定することができない場合があります。これは多少すべての宛先ファイルにタイムスタンプを持つマーキングメッセージを配置することによって軽減することができます。これらは、タイムスタンプをコーディネートしている場合は、個々のメッセージの受信の時間のいくつかの兆候があるでしょう。
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.
任意の配列の表示又はスタンプすることなく、メッセージを後の時間に記録し再生することができます。攻撃者は、機械の通常の活動を示す一連のメッセージを記録することができます。後で、その攻撃者は、ネットワークからそのマシンを削除して、コレクタにsyslogメッセージを再生します。でも、ヘッダ部にTIMESTAMPフィールドで、攻撃者がパケットを記録することができるし、単にそれらを再送信する前に、現在の時刻を反映するためにそれらを修正することができます。管理者は、受信したメッセージでは珍しいものを見つけないかもしれないし、その領収書は、誤って機械の正常な活動を示すことになります。
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であることから、一部のメッセージが失われる可能性があります。彼らはどちらかのネットワークの混雑によって破棄される可能性があり、あるいは、それらは悪意を持って傍受され、廃棄することができます。一つ以上のSyslogメッセージの低下の影響を決定することができません。メッセージは簡単なステータスの更新されている場合は、その非受信時は、どちらか気づいたことがない場合や、システムオペレータのために迷惑を引き起こす可能性があります。メッセージはより重大である一方、その後、管理者は、現像し、潜在的に深刻な問題に気づくかもしれません。メッセージはまた、傍受や不正な活動を隠蔽するための方法として、攻撃者によって破棄されることがあります。
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メッセージは、輸送中に破損してもよいし、攻撃者が悪意を持って、それらを変更することができます。損傷されるシスログメッセージを含むパケットの場合には、リンク層に、ならびに損傷を検出することができるIP [9]及びUDPプロトコルに組み込まれた様々なメカニズムが存在します。仲介ルータが破損したIPパケット[10]を破棄してもよいです。 UDPパケットへの損傷は静かにそれを破棄することができる受信UDPモジュールによって検出することができます。いずれの場合においても、メッセージの元の内容は、コレクタに配信されません。攻撃者は、syslogメッセージの送信者とコレクタとの間に配置されている場合はさらに、彼らはにトランジットの不正活動を隠すためにしながら、それらのメッセージを傍受し、変更することができるかもしれません。
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 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のアプリケーションはいずれも、輸送中のメッセージの機密性を提供するためのメカニズムを持っています。彼らは、ワイヤのオフパケットを盗聴している場合はクリアテキストのメッセージを渡すほとんどの場合、運用スタッフにとっての利点です。運用スタッフは、正しい問題を追跡するために、メッセージを読んで、ワイヤーを横切る他のパケットから見た他のイベントに関連付けることができるかもしれません。残念ながら、攻撃者はまた、syslogメッセージの人間が読めるコンテンツを観察することができるかもしれません。攻撃者は、その後、マシンを侵害またはその他の損傷を行うには、それらのメッセージから得られた知識を使用することができます。
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.
メッセージを作成するプロセスは、メッセージ優先順位値を使用することによって、イベントの重要性を意味することができるが、この値は、パケットの配信の重要性との間に明確な関連は存在しません。その一例として、2つのイベントメッセージを生成するアプリケーションを考えてみます。最初は、通常のステータスメッセージであるが、第2のプロセスに問題があることを示す重要なメッセージであってもよいです。この第2のメッセージは、イベントの重要度に関連付けられた適切に高い重大度値を有するであろう。事業者は、これらのメッセージの両方が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メッセージを受け入れるだろう。多くのデバイスは、通常のステータスメッセージを送信しているが、1は、重要なイベントメッセージを送信している場合は、他のメッセージを介して重要なメッセージの優先順位を決定するために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 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.
ケースバイケースで、デバイスのオペレータは、サービス識別子の品質の異なるレベルを関連付けるためにいくつかの方法を見つけることができます。一例として、オペレータがIPv4優先順位フィールド[9]で使用する特定の値を有する特定の優先度値を持つsyslogメッセージの間にいくつかのリンクを定義することを選択することができる、IPv6のトラフィッククラスオクテット[11]、または差別化サービスフィールド[12]。上記の例では、オペレータは、ネットワークを通過するように、高い信頼性、低遅延キューに問題があることを示すメッセージを関連付けて通常送達とステータスメッセージを関連付ける能力を有していてもよいです。これは、通常のステータスメッセージの前に基本的なメッセージの優先順位付けの影響を持っているでしょう。送信または受信された多くの近同時メッセージがある場合でも、このホップバイホップ優先順位付けと、このキューイングメカニズムは、まだ受信デバイスに送信装置にブロッキングラインのヘッド並びにバッファ枯渇につながる可能性があります。この動作は、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の受信機が原因近同時に受信される多数のメッセージにバッファの枯渇を患っている場合にも、受信側では、重要なメッセージが他のメッセージと一緒に無差別に滴下してもよいです。これらは、デバイスとその容量の問題であるが、プロトコルのセキュリティ上の問題はそれほど重要なメッセージにわたって比較的より重要なメッセージのない優先順位付けがないことです。
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]のための問題を引き起こすことが知られています。メッセージは本来の受信者に予定がない場合は、それらを見直したり、処理することができません。
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メッセージを中継するように構成されてもよいです。ある特定のケースでは、管理者は、彼が誤ってお互いに特定の優先度の値を持つメッセージを転送するために2つのリレーを構成していたことがわかりました。これらのマシンのどちらかがどちらかの受信またはメッセージの種類を生成するとき、それは他のリレーにそれを転送します。そのリレーは、順番に、それをバック転送します。このサイクルが介在するネットワークにだけでなく、二つのデバイス上の処理の可用性への劣化を引き起こすました。ネットワーク管理者は、このような死のスパイラルを起こさないように注意する必要があります。
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メッセージは、ネットワークのリンクのいずれかを圧倒べきではありません。
The syslog protocol has been assigned UDP port 514. This port assignment will be maintained by IANA exclusively for this protocol.
syslogプロトコルは、このポート割り当てが排他的にこのプロトコルのためにIANAによって維持されるUDPポート514が割り当てられています。
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節で説明したように、これらの属性の名前空間識別子が数字として定義されているメッセージを生成したファシリティを示すために命名された属性の定義を提供します。プロトコルは、これらの数値のための名前空間の特定の割り当てを定義していません。アプリケーション開発者やシステムベンダーは、属性、その意味論、および関連する番号を定義することが許可されています。この名前空間は、システムがさえ異種デバイス間で類似したものとみなされるイベントを記述するために同じ属性、意味論と関連する番号を使用することが予想されるとして、衝突を防ぐために制御されることはありません。
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メッセージのフォーマットを標準化するために、過去の試みがなされてきました。最も注目すべき試みは、これは、ユニバーサル・ロギング・プロトコル（ULP）BOFだった1997年の第40インターネットエンジニアリングタスクフォース会議でBOFに結実し、その会議の議事録は、オンラインIETF議事ウェブサイト[14]です。
Many good thoughts came from that effort and interested implementers may want to find some of the notes or papers produced from that effort.
多くの良い考えはその努力から来て、興味のある実装者はその努力から生産ノートや書類の一部を検索することがあります。
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.
この記事の執筆時点では、努力は伝統的にテキストのみのものとして考えられている用途での国際文字セットの使用を許可するために進行中です。上述したホスト名とTIMESTAMPフィールドは、その代表的なものです。また、コンテンツ全体のフィールドは、伝統的にUS-ASCIIとして知られているコードセットの文字とスペースを印刷されています。これらの国際化の取り組みの支持者が破壊されることなく、syslogメッセージ内の国際文字セットの使用を許可するための適切な方法を見つけることが期待されます。また、実装者は、追加のコードセットの将来の受け入れを可能にすることが期待されなければならないと、彼らは適切な計画を立てること。ここでも、既存のシステムのシンプルさが、その受け入れに多大な値となっていることを警告しなければなりません。簡潔には、その値を減少させることが少なく何か。
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>
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デーモンとプロトコルのオリジナルの発明者と著者です。このメモの作者とコミュニティ大では、この作業のために、それは長年にわたって提供してきたことの有用性のために感謝の意を表したいと思います。
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.
この事実上の標準オペレーティングシステムの機能に関する追加情報の大規模な量は、通常、多くのUNIXおよびUNIXベースの、syslog.confファイルにだけでなく、syslog.confのは、Syslog、syslogdなどとロガーのmanページで見ることができます以下のようなデバイス。
References
リファレンス
1 Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
1ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
2 Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
2クロッカー、D.とP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
3 USA Standard Code for Information Interchange, USASI X3.4-1968
情報交換、USASI X3.4-1968のための3米国標準コード
4 Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
4 Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
5 Mockapetris, P., "Domain names - Implementation and Specification", STD 13, RFC 1035, November 1987.
5 Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
6 Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
6 HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、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つのデータ要素と交換フォーマット - 情報交換 - 日付と時刻の表現、国際標準化機構、参照番号ISO 8601：1988（E）、1988
8 Stowe, M., et al, "Chemical Mimicry: Bolas Spiders Emit Components of Moth Prey Species Sex Pheromones", Science, 1987
、サイエンス、1987：ら、「蛾餌種セックスフェロモンのボーラクモエミットコンポーネント化学擬態」8ストウ、M.、
9 Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
9ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
10 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
10ベイカー、F.、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
11 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
11デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
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分野）の定義"、RFC 2474、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）、 "フィールドのお知らせ：Cisco IOSの（R）Syslogのクラッシュ"、1999年1月11日http://www.cisco.com/warp/public/707/advisory.html
14 Walker, D., IETF Secretariat, "Proceedings of the Fortieth Internet Engineering Task Force, Washington, DC, USA, December 8- 12, 1997 http://www.ietf.org/proceedings/97dec/index.html
14ウォーカー、D.、IETF事務局、「第40インターネットエンジニアリングタスクフォース、ワシントンD.C.、USA、12月8 12、1997 http://www.ietf.org/proceedings/97dec/index.htmlの議事録
Author's Address
著者のアドレス
Chris Lonvick Cisco Systems 12515 Research Blvd. Austin, TX, USA
クリスLonvickシスコシステムズ12515リサーチブルバードオースティン、TX、USA
Phone: +1.512.378.1182 EMail: clonvick@cisco.com
電話：+1.512.378.1182電子メール：clonvick@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。