Ubuntu18.04 Logcheck

従来運用しているシステムではLogcheckが動いていて、様々なログが日に2回(そんな設定にしている)送られてきている。だが、実は見ていない。最初のうちは見ていたのだが「攻撃されているな」「防いでいるな」が見えて安心していただけで飽きてしまったのだ。

今になってみてとっておけば良かったな、と思うのは例えば

各種サービスが何らかのエラーを出したとき。
スパム対策技術S25Rで450(要求されたアクションは実行されませんでした)を返送したとき。

なんじゃないのかなと。よくよく考えてみれば「防いでいる」情報は防いでいるんだから問題ないわけで、本当に見たいログは別にあったのだった。

※なお、egrepの条件とmatchすることを一般に「一致」と表現するけれど、個人的には「適合」の方がよりmatchする気がしてしまい、この投稿では「適合」とか「照合」とか表現してみているので読みづらいかもしれません。

今回やったことはこれ。もっとサクサク終わると思ったけど、翻訳に時間がかかっちゃって一週間以上を費やしてしまった。

Logchekのインストール
出力されるログを制御
- ディレクトリ構成
- 欲しい情報をSECURITY EVENTSで取り出す ※S25Rログはココで検知
- いらない情報をSECURITY EVENTSから除外する
- いらない情報をSYSTEM EVENTSから除外する
- テスト
やったこと
- README.logcheck-database(翻訳風)
- logtailのオフセットファイル

Logchekのインストール

これから行う作業はREADME.logcheck-databaseをよく読んでから実施した方が安全。READMEを読まなきゃできないほど難しい作業でもないが、長い期間安心・便利に使うには読んでおいた方がお得。自分の理解を深めるために翻訳してみたものを下の方に載せているのでご参考まで。

インストール

Logcheckと合わせて、諸先輩方が作り上げたフィルタパターンのdatabaseも一緒にインストールしておく。

$ sudo apt install logcheck logcheck-database

$ getent passwd
…
logcheck:x:nnn:nnn:logcheck system account,,,:/var/lib/logcheck:/usr/sbin/nologin

メールの送信先の設定

確認結果の送信先となるメールアドレスはここで設定できる。

/etc/logcheck/logcheck.conf

REPORTLEVEL="server"
SENDMAILTO="logcheck" ← ココ(hoge@hogeserver.hoge形式で指定可能らしい)
MAILASATTACH=0
FQDN=1
TMP="/tmp"

※コメントが長いけど、デフォルトではこの5つの指定だけが有効になっている。

デフォルトの宛先 logchek はエイリアスで root が追加されており、結果として root にメールが送信されるようになっている。

/etc/aliases

logcheck: root

実行タイミングの設定

実行タイミングはココに。そうか、最近バックアップスクリプトの実行計画をcrontabに直接書いていたけど、本当は/etc/cron.dに1つ1つ書いていくのが正しいのね。

/etc/cron.d/logcheck

# /etc/cron.d/logcheck: crontab entries for the logcheck package

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

@reboot         logcheck    if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; fi
#2 * * * *       logcheck    if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi
2 8,20 * * *       logcheck    if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi

# EOF

※毎時2分に送られてくる → 8:02 と 20:02 の2回に変更。

インストール時に logcheck-database も一緒にインストールしたことから、送られてくるメッセージもだいぶ抑制されたものになっている。

確認対象のログファイルの設定

UFWのログをsyslogに出力しないように設定をしている。直接サーバーをインターネットに向けて公開しておくと、とんでもない量のブロックログが出力される訳で…

/etc/rsyslog.d/20-ufw.conf

# Log kernel generated UFW log messages to file
:msg,contains,"[UFW " /var/log/ufw.log

# Uncomment the following to stop logging anything that matches the last rule.
# Doing this will stop logging kernel generated UFW log messages to the file
# normally containing kern.* messages (eg, /var/log/kern.log)
& stop ← 先頭の#を消してこの行を有効にすることで syslog に出なくなっている

確認対象になるログファイルはlogcheck.logfilesで指定できる。
上記のようにUFWのログをsyslogに出力しないようにしている場合に、それでもUWFのログを確認対象にしたいのならば ufw.log を追加すればよい。具体的には以下の通り赤文字部分を追加する。

/etc/logcheck/logcheck.logfiles

