「セキュリティ問題」の版間の差分

2010年8月8日 (日) 20:35時点における最新版

導入 Introduction

これは、安全な方法でセットアップするように、Nagiosをインストールする時、あなたが覚えておくべきであるいくつかのことの簡潔な概観であることを意図します。

あなたの監視ボックスは、あなたの他のシステムに入る裏口として見なされます。多くの場合、ファイアウォールを通したアクセスは、リモートサーバを監視するためにNagiosサーバに許されるでしょう。ほとんどすべてのケースでは、それは様々な情報のためにそれらのリモートサーバについて尋ねる事が出来ます。リモートシステムについて尋ねるためにいつも一定水準の信頼を監視サーバに与えます。これは潜在的攻撃者があなたのシステムへ引きつけられる裏口を与えます。攻撃者は、もし最初に監視サーバをダメにするなら、あなたの他のシステムに簡単に入り込むかも知れません。あなたがリモートシステムを監視するのに共有されたSSHキーを利用しているなら、これは特に本当です。

もし侵入者に、Nagiosデーモンに対するチェック結果または外部のコマンドを提出する能力があるなら、彼らは、偽の通知もしくは引き起こされるイベントハンドラスクリプトと共にあなたを狂わせる偽の監視データを提出する可能性があります。もしサービスの再起動、サイクルパワーなどのイベントハンドラスクリプトがあるのなら、これは特に問題が多いかもしれません。

別の気になる所は、ワイヤを偶然見つけるのと同じように侵入者が監視データ(ステータスの情報)を嗅ぎつける能力です。通信チャネルが暗号化されていないなら、攻撃者達はあなたの監視情報を見ることによって、貴重な情報を獲得できます。例として、以下の状況をみなしてください: 攻撃者は、ある期間、ワイヤに関する監視データを得て、それらに通常ログインするユーザの数に沿って、あなたのシステムの典型的なCPUとディスク負荷使用法を分析します。その時、攻撃者は悟られずにシステムに近づいて、リソースを使用する最も良い時間(CPUなど)を決定できます。

Nagiosベースの監視をしているソリューションを実現す時、ここに、あなたがシステムを安全に保つのを確実にするのを助けるいくつかのヒントがあります…

ベストな練習 Best Practices

1.専用監視するサーバを使用してください。 私は、あなたが監視(そして、ことによると他の管理タスクと)専用のサーバにNagiosをインストールすることを勧めます。まるでそれがあなたのネットワークで最も重要なサーバの1つであるかのように監視サーバを保護してください。実行するサービスを最小に抑えてください、そしてTCP wrappersやファイアウォールなどを経由してアクセスを通過させて下さい。 Nagiosサーバがあなたのサーバとの通信が許容されていて、あなたのファイアウォールを突っ込むことができるかもしれないので、あなたの監視サーバへのアクセスをユーザに許すのは、セキュリティリスクであるかもしれません。もしサーバにローカルのアカウントがありましたらシステムセキュリティーホールを通って、それはいつもルートアクセスをより獲得しやすいのを覚えてください。

2.rootでNagiosを実行しない。 Nagios doesn't need to run as root, so don't do it. Nagiosをroot権限で実行する必要はなくそれをやってはいけません。あなたは、主なコンフィグファイルにおける nagios_ユーザ と nagios_グループ の設定を使用することによって始動の後に特権を下げて、別のユーザ/グループとして稼働するようにNagiosに語りかける事ができます。ルートアクセスを必要とするイベントハンドラかプラグインを実行する必要があるなら、あなたはsudoを使用したかったかもしれません。

3.チェック結果ディレクトリの通過 nagiosユーザだけがcheck result path を読む、または書き込みが出来る事を確実にしてください。 nagios(またはroot)以外のユーザがこのディレクトリに書き込みができるなら彼らは偽のホスト/サービスチェック結果をNagiosデーモンに送るかもしれません。これはいらだち(にせの通知)かセキュリティ上の問題(開始されるイベントハンドラ)をもたらすかも知れません。

