UNIXサーバの運用管理で欠かせないログ管理：止められないUNIXサーバのセキュリティ対策（7）（1/2 ページ）

　前回までは4回にわたり、サービスの利用制限について説明した。今回からはログの運用管理および監査方法について説明する。

運用管理で欠かせないログ管理

　UNIXでは、システムが出力したメッセージやアプリケーションの動作状況などを、ログとしてファイルなどに記録する。記録される内容には、正常な動作を示すメッセージから緊急事態を示すエラーメッセージまで、さまざまな事象が含まれることから、ログはUNIXサーバを運用管理するうえで欠かせない存在となっている。

　本稿では、UNIXログシステムの大半を担うsyslogを中心に、現状の把握と見直しを行う。

ログの種類と出力方法

　UNIXのログには、システムの異常を示すログ、ユーザーのログイン履歴や認証時のログ、メールシステムの送信ログ、さらにはサーバプログラムの動作ログなど、その用途に応じてさまざまな種類が存在する。そして、それらのログは、syslogなどのログ制御システムを介して出力される場合もあれば、プログラム自身が出力する場合もある。

　UNIXサーバにおいて、一般的なログの種類と格納先を表1に示す。

syslogとプログラムの出力するログ

　前述のとおり、UNIXのログの出力方法は、ログ制御システム（syslog）を介して出力する方法と、プログラム自身が出力する方法に大別される。

　前者のsyslogは、もともとはメールサーバプログラムのsendmail用として開発されたものだが、それが広く浸透し、いまではUNIXにおいて当たり前のように利用されるまでになった。表1でも示したとおり、UNIXログの大半は、このsyslogによって制御・出力されている。

　後者は、前者のsyslogのようなログ専用サービスに出力を任せるのではなく、自分自身でログをファイルに保存する。この方法は、syslogとは異なる形式でログに保存したい場合や、WebサーバのApache＊1など、ログファイルへの書き込みが頻発する、処理数の多いサービスで用いられている。

　本稿では、前者のsyslogを中心に説明する。

syslogの設定内容を理解する

　UNIXサーバ管理者は、syslogが、どういった内容を、どこに出力するのかを把握しておく必要がある。そのためには、まずsyslogで設定されている内容自体を理解することから始める。

syslogの仕組み

　前述のとおり、syslog（RFC3196）は、もともとsendmail用のログ制御システムとして開発されたもので、現在広く浸透しているsyslogは、BSD版がオリジナルとなっている。

　syslogのおおまかなデータの流れを図1に示す。

図1 syslogのデータの流れ

　図1に示すとおり、外部サーバからのログデータの受け取りは、514/udp＊2のインターネットドメインソケット＊3を使って行われる。自分自身のログデータは、UNIXドメインソケットの/dev/logを使う。ただし、カーネルの出力メッセージの場合は、/dev/klogが使用されることになる＊4。syslogは、これらすべてのログデータのやりとりを、syslogサーバプログラムのsyslogdで行い、その動作は、/etc/syslog.confの内容に基づき決定される。

syslogの設定（syslog.confの書式）

　syslogに関する設定は、/etc/syslog.confの値で決まる。syslogdは、このsyslog.confの設定内容を読み込み、実際の運用に適用する。

　基本的なsyslog.confの記述形式は、以下のとおりとなる。なお、「facility」「priority」「ログの出力先」の詳細については後述する。

　左辺のfacilityとpriorityは、ドット（.）で区切る。1つの出力先に、facilityとpriorityを複数指定する場合は、セミコロン（;）で区切る必要がある。

facility.priority;facility.priority;……

　また、「facility.priority」と「ログの出力先」は、必ずタブ（TAB）で区切る必要がある。最近では、空白も指定可能なsyslogdもあるが、いらぬトラブルを招かないためにも、“syslog.confはタブ（TAB）で区切る”と覚えておくとよいだろう。

facility（機能）とpriority（重要度）を理解する

　syslogを理解するうえで必ず避けて通れないのが、facilityとpriorityの設定項目だ。このfacilityとpriorityの値を調整することで、意図したログの内容を、特定の出力先に出力することが可能になる。

• facility（機能）

facilityの代表的な値は、表2のとおりとなる。機能（項目）別に設定すべき値があらかじめ定義されている。また、複数のfacilityを指定したい場合は「,」（カンマ）で接続して使用する。

• priority（重要度）

priorityの代表的な値は、表3のとおりとなる。上にいくほど緊急度が高くなり、条件として、設定した値またはそれよりも緊急度が高い場合に限り、ログメッセージが出力される。

• ログの出力先

syslog.confの右辺では、facilityとpriorityで定義したログの内容を、どこに出力するかを定義する。出力先は表4のとおりとなる。

設定内容を反映させる

　/etc/syslog.confに設定した内容を反映させるには、syslogdにHUP（ハングアップ）シグナルを送り込めばよい（kill -HUP syslogdのプロセスID）。

# ps -ax | grep syslogd
113 ?? Ss 0:00.46 /usr/sbin/syslogd -s
# kill -HUP 113

　または、

# kill -HUP `cat /var/run/syslogd.pid`

　のように実行する。なお、正しく反映されたかどうかは、後述の「設定内容の確認（loggerコマンド）」で確認するとよいだろう。

syslogの設定例

　それでは、実際にsyslog.confの代表的な設定例をいくつか紹介する。

　なお、設定を変更した場合は、前述の「設定内容を反映させる」の手順が必要になる。

　例：メールに関するすべてのログ（mail.*）は、/var/log/maillogに格納する。

mail.*                  /var/log/maillog

　例：警告レベルのすべてのログ（*.alert）は、ユーザーrootおよびkimuに通知する。

*.alert     root,kimu

　例：緊急事態のすべてのログ（*.emerg）は、ログイン中のすべてのユーザーに一斉通知する。

*.emerg     *

　例：すべてのエラーログ（*.err）、およびカーネルに関するすべてのログ（kernel.*）は、コンソール画面（/dev/console）に表示する。

*.err;kernel.*     /dev/console

　例：すべての警告レベル以上のログ（*.alert）は、任意のプログラム（例では/usr/local/bin/logscript）に渡す。

*.alert     |/usr/local/bin/logscript

　例：認証関連のすべてのログ（auth,authpriv.*）は、ログサーバloghost.example.co.jpに転送する。

auth,authpriv.*     @loghost.example.co.jp

　なお、ログサーバへの転送については、次回説明する。

　次ページでは、syslogの設定について見直すことにする（続く）。