【連載】
止められないUNIXサーバのセキュリティ対策
第9回 安全性の高いログ・サーバへの乗り換えのススメ（1）
〜 syslogサーバからsyslog-ngへの乗り換え 〜

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

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

　前回は、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などの外部プログラムを使う必要がある。

    ＊1
    【参考記事】サーバのログ監視ツールを使いこなそう - swatchによるログの常時監視（Linux Square）

  • ログ受信時のアクセス制御

    ログ受信時の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 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>）の対応付けを行う。

logの記述形式
log { source(s1); source(s2); ……
      filter(f1); filter(f2); ……
      destination(d1); destination(d2); ……
      flags(flag1[, flag2……]); };

　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の実際の切り替えに関して説明する。

「第8回」へ

「第10回」へ

index
第1回 不要なサービスの停止こそ管理の第一歩
第2回 ソフトウェアの現状確認とアップグレード
第3回 サービスをセキュアにするための利用制限（1）
第4回 サービスをセキュアにするための利用制限（2）
第5回 サービスをセキュアにするための利用制限（3）
第6回 特権ユーザーの安全性向上を行うsudoの設定例
第7回 UNIXサーバの運用管理で欠かせないログ管理
第8回 syslogによるログの一元管理
第9回 安全性の高いログ・サーバへの乗り換えのススメ（1）       
　　　　syslogdからsyslog-ngへ
　　　　syslog-ngの導入
　　　　syslog-ngの設定

関連記事
連載：Webアプリケーションに潜むセキュリティホール
特集：クロスサイトスクリプティング対策の基本
連載：インシデントレスポンスはじめの一歩〜rootkitを検出するために

Security&Trust記事一覧

TechTargetジャパン

Security&Trust フォーラム 新着記事

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

RSSフィード

＠IT 新着記事

キャリアアップ

- PR -
＠IT Sepcial
→ ＠IT Special ヘ

イベントカレンダー

PickUpイベント

- PR -
もっと見る
- PR -

お勧め求人情報

ホワイトペーパー（TechTargetジャパン）

＠IT Sepcial
→ ＠IT Special ヘ
ソリューションFLASH