序論
これはNagiosをインストールするとき安全な方法でセットアップする事で心して置くべき何点かの簡潔な概要の説明を意図しています。
監視するマシンは他のシステムに入る裏口と見なされるます。多くの場合、Nagiosサーバはリモートサーバを監視するためファイアウォールを通したアクセスを許可されています。 全ケースの大部分で、様々な情報をそれらのリモート・サーバに問い合わせが行えます。 リモート・システムに問い合わせを行うため、いつも一定水準の信頼を監視サーバに与えます。これはシステムへの魅力的な裏口を潜在的攻撃者に与てしまいます。攻撃者は、最初に監視サーバに入ってそれから他のシステムに入るのは簡単な時間で行えます。 リモート・システムの監視に共有のSSHキーを利用しているなら、特にこれは事実です。
侵入者がNagiosデーモンにチェック結果や外部のコマンド実行させる能力があるなら、にせの監視データを提出する可能性があり、にせの通知であなたを怒らせたり、イベントハンドラ・スクリプトを起動されたりします。 サービス再起動、電源入れ直しをするスクリプトのイベントハンドラーは、特に問題が多いものです。
別の気になる所は、ネットを通してやってきた侵入者が監視データ（ステータス情報）を見付出す能力です。 通信チャネルが暗号化されていないと、攻撃者は、監視情報を見て、貴重な情報を獲得できます。 以下の状況を例に挙げます: 攻撃者は、一定期間、ネットから監視しているデータを得て、通常のログインしているユーザと共にあなたのシステムの典型的なCPUやディスク負荷を分析します。 攻撃者は、それゆえ、悟られず、システムを危険にさらし、リソース（CPUなど）を使う最も良い時間を決められます。
ここに、Nagiosベースの監視ソリューションを導入するとき、システムの安全を確実に保つちょっとした助けがあります…
良いやり方
- 監視専用マシンを使用. 私は、監視(そして、ことによると他の管理タスク)専用サーバにNagiosをインストールすることを勧めるます。 まるでそれがネットワークで最も重要なサーバの1つのように監視サーバを保護します。 実行しているサービスを最小に抑え、そして、TCPラッパー、ファイアウォールなどでアクセスを制限します。 Nagiosサーバがあなたのサーバとの通信が許可されていて、ファイアウォールを通る事ができるかもしれない場合、監視サーバへのアクセスをユーザに許すのは、セキュリティリスクとなる可能性があります。 マシンにローカル・アカウントを持つと、システムのセキュリティ・ホールを使って何時もルート権限のアクセスを簡単に得られる事に心してください。
- ルートでとNagiosを実行してはいけません。. Nagiosがルートで稼働する必要はないので、それは行いません。 メイン設定ファイルの nagios_user と nagios_group の指示を使って Nagiosにスタート後、ユーザ/グループの権利を下げるよう指示できます。 ルートアクセスを必要とするイベントハンドラやプラグインを実行する必要があるなら、sudoを使用してみてください。
- チェック結果ディレクトリ以下をロック. nagiosユーザだけにチェック結果ディレクトリのread/write 権限があるかを確認します。 nagios(または、ルート)以外のユーザがこのディレクトリに書くことができると、にせのホスト/サービス・チェック結果をNagiosデーモンに送る事ができます。 これは結果として困り事(にせの通知)やセキュリティの問題(イベントハンドラがスタートされる)を起こすかもしれません。
- 外部コマンド・ファイル以下をロック. 外部コマンドを許可する場合、/usr/local/nagios/var/rw ディレクトリに適切な許可を必ず設定します。 Nagiosユーザ(通常nagios)とウェブサーバーユーザ(通常一人も、httpd、apache2、またはwww-データ)にコマンド・ファイルに書き込み許可を持って欲しいと思うだけです。 監視と管理タスク専用で、一般使用されないマシンの上にNagiosをインストールするのはすばらしいはずです。 公開やマルチユーザ・マシン(推薦されない)にNagiosをインストールしたなら、ウェブサーバーユーザにコマンド・ファイルの書き込み権限を許可するのは、セキュリティ上の問題です。 結局、あなたのシステム上のどんなユーザにも外部のコマンド・ファイルを使ってNagiosを制御して欲しいと思いません。 この場合、私は、nagiosユーザだけにコマンド・ファイルの書き込みアクセスを許可し、CGIを実行するのに nobodyユーザでなく nagiosユーザを使う何かCGIWrapのようなものを使用することを提案します。
- CGI認証の必要性. 私は、CGIにアクセスするため認証を行うことを強く提案します。 それを行ったら、許可された連絡先が持つデフォルトの権限について書かれたドキュメントを読み、必要な場合だけ特定の連絡先に追加の権限を許可します。 認証の設定と権利の許可を設定する指示はここにあります。 CGI設定ファイルの use_authentication 指示を使って CGI認証の機能を禁止すると、コマンドCGIは外部コマンドファイルにどんなコマンドの書き込みも拒否します。 結局、世界にNagiosを制御できて欲しいと思わないでしょう?
- 強化されたCGIセキュリティ基準を実装. 私は、CGIのためにここで説明された、警備の強化基準を実装する検討を強く提案します。 これらの基準は、Nagiosウェブ・インタフェースにアクセスで使うユーザ名/パスワードが第三者によって傍受されないのを確実にする助けとなります。
- コマンド定義にフルパスを使用. コマンドを定義するとき、実行するどんなスクリプトやバイナリーもフルパス(相対的でなく)を必ず指定します。
- $USERn$マクロで機密情報を隠します。. CGIはメイン設定ファイルiとオブジェクト・設定ファイルを読むので、そこにどんな機密情報も(ユーザ名、パスワードなど)置きたくありません。 コマンド定義でユーザ名、そして/または、パスワードを指定する必要があるなら、それを隠すのに$USERn$マクロを使用します。 $USER$マクロは1つ以上のリソース・ファイルで定義されます。 CGIは、リソース・ファイルの内容を読もうとしないので、その場所には更に厳しいアクセス権(600か660)を設定できます。 $USERn$マクロをどの様に定義するかの例について配布されているNagiosベース中のサンプル resource.cfgファイルを見ます。
- マクロから危険な文字を削除. illegal_macro_output_chars 指示を使ってそれが通知で使われる前に危険な文字を$HOSTOUTPUT$、$SERVICEOUTPUT$、$HOSTPERFDATA$、および$SERVICEPERFDATA$マクロから削除します。 危険文字は、シェルによって解釈され、その結果、セキュリティーホールを開けてしまいます。 $HOSTOUTPUT$、$SERVICEOUTPUT$、$HOSTPERFDATA$、そして/または、$SERVICEPERFDATA$マクロ に逆引用符 (`)が含まれるこの例では攻撃者に nagios ユーザとしてどんなコマンド実行も許可されてしまいます。(Ngaiosをルートで動かさない良い理由です)
- リモート・エージェントへの安全なアクセス. リモート・システムの上でエージェント(NRPE、NSClient、SNMPなど)へのアクセスをファイアウォール、アクセス・リストなどを使って制限します。 あなたは誰にもあなたのシステムのステータス情報を見て欲しいと思いません。 攻撃者によってこの情報が使われ、リモート・イベントハンドラー・スクリプトを実行したり、見つからない最も良い時間を決めるのに使われます。
- 安全な通信チャンネル. 可能の場合は常に、Nagiosをインストールしたマシン間、そして、Nagiosサーバと監視エージェントの間の通信チャネルを必ず暗号化します。 ステータス情報を誰かがネットワークを通して盗み見て欲しいと思いません。 攻撃者によってこの情報が使われ、見つからない最も良い時間が決められます。
参照: CGIセキュリティ