BigAdmin: 特集記事: syslog-ng および Stunnel による集中セキュアログサーバーの作成

Skip to Content Sun and Oracle Channel Sun How to Buy Log In United States [Change] English

BigAdmin System Administration Portal

特集記事: syslog-ng および Stunnel による集中セキュアログサーバーの作成

Print-friendly Version

Submit Content | Check BigAdmin Bucks

syslog-ng および Stunnel による集中セキュアログサーバーの作成

Amy Rich、2004 年 9 月

Stunnel のインストール
Stunnel で syslog-ng を使用するための証明書ファイルの作成
syslog-ng とともに使用するための Stunnel の構成
syslog-ng のインストール
syslog-ng の構成
参考資料

UNIX のシステム管理者にとっては、syslog デーモンはかなりなじみ深いものですが、デーモンが収集する情報は、問題が含まれていることをだれかが報告しないかぎり、処理されないままに終わることが頻繁にあります。マシンの数が少なからずあるサイトでは、日次であれ月次であれ、わざわざ時間を割いてログインし、複数のログファイルをチェックする人はいません。複数のマシン間でデータを関連付けることのできる自動スクリプトは、各マシンに個別にアクセスする必要があるため、書くことが困難です。自動および手動でのデータ処理の負荷を削減するため、多くのサイトでは、中央ログサーバーを実装し、UNIX サーバー、Windows デスクトップ、Mac デスクトップ、およびルーターやスイッチなどのネットワーク機器を含むすべてのマシン (できれば時刻と日付を簡単に関係付けることができるように、NTP を実行していることが望ましい) のデータを収集しています。集中化ロギングは、従来の UNIX syslog デーモンのほとんどにとっては、かなりありふれたもので、syslogd は初期実装からほとんど変更されておらず、欠点が残っています。

標準 UNIX の syslog デーモンは、UDP 上でメッセージを自由に転送します。つまり、機密性があるデータを、だれでも探り出せるということです。また、facility.level モデルにはかなり制約があり、ほとんどのオペレーティングシステムに付属しているデフォルトの /etc/syslog.conf ファイルは、管理者にとって意味のある数多くのメッセージを記録しません。判読可能な形でログを解析したり、自動的にデータマイニングを行なったりするのは、容易なことではありません。たとえば、UNIX の syslog デーモンでは、ユーザーがホスト別にログファイルを分割したり、ログメッセージを正規表現に一致させたりすることは、簡単にはできませんこのため、従来の syslog デーモンを使用する大部分の集中化ログサーバーは、結局、一体型のログファイルを生成する以上のことを行いません。ログファイルは、syslogd プロセスによって閉じられてはじめて処理されます。

そのため、ロギングを集中化するサイトの大部分は、従来の syslog デーモンを、Metalog、msyslog、または類似のものなど、もっと安全で柔軟なものに交換しています。syslog の一般的な代替方法としては、オープンソースプログラムの syslog-ng があります。組織では、各 UNIX ホスト上で、または単に syslog サーバー自体で、syslog-ng を実行できます。syslog-ng がログホスト上でのみ実行される場合、クライアントは通常どおりデータを UDP ポート 514 経由で送信しますが、ログの編成および操作はサーバー上でのほうが行いやすくなります。

各 UNIX ホストで syslog-ng を実行することの利点は、データが不意に盗聴されないように、IPSec や Stunnel ユーティリティーを使用してロギングチャネルを暗号化できることです。トランスポート機構として Stunnel と組み合わせることによって、組織は、希望するすべての UNIX ホストからのログメッセージを集中化して安全に追加処理できます。syslog-ng の場合、Stunnel の機能は、ローカルポートでログ接続を受け入れ、接続を SSL セッションでラップして、リモートログホストの安全なポートにリダイレクトすることです。次に、リモートログホスト上の stunnel プロセスが、SSL セッションを復号化し、その復号化した情報を標準ポートで syslog サーバーに返します。今度はログサーバー上なので、ログファイルの編成および解析は、syslog-ng の柔軟性を使用して行われます。

