Syslog
ウィキペディアから
syslog（シスログ）は、ログメッセージをIPネットワーク上で転送するための標準規格である。"syslog" という用語は、その通信プロトコルを指すだけでなく、syslog メッセージを送信するシステム（アプリケーションやライブラリ）syslog メッセージを受信し報告・分析するシステムに対しても使われる。syslogの各メッセージには、そのメッセージを生成したシステムの種類を示すファシリティコードが付与され、重大度が設定される。
| 作者 | エリック・オールマン |
|---|---|
| 初版 | 1980年代 |
| 対応OS | Unix系 |
| 種別 | システムログ記録 |
| 公式サイト |
datatracker |
システム管理やセキュリティ監査の目的だけでなく、一般的な情報提供、分析、デバッグ用にも用いられる。多くのプラットフォームで、プリンタ、ルータ、メッセージレシーバなど、様々なデバイスがsyslog規格を使用している。これにより、異なるタイプのシステムからのログデータを1つの集中リポジトリで一括して管理することができる。syslogの実装は、多くのオペレーティングシステムで行われている。 ネットワーク上で動作する場合、syslogはクライアントサーバモデルを採用している。受信側（サーバ）は一般に"syslogd"、"syslogデーモン"、"syslogサーバ" などと呼ばれる。クライアントは1024バイト以下の短いテキストメッセージをサーバに送信する。syslogメッセージはUDPまたはTCP上で送信される。送信されるデータは一般にクリアテキストであるが、Stunnel、sslio、sslwrap といった SSL ラッパーを使って SSL/TLS による暗号化が可能である。
歴史
syslogは、1980年代にエリック・オールマンによってsendmailプロジェクトの一環として開発された[1]。以降、他のアプリケーションでも採用されるようになり、現在ではUnix系システムの標準的なログ記録方式となっている[2]。その他のOSでも実装されており、ルータなどのネットワーク機器にもよく搭載されている[3]。
長らくデファクトスタンダードであって、何らかの規格があるわけではなく、個々の実装には非互換も存在していた。セキュリティ強化のため、IETFはsyslogワーキンググループを結成した。2001年、syslogの現状をまとめて文書化したRFC 3164が発表された。その後、2009年にRFC 5424で標準化された[4]。
様々な企業が、syslogの実装について特許を主張しようとしたが[5][6]、プロトコルの利用と標準化にはあまり影響を及ぼさなかった。
syslogメッセージの構成要素
要約
視点
syslogメッセージの発信者から提供される情報には、ファシリティコードと重大度レベルが含まれる。syslogソフトウェアは、エントリを受信側に渡す前に、情報ヘッダに情報を追加する。情報ヘッダには、元の送信者のプロセスID、タイムスタンプ、デバイスのホスト名またはIPアドレスが含まれる。
ファシリティコード
ファシリティコード(facility code)は、メッセージを記録するシステムの種類を指定するために使用される。ファシリティコードにより、受信側で処理方法が変わる可能性がある[7]。規格で定義された利用可能なファシリティコードは、以下の通りである[8]。
| ファシリティコード | キーワード | 説明 |
|---|---|---|
| 0 | kern | カーネルメッセージ |
| 1 | user | ユーザレベルメッセージ |
| 2 | メールシステム | |
| 3 | daemon | システムデーモン |
| 4 | auth | セキュリティ/認証メッセージ |
| 5 | syslog | syslogdが内部で生成したメッセージ |
| 6 | lpr | ラインプリンタ・サブシステム |
| 7 | news | ネットニューズ・サブシステム |
| 8 | uucp | UUCPサブシステム |
| 9 | cron | Cronサブシステム |
| 10 | authpriv | セキュリティ/認証メッセージ |
| 11 | ftp | FTPデーモン |
| 12 | ntp | NTPサブシステム |
| 13 | security | ログ監査 |
| 14 | console | ログ警告 |
| 15 | solaris-cron | スケジューラ・デーモン |
| 16–23 | local0 – local7 | ローカル使用のファシリティコード |
ファシリティコードとキーワードの対応は、OSやsyslogの実装によっては異なる場合がある[9]。
重大度レベル
規格で定義された重大度レベル(severity level)は以下の通りである[10]。
| 値 | 重大度 | キーワード | 非推奨 キーワード | 説明 | 状態 |
|---|---|---|---|---|---|
| 0 | Emergency | emerg | panic[11] | システム使用不可 | パニック状態[12]。 |
| 1 | Alert | alert | 早急な対処が必要 | システムのデータベースが破損しているなど、すぐに修正すべき状態[12]。 | |
| 2 | Critical | crit | 致命的な状態 | ハードデバイスのエラー[12]。 | |
| 3 | Error | err | error[11] | エラー状態 | |
| 4 | Warning | warning | warn[11] | 警告状態 | |
| 5 | Notice | notice | 正常だが注意が必要な状態 | エラー状態ではないが、特別な処理を必要とする可能性のある状態[12]。 | |
| 6 | Informational | info | 通知メッセージ | プログラムが期待通りに動作していることの確認。 | |
| 7 | Debug | debug | デバッグメッセージ | 通常、プログラムのデバッグ時にのみ使用される情報を含むメッセージ[12]。 |
EmergencyとDebug以外の重大度レベルの意味は、アプリケーションにより異なる。例えば、顧客の口座残高情報を更新するためのトランザクションを処理するシステムであれば、最終段階でのエラーにはAlertレベルを割り当てるべきである。しかし、顧客の郵便番号を表示しようとした際に発生したエラーならば、ErrorやWarningレベルで十分である。
通常、サーバ側でメッセージの表示を行うときにある重大度レベルでフィルタリングを行う場合、それより重大な重大度レベルのエントリも含めて表示する。例えば、Notice、Info、Debugのメッセージをフィルタリングする際にはWarningレベルのエントリも含まれる[13]。
メッセージ
RFC 3164では、メッセージ・コンポーネント（measge component、MSGと略称される）は、メッセージを生成したプログラムやプロセスの名前であるTAGと、メッセージの詳細を含むCONTENTの2つのフィールドで構成されると規定されている。
RFC 5424[14]には、「MSGは、RFC 3164でCONTENTと呼ばれていたものである。TAGはヘッダの一部になったが、単一のフィールドではない。TAGはAPP-NAME、PROCID、MSGIDに分割されている。これはTAGの使い方と完全には似ていないが、ほとんどの場合同じ機能を提供する」と書かれている。rsyslogなどの一般的なシスログツールは、この新規格に準拠している。
コンテンツフィールドは、UTF-8の文字セットでエンコードし、ASCIIにおける制御文字の範囲のオクテット値は避けるべきである[15][4]。
ロガー
生成されたログメッセージは、コンソール、ファイル、リモートのsyslogサーバー、リレーなど、さまざまな宛先に送ることができる。ほとんどの実装では、ログにメッセージを送信するためのコマンドラインユーティリティ（多くの場合、「ロガー」(logger)と呼ばれる）やソフトウェアライブラリが提供されている[16]。
収集したログを表示・監視するには、クライアントアプリケーションを使用するか、システム上のログファイルに直接アクセスする必要がある。よく使われるコマンドラインツールはtailやgrepである。ログサーバは、ローカルファイルだけでなく、ネットワーク経由でログを送信するように設定できる。いくつかの実装には、syslogメッセージのフィルタリングと表示のためのレポートプログラムが含まれている。
通信プロトコル
ネットワーク上で動作する場合、syslogはクライアントサーバモデルを採用しており、サーバはクライアントからのプロトコル要求をwell-knownポートまたは予約済みポートで待ち受ける。歴史的には、ネットワークログの用途で使用される最も一般的なトランスポート層プロトコルはUDPであり、サーバの待受けポートは514である[17]。UDPには輻輳制御メカニズムがないため、実装にはTransport Layer Security(TLS)のサポートが必要であり、一般的な使用には[18]TCPのポート6514が推奨される[19]。
制限
プロセス、アプリケーション、オペレーティングシステムはそれぞれ独立して記述されているため、ログメッセージの内容にはほとんど統一性がない。フォーマットや内容については、何の想定もされていない。syslogメッセージはフォーマットされているが（RFC 5424にはABNF（拡張バッカス・ナウア記法）の定義がある）、そのMSGフィールドはフォーマットされていない。
syslogのプロトコルは片方向通信であり、受信側が受信できたことを発信側が確認する手段はない。
今後の展望
syslogの利用は拡大し続けている。様々なグループがsyslogの拡張の標準化を行っており、例えば医療関係での応用などが提案されている[20]。
アメリカでは、SOX法、PCI DSS、HIPPA法などの規制により、企業は包括的なセキュリティ強化を迫られており、それには各種ソースからのログを集め、解析することも含まれている。ログを収集するにはsyslogは最適なフォーマットであり、その解析を行うオープンソースやプロプライエタリのツールも数多く存在する。Windowsのイベント ビューアや他のログフォーマットからsyslogへの変換のためのユーティリティも存在する。
最近では、企業全体のsyslog記録を集めて解析する、マネージド・セキュリティサービス(MSS)が登場している。これは、人工知能的アルゴリズムを適用してパターンを検出し、顧客に対して問題を通報するサービスである[21]。
規格文書
syslogプロトコルは、IETFが発行するRFCによって定義されている。syslogプロトコルを定義するRFCは以下の通りである[22]。
- The BSD syslog Protocol (英語). RFC 3164。 (obsoleted by The Syslog Protocol (英語). RFC 5424。)
- Reliable Delivery for syslog (英語). RFC 3195。
- The Syslog Protocol (英語). RFC 5424。
- TLS Transport Mapping for Syslog (英語). RFC 5425。
- Transmission of Syslog Messages over UDP (英語). RFC 5426。
- Textual Conventions for Syslog Management (英語). RFC 5427。
- Signed Syslog Messages (英語). RFC 5848。
- Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog (英語). RFC 6012。
- Transmission of Syslog Messages over TCP (英語). RFC 6587。
実装例
関連項目
脚注
参考文献
外部リンク
Wikiwand - on
Seamless Wikipedia browsing. On steroids.