syslogによるログの一元管理止められないUNIXサーバのセキュリティ対策(8)

» 2004年02月25日 00時00分 公開
[木村靖三井物産GTI]
※ご注意
本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。

 前回は、UNIXのログ管理の基本となるsyslogの仕組みと設定方法について述べた。今回は、syslogによる別のサーバへのログ転送について説明する。

syslogによるログの一元管理

 前回説明したとおり、syslogには、ログを別のsyslogサーバに転送する機能がある。syslogでは、その機能を使って各サーバのログを1カ所に集めることで、ログの一元管理を実現できる。

syslogによるログの転送

 syslogによるログの一元管理を実現させるためには、ログを受信するサーバ(ここではログ・サーバと表記)にて514/udpポートを待機状態(listen)にしておく必要がある。

 syslogでは、その514/udpポートを介して、サーバからサーバへのログ転送が行われる。そして、ログを受信したログ・サーバでは、/etc/syslog.confの設定内容に従い、ログの出力先が決定される。

図1 syslogによるログ転送 図1 syslogによるログ転送

ログ転送によるメリット/デメリット

 ログをログ・サーバに転送する場合、次のようなメリット/デメリットが生じる。

【メリット】

  • 各サーバのログを一元管理できる
  • ログの改ざんを高い確率で防げる

【デメリット】

  • UDPによる転送のため取りこぼしの可能性が生じる
  • ログ・サーバを準備するためのコストが掛かる(ログ専用機にした場合)

 「ログの改ざんを高い確率で防げる」は、攻撃者がサーバに侵入した際に、痕跡を消すためにログの改ざんを行うが、ログの転送を行っていれば、ログそのものがサーバ上には存在しないため、改ざんを防ぐことができる。

 もちろんログ・サーバ自身に侵入されたらおしまいだが、ログ・サーバは、Webやメールといったほかの用途のサーバと違い、よりセキュアな環境を構築しやすい。

 例えば、ログ・サーバで提供するサービスは、極端な話514/udpのみでよく、また514/udpに対するアクセスをログの転送元からのみに絞り込むことで、侵入を困難にすることができる。

 デメリットに挙げた「UDPによる転送のため取りこぼしの可能性が生じる」は、UDPはTCPと違い相手に届いたかどうかの確認を行わず、また再送もしないため*1、ログの損失の可能性が生じる。その確率は、ログが大量かつ頻繁に発生するにつれ高くなる。

*1
その代償として、「TCPよりも高速なデータの配送」が得られる。

ログ転送の設定

 それでは、syslogによるログ転送の設定を説明する。ログ転送の設定自体は非常に簡単だが、その前に行うべきことも踏まえ以下に説明する。

サーバの時刻同期を行う

 最初に、各サーバおよびログ・サーバの時刻同期を行っておく。時刻同期には、NTP*2を使うのが通常だろう。時刻同期は、ログの監査を行う際に重要となるので、ログの転送を行う/行わないにかかわらず、必ず行うことをお勧めする。

ログ・サーバをセキュアにする

 まずはログ・サーバ自身をセキュアにし、侵入の可能性をゼロに近づける必要がある。そのためには、まずは不要なポート(サービス)の停止から行う。

 ログ・サーバでは、514/udpポートのみが待機状態であればよいので、そのほかのポート(サービス)は停止しても構わない(必要に応じてsshなどメンテナンス系のサービスを許可すればよい)。

 なお、不要なサービスの停止については、本連載の【第1回 不要なサービスの停止こそ管理の第一歩】を参照してほしい。

ログ・サーバのログ受信設定

 各サーバでsyslogのログを転送する前に、転送先であるログ・サーバ側で、514/udpポートを待機状態にし、ログの受け入れを可能にしておく。

 ログ・サーバ(syslogd)の種類によっては、起動時に514/udpがデフォルトで待機状態になっている場合もあれば、そうでない場合もある。そうでない場合の多くは、前回説明したとおり、セキュリティを考慮して意図的に閉じていることが多い。514/udpが閉じられている場合は、待機状態にしなければならないが、そのためには、syslogdの再起動が必要となるので基幹サーバなどの場合は注意しよう。

(1)514/udpポートの確認

 ログ・サーバ上で514/udpが待機状態かどうかを確認する。確認には、netstatコマンドを使うとよい。

% netstat -an | grep -i udp | grep 514

 待機状態でない場合は何も表示されない。その場合は、次のsyslogdの再起動が必要となる。

(2)514/udpを待機させる

 確認の結果、514/udpポートが閉じられていた場合は、514/udpポートを待機状態にさせる。

  • FreeBSD 4.6の場合

syslogdに-sオプションが指定されていた場合は無効にし、syslogdを再起動させる必要がある。また、FreeBSDのsyslogdには、-a オプションを指定すると514/udpに対するアクセス制限を行えるので、それも併せて設定するとよい。

例:192.168.0.0/24 からの514/udpに対するsyslog転送を許可する。

 1)syslogdの停止

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

 2)syslogdの起動(-sの除外と-aの追加)

    # /usr/sbin/syslogd -a 192.168.0.0/24:*

次回OS起動時も同様に行いたい場合は、/etc/rc.confのsyslogd_flags変数にセットしておく必要がある。

    syslogd_flags="-a 192.168.0.0/24:*"
  • NetBSD 1.6の場合

FreeBSD同様、syslogdに-sオプションが指定されていた場合は無効にし、syslogdを再起動させる必要がある。/etc/rc.confにオプションなしのsyslogd_flags変数を追加する。

    syslogd_flags=""

追加後、syslogdを再起動する。

    # /etc/rc.d/syslogd restart
  • Solaris 8の場合

デフォルトで待機状態となっているため特に変更の必要はないが、もしsyslogdに-tオプションが指定されていた場合は、無効にする必要がある。

  • Red Hat Linux 7.3の場合

