syslog
作者 エリック・オールマン
初版 1980年代
対応OS Unix系
種別 システムログ記録
公式サイト datatracker.ietf.org/wg/syslog/charter/ ウィキデータを編集
テンプレートを表示

syslog（シスログ）は、ログメッセージをIPネットワーク上で転送するための標準規格である。"syslog" という用語は、その通信プロトコルを指すだけでなく、syslog メッセージを送信するシステム（アプリケーションやライブラリ）syslog メッセージを受信し報告・分析するシステムに対しても使われる。syslogの各メッセージには、そのメッセージを生成したシステムの種類を示すファシリティコードが付与され、重大度が設定される。

システム管理やセキュリティ監査の目的だけでなく、一般的な情報提供、分析、デバッグ用にも用いられる。多くのプラットフォームで、プリンタ、ルータ、メッセージレシーバなど、様々なデバイスが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]。

ファシリティコード キーワード 説明
0kernカーネルメッセージ
1userユーザレベルメッセージ
2mailメールシステム
3daemonシステムデーモン
4authセキュリティ/認証メッセージ
5syslogsyslogdが内部で生成したメッセージ
6lprラインプリンタ・サブシステム
7newsネットニューズ・サブシステム
8uucpUUCPサブシステム
9cronCronサブシステム
10authprivセキュリティ/認証メッセージ
11ftpFTPデーモン
12ntpNTPサブシステム
13securityログ監査
14consoleログ警告
15solaris-cronスケジューラ・デーモン
16–23local0 – local7ローカル使用のファシリティコード

ファシリティコードとキーワードの対応は、OSやsyslogの実装によっては異なる場合がある[9]。

重大度レベル

規格で定義された重大度レベル(severity level)は以下の通りである[10]。

値重大度キーワード非推奨
キーワード		説明状態
0Emergencyemergpanic[11]システム使用不可パニック状態[12]。
1Alertalert早急な対処が必要システムのデータベースが破損しているなど、すぐに修正すべき状態[12]。
2Criticalcrit致命的な状態ハードデバイスのエラー[12]。
3Errorerrerror[11]エラー状態
4Warningwarningwarn[11]警告状態
5Noticenotice正常だが注意が必要な状態エラー状態ではないが、特別な処理を必要とする可能性のある状態[12]。
6Informationalinfo通知メッセージプログラムが期待通りに動作していることの確認。
7Debugdebugデバッグメッセージ通常、プログラムのデバッグ時にのみ使用される情報を含むメッセージ[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]。

実装例

関連項目

脚注

  1. ↑ “Eric Allman”. Internet Hall of Fame. 2017年10月30日閲覧。
  2. ↑ “3 great engineering roles to apply for this week” (英語). VentureBeat (2021年8月6日). 2021年8月16日閲覧。
  3. ↑ “Efficient and Robust Syslog Parsing for Network Devices in Datacenter Networks”. 2021年11月17日閲覧。
  4. 1 2 rfc 5424.
  5. ↑ “LXer: Patent jeopardizes IETF syslog standard”. 2021年11月17日閲覧。
  6. ↑ “IETF IPR disclosure on HUAWEI's patent claims”. 2021年11月17日閲覧。
  7. ↑ “Syslog Facility”. 22 November 2012閲覧。
  8. ↑ rfc 5424, p. 9.
  9. ↑ “The Ins and Outs of System Logging Using Syslog”. SANS Institute. 2010年4月15日時点のオリジナルよりアーカイブ。2021年11月17日閲覧。
  10. ↑ rfc 5424, p. 10.
  11. 1 2 3 “syslog.conf(5) - Linux man page”. 2017年3月29日閲覧。
  12. 1 2 3 4 5 “closelog, openlog, setlogmask, syslog - control system log”. 2017年3月29日閲覧。
  13. ↑ “Severity Levels for Syslog Messages”. docs.delphix.com. 2021年8月16日閲覧。
  14. ↑ rfc 5424, appendix-A.1. "This document describes a layered architecture for syslog. The goal of this architecture is to separate message content from message transport while enabling easy extensibility for each layer."
  15. ↑ Transmission of Syslog Messages over TCP (英語). April 2012. doi:10.17487/RFC6587. RFC 6587。
  16. ↑ “logger Command” (英語). www.ibm.com. 2021年8月16日閲覧。
  17. ↑ “Syslog Server”. www.howtonetwork.com. 2021年8月16日閲覧。
  18. ↑ rfc 5424, section-8.6.
  19. ↑ TLS Transport Mapping for Syslog (英語). March 2009. doi:10.17487/RFC5425. RFC 5425。section-7.1
  20. ↑ “ATNA + SYSLOG is good enough”. Healthcare Exchange Standards (2 January 2012). 2018年6月6日閲覧。
  21. ↑ Yamanishi, Kenji; Maruyama, Yuko (2005-08-21). “Dynamic syslog mining for network failure monitoring”. Proceedings of the eleventh ACM SIGKDD international conference on Knowledge discovery in data mining. KDD '05 (Chicago, Illinois, USA: Association for Computing Machinery): 499–508. doi:10.1145/1081870.1081927. ISBN 978-1-59593-135-1.
  22. ↑ “Security Issues in Network Event Logging (syslog)”. IETF. 2021年11月17日閲覧。

参考文献

外部リンク

⌬ Phoenix Mesh CID: 未登録 IPFS未登録 📡 0ピア N=1 CRITICAL PQS B76