# these files will be checked by logcheck
# This has been tuned towards a default syslog install
/var/log/syslog
/var/log/auth.log
/var/log/ufw.log

だが、これを追加すると SYSTEM EVENTSログが半端ない量になってしまう…。ブロックしてくれているのだから問題ないし、イベントとして見なくてもいいかなー、ということで /var/log/ufw.log は先頭に # を付けて無効化しておいた。

出力されるログを制御

経験から、logcheckからかなりの量のログがレポートされるイメージ。だけど、READMEを読んでみれば、レポートは重要度により以下の3層に分けられており、特に注意するべきログは限られていたのだった。知らなかった(ちゃんと読むのは大事)…。

第1層 SECURITY ALERTS 侵入の企てを検出(フィルタで抽出)
第2層 SECURITY EVENTS 特別な注意に値する(フィルタで抽出)
第3層 SYSTEM EVENTS 残りのログすべて(フィルタで除外可能)

このことから考えて、本当に見たいログは SECURITY ALERTS か SECURITY EVENTS として出力されるように条件文を設定しておいて、SYSTEM EVENTS は気が向いたら読むくらいに考えておくのが良さそう。例えば、S25Rが450を返送したことを確認するならSECURITY EVENTS層でフィルタするのが適切なように思われた。

今回の記事を執筆中、実際にlogcheckから送られてきたレポートには SYSTEM EVENTS に結構な量のログが含まれていた。だが、よくよく確認すると2019/06/12時点のkopanoのバグ？っぽいログもあった。Debianでは既に修正されており、いずれUbuntuにも反映されて出力されなくなるだろう。こうした不必要なログはローカルなフィルタを掛けて出力されないようにすると確認がだいぶ楽になると思う。

ディレクトリ構成

logcheckインストール後のディレクトリ構成はこんな感じ。後述のREADMEを見てからこの構成を考えると、至極きれいに整理されていることが分かる。

/etc/logcheck
 ├ logcheck.conf
 │
 ├ logcheck.logfiles     ← 監視対象のログファイル設定
 ├ logcheck.logfiles.d/
 │
 │                          第1層
 ├ cracking.d/           ← SECURITY ALERTS
 ├ cracking.ignore.d/    ← SECURITY ALERTS のキャンセル(下位層に引き継がれない 初期設定は空)
 │
 │                          第2層
 ├ violations.d/         ← SECURITY EVENTS
 ├ violations.ignore.d/  ← SECURITY EVENTS のキャンセル(下位層に引き継がれない 初期設定はlogcheckの除外のみ)
 │
 │                          第3層 logcheck.confで参照ディレクトリが変わる
 ├ ignore.d.paranoid/    ← SYSTEM EVENTS paranoid
 ├ ignore.d.server/      ← SYSTEM EVENTS server
 ├ ignore.d.workstation/ ← SYSTEM EVENTS workstation
 │
 └ header.txt            ← メール本文の最初に書かれているメッセージ

/var/lib/logcheck         ← ログの最終位置を覚えておくためのファイル

レポートレベルを server にしているので、ignore.d.server が参照されているはずなので、その中身を見てみたところ、各種デーモンに関する除外定義が書かれていた。例えば、postfixには、無視して良さそうなパターンが結構な勢いで定義されていた。

欲しい情報をSECURITY EVENTSで取り出す

欲しい情報が取り出せる正規表現を考えて、テストをして、当該のファイルに追記する…という流れ。

syslogをテストするなら…

logcheck-test -s "ここに試したい正規表現を記載"

auth.logをテストするなら…

logcheck-test -a "ここに試したい正規表現を記載"

これ以外のログファイルをテストするなら…

logcheck-test -l チェックしたいログファイル名 "ここに試したい正規表現を記載"

S25Rのルールで拒否した記録がたまたま出てきたので、これに適合する正規表現を考えてみる。

Jun 12 16:33:08 hogeserver postfix/smtpd[72438]: NOQUEUE: reject: RCPT from 送信元FQDN[nnn.nnn.nnn.nnn]: 450 4.7.1 <送信元FQDN[nnn.nnn.nnn.nnn]>: Client host rejected: S25R check, be patient; from=<hogeuserhogeserver.hogeddns.jp@hogehogeservice.jp> to=<hogeuser@hogeserver.hogeddns.jp> proto=ESMTP helo=<送信元FQDN>

/etc/logcheck/ignore.d.server/postfix にあるルールを参考に作成したルールがこれ。

