DNS アクティビティの構成 - BlueCat Integrity - 9.5.0

以下のセクションでは、DNS アクティビティを構成する手順について説明します。

1. 構成ドロップダウン メニューから、構成の 1 つを選択します。
2. [サーバ] タブを選択します。タブは最後に作業したページを記憶するので、もう一度タブを選択して、[構成情報] ページにいることを確認します。
3. [サーバ] で、BDDS の名前をクリックします。サーバの [詳細] タブが開きます。
4. サーバ名メニューをクリックし、[サービス構成] を選択します。
5. [サービス タイプ] ドロップダウン メニューの [正常性テレメトリ] セクションで、[DNS アクティビティ] を選択します。Address Manager はサーバにクエリを実行して、サービス設定の現在の値を返します。
6. [一般設定] で以下のパラメータを設定します。
   • DNS アクティビティの有効化: このチェックボックスを選択すると、DNS アクティビティが有効になります。このチェックボックスを選択解除すると、DNS アクティビティが無効になります。
     注: DNS アクティビティを有効にすると、DNS/DHCP サーバでファイアウォール ルールが変更され、指定された URI エンドポイントへのエグレスが許可されます。指定された IP アドレスに送信トラフィックが許可されます。
     重要: DNS アクティビティ サービスを有効にすると、リソースが集中的に消費され、DNS/DHCP サーバのパフォーマンスが影響を受ける可能性があります。
   • 出力タイプ: DNS アクティビティ データの記録場所を選択します。データを HTTP エンドポイント、Splunk サーバ、Kafka クラスタ、または Elasticsearch サーバにデータ ログを記録できます。
     [HTTP] を選択する場合、以下のフィールドが表示されます。

     • 出力 URI: DNS クエリおよび応答情報を使用する予定の HTTP エンドポイントの URI を入力します。
       注:

       • このフィールドにエンドポイントの IP アドレスを入力することを推奨します。ホスト名を入力する場合、別の DNS サーバをそのホストのリゾルバとして使用する必要があります。DNS アクティビティを構成する場所の DNS/DHCP サーバは、クライアント用リゾルバとして使用することもできますが、独自の OS 関連参照用リゾルバとして使用することはできません。
       • URI でドメイン名が使用されている場合、DNS/DHCP サーバでドメイン名を解決できることを確認する必要があります。
       • [出力 URI] フィールドの URI は、RFC2396 で定められる形式に従う必要があります。
     • ベアラ トークン (オプション): HTTP エンドポイントの認証に使用されるベアラ トークンを入力します。
     • 正常性チェック: このチェックボックスを選択すると、正常性チェック サービスが有効になります。このチェックボックスを選択解除すると、正常性チェック サービスが無効になります。初期化時、正常性チェックは、ダウンストリーム サービスがアクセス可能で、DNS クエリ データを受け入れることができることを確認します。
     • 正常性チェック URI: 正常性チェック情報を使用する予定の HTTP エンドポイントの URI を入力します。
       注: [正常性チェック URI] フィールドの URI は、RFC2396 で定められる形式に従う必要があります。
     [Splunk] を選択する場合、以下のフィールドが表示されます。

     • ホスト: Splunk HEC ホストの URI を入力します。Splunk Enterprise の HEC URI の標準形式は、次のとおりです。

       <protocol>://<FQDN or IP address of the host only>:<port>

       注:

       • このフィールドにエンドポイントの IP アドレスを入力することを推奨します。ホスト名を入力する場合、別の DNS サーバをそのホストのリゾルバとして使用する必要があります。DNS アクティビティを構成する場所の DNS/DHCP サーバは、クライアント用リゾルバとして使用することもできますが、独自の OS 関連参照用リゾルバとして使用することはできません。
       • URI でドメイン名が使用されている場合、DNS/DHCP サーバでドメイン名を解決できることを確認する必要があります。
       • いかなる要素の追加または省略なく、上の説明で規定される HEC URI 形式に正確に従っていることを確認します。ポートは必須です。例えデフォルトでも指定してください。URI にはスラッシュやフォルダを追加しないでください。
       • [ホスト] フィールドの URI は、RFC2396 で定められる形式に従う必要があります。
     • トークン: Splunk HEC トークンを入力します。
     • 正常性チェック: このチェックボックスを選択すると、正常性チェック サービスが有効になります。このチェックボックスを選択解除すると、正常性チェック サービスが無効になります。初期化時、正常性チェックは、ダウンストリーム サービスがアクセス可能で、DNS クエリ データを受け入れることができることを確認します。
       注: このチェックボックスを選択すると、DNS/DHCP サーバは /services/collector/health/1.0 でデフォルトの Splunk 正常性チェック エンドポイントを使用します。
     [Kafka] を選択する場合、以下のフィールドが表示されます。

     • トピック: イベント書き込み先の Kafka トピックの名前を入力します。
     • ブートストラップ サーバ: ホストとポートのペアをコンマ区切りで入力します。このリストは、Kafka クライアントが初めてブートストラップする際にその接続先となる「ブートストラップ」 Kafka クラスタ内の Kafka Broker のアドレスです。このフィールドは、IPv4、IPv6、FQDN 値をサポートします。

       例:10.14.22.123:9092,10.14.23.332:9092

       注:

       • このフィールドには IP アドレスを入力することを推奨します。ホスト名を入力する場合、別の DNS サーバをそのホストのリゾルバとして使用する必要があります。DNS アクティビティを構成する場所の DNS/DHCP サーバは、クライアント用リゾルバとして使用することもできますが、独自の OS 関連参照用リゾルバとして使用することはできません。
       • Kafka ブローカーのアドレスに http または https を含めないでください。
       • ドメイン名が使用されている場合、DNS/DHCP サーバでドメイン名を解決できることを確認する必要があります。
     • 鍵フィールド (オプション): トピック鍵に使用するログ フィールド名またはタグ鍵を入力します。ログまたはタグ内にフィールドがない場合、空の値が使用されます。指定しない場合、鍵は送信されません。Kafka は、鍵のハッシュを使用してパーティションを選択するか、レコードに鍵が含まれない場合はラウンドロビン方式を使用します。
     • 正常性チェック: このチェックボックスを選択すると、正常性チェック サービスが有効になります。このチェックボックスを選択解除すると、正常性チェック サービスが無効になります。初期化時、正常性チェックは、ダウンストリーム サービスがアクセス可能で、DNS クエリ データを受け入れることができることを確認します。
       注: 正常性チェック URI は Kafka Broker アドレスに基づいて構成されます。
     [Elasticsearch] を選択する場合、以下のフィールドが表示されます。

     • エンドポイント: ログ送信先の Elasticsearch エンドポイントを入力します。このフィールドは、IPv4、IPv6、FQDN 値をサポートします。

       例: http://10.24.32.122:9000

       例: https://example.com

       例: https://user:password@example.com

       注:

       • このフィールドには、エンドポイントの IP アドレスを入力することを推奨します。ホスト名を入力する場合、別の DNS サーバをそのホストのリゾルバとして使用する必要があります。DNS アクティビティを構成する場所の DNS/DHCP サーバは、クライアント用リゾルバとして使用することもできますが、独自の OS 関連参照用リゾルバとして使用することはできません。
       • ドメイン名が使用されている場合、DNS/DHCP サーバでドメイン名を解決できることを確認する必要があります。
     • 索引: イベントの書き込み先の Elasticsearch 索引名を入力します。
     • ユーザ: 基本認証ユーザ名を入力します。
     • パスワード: 基本認証パスワードを入力します。
     • 正常性チェック: このチェックボックスを選択すると、正常性チェック サービスが有効になります。このチェックボックスを選択解除すると、正常性チェック サービスが無効になります。初期化時、正常性チェックは、ダウンストリーム サービスがアクセス可能で、DNS クエリ データを受け入れることができることを確認します。
       注: 正常性チェック URI は Elasticsearch インスタンスに基づいて構成されます。
   • TLS オプション: TLS オプションを構成するには、このチェックボックスを選択します。
     重要: 出力を構成するとき、[出力 URI]、[正常性チェック URI]、[ホスト]、[ブートストラップ サーバ]、または [エンドポイント] フィールドに HTTPS エンドポイントを入力する場合、このチェックボックスを選択し、TLS 情報を入力する必要があります。
     • [CA 証明書のアップロード] で [参照] をクリックし、リモート ホストの TLS サーバ証明書で CA 署名の認証に使用される CA 証明書 (信頼されたサードパーティまたは自己署名済み) を見つけます。
       注: CA 証明書または証明書バンドルを格納しているファイルは、PEM 形式でなければなりません。TLS ハンドシェイクの成功を確実にするためには、クライアント (BDDS) にアップロードされた CA 証明書は、サーバによって TLS サーバ証明書の CA 署名の認証に使用される CA 証明書 (および該当する場合は中間証明書) と同じでなければなりません。CA 証明書は、ブラウザ エクスポートまたはその他の信頼できるソースから取得し、PEM 形式に変換できます。
     • [アップロード] をクリックして CA 証明書をアップロードします。
     • アップロードされた CA 証明書とリモート ホストの TLS サーバ証明書を使用して TLS ハンドシェイクを試みる場合は、[証明書を確認] チェックボックスを選択します。
       注: [証明書を確認] は、アップロードされた証明書の信頼性を確認しません。このコンテキストにおいて [証明書を確認] は、有効なハンドシェイクを作成するために CA 証明書が正しく TLS サーバ証明書に一致するかどうかのみを確認します。
       注: [証明書を確認] でエラーが発生したら、場合によっては DNS/DHCP サーバで CA/チェーン CA 証明書を手動でインストールする必要があります。手動インストール手順については、BlueCat カスタマー ケア ポータルで KB-17944 を参照してください。
     • TLS ハンドシェイク時にサーバ証明書の CN (一般名) または SAN (サブジェクトの別名) に対して、URI のホスト名部分を検証するには、[ホスト名の検証] チェックボックスを選択します。
       注: 自己署名済み証明書を使用する場合、サブジェクトの別名と IP アドレス (RFC 5280 4.2.1.6 を参照) を追加するか、[ホスト名の検証] チェックボックスを無効にすることを推奨します。
