目次 表示
GroundWork Monitorは、実際の検出プロセスのための設定オプションを格納するのに検出定義を使用します。一度、検出定義が作成されると、管理者は手元で容易に、その業務に対する最も適切な検出定義を選択することができ、適切なすべてのオプションと選択済みの変数によって、すぐに関連した検出処理が始ます。
このモデルでは、管理者は、必要とするそれぞれの検出プロセスのために、個別の検出プロセスが完全に実施されるために必要なオプションを格納した別々の検出定義を作成します。
例えば、管理者は、単に一握りのTCPとUDPのウェルノウンサービスについてローカルネットワーク上のデバイスを探索する検出定義と、SNMPサービスについてリモートネットワーク上のデバイスを探索する別の検出定義を作成し、これらそれぞれのプロセスで異なるタイプのデータベース同期を行わせることができます。
検出定義は最初から最後までの検出操作を記述しているので、完了までの実行の全プロセスに必要なすべてのオプションと変数が盛り込まれています。より具体的に言うと、各検出定義には探索するアドレスの範囲、検索するネットワークアドレスに使用する検出方法、その結果を処理するのに使われる自動化スキーマ定義、および完了時に行われるべき自動アクションを設定するオプションと変数を含みます。
この関係を下記の図に示し、以下の文章で詳しく説明しますが、ここで理解するべき重要点は、これらのオプションと変数の全てが検出定義を作成する前に指定されなければならないことです。
図: 検出定義
検出定義の主要な構成要素は、下記のようになります:
各検出プロセスは、ひとつ以上のIPアドレスの範囲に対して行われ、最低限ひとつのアドレス範囲が指定される必要があります。アドレス範囲は、検出定義によって参照される独立したオブジェクトですが、検出定義自体の一部として定義する、あるいは、検出定義内に格納される検出方法の一部として定義する(次のセクション参照)こともできます。管理者は、複数のアドレス範囲を定義することができ、また、以前処理したものにアドレス範囲を追加したり無効化したりすることができます(これにより、管理者が複数の大きなネットワークに対して実行する前に小さなネットワークに対しての検出定義のテストを実施できるようにします)。
検出サービスは、各デバイス上でアクティブなサービスを検出するために複数種類のネットワーク技術を使用できます。検出方法は独立したオブジェクトであり、検出定義によって参照され、また個別に管理されます。少なくともひとつの検出方法が各検出定義で定義されなければなりませんが、複数の検出方法をひとつの検出定義に関連付けることができ、また、検出定義毎の複数の検出方法は有効にしたり無効にしたりできます。
デフォルトでは、GroundWorkMonitorは、一般的なインターネットサービスのウェルノウンTCPと、UDPポートを探索するのにオープンソースのnmapユーティリティを使い、また、一般的な管理データに定義されたデバイスを探索するために、SNMPクエリを使います。しかし、検出サブシステムはまた、一般的なUDPサービスを探索するのにnmap を使い、他の場所で生成されたWMI 検出データをインポートすることができます。管理者はまた、必要に応じて任意のスクリプトとコマンドを使える、管理者自身の検出方法を作成することができます。
選らばれたネットワークについて、一度、選ばれた検出方法で探索プロセスが完了すると、検出されたデバイスとホストとサービスプロファイルのマッチングプロセスが始まります。このプロセスは別のスキーマ定義構成オブジェクトの中に格納された、それ自体の構成オプションを使用する自動化サブシステムによって管理されます(スキーマ定義についての詳細は、「自動化(Automation)」 セクション以下を参照してください)。スキーマ定義は、マッチングプロセスに対して検出データ形式を提示するのに使用し、また検出出力と適当なホストをサービスプロファイルにマッピングする時に使用される文字列構文を記述します。各検出定義は、スキーマ定義をひとつだけ持たなければなりません。
プロファイルのマッチングプロセスが完了したら、自動検出サービスは管理者の確認のためにその結果を表示するか、検出したノードを自動的に Foundationデータベースに追加するか、構成データベースを更新して必要であればそれ自体の必要なサービスを再起動するかのどれかが行えます。このオプションは自動化アクションの設定で制御され、Interactive、 Automatic、Auto-Commit (上記の順)のどれかを選択します。このオプションはプロセス毎に上書きすることができ、そのため管理者は GroundWork Monitor の構成データベースに結果を自動的にコミットされるよう頼む前に、検出プロセスをテストすることができます。
検出定義は、検出コンソール画面で管理されます。検出コンソール画面をアクセスするには、メインメニューからAuto Discovery (自動検出)メニューを選択します。検出画面はデフォルトのアクティブ画面ですが、トップメニューバーの Discovery(検出)メニューを選ぶことで、明示的にこの画面をアクティベートすることができます。
デフォルトの検出コンソール画面を下図に示します。先に述べた例で分かるように、GroundWork Monitorは、インストレーション中に作られた GroundWork-Community-Discovery と呼ぶデフォルトの検出定義を提供します(GroundWork Monitor の商用バージョンでは、デフォルトの検出定義はGroundWork-Discovery-Proと呼びます)。
図: 検出コンソール画面
複数の検出定義があるとき、現在選択されている検出定義が 黄色の背景色で強調されます。ひとつの検出定義しかないときは、それはいつも選択され、いつも強調されます。
いくつかの 実行時オプションと変数は各検出プロセスで使用され、メインコンソール画面に表示されます。たとえば自動化アクションタイプ(Interactive(対話型)、Auto(自動)、Auto-Commit(自動コミット))が検出定義名と説明と同じ行に表示されます。一方、全ての
既知のアドレス範囲は、すでに現在選ばれている検出定義にリンクされているアドレス範囲といっしょに画面の下部に表示されます。
自動化アクションとアドレス範囲は、サーチを始める前に変更したいオプションを選択することで簡単に変更できます。メイン検出コンソール画面内のこれらのオプションへのアクセス提供により、管理者は検出定義自体を編集することなく、これらの設定を実行時に変更することができます。 上記の Save(保存)ボタンをクリックすると、現在選択されている実行時オプションを検出定義の恒久的なデフォルトにします。
検出定義への細かい変更は、Edit(編集)ボタンをクリックして行います。このトピックについては「検出定義の編集」セクションで説明します。
新しい検出定義を作成するには、New(新規作成)ボタンをクリックして行います。このトピックについては「検出定義の作成」セクションで説明します。
現在選んでいる検出定義と実行時オプションを使って検出プロセスを実行するには、Go(実行)ボタンをクリックします。このトピックについては「検出プロセスの実行」セクションで説明します。
新規の検出定義を作成するには、検出コンソール画面の New(新規作成)ボタンをクリックします。下図のような新しい画面が表示されます。図上のどこかのフィールドをクリックすると、下記の表のフィールドの説明が表示されます。
あなたの要求を満たすよう、フィールドに入力します。
要求を満たすようにフィールドへの入力が終わったら、Create(作成)ボタンをクリックして続けます。ここで、新しい検出定義値が既にロードされた検出定義エディタ画面が表示されます。新しい検出定義の作成を続けたくなければ、Cancel(キャンセル)ボタンをクリックして、メイン検出コンソール画面に戻ります。
図:新規自動検出定義
表:新規自動検出定義のフィールド
Name(名前) |
新しい検出定義の名前を入力します。 |
Description(定義) |
新しい検出定義についての説明を入力します。 |
Import Schema (インポートスキーマ) |
このドロップダウンリストは、これまでの作成されたすべての自動化スキーマ定義を表示します。デフォルトでは、このリストには、備え付けの"GroundWork Community Discovery"スキーマ定義のみが含まれます(商用版では、"GroundWork-Discovery-Pro"が表示されるでしょう)。異なるスキーマを使う必要があれば、現在の操作をキャンセルして、適当なスキーマが作成された後で戻ってくることができます。あるいは、現在の操作を続け、後で検出定義を変更することもできます。検出定義の作成を続けるためには、自動化スキーマ定義を選ぶ必要があります。タイプに関わり無くドロップダウンリストの中にはすべてのスキーマ定義が表示されますが、検出プロセスは host-import のスキーマタイプを持つスキーマ定義のみを使用することができることに注意してください。自動化スキーマ定義とスキーマタイプについて詳しくは、自動化(Automation)のセクションを参照ください。 |
Default Automation |
このドロップダウンリストでは使用可能な三つの自動化オプションが表示されます。 "Interactive(対話型)" は管理者が検出プロセスの結果の確認を要求される、 "Auto(自動)" は結果が GroundWork Monitor の構成データベースに追加される(しかし、その構成は自動的にコミットされない)、"Auto-Commit(自動コミット)" はその結果が追加されてその変更が自動的にコミットされて、 GroundWork Monitor は直ぐにそれらのデバイスの監視を始めます。処理を続けるために自動化アクションを選択する必要がありますが、後で変更することもできます。 |
Create from Template |
検出定義は一部を再利用可能できる"テンプレート"として保存することができます(詳細は次のセクションの記述を参照ください)。 すでに検出定義をテンプレートとして保存してある場合、ドロップダウンリストからそれ選ぶことで、そのオプションと変数のいくつかを再利用することができます。デフォルトでは、このリストボックスには、デフォルトの検出定義に由来する備え付けの "GroundWork-Default-OS" (商用版では "GroundWork-Discovery-Pro")のみが含まれます。 他の定義からのオプションを引き継ぎたくない場合はドロップダウンリストを空のままにしてください。 |
検出定義に関係するオプションと変数を編集するには、検出コンソール画面中の編集したい検出定義を選びます。
Edit(編集)ボタンををクリックします。そうすると、検出定義の値が既にロードされている検出定義エディタ画面が表示されます(先のセクションで述べたように、この画面は新規の検出定義画面が作られた時にも表示されます)。下図はデフォルトの GroundWork-Community-Discovery からの値を使用した検出定義エディタ画面を示します。
検出定義への変更を終了したら、下記のどれかを選ぶことができます:
その変更を恒久化するため Save(保存)ボタンをクリックします。
将来に適用できるようにする検出定義テンプレートを作成するには、Save As Template (テンプレートとして保存)ボタンをクリックします。テンプレートはXMLテキストファイルとして、GroundWork Monitor サーバの /usr/local/groundwork/core/monarch/automation/templates ディレクトリに保存されます。テンプレートファイルは、他のGroundWork Monitorサーバ上の同ディレクトリにコピーし、すぐにそのシステム上で使用できます。
変更した内容を恒久化しないまま、今の設定で検出プロセスを実行したい場合、 Go(実行)ボタンをクリックします。変更をキャンセルし、メイン検出画面に戻る場合は Close(閉じる)ボタンをクリックしてください。
図:検出定義エディタ画面
表:検出定義のフィールド
Description(説明) |
この検出定義のための簡潔な説明を入力します。 |
Schema(スキーマ) |
このドロップダウンリストは、これまでの作成されたすべての自動化スキーマ定義を表示します。デフォルトでは、このリストには、備え付けの"GroundWork Community Discovery"スキーマ定義のみが含まれるでしょう。自動化についての情報は後述の自動化セクションを参照してください。タイプに関わり無くドロップダウンリストの中にはすべてのスキーマ定義が表示されますが、検出プロセスは host-import のスキーマタイプを持つスキーマ定義のみを使用することができることに注意してください。自動化スキーマ定義とスキーマタイプについて詳しくは、自動化(Automation)のセクションを参照ください。 |
Default Automation (デフォルトの自動化) |
このドロップダウンリストでは使用可能な三つの自動化オプションが表示されます。 "Interactive(会話型)" は管理者が検出プロセスの結果の確認を要求される、 "Auto(自動)" は結果が GroundWork Monitor の構成データベースに追加される(しかし、その構成は自動的にコミットされない)、"Auto-Commit(自動コミット)" はその結果が追加されてその変更が自動的にコミットされます。 |
Traceroute Option |
このオプションは検出サービスが自動的に検出したデバイスの親デバイスを調べるのに、traceroute コマンドを使用することを認めます。このオプションは、ひとつ以上のリモートネットワークを探索する場合と、 Nagios 内のホストエントリがネットワークトポロジーを反映する親子関係をもつ場合にのみ有用です。 traceroute コマンドでは、検出したデバイスと中継するネットワークデバイス上で ICMP を有効にする必要があることに注意してください。また、非常に巨大なネットワークや低速な広域通信網(WAN)で探索を行おうとする場合、デフォルトのホップ数とタイムアウト値を適当なサイズのネットワークに合わせて、デフォルト値を上書きする必要があるかもしれないことに注意してください。 |
Methods(方法) |
エディタ画面の本部分は、使用可能なネットワークサービスについて検出されたデバイスを調べるための検出方式を示します。これまでに定義されたすべての検出方式(他の検出定義で作成されたものを含みます)がここに表示され、そして現在の検出定義に関連付けられた検出方式が積極的に選択されます。新規インストールでは、ここにはデフォルトのインストレーションで提供される"Nmap TCP"と"Nmap UDP"の検出方式のみが表示され、追加検出方式が必要に応じて作成されるでしょうし、既存の検出方式の変更も可能です。管理者が作成作業中に、ひとつ以上の検出方式を選んでいる検出テンプレートを使用しない限り、新規の検出定義に関連付けられる検出方式はありません。検出方式の作成と管理についての情報は、後述の検出方式の管理(Managing Discovery Methods)のセクションを参照してください。 |
Ranges and Filters |
エディタ画面の本部分は、探索するために使用するアドレス範囲を表示します。他の検出定義で作成されたものを含む、これまでに定義されたすべてのアドレス範囲がここに表示されます。新規インストールでは、ここにはインストレーション時に作成されるアドレス範囲 "local subnet" のみが表示され、追加アドレス範囲が必要に応じて作成されるでしょうし、既存のアドレス範囲の変更も可能です。管理者が作成作業中に、ひとつ以上のアドレス範囲を選んでいる検出テンプレートを使用しない限り、新規の検出定義に関連付けられるアドレス範囲はありません。アドレス範囲の作成と管理についての情報は、後述のアドレス範囲の管理(Managing Address Ranges)のセクションを参照してください。 |
検出定義を削除するには、検出定義エディタ画面の中から行う必要があります。メイン検出コンソール画面から削除したい検出定義を選んで Edit(編集)ボタンをクリックします。検出定義エディタ画面が表示されたら、右上端の Delete(削除)ボタンをクリックします。すると、検出定義に関連した検出方式を同様に削除できる、下記のような確認ボックスが表示されます:
図:検出定義の削除
検出定義の関連した検出方式のどれかを削除したい場合は、該当するチェックボックスを有効にします。選択した内容で問題なければ、検出定義と選んだ検出方式を削除するため Yes(はい)ボタンをクリックするか、キャンセルしてメイン検出コンソール画面に戻るには No(いいえ)ボタンをクリックします。
アドレス範囲は、検出プロセス中に探索するIPアドレスを指定するのに使用します。アドレス範囲は、メイン検出コンソール画面、検出定義エディタ画面および検出方式エディタ画面で指定することができます。これら全ての場合において、下記の図のようにRanges and Filters(範囲とフィルタ)セクションがあります。
インストール中、GroundWork Monitorは、サーバーのローカルIPアドレスとローカルサブネットマスクを調べ、ローカルネットを反映するlocal subnet(ローカルサブネット)アドレス範囲を作成しようとします。下記の例では Range / filter の local subnet エントリの値として 127.0.0.* が示されていますが、あなた自身のエントリにはあなたのローカルなネットワークが反映されるでしょう。
図:アドレス範囲とフィルタ
必要な数のアドレス範囲を作成することができ、複数のアドレス範囲がどの検出プロセスついても指定することができます。最低限ひとつのアドレス範囲が実行される検出プロセスを行うために使用されなければなりません。
新規のアドレス範囲を作成するには、フィールドに適切な値を入力し、Add Range/Filter(範囲/フィルタ追加)ボタンをクリックします。
この時点で、新しいアドレス範囲が作成され、現在の画面のRange/Filter(範囲/フィルタ)セクションに現れます。検出プロセスに取り込まれる前に、アドレス範囲が選択される必要があることを覚えて置いてください。
アドレス範囲を削除するには、その隣にある delete Range/Filter(範囲/フィルタ削除)のハイパーリンクをクリックします。アドレス範囲の編集機能はありません。アドレス範囲を変更したい場合、削除して再作成する必要があります。
表:範囲とフィルタ
Name (名前) |
アドレス範囲の短い名称を入力します。 |
Type (タイプ) |
自動検出には二つのタイプのアドレス範囲があります:"include (包含)"範囲は探索されるアドレスを指定し、"exclude (除外)"範囲は、探索されないサブネットの範囲を指定します。"include (包含)" 範囲にないIPアドレスは探索されませんので、"include (包含)"範囲中にないアドレスを"exclude (除外)"する必要はありません。 |
Range / Filter
|
アドレス範囲は下記の異なるフォーマットのどれかを使用することができます: n.n.n.nやhostname.domain.dom .単一のホストを包含したり、除外したりする場合、IPアドレスやホスト名を指定します(ホスト名が使用される場合、検出プロセスを実施する度にGroundWork Monitorサーバによって名前解決ができなければなりません) ?n.n.n.* 指定したオクテット範囲に適合する全てのアドレスを指定したい場合、指定するオクテットに対してワイルドカード文字を使用することができます。例えば、"192.168.10.*"を指定すると、192.168.10.0 から 192.168.10.255が適合します。 ? n.n.n.n-n オクテット境界に一致しないアドレス範囲を指定したい場合、開始と終了アドレスをダッシュで分けて指定できます。例えば、"192.168.10.5-6"は、192.168.10.5 と 192.168.10.6 のみが一致します。 ? n.n.n.n,n.n.n.n,n.n.n.n .ひとつのエントリの中に複数の個別アドレスを指定したい場合、個々のアドレスをカンマで分けて指定することができます。例えば、"192.168.10.5,192.168.10.7"の指定は、192.168.10.5 と 192.168.10.7 のみの指定となります。 |
検出方式は、各IPアドレス上で探索されるべきネットワークサービスを指定するのに使用します。この処理の間、検出サービスが、カレントの検出定義に関連付けられたIPアドレスの一覧に対して繰り返され、カレントアドレスに対して1回かそれ以上のテストが実行され、そして検出されたサービスの目録となる1つかそれ以上の行の出力データが生成されます。つづいて、出力データがホストとサービスデータをしかるべき Nagios プロファイルにマッピングする自動化サブシステムによって読まれ、分析されます。
検出方式は、下図のようなMethods (方式)セクションを持つ、検出定義エディタ画面中の検出プロセスとのみ関係付けられることができます。
図:方式
GroundWork Monitorはデフォルトで、上記の図で表示されている二つの検出方式を提供します:
Nmap TCP 検出方式は、WebやEメールサービスのような一般的なTCP/IPネットワークサービスに対するデバイスを調査するために使用します。
SNMP 検出方式は、SNMPの管理情報に対する調査をするために使用されます。
必要に応じてバンドルされた検出方式を変更したり、新しい方式を作成することができます。複数の検出方式を各検出定義にアサインすることができます。少なくともひとつの検出方式が検出プロセスを実施するために使用される必要があります。
注意: 検出方式は順番に実行され、場合によっては、先の検出方式で検出されたデバイスのみがクエリされます。たとえば、上図の Nmap TCP 方式は、SNMP検出方式の前に実行されます(この関係は、後述するように、SNMP検出方式にとって重要です)。現在、検出方式の順番を変えることはできませんので、必ず望ましい順番で作成する必要があります。
適切な値でフィールドを埋め、Add Method(方式追加)ボタンをクリックします。
この時点で、検出方式エディタ画面が表示され、検出方式に関連するオプションと変数を入力できるようになります。(検出方式エディタ画面のレイアウトは、各検出タイプ毎に異なります)。
既存の検出方式を変更したい場合、検出方式の隣にある Edit Method(方式編集)のハイパーリンクをクリックします。これにより、選んだ検出方式の内容を持つ、しかるべき検出方式エディタ画面が表示されます。
表: 検出方式のフィールド
Name (名前) |
検出方式の簡易名を入力します。 |
Type (タイプ) |
下記に詳しく説明する4つのタイプの検出方法が使用可能です。しかし、このフィールドはデバイスを探索するのに使用されるネットワーク技術を表現するためだけに使用され、検出方式が完全に構成されて機能するには、さらなる構成設定が別の画面で要求されることを理解することが重要です。
|
Description(説明) |
検出方式に簡潔な説明を入力します。 |
Nmap 検出方式は、TCPとUDP接続要求を使って、検出された各デバイス上のネットワークサービスを探索します。探索が成功すると必ず、検出方式は検出されたサービスを示すサービスの match value (一致値)を返し、(可能であれば)いっしょにホストプラットフォームの識別情報を返します。探索終了後、一致値は自動化処理のために、そのデバイスにとって適切なホストとサービスプロファイルに関係付けられます。
複数のサービスプロファイルを指定できますが、それらは全て同一のプロトコルタイプである必要があり、少なくともひとつのサービスが定義されなければなりません。
下図は、デフォルトの Nmap TCP 検出方式を使った Nmap タイプの検出方式エディタ画面です。下表は、Nmap検出方式エディタ画面のオプションとフィールドです(異なるタイプのNmap探索には異なるフィールドが使われることに注意してください)。
図:Nmap TCP検出方式
表:Nmap検出方式エディタのオプションとフィールド
Scan Type (SCANタイプ) |
nmap のSCANタイプには下記の3つがあります:
|
TCP SNMP Check |
このオプションは、検出されたデバイスに対し、そのターゲット上でSNMPが有効にされているかを確認するためのUDPクエリでの探索も行うかどうかを決定します。このオプションが有効であって、SNMP検出方式も有効な場合、UDPクエリに応答したデバイスのみが、その後のSNMP検出方式での探索を受けます。このチェックボックスはTCP SCANのひとつが選ばれた(UDP SCANは別のオプションを必要とせず、明示的にSNMPの探索をすることができます)場合にのみ有効であることに注意ください。 |
SNMP Match Strings |
TCP SCAN処理の間に、TCPプロトコルのハンドシェイクのある特徴を調べることでnmapはホストのプラットフォームとターゲットデバイス上で使用されているオペレーティングシステムの識別を試み、この情報といっしょに結果データ内に記録されます。 この処理が成功した場合、より制限された数の継続SNMPクエリのために、結果のホスト識別文字列を追加入力フィルタとして使えます。このオプションを使うために、このフィールドに、制限フィルタとして使いたい、いくつかあるいは全てのデバイス識別文字列フィルタの文字列を入力する必要があります。一般的に、これは"cisco"や"hewlett-packard"ようなの文字列あるいは、その他のnmapホスト識別子の文字列の一部となるでしょう。複数の文字列は、コンマで区切って入力することができます。一致処理では大文字小文字を区分しません。このフィールドは TCP SCANが使用されているときにのみ有効であることに注意ください(UDPはハンドシェイクを使用しないので、nmapはUDP探索によってホストのオペレーティングシステムを検出することができません)。 |
Scan Timeout |
このオプションはnmapが生成したコネクション要求間の遅延を調べます。短い猶予時間を指定するとSCANは早くなりますが、ローカルサーバとリモートのネットワークが遠隔や低速なネットワークパスで分かれている場合、非常に早くタイムアウトしてしまうでしょう。積極的(aggressive)な遅延時間が侵入検出アラームを誘発することも知られていますので、長めの猶予時間にすれば、探索による通知が発生しないかもしれません。このフィールドの選択肢は、paranoid(緩慢)、polite(丁寧)、normal(普通)、aggressive(積極的)とinsane(高速)であり、順に非常に遅いSCANから非常に早いSCANとなります。 |
Ports |
nmap検出方式エディタ画面の本セクションは、探索するポート番号と探索が成功したと判断された際に、返される「一致値(Match Values)」を列挙するために使用します。 新規の指定を追加する場合は、ポート番号と成功時に返される一致値を入力し、Add Port (ポート追加)ボタンをクリックします。既存の指定を削除するには、エントリーの脇にあるdelete port (ポート削除)のハイパーリンクをクリックします。 |
一致値の文字列は、ホストエントリとサービスプロファイルと関係付けに使用される、結果ログファイルに保存されます。一致値の内容は、既存のサービス、サービスプロファイル、ホストプロファイルと"検出"値で調律されていることに注意ください。あなたはこれらの調律された値に規制されませんが、サービス、サービスプロファイル、ホストプロファイルと検出された一致値の順番のリストが構成データベースや、GroundWorkサーバの/usr/local/groundwork/profilesディレクトリの中にロードされたどんなプロファイルの中にも見られるでしょう。ひとつの調律されたサービス、サービスプロファイルやホストプロファイルの値を選ぶことの効果は、使用される自動化スキーマで決まります。
スキーマの編集についての詳細は、自動化についてのセクションを参照してください。デフォルトのスキーマは、これらを下記のように処理するでしょう:
表:一致値の形式とアクション
If the match values begins with: |
行われるべきアクション: |
service-<service name> |
検出されたホストに指定されたサービスをアサインします。 |
service-profile-<service profile name> |
指定されたサービスプロファイルを検出されたホストにアサインします。 |
host-profile-<host profile name> |
指定されたホストプロファイルを検出されたホストにアサインします。 |
下記の一致値はその後に続く検出方式上でのみ効果を持ちます。別の一致値の効果は以下のようになります:
表:一致値の形式とアクション
If the match values begins with:(一致値が下記の形式で始まる場合) |
行われるべきアクション: |
discover-snmp |
その後に続くSNMP方式がこのポート・シグネチャーと一致するホストに制限されます。 |
discover-script |
その後に続くscript 方式がこのポート・シグネチャーと一致するホストに制限されます。 |
discover-wmi |
効果なし。将来機能のための予約。 |
新規に生成された一致値は、しかるべき自動化スキーマ定義が更新されるまでは使えないことに注意してください (このプロセスについて詳しくは「自動化サブシステム」の セクションを参照してください)。
表:範囲とフィルタ
Ranges and Filters |
検出方式エディタ画面の本セクションで、特定のアドレス範囲に特定の検出方式をリンクすることができます。検出定義で複数のアドレス範囲に対して複数の検出方式を使用していて、現在の検出方式がその中のいくつかのアドレス範囲にのみ都合が良い場合、その検出方式を特定のアドレス範囲で利用できるようにしたくなるかもしれません。しかしながら、検出定義において、定義されたすべての検出方式をすべての有効なアドレス範囲で使用する場合においては、その検出方式内で明示的にアドレスを有効にすることはできません。 |
オプションとフィールドが満足する内容で満たされたら、続けるために右上部にあるSave(保存) ボタンをクリックします。この時点で、元の検出定義エディタ画面に戻るでしょう。また、該当するボタンをクリックすることで、検出方式の名称を変更したり削除することができます。
SNMP 検出方式は、デバイスが SNMP プロトコルをサポートしているかを調べるためにSNMP クエリを使用します。サポートされていれば、追加の探索が使用されます。そのデバイス上のネットワークインタフェースを列挙した後、各インタフェースに適合するサービスプロファイルをアサインします。デバイスがSNMPクエリに応答しなければ無視されます。
さらに SNMP へ応答したデバイスは、オプションとして特定の計測を要求されます。これらの計測は構成ファイルの中のユーザインタフェースの外にある、 /usr/local/groundwork/core/monarch/automation/conf/snmp_scan_input.cfg. の中で指定されます。
このファイルのフォーマットは OID=matchstring であり、OID は SNMP オブジェクト識別子の数字で、matchstring はサービスやサービスプロファイルを指定された OID の SNMP クエリに応答することのできるホストに割り付けるための任意の文字列です。
これは高度なオプションです。構成設定には、探索するデバイス上の SNMP MIB の知識が必要です。GroundWork Monitor の Professional バージョンは、デフォルトファイルの中にいくつかのサンプルを持っています。GroundWork Monitor Professional 内のデフォルト検出定義のための自動化スキーマ内に、これらのサンプルを処理するのに必要なスキーマ値が含まれています。
検出定義に関連付けられた SNMP 検出方式は、現在の検出プロセスに関連したアドレス範囲全体に対して使用されことに注意してください。SNMPクエリはハンドシェイクのメカニズムを提供しないUDPを使用するので、失敗を検出するタイムアウト間隔(デフォルトの値は15秒)が必要です。つまり、SNMP探索には、特に大規模ネットワークの場合、非常に時間がかかります。
この理由から、自動検出(Auto-Discovery)は SNMP 検出方式を、より高速な TCP スキャンとリンクできるようにしています。このやり方では、TCP 探索で検出されたデバイスのみが、追加の SNMP クエリでの探索を行われます(Nmap TCP 方式は、このための高速 UDP スキャンオプションを含みます)。さらに、管理者は特定タイプのプラットホームのホストに対してクエリを制限することもできるので、すべてのデバイス上のネットワークインタフェースを列挙しなくて済ますことができます。この処理について詳しくは、上述のNmap検出方式のセクションを参照ください。
下図は、予めロードする値がない SNMP タイプの検出方式のための検出方式エディタを示します。
注意: 多くの場合、コミュニティーストリングはセキュリティ的に微妙なので、自動検出からは SNMP コミュニティーストリングを自動構成設定には渡しません。あるコミュニティーストリングの中にはあるが、他のコミュニティーストリングの中にはないOIDに対して、コミュニティーストリングを区別することが必要なカスタムの自動検出メカニズムを推奨します。
図:SNMP検出方式
SNMP検出方式エディタのオプションとフィールドは、下記のようになります:
表:SNMP検出方式エディタのオプションとフィールド
SNMP Version |
SNMP検出方式は、SNMPのバージョン1、2cと3をサポートします。SNMPのバージョン1は、最も簡単で最も広くサポートされていますが、バージョン2cの持ついくつかの効率の良さが欠けており、そしてバージョン3は最高のセキュリティを提供します。デフォルトではSNMP検出方式は、SNMPバージョン2cを使い、お客様のネットワークデバイスがバージョン3を使うように設定されていると知っていない限りそのバージョン2cを使用するべきです。 |
SNMP v3 |
SNMP v3のフィールドは、バージョン3が選ばれるまで無効です。バージョン3を使用している場合、SNMP v3フィールドに認証情報を入れる必要があります。 |
Community Strings |
このフィールドは、バージョン1や2が選ばれない限り無効です。バージョン1や2を使っている場合、調査クエリで使用する、ひとつ以上の値をコミュニティ・ストリングのフィールドに入れます。SNMPコミュニティ・ストリングは、最初から最後の順で、どれかが上手く使えるまで、あるいは、すべて試し終わるまで試されます。 |
Ranges and Filters |
検出方式エディタ画面の本セクションで特定のアドレス範囲に特定の検出方式をリンクできます。検出定義が複数のアドレス範囲に対して複数の検出方式を使用し、現在の検出方式がいくつかのアドレス範囲にのみ都合が良いのであれば、この検出方式を特定のアドレス範囲で利用できるように望むかもしれません。しかし、検出定義が指定されたすべての検出方式を使う、それらの場合においては、検出方式内で明示的にアドレスを有効にしてはいけません(その代わり、それらは実行時に検出定義によって取り込まれます)。 |
オプションとフィールドが満足する内容で満たされたら、続けるために右上部にあるSave(保存) ボタンをクリックします。この時点で、元の検出定義エディタ画面に戻るでしょう。また、該当するボタンをクリックすることで、検出方式の名称を変更したり削除することができます。
WMI 検出方式は、Windowsデバイスのディスク、メモリとCPU リソースを探索するため、Windows Management Interface の独立したスキャンを使用します。これらのスキャンには、GroundWork のWindows子サーバが必要です。詳しくは、このオプショナルなGroundWork 製品についてのドキュメントを参照ください。
下図は、あらかじめロードする値がないWMI タイプの検出方式のための検出方式エディタを示します:
図:WMI検出方式
WMI検出方式エディタ画面は、提供するためのWMIタイプのひとつのオプションだけを提供します。下記の二つの使用可能なWMIスキャンタイプがあります:
表:WMI検出方式エディタのオプションとフィールド
Server(サーバ) |
このスキャンタイプは GroundWork に Windows 子サーバから得られるすべての検出アウトプットをロードします。Windows 子サーバは、個別にこれらの結果をGroundWorkサーバにアップロードするよう構成設定する必要があります。 |
Proxy(プロキシ) |
このオプションは未実装のままです。これを選択すると何の影響もありません。 |
注意 :実際のスキャンがないので、WMI検出方式エディタ画面にはアドレス範囲の管理エリアはありません。
オプションとフィールドが満足する内容で満たされたら、続けるために右上部にあるSave(保存) ボタンをクリックします。この時点で、元の検出定義エディタ画面に戻るでしょう。また、該当するボタンをクリックすることで、検出方式の名称を変更したり削除することができます。
スクリプト 検出方式は、管理者が自分自身の検出プローブを作成するために設計されました。自動検出サブシステムは、ほとんどの一般的なネットワークサービスを見つけることができる検出方式を提供しますが、時々、管理者が自分自身の検出方式を作成したくなることがあるでしょう。そのために、考えうるほとんどどのようなデバイスについての特徴を探すためにスクリプト方式を使うことができ、そのための必要条件は Groundwork ホストがコマンドを実行できて必要な出力が返されることと、Nagios 望ましいリソースにしかるべく記述されたサービス定義を使用できることのみです。
例えば、管理者は、ホスト上で稼動するすべてのサービスを監視するのに TCP や SNMP 探索を使用する代わりに、それらホストを検出、監視するために ping 等のツールを使って現在到達可能なネットワーク上のホストを一覧にしたいと思うかもしれません。このやり方では、管理者は ping ユーティリティを呼び出す簡単なスクリプトを使って、各IPアドレスについて必要なアウトプットを出力して、その後、その結果データを使って正しい Nagios ホストとサービスプロファイルに検出されたデバイスを結び付けることができます。一度、このスクリプトがカスタムの検出方式に結び付けられたら、管理者は必要なときにはいつでも、その ping 検出方式を実行することができます。
同様に、必要なスクリプトを作成して適当な Nagios プロファイルにその出力をマッピングすることにより、AppleTalk や DECnet ットワーク上のデバイスの検出、あるいは、リモートホスト上で実行されているローカルアプリケーションの検出など、他のタイプのネットワークサービスの計測にも同じ原理を使うことができます。
ここをクリック するとこれらのポイントを明確にするための、完全に機能する検出スクリプト例を表示します。このスクリプトはターゲットデバイスに ping するのに Nagios の check_icmp ユーティリティを使い、ターゲットホストに結びついたホスト名データを調べ、そのて、検出されたデータに基づいて適切な形式で応答行を作成します。
おわかりのように、このスクリプト例は、検出処理によって Groundwork から渡される IP アドレスのための入力を読んで、ターゲットアドレスに ping するために Nagios の check_icmp コマンドを呼び出します。ターゲットのデバイスが何らかの探索に( OK や WARNING のコマンド応答によって定義されるように)応答したら、デバイス名とエイリアスを調べるために一連のホスト名調査が実施されます。最後に、そのホストとサービスプロファイルのアトリビュートが、あらかじめ準備されている値で埋められて応答データが返されます。つまり、探索に対して何の応答も上手く返さないデバイスは単に無視され、空の値の列が返されます。
このスクリプト例は、検出定義で登録されたアドレス範囲に基づいて GroundWork Monitor によって提供される各々の個別アドレスについて、各ターゲットの IP アドレスに対して一度だけ実行される点に注意してください。
GroundWork がそのスクリプトを上手く使用するには、そのスクリプトの出力が、現在の検出定義に関連してい、自動化スキーマ定義内で定義されているフィールドのレイアウトに対応している必要があります。例えば、上記のスクリプトは、使用するべき既設定のレイアウトと一致ルールを持つ、デフォルトのGroundWork スキーマ定義を使用する検出定義と共に使用されることを前提にしています。デフォルトのスキーマ定義が使用された場合、出力ファイルは後述の自動化データファイルのセクションで説明されているのと同じフィールドを含むでしょう。
そのレコードが適用される特定のホストを示すために、すべての明示されたホストレコードがホスト名と IP アドレスフィールドを含む必要があることは特に重要です。さもなければ、自動化プロセッサは、カレントのレコードが前のホストレコードの更新情報であると推察し、フィールドデータのいくつかを追加したり上書きします。同様に、そのスクリプトがその業務を実行したことを検出プロセッサが知るために、探索されるすべてのホスト毎に一行の応答データを生成する必要があります。これは、(上記のサンプルスクリプトのように)完全に空のフィールドを持つ列か、明確なホストに適用されるレコードを表すホスト名とアドレスを列に含むかのどちらかでしょう。ファイルのレイアウトルールとファイルのコンテンツがどのように分析され使用されるかについての詳細は、後述の自動化処理のセクションでの説明を参照してください。
注意:スクリプトの出力は GroundWork によってキャプチャーされ、/usr/local/groundwork/core/monarch/automation/data ディレクトリ内の検出定義名を反映した名称のファイル中に保存されます。その結果ファイル中のデータは、検出プロセスが完了した後、自動化サブシステムによってのみ処理されます
いったんスクリプトが作成されたら、それを使用するために検出方式として登録される必要があります。
下図は、あらかじめロードする値がない Script タイプ検出方式のための検出方式エディタを示します:
図: スクリプト検出方式
スクリプト検出方式エディタのオプションとフィールドは下記のとおりです:
表:Script検出方式エディタのオプションとフィールド
Script type (スクリプトタイプ) |
現在サポートされているタイプは、Customタイプのみ。 |
Run Mode (実行モード) |
実行モードのタイプは、そのスクリプトがすべての IP アドレスに対して実行されるか、あるいは検出処理中に一回だけ実行されるかを指定します。 "BatchMode(バッチモード)" チェックボックスがチェックされていなければ、そのスクリプトは、すべての IP アドレスに対して実行され、チェックされていればそのスクリプトは一回だけ実行されます。 |
Command Line (コマンドライン) |
検出方式で使用するコマンドのフルパスを指定する必要があります。スクリプトファイルは、/usr/local/groundwork/core/monarch/automation/scripts ディレクトリに保存され、 nagios ユーザがそのスクリプトの実行するのに十分なパーミッションを有する必要があります。 注:このフィールドの中で、ハードコードの引数や nagios ユーザアカウントで通常に利用可能な環境変数で、パラメータや引数を指定することができます。そのスクリプトが各ホストアドレスに対して実行される場合、その変数は $HOST$ や $user21$ などの Nagios マクロとして参照することができ、これらのマクロはコマンドラインに渡される前に GroundWork Monitor よって展開されます。しかし、スクリプトがバッチモードで実行される場合、そのマクロは展開されませんので、そのスクリプトでは使用できません |
Ranges and Filters (範囲とフィルター) |
検出方式エディタ画面のこのセクションで特定のアドレス範囲に特定の検出方式をリンクできます。検出定義が複数のアドレス範囲に対して複数の検出方式を使用し、現在の検出方式がいくつかのアドレス範囲にのみ都合が良いのであれば、この検出方式を特定のアドレス範囲で利用できるように望まれるかもしれません。しかし、その検出定義が定義されたすべての検出方式を使う場合においては、検出方式内で明示的にアドレスを有効にしてはいけません(その代わり、それらは実行時に検出定義によって取り込まれます)。 |
オプションとフィールドが満足する内容で満たされたら、続けるために右上部にあるSave(保存) ボタンをクリックします。この時点で、元の検出定義エディタ画面に戻るでしょう。また、該当するボタンをクリックすることで、検出方式の名称を変更したり削除することができます。
検出方式を削除するには、検出方式エディタ画面から実施する必要があります。
検出定義エディタ画面に行き、削除する検出方式の隣のハイパーリンク edit method(方式編集)をクリックします。
検出方式エディタ画面が開いたら右上隅の Delete(削除)ボタンをクリックします。下図のような確認ボックスが表示されるでしょう。
検出方式を削除するには、Yes(はい)ボタンをクリックして、キャンセルします。検出定義エディタ画面に戻る場合は、No(いいえ)ボタンをクリックします。
図:検出方式の削除
検出定義は、メイン検出コンソール画面と検出定義エディタ画面のどちらからでも右上端の Go>>(実行) ボタンをクリックするだけで実行することができます。実行時に自動化アクションを変更したりアドレス範囲を有効化/無効化することができ、それらの変更は開始する前に検出プロセスの中に組み込まれますが、他のオプションは使用される前に必ず保存が必要です。
検出処理が始まったとき、/usr/local/groundwork/core/monarch/automation/data の中に使用されている検出方式を元にした名称の出力ファイルが作られます。選ばれた検出処理の他のインスタンスが起動されていて処理がまだ完全に終わっていない場合、このファイルが既に存在するので、下記のような画面が表示されます。前のアウトプットを廃棄して新しい検出ジョブを始めるか、検出プロセスを飛ばして自動化プロセスにスキップするか、要求をキャンセルしてメイン検出コンソール画面に戻るかの選択ができます。
図:検出の重複
検出の処理をさらに進めると、次に、検出動作が侵入検知ソフトウェアに引っ掛ったり、他の類のセキュリティアラームを誘発するかもしれないという、下図のようなワーニング画面が表示されるでしょう。誤認警報による悪い影響を防止するため、これら処理を実施する前にネットワークセキュリティの担当者と調整する必要があるかも知れません。検出操作を続行する前にAccept (承認)のトグルを有効にして、Go>>(実行) ボタンをクリックすることで、ワーニングに対して承認をする必要があります。
図:検出実行の確認
検出プロセスが始まると、下記のようなステータス画面が表示されます。この画面は各ホストが検出され探索される毎にリアルタイムで更新されます。この際には、現在の動作をキャンセルして最初からやり直さない限り、内容の変更はできません。検出プロセスがどの位の時間で終了するかは、多くのファクター、つまり選んだアドレス範囲のサイズ、使用する検出タイプ、ネットワーク上のアクティブなノード数や多くの他のファクターで決まります。デフォルトの検出定義と関連オプションを使って小さなネットワークをスキャンするには、およそ10分かかります。
図: 検出実行中の画面
全てのIPアドレスが探索された後、Next(次へ) ボタンがアクセスできるように変わり、適切なホストやサービスプロファイルに検出したデバイスをマッチングし、必要なデータベース更新を行うことを続けることになるでしょう。詳細は、後述の 自動化サブシステム セクションで説明します。