^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: (NOQUEUE|[[:xdigit:]]+): reject: [[:upper:]]+ from [^[:space:]]+: 450( 4\.7\.1)? <[^>]*>: Client host rejected: S25R check, be patient;.+$

数日前のログだったのでローテートされて syslog.2.gz になっていたので、溶かしてテスト。

$ sudo gzip -d /var/log/syslog.2
$ logcheck-test -l /var/log/syslog.2 "上記のルール"
Jun 12 16:33:08 hogeserver postfix/smtpd[72438]: NOQUEUE: reject: RCPT from 送信元FQDN[nnn.nnn.nnn.nnn]: 450 4.7.1 <送信元FQDN[nnn.nnn.nnn.nnn]>: Client host rejected: S25R check, be patient; from=<hogeuserhogeserver.hogeddns.jp@hogehogeservice.jp> to=<hogeuser@hogeserver.hogeddns.jp> proto=ESMTP helo=<送信元FQDN>
Jun 12 16:43:08 hogeserver postfix/smtpd[72438]: NOQUEUE: reject: RCPT from 送信元FQDN[nnn.nnn.nnn.nnn]: 450 4.7.1 <送信元FQDN[nnn.nnn.nnn.nnn]>: Client host rejected: S25R check, be patient; from=<hogeuserhogeserver.hogeddns.jp@hogehogeservice.jp> to=<hogeuser@hogeserver.hogeddns.jp> proto=ESMTP helo=<送信元FQDN>
Jun 12 16:53:08 hogeserver postfix/smtpd[72438]: NOQUEUE: reject: RCPT from 送信元FQDN[nnn.nnn.nnn.nnn]: 450 4.7.1 <送信元FQDN[nnn.nnn.nnn.nnn]>: Client host rejected: S25R check, be patient; from=<hogeuserhogeserver.hogeddns.jp@hogehogeservice.jp> to=<hogeuser@hogeserver.hogeddns.jp> proto=ESMTP helo=<送信元FQDN>
…
================================================================================
parsed file: /var/log/syslog.2
used rule: '上記のルール'

※メールアドレスや送信元の情報はマスクしているのでご了承を。

うまくいきそうだ。

ところで、S25Rには3つの450がある。ただし、ウチではブラックリストは利用しておらず、Realtime Blackhole List(RBL)を利用している。

reverse lookup failure, be patient
S25R check, be patient
domain check, be patient ← 未使用：ブラックリストに引っかかったとき

ブラックリストで引っかかったものはブラックリストを作成している団体がメンテナンスしてくれているので見る必要はないと判断。
よって、新たにルールファイルを作り、利用している2つに適合するルールを追加することにした。

/etc/logcheck/violations.d/postfix ※新規作成

^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: (NOQUEUE|[[:xdigit:]]+): reject: [[:upper:]]+ from [^[:space:]]+: 450( 4\.7\.1)? <[^>]*>: Client host rejected: reverse lookup failure, be patient;.+$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/smtpd\[[[:digit:]]+\]: (NOQUEUE|[[:xdigit:]]+): reject: [[:upper:]]+ from [^[:space:]]+: 450( 4\.7\.1)? <[^>]*>: Client host rejected: S25R check, be patient;.+$

最後にルールファイルをテスト。

$ sudo logcheck-test -l /var/log/syslog.2 -r /etc/logcheck/violations.d/postfix
Jun 12 16:33:08 hogeserver postfix/smtpd[72438]: NOQUEUE: reject: RCPT from 送信元FQDN[nnn.nnn.nnn.nnn]: 450 4.7.1 <送信元FQDN[nnn.nnn.nnn.nnn]>: Client host rejected: S25R check, be patient; from=<hogeuserhogeserver.hogeddns.jp@hogehogeservice.jp> to=<hogeuser@hogeserver.hogeddns.jp> proto=ESMTP helo=<送信元FQDN>
Jun 12 16:43:08 hogeserver postfix/smtpd[72438]: NOQUEUE: reject: RCPT from 送信元FQDN[nnn.nnn.nnn.nnn]: 450 4.7.1 <送信元FQDN[nnn.nnn.nnn.nnn]>: Client host rejected: S25R check, be patient; from=<hogeuserhogeserver.hogeddns.jp@hogehogeservice.jp> to=<hogeuser@hogeserver.hogeddns.jp> proto=ESMTP helo=<送信元FQDN>
Jun 12 16:53:08 hogeserver postfix/smtpd[72438]: NOQUEUE: reject: RCPT from 送信元FQDN[nnn.nnn.nnn.nnn]: 450 4.7.1 <送信元FQDN[nnn.nnn.nnn.nnn]>: Client host rejected: S25R check, be patient; from=<hogeuserhogeserver.hogeddns.jp@hogehogeservice.jp> to=<hogeuser@hogeserver.hogeddns.jp> proto=ESMTP helo=<送信元FQDN>
…
================================================================================
parsed file: /var/log/syslog.2
used rule file: /etc/logcheck/violations.d/postfix

