Network Working Group / Request for Comments: 3164 / 状態: 広報(Informational)
C. Lonvick (Cisco Systems)
2001年8月
この文書の目的は、インターネット・コミュニティーに対して有用な情報を提供することである。インターネット標準を定めることを目的とするものではない。この文書は自由に配付して構わない。
Copyright (C) The Internet Society (2001). All Rights Reserved.
この文書は、syslogプロトコルの実際の動作を調べ、記述したものである。syslogプロトコルは、ネットワークを介して何らかのイヴェントを通知するためのしくみとして、長年にわたって使われてきた。もともとはカリフォルニア大学Berkeley Software Distribution (BSD) TCP/IPシステムで実装されたものである。しかしシステムの運用や管理に有用であると認められた結果、各種のオペレーティング・システムに移植されたほか、さまざまなネットワーク機器の埋め込みシステムにも使われている。
古来、生物が生きていく上で、意志の伝達は欠かせなかった。自己を認識できる生物は、身に迫った危険、食料など生きるために必要なもののありかなど、さまざまな事柄をメッセージとして伝えてきたのである。メッセージは通常、他の個体に対して情報を与えるものであるが、それに対する返事は必ずしも必要とはされない。同じことが、人々が互いにやり取りしながら何らかの活動を行う際にも成り立つ。例えば気象警報は、サイレンを鳴らす、テレヴィやラジオで放送する、(船舶などで)旗をあげる、などさまざまな方法で伝達できる。警報を聞いたり見たりした人は、その影響を自分で判断し、適切に行動するはずである。多くの場合、警報を受け取った旨を応答する必要はないし、されても却って困ってしまうかも知れない。 同じように、オペレーティング・システム、プロセス、アプリケーションなども、現在の状態を表したり、何らかのイヴェントが発生した旨のメッセージを送るようになっている。普通はその機器の操作員に対してイヴェント発生を伝えるものである。しかしシステムが複雑になってくると、状況を迅速に把握できるよう、さまざまなメッセージを分類、記録するしくみが必要になってきた。 syslogプロセスもそのようなしくみの1つで、さまざまなオペレーティング・システムに採用されている。柔軟性を重視して設計されていることが特徴で、各プロセスが生成したメッセージをどこに送るか、自由に設定できるようになっている。例えば、イヴェントは内容に応じて別々のファイルに記録し、コンソールにも表示するよう設定できる。あるいは、別の機器で動いているsyslogプロセスに、ネットワーク経由でメッセージを転送するという設定も可能だ。 syslogプロセスは、さまざまな規模のシステムに対応するため、ネットワーク対応が欠かせない。何台もの機器を管理する場合、機器ごとのメッセージをいちいち見ている暇はないのが普通だからだ。遠隔機器上で動作するsyslogプロセスは、メッセージをファイルに記録するか、または別の機器に転送するよう設定しなければならない。
ごく簡単に言うと、syslogプロトコルは、イヴェントの通知メッセージを、IPネットワークを介して「コレクター」(あるいは「syslogサーヴァー」)に伝送するためのしくみである。プロセス、アプリケーション、オペレーティング・システムはそれぞれ、ある程度独立して開発されるものなので、syslogメッセージの内容が完全に統一されているとは言い難い。そのため、メッセージの書式や内容については何の仮定も設けず、単にイヴェント・メッセージを伝送するだけのものとして設計されている。どのような場合でも、メッセージを生成する「デヴァイス」が1つ存在する。そのデヴァイスで動作するsyslogプロセスは、メッセージをコレクターに送信できる。メッセージを受け取った旨の確認通知は発せられない。
syslogプロトコルやプロセスの基本方針の1つに、簡潔さということがある。送り手側と受け手側との間に、緊密な協調関係は必要ない。すなわち、syslogメッセージを送る際、受け手側で何か設定する必要はないし、それどころか、物理的に受け手が存在しなくても構わないのである。逆に言えば、明示的に設定や定義をしなくても、多くの機器がメッセージの受け手になりうる。syslogが広く普及した要因の1つに、この特徴を挙げてもよいだろう。
オペレーティング・システムやプロセス、アプリケーションが、どのような状況のときにメッセージを生成するか、開発者は自由に設計できる。例として、現在の状態を通知するためにメッセージを生成する使い方がある。一定時間ごとに生成する方法、あるいは、プログラムの起動、終了などの時点で生成する方法が考えられる。別の例として、所定の条件が成立するとメッセージを生成するという使い方もある。この場合に生成されるのは、状態通知メッセージであったり、あるいは何らかの警告を与えるメッセージかも知れない。 システム開発者は、こういったメッセージを適宜分類して扱う。分類の基準は、メッセージを生成した機能(facility)と、その重大度(severity)である。システムの操作員は、この基準に従って、必要なメッセージのみを選択できる。迅速に対処しなければならない、深刻な障害を通知するメッセージは、すぐにわかるようにする。一方、単に状態を報告するだけのメッセージはファイルに保存しておき、必要なときに調べればよい。さらに、画面に表示するか単にファイルに蓄積するか、という選択肢もある。
デヴァイスには、イヴェント・メッセージを表示あるいは転送する規則を設定しなければならない(MUST)。規則の自由度は非常に高い。すべてのメッセージをそのデヴァイス自身に保存する一方、重要なメッセージは別の機器に転送する、というような規則が設定可能である。あるいは、ある機能(facility)に関するメッセージは利用者に送信し、同時にシステム・コンソールにも表示する、という設定もありうるだろう。システム管理者は、イヴェント・メッセージやそれを生成するプロセスの性質を考慮して、どの機能や重大度のメッセージを、どの機器に転送するか定義する。例えば、電子メール機能に関するメッセージはすべて、あるコレクターに転送する、という設定が考えられる。あるいは、カーネルが生成するメッセージはすべてsyslogサーヴァーに転送し、重要なものはさらに別のサーヴァーにも転送して二重化する、という設定も可能だ。さらに、システム・コンソールに表示し、適切な管理者にメールで通知し、同時にデヴァイス自身のディスクに保存する、といった設定も検討してよいだろう。逆に、ローカルなプロセスが生成したメッセージは、単にコンソールに表示するだけにして、保存や転送はしないようにした方がよいかも知れない。各イヴェントを処理する規則は、当該デヴァイス上に設定することになる。設定が済めば、コレクター側にはどのようなメッセージが集まるかもわかるので、それに合わせてsyslogサーヴァーを適切に設定しなければならない。
メッセージの具体的な内容もシステムの開発者次第である。これを読むことになるであろう人に対して、適切な情報を提供する文面であるものと想定されている。また、メッセージの生成日時、生成したデヴァイスやプロセスを特定する情報を記述しておけば、有用であろう。しかしこれも必須条件ではない。
どの機器上のどのプロセスも、イヴェント・メッセージを生成しうると想定しなければならない。プリンター、ルーター、ハブ、スイッチ、ディスクレス・ワークステーションなど、記憶装置のない機器についても同様である。この場合、イヴェント・メッセージをコレクターに転送しない限り、操作員が読むことはできないかも知れない。
イヴェント・メッセージを受け取った側の処理については、この文書では扱わない。1.1節で説明したのと同様、適切な管理者に対して表示する、ディスクに保存する、別の機器に転送する、あるいはそういった処理を組み合わせることが考えられる。受け取ったメッセージの処理方法を決める規則は、当該機器で生成されたメッセージに関する規則と同様である。
メッセージを送信するデヴァイスの方よりも、コレクター機器の数は少ないのが普通である。したがって、さまざまな機器から届くメッセージを、少数の機器に集約することができる。
syslogはトランスポート層のUDP(User Datagram Protocol)[1]上で動作する。syslogに割り当てられているUDPポート番号は514である。送り手がsyslogプロセスであることがわかるよう、送信元ポート番号も514とするよう推奨されている(RECOMMENDED)が、それ以外のポートから有効なsyslogメッセージが送られてくることもありうる。この場合でも、常に同じポート番号を使うよう推奨されている(RECOMMENDED)し、これが作法に適った方法と考えられている。
この文書では次の定義に従って用語を使う。
メッセージに関与する機器のアーキテクチャーを以下に要約する。
図1に示すアーキテクチャーはどれも有効である。第1の形態が最も一般的であるが、その他の形態も可能である。上述のように、図ではリレー(Relay)と表している機器も、メッセージをすべて転送するとは限らないし、独自のメッセージを生成、送信することもある。
+------+ +---------+
|Device|---->----|Collector|
+------+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->----|Collector|
+------+ +-----+ +---------+
+------+ +-----+ +-----+ +---------+
|Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+------+ +-----+ +-----+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->----|Collector|
| |-\ +-----+ +---------+
+------+ \
\ +-----+ +---------+
\-->--|Relay|---->----|Collector|
+-----+ +---------+
+------+ +---------+
|Device|---->----|Collector|
| |-\ +---------+
+------+ \
\ +-----+ +---------+
\-->--|Relay|---->----|Collector|
+-----+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->-------|Collector|
| |-\ +-----+ /--| |
+------+ \ / +---------+
\ +-----+ /
\-->--|Relay|-->--/
+-----+
図1 syslogに関与する機器のアーキテクチャー例
UDPの送信先ポート番号が514であるIPパケットは、ペイロード部分をsyslogメッセージとして扱わなければならない(MUST)。最初に生成されたメッセージと、中継されたメッセージとで、書式が違っていても構わない(MAY)。syslogメッセージは、この文書で規定する書式にして送信するよう推奨する(RECOMMENDED)が、必須ではない。リレーは、メッセージが書式に合致していると認識した場合、何も変更せずにメッセージを再送信しなければならない(MUST)。反対に書式に合致していないと認識した場合は、書式に合うようメッセージを修正してから再送信する必要がある(REQUIRED)。4.1節に示すのは、syslogメッセージの推奨される(RECOMMENDED)書式である。4.2節ではsyslogメッセージを生成する際の必要事項、4.3節では中継する場合の必要事項を説明する。
ネットワーク上を流れるsyslogメッセージは3つの部分から成り、それぞれPRI、HEADER、MSGと呼ぶ。パケット全体の長さは、1024バイトまたはそれ以下でなければならない(MUST)。最短の長さは規定しない。もっとも、内容のないsyslogメッセージは役に立たないので、送信するべきではない(SHOULD NOT)。
PRI部は3〜5文字で構成しなければならず(MUST)、先頭と末尾は山括弧で囲む。すなわち、先頭は「<」、次いで数字、最後に「>」で閉じるのである。PRI部に使うコード集合は、RFC 2234[2]に規定されている、8ビット幅を用いた7ビットASCIIでなければならない(MUST)。これは「USA Standard Code for Information Interchange」[3]で定義されたASCIIコードである。この中で「<」文字はAugmented Backus-Naur Form (ABNF) %d60、「>」文字はABNF %d62と定義されている。山括弧で囲まれた数字は優先度(Priority)を表す値で、以下に示すように、機能(Facility)および重大度(Severity)を表す。Priority値は1〜3桁の10進整数(ABNF DIGITS)で、「0」を表す%d47から「9」を表す%d57の範囲を使う。
syslogメッセージのFacilityやSeverityは、10進数値でコード化されている。オペレーティング・システムで管理されるデーモンやプロセスのいくつかには、Facility値が割り当てられている。Facility値が割り当てられていない場合は「local use」または「user-level」というFacilityを使う。特定目的に割り当てられているFacilityとそのコード値を表に示す。
| コード | Facility |
|---|---|
| 0 | カーネル: kernel messages |
| 1 | ユーザー・レヴェル: user-level messages |
| 2 | 電子メール: mail system |
| 3 | システム・デーモン: system daemons |
| 4 | セキュリティー/認証: security/authorization messages (註 1) |
| 5 | syslogd内部生成: messages generated internally by syslogd |
| 6 | ライン・プリンター: line printer subsystem |
| 7 | ネット・ニューズ: network news subsystem |
| 8 | UUCP: UUCP subsystem |
| 9 | クロック・デーモン: clock daemon (註 2) |
| 10 | セキュリティー/認証: security/authorization messages (註 1) |
| 11 | FTP(ファイル転送): FTP daemon |
| 12 | NTP(時刻合わせ): NTP subsystem |
| 13 | 監査: log audit (註 1) |
| 14 | 警戒: log alert (註 1) |
| 15 | クロック・デーモン: clock daemon (註 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) |
表1 syslogメッセージのFacility
註1: Facility 4、10、13、14は、さまざまなオペレーティング・システムが、内容的にはよく似た、セキュリティー/認証、監査、警戒の目的で使っている。
註2: Facility 9、15は、さまざまなオペレーティング・システムが、クロック(cron/at)メッセージに使っている。
Severityも同様に10進数値でコード化されており、メッセージのPriorityとして使えるようになっている。Severityとそのコードを表に示す。
| コード | Severity |
|---|---|
| 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 |
表2 syslogメッセージのSeverity
Priority値は、Facility値を8倍し、Severity値を加算して求める。例えば、kernelメッセージ(Facility=0)で重大度がEmergency(Severity=0)であれば、Priority値は0となる。同様に、「local use 4」メッセージ(Facility=20)で重大度がNotice(Severity=5)であれば、Priority値は165である。syslogメッセージのPRI部にはこのPriority値を山括弧で囲んで記述するので、それぞれ「<0>」「<165>」となる。「<」の直後に「0」が続くのはPriority値が0の場合だけで、それ以外の場合、頭に「0」をつけてはならない(MUST NOT)。
HEADER部には、日時と、デヴァイスのホスト名またはIPアドレスを記述する。この部分は印字可能文字のみで構成しなければならない(MUST)。コード集合はPRI部と同様、8ビット幅を用いた7ビットASCIIでなければならない(MUST)。このコード集合で実際に使える文字は、ABNF VCHAR値(%d33-126)および空白(SP、%d32)だけである。
HEADER部は、TIMESTAMPおよびHOSTNAMEの2つの欄から成る。TIMESTAMPは、PRI部末尾にある「>」の直後に記述する。TIMESTAMP、HOSTNAMEの各欄の直後には、空白文字を置かなければならない(MUST)。HOSTNAME欄には、当該機器自身が認識しているホスト名を記述する。但しホスト名がない場合はIPアドレスとする。IPアドレスが複数ある機器の場合、メッセージを送信するのに使うIPアドレスを記述するものが多いが、そうなっていない実装も存在する。どのインターフェイスを使ってメッセージを送るかに関係なく、常に同じ送信元IPアドレスを使うのである。この場合、同じデヴァイスから送信されるメッセージは、常にHOSTNAME欄が一致していることになる。
TIMESTAMP欄には、「Mmm dd hh:mm:ss」という書式で、現地時刻を記述する。ここで:
TIMESTAMP欄の直後には空白を1つ入れなければならない(MUST)。
HOSTNAME欄に記述できるのは、メッセージを生成したデヴァイスのホスト名、IPv4アドレス、IPv6アドレスのいずれかである。特にホスト名が望ましい。その場合の書式は、STD 13 [4]の仕様に従わなければならない(MUST)。空白を含んではならず(MUST NOT)、また、ドメイン名も記述してはならない(MUST NOT)。IPv4アドレスの場合は、STD 13 [5] の仕様に従い、ドット区切り10進記法で記述しなければならない(MUST)。IPv6アドレスの場合は、RFC 2373 [6]の規定にもとづく、有効な表現は使ってよい(MAY)。HOSTNAME欄の直後には空白を1つ入れなければならない(MUST)。
syslogパケットの残りの部分はMSG部となる。通常、メッセージを生成したプロセスに関する付加情報で始まり、そのあとにメッセージ文が続く。MSG部の終了を表す区切り文字はない。また、印字可能文字のみで構成しなければならない(MUST)。コード集合としては伝統的に、PRI部やHEADER部と同様、8ビット幅を用いた7ビット・コードが広く使われている。このコード集合で実際に使える文字は、ABNF VCHAR (%d33-126)および空白(SP、%d32)だけである。しかし、MSG部にこのコード集合を使わなければならないという規定はないし、このことを仮定した処理もない。MSG部の文字は、上述のように印字可能な文字と空白だけから構成される限り、これ以外のコード集合を用いてもよい(MAY)。MSG部に使うコード集合は、想定される受け手を考慮して、慎重に選択するべきである(SHOULD)。受け手側で表示できず、人が認識できないような文字が使われていると、必要な情報が操作員や管理者に伝わらないことになる。
MSG部は、TAG欄とCONTENT欄の2つから成る。TAG欄にはメッセージを生成したプログラムまたはプロセスの名前を記述する。CONTENT欄にはメッセージの詳細を記述する。この欄は伝統的に自由形式で、イヴェントに関する詳細情報を記述することになっている。TAGはABNF英数字から構成される文字列で、32文字を超えてはならない(MUST NOT)。英数字以外の文字はTAG欄の末尾を表し、それ以降がCONTENT欄になる。CONTENT欄の先頭、すなわちTAG欄の末尾を表す文字は、左角括弧「[」、コロン「:」、空白のいずれかであることが多い。これについては5.3節でさらに詳しく説明する。
デヴァイスから送出されるsyslogパケットの内容について、必須とされる条件は何もない。繰り返すが、ポート番号514のUDPパケットは、ペイロード部分が有効なsyslogメッセージであると考えなければならない(MUST)。とはいっても、syslogパケットには、4.1節に説明したPRI、HEADER、MSGをすべて揃えるよう推奨する(RECOMMENDED)。これにより読みやすさが増すばかりでなく、中継する際にメッセージを書き換える必要がなくなる。
推奨される(RECOMMENDED)書式でsyslogメッセージを生成するプログラムを実装する場合、次の指針に従ってほしい。
パケットを受け取ったリレーは、有効なPRIがあるかどうかをまず確認する。先頭文字が「<」でなければ、有効なPRIが含まれてないものと仮定しなければならない(MUST)。また、第3、第4、第5のいずれの文字も「>」でない場合も、PRIが含まれていないものと仮定しなければならない(MUST)。有効なPRI部が見つかった場合、次にHEADER部に有効なTIMESTAMPがあるかどうか確認する。ここまでの確認結果により、受け取ったメッセージは3つの場合に分けられる。それぞれの場合について実行するべき処理を、表3の各節で説明する。
| 場合 | 節 |
|---|---|
| PRIもTIMESTAMPも有効 | 4.3.1 |
| PRIは有効だが、TIMESTAMPは存在しないか無効 | 4.3.2 |
| PRIがない、またはPRIと認識できない | 4.3.3 |
表3 受け取ったsyslogメッセージの場合分け
PRIもTIMESTAMPも有効であれば、リレーは次に、syslogパケットをどう処理するか、自分自身の設定を調べる。リレーは、Priority値に基づいて、syslogパケットを転送するよう設定できるようになっていなければならない(MUST)。転送するよう設定されている場合、パケットを何も書き換えずに転送しなければならない(MUST)。ここで再び強調しておきたいが、syslogメッセージを最初から4.1節に記述した書式で生成するよう推奨している(RECOMMENDED)のは、中継する際に書き換えなくて済むようにするためである。
TIMESTAMP欄の時刻が有効なものかどうか、メッセージの受け手が確認する必要はないこともここで註意しておこう。日付けが正しく設定されていないデヴァイスでも有効なsyslogメッセージを送信できるよう、このような仕様になっている。同様に、HOSTNAME欄の記述が送信元デヴァイスのホスト名やIPアドレスと合致することも、リレーは確認する必要がない。その理由は4.1.2節に説明した通りである。
受け取ったsyslogパケットに有効なTIMESTAMPがない場合、リレーは、PRI部の末尾を表す「>」の直後に、TIMESTAMPおよび空白文字を追加しなければならない(MUST)。また、そのあとにHOSTNAMEと空白文字も追加するべきである(SHOULD)。これらの欄について、詳しくは4.1.2節に解説した。受け取ったパケットの残余の部分は、MSG部のCONTENT欄と看做して、そのままHEADER部のあとに追加しなければならない(MUST)。どのプロセスがメッセージを生成したか、リレーが知ることはできないため、TAG値は生成できず、したがってこれは追加しない。
追加するTIMESTAMPは、中継する時点でのリレーの現地時刻とする。
HOSTNAMEはデヴァイスのホスト名で、リレーが認識している通りのものを追加する。ホスト名がわからない場合は代わりにIPアドレスを追加する。
リレーがPRI部のあとにTIMESTAMPを追加した場合、あるいはTIMESTAMPおよびHOSTNAMEを追加した場合、パケットの長さが1024バイト以下であることを確認しなければならない(MUST)。1024バイトを超えてしまった場合、リレーはパケットの末尾を切り捨てて、1024バイト以下に納まるようにしなければならない(MUST)。これにより末尾部分の情報が失われる可能性がある。4.1節に記述したように、最初からsyslogパケットにPRI部やHEADER部を入れておくよう推奨している(RECOMMENDED)のは、このためである。
受け取ったsyslogメッセージにPRI部がない、またはPRI部と認識できない場合、リレーはPriority値が13のPRI部を挿入し、4.3.2節で説明したようにTIMESTAMPも追加しなければならない(MUST)。さらに、4.3.2節で説明したように、HOSTNAMEも追加するべきである(SHOULD)。受け取ったパケット全体をMSG部のCONTENT欄であると看做し、そのままHEADER部のあとに追加する。
PRI部と認識できない場合の例としては、「<00>」というようなものがある。これはメッセージの先頭4文字であるかも知れない。いずれにしても、リレーはsyslogパケットの処理方法に関する設定を調べる。Priority値が13のsyslogメッセージを他のリレーまたはコレクターに転送するよう設定されていれば、上述のようにパケットを書き換えなければならない(MUST)。HOSTNAMEも挿入するよう推奨されている(RECOMMENDED)ので、結果は次のようになる。
リレーがPRI部のあとにTIMESTAMPを追加した場合、あるいはTIMESTAMPおよびHOSTNAMEを追加した場合、パケットの長さが1024バイト以下であることを確認しなければならない(MUST)。1024バイトを超えてしまった場合、リレーはパケットの末尾を切り捨てて、1024バイト以下に納まるようにしなければならない(MUST)。これにより末尾部分の情報が失われる可能性がある。4.1節に記述したように、最初からsyslogパケットにPRI部やHEADER部を入れておくよう推奨している(RECOMMENDED)のは、このためである。
4章ではsyslogプロトコルの書式や内容について必要な事項をすべて説明したが、syslogメッセージに付加する情報に関しては、長い間にさまざまな約束事ができてきた。必須事項というわけではないが、実装にあたっては、どのような状況でどの機器が生成したメッセージなのか、受け手が充分な手掛かりを得られるよう考慮して欲しい。
システム・メッセージを長期にわたって保管しておくネットワーク管理者も多い。それを考慮して、TIMESTAMPの末尾を表す空白のあとに、2桁または4桁で年が記録されているsyslogメッセージもある。しかしこれは、本来の書式に準拠していない。年も含めて日時を記述したい場合は、CONTENT欄を使うべきである。ISO 8601 [7] に定義された日時の書式に倣うのもよいだろう。
長期にわたって保管することを考慮した記録方法が、いろいろ提案、実装されている。1つの方法は、コレクターがメッセージを保管する際に書き換えるというものである。年その他の情報を各レコードに追記するだけの、単純なスクリプトでもよい。別法として、ネットワーク管理者にとって都合のよい書式に、日時を書き換えてしまう方法もある。あるいは、現在の年を記述したレコードをファイルに挿入する方法もある。その付近のレコードはすべて、その同じ年に受け取ったものと判断してよい、というわけだ。但しどの方法にしても、時間帯をどう扱うかについては考慮されていない。
メッセージを生成したデヴァイスを容易に特定できるよう、CONTENT欄に完全修飾ドメイン名(FQDN; Fully Qualified Domain Name)とIPアドレスを記録しておくのもよい方法だ。HOSTNAME欄には、伝統的に、ホスト名のみを記述することになっている。
デヴァイス上で実際にメッセージを生成したプロセスに関しても、何らかの情報があれば、記録しておくのもよいだろう。きちんとしたオペレーティング・システムであれば、通常、プロセス名やプロセスID(よく「pid」とも呼ばれる)を記録しておけばよいはずである。プロセス名は一般に、TAG欄に記述する。付加的な情報を、CONTENT欄の先頭に記述することも多い。一般に、「TAG[pid]:」という書式が用いられる。この場合、左角括弧がTAG欄の末尾を示す区切り文字であり、かつCONTENT欄の先頭文字にもなっている。但し、プロセスIDが特に重要な意味を持たない場合は、記述しなくても構わない。
その場合、TAG欄の直後にコロンと空白をおいて、「TAG: 」という書式にすることが多い。コロンはCONTENT欄の先頭文字になる。
例として、2つの機器を結ぶネットワーク上を流れうる、有効なメッセージを示す。読みやすさを考慮して、字下げを施し、適当に改行を追加しておく[訳文(HTML)ではblockquote要素として示す]。
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8
この例は、より高い処理権限を得ようとしたが、認証に失敗したことを表している。実際に試みられたコマンドと、そのユーザー名も示されている。mymachineというデヴァイスが生成したメッセージであることもわかる。リレーがこれを受け取った場合、何も変更せずに後続に転送して構わない。PRI部と、HEADER部のTIMESTAMP欄が、正しく記述されているからである。TAG値は「su」というプロセス名である。コロンがTAG欄の末尾を表し、CONTENT欄の先頭文字にもなっている。この例では、プロセスID(pid)は記載されていない。このsyslogメッセージの受け取り手がpidを知っても、何の役にも立たないという判断に基づいている。したがって、CONTENT欄の先頭の2文字は、コロンおよび空白である。
Use the BFG!
これも有効なメッセージではあるが、役に立つ情報はほとんどない。まず、PRI部がない。日時も、メッセージの生成元も記述されていない。これが紙に印字されたりディスクに保存されたりしても、読む人にとっては何の役にも立たないだろう。
これは明らかに、デヴァイスが生成したメッセージそのものである。リレーは、4.3節で説明したように、転送する際にメッセージを書き換えなければならない(MUST)。実際に中継されるのは次のようなメッセージである。
<13>Feb 5 17:32:18 10.0.0.99 Use the BFG!
中継する際には、元のメッセージ全体を、MSG部のCONTENTとして扱う。まず、Priority値が13の、有効なPRI部を追加する。次にHEADER部のTIMESTAMPおよびHOSTNAMEを追加する。これにより、後続のリレーは何も書き換える必要がなくなる。この例では日が1桁である点にも註意されたい。TIMESTAMPの書式では、日が1桁(この例では「5」)の場合、空白を頭に追加することになっている。したがって、月の名前のあとに空白が2つはさまっている。また、メッセージを送り出したデヴァイスのホスト名はわからないので、HOSTNAME欄にはIPv4アドレスが入っている。
<165>Aug 24 05:34:00 CST 1987 mymachine myproc[10]: %% It's time to make the do-nuts. %% Ingredients: Mix=OK, Jelly=OK # Devices: Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport: Conveyer1=OK, Conveyer2=OK # %%
このメッセージには有効なPRI部がある。Priority値を調べると、「local use 4」メッセージで重大度がNoticeであることがわかる。また、HEADER部には正しいTIMESTAMP欄がある。したがってリレーは、このメッセージを書き換えることなく中継して構わない。しかしHOSTNAME欄およびTAG欄は、4章で述べた仕様に合致していない。「CST」がHOSTNAME欄と看做され、「1987」以降はMSG部になってしまう。
CONTENT欄の情報が、遠隔測定で得られたデータでも、監視制御やデータ取得に関する情報でもないことに註意しておこう。安全性については6章で詳しく考察するが、こういった情報は一般に、このプロトコルで伝送するべきではない。
<0>1990 Oct 22 10:52:01 TZ-6 scapegoat.dmz.example.org 10.1.2.3 sched[0]: That's All Folks!
この例には、本来は必要でない情報がたくさん含まれている。人間や、高機能な構文解析システムならば、日付けや時刻、完全修飾ドメイン名(FQDN) [4]、IPアドレスなどを知ることができるだろう。しかしイヴェントそのものに関する情報は乏しい。重大度から判断して、これ以上の情報を蒐集、送信することはできそうになく、このメッセージを送信できたことだけで良しとしなければならないだろう。
これは明らかに、デヴァイスが生成したメッセージそのものである。HEADER部の最初の欄が、4.1.2節に定義した書式のTIMESTAMPではないので、リレーはこれを書き換えなければならない(MUST)。次のようにTIMESTAMPを追加するほか、HOSTNAMEも追加するべきである(SHOULD)。元のメッセージにあった、PRI部よりあとの部分は、新しいパケットではCONTENT欄になる。HOSTNAME欄はリレーが認識できたホスト名で、ドメイン名は含まれない。また、TAG値は追加しない。元のメッセージにはドメイン名やIPv4アドレスも記述されているが、できるだけ情報を伝えようという努力は認めるものの、4.1.2節に定義した書式に合致していないのである。
<0>Oct 22 10:52:12 scapegoat 1990 Oct 22 10:52:01 TZ-6 scapegoat.dmz.example.org 10.1.2.3 sched[0]: That's All Folks!
匂いは普通、確認応答の必要がないメッセージと考えられている。人間は、悪臭を避けようとする一方、おいしい食料を想起させる匂いには引き寄せられる。匂いや香りを感知したからといって確認応答の必要はないし、匂いの種類によっては、まったく無視されてしまうことさえある。一方、調理場から漂ってくる匂いだけから料理人の腕前を見破ることができると、高く賞賛されるのが普通である。同様に、匂いで異性をひきつけようとする動物は多い。例えばある種の蛾は、匂いを使って互いに相手を認識しあう。ところが、ナゲナワグモはメスの蛾が発するのと似た匂いを出すため、オスの蛾はこれにおびき寄せられてしまう。匂いの元にたどり着いた途端、クモに食べられてしまうのである[8]。これはメッセージが本来の意図通りに使われなかった例である。
syslogプロセスが1台の機器だけで閉じている場合、イヴェント通知メッセージは当該システム上のファイルに保存される。この場合、メッセージの信頼性は、システムの整合性次第である。一方、メッセージを他のコレクターに転送するよう設定すると、イヴェント通知メッセージの配送先が拡がり、メッセージの信頼性はネットワークの信頼性に依存するようになる。原理的にsyslogはしくみが単純なので、確実に配送しなければならない場合、このプロトコルで問題がないかどうかよく考えなければならない。上述の喩えで言うと、コンピューターのイヴェント・メッセージは事故や誤動作によって送られるかも知れないし、悪意の者が介在している可能性もあるのだ。もっとも、この文書の執筆時点で、ある機器がネットワークを介して他の機器を破壊したという事例は耳にしていない。
既に述べたように、メッセージ長が1024バイトを超えてはならない(MUST NOT)。この点を狙って、1024バイトより長いsyslogメッセージを送りつけるという攻撃がある。syslogの古い実装では、このようなsyslogパケットが送りつけられると問題が生じる場合があったのだ。したがってsyslogメッセージの受け手は、1024バイトを超えるパケットを受け取っても、誤動作しないようにしなければならない。実際に長いメッセージを受け取ったときの受け手の動作はさまざまである。メッセージの内容全体を記録するものもあれば、一部だけを記録するものもある。メッセージ全体を捨ててしまう実装さえある。中継する場合、このようなメッセージをそのまま再送信してはならない(MUST NOT)。
受け手も同様に、メッセージ本体が正当かどうか厳密に確かめなければならない。syslogコレクターは、Priority値が有効範囲外であっても誤動作しないようにしなければならない。このようなメッセージを中継する場合は、4.3.3節のように、CONTENT部のみか成る、書式が整っていないメッセージとして扱わなければならない(MUST)。
さらに、受け取ったメッセージが、4章に述べたように、印字可能な文字のみから成ることも確かめなければならない。そうでない場合でも誤動作しないように実装する必要がある。
syslogの配送のしくみは、メッセージとその送り手を対応づけて扱うようにはなっていない。すなわち、パケットの受け手は、本当に記述されている通りの送り手から送られたものかどうか、確かめるすべがないのである。さらに、HEADER部のHOSTNAMEと、IPヘッダーの送信元IPアドレスに対応するホスト名とが合致するかどうか、確認する必要がないとされている点にも註意しなければならない。
ホスト名を確認しないようになっているため、設定が誤っていれば、ほかの機器が生成したように詐称するsyslogメッセージをコレクターに送信してしまう可能性がある。メッセージを生成したはずの機器と、実際の状態が合致していないのだから、管理者は混乱してしまう。複数の機器が同じ名前を名乗っていることに気がつかなければ、迅速な対処はおぼつかない。
HEADER部のHOSTNAME欄に記載されたホスト名が、その機器にとってしか意味がなく、短期間で無効になってしまう場合もある。デヴァイスがIPアドレスをDHCPプールから取得していれば、ホスト名から実際のメッセージ送信元を特定するのは難しいことがある。CONTENT欄に完全修飾ドメイン名を記述するようにすれば、これが常に同じIPアドレスまたは同じ機器に対応している場合、管理者がメッセージの送信元を正しく特定できる可能性が高い。
このような動作を悪用される可能性があるので註意しなければならない。攻撃者はsyslogメッセージをコレクターに送りつける(送信元はメッセージに記述されている通りかも知れないし、そうでないかも知れない)。ある場合には、真の攻撃目標から管理者の目をそらすためにsyslogメッセージが悪用される。例えば、ある機器に問題が生じたという、にせのメッセージを送りつける。システム管理者がその対処に気を取られている間に、別の機器、あるいは同じ機器の別のプロセスに対して攻撃を試みるのである。さらに、にせの状態通知やイヴェント通知を行うsyslogメッセージを送信するかも知れない。例えば、ある重要なプロセスを停止させる。すると終了通知メッセージが生成されるはずである。そこで、プロセスが再起動された、というにせの通知メッセージを生成するのである。システム管理者はこれにだまされて、本当に再起動されたかどうか確認しないでしまうかも知れない。
一般に、ネットワークの異常を調べる場合、各イヴェントが発生した順序を正しく把握する必要がある。メッセージが生成された通りの順序でsyslogコレクターに届き、その記録からイヴェントの発生順序がわかるならば話は簡単だ。残念ながらsyslogのプロセスやプロトコルには、配送順序を保証するためのしくみはない。そのために起こりうる問題について、以下詳しく述べる。
syslogレコードは通常、届いた順にファイルに記録されたり、コンソールに表示されたりする。メッセージが生成された順序と一致しているとは限らない。IPネットワークを経由する以上、順序が入れ替わることもある程度想定しなければならないのである。この点に註意しないと、例えばあるプロセスが起動する前に停止したように見えて、混乱を招くかも知れない。もしも生成元プロセスが生成時刻や順序番号をメッセージに挿入していれば、誤解をある程度避けることができる。この場合、送信元デヴァイスの時計は、信頼できる基準時間源に合わせられることが望ましい。しかしその機能がないデヴァイスもあるし、あったとしてもメッセージに時刻を記録できない場合もある。
syslogにはイヴェントの順序を統一的に管理するしくみがない。同じデヴァイス内であればCONTENT欄に順序番号を打つことも可能であるが、複数のデヴァイス間にわたる順序番号は難しい。各デヴァイスから送られてくるメッセージの順序番号が、すべて1番になってしまうこともありうる。この場合もやはり、各デヴァイスが時計を基準時間源に合わせ、時刻をメッセージに挿入するようになっていれば、ある程度は誤解を避けることができる。先にも述べたように、送り手が単一でもメッセージの順序が入れ替わって届くことがあるのだから、複数になれば事態はさらに悪化する。あるデヴァイスが生成したメッセージが遅延すると、それよりあとに別のデヴァイスで生成されたメッセージが、先に届いてしまうかも知れない。生成時刻が記録されておらず、複数のデヴァイス間にわたる順序番号もなければ、届いた順に表示されてしまい、実際のイヴェント発生順序と食い違うことになる。
ネットワークの設定が複雑になると、イヴェントの発生順序を把握するのがさらに難しくなる。例えばあるデヴァイス群が、状態メッセージなどを1つのコレクターに送信し、重要なメッセージはさらに別のコレクターにも送信するとしよう。さらに、同じコレクター内で、別のファイルにもメッセージが記録されるとする。こうなると、メッセージの生成元が時刻を記録していない限り、各所に保存されたメッセージの順序を正しく把握するのは困難である。あるファイルに記録されたレコードが、別のファイルのレコードより前か後か、判断できないのである。ファイルに記録する際、時刻を記録したレコードを挿入するようにすれば、ある程度は問題を解消できる。各機器の時刻を合わせておき、それを記録しておけば、各メッセージの受け取り時刻を推測する手がかりになるかも知れない。
メッセージに順序番号も時刻も記録されていない場合、これを横取りしておき、あとで同じものを再送するという攻撃が成り立つ。例えば攻撃者は、あるデヴァイスが正常に動作していることを示すメッセージを横取りし、保存しておく。そうしておいて、ネットワークからそのデヴァイスを切り離す一方、保存しておいたsyslogメッセージをコレクターに送信するのである。HEADER部にTIMESTAMP欄があったとしても、ここを書き換えて再送信すれば同じことだ。すると管理者は、メッセージを見て、何も問題がないと判断してしまう。
syslogのプロセスにもプロトコルにも、正しく配送されたかを確認するためのしくみはない。しかもUDP上に実装されるプロトコルなので、メッセージが到達していなくてもわからない。ネットワークの輻輳や、経路上にいる攻撃者の介在により、メッセージが失われてしまっても、その旨を検出できないのである。単に状態の更新を通知するメッセージであれば、届かなくても気付かずにそれっきりになるかも知れないし、システム運用者が少しばかり気にするかも知れない。一方、重要なメッセージであれば、重大な問題に管理者が気付かないでしまうおそれがある。また、攻撃者がsyslogメッセージを盗聴し、破棄している場合、別の不正な活動を隠蔽しようとしている可能性が高い。
syslogメッセージは、捨てられてしまうばかりでなく、伝送中に損傷したり、攻撃者の手によって改竄されたりする可能性もある。syslogメッセージのパケットが損傷した場合にそれを検出するしくみは、IPプロトコル[9]やUDPプロトコルのほか、リンク層にも組み込まれている。中継するルーターが、損傷したIPパケットを廃棄する可能性もある[10]。UDPパケットが損傷を受けた場合、受け取った側のUDPモジュールがそれを検出し、黙って廃棄するかも知れない。いずれにしても、元のメッセージの内容はコレクターに届かないことになる。さらに、送り手と受け手を結ぶ経路上に攻撃者が介在した場合、横取りして改竄することにより、不正な操作を隠蔽しようとするかも知れない。
イヴェント・メッセージの書式について、厳密に守らなければならないような指針はないが、ほとんどのメッセージは、ある程度の能力がある管理者であれば読んで意味がわかるように生成されている。syslogのプロトコルにもアプリケーションにも、伝送中のメッセージを秘匿するしくみはない。盗聴の問題を考慮しなければ、平文でメッセージを送る方が、運用者にとっては便利だからである。不具合が生じた場合、そのままメッセージを読み、他のパケットから得たイヴェント情報とも関連付けて原因をつきとめ、解決できるわけだ。ところが、残念ながらsyslogメッセージは、攻撃者にも簡単に読めてしまう。攻撃者はこうして得た情報を悪用して効果的に攻撃できるのである。
メッセージを生成するプロセスは、イヴェントの重大度を示すためにPriority値を使うことができるが、重大だからといってパケットの配送が特別扱いされるわけではない。例えば、あるアプリケーションがイヴェント・メッセージを2つ生成したとしよう。1つ目のメッセージは単に状態を報告するもの、2つ目は障害発生を通知する、重大度の高いものとする。2つ目のメッセージはSeverity値が高いはずである。どちらも同じsyslogコレクターに送信するよう設定されていれば、2つとも同じようにUDPプロトコルで伝送される。普通の環境であれば、どちらのメッセージも区別なく、発生順に送信される。
そしてやはり普通の環境では、受け手はsyslogメッセージを受け取った順に処理する。多くのデヴァイスが通常の状態メッセージを送信する中、1台のデヴァイスが重大度の高いイヴェント・メッセージを送ったとしても、syslogプロトコルに、それを特別扱いするようなしくみはない。
サーヴィス品質識別子を重大度のレヴェルに対応付け、対症療法的に運用している例も見受けられる。例えば、特定のPriority値のsyslogメッセージを伝送する際に、IPv4 Precedence(優先度)欄[0]、IPv6 Traffic Class値[11]、Differentiated Services欄[12]などにある値を設定し、特別扱いすることが考えられる。こうしておいて、状態通知メッセージは通常通りに配送する一方、障害を通知するメッセージは信頼性が高く遅延の小さいキューを使って、迅速に伝わるよう設定する。これにより、重要なメッセージの処理優先度を高くする効果が得られる。このようなホップごとの優先順位づけでも、同時に多くのメッセージが送受信されれば、送信側デヴァイスの閉塞、受信側のバッファー枯渇などが起こる可能性はある。syslogに限らず、メッセージを順に送信するような処理においては避けられないことだ。
これに関連して、安全性についても考慮しなければならない。重要なイヴェント・メッセージが閉塞して送信できなくなると、重要性の劣るメッセージの方が優先されてしまうことがある。キューが適切にクリアされれば、重要なメッセージはほんの数秒で転送されるはずだ。ところが、キューがクリアされないと、重要なメッセージが転送されないおそれがある。受け手側でも、ほとんど同時に多数のメッセージが届き、バッファーが枯渇した結果、重要なメッセージが他のメッセージに埋もれ、失われてしまう可能性がある。これは機器ごとの容量の問題だが、メッセージの重要性に応じて優先度をつけるしくみがないことは、プロトコルの安全性の上で問題になる。
メッセージや設定に関する制御情報が配布されることはないため、メッセージが意図通りの受け手に届けられるかどうかは、完全にネットワーク管理者の責任である。不註意により、syslogメッセージを間違った受け手に送信するよう、デヴァイスを設定してしまう場合がある。通常、その受け手はsyslogメッセージを受け取るように設定されてはいないので、単に捨ててしまうことになる。場合によっては、意図しないsyslogメッセージが届くことにより、受け手側に問題が起こりうることが知られている[13]。意図した受け手に届かなければ当然、内容を確認し、対処することはできない。
図1のように、syslogメッセージを次々と中継して、コレクターまでつなげるよう設定できる。その際、あるPriority値のメッセージを、2台のリレーが互いに相手に転送するよう誤設定してしまうことがある。該当するPriority値のメッセージを一方のリレーが受け取るか生成すると、もう一方に転送され、再び元に戻ってきてしまう。これにより、2台の機器ばかりでなく、それを結ぶネットワークの処理能力も低下する。ネットワーク管理者は、このような「デス・スパイラル」が生じないよう註意しなければならない。
ネットワーク管理者は、syslogメッセージを受ける側がどの程度の容量までならば受け入れられるか、時間をかけて見積もらなければならない。コレクターににせのメッセージを大量に送りつけてディスクをあふれさせる、サーヴィス妨害(DoS; Denial of Service)攻撃をしかけられる可能性もある。レコードを蓄積するファイルを循環方式にすれば多少は被害を緩和できるかも知れないが、あとで管理者がレコードを確認できなくなるおそれがある。この点を考慮して、受け手、特にコレクターは、送りつけられるメッセージをすべて受け取れるだけのネットワーク容量を確保しておかなければならない。
ネットワーク管理者は、デヴァイス、リレー、コレクターを結ぶネットワーク経路についても、慎重に計画しなければならない。生成されたsyslogメッセージにより、ネットワークが輻輳してしまうようであってはならない。
syslogプロトコルは、UDPのポート番号514に割り当てられている。ポート番号の割り当てはもっぱらIANAが管理している。
syslogプロトコルでは、各メッセージの重大度(Severity)や、メッセージを生成する機能(Facility)を表すために、4章で示したような名前つき属性を定義している。各属性の名前空間識別子は、数値で定義されている。この数値の割り当ては、プロトコル自身が特に定義しているわけではない。したがって、アプリケーションやシステムの開発者が、属性およびその意味、数値の割り当てを適宜決めても構わない。また、数値の衝突を回避するよう考慮されてもいない。デヴァイスの種類は異なっても、同じようなイヴェントを記述するためには、同じ属性、意味、数値を使うと想定しているからである。
syslogプロトコルは、ネットワークを介してイヴェント通知メッセージを送信するために、有効に利用されている。syslogメッセージの受け手は常に、「違背があってもできるだけ寛大に解釈する」という考え方で処理することが大切だ。ネットワーク運用者は、このプロトコルを利用する場合、その特性や、安全性に関する影響を理解しておくようお勧めする。
syslogメッセージの書式を標準化しようという動きはこれまでにもあった。代表的なものは、1997年、第14回IETF(Internet Engineering Task Force)会合のBOFである。その様子は、「IETF Proceedings」ウェブ・サイト[14]に、「2.1.34 Universal Logging Protocol (ulp) BOF」として公開されている。
さまざまな提案がなされているので、プロトコルを実装する際には、このときの研究ノートや論文を参照するべきだろう。
syslogはテキストのみでやり取りするアプリケーションとして扱われてきたが、この文書の執筆時点では、文字セットの国際化が検討されている。HOSTNAME欄やTIMESTAMP欄がその対象だ。また、CONTENT欄もすべて、印字可能文字および空白から成る、US_ASCIIコードで記述することになっている。国際化の提案者に対しては、混乱をきたさない方法で、syslogメッセージに国際文字セットが使えるようにするよう期待されている。また、将来コード・セットが追加になっても対応できるよう、実装に際しては今から準備しておいて欲しい。繰り返すが、既存のシステムは機構が単純だったために広く受け入れられた、ということを忘れてはならない。拡張の結果、単純さが損なわれれば、受け入れ難くなってしまうだろう。
この文書の執筆にあたって、次の各氏から助言をいただいた。
Eric Allman氏は、syslogデーモンおよびプロトコルを考案し、実装した。この文書の著者およびインターネット・コミュニティーは、同氏の多大な業績に敬意を表し、長年にわたって広く活用させていただいたことを感謝する。
syslogプロトコルは、各種のオペレーティング・システムで事実上標準的に用いられている。さらに詳しくは、syslog.confファイルのほか、多くのUnix系機器で利用できる、syslog.conf、syslog、syslogd、loggerなどのmanページを参照されたい。
Chris Lonvick Cisco Systems 12515 Research Blvd. Austin, TX, USA Phone: +1.512.378.1182 EMail: clonvick@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.