Serverのログ管理

1.ログの設定

1-1.はじめに

  Serverの管理者にとって、Serverの正常性の確認とトラブルシューティングは設定変更と同じか、それ以上に重要な作業になります。この日常の正常性の確認と随時のトラブルシューティングを行う際に役立つのが、各アプリケーションやOSの出力するログになります。
  一般的に常にログを監視するという業務はありえないでしょう。何も起こらなければ退屈以外の何者でもなく、ログを監視していても異常かどうかは即座に判断できないことが多いかと思います。ログを確認するタイミングとしてはシステムに何かが起こった場合、或いはこれから何か起こる可能性が考えられる場合があげられます。（それ以外はログを見ないという管理者もいるかと思います。）何かが起こった場合とは、システムの監視装置がサーバの異常を知らせてくれる場合や、システムの利用者から何かしらが利用できないと連絡を受けた場合であり、ログを見る為のトリガーがはっきりしています。これに対して、何か起こる可能性が考えられる場合とは、数年前で言うと2000年問題に関係し、大晦日から元旦に日が変わる瞬間や、また平時であってもサーバに負荷のかかる作業を行わせる場合に、ログに異常が表示されないか眺めている管理者の方もいるかと思います。
ただし、サーバとは常時稼動を必要としているコンピュータであり、できることであればサービスやハードが止まる前に前兆となるログの出力を確認し、事前に対処することができればベストであるに違いありません。
  では、常に眺めていることのできないログから必要な情報を取得する為にはどのようにしたら良いのでしょうか？本当に必要な情報が簡単に取り出せるようにすることが一つの回答になるかと思います。

必要な情報と不必要な情報

  サーバのログを確認すれば、不正アクセスの監視、サーバの状態監視、サービスの動作監視などを行うことができます。ただしデフォルト設定のままでは必要な情報と特に必要でない情報が同じファイルの中に存在しています。（必要な情報とは、使用しているサービスやサーバの論理的な配置、あるいはログを必要とする人によって異なります。）最低限必要な情報について少し考えてみましょう。

不正アクセスの監視

  不正アクセスが行われているかどうかを知るためには、何が正常な状態と異なるのか、どのような情報が表示されたときにどのような攻撃あるいは攻撃のための準備作業が行われているのかを知っておく必要があります。正常な状態を知るには、日ごろからログを確認し、どんなメッセージが表示されているかを知っておけば、普段見たことのない情報が表示されていれば何かが起こっていると認識することができます。実際におかしな情報が表示されていることを確認できた場合には、それがどういった種類の情報なのかを考えなければなりません。このようなセキュリティに関連する情報は/var/log/messagesと/var/log/secure で確認ができます。
  ログの記述内容は大きく分けて次のようになっています。

(1)下記は”yamada”ユーザでログインしようとしたが、認証に失敗したと表示されています。認証に失敗することはユーザ側の操作ミスなどで十分考えられることですが、同じユーザで同じ失敗が重なる場合には注意する必要があります。 Jul 27 10:51:22 itbsv1 login[8276]: FAILED LOGIN SESSION FROM (null) FOR   yamada,Authentication failure   (2)下記は”root”ユーザでssh接続を行い、パスワードの認証に失敗した場合の表示です。 Jul 27 11:21:35 itbsv1 sshd[8306]: Failed password for ROOT from 192.168.0.11   port 1027 ssh2   81)と(2)を比較していただくと、大文字小文字の違いはありますが”failed”の単語が両方に表示されています。ログファイルから”failed”の単語を含む行を抜き出せば何かに失敗したメッセージだけを確認することができます。”grep ”に”i”オプションを指定することで、大文字小文字の区別なく抜き出すことができます。 # grep -i failed /var/log/messages   “failed”以外にもrejectやerr、bad、プログラムによってはattackなどの文字でも必要な行が抜き出せます。 特定のサービスに対する攻撃の場合には同じ或いはほぼ同じメッセージが表示されます。 以下はxntpdに対してのDOS攻撃の場合の表示になります。   Jul 27 13:41:01 itbsv1 xntpd[8496]: [ID 866926 daemon.notice] xntpd exiting on    signal 10   Jul 27 13:41:01 itbsv1 xntpd[8496]: [ID 866926 daemon.notice] xntpd exiting on   signal 10 Jul 27 13:41:01 itbsv1 xntpd[8496]: [ID 866926 daemon.notice] xntpd exiting on   signal 10 Jul 27 13:41:01 itbsv1 xntpd[8496]: [ID 866926 daemon.notice] xntpd exiting on   signal 10 Jul 27 13:41:01 itbsv1 xntpd[8496]: [ID 866926 daemon.notice] xntpd exiting on   signal 10   このような明らかにおかしいメッセージが表示されている場合は使用しているサービスのバージョンを調べてセキュリティに問題がないか確認をして、必要であればバージョンアップを行う等の作業を行ってください。 ▼Java や Linux を体系的に学びましょう！▼ Stack*のラクスが、 新学習方式のカリキュラムを開発しました！ 14700円から(*1)、Java や Linux を体系的に学べます！！ (*1 テキスト代のみの税込料金です)   デフォルトでは/var/logディレクトリに様々なログファイルがあります。以下の表から代表的な情報がどのファイルに出力されるのかを確認し、何に関する情報が必要であるかに応じて、特定の単語を抜き出すファイルを指定してください。

  最低限のログを確認する方法がわかったかと思います。ここからはログの設定を変更することでより見やすい状態にする為の方法を説明します。

