本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。
前回は、syslogによるログ転送の説明をした。今回は、安全性がより考慮されたsyslogサーバのsyslog-ng（syslog-next generation）への乗り換えについて2回に分けて述べる。では、syslogサーバのセキュリティ上の課題やsyslog-ngの主な機能を紹介しよう。
syslogdからsyslog-ngへ
前回までに説明したオリジナルのsyslogサーバ（syslogd）には、きめ細かなログの制御・監査が行えない、あるいはセキュリティがあまり考慮されていないなどの課題が残されている。
もちろん、それでも十分にログの運用管理は行えるが、本稿ではさらに踏み込んで、それらの課題をクリアするために、より高機能かつセキュアなsyslog-ngの導入を検討することにした。
syslogdの課題
syslogdの機能面やセキュリティ面から見た課題を、以下にいくつか挙げてみる。
●ログの出力先を細かく制御できない
各アプリケーションは、あらかじめ用意されたfacilityのいずれかを使用してログを出力するため、アプリケーションごとにログの出力先を変更することが困難。
●ログ監査の自動化が困難
ログに特定のメッセージが出力された場合、管理者にメールで通知するなどのアクションを自動的に行えない。行いたい場合は、swatch（Simple Watcher）＊1などの外部プログラムを使う必要がある。
●ログ受信時のアクセス制御
ログ受信時の514/udpに対するアクセス制御が行えない。行えたとしても、一部OSのsyslogd（FreeBSD、NetBSDなど）に限られる。
●root権限で動作する
syslogdは、root権限で動作する。そのため、万が一syslogd経由による侵入を許した場合、即root権限の取得につながる。
syslog-ngの導入
syslog-ngは、GPL（General Public License）に基づいたフリーのsyslogソフトウェアで、オリジナルのsyslogdの機能はもちろんのこと、さまざまな機能のサポートやセキュリティ面が考慮された作りになっている。このsyslog-ngを導入することで、前述のsyslogdの課題をクリアすることができる。では、syslog-ngの主な機能を紹介しよう。
●syslogdの機能
従来のsyslogdで提供されている機能は、syslog-ngでも同様に利用できる。
●ログの出力先を細かに制御できる
syslog-ngのfilter機能により、facilityやpriorityはもちろんのこと、アプリケーション名や受信したログの内容に応じて、ログの出力先を指定できる。
●ログ監査の自動化が行える
facility、priority、ホスト名、アプリケーション名などに合致したログをメールプログラムに渡すことで、管理者に自動通知することができる。
●ログ受信時のアクセス制御
ほかのsyslogサーバからログを受信する際に、アクセス制御を行える。また、TCP Wrapper＊2との連係によるアクセス制御も行える。
＊2【参考記事】▼第3回 サービスをセキュアにするための利用制限
●root以外のユーザー権限で動作可能
syslog-ngでは、実効ユーザー権限をroot以外にすることが可能だ。これにより、万が一侵入された場合でもroot権限を直接取得されることはない＊3。
＊3
攻撃者に一般ユーザー権限で侵入され、内部からの攻撃によりroot権限を取得されると意味がなくなるが、それでもシステムを乗っ取られるまでの時間を少しでも稼ぐことができる。
●TCPポートによるログ転送
従来のsyslogdは、ログ転送のために514/udpポート（固定）を使用していた。syslog-ngでは、TCPポートかつ任意のポートを使用してログ転送可能だ。TCPによるログ転送では、最大接続数の制限も行えるため、Flood系のDoS攻撃への対処が可能となる。
syslog-ngの導入前の注意点
syslogdからsyslog-ngに切り替える場合、一時的とはいえsyslogによるログの出力が停止してしまう＊4。そのため、本連載タイトルの「止められないUNIXサーバ」に少し反してしまうが、本稿では停止時間を極力短く（理想は数秒）、かつ安全に切り替えることに配慮しながら説明するつもりだ。
＊4
syslogdとsyslog-ngを並行稼働した場合、どちらかが出力されるログを占有してしまうので、切り替える場合は、やはりsyslogdの停止、syslog-ngの起動の手順を踏む必要がある。
停止時間を短く、かつ安全に移行するためには、以下をクリアにしておけばよい。
（1）切り替える時間帯は、ログの出力が少ない時間帯を選ぶ
（2）動作検証を十分に行う。できればテスト環境下にて、本番と同じ環境を作って検証する
syslog-ngの導入
syslog-ngと関連ライブラリの入手
syslog-ngのソースコード（またはパッケージ）を下記サイトより入手する。また、syslog-ngを使用するには、libolライブラリが必須となるので、それも併せて入手しておく。
- syslog-ng（http://www.balabit.com/products/syslog_ng/）
- libol（http://www.balabit.com/downloads/libol/0.3/）
本稿では、安定版のsyslog-ng 1.6.2およびlibol 0.3.13＊5を使用した。
＊5
syslog-ng 1.6.2を使う場合、libolは0.3.13以上のバージョンである必要がある。
syslog-ngのインストール
入手したsyslog-ngをインストールする。syslog-ngは、syslogdとファイル名がぶつかることはないので、syslogdが稼働中の状態でインストールしても構わない。
●パッケージシステムを利用する場合
syslog-ngがパッケージシステムとして提供されている場合は、極力それを利用する。例えば、FreeBSD portsでは、sysutils/syslog-ngとして提供されている。
●ソースコードを利用する場合
syslog-ngのパッケージが提供されていない場合は、syslog-ngのソースコードをコンパイルしてインストールする。手順を次に示す。
（1）libolのコンパイル
syslog-ngのコンパイルの前に、libolをコンパイルしておく。syslog-ngでlibolを静的に取り込むのであれば、libolは必ずしもシステム上にインストールされている必要はない（動的に取り込む場合はインストールが必要）。ここでは、syslog-ngのソースコードと同じディレクトリ上に展開し、コンパイルした。
% cd /usr/local/src
% gunzip -cd libol-0.3.13.tar.gz | tar xvf -
% cd libol-0.3.13
% ./configure
% make
（2）syslog-ngのコンパイル
% cd /usr/local/src
% gunzip -cd syslog-ng-1.6.2.tar.gz | tar xvf -
% cd syslog-ng-1.6.2
% ./configure --with-libol=/usr/local/src/libol-0.3.13
% make
--with-libolは、libolが事前にインストールされていれば指定する必要はない。また、TCP Wrapperと連係する場合は、./configureに--enable-tcp-wrapperオプションを指定する必要がある。
（3）syslog-ngのインストール
# make install
デフォルトインストールの場合、以下の場所にファイルがインストールされる。
/usr/local/sbin/syslog-ng
/usr/local/man/man5/syslog-ng.conf.5
/usr/local/man/man8/syslog-ng.8
syslog-ngの設定
syslog-ngの基本設定を行う。デフォルトは、/usr/local/etc/syslog-ng/syslog-ng.confファイルに設定を記述する（格納場所は変更可能）。
syslog-ng.confの記述形式
syslog-ng.confに記述する内容を説明する。ここでは、必須となる項目を中心に説明していく。
syslog-ngの設定は、次の5つの項目が基本となる。
- （1）source（ログの受信に関する設定）
- （2）filter（出力するログのフィルタリング）
- （3）destination（ログの送信に関する設定）
- （4）log（source、destination、filterの対応付け）
- （5）options（オプション）
このうち必須となるのが、source、filter、destination、logの項目で、必要に応じoptionsを指定する。
なお、syslog-ng.confに関する詳細は、HTMLドキュメント＊6を参照するか、ソースコードに付属の設定サンプル（contribディレクトリ下）を参考にするとよい。
＊6
ソースコード展開先のdocディレクトリ下にあるが、最新版は、syslog-ngのWebサイトにて参照可能。http://www.balabit.com/products/syslog_ng/reference/book1.html
（1）source（ログ受信に関する設定）
sourceでは、どこからログを受信するかについて設定を行う。記述形式は、次のとおりとなる。
| sourceの記述形式 |
|---|
| source <identifier> { source-driver(params); source-driver(params); …… }; |
<identifier>には、syslog-ng内で一意となる名前を定義する。source-driverには、表1に示す内容を記述する。
| 名前 | 説明 |
|---|---|
| internal | syslog-ng内部で生成されるメッセージを出力 |
| unix-stream | SOCK_STREAMモードで指定したUNIXソケットを開き、ログメッセージを受信（Linux場合） |
| unix-dgram | SOCK_DGRAM モードで指定したUNIXソケットを開き、ログメッセージを受信（BSD系UNIXの場合） |
| file | 指定されたファイルを開き、メッセージを読む |
| pipe、fifo | 指定した名前パイプをオープンして、ログメッセージを読む |
| udp | UDPポートを待機しログメッセージを受信 |
| tcp | TCPポートを待機しログメッセージを受信 |
| sun-stream、sun-streams | 指定したSTREAMSデバイスを開き、ログメッセージsun-streamsを受信（Solarisなど） |
| 表1 source-driverで行える設定 | |
sourceの設定例を次に示す。OSによって、ログの受け渡しを行うUNIXドメインソケットが異なることに注意する。
・Red Hat Linuxの場合
source src { pipe ("/proc/kmsg" log_prefix("kernel: "));
unix-stream("/dev/log"); internal(); };
Red Hat Linuxでは、/proc/kmsgよりカーネルメッセージを取得する。また、log_prefixにより、メッセージの先頭に"kernel: "を追加して、従来のsyslogdと同じ出力形式にする。
・FreeBSD、NetBSDの場合
source src { unix-dgram("/var/run/log"); internal(); };
・Solarisの場合
source src { sun-streams("/dev/log" door("/etc/.syslog_door")); internal(); };
（2）filter（出力するログのフィルタリング）
filterでは、出力するログメッセージのフィルタが行われる。filterで合致したログメッセージに対して、後述のdestinationでログの出力先を決定させることができる。
| filterの記述形式 |
|---|
| filter <identifier> { expression; }; |
<identifier>には、syslog-ng内で一意となる名前を定義する。expressionには、表2に示す内容とand、or、notの論理式を組み合わせて記述する。
| 名前 | 説明 |
|---|---|
| facility | 指定したfacilityに合致するログメッセージが対象となる。facility（faciliy[,facility]）の形式で指定する。 |
| level | 指定したpriorityに合致するログメッセージが対象となる。priority（）level（pri[,pri1..pri2[,pri3]]）の形式で指定する。 |
| program | 指定したプログラム名（正規表現による指定可）に合致するログメッセージが対象となる。program（プログラム名）の形式で指定する。 |
| host | 指定したホスト名（正規表現可）に合致するログメッセージが対象となる。host（ホスト名）の形式で指定する。 |
| match | 指定した正規表現そのものに合致するログメッセージが対象となる。 |
| filter | 別のfilterルールを呼び出す。 |
| 表2 filterで行える設定 | |
filterの設定例を次に示す。
例1：facilityがauthとauthprivのログを対象にする場合
filter f_authpriv { facility(auth,authpriv); };
例2：priorityがinfoからemergまでのログを対象にする場合
filter f_info { level(info..emerg); };
例3：ホスト名server1に合致するログを対象にする場合
filter f_server1 { host("server1"); };
例4：組み合わせ例（例1かつ例2のログを対象にする場合）
filter f_authlog { facility(auth,authpriv) and level(info..emerg); };
（3）destination（ログの送信に関する設定）
destinationでは、前述のfilterルールにマッチしたログの出力先（送信先）を定義する。
| destinationの記述形式 |
|---|
| destination <identifier> { destination-driver(params); destination-driver(params); …… }; |
<identifier>には、syslog-ng内で一意となる名前を定義する。destination-driverには、表3に示す内容を記述する。
| 名前 | 説明 |
|---|---|
| file | 指定したファイルにログを出力 |
| fifo、pipe | 指定したFIFOやパイプにログを出力 |
| unix-stream | UNIXドメインソケットのSOCK_STREAM形式でメッセージを送信（Linux syslog） |
| unix-dgram | UNIXドメインソケットのSOCK_DGRAM形式でメッセージを送信（BSD syslog） |
| host | udp指定したホストとUDPポートにログを送信 |
| usertty | ログイン中のユーザーにログを出力 |
| program | 外部プログラムにログを出力 |
| 表3 destinationで行える設定 | |
destinationの例を次に示す。なお、出力されるログは、前述のfilterで定義した内容が対象となる。
・/var/log/maillog ファイルにログを出力
destination d_maillog { file("/var/log/maillog"); };
・システムにログイン中のユーザーrootにログを出力
destination d_usertty { usertty("root"); };
（4）log（source、destination、filterの対応付け）
logでは、前述のsource、destination、filterで定義した各ルール名（<identifier>）の対応付けを行う。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
source、filter、destinationには、前述の各項目で定義したルールを記述する。flagsには、表4に示す内容を記述する（省略可能）。
| フラグ名 | 説明 |
|---|---|
| final | log文の終わりの場合に指定する。必ずしも必要ではない。 |
| fallback | フォールバック形式でログを生成する。 |
| catchall | sourceを無視して、filterに合致するメッセージのみを対象とする。 |
| 表4 logのflagsパラメータ | |
logの例を次に示す。
- sourceがsrc、filterがf_maillogの内容に合致するログを、destination d_maillogに出力する
log { source(src); filter(f_maillog); destination(d_maillog); };
（5）options（オプション）
optionsでは、syslog-ngに関する初期設定値などの変更を行う。必要に応じてオプションの値を変更する。
| optionsの記述形式 |
|---|
| options { option1(params); option2(params); …… }; |
指定可能なオプションは、たくさんあるので付属のドキュメントを参照してほしい。optionsの例を次に示す。
- ログ出力の際にバッファリングしない（sync（0））。また、syslog-ngの状態監視の報告は、1日間隔（86400秒）で行うようにする（stats（86400））
options{
sync(0);
stats(86400);
};
今回は、高機能かつセキュアなログ・サーバのsyslog-ngの導入前のsyslogサーバのセキュリティ上の課題やsyslog-ngの主な機能などの説明を行った。引き続き次回も、syslog-ngの実際の切り替えに関して説明する。
- Tripwireのポリシーを最適化する
- Tripwireでファイルの改ざんを検出せよ〜Tripwireのインストールと初期設定 〜
- 安全性の高いログ・サーバへの乗り換えのススメ（2）〜 ログ管理のセキュリティ強化を実現する方法を知ろう 〜
- 安全性の高いログ・サーバへの乗り換えのススメ（1）〜 syslogサーバからsyslog-ngへの乗り換え 〜
- syslogによるログの一元管理
- UNIXサーバの運用管理で欠かせないログ管理
- 特権ユーザーの安全性向上を行うsudoの設定例
- サービスをセキュアにするための利用制限（3）〜管理者権限の制限のためのsuとsudoの基本〜
- サービスをセキュアにするための利用制限（2）〜管理者特権の利用制限〜
- サービスをセキュアにするための利用制限〜TCP Wrapperによるサービスのアクセス制限〜
- ソフトウェアの現状確認とアップグレード
- 不要なサービスの停止こそ管理の第一歩
Copyright © ITmedia, Inc. All Rights Reserved.