[[Logcheck]]
#contents
----
* Logcheck README 日本語訳 [#oc944181]
** ドキュメントの翻訳について [#fbf49481]
日本語版のドキュメント公開については念のため作者さんに問い合わせ中です。先方の回答やライセンスによってはドキュメントは非公開になる場合もあります。
ドキュメントの内容は出来るだけオリジナル英語に忠実に翻訳するように努めますが、日本語として不適切な部分は日本語として読みやすいように置き換えている場合もあります。なお、免責事項として、日本語版を利用者が利用するにあたり、いかなる場合も訳者はその責をを追いません（、と書くのが一般的ですので、私も書かせてください。。）。
* README [#y3078093]
インストール作業：どうかファイルの全部を読んでください！
** Operation - 動作 [#j6e6ce1f]
Logcheck にはいくつかファイルがあります:
logcheck.sh -- メインとなるスクリプトです。このファイルが全てのプロセスを制御し、ログファイルを単純な grep コマンドで調査します。ファイルは基本的に cron によって定期的に実行され、調査結果をシステム管理者に報告します。
logtail -- テキストファイルの末尾を覚えておく働きを持つ実行可能なプログラムです。プログラムはログを最後に開いた場所から logcheck によって情報を解析するために使われます。二重に古いログを解析しないような働きがあります。全ログファイルがこのプログラムで処理されます。"########.offset" という名前でディレクトリにファイルがおかれます。######## には解析したログファイル名が割り当てられます。ファイルの中には logtail が動作する為の 10 進数のオフセット情報が保存されています。ファイルを削除してしまうと logtail はログファイルのはじめから再解析することになってしまいます。Logchek にはログファイルがいつローテートされたか調べることが出来るように、ファイルサイズと i ノード情報を追跡します。前回実行時と比べ、ログファイルの i ノード情報が変更されるかファイルサイズが小さくなれば、logtail はカウンタをリセットしてファイル全体を解析しなおします。
logcheck.hacking -- このファイルへは明らかにシステムに対する攻撃と思われるキーワードを記述します。攻撃パターンというものがどのようなものか分からないのであれば、これらのファイルは触らないほうがよいでしょう（標準のキーワードは一般的にインターネット上のセキュリティ・スキャンや攻撃、sendmail(8) に見られるような無効な構文を含むメールアドレスといった情報を記述していあります）。どのようなキーワードでもログファイル中に発見されれば、あなたの注意を引くように "ACTIVE SYSTEM ATTACK"(システムが攻撃を受けています)といった不愉快な見出しで報告を送ります。
logcheck.violations -- このファイルへはシステムイベントのなかで問題と思われるキーワードを記述します。キーワードには "denined"(拒否)や"refused"(拒絶)等があります。"su" といった正常な動作であっても記述してあります。TCP ラッパーがインストールされていたとしても、 FWTK や BSDish といった偏ったメッセージ全てに対し包括的なものではありません。攻撃の兆候があれば "Security Violations"(セキュリティ侵害) という見出しで報告を送ります。
logcheck.violations.ignore -- こちらのファイルへは logcheck.violations ファイルに対して検索対象外とするキーワードを記述します。こちらに記述された言葉が検出されても報告されることはありません。たとえば次のようなログです：
Feb 28 21:00:08 nemesis sendmail[5475]: VAA05473: to=crowland, ctladdr=root
(0/0), delay=00:00:02, xdelay=00:00:01, mailer=local, stat=refused
Feb 28 22:13:53 nemesis rshd: refused connect from hacker@evil.com:1490
１つ目の行は sendmail のログですが、かなり一般的に見受けられるログです。stat 部ではリモートホストからの接続が拒否されたという意味です(stat=refused)。このようなログが出る原因は様々ですが、一般的に問題ではありません。
下の行は誰か(hacker@evil.com)が自分のマシンへの rsh セッションを試みたものの失敗したという意味です。というよりも、むしろ rsh を使うべきではありません。
ファイル logcheck.violations は "refused" といった言葉を探し出し、ログの中にフラグをつけます。ですので、いずれの場合も警報が通知されますが(いずれの場合も refuled という言葉が入っていますので)、 sendmail の方は誤警報です。そこで logcheck.violations.ignore ファイルに以下のような記述を行うことで logcheck に対して sendmail の問題を無視するようにし、rsh に関する警報のみ報告するようにすることができます：
(logcheck.violations.ignore ファイルへの記述)
mailer=local, stat=refused
ログファイル中に "refused" という箇所があっても、この記述により "mailer=local, stat=refulesd" というキーワードが含まれる場合には通知はなされません。これはかなり基本的であまり知的な方法ではありませんが、重要な事を無視して見落とさないように特別な注意を払う必要があります。logcheck.violations.ignore のファイルに長すぎるメッセージを入れなくとも特定のイベントを無視できることにご注意下さい。ここで何を記述するかには十分に注意を払う必要gあります。プログラムは純粋にログファイルに含まれる文字列に対して grep を実行しています。調整は慎重に行ってください。上記のことがご理解できない場合には、このファイルをそのままにしておいてください。
ログファイル中に "refused" という箇所があっても、この記述により "mailer=local, stat=refulesd" というキーワードが含まれる場合には通知はなされません。これはかなり基本的であまり知的な方法ではありませんが、重要な事を無視して見落とさないように特別な注意を払う必要があります。logcheck.violations.ignore のファイルに長すぎるメッセージを入れなくとも特定のイベントを無視できることにご注意下さい。ここで何を記述するかには十分に注意を払う必要があります。プログラムは純粋にログファイルに含まれる文字列に対して grep を実行しています。調整は慎重に行ってください。上記のことがご理解できない場合には、このファイルをそのままにしておいてください。
logcheck.ignore -- このファイルにはログ中にキーワードがあっても無視する言葉を記述します。どのような言葉を無視するかには再び注意を払うようにし、ワイルドカードも控えめに使って下さい。このファイルに一致しないメッセージがあれば（あなたが敢えて何もミスしないように）、プログラムが "Unusual System Activity"(システムの異常動作)として報告します。再び標準では BSDinish と FWTK と TCP ラッパーの為に記述してあります。
検索方法は以下のルールを完全に遵守します：
1) まずシステムに対する攻撃活動が報告されます。
2) 次にセキュリティ違反であると報告されます。
3) 最後に異常なシステムイベントが発生したと報告されます。
logcheck.hacking と logcheck.violations ファイル上のキーワード検索では、私たちが何もミスしないようにする為に、大文字と小文字の違いを無視します。logcheck.violations.ignore と logcheck.ignore でも同様に私たちのミスを防ぐため、大文字と小文字の違いを無視します。 *.ignore ファイルの中身は間違いなくテキスト形式のファイルである必要があります。logcheck.violations と logcheck.hacking ファイルに記述された言葉に対しては一層敏感になっており、どのような場合でも、とにかく一致する事があれば報告をおこないます。
プロセス全体の動作は以下のような構造です：
logcheck.sh が１時間毎に実行されます ---->
logcheck.sh が logtail コマンドを実行してログファイルを調べます ---->
logtail が前回解析した所からログファイルの文字列を解析します --->
logcheck がシステムに対する攻撃メッセージを抽出します --->
logcheck セキュリティ警告に関するメッセージを抽出します --->
logcheck が無視するセキュリティ警告に対するメッセージを除外します --->
logcheck が全てのメッセージの中で無視するメッセージを除外します --->
以上の流れで検出された全てのメッセージがシステム管理者宛にメールされます。
全体的に非常な単純なプロセスですが、本来あなたが知るべきであった驚くほどのシステム上の注意を払うべきメッセージを報告してくれるでしょう。本来、私たちがチェックすべきだったものです。
** Installaiton - インストール [#hf5a0855]
syslog.conf ファイルが何であるかを知っていて、可能な限り多くの情報をログに記録できる事も理解し、ログの安全性を確保しているのであればステップ２へ進んでください。そうでない場合はステップ１から始めましょう。
*** ステップ１：syslog デーモンの設定とログファイルの保全 [#obc1ddc8]
logcheck をセットアップする前に、単に syslog をシステム上で動作させるのではなく、可能な限り最大限のログを取得できるようにする事を確認してください。殆どのシステムでは logcheck が完全な解析を行えるように、全ての syslog メッセージを１つのファイルに記録することを推奨します。設定ファイルに対するミスは許されません。BSD 系のシステムでは /etc 配下にある syslog.conf を編集することになります。このファイルでは syslogd が動作するためのパラメータが指定されています。もし意味を理解していないのであれば、どうか確認してください。
man syslog.conf
- あるいは -
本を読んでください。
多くの syslog.conf ファイルは各項目にタブやスペースを使うことに敏感ですので、syslogd デーモンが誤動作しないようスペースの扱いには十分気をつけてください。
syslog.conf ファイルへの記述は以下のようなものです：
*.info /var/log/messages
この記述は /var/log にあるファイル messages に全ての情報を記録します。/var/log というのはログ保存に用いられる典型的なディレクトリですが、あなたの環境にあわせて書き換えてください。BSD 系であれば主に /var/log であり、Linux の場合は /var/adm です（ただし、最近の Linux ディストリビューションでも /var/log に保存されるようになっています）。ホスト毎に syslog.conf は標準の設定を持っています。もし大規模なサーバ（例えばメールサーバ）を運用しているのであれば、ログの取得は膨大なものとなりますので、ハードディスクの容量を圧迫するかもしれないので注意を払ってください。記述は以下のようにも書けます：
*.info;mail.none /var/log/messages
mail.notice /var/log/messages
こちらの記述は純粋に非標準のメッセージを記録するだけです。ただ、この記述だけでは誰かがシステムに侵入を試みたり侵入したり、あるいはシステム権限を奪取されても検出することは難しくなります。あまりお勧めできません。多くのシステムではシステムサービス毎に異なったログファイルを記録するようにしています。典型的な記述はいかのような設定です：
*.info;mail,ftp,daemon,authpriv.none /var/log/messages
mail.info /var/log/mail.log
ftp.info /var/log/ftp.log
daemon.info /var/log/daemon.log
authpriv.* /var/log/secure.log
この記述は一般的なシステムメッセージ、メール、ftp、各種デーモンとセキュリティに関するメッセージを個別に記録します。Logcheck はこれら全てのログを検査するように設計してあります。再びとなりますが、自分の syslog.conf や man syslog.conf を参照して、どうか多くの情報を理解しておいてください。
必要に応じて syslog.conf を編集したあと、設定を反映させるために syslogd に対して HUP シグナルを送り syslogd を再起動させます。
重要：これからログディレクトリ（例えば /var/log ）に移動して、ログファイルの所有者を root に、グループを wheel に、そしてファイルパーミッションは 600 にしなくてはいけません。まず第一にファイルが存在していなければ、自分で作成しておいたほうがいいでしょう。たとえば単純な "messages" と呼ばれるログファイルを作成したいのであれば、次のようにします：
touch /var/log/messages
パーミッションについても以下のように変更を行わなくてはいけません：
chown root.wheel /var/log/messages
chmod 600 /var/log/messages
私は他のログファイルに対しても同様に似た方法（所有者とグループをの変更が許されないのであれば、せめてパーミッションを 600 にするだけでも）でも良いのでパーミッションを変更することをお勧めします。ログファイルにはシステムが稼働するあらゆる機密性の高いデータが含まれています。たとえば、パスワード認証やシステムのエラー、システムの脆弱性に関するデータも含まれるかもしれません。注意を払うべきです。私は個人的にこれらのログファイルは決して root 以外の権限で読み込み可能であってはいけないと思っています。
BSD か FreeBSD のシステムであれば、/etc ディレクトリにある /etc/daily、/etc/weekly、/etc/monthly にあるスクリプト中の "rotate()" 関数にあるログのローテート時におけるパーミッションの記述を変更すべきです。変更点は次の１行を書き加えます。
cp /dev/null "$file"; chmod 644 "$file"
この行を次のように書き換えてください：
cp /dev/null "$file"; chmod 600 "$file"
（上記の指定は BSDI 2.x と BSDI 3.x ユーザ向けの rotate 関数についてであって、現在のシステムで 644 から 600 になっているようであれば問題はありません。FreeBSD では BSDI 2.x スクリプトと似ているでしょう）
ログファイルが自動的にローテートされるとき、それらの権限が自動的に再設定されます。
これらのステップが完了したら、次のステップ２に進むことができます：
*** ステップ２：Logcheck と logtail のインストール [#fe7a336a]
Logcheck は実行時に以下のファイルを必要とします。
logcheck.sh
logtail.c
logcheck.hacking
logcheck.violations
logcheck.violations.ignore
logcheck.ignore
好きなエディタを使って logcheck.sh を読み込んでください。それから、"CONFIGURATION SECTION"（設定箇所）を書かれた場所を探してください。
SYSADMIN の変数には管理者名を入力してください。ここにはローカルのユーザ名（標準は root です）かリモートで監視するメールアドレスを記入してください。
"LOG FILE CONFIGURATION SECTION"(ログファイル設定)と書かれた場所を探して、時部のシステムに該当するコメントをはずすか、自分自身でログファイルの指定を行ってください。記述する際には > と >> の演算子の違いを理解しておいて下さい。
標準のシステムタイプ(Linux, BSDI, FreeBSD, SunOS など)を利用している場合は、単純に "make <システムタイプ>" と入力して、インストールすることが出来ます。もし別のパス（/usr/local/どこか）にインストールしたいおであれば、メインの logcheck.sh スクリプトに含まれるlogcheck.hacking、logcheck.violations、logcheck.ignore、logcheck.violations.ignore、logtail といったパスを変更する必要があります。必要性がないのであれば、変更しないことをお勧めします。
標準のパス /usr/local/etc と /usr/local/bin を変更したい場合は logcheck.sh ファイルを必要に応じて変更し、Makefile の INSTALLDIR と INSTALLDIR_BIN の指定も同様に変更する必要があります。
Makefile は標準で /usr/local/etc/tmp ディレクトリを作成しようとする事に注意を払ってください。これは logcheck を処理するためにファイルを寄せ集めた場所です。私は誰でもアクセス可能な /tmp を使う事を推奨しません。特定のユーザが logcheck スクリプトを騙して、重要なファイルを上書きさせるようシンボリックリンクを作成するという脅威があるからです。また、私は /tmp という悪名を孕む安全ではないディレクトリを自動化スクリプトが用いないようにする事も提唱します。
** Editing Cron - cron の編集 [#kfcafec0]
logcheck のインストールが終わった後は、crontab ファイルに root 権限で logcheck が１時間毎に実行されるよう設定してください（私の推奨値はもっと頻繁に行うべきだと思いますが、必要がなければ数時間毎に実行させるようにしても構いません）。以下は記述例です：
毎時間チェック（BSD システムと Red Hat の /etc/crontab）：
00 * * * * root /bin/sh /usr/local/etc/logcheck.sh
１５分毎にチェック（Linux Slackware では /var/spool/cron/crontabs/root）：
00,15,30,45 * * * * /usr/local/etc/logcheck.sh
あまり警告メッセージを表示しないファイアウォールを導入しているシステムでは 15 分おきにチェックする事をお勧めします。
覚えておいてほしいのは、ログの中に何ら記録がされなければ、logcheck は何も警告を行いません。15 分毎にチェックを実行させてもシステムが静かであればメールボックスに対する影響は無いでしょう。活動的なシステムでは頻繁にメッセージを送ってくるかもしれませんが、分析のためにあなた自身が多くの時間をとられてしまうことも意味しますので、好ましくない場合もあるでしょう。繰り返します、１時間毎のチェックを推奨します。
crontab を編集したあとは設定を反映するために crond に HUP シグナルを送りリセットしなくてはいけません。
** Final Check and Troubleshooting - 最終チェックとトラブル対策 [#h44c25d7]
これで殆どの作業が終わりました。logcheck.sh スクリプトを手動で実行して間違いなくログファイルをエラー無く読み込み、指定したアカウントにメールが送られるか確認をする事をお勧めします。syslog に実際にどのようなイベントが記録されているか確認し、自分自身でイベントを作り logcheck のレポートに反映されるか確認してください（たとえば su コマンドで root になる）。そうすると、メッセージの記録がメールで送られてくるでしょう。何回も同じメッセージを受け取らないかも確認するために、何度か logcheck を実行してみてください。
もし繰り返し同じメッセージを受け取ってしまうようであれば、何か logtail プログラムに（正しくファイルを作成できないようです）問題が発生しているので、プログラム実行後、ディレクトリ内に *.offset ファイルが作成されているかどうか確認してください。もしそこに logtail によってバイナリファイルが作成されないようであれば、プログラムに問題があります。そのような場合、logtail コマンドを手動でもう一度実行し、log ファイルに対して offset ファイルが作成されるかどうか再確認して下さい。もしファイルの作成が拒否されるようであれば、実行ファイルのパーミッションを確認して root ユーザ権限で全て動作しているかどうかを確認してください。
logcheck ファイルが使う標準のパーミッションは以下の通りです：
- logcheck* -- 600 -- root のみ"読み" "書き"可能。所有者は root 、グループは wheel です。
- logtail* -- 700 -- root のみ"読み" "書き" "実行" 可能。所有者は root 、グループは wheel です。
メモ：どのような理由があってもファイルに対しては SUID root 権限を与えるべきではありません
一層用心深い方達は、ログファイルを特別なユーザーやグループに割り当てて、ログファイルの検査を特定のユーザに行わせたいと考えるかもしれません。このような方法を希望するときは、logcheck ファイルに関するパーミッションを調整して、それらログが正しくログ保存ディレクトリに書き込まれるかを確認すべきです。
もし質問がある場合や、わずかですが何か手助けできることがあればメールを送ってください。不幸にも私のスケジュールはどちらかというと忙しいほうなので、質問を送っても返信が届くまで辛抱強く待ってください....
どうも、ありがとうございました。
Craig Rowland
![[Pocketstudio.jp Linux Wiki]](image/icon.gif "[Pocketstudio.jp Linux Wiki]"){kind=icon}
