本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。前回は、UNIXのログ管理の基本となるsyslogの仕組みと設定方法について述べた。今回は、syslogによる別のサーバへのログ転送について説明する。前回説明したとおり、syslogには、ログを別のsyslogサーバに転送する機能がある。syslogでは、その機能を使って各サーバのログを1カ所に集めることで、ログの一元管理を実現できる。syslogによるログの転送syslogによるログの一元管理を実現させるためには、ログを受信するサーバ(ここではログ・サーバと表記)にて514/udpポートを待機状態(listen)にしておく必要がある。syslogでは、その514/udpポートを介して、サーバからサーバへのログ転送が行われる。ログを受信したログ・サーバでは、/etc/syslog.confの設定内容に従い、ログの出力先が決定される。syslogによるログ転送ログ転送によるメリット/デメリットログをログ・サーバに転送する場合、次のようなメリット/デメリットが生じる。各サーバのログを一元管理できるログの改ざんを高い確率で防げる【デメリット】UDPによる転送のため取りこぼしの可能性が生じるログ・サーバを準備するためのコストが掛かる(ログ専用機にした場合)「ログの改ざんを高い確率で防げる」は、攻撃者がサーバに侵入した際に、痕跡を消すためにログの改ざんを行うが、ログの転送を行っていれば、ログそのものがサーバ上には存在しないため、改ざんを防ぐことができる。ログ・サーバ自身に侵入されたらおしまいだが、ログ・サーバは、Webやメールといったほかの用途のサーバと違い、よりセキュアな環境を構築しやすい。ログ・サーバで提供するサービスは、極端な話514/udpのみでよく、また514/udpに対するアクセスをログの転送元からのみに絞り込むことで、侵入を困難にすることができる。デメリットに挙げた「UDPによる転送のため取りこぼしの可能性が生じる」は、UDPはTCPと違い相手に届いたかどうかの確認を行わず、また再送もしないため*1、ログの損失の可能性が生じる。その確率は、ログが大量かつ頻繁に発生するにつれ高くなる。*1その代償として、「TCPよりも高速なデータの配送」が得られる。ログ転送の設定それでは、syslogによるログ転送の設定を説明する。ログ転送の設定自体は非常に簡単だが、その前に行うべきことも踏まえ以下に説明する。サーバの時刻同期を行う最初に、各サーバおよびログ・サーバの時刻同期を行っておく。時刻同期には、NTP*2を使うのが通常だろう。時刻同期は、ログの監査を行う際に重要となるので、ログの転送を行う/行わないにかかわらず、必ず行うことをお勧めする。Index:時間を正確に合わせるにはログ・サーバをセキュアにするまずはログ・サーバ自身をセキュアにし、侵入の可能性をゼロに近づける必要がある。そのためには、まずは不要なポート(サービス)の停止から行う。ログ・サーバでは、514/udpポートのみが待機状態であればよいので、そのほかのポート(サービス)は停止しても構わない(必要に応じてsshなどメンテナンス系のサービスを許可すればよい)。不要なサービスの停止こそ管理の第一歩】を参照してほしい。各サーバでsyslogのログを転送する前に、転送先であるログ・サーバ側で、514/udpポートを待機状態にし、ログの受け入れを可能にしておく。ログ・サーバ(syslogd)の種類によっては、起動時に514/udpがデフォルトで待機状態になっている場合もあれば、そうでない場合もある。ない場合の多くは、前回説明したとおり、セキュリティを考慮して意図的に閉じていることが多い。514/udpが閉じられている場合は、待機状態にしなければならないが、そのためには、syslogdの再起動が必要となるので基幹サーバなどの場合は注意しよう。(1)514/udpポートの確認ログ・サーバ上で514/udpが待機状態かどうかを確認する。確認には、netstatコマンドを使うとよい。514待機状態でない場合は何も表示されない。その場合は、次のsyslogdの再起動が必要となる。(2)514/udpを待機させる確認の結果、514/udpポートが閉じられていた場合は、514/udpポートを待機状態にさせる。4.6の場合syslogdに-sオプションが指定されていた場合は無効にし、syslogdを再起動させる必要がある。オプションを指定すると514/udpに対するアクセス制限を行えるので、それも併せて設定するとよい。514/udpに対するsyslog転送を許可する。192.168.0.0/24:*次回OS起動時も同様に行いたい場合は、/etc/rc.confのsyslogd_flags変数にセットしておく必要がある。1.6の場合FreeBSD同様、syslogdに-sオプションが指定されていた場合は無効にし、syslogdを再起動させる必要がある。/etc/rc.confにオプションなしのsyslogd_flags変数を追加する。syslogd_flags=""追加後、syslogdを再起動する。8の場合デフォルトで待機状態となっているため特に変更の必要はないが、もしsyslogdに-tオプションが指定されていた場合は、無効にする必要がある。7.3の場合/etc/sysconfig/syslogのSYSLOGD_OPTIONS変数に、-rを追加する。-r"修正後、syslogdを再起動させる。実際にログ・サーバ上で514/udpが待機状態になったかどうかを確認する。確認には、同じくnetstatコマンドを使う。*.*待機状態の場合は、上記のような表示がされる。これで、いつでもログを受け取れる状態になった。転送元サーバの設定ログの転送元となるサーバでは、ログ転送を行うための設定をsyslog.confに追加する必要がある。例:すべてのログをホスト名loghost(IPアドレス192.168.0.10)に転送する。(1)/etc/hostsにログ・サーバのホスト名/IPアドレスを追加するホスト名loghostを名前解決できるように、/etc/hosts*3に以下の一行を追加する。loghostという名前は、Solarisなどではログのデフォルトの出力先として/etc/hostsに登録されている場合があるので、重複しない名前を割り当てる必要がある。loghost*3DNSによる名前解決も可能だが、あまりお勧めはしない。DNSサーバが停止した場合に、ログ・サーバの名前解決が行えず、その間のログは転送できないため破棄されてしまうからだ。IPアドレスの直接指定も可能だが、後々のメンテナンスを考えると、IPアドレスの直接指定は避けた方がよいだろう。@loghost@の右側のloghostは、先ほど/etc/hostsに記述したログ・サーバを指定する。*.*で、すべてのfacilityとpriorityをloghostに転送することになるが、もちろん特定のfacilityとpriorityのみ転送することができる。facilityがauthprivのログを転送する場合は、以下のようにすればよい。@loghost*4追加するのは、慎重に移行するためである。ログ転送の移行が完了するまで既存の設定を残し、たとえ移行中にログ転送に失敗しても、既存の出力先にログは格納されているので、ログの取りこぼしを防ぐことができる。(3)syslogdに設定を再読み込みさせるsyslogdにHUPシグナルを送信し、/etc/syslog.confの内容を再読み込みさせる。/var/run/syslogd.pid`ここまでできたら、ログ転送のための設定は完了となる。後は、後述の確認作業で実際に転送できるかどうかを確認する。ログ転送の確認ログ転送のための設定が完了したら、即座に確認を行う。確認は、前回説明したloggerコマンドを使うとよい。desu」のメッセージを出力させる場合は以下のように実行する。desu"うまくいくとログ・サーバ上のログの出力先には、以下のようなメッセージが出力される。ログであることが分かる。複数台のサーバがある場合も同様に行う。192.168.0.51から行うと、以下のように記録される。この場合、前者と同じ出力先にログが出力される。testなお、ログの監査をしやすくするために、IPアドレスではなく、ホスト名でログに出力したい場合は、/etc/hostsにそれぞれの名前を追加しておくとよい。server2保存した後は、以下のように出力される。test転送がうまくいかない場合ログの転送がうまくいかない場合は、単純な設定ミスか、あるいはネットワークまわりのトラブルが考えられる。一般的には、前者の設定ミスであることが多いが、いずれにせよ、どこが悪いのかを切り分けるためには、ログのパケットが正常に送信されているかどうかを確認すればよい。パケットの送信確認は、tcpdumpやsnoopといったコマンドを使うことになる*5。Filter)などのパケットキャプチャ機能がカーネルレベルで無効(off)になっていたりするなど、tcpdumpやsnoopは、必ずしも利用可能であるとは限らない。tcpdumpにて、ログ・サーバ(192.168.0.10)の514/udpに対してパケットが送信されているかどうかを確認するには、以下のとおり実行する。34ログの転送元(192.168.0.50)からログ・サーバ(192.168.0.10)に対してパケットが送信されていることが分かる。この時点でパケットが流れない場合は、ログの転送元に原因があることが特定できる(syslog.confの記述ミス、ホスト名解決できないなど)。逆に、上記のとおりパケットは流れている場合は、ログ・サーバ側に問題があることが特定できる(514/udpが待機状態でない、アクセス拒否をしているなど)。今回は、syslogによるログ転送について説明した。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。