※ルールファイルを置く場所はrootしかアクセスができないので sudo する。

1つめのルールはチェックし切れていないけれど、間違っていたら修正すればいい。(この後、不正アクセスで1つめのルールに抵触するメールが送られてきた。ちゃんとレポートされることが確認できた)

いらない情報をSECURITY EVENTSから除外する

あまりないと思うけれど、SECURITY EVENTSにいらないと思うログが出ていたら…という話。

やることは、次項「いらない情報をSYSTEM EVENTSから除外する」とほとんど同じだが、ファイルを置く場所が以下に変わる。
/etc/logcheck/violations.ignore.d

ファイル名は自由に付けられるが、照合されるパッケージを限定するならファイル名を logcheck-<packagename> にする。
これ以外の名前の場合には、発生するすべてのSYSTEM EVENTSと照合される。

パッケージを限定すると、結構いい加減なパターン記述でも他のパッケージに影響を与えないので安心。

いらない情報をSYSTEM EVENTSから除外する

試しにバグによって出力されているログを除外してみる。
本来はバグが修正されるのを待つべきだが、設定のやり方を覚えるのにちょうど良いのでやってみる。

/etc/logcheck/ignore.d.server/z_original ※新規作成

^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? audit: type=1107 .+label="/usr/sbin/kopano-server".+$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])?  exe="/usr/bin/dbus-daemon".+$

※ファイル名をz_originalにしたのは、ls -l とかでファイルを見たときに一番最後に表示されれば忘れないかなーという程度の思いから。実際にはファイル名がどんなものであっても構わない。

ダブルクォーテーション[“] を検索対象にする場合、\でエスケープする。これはキャラクターパターン指定、[abc\”]のような場合も同じ。これは、実際にegrepにパラメータとして渡されるときに\でエスケープする必要があるから。

作ったルールをテストしてみる。

$ logcheck-test -s -r /etc/logcheck/ignore.d.server/z_original
どさ～っとログが出る
================================================================================
parsed file: /var/log/syslog
used rule file: /etc/logcheck/ignore.d.server/z_original

この結果から、どさ～っと報告されていたログは無効化され、これ以降の報告には含まれなくなることが確認できた。

テスト

新しく作ったルールそのものをテストするときには logcheck-test を使うが、全体的な動作をテストするときには logcheck に -t(テストモードオフセットを更新しない)を使うのが良さそう。

$ sudo -u logcheck logcheck -t

logcheckはlogtailを利用してログを収集しており、前回取り出したログはテストの対象にならない。これを無視して全部をチェック対象にするなら、以下を実行してオフセット情報を消してしまえばいいと思う。

$ sudo rm /var/lib/logcheck/offset*

やったこと

READMEの翻訳風を作成したのと、logtailのオフセットファイルの中身を調べてみている。

README.logcheck-database(翻訳風)

システムに詳しい人にとってみたら難しくないのだろうけれど、オレにとってはとっても難しいから、説明を読んでみないと…ということで、そんなに長いものでもないからGoogle先生に翻訳してみてもらった後に少し手を入れた翻訳風を作成。

翻訳しながら迷う迷う…これを読め！って言っている人がパラパラいて、これを読めるのか凄いなーと思ってしまった。1つの事柄に付加される情報量が多すぎるし、具体例が少ないから、ストンと入ってこない…。

原文はこちら。結構頑張って風味を出したけど、おかしいな？と思ったら原文確認のこと。

概要

Logcheck-databaseは、”logcheck”パッケージが必要とするegrepパターンを提供します。これは、(“logtail”によって収集された)最近のログメッセージを要約されたニュースにして送信するためのフィルターとして使われます。