4.外部コマンドファイルのロックダウン あなたが外部のコマンドを可能にするなら、/usr/local/nagios/var/rwディレクトリの上に適切なパーミッションを必ず設定してください。あなたは、Nagiosユーザ(通常はnagios)とウェブサーバーユーザ(通常はnobody, httpd, apache2またはwww-datanobodyであることの代わりにnagiosユーザとしてCGIを実行するのにコマンドファイルの上でnagiosユーザの書き込みアクセスを承諾するだけであり、何かCGIWrapのようなものを使用することを提案するでしょう。

5.CGIでの認証の必要性 私は、CGIにアクセスするための認証を必要とすることを強く提案します。 一度、あなたがそれを行う…必要に応じての追加権利のための、認証された特別なコンタクトが持っている標準の権利におけるドキュメンテーションを読んで下さい。認証をセットアップして承認権利を構成する設定を ここで見つけることができます。 CGIコンフィグファイルにuse_authentication設定を使用することでCGI認証を無効にするなら、 command CGIは外部のコマンドファイルへのどんなコマンドの書き込みも拒否します。結局、あなたは、Nagiosを制御できり世界が欲しくないんでしょう?

6.エンハンスドCGIセキュリティ診断の実行 私は、あなたがここで説明されるように、エンハンスドCGIセキュリティ診断の実行を検討する事を強く提案します。これらの診断は、あなたがNagiosウェブインタフェースにアクセスするのに使用するユーザ名/パスワードが第三者によって傍受されない事を確実にするのを助けることができます。

7.コマンド定義における絶対パスの使用 コマンドを定義したら、あなたが作成しているあらゆるスクリプトやバイナリに絶対パス(相対パスでなく)を必ず指定してください。

8.$USERn$マクロを使用した機密情報の隠ぺい そのCGIがメインコンフィグファイルとオブジェクトコンフィグファイルを読み込むので、あなたは、そこにあるどんな機密情報も(ユーザ名、パスワードなど)保ちたくありません。コマンド定義におけるユーザ名、そして/またはパスワードを指定する必要があるなら$USERn$マクロを使用して、それを隠してください。 $USERn$マクロは、1またはそれ以上のリソースファイルで定義されます。 CGIは、リソースファイルのコンテンツを読むのを試みないので、あなたはそれらの上により厳しいパーミッション(600か660)を設定できます。どう$USERn$マクロを定義するかの例のためのNagiosディストリビューションのベースの中でサンプルresource.cfgファイルを見てください。

9.マクロから危険な文字列を除去して下さい それらが通知などに使用される前にillegal_macro_output_chars 設定を使用して、$HOSTOUTPUT$、$SERVICEOUTPUT$、$HOSTPERFDATA$および$SERVICEPERFDATA$マクロから危険な文字列を取り除いてください。危険な文字列は、シェルによって解釈され、その結果セキュリティーホールを開くかも知れないものであるかもしれません。これは、攻撃者をNagiosユーザとして、任意のコマンドを実行する事を認めてしまう $HOSTOUTPUT$、$SERVICEOUTPUT$、$HOSTPERFDATA$、そして/または$SERVICEPERFDATA$マクロにおけるbacktick(`)文字列の存在が一つの例です。 (rootユーザとしてNagiosを実行しない十分な理由の1つ)

10.リモートエージェントへのセキュアアクセス ファイアウォール、アクセスリストなどを使用するリモートシステム上で、エージェント(NRPE、NSClient、SNMPなど)へのアクセスを必ず通過させて下さい。あなたは全ての人に、ステ－タス情報のためにあなたのシステムについて疑って欲しくないですよね。この情報は、攻撃者が気付かれずにリモートイベントハンドラスクリプトを実行するか、または最良な時を決定するのに使用できました。

11.安全通信チャンネル 可能であるときはいつもあなたは異なったNagios設備間と、、あなたのNagiosサーバと監視しているエージェントの間の通信チャネルを必ず暗号化して下さい。あなたは、ステータス情報をかぎつける事が出来る誰かにあなたのネットワークを越えて欲しくはないですよね。攻撃者は、見つからずに最も良いタイミングを決定するのにこの情報を使用出来ました。