SPARC プラットフォーム版 Solaris 8 オペレーティングシステムを稼働するマシンに、syslog-ng と Stunnel をインストールおよび構成する手順についてはあとで説明しますが、この手順は、SPARC プラットフォーム版および x86 プラットフォーム版の Solaris OS の、旧バージョンおよび最新バージョンのすべてに使用できます。後述の各リファレンスマシンには、OpenSSL、TCP ラッパー、Solaris 8 /dev/urandom patch、GNU 開発環境 (gcc など)、およびその他のフリーウェアパッケージがインストールされています。また、ログサーバーとして使用されるマシンは、徹底的に堅牢化されています。これは、ネットワークのすべてのマシンから、セキュリティー関連の機密情報を集めて保管するからです。すべてのリファレンスマシンはサブネット 192.168.1 上にあり、ログサーバーの IP アドレスは 192.168.1.10 になります。

Stunnel のインストール

セキュアログサーバーを実装する最初の手順は、Stunnel をサーバーおよび各クライアントにインストールすることです。また、Stunnel は、(syslog を syslog-ng に交換しないで) 従来の syslog デーモンと一緒にも使用できますが、そうすると、求めている柔軟性が得られなくなります。後述の手順では、stunnel を独自のユーザーおよびグループで稼働するように構成および構築し、非公開の独自のディレクトリにディレクトリ変更しています。そのために、ここではまず stunnel のグループおよびユーザーを作成しておきます (UID および GID は無作為に選択されます)。

/usr/sbin/groupadd -g 122 stunnel
/usr/sbin/useradd -c stunnel -d /nonexistent -m -g 122 -u 122 stunnel

次に、Stunnel ソースを取得し、展開して構成します。各ホストで、OpenSSL 証明書は /usr/local/etc/openssl/certs に保存されますが、それ以外にローカルにインストールされたドキュメントインストール用のドキュメントディレクトリは、/usr/local に保持します。また、localstatedir を /var/run/stunnel に設定します。これは、再起動後に持続している必要がないためと、筆者がディレクトリ変更後のディクトリ内に設定したいためです。

wget http://www.stunnel.org/download/stunnel/src/stunnel-4.05.tar.gz
tar zxf stunnel-4.05.tar.gz
cd stunnel-4.05

./configure --localstatedir=/var/run/stunnel \
 --with-pem-dir=/usr/local/etc/openssl/certs --datadir=/usr/local

make
make install

Stunnel で syslog-ng を使用するための証明書ファイルの作成

Stunnel インストールプロセスは、必要に応じて使用できる自己署名付き証明書を作成します。非公開の自身の認証局を運営しており、Stunnel を syslog-ng 用にのみ実行するので、syslog-ng 自分専用の証明書を生成してそれに署名します。自身の CA を設定して証明書に署名する手順については、「SSL 証明書の手引き」をご覧ください。

自身の CA として自分を設定して、公的に認められている別の CA に証明書要求を提示する場合は、サーバーの PEM ファイルを作成します。

openssl req -new -days 3650 -nodes -config stunnel.cnf -out serverreq.pem \
-keyout syslog-ng-server.pem

また、各クライアントに対応する PEM ファイルも作成します。

openssl req -new -days 3650 -nodes -config stunnel.cnf -out clientreq.pem \
-keyout syslog-ng-client.pem

各 PEM ファイルにローカル CA で署名するか、または公開 CA に署名してもらいます。ここでは、apache の mod_ssl ディストリビューションに付属している sign.sh スクリプトを使用します。

sign.sh /tmp/serverreq.pem 
sign.sh /tmp/client1req.pem 
sign.sh /tmp/client2req.pem
sign.sh /tmp/client3req.pem

結果の crt ファイルには、対応する各 PEM ファイルの証明書が含まれています。サーバーには、サーバーの PEM ファイル syslog-ng-server.pem、および /tmp/serverreq.pem.crt ファイルからコピーされたサーバーの非公開鍵と証明書が必要です。

また、サーバーには、クライアントの PEM ファイル syslog-ng-client.pem に加え、次のような、crt ファイルを基にした、署名元 CA からの証明書および各クライアントからの証明書のみが必要です (この例では、3 つの syslog-ng クライアントを想定しています)。

各クライアントは、PEM ファイル syslog-ng-client.pem 内に、独自の証明書および非公開鍵を持つことが必要です。

また、各クライアントには、次のようなサーバーからの証明書と署名元 CA からの証明書を含む PEM ファイル、syslog-ng-server.pem も必要です。