一連のルール

フィルタリングルールのセットは3層からなり、すべてがよくあるegrep※パターンマッチであり、順番に適用されます。

訳注)
egrepについてWikipediaを見に行ったところ extended global regular expression print (拡張/ファイル全体から/正規表現に適合する行を/表示する)の意味であることが分かりました。

1. the “SECURITY ALERTS” layer,
有効な侵入の企てを検出するように設計されています。

アラームを発するパターンは “/etc/logcheck/cracking.d” にあり、これらに適合したイベントは “Security Alerts”になり、関連するイベントはこの層に遷移します。crackng.dにある標準的なキーワードファイルには、敵対的行為の既知の症状が書き込まれています(参照 logcheckのREADME.keywordsファイル)。

logcheckはこれら最優先のアラームをキャンセルするパターンをデフォルトでは利用しないようになっていますが、ローカル管理者がlogchek.confで有効にすれば※ “/etc/logcheck/cracking.ignore.d”ディレクトリのルールを利用するようになります。cracking.ignoreのルールに適合すると、アラートは誤ったアラームとして再分類されます(下層のviolations.ignoreと同様です)。これは、それらが完全に無視されることを意味していることに注意してください – この層で処理されたログメッセージは下層に引き継がれません。

訳注)
logcheck.confにあるSUPPORT_CRACKING_IGNOREに1を設定することで有効になります。

2. the “SECURITY EVENTS” layer,
それほど重要ではないがまだ特別な注意に値すると考えられるイベントを検出するように設計されています。

アラームを発するパターンは “/etc/logcheck/violations.d”にあり、これらに適合したものは “Security Events”になり、関連するイベントはこの層に遷移します。

このアラームをキャンセルするパターンは通常 “/etc/logcheck/violations.ignore.d”ディレクトリにあり、violations.ignoreのパターンに適合した “Security Events”は、誤ったアラームとして破棄されます。

3. the “SYSTEM EVENTS” layer,
残りのログを取り扱います。

この層はcracking.dやviolations.dのようにアラームを発生させるものと違い、上位層から取り残されたすべての行が “System Events”に含まれるものと見なします。

3つある “/etc/logcheck/ignore.d.*”ディレクトリ内のパターンは、些細な出来事として警告を無効化してレポートから除外するため機能します。

どのディレクトリが参照されるのかは、logcheckの “REPORTLEVEL”によって異なります※(詳細は、対応するlogcheckのREADMEを参照してください)。最低限必要なのは、ignore.d.paranoid内の一連のフィルタです。イベントがフィルタを通して記録されないログになったならば、レポートに含まれません。

訳注)
logcheck.confにあるREPORTLEVEL項目で、workstation、server、paranoidの3種類が指定できます。対応するディレクトリは
/etc/logcheck/ignore.d.workstation
/etc/logcheck/ignore.d.server
/etc/logcheck/ignore.d.paranoid
です。

各ディレクトリ内のファイル

ルール用のディレクトリには、次のようなパターンファイルを含めることができます：
./<packagename>

ルールのファイル名はrun-parts(8)と互換性のある文字のみにしてください。これを書いている時点では、これには英数字、アンダースコア、ハイフンが含まれています。

それぞれのDebianパッケージに対応するルールが含まれており、例えば次のような ”fooserver”パッケージの疑わしいイベントログが記録されたとして：
“$DATE $HOSTNAME fooserver[$PID]: $USER is up to no good”
これが “/etc/logcheck/violations.d/fooserver”に定義されたパターンを含んでいれば、それは “System Event”から “Security Event” サブセクション”fooserver”に昇格されて通知されます※。

訳注)
実際のメールで以下のような形で報告されることを説明しています。

Security Events for fooserver
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jun 15 07:01:15 hogeserver fooserver[92560]: hogeuser is up to no good
…

一方で、些細に見える(例えばネットワーク上のスパイとスパイ対策の争いの)メッセージの類いがあるなら、とても熱心な管理者を除くすべての人は “/etc/logcheck/ignore.d.server/fooserver”に行を追加して何も起きないように設定を変えてください。