7. [バッファ] で以下のパラメータを設定します。
   重要: DNS/DHCP サーバ v9.4.0 以降におけるバッファ設定の変更

   DNS/DHCP サーバ v9.4.0 からは、Disk バッファ設定が使用できなくなりました。これまでに DNS/DHCP サーバ v9.3.0 で Disk バッファ設定を使用して DNS アクティビティ サービスを構成済みで、DNS/DHCP サーバ v9.4.0 以降にアップグレードする場合、DNS アクティビティ サービスを再構成するとバッファ設定は Memory に更新されます。

   • 最大イベント数: メモリ バッファ内に保存される DNS イベントの最大数を入力します。イベントの最大値は 64,000,000 です。
     注: このフィールドには、可能な限り最高の DNS/DHCP サーバに送信可能なクエリ毎秒 (QPS) およびエンドポイントのイベント処理速度に基づいて、値を入力できます。例えば、ご使用の環境で可能な限り最高の QPS が 20,000 QPS の場合、このフィールドの値を 200,000 に設定すると、エンドポイントのクエリ処理速度が遅い場合に 10 秒のイベントが DNS アクティビティ バッファに保存されます。
8. [フィルタ (オプション)] で以下のパラメータを設定します。
   注: 最大 10 個の除外フィルタを設定できます。

   • 除外するカテゴリ: ログから除外する DNS イベントのカテゴリを選択します。DNS イベントは、[ドメイン名]、[クエリ]、[応答]、[ソース アドレス] に基づいて除外できます。
     注:

     • サブカテゴリを [すべて] および [応答] 除外カテゴリに設定し、同じ DNS アクティビティ構成でサブカテゴリを [すべて] に設定して、[クエリ] 除外カテゴリを構成することはできません。
     • [クエリ] または [応答] カテゴリを使用してコンテンツにフィルタをかけると、イベント メッセージが生成されない場合があります。詳しくは、「シナリオ:DNS アクティビティ イベント メッセージが生成されない」を参照してください。
   • サブカテゴリ: ログから除外する DNS メッセージ タイプを選択します。このフィールドは、[クエリ] または [応答] を [除外するカテゴリ] として選択すると表示されます。
     除外するように構成可能な DNS メッセージ タイプは以下のとおりです。

     • すべて: メッセージ タイプに関係なく、すべてのクエリまたは応答を除外します。
     • クライアント: クライアント クエリまたは応答を除外します。
     • Auth: 権威クエリまたは応答を除外します。
     • リゾルバ: リゾルバ クエリまたは応答を除外します。
     • フォワーダ: フォワーダ クエリまたは応答を除外します。
     • 更新: 更新クエリまたは応答を除外します。

     DNS メッセージ タイプの詳細については、「参考:DNS アクティビティ イベント メッセージ例」を参照してください。

   • ドメイン名: 記録対象から除外するドメイン名を入力します。このフィールドは、[ドメイン名] を [除外するカテゴリ] として選択すると表示されます。
     注: ドメイン名がサポートするのは、左端のワイルドカード文字のみです。例: *.example.com または *-host.example.com。
   • ソース アドレス: 記録対象から除外する IPv4 または IPv6 ブロックを CIDR 表記で入力します。例: 192.0.2.0/24 または 2001:6789::/64。このフィールドは、[クエリ アドレス] を [除外するカテゴリ] として選択すると表示されます。

   重要:

   • フィルタ除外は、表示順に基づいて実行されます。[上に移動]、[下に移動]、[削除] を使用すると、リストのコンテンツと除外の実行順序を変更できます。コンテンツを除外する際は、小さい範囲から大きい範囲へ行うことを推奨します。例えば、クエリの除外は、上位レベル ドメインと下位レベル ドメインを除外する前に、リストの上位に表示されます。
   • 同じ [除外するカテゴリ] のフィルタ除外は、除外カテゴリの初回出現に基づいて適用される場合にはグループ化されます。例えば、以下のフィルタが [フィルタ (オプション)] セクションに追加される場合:
     • ソース アドレス 10.10.10.0/24
     • クエリ クライアント
     • ドメイン名 = www.example.com
     • ソース アドレス 10.10.11.0/24
     フィルタは以下のように適用されます。
     • ソース アドレス 10.10.10.0/24, 10.10.11.0/24
     • クエリ クライアント
     • ドメイン名 = www.example.com
9. [更新] をクリックします。
   [更新] をクリックしても、DNS/DHCP サーバに DNS サービスがデプロイされなかった場合、DNS アクティビティ イベントが発生するには、DNS/DHCP サーバで DNS デプロイメントを実行する必要があります。DNS サービスがすでに DNS/DHCP サーバで構成済みの場合、[更新] をクリックすると DNS アクティビティ サービスが有効になります。

   [DNS アクティビティ ステータス] で、DNS アクティビティ ログが DNS/DHCP サーバで実行中であるかどうかを確認できます。

   このサービスは、構成された宛先へ送信されるデータをバッチ処理します。バッチの期間が 1 秒に到達するか、バッチのサイズが 1049000 バイトに到達すると、バッチはシステムからフラッシュされ、構成された宛先へ送信されます。

   サービスが HTTP 応答ステータス コード 429 または 500 以降 (501 を除く) を受信すると、サービスは失敗した要求の送信を 5 回再実行しようと試みます。5 回再実行してもサービスがまだ失敗した要求を送信できない場合、イベント メッセージは削除され、エラー メッセージが記録されます。