セキュリティーを保護するため、各マシン上でルートのみが証明書ファイルを読み取れることを確認してください。

chmod 400 /usr/local/etc/openssl/certs/syslog-ng-*
chown root:other /usr/local/etc/openssl/certs/syslog-ng-*

syslog-ng とともに使用するための Stunnel の構成

サーバー上で、次に示すような情報を内容とする syslog-ng 専用 Stunnel 構成ファイル、/usr/local/etc/stunnel/stunnel.conf を作成します。このサンプルファイルでは、ローカルの証明書およびキー、サーバーの証明書、ユーザーおよびグループとしての stunnel、chroot ディレクトリを指定しています。verify の値 3 により、stunnel は、ローカルにインストールされている証明書を使用して接続先を検証します。Stunnel はデフォルトでは検証をオフにしているので、ここで検証をオンにすることは重要です。構成ファイルの最後のセクションでは、SSL によってラップされるセッションのポート番号および IP:ポートを指定します。いずれも、接続が受け入れられてリダイレクトされるポートです。ポート 514 は標準の syslog ポートで、5140 は無作為に選択された未使用のポートです。追加情報および構成オプションについては、stunnel のマニュアルページを参照してください。

cert = /usr/local/etc/openssl/certs/syslog-ng-server.pem
CAfile = /usr/local/etc/openssl/certs/syslog-ng-client.pem
chroot = /var/run/stunnel
pid = /run/stunnel.pid
setuid = stunnel
setgid = stunnel
verify = 3
[5140]
   accept = 192.168.1.10:5140
   connect = 127.0.0.1:514

各クライアントにおいて、syslog-ng 専用の /usr/local/etc/stunnel/stunnel.conf ファイルは、サーバーの stunnel.conf ファイルと似たディレクティブを含んでいます。cert の値と CAfile の値、および accept の値と connect の値は交換され、client ディレクティブが追加されています。

client = yes
cert = /usr/local/etc/openssl/certs/syslog-ng-client.pem
CAfile = /usr/local/etc/openssl/certs/syslog-ng-server.pem
chroot = /var/run/stunnel
pid = /run/stunnel.pid
setuid = stunnel
setgid = stunnel
verify = 3
[5140]
   accept = 127.0.0.1:514
   connect = 192.168.1.10:5140

これで、Stunnel が構成されたので、syslog-ng のインストールおよび構成の準備が完了しました。この時点で Stunnel をテストする場合は、IMAP または telnet など、別の TCP ポートまたはサービスを代わりに使用するように Stunnel を構成します。詳細は、Stunnel Examples のページを参照してください。

syslog-ng のインストール

syslog-ng の安定したバージョンを実行すると、まずライブラリ libol をインストールするか、または少なくともビルドするように要求されます。次に示すように、ライブラリをダウンロードし、展開してインストールします。

wget http://www.balabit.com/downloads/libol/0.3/libol-0.3.14.tar.gz
tar zxf libol-0.3.14.tar.gz
cd libol-0.3.14

./configure
make
make install

次に、syslog-ng のソースを取得して展開し、構成してインストールします。ここでは、構成の際に TCP ラッパーのサポートも追加しました。インストールして実際に他のデーモンに対して使用しているからです。

wget http://www.balabit.com/downloads/syslog-ng/1.6/src/syslog-ng-1.6.5.tar.gz
tar zxf syslog-ng-1.6.5.tar.gz
cd ../syslog-ng-1.6.5

./configure --enable-tcp-wrapper
make
make install

パケットフィルタまたは TCP ラッパーで必ず適切なポートを開くようにします。暗号化されていない復号化された syslog メッセージもログホストで受け入れる場合には、サーバーは、TCP ポート 5140 および UDP ポート 514 でクライアントからの接続を受け入れる必要があります。TCP ラッパーのための拡張構文をサポートするため、サーバーの /etc/hosts.deny に次を追加します。

syslog-ng :LOCAL 127.0.0.1 192.168.1. :ALLOW

また、クライアントの /etc/hosts.deny に次を追加します。

syslog-ng :LOCAL 127.0.0.1 :ALLOW

次に、各マシンの起動時に実行される stunnel および syslog-ng の起動スクリプト、/etc/init.d/syslog-ng を作成します。次のスクリプトは、Solaris 8 OS の syslog 起動スクリプトを土台にしており、stunnel および syslog-ng を起動するだけでなく savecore も実行します。

