【連載】
止められないUNIXサーバのセキュリティ対策

第8回 syslogによるログの一元管理


三井物産GTI （現：三井物産セキュアディレクション株式会社）
木村　靖
2004/2/25

※ご注意 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。

---

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

syslogによるログの一元管理

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

●syslogによるログの転送

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

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

図1 syslogによるログ転送

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

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

【メリット】

・各サーバのログを一元管理できる

・ログの改ざんを高い確率で防げる

【デメリット】

・UDPによる転送のため取りこぼしの可能性が生じる

・ログ・サーバを準備するためのコストが掛かる（ログ専用機にした場合）

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

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

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

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

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

ログ転送の設定

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

●サーバの時刻同期を行う

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

＊2 【参考記事】 ・Windows TIPS ：NTPでネットワーク全体のマシンの時刻を合わせる ・Linux Tips Index：時間を正確に合わせるには

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

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

　ログ・サーバでは、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ソフトウェアの導入について説明する。

「第7回」へ

「第9回」へ

index

第1回 不要なサービスの停止こそ管理の第一歩

第2回 ソフトウェアの現状確認とアップグレード

第3回 サービスをセキュアにするための利用制限（1）

第4回 サービスをセキュアにするための利用制限（2）

第5回 サービスをセキュアにするための利用制限（3）

第6回 特権ユーザーの安全性向上を行うsudoの設定例

第7回 UNIXサーバの運用管理で欠かせないログ管理

第8回 syslogによるログの一元管理         syslogによるログの一元管理         ログ転送の設定         ログ転送の確認

関連記事

連載：Webアプリケーションに潜むセキュリティホール

特集：クロスサイトスクリプティング対策の基本

連載：インシデントレスポンスはじめの一歩〜rootkitを検出するために

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）