syslogとは？RFCと歴史から考える

syslog（シスログ）とは？

syslogとは、ネットワークやシステムで出力されたログメッセージを統一化、一元管理するための規格、枠組みのことです。

syslogは取り扱い範囲が非常に広く、歴史的な経緯も相まって、文脈や意図によって様々なニュアンスを持ちます。用いられる例としては、以下のようなものが挙げられます。

通信プロトコルとしてのsyslog

syslogサーバなどの特定サーバにログを送る通信プロトコルのニュアンスで使うケースです。

例えば「ログを収集するためにファイアウォールでsyslog通信を許可してほしい」という場合は、「ログを収集するためにファイアウォールの設定変更を行い、ログの出力元からログ集約サーバに対してUDPの514ポートを通信可能にしてほしい」という意味になります。

ログのフォーマットとしてのsyslog

実際に出力されるログメッセージのフォーマットにフォーカスしたニュアンスで使うケースです。

例えば「syslog形式のファイアウォールのログを分析したい」といった表現が該当します。こちらは出力されたログメッセージの文書フォーマットを指しており、「ログメッセージに出力されている情報（例えば、送信元IPアドレスなど）を分析したい」という意味になります。

ツールとしてのsyslog

ログを外部に転送するツールを指すようなケースです。

例えば「Linuxのsyslogを使って、ログを集約したい」といった表現が該当します。こちらは「大抵のLinuxに含まれるrsyslogのようなツールを使用して、特定サーバにログを送信してログを集約したい」という意味になります。

アウトプットとしてのsyslog

ログそのもの、システムログの略称に近しい感覚で使われるケースです。

例えば「Windowsイベントログとsyslogを集約して分析したい」といった表現などが該当します。こちらを意訳すると、「Windowsイベントログとシステムログ(一般的なLinuxのディストリビューションにおける/var/log配下にあるようなログ)をそれぞれ一か所に集め、横断して分析したい」という意味になります。

syslogは立場や役割により概念が変わる

上記でご紹介したものは、人によっては聞いたことがなかったり、「それは違うだろう」と思うケースもあるかと思います。しかし、いずれの言葉もsyslogの一側面をとらえており、必ずしも全て間違っているとは断言できないと筆者は考えます。

syslogは幅広い概念を有しており、ネットワーク機器やOS毎に様々な実装のされ方をしています。そのため、ネットワーク担当者や運用保守メンバーなど立場や役割によってとらえ方が変わる概念でもあります。ご紹介した例のように、各々一側面の色が濃すぎるが故に発言者の意図をとらえないと認識齟齬が発生することがあります。

そこで「syslogとはそもそも何か」を本記事では改めて考えていきます。

>>syslogを効率的に管理したい方はこちら

syslogの歴史

syslogを改めて考えるにあたり、初めに歴史的な推移を考えてみましょう。

1.  1980年頃：syslogの誕生

syslogはSendmailのプロジェクトの一環として、エンジニアEric Allmanの手によって生まれ、BSD/OSと呼ばれるUNIX系のOSに導入されました。

はじめのsyslogはログメッセージを単純なテキストファイルとしてアウトプットするだけでした。しかし改良を重ねるうちに、ユーザーが異なるシステム上のログメッセージを収集および管理するための手段・規格として確立されていきました。

2. 2001年頃：公式化したsyslog(RFC3164/通称：BSD形式 文書化)

当初はSendmailにのみ適用されていました。しかし運用を行うにあたり有益だったため、他のアプリケーションにも次第に採用されはじめ、UNIX系の標準的なログの取り決めとなりました。

当初は正式な公開仕様がなく、互換性がないものも散見されました。そこで、インターネット技術の標準化を推進するIETFが調査を行い、その結果をデファクトスタンダードとして2001年の8月にRFC3164として文書化しました。

これによってsyslogの形が浮き彫りにされ、一般化されることになりました。また、同時期にsyslogの信頼性を高めることを目的としたRFC3195なども発行されました。

3. 2009年頃：整理され、改良されたsyslog(RFC5424/通称：IETF形式 文書化)

RFC3164はあくまでも、実際に使われているデファクトスタンダードを形にしたものであったため、フォーマットをより洗練する必要性や、不正が行われる余地が大きいなど課題が残っていました。

将来の拡張性や既存の改善を図るため、IETFがフォーマットを定めて規格化を行い、RFC5424として文書化されました。現状、syslogにおけるメインストリームのRFCは、このRFC5424です。