#!/sbin/sh
#

case "$1" in
'start')
	if [ -f /usr/local/etc/syslog-ng/syslog-ng.conf -a -x \
             /usr/local/sbin/syslog-ng ]; then
		#
		# Before syslogd starts, save any messages from previous
		# crash dumps so that messages appear in chronological order.
		#
		/usr/bin/savecore -m
		if [ -r /etc/dumpadm.conf ]; then
			. /etc/dumpadm.conf
			[ "x$DUMPADM_DEVICE" != xswap ] && \
			    /usr/bin/savecore -m -f $DUMPADM_DEVICE
		fi
		#
                # Start stunnel so logs are sent encrypted
                #
                if [ -f /usr/local/etc/stunnel/stunnel.conf \
                     -a -x /usr/local/sbin/stunnel ]; then
                   echo "Starting stunnel"
                   mkdir -p /var/run/stunnel/run
                   chown stunnel:stunnel /var/run/stunnel/run
		   /usr/local/sbin/stunnel 
                   echo "Starting syslog-ng"
                   /usr/local/sbin/syslog-ng 
                fi
	fi
	;;

'stop')
	if [ -f /var/run/syslog-ng.pid ]; then
		syspid=`/usr/bin/cat /var/run/syslog-ng.pid`
		[ "$syspid" -gt 0 ] && kill -15 $syspid && \
                echo "Killed syslog-ng"
	fi
        if [ -f /var/run/stunnel/run/stunnel.pid ]; then
                syspid=`/usr/bin/cat /var/run/stunnel/run/stunnel.pid`
                [ "$syspid" -gt 0 ] && kill -15 $syspid && \
                echo "Killed stunnel"
        fi

	;;

*)
	echo "Usage: $0 { start | stop }"
	exit 1
	;;
esac

Solaris に内蔵されている syslog 起動スクリプトおよび停止スクリプトへのリンクを削除し、新しい syslog-ng スクリプトへのリンクに交換します。

rm /etc/rc*.d/???syslog
ln -s /etc/init.d/syslog-ng /etc/rc0.d/K40syslog-ng
ln -s /etc/init.d/syslog-ng /etc/rc1.d/K40syslog-ng
ln -s /etc/init.d/syslog-ng /etc/rc2.d/S74syslog-ng
ln -s /etc/init.d/syslog-ng /etc/rcS.d/K40syslog-ng

syslog-ng の構成

syslog-ng の柔軟性は、その構成ファイルにあります。操作の記録にとって重要な構成ディレクティブは、source、filter、destination、および log です。Source ディレクティブは、ローカルおよびリモートのログメッセージの起点を指定します。Filter ディレクティブは、機能、レベルまたは優先順位度、プログラム名、ホスト名、または正規表現一致を基準に、ログメッセージを分割できます。destination には、ファイル、パイプ、ストリーム、データグラム、UDP または TCP 接続、および tty、またはプログラムを指定できます。log ディレクティブは、一致したログメッセージの処理方法を定義するもので、source、filter、および destination ディレクティブのコレクションになっています。使用可能なディレクティブについての詳細は、『syslog-ng reference manual』を参照してください。 syslog-ng FAQ にはさまざまな例が記載されています。

次に、各ローカルホスト側の /var/log に格納されるログファイルの例、および集中化ログサーバー側の /var/log/clients/$YEAR/$MONTH/$HOST に格納されるログファイルの例を示します。まず、ログホスト側の /usr/local/etc/syslog-ng/syslog-ng.conf は、ローカルホスト、stunnel によって暗号化されたホスト、および stunnel を使用するように強制できないルーターおよびスイッチなど標準 UDP ホストからのメッセージをサポートします。フィルタは、機能およびレベル、プログラム名一致、およびこれらの組み合わせを使用しています。

# Options
options {
          use_fqdn(yes);
          sync(0);
          keep_hostname(yes);
          chain_hostnames(no);
	  create_dirs(yes);
        };

# Sources of syslog messages (both local and remote messages on the server)
source s_local   { 
                   sun-streams("/dev/log" door("/etc/.syslog_door")); 
                   internal();
                 };