1−2.SYSLOGD

syslog.confのフォーマット

 defaults
 {
    instances               = 60
    log_type                = SYSLOG authpriv
    log_og_success          = HOST PID
    loc_on_failure          = HOST
    cps                     = 25 30
 }

 includedir /etc/xinetd.d

 service telnet
 {
 	disable		    = no
 	flags		    = REUSE
 	socket_type	    = stream
 	wait		    = no
 	user		    = root
 	server		    = /usr/sbin/in.telnetd
 	log_on_failure	+= USERID
 	log_type		= SYSLOG local0		←追加
 }

・priority
  次にpriorityですが、プログラムが出力するメッセージのうち、必要な重要性のあるログのレベルを設定します。

  通常の設定を行うと、指定したpriority以上のログが出力されます。例えば、errを指定すればcrit、alert、emergのレベルの出力もされます。すなわち重要度の低いpriorityを選択すればするほど出力されるメッセージは多くなります。逆に指定したpriorityの重要度の低いメッセージのみを出力させたい場合には、”mail.*;mail.!warn”のように記述することも可能です。この設定ではメールに関するメッセージのdebugとinfoとnoticeが出力されます。（ここでの”*”は全てのメッセージの意味）
また特定のpriorityのみを指定することも可能です。それには”＝”を使用します。”kernel.=warn”のように記述すると、カーネルの警告メッセージだけが出力されます。これに”!”をあわせることで、特定のpriorityを除くメッセージを出力することも可能です。
これらのpriorityの指定以外に、noneを利用するとそのfacirityを出力しないことも可能です。noneは”*”を利用して全てのfacilityを指定し、あるfacirityにnone指定して続けて記述することで意味をなします。

  どのfacilityをどのpriorityにするかは何を監視したいかによりますが、重要なデータを見逃さないように必要なデータが取得できるpriorityに変更してください。

・action
  actionにはselectorで指定したメッセージをどこに、あるいはどのように出力するかを設定します。具体的には(1)ファイルのパスを記述してどのファイルに出力する、(2)”|”を利用して他のプログラムに渡す、(3)@ホスト名で他のホストに渡す、(4)システムに登録されているユーザ名でそのユーザのコンソールに表示させるになります。また出力先のファイルを/dev/consoleを指定することでコンソールに表示させることも可能です。actionの設定例は以下です。

  以上の内容よりデフォルトのsyslog.conf（※）を見てみましょう。

1…authprivとcronを除いた全てのfacilityでinfo以上のメッセージを/var/log/messagesに出力する。
2…authprivのfacilityは全てのメッセージを/var/log/secureに出力する。
3…mailのfacilityは全てのメッセージを/var/log/maillogに出力する。
4…cronのfacilityは全てのメッセージを/var/log/cronに出力する。
5…全てのfacilityでemergのメッセージをオンラインユーザのコンソールへ出力する。
6…uucpとnewsのfacilityでcrit以上のメッセージを/var/log/spoolerへ出力する。
7…local7のfacilityの全てのメッセージを/var/log/boot.logへ出力する。

1-3.syslog server

  以前ログを数ヶ月から数年間保存することを法制化しようという動きがありました。これは不正アクセスの情報を残すためでしたが、まだ実際の法律としては存在していません。しかし、ログを残すことはネットワーク管理者の重要な作業の一つであることは間違いありません。不正アクセスを行う者にとって、ログには自分を特定する情報が記述されているため、削除されることもあります。これに対処するために、異なるホストをsyslog serverとして運用する方法があります。既に述べたようにsyslog.confの設定でactionに@ホスト名（或いはＩＰアドレス）を入力すると、そのホストにログを転送することができます。ただし、ログを受け取るホスト側でも設定が必要です。syslog serverとしてホストを設定するには、syslogdに-rオプションを指定して起動します。  syslogdを停止してから”/sbin/syslogd -r”で実行してください。RedHat系であれば/etc/sysconfig/syslogにSYSLOGD_OPTIONS=”-m 0 -r”のように追記をしてsyslogdを再起動すればsyslog serverとして使用することができます。  syslog serverへ転送されたログは、syslog serverのsyslog.confの内容に従い処理されます。ここで注意すべき点は、syslog serverのユーザとパスワードを他のサーバと同じにしないこと、複数のサーバからログの転送を行うのであれば、容量的に十分余裕を持たせておくことが必要です。

  以上でsyslogdの主な機能については網羅できているはずです。複数のサーバから自分に必要な情報を洗い出す作業を少しでも減らそうと思えば、syslog serverを１台構築し、例えばpriorityがwarn以上のものを一つのファイルに出力するように設定することも可能です。