パッケージは時々 “Security Events”とすべき特別なアラームを出力することもあるし、すべきでない例外的な変種を出力することもあるでしょう。恐らくこれは
　　”$DATE $HOSTNAME fooserver[$PID]: $USER barred”
や
　　”$DATE $HOSTNAME fooserver[$PID]: none barred”
といったログです。
こんなときにアラームを無効にするには “fooserver”という名前のviolations.ignoreルールファイルで “none barred”をフィルタします。これは “none barred”という単語を含む他の “Security Events”には影響しません (それはクラッカーがそれらの単語を使ってsshに攻撃できるようにするかもしれないからです)。<packagename>の無効パターンファイルは、そのパッケージ固有のレポートセクションのログメッセージにのみ影響します。他のものと区切られるというこの制限は、ルールが必要とする手続きの数を減らします。

./logcheck または ./logcheck-<packagename>

標準の “一般的な”規則は各ディレクトリの「./logcheck」ファイルにあります。

つまり、 “cracking.ignore.d”ルールを意図的に変更しない限り、 “Security Alert”を引き金にした”攻撃”( “/etc/logcheck/cracking.d/logcheck”に並んでいる)に適合するすべてが記録されます。

** 注 Debian：私たちは./logcheckと./logcheck-<packagename>にあるファイルを空っぽにしてignore.d.*/<packagename>にまとめました。これを実施したのは、標準の./logcheckがひどく多い誤検知(see e.g. #449028)と多数のルール重複(#254542)を来していたからです※。

訳注)
実際には空っぽではなく、ファイルそのものがありません。

パッケージ固有の”無効”フィルタは、パッケージ固有ではない”検知”パターンを上書きするわけではないことに注意してください。”fooserver”が次のsyslogメッセージを出力したとします：
　　”$DATE $HOSTNAME fooserver[$PID]: 3 attempts 0 rejected”
よくあるキーワード “reject”が一般的な “/etc/logcheck/violations.d/logcheck”に並べられていれば、”Security Events”が頻繁に引き起こされるでしょう。こんなときに “/etc/logcheck/violations.ignore.d/fooserver”にフィルタリングパターンを入れても役に立ちません！
この問題を解決するには、特別な権限がある./logcheck-<packagename>形式のファイルを使用します：
“/etc/logcheck/violations.ignore.d/logcheck-fooserver”
これには、その特定のパッケージに向けたパターンを含めることができ、それは一般的なルールよりも優先されます。

./local または ./local-<packagename>

システム管理者は、ファイル名 “local-*”を作成して “logcheck-*”パターンリストに独自のパターンを追加できます※。

“ippl”でネットワーク接続を詳細にsyslogに記録している場合は、カスタムの “Security Events”キーワードを
　　”/etc/logcheck/violations.d/local-ippl”
および、例外用の
　　”/etc/logcheck/violations.ignore.d/local-ippl”
に追加します。

訳注)
これを見て、logcheck-databaseパッケージが提供するファイルに対して手軽に自分ルールが追加できるのかと思ったのですが、実際は違っていて、local-<packagename>を作ってもlogcheck-<packagename>の追加パターンになるのではなく、単純にすべてのログと照合されていました。

書き方

ローカルルールファイルを編集するときは注意してください。logcheckは前処理で( “egrep ” syslog”はすべての行に適合するので)それらの危険な空白とコメント行を削除します。過度に寛大なフィルタリングを避けるためにカスタムパターンを作成するときには注意が必要です。logcheckのルールの目的は、拡張正規表現のすべてのリソースを使用して、対象となるログメッセージと正確に照合することです。このようなログメッセージを読むのが面倒ならば：

Apr 6 19:30:24 oempc wwwoffled[11763]: WWWOFFLE Online.
Apr 6 19:31:54 oempc wwwoffled[11763]: WWWOFFLE Offline.

…無視するために必要とするローカルなパターンはこうです：

^\w{3} [ :0-9]{11} oempc wwwoffled\[[0-9]+\]: WWWOFFLE (On|Off)line\.$

拡張正規表現において文字 “.?*+[](){}^$|\” は特別で、その文字そのものを意図するときはエスケープする必要があります(上記の例の最終位置のように)。特にegrepをだめにするような括弧の組み合わせの間違いに用心してください。

ローカルの管理者は、 “fooserver”やその他のパッケージを維持しフィルタを提供する人達よりかなり明確に定義できます。ローカルな情報を利用できるので、パッケージを維持する人達が “[[:alpha:]]”を使うべきところで “[a-zA-Z]”と示すことができます。もっといえば、ホスト名等を明示的に定義することができます。そう、”[._[:alnum:]-]+”ではなく、上記の “oempc”のような定義ができます。