source s_stunnel { 
                   tcp(ip("127.0.0.1")
                   port(514)
                   max-connections(1));
                 };

source s_udp     { udp(); };

# Level Filters
filter f_emerg   { level (emerg);            };
filter f_alert   { level (alert .. emerg);   };
filter f_crit    { level (crit .. emerg);    };
filter f_err     { level (err .. emerg);     };
filter f_warning { level (warning .. emerg); };
filter f_notice  { level (notice .. emerg);  };
filter f_info    { level (info .. emerg);    };
filter f_debug   { level (debug .. emerg);   };

# Facility Filters
filter f_kern   { facility (kern);   };
filter f_user   { facility (user);   };
filter f_mail   { facility (mail);   };
filter f_daemon { facility (daemon); };
filter f_auth   { facility (auth);   };
filter f_syslog { facility (syslog); };
filter f_lpr    { facility (lpr);    };
filter f_news   { facility (news);   };
filter f_uucp   { facility (uucp);   };
filter f_cron   { facility (cron);   };
filter f_local0 { facility (local0); };
filter f_local1 { facility (local1); };
filter f_local2 { facility (local2); };
filter f_local3 { facility (local3); };
filter f_local4 { facility (local4); };
filter f_local5 { facility (local5); };
filter f_local6 { facility (local6); };
filter f_local7 { facility (local7); };

# Custom Filters
filter f_user_none     { not facility (user);                     };
filter f_kern_debug    { filter (f_kern) and filter (f_debug);    };
filter f_daemon_notice { filter (f_daemon) and filter (f_notice); };
filter f_mail_crit     { filter (f_mail) and filter (f_crit);     };
filter f_mesg          { filter (f_kern_debug) or 
                         filter (f_daemon_notice) or 
                         filter (f_mail_crit);                    };
filter f_authinfo      { filter (f_auth) or program (sudo);       };

# Destinations: local files, the console, and the client files
destination l_authlog  { file ("/var/log/authlog");   };
destination l_messages { file ("/var/log/messages");  };
destination l_maillog  { file ("/var/log/maillog");   };
destination l_ipflog   { file ("/var/log/ipflog");    };
destination l_imaplog  { file ("/var/log/imaplog");   };
destination l_syslog   { file ("/var/log/syslog");    };

destination l_console  { file ("/dev/console");       };

destination r_authlog  { file
  ("/var/log/clients/$YEAR/$MONTH/$HOST/authlog");    }; 
destination r_messages { file 
  ("/var/log/clients/$YEAR/$MONTH/$HOST/messages");   }; 
destination r_maillog  { file 
  ("/var/log/clients/$YEAR/$MONTH/$HOST/maillog");    }; 
destination r_ipflog   { file 
  ("/var/log/clients/$YEAR/$MONTH/$HOST/ipflog");     }; 
destination r_imaplog  { file 
  ("/var/log/clients/$YEAR/$MONTH/$HOST/imaplog");    }; 
destination r_console  { file 
  ("/var/log/clients/$YEAR/$MONTH/$HOST/consolelog"); }; 
destination r_syslog   { file
  ("/var/log/clients/$YEAR/$MONTH/$HOST/syslog");     };
destination r_fallback { file
  ("/var/log/clients/$YEAR/$MONTH/$HOST/$FACILITY-$LEVEL"); };

# Log statements
# Local sources
log { source (s_local); filter (f_authinfo)  destination (l_authlog);  };
log { source (s_local); filter (f_mail);     destination (l_maillog);  };
log { source (s_local); filter (f_local0);   destination (l_ipflog);   };
log { source (s_local); filter (f_local1);   destination (l_imaplog);  };
log { source (s_local); filter (f_syslog);   destination (l_syslog);   };
log { source (s_local); filter (f_emerg); filter (f_user_none); 
                                             destination (l_console);  };
log { source (s_local); filter (f_mesg);  filter (f_user_none);
                                             destination (l_messages); }; 

# All sources, since we want to archive local and remote logs
log { source (s_local); source (s_stunnel); filter (f_authinfo);
     destination (r_authlog);   };
log { source (s_local); source (s_stunnel); filter (f_mail);
     destination (r_maillog);   };
log { source (s_local); source (s_stunnel); filter (f_local0);
   destination (r_ipflog);      };
log { source (s_local); source (s_stunnel); filter (f_local1);
   destination (r_imaplog);     };