1-4.logrotate

  syslogdの設定で必要なログの設定を行いましたが、そのまま特定のログファイルに永遠にログが書き込まれていくことはありません。なぜならログファイルのデータ量があまりにも大きくなれば、ディスク容量を圧迫しますしログを確認しようとしたときに時間やCPUへの負担が大きくなるからです。これを回避するためにlogrotateというプログラムがあります。logrotateは設定されたタイミングでログファイルのバックアップを行い、新しいログファイルを作成するログのローテーションを行ってくれます。

logrotateは/etc/logrotate.confと/etc/logrotate.dディレクトリにある各設定ファイルによって行われます。

・logrotate.conf
  logrotate.confの内容は以下です。

1. 毎週ファイルの置き換えを行う。（monthly、weekly、daily）


2. ４世代分ファイルを保存する。


3. ファイルの置き換えを行った後、新しいログファイルを作成する。


4. 圧縮する。（デフォルトでは圧縮しません）


5. 各ログの詳細設定ファイルは/etc/logrotate.dにある。


6. wtmpファイルはlastコマンドで誰がloginしたかを調べることができます。wtmpログファイルは、毎月一世代のみファイルを置き換え、新しいファイルを0664のパーミッションで、所有者をroot、所有グループをutmpで作成を行う。

  logrotate.confファイルはlogrotateのグローバルな設定を行います。例えば1日のログのデータ量が非常に多い場合には、weeklyではなくdailyに変更をすることで、一つのファイルのサイズを減らすことができます。その場合には”rotate 4”では4日分しかログが残らないため、必要に応じて数字を大きくするなどの設定変更が必要です。

・/etc/logrotated.d
  各ログファイルの設定は/etc/logrotated.dディレクトリの設定ファイルで行います。syslogdで設定されたログの設定ファイルは/etc/logrotated.d/syslogになります。

 /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler
　　/var/log/boot.log /var/log/cron {　　…1
　　sharedscripts　　　　　　　　　　　　…2
　　postrotate　　　　　　　　　　　　　 …3
　　/bin/kill -HUP ‘cat /var/run/syslogd.pid 2> /dev/null ‘ 2> \
　/dev/null || true　　　　　　　　　　　…4
　　endscript　　　　　　　　　　　　　　…5
 }

（※）RedHat Linux9のデフォルト設定です。

1. 最初の行にどのログファイルに関する設定かの記述です。


2. sharedscriptsは複数のログファイルのローテーション後に下の作業を1度のみ実行します。


3. postrotateとendscriptの間のコマンドをローテーション終了後に実行します。


4. syslogdの動作中にファイルを移動すると、syslogdは出力すべきログファイルを見失ってしまうため、ここではsyslogdにHUPシグナルを送って、設定を再読込させています。


5. コマンドの終了を表しています。

グローバルの設定では毎週ローテーションですが、syslogdのログファイルのみ毎日に変更したければ、この中括弧のpostrotateより上にdailyと記述します。他にはmissingokと記述すると対象のファイルが存在しなくてもエラーを出さない設定や、size 10Mと記述するとファイルサイズが10Mを超えるとローテーションを行う等の設定も可能です。指定可能なオプションが多いため、詳細はman logrotateで確認してください。
  logrotateはデーモンではなく、ここで設定した内容はcronによってroglotateが起動されたときに読み込まれますcronは/etc/crontabの内容に従い、/etc/cron.dailyディレクトリのsyslogが実行されます。syslogファイルはlogrotateを起動するスクリプトになっており、設定ファイルに従い処理が実行されます。

NTP

  ログファイルに出力される内容から日時とサーバ、情報を知ることができます。自分が管理しているサーバで何か問題が発生した場合には、特定の端末からサーバへのアクセスログや、特定の時間の全てのログをチェックする必要が出てきます。
このようなときにもっとも重要になる点としては、サーバの時間設定が正しく行われていることがあります。もちろんずれた時間を計算しながらログのチェックを行うことも可能ですが、手間を考えると正確な時間でログが表示されているべきですし、また他のソフトなどでシステムより時間を取得しているものもあります。
  コンピュータの時間は定期的にあわせなければ、もっとも信用のできないものになります。
  正確な時間をシステムに設定する為にntpがあります。ntpはインターネット上に存在するnptサーバより正確な時刻を取得し、ntpクライアントの時刻を正しく設定し保持することができます。
  ここでは詳細は省きます。http://www.eecis.udel.edu/~ntp/や
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/249usexntpd.html等を参考にしてください。

▼Java や Linux を体系的に学びましょう！▼ Stack*のラクスが、 新学習方式のカリキュラムを開発しました！ 14700円から(*1)、Java や Linux を体系的に学べます！！ (*1 テキスト代のみの税込料金です)

>>次のページへ