[要約] RFC 3164は、BSD Syslogプロトコルに関する仕様を定めたものであり、システムログの収集と転送を目的としています。このRFCは、ログメッセージのフォーマットやプロトコルの動作に関する指針を提供します。
Network Working Group C. Lonvick
Request for Comments: 3164 Cisco Systems
Category: Informational August 2001
The BSD syslog Protocol
BSD SYSLOGプロトコル
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.
Copyright（c）The Internet Society（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プロセスは、多くのオペレーティングシステムで広く受け入れられてきたそのようなシステムの1つでした。柔軟性がこのプロセスに設計されたため、オペレーションスタッフは、デバイスで実行されているプロセスから送信されるメッセージの宛先を構成する機能を備えています。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プロトコルは、最も単純化する用語では、マシンがイベントメッセージコレクター（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の受け入れと展開を大いに支援しました。
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.
オペレーティングシステム、プロセス、アプリケーションの作家は、メッセージを生成する状況を完全に制御しています。場合によっては、ステータスを与えるためにメッセージが生成されます。これらは、一定の期間、またはプログラムの呼び出しや出口などの他の間隔のいずれかになります。他の場合には、一連の条件が満たされているため、メッセージが生成される場合があります。そのような場合、ステータスメッセージまたは何らかのタイプのアラームを含むメッセージが生成される場合があります。オペレーティングシステム、プロセス、アプリケーションの作家は、メッセージをいくつかの幅広いカテゴリの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コレクターに送信するプロセスは一般に、どの施設メッセージとどの重大度レベルが転送されるかを決定し、リモートレシーバーを定義することで構成されています。たとえば、管理者は、メール機能によって生成されたすべてのメッセージを、特定のイベントメッセージコレクターに転送することを望む場合があります。その後、管理者は、すべてのカーネル生成メッセージを別のSyslogレシーバーに送信すると同時に、カーネルからの非常に深刻なメッセージも3番目のレシーバーに送信されるようにしたい場合があります。また、これらのメッセージをシステムコンソールに表示し、適切な人に郵送されると同時に、デバイスのローカルディスク上のファイルに送信されることも適切かもしれません。逆に、コンソールにのみ表示されるが、デバイスから保存または転送されていないローカルに定義されたプロセスからのメッセージがあることが適切かもしれません。いずれにせよ、これのルールはデバイスで生成する必要があります。管理者は、コレクターでどのタイプのメッセージが受信されるかを把握するため、それらの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.
Syslogは、ユーザーデータグラムプロトコル（UDP）[1]を基礎となる輸送層メカニズムとして使用します。Syslogに割り当てられたUDPポートは514です。ソースポートも514であり、メッセージが送信者のSyslogプロセスからのものであることを示すことをお勧めしますが、有効なsyslogメッセージがどこから来たのか見られる場合があります。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と呼ばれ、2番目の部分はヘッダー、3番目の部分は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パーツは、リード「<」（「 'less-less' '' noth 'Character）から始まり、その後に「>」（「より大きな」文字）が続きます。このパートで使用されているコードセットは、RFC 2234 [2]で説明されているように、8ビットフィールドの7ビットASCIIでなければなりません。これらは、「情報交換のための米国標準コード」で定義されているASCIIコードです[3]。これでは、「<」文字は、拡張されたバックスノーフォーム（ABNF）％D60として定義され、「>」文字にはABNF値％D62があります。これらの角度ブラケットに含まれる数は優先度値として知られており、以下に説明するように施設と重大度の両方を表します。優先順位は、％d48（「0」の場合）の値（「9」）の値（「0」）の値を使用して、1、2、または3つの小桁（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)
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-さまざまなオペレーティングシステムが、クロック（cron/at）メッセージに施設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アラート：アクションをすぐに実行する必要があります2クリティカル条件3エラー：エラー条件4警告：警告条件5通知：通常の重要な条件6情報メッセージ7デバッグ：デバッグレベルメッセージ
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です。= 5）優先度の値は165です。Syslogメッセージのpri部分では、これらの値は<0>と<165>の角度ブラケットの間にそれぞれ配置されます。「0」の値が「<」に従うのは、「0」の優先順位値のみです。それ以外の場合は、「0」の主要なsを使用してはなりません。
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.
ヘッダーには、タイムスタンプとホスト名と呼ばれる2つのフィールドが含まれています。タイムスタンプは、PRI部品からの後続の「>」をすぐに追跡し、単一のスペース文字は各タイムスタンプとホスト名のフィールドに従う必要があります。ホスト名には、それ自体が知っているように、ホスト名が含まれます。ホスト名がない場合は、独自のIPアドレスが含まれます。デバイスに複数のIPアドレスがある場合、通常、メッセージが送信されるIPアドレスを使用することがわかります。この動作に代わるものも見られます。その場合、メッセージが送信されるインターフェイスに関係なく、単一のソースIPアドレスを使用してすべてのメッセージを送信するようにデバイスを構成することができます。これにより、デバイスから送信されたすべてのメッセージに対して単一の一貫したホスト名が提供されます。
The TIMESTAMP field is the local time and is in the format of "Mmm dd hh:mm:ss" (without the quote marks) where:
タイムスタンプフィールドは現地時間であり、「MMM DD HH：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:
MMMは、大文字の最初のキャラクターと小文字の他の2人のキャラクターを持つ今年の英語の略語です。以下は唯一の許容値です。
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
1月、2月、3月、4月、5月、5月、6月、7月、8月、9月、10月、11月
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日は「8月7日」として表され、「G」と「7」の間に2つのスペースがあります。
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）および2番目（SS）エントリは00〜59の包括的です。
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.
ホスト名フィールドには、メッセージのオリジネーターのホスト名、IPv4アドレス、またはIPv6アドレスのみが含まれます。優先値はホスト名です。ホスト名を使用する場合、ホスト名フィールドには、STD 13 [4]で指定されているように、デバイスのホスト名を含める必要があります。これには埋め込まれたスペースが含まれていないことに注意する必要があります。ドメイン名をホスト名フィールドに含めてはなりません。IPv4アドレスを使用する場合、STD 13 [5]で使用される点線の小数表として表示する必要があります。IPv6アドレスが使用される場合、RFC 2373 [6]で使用される有効な表現を使用できます。単一のスペース文字もホスト名フィールドに従う必要があります。
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パーツには、タグフィールドとコンテンツフィールドと呼ばれる2つのフィールドがあります。タグフィールドの値は、メッセージを生成したプログラムまたはプロセスの名前になります。コンテンツにはメッセージの詳細が含まれています。これは伝統的に、イベントの詳細な情報を提供するフリーフォームメッセージでした。タグは、32文字を超えてはならないABNFの英数字の文字列です。非英数字の文字は、タグフィールドを終了し、コンテンツフィールドの開始文字であると想定されます。最も一般的には、タグフィールドの結論を意味するコンテンツフィールドの最初のキャラクターは、左の正方形のブラケット文字（ "["）、コロン文字（ "："）、またはスペース文字であると見られています。これについては、セクション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メッセージと見なされなければならないことをここで繰り返す必要があります。ただし、Syslogパケットには、セクション4.1 -PRI、ヘッダー、およびMSGで説明されているすべての部品があることが推奨されています。
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.
元々形成されたメッセージにホスト名フィールドがある場合、それ自体が知っているようにホスト名が含まれます。ホスト名がない場合は、独自の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が含まれていないと想定する必要があります。3番目、4番目、または5番目の文字が直角ブラケット文字ではない場合、リレーは再びPRIが元のメッセージに含まれていないと仮定する必要があります。リレーが有効なPRI部品を見つけた場合、ヘッダーパーツの有効なタイムスタンプを確認する必要があります。これらのルールから、受信したメッセージの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
表3.受信したsyslogメッセージのケース
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と有効なタイムスタンプを見つけた場合、その内部構成を確認します。リレーは、優先度の値に基づいてSyslogパケットを転送するように構成する必要があります。リレーが受信したパケットを転送するように構成されていることがわかった場合、パケットに変更を加えることなくそうする必要があります。ポイントをもう一度強調するために、このため、セクション4.1で説明されている形式に元々送信されたSyslogメッセージが付着することが推奨されます。
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.
ここで、メッセージ受信機はタイムスタンプフィールドの時間を検証する必要がないことに注意する必要があります。日付が正しく設定されていないデバイスには、有効なsyslogメッセージを送信する機能がまだあると仮定することができます。さらに、リレーは、ホスト名フィールドの値がメッセージを送信するデバイスのホスト名または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パケットに有効なタイムスタンプを見つけられない場合、PRI部品の閉鎖角度ブラケットの直後にタイムスタンプとスペース文字を追加する必要があります。さらに、タイムスタンプの後にホスト名とスペース文字を追加する必要があります。これらのフィールドについては、ここで説明し、セクション4.1.2で詳しく説明します。受信したパケットの残りの部分は、MSGのコンテンツフィールドとして扱われ、追加する必要があります。リレーには、メッセージを発信したデバイスからの発信プロセスを決定する方法がないため、タグ値を決定することはできず、含まれません。
The TIMESTAMP will be the current local time of the relay.
タイムスタンプは、リレーの現在の現地時間になります。
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.
ホスト名は、リレーで知られているように、デバイスの名前になります。名前を決定できない場合、デバイスの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およびヘッダー部分には、セクション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を使用してSyslogメッセージを受信した場合、セクション4.3.2で説明されているように、優先度の値を13のPRIとタイムスタンプを挿入する必要があります。リレーは、セクション4.3.2で説明されているようにホスト名を挿入する必要があります。受信したパケットの内容全体は、中継の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メッセージを別のリレーまたはコレクターに転送するように構成されている場合、上記のようにパケットを変更する必要があります。ホスト名の推奨挿入を含む、これを行う詳細は以下に示されています。
Originally received message
<00>...
Relayed message
<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パーツの後にタイムスタンプ、またはタイムスタンプとホスト名を追加する場合、パケットの総長さがまだ1024バイト以下であることを確認する必要があります。パケットが1024バイトを超えて拡張されている場合、リレーはパケットを1024バイトに切り捨てる必要があります。これにより、元のパケットの終わりから重要な情報が失われる可能性があります。このため、元々生成されたsyslogパケットのPRIおよびヘッダー部分には、セクション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文字の年のフィールドがタイムスタンプを終了するスペースをすぐにたどるより明示的なタイムスタンプが含まれていることがわかりました。これは、フィールドの順序と形式の元の意図と一致していません。実装者が送信されたメッセージ内により具体的な日付とタイムスタンプを含めることを希望する場合、コンテンツフィールド内にある必要があります。実装者は、より明示的な日付と時刻情報を含める場合は、ISO 8601 [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つの選択肢は、今年を含むファイルにレコードを挿入することです。協会により、その有益な記録に近い他のすべての記録は、同じ年に受け取られるべきでした。ただし、これらのどちらも、正しいタイムゾーンを各レコードに関連付けるという問題に対処していません。
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）とIPアドレスを含めることをお勧めします。ただし、従来、ホスト名フィールドにはホスト名のみが含まれていました。
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.
また、メッセージを生成したデバイス上のプロセスに関する情報を含めることは、その概念が存在する場合に含めることが良い慣行であると考えられています。これは通常、堅牢なオペレーティングシステムのプロセス名とプロセスID（「PID」と呼ばれることが多い）です。プロセス名は一般にタグフィールドに表示されます。多くの場合、コンテンツフィールドの先頭に追加情報が含まれています。「Tag [PID]：」の形式は、引用符のない - 一般的です。左の正方形のブラケットは、この場合にタグフィールドを終了するために使用され、次にコンテンツフィールドの最初の文字です。プロセス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.
その場合、コロンとスペース文字は通常、タグに従います。これは、引用符なしで「タグ：」として表示されます。その場合、コロンはコンテンツフィールドの最初の文字です。
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
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パーツとヘッダーパーツにタイムスタンプフィールドが含まれているため、それを送信する前に変更を加えません。この例のタグ値は、プロセス「SU」です。コロンはタグフィールドを終了し、コンテンツフィールドの最初の文字です。この場合、プロセスID（PID）は一時的と見なされ、このsyslogメッセージを見ている人は誰でもPIDを知ることから有用な情報を得ません。含まれていないため、コンテンツフィールドの最初の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!
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パーツのコンテンツ部分として扱われています。最初に、デフォルトの優先度値13を使用して有効なPRI部品が追加されました。次に、ヘッダーパーツのホスト名とともにタイムスタンプが追加されました。後続のリレーでは、このメッセージにこれ以上の変更は行われません。この例では、月の日は10未満であることに注意する必要があります。日付の1桁（この場合は5）にはタイムスタンプ形式のスペースがあるため、タイムスタンプには2つのスペースがあります。月の前に。また、リレーはメッセージを送信するデバイスのホスト名の知識がないように見えます。これにより、デバイスの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 # %%
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".
このメッセージには、優先順位の値を持つ有効なPRI部品があり、地元で定義された施設（Local4）から来たことを示しています。ヘッダーパーツには、メッセージに適切なタイムスタンプフィールドがあります。リレーは、送信する前にこのメッセージを変更しません。ただし、ホスト名とタグフィールドは、セクション4の定義と一致していません。ホスト名フィールドは「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!
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で定義されている形式のタイムスタンプではないため、リレーで変更する必要があります。リレーはタイムスタンプを追加し、次のようにホスト名を追加し、元のパケットのPRI部品の後に受信したパケット全体を新しいパケットのコンテンツフィールドとして扱います。ホスト名フィールドで使用される値は、リレーで知られているように、ドメイン名のないホスト名のみです。リレーパケットにタグ値は追加されません。元のメッセージにドメイン名と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.
臭いは、承認を必要としないメッセージと見なされる場合があります。人々は悪い臭いを避ける傾向がありますが、おいしい食べ物と関連する臭いに惹かれます。臭気や香りの受領の承認は必要ありません。実際、いくつかの臭気を完全に無視することは裁量の高さかもしれません。一方、通常、キッチンから漂う雰囲気からの料理人の腕前を認めることは通常、良い礼儀正しさと考えられています。同様に、さまざまな種が臭いを利用して仲間を引き付けることがわかっています。Mothの1種は、この香りを使用してお互いを見つけます。しかし、ボラスのクモは、この種の雌のmothの臭いを模倣できることがわかっています。この香りは、男性のmothを魅了し、仲間を見つけることを期待してそれに続きます。代わりに、彼らが香りの源に到着すると、彼らは食べられます[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 Processは、ローカルで使用されているため、イベント通知メッセージをそのシステム上のファイルに配置します。これは、メッセージを保護するためのシステムの整合性に依存しています。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パケットの受領が問題を引き起こしました。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.
この動作の可能性のある結果の1つは、誤解されたマシンが別のマシンとして自分自身を表すコレクターに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.
また、ヘッダー部分のホスト名フィールドを埋める場合は、局所的な重要性のみを有する可能性があり、それは一時的なみである可能性があることに注意する必要があります。デバイスがDHCPプールからIPアドレスを取得していた場合、識別子と実際のソースとの間の関連性が常に当てはまるとは限りません。コンテンツに完全に認定されたドメイン名を含めると、管理者は、常に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メッセージを単一のコレクターに送信するように構成されているいくつかのデバイスがある場合にさらに悪化します。1つのデバイスからのメッセージが遅延する可能性があるため、最初のデバイスからのメッセージが2番目のメッセージの前に生成された場合でも、コレクターが最初に別のデバイスからメッセージを受信します。タイムスタンプまたは調整されたシーケンス番号がない場合、メッセージを受信した順序で提示することができ、実際のイベントのシーケンスの不正確なビューを与える可能性があります。
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つのファイルのレコードが別のファイルのレコードの前または後に発生したかどうかを判断できない場合があります。これは、すべての宛先ファイルにタイムスタンプでメッセージをマークすることにより、やや軽減される可能性があります。これらがタイムスタンプを調整した場合、個々のメッセージを受信した時刻の兆候があります。
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メッセージをコレクターに再生する場合があります。ヘッダー部分にタイムスタンプフィールドがあっても、攻撃者はパケットを録音することができ、それらを再送信する前に現在の時間を反映するように単純に変更できます。管理者は、受信したメッセージで珍しいことは何もないと思われ、その領収書はマシンの通常のアクティビティを誤って示していることがあります。
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メッセージのドロップの結果を決定することはできません。メッセージが単純なステータスの更新である場合、非受信者に気付かないか、システムオペレーターに不快感を与える可能性があります。一方、メッセージがより重要である場合、管理者は発展し、潜在的に深刻な問題に気付かない場合があります。また、不正なアクティビティを隠す方法として、攻撃者によってメッセージが傍受され、破棄される場合があります。
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プロトコルには、損傷を検出する可能性のある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つのイベントメッセージを生成するアプリケーションを検討してください。1つ目は通常のステータスメッセージですが、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]、IPv6トラフィッククラスOctet [11]、または差別化されたサービスで使用する特定の値を持つ特定の優先順位値を持つSyslogメッセージ間のリンケージを定義することを選択できます。フィールド[12]。上記の例では、オペレーターは、ネットワークを通過するときに高い信頼性、低レイテンシーキューで問題を示すメッセージを関連付けながら、ステータスメッセージを通常の配信に関連付ける機能を持っている場合があります。これは、通常のステータスメッセージの前に必須メッセージに優先順位を付けることに影響を与えるでしょう。このホップバイホップの優先順位付けがあっても、このキューイングメカニズムは、送信デバイスのラインヘッドのブロックと、受信装置の飢verのバッファーが送信または受信されている場合は、受信装置の浸透につながる可能性があります。この動作は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レシーバーが大量のメッセージがほぼ同時に受信されているため、バッファーの飢vに苦しんでいる場合、重要なメッセージは他のメッセージとともに無差別にドロップされる場合があります。これらはデバイスとその能力の問題ですが、プロトコルのセキュリティ上の懸念は、重要でないメッセージよりも比較的重要なメッセージの優先順位付けがないことです。
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つのリレーに転送メッセージに構成したことを発見しました。これらのマシンのいずれかがそのタイプのメッセージを受信または生成した場合、それを他のリレーに転送します。そのリレーは、順番にそれを前方に戻します。このサイクルは、介入ネットワークと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プロトコルにはUDPポート514が割り当てられています。このポート割り当ては、このプロトコル専用に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で説明されているメッセージを生成した施設を示すための名前付き属性の定義を規定しています。これらの属性の名前空間識別子は、数字として定義されます。プロトコルは、これらの数値の名前空間の特定の割り当てを定義しません。アプリケーション開発者またはシステムベンダーは、属性、そのセマンティクス、および関連する数値を定義することができます。この名前のスペースは、衝突を防ぐために制御されません。システムは同じ属性、セマンティクス、および関連する数字を使用して、異種デバイス間でも類似していると見なされるイベントを説明することが期待されています。
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 Internet Engineering Task Force Forceの会議でBOFで頂点に達した最も注目すべき試み。これは、Universal Logging Protocol（ULP）BOFであり、彼らの会議の議事録はIETF Proceedings Webサイト[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.
この執筆時点では、伝統的にテキストのみであると考えられてきたアプリケーションでの国際的なキャラクターセットの使用を可能にするための努力が進行中です。上記のホスト名とタイムスタンプのフィールドは、これを代表しています。また、コンテンツフィールド全体は、従来、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 Daemon and Protocolの元の発明家であり著者です。このメモの著者とコミュニティ全体の著者は、この作品と長年にわたって提供されてきた有用性に対する彼らの感謝を表明したいと考えています。
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ファイルと、syslog.conf、syslog、syslogd、syslogd、およびloggerのmanページにあります。デバイスのように。
References
参考文献
1 Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
1 Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
2 Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
2 Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
3 USA Standard Code for Information Interchange, USASI X3.4-1968
3 USA標準コード情報インターチェンジ、USASI X3.4-1968
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. Deering、「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
8 Stowe、M.、et al、「化学模倣：Bolas Spidersは、Moth Prey種の性フェロモンの成分を発する」、Science、1987
9 Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
9 Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
10 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
10 Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
11 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
11 Deering、S。and 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 Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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 Cisco Systems製品セキュリティインシデント対応チーム（PSIRT）、「フィールド通知：Cisco IOS（R）Syslog Crash」、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 Walker、D.、IETF事務局、「ワシントンDC、米国ワシントンDC、12月8日 - 12日、1997年12月8日 - 12日、http://www.ietf.org/97dec/index.html
Author's Address
著者の連絡先
Chris Lonvick Cisco Systems 12515 Research Blvd. Austin, TX, USA
Chris Lonvick Cisco Systems 12515 ResearchBlvd.米国テキサス州オースティン
Phone: +1.512.378.1182
EMail: clonvick@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。