log { source (s_local); source (s_stunnel); filter (f_syslog);
   destination (r_syslog);      };
log { source (s_local); source (s_stunnel); filter (f_emerg); 
      filter (f_user_none);
      destination (l_console);  };
log { source (s_local); source (s_stunnel); filter (f_mesg);
   filter (f_user_none);
      destination (l_messages); };

次に示すクライアント側の syslog-ng.conf の例では、フィルタは同じですが、それ以外の大部分の構成が、クライアントステータスを反映するように変更されているか、または削除されています。

# Options
options { 
          sync(0);
          use_fqdn(yes);
        };

# Sources of syslog messages (only local on clients)
source s_local { 
                 sun-streams("/dev/log" door("/etc/.syslog_door")); 
                 internal();
               };

# Destinations: local files, the console, and the remote syslog server
destination l_authlog  { file ("/var/log/authlog");   };
destination l_messages { file ("/var/log/messages");  };
destination l_maillog  { file ("/var/log/maillog");   };
destination l_ipflog   { file ("/var/log/ipflog");    };
destination l_imaplog  { file ("/var/log/imaplog");   };
destination l_console  { file ("/dev/console");       };
destination l_syslog   { file ("/var/log/syslog");    };
destination stunnel    { tcp ("127.0.0.1", port(514)); };

# Level Filters
filter f_emerg   { level (emerg);            };
filter f_alert   { level (alert .. emerg);   };
filter f_crit    { level (crit .. emerg);    };
filter f_err     { level (err .. emerg);     };
filter f_warning { level (warning .. emerg); };
filter f_notice  { level (notice .. emerg);  };
filter f_info    { level (info .. emerg);    };
filter f_debug   { level (debug .. emerg);   };

# Facility Filters
filter f_kern   { facility (kern);   };
filter f_user   { facility (user);   };
filter f_mail   { facility (mail);   };
filter f_daemon { facility (daemon); };
filter f_auth   { facility (auth);   };
filter f_syslog { facility (syslog); };
filter f_lpr    { facility (lpr);    };
filter f_news   { facility (news);   };
filter f_uucp   { facility (uucp);   };
filter f_cron   { facility (cron);   };
filter f_local0 { facility (local0); };
filter f_local1 { facility (local1); };
filter f_local2 { facility (local2); };
filter f_local3 { facility (local3); };
filter f_local4 { facility (local4); };
filter f_local5 { facility (local5); };
filter f_local6 { facility (local6); };
filter f_local7 { facility (local7); }; 

# Custom Filters
filter f_user_none     { not facility (user);                     };
filter f_kern_debug    { filter (f_kern) and filter (f_debug);    };
filter f_daemon_notice { filter (f_daemon) and filter (f_notice); };
filter f_mail_crit     { filter (f_mail) and filter (f_crit);     };
filter f_mesg          { filter (f_kern_debug) or 
                         filter (f_daemon_notice) or 
                         filter (f_mail_crit);                    };
filter f_authinfo      { filter (f_auth) or program (sudo);       };

# Log statements
# Log things locally
log { source (s_local); filter (f_authinfo); destination (l_authlog);  };
log { source (s_local); filter (f_mail);     destination (l_maillog);  };
log { source (s_local); filter (f_local0);   destination (l_ipflog);   };
log { source (s_local); filter (f_local1);   destination (l_imaplog);  };
log { source (s_local); filter (f_syslog);   destination (l_syslog);   };
log { source (s_local); filter (f_emerg); filter (f_user_none); 
                                             destination (l_console);  };
log { source (s_local); filter (f_mesg); filter (f_user_none);
                                             destination (l_messages); }; 

# Log everything remotely via stunnel
log { source (s_local);                      destination (stunnel);    };

syslog-ng のもっとも高度な使用法として、ログメッセージをその重要性に基づいて、直接データマイニングソフトウェア、データベース、電子メール、またはプリンタに送信できます。また、便利なもう 1 つのヒントとして、swatch、logsurfer、Log Tool、または Logwatch などのリアルタイムログアナライザで監視できる 1 つのファイルに、優先順位の高いログメッセージを送信できます。データマイニングおよび監視の自動化が持つ可能性は、広大です。ログエントリをさまざまな方法で編成および処理できるからです。