目次
syslog Server
Last modified: 2014/06/05
syslogについて。
syslogは、相当初期の頃から存在するLog収集用Daemonであって、その設定方法等は様々な場所に大量に記述されている。 ここでまとめなおしても意味が無いかもしれないが、久しぶりすぎてハマってしまったので、自分の理解の範囲でまとめておくことにする。
前提: NetBSD 6のsyslogd
- syslogは非常に昔から実装されている為、様々なVariantがある。また、syslog-ng等の実装もある。
- 本稿では、NetBSDのDistributionに入っているsyslogd用のsyslog.confを解説する物とする
- でも全部はかけないよ
参考:
syslog.confの設定
syslog は、Daemon やその他の一般アプリケーションの状態や問題などの記録を残すための仕掛けである。この syslog を受け取り記録する為の Daemon が syslogd である。
syslogd の設定ファイルが syslog.conf であり、多くの Unix 系システムでは /etc/
配下に設置されていることが多い。
syslog.conf には、「logの分類(Selector)」と「syslogメッセージの送付先(Action)」を記載する必要がある。従って、syslog.confは以下の形式になる。
1: Facility.Level (Tab) 送付先 : 基本形 2: fac.lv;fac.lv (Tab) 送付先 : 複数のSelectorからのメッセージを、送付先に一括で送る 3: Facility (Tab) 送付先 : Levelを省略 4: fac,fac (Tab) 送付先 : Levelを省略した複数のSelectorからのメッセージを、送付先に一括で送る
上表に示したように、Selectorは
- Selector は
Facility.Level
の形式をしている - Selector は “;” で区切ることで複数記載できる
- Selector が Facility のみで構成される場合、“,”で区切ることで複数を連結して記載できる
という構造になっている。そのFacilityとLevelの内容を下表に記載する。
Facility | 主な用途 |
---|---|
auth | 認証システムからのlog。login(1), su(1), getty(8) など |
authpriv | authと同様。システムによって流儀が異なる。初期設定ではauthと差がない |
cron | cron(8) 用 |
daemon | システムのdaemon用。routed(8)など。このFacilityは、様々なdaemonが利用する |
ftp | ftpd(8) 用 |
kern | kernel用。userland processからのメッセージは含めない |
lpr | プリンター用(本来はLine Printer Daemon用)。lpr(1), lpc(8), lpd(8) など |
メール用 | |
news | NetNews用。現在では、利用されることは稀 |
syslog | syslogd(8) 用 |
user | 様々なユーザープロセスからのメッセージ用。Facilityを指定しない場合のdefault |
uucp | uucp用。現在では、利用されることはまずない |
local[0-7] | 自由に利用できるFacility。local0〜local7まである |
* | 全てのFacilityを意味する |
Level | 意味 |
---|---|
emerg | Panicの状態。システム全域に影響があると考えられる場合に利用される |
alert | 即時対応すべき状態。SystemのDBが壊れた場合等に利用される |
crit | 致命的な状態。HDDの故障等の場合に利用される |
err | エラー。アプリケーション停止等の際に原因等を出力するのに利用される |
warning | 警告。 |
notice | 通知。エラー等の状況ではないが、何らかの対処が望ましい場合に利用される |
info | 情報。何らかの情報を記録しておく為等に利用される |
debug | デバッグ。いわゆるデバッグの為に必要な詳細情報等を出力する為に利用される |
none | このLevelが指定された場合、指定されたFacilityは全て除かれる。 |
* | このLevelが指定された場合、none以外の全てのLevelのメッセージを対象とする |
FacilityのauthとauthprivはNetBSDのDefault設定では差がない。もし分けるなら、Console系のlogin/su/getty等をauthに、Network系のssh等をauthprivにするのも一案である。
Actionには、syslogメッセージの送付先を記述する。送付先には
- log file
- 他のsyslog server
- 何らかのprogram
を記載できる。
Selectorの記述において、Levelを指定した場合、指定したレベルを含む、それよりも重要度の高いメッセージは全て含まれる。
例として、Selectorに“mail.err”を指定した場合、syslogdがActionに送るのは、“mail.err”だけではなく、“mail.crit”, “mail.alert”, “mail.emerge”のメッセージになる。
もし、指定したLevelのみを記録するのであれば、Levelに“=“を付記する。つまり、前の例で言えば、”mail.=err”と指定した場合、“mail.err”のメッセージのみ送付先に送られる。
もし、指定したLevelのみを記録しないのであれば、Levelに“!=“を付記する。つまり、前の例で言えば、”mail.!=err”と指定した場合、“mail.err”のメッセージ以外が送付先に送られる。
Level指定 | 意味 | 例 | 例の意味 |
Level | Level 以上 | mail.err | mail の err 以上を記録する |
=Level | Level だけ | mail.=debug | mail の debug だけを記録する |
!=Level | Level 以外 | mail.!=emerg | mail 全てのうち emerg 以外を記録する |
.none | この Facility は全て除く | mail.none | mail.* は除く |
.* | この Facility の全て | mail.* | mail Facilityに所属する全てを記録する |
ここまでを理解すれば、System付属のsyslog.confは読めるようになる。
拡張
Security保護の観点やlog分析の観点から、logはどこかにまとまっていることが望ましい場合が多い。
例えば、Security保護を考えた場合、あるServer等が乗っ取られた場合に、侵入者は乗っ取りの痕跡を消す行為を行う場合がある。侵入者は、まずlogの改竄を視野に入れる。このとき、logが別マシンにあれば、書き換えることは当然困難になる。
Log分析を考えると、大量のアクセスがある複数のWeb Serverが存在する場合にlogの分析を個別に実施していたのでは、様々な解析を行う際に不便になる。
このような場合に、logを一カ所にまとめてしまえば、log改竄の可能性が減らせ、分析も(少しは)簡単になる。 syslogは、このような局面において、外部のsyslogホストに対してlogを送付することが可能である。
syslogにおけるFacilityは有限であり、これを拡張することは難しい。その状況において、非常に大量のlogを出力するプログラムと、あまりlogを出力しないプログラムが同じFacilityを利用している場合に、かつ、それぞれのプログラムで定義されているFacilityを(設定等で)変更することが困難な場合の為に、送付元のprogramやhostを選別してActionを変えることが可能になっている。
Selector側でのlogの分離(program編)
例えば、snmpdやroutedはlogのFacilityとしてdaemon.*を利用する。仮にsyslog.confで以下のように設定してあるとすると、routedのlogとsnmpdのlogが混ざってしまう。
daemon.* /var/log/daemon.log
しかし、snmpdとroutedでは、log分析の意味が異なる。こういう場合に、daemon毎にlogを分離したい場合がある。
logの分離の為には、以下のように記述する
!-snmpd,routed ←snmpdとroutedを除外 daemon.* /var/log/daemon.log !snmpd ←snmpdのlogのみを扱う daemon.* /var/log/snmpd.log !routed,gated ←routedとgatedのlogのみを扱う daemon.* /var/log/routing.log
Selector側でのlogの分離(host編)
別のホストから送られてくるlogを分離したい場合には、以下のように記載する。
- 自分自身のlogを/var/log/localhost以下に記録
- web1から送られてきたlogを/var/log/web1以下に記録
- dialerから送られてきたpppのlogを/var/log/dialer以下に記録
する例を記載する
+@ # ←localhostからのlogを記載するセクション *.err;kern.*;auth.notice;authpriv.none;mail.crit /dev/console *.info;auth,authpriv,cron,ftp,kern,lpr,mail.none /var/log/messages kern.debug /var/log/messages auth,authpriv.info /var/log/authlog cron.info /var/log/cron ftp.info /var/log/xferlog lpr.info /var/log/lpd-errs mail.info /var/log/maillog #uucp.info /var/spool/uucp/ERRORS !* # ←全てのsyslog通信を受け取る +web1 # ←web1からのlog *.err;kern.*;auth.notice;authpriv.none;mail.crit /var/log/web1/console *.info;auth,authpriv,cron,ftp,kern,lpr,mail.none /var/log/web1/messages kern.debug /var/log/web1/messages auth,authpriv.info /var/log/web1/authlog cron.info /var/log/web1/cron ftp.info /var/log/web1/xferlog lpr.info /var/log/web1/lpd-errs mail.info /var/log/web1/maillog *.* /var/log/web1/other.log !pppd # ←pppdからのlog +dialer # ←dialerからのlog *.* /var/log/dialer/pppd.log
なお、ここでホスト名(web1,web2等)を記載しているが、ホスト名の代わりにIP Addressでも構わない。 ホスト名を利用する場合は、DNSを使わず、/etc/hostsに記載しておくことを推奨する。 これは、DNS Serverを用いた名前解決が失敗した場合に、logがなくなるからである。
Selector側での分離の文法
上記分離の記法は、以下のルールに従う。
- Stringで指定されたホスト名、Program名、もしくは文字列に一致する情報のみを、Selector Actionの集合に適用する。
#!+String1,String2 !+String1,String2 #+String1,String2 #!String1,String2 !String1,String2
- Stringで指定されたホスト名、Program名、もしくは文字列に一致しない情報のみを、Selector Actionの集合に適用する。
#!-prog1,prog2 !-prog1,prog2 #-prog1,prog2
- 全てのプログラム、ホスト、文字列を取り扱う
!*
なお、ホスト名に“@“を指定した場合、localhostの意味になる。
記号等について以下にまとめる。
文字 | 意味 |
---|---|
(TAB) | 「Selector」と「Action」の区切 |
; | 「Selector」 をつなぐ |
= | 「Level」を限定する |
!= | それ以外の「Level」 |
@ | 自機 |
+ | ホスト名、プログラム名の指定したものを加える |
- | ホスト名、プログラム名で指定したものを除外する |
! | プログラム名、ホスト名、文字列の指定 |
# | 通常は注釈。!や+,-と組み合わせた場合、ホスト名・プログラム名、文字列の指定に使う |
, | Facilityをつなぐ |
* | 全て。何でも |
. | 「Facility.Level」のように「Facility」と「Level」をつないで、「Selector」を作る |
none | 除外 |
Actionへの記述
Actionには、Logを出力する先のファイル名、Logを送りつけるホスト名、Log処理を実行するプログラム、loginしているユーザー等を記載できる。
以下、Actionの例
1. ファイルに出力する場合 cron.info /var/log/cron →送られてきたメッセージを/var/log/cronに追記する 2. 他のホストに転送する場合 cron.info @loghost →送られてきたメッセージをloghostに対して送る 3. 他のホストに転送する場合(TLSを使う場合。試験していないので間違いがあるかも) cron.info @[loghost]:1234(fingerprint="SHA1:01:02:...") →loghostの1234番ポートにTLSでメッセージを送る。 fingerprint以下は認証に利用する 4. プログラムを利用してlogを加工する cron.info |exec /usr/local/sbin/cronfilter →送られてきたメッセージを/usr/local/sbin/cronfilterで処理する 5. loginしているrootとuser1に対して送る cron.info root,user1 6. loginしている全ユーザーに対して送る cron.info * 7. システムのコンソールに出力する cron.info /dev/console
注意点
- syslogdは、出力先のファイルを自身で作成しない。そのため、touch /var/log/daemon.log等を実行して、事前に出力先ファイルを作成する必要がある。
- syslogdに設定ファイルを再度読み込ませるには、HUPシグナルを送る。つまり、kill -HUP [syslogdのPID]を実行すれば良い
- syslog.confをdebugしたい場合には、syslogdに-d -vをつけて起動すれば良い
- 現時点では、wtmp/wtmpx/lastlog/lastlogx をremoteに転送する方法が不明。
- これらは、BinaryのDatabase Fileで、login(1)等が直接記録する。そのため、syslogの仕組みを利用していない。
- 現在は、pam_lastlogがこの辺を制御しているのだが、pamを利用してremoteにlogを飛ばすことは(今のところ)やり方が解らない(or できない)
- 同様に accounting (accton(8))の機能が出すlogもremoteに飛ばす方法が不明。
- syslogではなく、rwhodやewhodを使って擬似的に収集する方策があることが判明。これはこれから調査
logのrotate
syslogは、自身では、logメッセージを「追記するだけ」なので、放っておくとlogファイルが巨大になる。これでは困るので、logをrotateするべきである。
logをrotateさせるのがnewsyslogで、その設定ファイルが/etc/newsyslog.confである。
こちらは、それほど難しくないので、詳細はman newsyslog.confを参照のこと。