テストの仕方

新しいルールのテストにはlogcheck-testコマンドを利用することをお勧めします(参照 logcheck-test(1))。

あるいは手動でログファイルをgrepして、こんな風に末尾の空白を外すこともできます※：

sed -e 's/[[:space:]]*$//' /var/log/syslog | egrep \
'^\w{3} [ :0-9]{11} oempc wwwoffled\[[0-9]+\]: WWWOFFLE (On|Off)line\.$'

訳注)
logchek-test のスクリプトの中を見てみたところ、ここで行っている前処理(危険な空白の除去)を行うようになっていましたから、テストにはlogcheck-testを使った方が簡単です。なお、logchek-test はルールが入ったファイルを指定してテストすることもできるようになっています。

ログが表示されたら、正規表現は機能しています。

メンテナンスを簡単にするために、すべての規則ファイルの最終行にキャリッジリターンがあることを確認して “sort -u”に渡せば、きれいに “cat”できるようになります。システムイベントはパッケージごとに分割されていないため、ignore.d.*/ のローカルルールが “local-x”, “local-y” および “local-z”に分割されていても、合併した “local”ファイルであっても効果に違いはありません。やりやすい方を使ってください。

この他の安全策は、適用可能なすべての規則を照合するプロセスが “run-parts”、これは “/etc/cron.d”や “/etc/ppp/ip-up.d”などの繰り返し処理にも使われるユーリティティで、これを使用するという事実によって提供されます。したがって、 “fooserver.disabled”や “local〜”のような名前のファイルは自動的に無視されます。

訳注)
ルールを追加した後、logcheck に -t を付けて実行すればルール全体を通したテストができます。

提出方法

logcheckによって無視されないメッセージがある場合、Debian Bug Tracking System(BTS)で logcheck-databaseパッケージに対してバグを提起してください。

Debian BTS を使ったバグ報告が初めての方は、ここで詳しく知ることができます：
http://www.debian.org/Bugs/Reporting

とはいえ、私たちにはすべてのルールを追加・更新する時間はありませんので、以下の例外があります：

* デバッグメッセージ
* Debianに含まれないソフトウェアが生成するメッセージ
* パッケージのバグによる一時的なメッセージ
* デーモンの起動と停止に関するメッセージ

これらのメッセージに関連するバグは提起しないようお願いします。

logtailのオフセットファイル

前回どこまで取り出したのか…という情報は/var/lib/logcheckに保管されている。たとえばsyslogの中身はというと…

/var/lib/logcheck/offset.var.log.syslog

5507379 ← iノード番号
33062   ← 何文字目まで取り出したのか(次は33063文字目から抽出)

iノード番号が「前回と同じファイルであるかどうかを確認する」ために利用されている。どんな番号なの？と確認してみたら…

$ ls -li /var/log/syslog*
5507379 -rw-r----- 1 syslog adm  78833 Jun 16 09:59 /var/log/syslog
5507694 -rw-r----- 1 syslog adm 541925 Jun 16 06:25 /var/log/syslog.1
5508629 -rw-r----- 1 syslog adm  40769 Jun 15 06:25 /var/log/syslog.2.gz
5505196 -rw-r----- 1 syslog adm   8287 Jun 14 06:25 /var/log/syslog.3.gz
5507257 -rw-r----- 1 syslog adm  11012 Jun 13 06:25 /var/log/syslog.4.gz
5507430 -rw-r----- 1 syslog adm  38572 Jun 12 06:25 /var/log/syslog.5.gz
5507839 -rw-r----- 1 syslog adm  11361 Jun 11 06:25 /var/log/syslog.6.gz
5509202 -rw-r----- 1 syslog adm  75481 Jun 10 06:25 /var/log/syslog.7.gz

となっていて、必ずしも新しいファイルが新しい番号になるって訳でもないらしいが、ファイル名が同じでも、それが前回見たファイルと同じなの？という確認に使える模様。

さいごに

せっかくlogcheckをインストールしていたのに、今まではうまく活用できていなかった。今後はこまめにメンテナンスして確認していこうと思う。だって、ちゃんと設定さえしておけば、基本的には SECURITY ALERTS と SECURITY EVENTS だけを見ておけば、後はゆっくりで良かったんだもん、たいした手間じゃなかったよ。