次いで、RFC5424で明示化していないトランスポート層プロトコルとしてUDPを使うことを想定したRFC5426や、将来的に使う規格としてTLSを用いたことを想定したRFC5425も発行され、syslogが盤石になった時期であると言えます。

4. 2010年以降：syslogの更なる拡張

執筆時点では主流ではありませんが、時代の変化からTLS のUDP版とも言うべき、DTLSを想定したsyslogとしてRFC6012が文書化されるなど、更なる拡張がされました。2012年には、TCP を用いたsyslogで観察された事柄を取りまとめたRFC6587が文書化されています。

ここまでご紹介したように、syslogは40年以上の歴史があります。更に複数のRFCが関わり扱われる範囲も広いため、意図することが人それぞれになるのも致し方ないと言えます。

RFCから紐解くsyslog

syslogは歴史的に長い期間を経て、RFCに遷移があったことはご理解いただけたかと存じます。では「syslogとは何か」をある種の技術標準仕様として扱われるRFCから紐解いていきましょう。

RFCとは、Requests for Commentsの略であり、The Internet Engineering Task Force(IETF)という組織が管理しているインターネット技術の標準仕様を指します。先ほどの歴史でお話をしたことと重なる部分も多いですが、syslogに関連するRFCは以下の通りです。

syslogには様々なRFCが存在しています。現時点で特にsyslogにとって重要なのが、RFC3164(BSD形式)とRFC5424(IETF形式)です。それ以外は、主にRFC5424を補完するような位置づけや提案の類のものとなります。

やっかいな点として、RFC5424が文書化されことを契機にRFC3164が廃止されたのですが、現実問題としてRFC3164基準の規格で動作するものが存在することが挙げられます。単にsyslogと述べても、どちらの準拠レベルで話しているかにより前提が変わってしまいます。

次に「syslogとは何か」ということを明確に記載しているRFC3164(BSD形式)とRFC5424(IETF形式)について、それぞれお話させていただきます。

RFC3164 (BSD形式)

RFC3164は、文書化される前のデファクトスタンダードを取りまとめたものになります。

RFC3164においてsyslogは、ログを転送する「リレー」、ログを受信・収集する「コレクター」、ログを出力する「発信元」の最大3種類の要素から構成されるログのやり取りを行う規格とされています。

基本的にはトランスポート層の通信プロトコルとしてUDP(基本のポートは514)を利用します。ペイロード(※データ本体の様なもの)であるログメッセージのフォーマットは以下のように定義されています。

BSD形式は「PRI」、TimeStampとHostnameからなる「HEADER」、Message部分の「MSG」の3つ部品から成立し、各要素はそれぞれ以下の意味となっています。

また、PRI部分以降の長さは「1024Byte未満」であることと記載されています。

RFC5424 (IETF形式)

RFC5424は、RFC3164 (BSD形式)の欠点などを補完して発展させたものです。そのため共通項目は多いですが、整理かつ再定義されたものとなっています。

RFC5424を意訳してお話しますと、syslogはメッセージ情報となる「コンテンツ」、それを処理（生成、解釈、格納、転送）する「アプリケーション」、ネットワークでのやり取りを司る「トランスポート」の3つのレイヤーで構成されます。

アプリケーションは、ログ転送を担う「リレー」、ログを受信・収集する「コレクター」、ログを出力する「発信元」の3種類の役割が存在します。

トランスポートは、通信プロトコルについて言及しているものですが、RFC3164と異なり特定のトランスポート層通信プロトコルを指定していません。その代わりに他のRFCで言及されています。例えば、RFC5426ではUDPを介したsyslogメッセージのやり取りについて言及しています。

大まかなイメージとしては以下の通りです。

またペイロードでありコンテンツの一部である、ログメッセージのフォーマットもRFC3164と異なり次のように定義されています。

IETF形式

IETF形式は大別すると、PRIやタイムスタンプMSGIDなどを含んだHEADERと任意で付与された構造化データであるSTRUCTURED-DATA、メッセージ部分であるMSGの3つに大別され、それぞれに細かい要素が存在します。

また、パケット長についても「最大2048Byteを目安とすべき」としています。

補足：PRI (FacilityとSeverity)について

RFC3164(BSD形式)やRFC5424(IETF形式)には、PRIというフィールドが存在しています。これらは、Facilityコードを8倍にしてSeverityコードの和の値が記載されます。

Facilityとは、どのようなログなのか出力元の分類をするための値です。いずれのRFCでも以下のように定義されています。

内容が一部重複していますが、これらは慣例的に使われているために同じ内容となっています。RFC3164時点で調査した内容が反映され、RFC5424ではそれを踏襲したという経緯です。

