HOME情報セキュリティ資料・報告書・出版物調査・研究報告書情報セキュリティ技術動向調査(2008 年下期)

本文を印刷する

情報セキュリティ

情報セキュリティ技術動向調査(2008 年下期)

3 SYSLOG技術動向

太田 耕平

1 はじめに

  本稿では、古くから、そして現在もTCP/IP環境でのログ収集のために広く利用されているSYSLOGプロトコルの標準化および技術動向について述べる。

2 SYSLOG標準の現状

  SYSLOGはインターネット初期からのロギングのためのデファクト標準となっており、UDPをトランスポートとし、そのシンプルさ、実装と運用の容易さから、純粋な記録以外にも、ウイルス・侵入検知などのセキュリティアラートなどの目的にも広く利用されている。
  しかし、実際のところそのプロトコルは十分には文書化されておらず、現在のよりどころはINFORMATIONALとして発行されているRFC 3164, “The BSD syslog Protocol”[1]だけである。これはトランスポートにUDPを用いており、信頼性を保障せず、認証、暗号化などの一般的なセキュリティ対策もないものとなっており、すなわち、

  •   暗号化がないことでシステム情報の盗聴は極めて容易であり、
  •   認証がないことで、偽のログメッセージを簡単に挿入でき、
  •   信頼性を保障していないため、重要なログの欠落を知ることも防ぐこともできない

  このことは、現実問題として、現状では今日のセキュリティ状況に見合わない脆弱なロギングシステムが一般的ロギングシステムとして利用されていることを示している。

  この状況を改善するため、IETFのSYSLOG WGでは、RFC 3195 “Reliable Delivery for syslog”[2]を策定し、TLSとBEEPによる安全なSYSLOGの標準化を目指した。しかし、この標準案は包括的なセキュリティ機能と引き換えにSYSLOGの美点であった簡便さを大きく損ない、従来のSYSLOGからのギャップも大きく多くの利用者・開発者に敬遠される結果となった。
  そのため、RFC 3195自体は、大幅に簡素化しdraft-lear-ietf-syslog-rfc3195bis-01のindividual-draftとして再提案することとなり、SYSLOG WGとしては、要件をさらに精査することで必須部分を抽出し、それぞれの部分を以下のように分割して標準化を目指している。

  •   メッセージフォーマットを策定する本体部分
      The syslog Protocol, RFC5424として2009年3月に発行
  •   従来のUDPによるSYSLOGに相当するUDPトランスポート部分
      Transmission of syslog messages over UDP, RFC5426として2009年3月に発行
  •   RFC3195の必須部分を抽出し、TCPによる信頼性を前提としたTLSトランスポート
      部分
      TLS Transport Mapping for Syslog, RFC5425として2009年3月に発行
  •   複数のCollectorにSYSLOGメッセージを振り分ける際の署名部分
      Signed syslog Messages, draft-ietf-syslog-sign-24.txt

  さらに、前述のように、SYSLOGはその重要性にもかかわらず、システムの稼働状況に対する管理が行なえないことから、管理性についての標準化も進められており、最初のステップとしてTextual Convention MIB(Textual Conventions for Syslog Management, <draft-ietf-syslog-tc-mib-08.txt>)の標準化が議論されRFC5427として2009年3月に発行され、他の管理標準案からの参照と利用も始まっている。しかし、本体部分については議論が遅れており、新たに整備されつつある新しいSYSLOG体系の中での大きな穴となっている。
  図 1に、2009年1月現在のSYSLOG関連プロトコルの標準化状況を示す。基本的なプロトコルのほとんどがIESGによるレビューを完了し、RFC番号の割り当てを完了しており、2009年3月よりRFCとして順次発行されている。

図 1 SYSLOG関連プロトコルの標準化状況

