安全性の高いログ・サーバへの乗り換えのススメ（2）～ ログ管理のセキュリティ強化を実現する方法を知ろう ～
※ご注意 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 前回に引き続き今回も、安全性がより考慮されたsyslogサーバのsyslog-ng（syslog-next generation）への切り替えについて述べる。 syslog-ngへの切り替え syslogdの設定を引き継ぐ 現行のsyslogdから切替える場合は、syslogdの設定内容をそのまま引き継ぐようにする。もちろん、一からsyslog-ngの設定を書き上げてもよいが、後々の運用管理において混乱が生じないようにするためには、現行syslogdの設定内容を引き継いだ方がよい。syslogdからsyslog-ngへの移行例（設定例）を以下に示す。 移行前：syslog
syslog-ngをmetalog風に使う - GeekFactory
以前、システムロガーにmetalogを使っていました。分かりやすいログ配置、分かりやすい設定ファイル、自動ローテーション等の利点があって重宝していましたが、たった一つ欠点がありました。それは他ホストからのsyslogを受信できないことでした。複数のホストを管理し始めると、ログを集約できないと不便です。 syslog-ngにおける標準的なログ配置はだいたいこんな感じと思います。logrotateでローテーションが行われると messages-20091001.gz といった具合に日付が付加されていきます。 /var/log/messages /var/log/messages-20091001.gz /var/log/secure /var/log/maillog metalogにおける標準的なログ配置は下記です。自動で日次ローテーションされるようになっています。 /var/log/ever
syslog-ngによるsyslog転送 - ragutarouの日記
複数の端末からsyslog転送を行い、そのログを端末毎に振り分けたい。syslogdではそれが難しいため、syslog-ngでやってみようと調べてみました。 syslog-ngの特長 (syslogdとの違い) syslogdで提供される機能はすべて同様に利用できる ログの出力先をアプリケーションやIPアドレス毎に制御できる swatchのように特定の文字列が出力された際にメール通知等のアクションができる udp514ポート以外にTCPや任意のポート番号でログ受信ができる TCPだとログの消失が無くなる root以外のユーザで動作させることができる セキュリティ的に望ましい syslog-ng Ver.1 と Ver.2 との違い 2006年11月に公開された syslog-ng Ver.2 は、Ver.1 とは以下の違いがあるようです。見たところ Ver.2 を使っておけば間違いなさそう
ログ管理 〜syslogとその周辺〜 【応用編】syslog について・・・syslogd の relay/collector の設定
「syslogとは」でも述べたように、syslogd には relay と collector の両方の機能があります。FreeBSD の場合、その設定は /etc/syslog.conf でおこないます。/etc/syslog.conf は 図6 のような構成になっています。 SELECTOR ACTION ..... # PROGRAM のログのみ !PROGRAM SELECTOR ACTION ..... # PROGRAM のログ以外 !-PROGRAM SELECTOR ACTION ..... # HOSTNAME から受信したログのみ +HOSTNAME SELECTOR ACTION ..... # HOSTNAME から受信したログ以外 -HOSTNAME SELECT
syslog-ngのログ集約時にホスト名でフィルターする方法 - 基本へ帰ろう
以下のような、サーバ構成でWebサーバのログを収集したいと考えたとします。 デプロイなどの関係上、設定ファイル（configファイル）はサーバごとに変更したくないという場合があります。 同じ、local6.info でログサーバに投げるため、通常ログサーバ側では同じログファイルに保存されますが、ホスト名などでフィルターをかければログファイルを分けることができます。それをやってみます。 転送元サーバの /opt/syslog-ng/etc/syslog-ng.conf （ホスト名:web-a、web-bともに同じです） /opt/syslog-ng/etc/syslog-ng.conf source s_local { file ("/proc/kmsg" program_override("kernel: ")); unix-stream("/dev/log"); internal();
マクロやテンプレでsyslog-ngを使い倒す
UNIX系OSのシステムロギングをおよそ20年の長きにわたって支えてきた「syslogd」にも、限界が見えつつあります。その限界を打ち破る機能を備えた新しいシスログデーモンを紹介します。（編集部） 前回「syslog-ngの導入と設定」で紹介したsyslog-ngの導入方法に続き、今回はその活用方法を紹介します。 syslog-ngでは、設定ファイルにマクロやテンプレートを使うことができます。マクロを使ってログのファイル名に日時を付加したり、テンプレートを使ってログの内容を自由に組み立てることができます。 またフィルタを設定することで、特定のメッセージを検出することができます。外部プログラムと組み合わせてメールを自動的に送信したり、不正アクセスを制限することも可能です。今回はそうしたsyslog-ngの活用方法を解説します。 【注意】 以降はrootユーザーにて作業を行います。Ubuntu
設定ファイル（/etc/syslog-ng/syslog-ng.conf）の詳細
30.2. 設定ファイル（/etc/syslog-ng/syslog-ng.conf）の詳細カーネルや各種サーバープログラムの出力するシスログメッセージには、ファシリティ（メッセージの種類）とプライオリティ（重要度）と呼ばれる値が設定されています。ファシリティはメッセージの種類を意味し、プライオリティはメッセージの重要度を意味します。syslog-ng デーモンの設定ファイルである /etc/syslog-ng/syslog-ng.conf には、どのファシリティで、どのプライオリティを持つメッセージをどこに出力するか、といった設定を source 、destination、filter の 3 つのパートと log ステートメントによって定義しています。 Turbolinux 11 Server のデフォルトの設定ファイルには以下の記述があります。# で始まる行はコメントです。 opti
UNIXサーバの運用管理で欠かせないログ管理
※ご注意 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 前回までは4回にわたり、サービスの利用制限について説明した。今回からはログの運用管理および監査方法について説明する。 運用管理で欠かせないログ管理 UNIXでは、システムが出力したメッセージやアプリケーションの動作状況などを、ログとしてファイルなどに記録する。記録される内容には、正常な動作を示すメッセージから緊急事態を示すエラーメッセージまで、さまざまな事象が含まれることから、ログはUNIXサーバを運用管理するうえで欠かせない存在となっている。 本稿では、UNIXログシステムの大半を担うsyslogを中心に、現状の把握と見直しを行う。 ログの種類と出力方法 UNIXのログ
syslogdの限界と次世代シスログデーモン（1/3） ― ＠IT
UNIX系OSのシステムロギングをおよそ20年の長きにわたって支えてきた「syslogd」にも、限界が見えつつあります。その限界を打ち破る機能を備えた新しいシスログデーモンを紹介します。（編集部） シスログデーモン「syslogd」は、UNIX系OSのシステムロギングをおよそ20年の長きにわたり支えてきました。しかし、増大する信頼性や安全性への要求、ログの適正保管といった要望に応えるには、syslogdでは力不足との声が高まっています。 そんな折、システムロギングをより確実に行い、RDBMSへのデータ保存や監視システムの連携といった可用性にも優れた、「syslog-ng」や「rsyslog」が注目を集めています。この連載では、こうした次世代シスログデーモンを取り上げ、導入方法や活用方法を解説します。 システムロギングとsyslogd 実行したイベントの履歴、システム不調や変更の記録、不正ア
システム管理の基礎 syslogdの設定をマスターしよう
syslogdによって記録されるログは、システムの運用・管理のための重要な手掛かりとなる。しかし、各環境固有の事情に合っていなければ、ログを取得する意味はない。syslogdやlogrotateの設定方法をマスターし、必要な情報を選別できるようにしよう。（編集局） 管理者にとって、サーバの正常性の確認とトラブルシューティングは、設定変更と同じかそれ以上に重要な作業です。それらの作業を行う際に役立つのが、各アプリケーションやOSが出力するログです。 一般的に、常にログを監視するという業務はあり得ないでしょう。何も起こらなければ退屈以外の何物でもなく、ログを監視していても異常かどうかは即座に判断できないことが多いかと思います。ログを確認するタイミングとしては、システムに何かが起こった場合あるいはこれから何か起こる可能性がある場合が考えられます。それ以外はログを見ないという管理者もいるでしょう。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
汝の隣人のブログを愛せよ | LOVELOG
http://blog.livedoor.jp/shigemarusan/archives/50564039.html