対して、Severityはそのログの緊急度を示します。

上記はいずれもプログラムなどにより任意で決定しており、値が曖昧なケースがあります。言わば目安であるため、これらの値を利用して監視・分析などを行う際には注意が必要です。

syslogの実装：「rsyslog」

RFCの観点からsyslogがどのようなものかをお話させていただきましたが、実際にはどのようにsyslogは実装されているのでしょうか。ここからは、rsyslogを例にお話させていただきます。(本記事はrsyslog V8を基準に記載しております)

「rsyslog」とは

rsyslogとは、ローカルもしくはリモートサーバのログを管理するオープンソースのソフトウェアデーモンのことです。CentOSやRHELなどLinuxのディストリビューションでも利用されてます。また、フィルタリング機能やTCPによるログの受信もできます。

rsyslogの構成要素としては、いくつかのインプットモジュールとアウトプットモジュールが存在しています。以下では、主なモジュールをご紹介します。

インプットモジュール

imjournal

journaldが収集したログを収集するためのモジュールです。主にローカルで出力されたログを集めるために使います。

imudp

UDPで転送されてきたログを受け取るために利用するモジュールです。rsyslogを使ってログ中継サーバやログ集約サーバを作りたいときに使います。

imtcp

TCPで転送されてきたログを受け取るために利用するモジュールです。rsyslogを使ってログ中継サーバやログ集約サーバを作りたいときに使います。

アウトプットモジュール

omfile

ログファイルを出力するためのモジュールです。内容によって異なるファイルに出力することなども可能です。

omfwd

別なサーバに転送するためのモジュールです。通信プロトコル等は設定ファイルで指定します。

上記のモジュール群をコントロールする設定ファイルrsyslog.confが存在し、それが各モジュールの挙動を制御しています。そのため、ローカルのログをファイル出力したり、他のサーバにログを中継したり、ログを集積するsyslogサーバとして利用したりなどができます。下記に特徴と挙動をまとめたイメージを記載します。

 

rsyslogを制御する「rsyslog.conf」

rsyslogにはログの「収集、出力、転送」など様々な機能がありますが、それらはいずれも設定ファイルで制御されます。複雑な設定も可能ですが、本記事ですべて記載すると量が多くなるため、使用頻度の高い設定のみをご紹介します。なお設定変更した場合、サービスの再起動が必要となるためご注意ください。

MODULES

有効化するインプットモジュールを指定します。通常デフォルト設定では、以下の設定が有効になっています。こちらが、journald経由のログを取得するものとなっています。