/etc/sysconfig/syslogのSYSLOGD_OPTIONS変数に、-rを追加する。

変更前:

    SYSLOGD_OPTIONS="-m 0"

変更後:

    SYSLOGD_OPTIONS="-m 0 -r"

修正後、syslogdを再起動させる。

    # service syslog restart

(3)514/udpポートの再確認

 実際にログ・サーバ上で514/udpが待機状態になったかどうかを確認する。確認には、同じくnetstatコマンドを使う。

% netstat -an | grep -i udp | grep 514
udp        0      0  *.514                  *.*

 待機状態の場合は、上記のような表示がされる。これで、いつでもログを受け取れる状態になった。

転送元サーバの設定

 ログの転送元となるサーバでは、ログ転送を行うための設定をsyslog.confに追加する必要がある。

 例:すべてのログをホスト名loghost(IPアドレス192.168.0.10)に転送する。

(1)/etc/hostsにログ・サーバのホスト名/IPアドレスを追加する

 ホスト名loghostを名前解決できるように、/etc/hosts*3に以下の一行を追加する。

 なお、loghostという名前は、Solarisなどではログのデフォルトの出力先として/etc/hostsに登録されている場合があるので、重複しない名前を割り当てる必要がある。

192.168.0.10 loghost

*3
DNSによる名前解決も可能だが、あまりお勧めはしない。なぜなら、DNSサーバが停止した場合に、ログ・サーバの名前解決が行えず、その間のログは転送できないため破棄されてしまうからだ。
また、IPアドレスの直接指定も可能だが、後々のメンテナンスを考えると、IPアドレスの直接指定は避けた方がよいだろう。

(2)/etc/syslog.confにログ転送の設定を追加*4する

*.*             @loghost

 @の右側のloghostは、先ほど/etc/hostsに記述したログ・サーバを指定する。*.*で、すべてのfacilityとpriorityをloghostに転送することになるが、もちろん特定のfacilityとpriorityのみ転送することができる。

 例えば、facilityがauthprivのログを転送する場合は、以下のようにすればよい。

authpriv.*              @loghost

*4
追加するのは、慎重に移行するためである。ログ転送の移行が完了するまで既存の設定を残し、たとえ移行中にログ転送に失敗しても、既存の出力先にログは格納されているので、ログの取りこぼしを防ぐことができる。

(3)syslogdに設定を再読み込みさせる

 syslogdにHUPシグナルを送信し、/etc/syslog.confの内容を再読み込みさせる。

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

 ここまでできたら、ログ転送のための設定は完了となる。後は、後述の確認作業で実際に転送できるかどうかを確認する。

ログ転送の確認

 ログ転送のための設定が完了したら、即座に確認を行う。

loggerコマンドによる確認

 確認は、前回説明したloggerコマンドを使うとよい。

 例えば、facilityがauthpriv、priorityがinfoの出力先に、「koreha test desu」のメッセージを出力させる場合は以下のように実行する。

% logger -p authpriv.info "koreha test desu"

 うまくいくとログ・サーバ上のログの出力先には、以下のようなメッセージが出力される。

Feb 13 00:44:02 192.168.0.50 kimu: log tensou test

 上記より、192.168.0.50 からのログであることが分かる。複数台のサーバがある場合も同様に行う。例えば192.168.0.51から行うと、以下のように記録される。この場合、前者と同じ出力先にログが出力される。

Feb 13 00:48:37 192.168.0.51 kimu: log tensou test

 なお、ログの監査をしやすくするために、IPアドレスではなく、ホスト名でログに出力したい場合は、/etc/hostsにそれぞれの名前を追加しておくとよい。

192.168.0.50 server1
192.168.0.51 server2

 保存した後は、以下のように出力される。

Feb 13 00:50:26 server1 kimu: log tensou test
Feb 13 00:51:04 server2 kimu: log tensou test

転送がうまくいかない場合

 ログの転送がうまくいかない場合は、単純な設定ミスか、あるいはネットワークまわりのトラブルが考えられる。

 一般的には、前者の設定ミスであることが多いが、いずれにせよ、どこが悪いのかを切り分けるためには、ログのパケットが正常に送信されているかどうかを確認すればよい。パケットの送信確認は、tcpdumpやsnoopといったコマンドを使うことになる*5

*5
盗み見を防ぐなどのセキュリティ上の理由により、tcpdumpやsnoopがもともとインストールされていなかったり、bpf(Berkeley Packet Filter)やLPF(Linux Packet Filter)などのパケットキャプチャ機能がカーネルレベルで無効(off)になっていたりするなど、tcpdumpやsnoopは、必ずしも利用可能であるとは限らない。

 例えばtcpdumpにて、ログ・サーバ(192.168.0.10)の514/udpに対してパケットが送信されているかどうかを確認するには、以下のとおり実行する。

# tcpdump -n -i fxp0 udp and dst host 192.168.0.10 and dst port 514
02:34:31.383954 192.168.0.50.514 > 192.168.0.10.514: udp 34

 ログの転送元(192.168.0.50)からログ・サーバ(192.168.0.10)に対してパケットが送信されていることが分かる。

 もし、この時点でパケットが流れない場合は、ログの転送元に原因があることが特定できる(syslog.confの記述ミス、ホスト名解決できないなど)。

 逆に、上記のとおりパケットは流れている場合は、ログ・サーバ側に問題があることが特定できる(514/udpが待機状態でない、アクセス拒否をしているなど)。


 今回は、syslogによるログ転送について説明した。次回は、今回紹介できなかった、セキュリティを考慮したsyslogソフトウェアの導入について説明する。

筆者紹介

三井物産GTI (現:三井物産セキュアディレクション株式会社

木村靖



Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。