「セキュリティ問題」の版間の差分
(ページの作成: == 導入 Introduction == center これは、安全な方法でセットアップするように、Nagiosをインストールする時、あ…) |
|||
14行目: | 14行目: | ||
== ベストな練習 Best Practices == | == ベストな練習 Best Practices == | ||
+ | 1.<b>専用監視するサーバを使用してください。</b> 私は、あなたが監視(そして、ことによると他の管理タスクと)専用のサーバにNagiosをインストールすることを勧めます。まるでそれがあなたのネットワークで最も重要なサーバの1つであるかのように監視サーバを保護してください。実行するサービスを最小に抑えてください、そしてTCP wrappersやファイアウォールなどを経由してアクセスを通過させて下さい。 Nagiosサーバがあなたのサーバとの通信が許容されていて、あなたのファイアウォールを突っ込むことができるかもしれないので、あなたの監視サーバへのアクセスをユーザに許すのは、セキュリティリスクであるかもしれません。もしサーバにローカルのアカウントがありましたらシステムセキュリティーホールを通って、それはいつもルートアクセスをより獲得しやすいのを覚えてください。 | ||
+ | |||
+ | [[ファイル:Security3.png|none]] | ||
+ | |||
+ | 2.<b>rootでNagiosを実行しない。</b> Nagios doesn't need to run as root, so don't do it. Nagiosをroot権限で実行する必要はなくそれをやってはいけません。あなたは、主なコンフィグファイルにおける [http://nagios.sourceforge.net/docs/3_0/configmain.html#nagios_user nagios_ユーザ] と [http://nagios.sourceforge.net/docs/3_0/configmain.html#nagios_group nagios_グループ] の設定を使用することによって始動の後に特権を下げて、別のユーザ/グループとして稼働するようにNagiosに語りかける事ができます。ルートアクセスを必要とするイベントハンドラかプラグインを実行する必要があるなら、あなたは[http://www.courtesan.com/sudo/sudo.html sudo]を使用したかったかもしれません。 | ||
+ | |||
+ | |||
+ | 3.<b>チェック結果ディレクトリの通過</b> nagiosユーザだけが[http://nagios.sourceforge.net/docs/3_0/configmain.html#check_result_path check result path] を読む、または書き込みが出来る事を確実にしてください。 nagios(またはroot)以外のユーザがこのディレクトリに書き込みができるなら彼らは偽のホスト/サービスチェック結果をNagiosデーモンに送るかもしれません。これはいらだち(にせの通知)かセキュリティ上の問題(開始されるイベントハンドラ)をもたらすかも知れません。 | ||
+ | |||
+ | 4.<b>外部コマンドファイルのロックダウン</b> あなたが[http://nagios.sourceforge.net/docs/3_0/extcommands.html 外部のコマンド]を可能にするなら、/usr/local/nagios/var/rwディレクトリの上に適切なパーミッションを必ず設定してください。あなたは、Nagiosユーザ(通常はnagios)とウェブサーバーユーザ(通常はnobody, httpd, apache2またはwww-datanobodyであることの代わりにnagiosユーザとしてCGIを実行するのにコマンドファイルの上でnagiosユーザの書き込みアクセスを承諾するだけであり、何か[http://cgiwrap.sourceforge.net/ CGIWrap]のようなものを使用することを提案するでしょう。 | ||
+ | |||
+ | |||
+ | 5.<b>CGIでの認証の必要性</b> 私は、CGIにアクセスするための認証を必要とすることを強く提案します。 一度、あなたがそれを行う…必要に応じての追加権利のための、認証された特別なコンタクトが持っている標準の権利におけるドキュメンテーションを読んで下さい。認証をセットアップして承認権利を構成する設定を [http://nagios.sourceforge.net/docs/3_0/cgiauth.html ここ]で見つけることができます。 CGIコンフィグファイルに[http://nagios.sourceforge.net/docs/3_0/configcgi.html#use_authentication use_authentication]設定を使用することでCGI認証を無効にするなら、 [http://nagios.sourceforge.net/docs/3_0/cgis.html#cmd_cgi command CGI]は[http://nagios.sourceforge.net/docs/3_0/configmain.html#command_file 外部のコマンドファイル]へのどんなコマンドの書き込みも拒否します。結局、あなたは、Nagiosを制御できり世界が欲しくないんでしょう? | ||
+ | |||
+ | |||
+ | 6.<b>エンハンスドCGIセキュリティ診断の実行</b> 私は、あなたが[http://nagios.sourceforge.net/docs/3_0/cgisecurity.html ここ]で説明されるように、エンハンスドCGIセキュリティ診断の実行を検討する事を強く提案します。これらの診断は、あなたがNagiosウェブインタフェースにアクセスするのに使用するユーザ名/パスワードが第三者によって傍受されない事を確実にするのを助けることができます。 | ||
+ | |||
+ | |||
+ | 7.<b>コマンド定義</b>における絶対パスの使用 コマンドを定義したら、あなたが作成しているあらゆるスクリプトやバイナリに絶対パス(相対パスでなく)を必ず指定してください。 |
2010年8月8日 (日) 20:32時点における版
導入 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.コマンド定義における絶対パスの使用 コマンドを定義したら、あなたが作成しているあらゆるスクリプトやバイナリに絶対パス(相対パスでなく)を必ず指定してください。