また、syslogサーバ(ログ中継サーバやログ集約サーバ)として活用したい場合、以下の記述を追記する必要があります。(デフォルトではコメントアウトされており、#を消すことで有効化できます)

UDP、ポート514を利用してログを受信したい場合

TCP、ポート514を利用してログを受信したい場合

GLOBAL DIRECTIVES

rsyslog全体にかかわる様々な制御内容を記述します。例えば、ワークディレクトリの指定や、個別の設定ファイルの読み取り先指定、ログメッセージのフォーマット変更などが該当します。

明確な要件がない限りは変更しないことが多いですが、自由度の高い変更も可能です。

例えば、タイムスタンプの形式に年情報を含みたい場合、下記のように「$ActionFileDefaultTemplate」の値をデフォルト値「RSYSLOG_TraditionalFileFormat」から「RSYSLOG_FileFormat」に変更することで、年情報が含まれるようになります。

設定値の意味は以下の通りです。

なお本記事で詳細は触れませんが、Templateと呼ばれる機能が存在しており、ログの出力フォーマットや動的な出力先生成などを操作することができます。ログの高度な分析などを行う関係でフォーマットを変えたいといった場合は、rsyslogのドキュメントを一読するとよいかもしれません。

RULES

こちらの記載に従って、ログファイルにログを書き込むよう動作します。ルールの基本的な記載方法は以下のようになっています。

[Facility].[Severity] [出力先 / 指定したテンプレート条件]

[Facility].[Severity]の組み合わせは「；」で区切ることで複数指定できます。Severityは、指定した以上の値全てが対象となります。反対に「none」を指定することで、無効化できます。

Linuxのサーバで目にする機会の多い「/var/log/messages」への出力もrsyslogが担っており、以下のようなデフォルト設定として記載されています。

こちらの具体例を説明しますと、以下4つの条件に合致するものを「/var/log/messages」に出力するとしています。

• 「*.info」：全てinfoレベル以上のもの
• 「mail.none」：mailではないもの
• 「authpriv.none」：authprivではないもの
• 「cron.none」：cronではないもの

基本的には、上から記載されているルールから順番に適用されます。また、ログが複数ルールにわたり適用されることもあります。なお、比較演算子や式、プロパティを使ったルールを作成することも可能です。複雑なフィルタを実装したい場合は一度、rsyslogのドキュメントを一読するとよいかもしれません。

begin forwarding rule

こちらの設定箇所は、外部の別サーバにログを転送する設定を記載します。デフォルトでは有効な記載はありませんが「ログ集約サーバにログを送りたい」という要件を実現する際に変更することが比較的多いように見受けられますので、設定例をご紹介します。

UDP、ポート514を利用してログを別サーバに送信したい場合

TCP、ポート514を利用してログを別サーバに送信したい場合

rsyslogの大まかな設定は以上になります。実は多機能であり、2023年6月に安定版(8.2306.0)がリリースされるなど、現在もメンテナンスや新機能の追加などが続いています。

「syslog」でログを収集した後は？

syslogは歴史も古く、ルーツは1980年代までさかのぼります。それだけ以前から、システムを運用する上で特定の場所にログを集約し、ログのフォーマットを統一化して管理することのメリットが大きいことの裏返しでもあります。

しかし、昔はrsyslogなどでログを集約し、コマンドでログを確認できる状態でも問題はありませんでした。しかし現在はログの増加や時代背景に伴い、ただ収集や閲覧するだけではなく、様々な目的のために、ログの扱い方が重要になってきました。ここからは、代表的な目的を3つご紹介します。

システム運用保守・障害対応

ログから平常時はシステムが正常に動作しているかを確認し、異常時にはエラーをトラッキングするなどをして円滑にシステムの運用保守を行うために収集します。大量のログからピンポイントで必要な情報をサマライズしてレポート出力することや、エラーを検知できる必要があります。

フォレンジック・セキュリティ利用・ガイドライン準拠

近年、避けることが困難なサイバー脅威への対策としてログの活用が不可欠であり、各種ガイドラインにもログ監査を行うことが必須条件となってきました。そのため、インシデントの原因や範囲を特定するため、複数種類のログを横断して検索・追跡することや、ログを包括的に確認し傾向分析できるレポート出力機能などが必要になります。

サービスのデータ分析

特定サービスのログを集め、サービスの状況を分析し知見を得て、業務上の判断を行います。例えば、Webページのアクセスログを収集してアクセス傾向を分析し、最適なサービスの追加を行うというシナリオです。

ログを集めるだけという時代から、多様なログを収集して統合管理し活用しなければならない時代にシフトしています。今もなお、ログの収集に不可欠であるsyslogは、まさにシステム運用における縁の下の力持ちと言えるでしょう。

ログを統合して管理できる「Logstorage」

統合ログ管理システム「Logstorage」は、統合ログ管理を簡単に実現するための製品として、syslogの円滑な収集と活用を支援します。

Logstorageとは様々なシステムに異なるフォーマットで散在するログを管理・分析する純国産の統合ログ管理システムです。内部統制、情報漏えい対策、サイバー攻撃対策、システム運用監視など多様な目的に対応できる、統合ログ分野でのデファクトスタンダード製品です。官公庁や金融業、通信業を中心に5100社以上が導入しており、統合ログ管理ツール分野シェア17年連続No.1となっています。

Logstorageは、UDP・TCＰ問わずログを受け取ることができる「syslogレシーバ」と呼ばれる機能が備わっています。syslogで送信されたログを簡単に保管でき、RFC3164形式のように年情報がない場合でも、「年補正機能」といった補助機能により年情報を正しく補完する機能が備わっています。また、一部のネットワーク機器のように複雑なログメッセージの文体であっても「ログフォーマット定義」と呼ばれる機能で、ログの意味付けを行い、より多様なログの検索や集計を実現できます。さらに、rsyslogなどを使ったsyslogサーバとは異なり、Windowsイベントログやクラウドのログも収集し、様々なログを横断して分析検索することも可能です。

ご興味がございましたら、下記リンクから商品紹介ページをご覧いただくか、試用版のご利用をご検討いただければと存じます。

>>Logstorage製品ページはこちら

 主な参考文献

• • Wikipedia 「Syslog」
  • Wikipedia 「Rsyslog」
  • RFC3164 「The BSD syslog Protocol」
  • RFC5424 「The Syslog Protocol」
  • RSyslog Documentation