3 SYSLOG実装の現状

  SYSLOGは、その重要性に対して、運用面での現実的な問題があまり考慮されてこなかったが、従来の技術的な運用管理の用途のみならず、監査などの用途の需要が高まるにつれ、その信頼性、完全性が大きな問題となっており、現在利用されている実装についても重要な調査がなされている。
  Marcus Ranumらは、USENIX2005およびSANS (SysAdmin, Audit, Network, Security) のロギングについての包括的なチュートリアルでSYSLOG運用の問題点についてもRFC 3164の内容と対比して指摘している。当時の一般的な構成で、現在標準的に使われているUDPを利用したネットワーク経由でのログ収集では、場合によっては99%以上のメッセージが失われることがありえることを指摘しており、一つの巨大なログサーバよりも、集約用の小型のログサーバを分散配備して、そこから中央のサーバに暗号化の上、信頼性のあるトランスポートで送信するようにすることが望ましいことを指摘している[3]
  また現在の一般的な環境で広く利用されている複数の実装でも、何らかの理由でメッセージ落ちが発生しても送信側、受信が双方でメッセージの欠落を知ることができない。最も伝統的なsyslogdでは日常的なメッセージ落ちの発生が報告されている[4][5]。メッセージ落ちの多くは秒間1000個以上のSYSLOGメッセージの発生時であり、その際はSeverityなどの重要性を考慮することなく発生順に破棄される。このようなログはディスク溢れやデーモンの設定ミスなどの障害時などにも起こりうる。
  また、最新の実装として知られているsyslog-ngやrsyslogでは基本性能が大きく改善されるとともにTCPによるリモートロギングのサポートなどにより信頼性が大きく向上しているが、ログの欠落が発生するケースが依然として残っている。具体的には障害などによってネットワークが長時間不通になり、サーバとのTCPコネクション自体が切断されてしまうようなケースに対する対応は十分ではない。例えば、Linuxの標準設定ではネットワークの不通状態が約15分を過ぎるとTCPコネクションが切断されてしまうため、その期間に発生したメッセージはコネクションと共に失われてしまう。同様の問題はSYSLOGプロトコル本体の著者であるRainer Gerhardsによっても指摘されており[6]、アプリケーションレベルでの信頼性を確保するためにRELP (Reliable Event Logging Protocol)を提案し、そのライブラリ実装を公開している[7]
  重要な点は、ログ情報はあらゆる監査や障害に対応する際の最後の砦ともいえる役割を担っていることである。そのため、様々な手段・レベルで信頼性を確保することが重要である、さらに重要なのは、管理者がログ情報を信頼するために、ログ収集システムそのものの信頼性を知ることができることである。つまり信頼性の確保をどこまでどのようにやるかの問題の基礎として、ログ収集システムの運用状況を管理するための機能が不可欠であるといえる。

4 まとめ

  本稿では、広く普及し、重要な役割を担っているSYSLOGプロトコルの現状について、標準化および技術の動向をまとめた。
  長く議論されてきたその仕様は、2009年1月現在、複数の要素に分割され、その基本要素の策定がほぼ完了している。
  セキュリティと信頼性を考慮した新しいSYSLOG標準により、現在大きく欠けているセキュリティ上のギャップをうめ、システムの基盤として欠かすことのできないロギングシステムに他のシステムと同じ水準のセキュリティを期待することができるようになる。
  一方で、トランスポートより上位の信頼性、および大規模システムでの適切な配備と管理の方法など、運用・管理面での標準化はまだ途上であり、残された課題となっている。

以上

参考文献

[1] RFC 3164, “The BSD syslog Protocol, August 2001, C. Lonvick”

[2] RFC 3195, “Reliable Delivery for syslog, November 2001, D. New, M.Rose”

[3] Marcus Ranum, “System Logging and Log Analysis”,
  http://www.ranum.com/security/computer_security/archives/logging-notes.pdf

[4] 細内 昌明, 山崎 謙太, 森田 滋, 中島 藤夫, 大辻 彰, 三瓶 英智,「ミッションクリティカル向けsyslog改善機能の提案と実装」, Linux Conference 2008.

[5] 角田 裕,丸山貴史,阿部 智,太田耕平,和泉勇治,キニ グレン マンスフィールド,根元義章,「ログの重要度に基づいた適応型送信制御による効率的なログ転送方式の提案」, 電子情報通信学会技術研究報告 Vol.107, No.530, CS2007-78, pp.27-32, Mar. 2008.

[6] Rainer Gerhards, “On the (un)reliability of plain tcp syslog...”,
  http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html

[7] librelp − a reliable logging library,
  http://www.librelp.com/

目次へ
次へ