| LANDISK HACKING DIARY | ||
|
||
| Since2005/8/17 | ||
|
||
| TOPへ戻る | ||
|
|
|
|
||||||||||||||||||||||||||||
| INDEX | ||||||||||||||||||||||||||||||
1. syslog のカスタマイズ 2. ルータのSyslog をLinux で受け取る 3. LANDISK でログの一元管理 4. 参考文献 |
||||||||||||||||||||||||||||||
| syslog のカスタマイズ | ||||||||||||||||||||||||||||||
|
|
いやいや、いままでRed Hat （or Fedora）しか使ってこなかったもんだから、syslog ってのはついつい、/var/log/message を見るもんだと思い込んでしまっているところがある。でも、debian を使うようになってから、ssh でログインした形跡もログられていないし（実際は、/var/log/auth.log に記録されている）、サーバーを再起動してもログに記録されない。/var/log/syslog にはそれなりに記録されているが、/var/log/message なんてほとんど何も記録されない。見慣れた表示のされ方ではないのでどうも使いづらいのだ。そこで、このログ表示をFedora っぽくしてみることにする。Fedora と debian とで使っているsyslog はほぼ同じような感じだったので、異なっているのは、/etc/syslog.conf の違いだけであろう（…推測）。つまり、この設定ファイルを完コピしてしまえばいいだけである。以下は、Fedora と debian のデフォルトで記述されていた/etc/syslog.conf の内容である。コメント部分は省いてある。 Fedora Core3 のデフォルトの/etc/syslog.conf
debian のデフォルトの/etc/syslog.conf
syslog.conf の書き方として、「Facility.Priority [1個以上のTAB] ログ保存場所」のような形式になっている（簡単に言えばね）。まず、Facility について簡単に一覧にしてみた。詳しくは、man ページを見て各自で確認して欲しい。
Priority 、つまりログの重要度は左から右にいくにつれて重要度が増していく。なお、今後利用しないほうがいいPriority は以下に含めていない。下記のPriority は、仮に info の場合は、info も含めた notice 以降のメッセージが全て記録されるようになる。crit と記述した場合は、crit以降のalert と emerg が記録され、crit 以下の error や warning は記録されないようになる。none はメッセージを送信しないという意味になる。emerg は、すべてのユーザーに一斉通知される。 debug --> info --> notice --> warning --> err --> crit --> alert --> emerg 上記の/etc/syslog.conf を例としてまとめてみる。 例1）authpriv.* /var/log/secure authpriv に関するログを全て、/var/log/secure に保存する 例2）uucp,news.crit /var/log/spooler uucp と news の crit 以上 のログを /var/log/spooler に保存する 例3) kern.* /dev/console カーネルメッセージをコンソールに表示する 例4) *.info;mail.none;authpriv.none;cron.none /var/log/messages 全てのFacility に関する info 以上のメッセージを/var/log/messages に記録するが、 mail と authpriv と cron に関するメッセージは、ここには記録しない。 例5）*.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages 全てのFacility に関する info と notice と warn のメッセージを /var/log/messages に記録するが、 auth と authpriv と cron と daemon と mail と new に関するログはここには記録しない。 例6） *.emerg * 緊急事態のすべてのログ（*.emerg）は、ログイン中のすべてのユーザーに一斉通知する。 例7） *.alert root alert 以上の全てのメッセージを root に通知する。 ■結論 結論から言えば、ログをファシリティごとに別々のファイルに分散させることは整理の面で役に立つであろうが、自宅サーバーの運用では、できるだけひとつのログファイルに集中させた方がきっと楽に違いない。少なくとも筆者はそう思う。毎日、膨大な量のログが記録されるような環境ならば、ファシリティごとにログファイルを分散させるべきだが、1日で数十行しか記録されないような環境であれば、ほぼ全てのメッセージを /var/log/messages に記録させたほうが断然効率が良い。その上で重要なファシリティのメッセージだけは専用のログに分けて保存しておき、後でまとめて閲覧できるようにしておく。ということで、Fedora のsyslog.conf に習って、LANDISK環境の syslog.conf を以下のように変えてみた。微妙に無駄も多い気がするが。
|
|||||||||||||||||||||||||||||
| ルータのSyslog をLinux で受け取る | ||||||||||||||||||||||||||||||
「ルータのsyslogをLinuxで受け取るには」という記事が @it に紹介されていたので、メモとしてここにも記述しておく。偶然にも、筆者もNetGenesis を使っている。まず、ルータの設定画面で、「ホストIPアドレス」にLANDISK のIPアドレスを入力し、変更を反映させるためルータを再起動する。NetGenesis 側はこれだけでOKだ。 次にLANDISK側の syslog の設定を行う。まず、/etc/syslog.conf に以下のように記述しておく。
/etc/init.d/sysklogd を開き、SYSLOGD オプションに -r をつけて起動するようにする。-r オプションは、リモートホストのログを保存するという意味だ。Fedora Core を使っている場合は、/etc/sysconfig/syslog にも同じ行があるので同様に編集しておく。
ここまで終えたら、sysklogd を再起動する。/var/log/user.log を見てルータからログが転送されてきていれば成功だ。注意したいのは、この時点で 514/udp がオープンになるということだ。WAN側からログを受け取らない場合は、ルータやファイアーウォールできっちりブロックしておく必要がある。514/udpでは、特にアクセス制限が行われていないため、514/udpに対してDoS攻撃が可能となってしまうからだ。
|
||||||||||||||||||||||||||||||
| LANDISK でログの一元管理 | ||||||||||||||||||||||||||||||
■ログサーバ（LANDISK）の準備 せっかくなので、LANDISKにログサーバーとしてログの一元管理を行ってもらうことにする。まず、ログを受け取れる状態にあるかどうかを先に確認しておく。514/udpがオープンになっていれば待機状態になっていることが確認できる。
■転送元サーバの設定 /etc/hosts にLANDISKのIPアドレスとホスト名を記述しておく。DNSによる名前解決でも構わないが、DNSサーバーが停止した場合にはログが転送されなくなる可能性も考慮にいれておく。なお、自宅サーバーの場合、IPアドレスとホスト名の組合せが固定されていることがほとんどなので、/etc/hosts に記述する必要性もあまりないかもしれない。
/etc/syslog.conf にログ転送の設定を追加しておく。大規模な環境では、置き換えるのではなく、追加することがポイントになる。*.* は全ての Facility と Priority を ログサーバーに転送することになるが、特定のFacility や Priority に限定しても構わない。
sysklogd を再起動させれば、ログがlandisk に転送される。問題がなければ、/etc/syslog.conf の記述を消去し、「*.* @landisk」のみに変更しておく。
確認には、logger コマンドを使うと便利だ。以下のようなコマンドを入力し、ログサーバー側の /var/log/messages、もしくは、/var/log/auth.log に"test "というログが記述されていれば正常にログの転送が行われていることがわかる。
|
||||||||||||||||||||||||||||||
| 参考文献 | ||||||||||||||||||||||||||||||
@it 「止められないUNIXサーバのセキュリティ対策」 第7回 UNIXサーバの運用管理で欠かせないログ管理 第8回 syslogによるログの一元管理 第9回 安全性の高いログ・サーバへの乗り換えのススメ（1） 第10回 安全性の高いログ・サーバへの乗り換えのススメ（2） |
||||||||||||||||||||||||||||||
| TOPへ戻る | ||
 |
||
| Copyright © KORO All Rights Reserved. |