Linux でフォワーダーをインストールして構成する

このドキュメントでは、Linux でフォワーダーをインストールして構成する方法について説明します。Windows にフォワーダーをインストールするには、Windows フォワーダーをご覧ください。

フォワーダーは、お客様の環境から Chronicle インスタンスにログを送信するために使用されます。これは、お客様がログを直接 Chronicle に送信し、Cloud バケットを使用したデータの取り込みを希望しない場合や、ログにサードパーティの API によるネイティブの取り込みがない場合に使用されます。フォワーダーは、取り込み API を手動で組み込むのではなく、すぐにデプロイできるソリューションとして使用できます。

Debian、Ubuntu、Red Hat、Suse などのさまざまな Linux ディストリビューションにフォワーダーをインストールできます。Google Cloud はフォワーダーの提供に Docker コンテナを使用します。Docker コンテナは、Linux を実行している物理マシンまたは仮想マシンで実行して、管理できます。

システム要件

一般的な最適化案は次のとおりです。システムに固有の最適化案については、Chronicle のサポートにお問い合わせください。

RAM - 収集されるデータの種類ごとに 1 GB。たとえば、エンドポイントの検出とレスポンス（EDR）、DNS、DHCP は別々のデータ型です。3 つすべてのデータを収集するには、3 GB の RAM が必要です。
CPU - 2 個の CPU は、10,000 EPS（1 秒あたりイベント数）（すべてのデータ型の合計）未満を処理するには十分です。10,000 EPS を超えるイベントを転送する予定の場合は、4～6 個の CPU をプロビジョニングします。
ディスク - Chronicle フォワーダーで処理するデータの量に関係なく、100 MB のディスク容量で十分です。バックログのメッセージをメモリではなくディスクにバッファする必要がある場合は、ディスクバッファリングをご覧ください。Chronicle フォワーダーは、デフォルトでメモリにバッファリングします。

Google IP アドレスの範囲

ファイアウォールの構成を設定するときなど、フォワーダー構成を設定するときに、IP アドレス範囲を開くことが必要な場合があります。Google では、特定の IP アドレスのリストを提供することはできません。ただし、Google の IP アドレス範囲を取得することはできます。

ファイアウォール構成を確認する

Chronicle フォワーダーコンテナとインターネット間のファイアウォールまたは認証済みプロキシには、次のホストへのアクセスを開くルールが必要です。

接続タイプ	宛先	ポート
TCP	malachiteingestion-pa.googleapis.com	443
TCP	malachiteingestion-europe-backstory.googleapis.com	443
TCP	malachiteingestion-europe-west2-backstory.googleapis.com	443
TCP	malachiteingestion-asia-southeast1-backstory.googleapis.com	443
TCP	accounts.google.com	443
TCP	gcr.io	443
TCP	storage.googleapis.com	443

構成ファイルをカスタマイズする

構成ファイルのテンプレートを取得するには、Chronicle の担当者にお問い合わせください。

出力セクションに示されているように、Google Cloud は、特定のメタデータを使用して、構成ファイルをフォワーダーインスタンスに合わせて調整します。要件に合わせて構成ファイルを変更できます。また、コレクタのセクションに取り込むログタイプに関する情報を含めることができます。構成設定の詳細については、Chronicle のサポートにお問い合わせください。

Linux フォワーダーを構成するには:

ソフトウェアに提供されている構成ファイルのテンプレートのコピーを作成します。

注: Chronicle のサポートにより、構成ファイルが提供されます。
次の命名規則を使用して、同じディレクトリに 2 つのファイルを保存します。

FORWARDER_NAME.conf - このファイルを使用して、ログの取り込みに関連する構成設定を定義します。

FORWARDER_NAME_auth.conf - このファイルを使用して、承認認証情報を定義します。
フォワーダーインスタンスの構成が含まれるようにファイルを変更します。このドキュメントのサンプルを参考にしてください。
対応する認証の詳細が入力されていない場合でも、FORWARDER_NAME_auth.conf ファイルの各入力にエントリが存在することを確認してください。これは、データを正しくマッピングするために必要です。

設定例

次のコードサンプルは、フォワーダーの構成ファイルの形式を示しています。Splunk や Syslog などの取り込みメカニズムの各タイプの設定について詳しくは、データの収集をご覧ください。

FORWARDER_NAME.conf ファイル

output:
  url: malachiteingestion-pa.googleapis.com:443
  identity:
    identity:
    collector_id: COLLECTOR_ID \
    customer_id: CUSTOMER_ID \

collectors:
  - syslog:
      common:
        enabled: true
        data_type: `WINDOWS_DHCP`
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - syslog:
      common:
        enabled: true
        data_type: `WINDOWS_DNS`
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10515
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
enable_auto_update: false

FORWARDER_NAME_auth.conf ファイル

output:
  identity:
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\\"PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/example-account-1%40example-account.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
  - syslog:
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"

この 2 つのファイルシステムにより、認証情報を別のファイルに格納してセキュリティを強化できます。FORWARDER_NAME.conf ファイルは、バージョン管理リポジトリまたは任意のオープン構成管理システムに保存できます。FORWARDER_NAME_auth.conf ファイルは、フォワーダーを実行している物理マシンまたは仮想マシンに直接保存できます。

構成例（単一のファイル）

output:
  url: malachiteingestion-pa.googleapis.com:443
  identity:
    identity:
    collector_id: "COLLECTOR_ID" \
    customer_id: "CUSTOMER_ID" \
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\ "PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/malachite-test-1%40malachite-test.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
      common:
        enabled: true
        data_type: `WINDOWS_DHCP`
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - syslog:
      common:
        enabled: true
        data_type: `WINDOWS_DNS`
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10515
      connection_timeout_sec: 60
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"
      tcp_buffer_size: 524288
enable_auto_update: false

単一の構成ファイルを使用していて、2 つのファイルシステムに移行する場合は、次の操作を行います。

既存の構成のコピーを作成します。
1 つのファイルを FORWARDER_NAME.conf ファイルとして保存し、そのファイルから承認認証情報を削除します。
もう一方のファイルを FORWARDER_NAME_auth.conf ファイルとして保存し、承認されていないデータをすべてファイルから削除します。このガイドのサンプル構成ファイルを参照用に使用します。
構成ファイルのカスタマイズで説明されている命名規則とその他のガイドラインに従ってください。

Docker のインストール

Docker のインストールはホスト環境によって異なります。Docker は別のホストオペレーティングシステムにインストールできます。Google Cloud では、いくつかの一般的な Linux ディストリビューションに Docker をインストールする際に役立つドキュメントが限られています。ただし、Docker はオープンソースであり、必要なすべてのドキュメントがすでに用意されています。Docker のインストール手順については、Docker のドキュメントをご覧ください。

Docker をシステムにインストールした後、Chronicle フォワーダーのインストールプロセスは、任意のタイプの Linux ディストリビューションと似ています。

Docker がシステムに正しくインストールされているかどうかを確認するには、次のコマンドを実行します（権限昇格）。

   docker ps

次のレスポンスは、Docker が適切にインストールされていることを示しています。

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

次のコマンドを使用して、Docker のインストールに関する追加情報を収集できます。

    docker info

Docker に問題がある場合、Chronicle のサポートチームは、このコマンドの出力をリクエストして、問題の修正とデバッグを行います。

Linux にフォワーダーをインストールする

このセクションでは、Docker コンテナを使用して Linux システムに Chronicle フォワーダーをインストールする方法について説明します。

ステップ 1. フォワーダー構成ファイルのダウンロード、転送、インストール

Chronicle は、ご使用のオペレーティングシステム（Linux または Windows）に固有のフォワーダー構成ファイルを提供します。Chronicle の担当者から提供されたリンクから、ノートパソコンのローカルディレクトリ（chronicle などのディレクトリ）にファイルをダウンロードします。以下の手順を完了したら、ノートパソコンからユーザーのホームディレクトリ内にあるフォワーダーの /opt/chronicle/config ディレクトリに構成ファイルを転送します。

ターミナルから Linux フォワーダーのホストに接続します。
Linux フォワーダーのホストで新しいユーザーを作成します。
```
  adduser USERNAME
  passwd USERNAME
  usermod -aG wheel USERNAME
```
Docker コンテナを実行する新しいユーザーのホームディレクトリに移動します。
Chronicle フォワーダーの構成ファイルを格納するディレクトリを作成します。
```
  mkdir /opt/chronicle/config
```
注: ディレクトリ名 config は例です。このディレクトリには任意の名前を指定できます。ただし、Docker 実行コマンドを実行するときは、必ず同じディレクトリ名を使用してください。
ディレクトリを移動します。
```
  cd /opt/chronicle/config
```
ファイルが転送されたら、構成ファイルが /opt/chronicle/config ディレクトリにあることを確認します。
```
  ls -l
```

ステップ 2. Docker コンテナ内でフォワーダーを実行する

次の手順に従って、Chronicle フォワーダーを初めて開始するか、Chronicle コンテナの最新バージョンにアップグレードできます。

--log-opt オプションは、Docker 1.13 以降で利用可能です。これらのオプションはコンテナログファイルのサイズを制限するものであり、Docker のバージョンがサポートしている限り、使用する必要があります。

アップグレードする場合は、まず、以前に実行した Docker をクリーンアップします。以下の例では、Docker コンテナの名前は cfps です。次のように docker pull コマンドを使用して、Google Cloud から最新の Docker イメージを取得します。
```
docker stop cfps
```
```
docker rm cfps
```
Google Cloud から最新の Docker イメージを取得します。
```
docker pull gcr.io/chronicle-container/cf_production_stable
```

Docker コンテナから Chronicle Forwarder を起動します。

docker run \
--detach \
--name cfps \
--restart=always \
--log-opt max-size=100m \
--log-opt max-file=10 \
--net=host \
-v /opt/chronicle/config:/opt/chronicle/external \
gcr.io/chronicle-container/cf_production_stable

フォワーダーをアンインストールする

以下の Docker コマンドを実行すると、Chronicle フォワーダーを停止、アンインストール、削除できます。

フォワーダーコンテナを停止またはアンインストールするには:

    docker stop cfps

フォワーダーコンテナを削除するには:

    docker rm cfps

フォワーダーを更新する

Chronicle フォワーダーには 2 つの部分があり、次のようにアップグレードされます。

フォワーダーバンドル - 自動的に更新されるため、再起動は必要ありません。
フォワーダー Docker イメージ - ステップ 2 で説明するように、既存のフォワーダーを停止し、新しいインスタンスを起動すると、手動で更新されます。

データの収集

以下のセクションでは、Chronicle インスタンスにさまざまなタイプのデータを取り込むように Chronicle フォワーダーを構成する方法について説明します。

Splunk データを収集する

Splunk のデータを Chronicle に転送するように Chronicle フォワーダーを構成できます。 Google Cloud は次の情報を使用して、Splunk からデータを転送するように Chronicle フォワーダーを構成します。

Splunk REST API の URL（例: https://10.0.113.15:8889）。
必要な各データ型（index=dns など）のデータを生成する Splunk クエリ。

FORWARDER_NAME.conf
output:
collectors:
  - splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10s
      maximum_window_size: 30s
      query_string: search index=* sourcetype=dns
      query_mode: realtime

Splunk アカウントの認証情報を Chronicle フォワーダーで利用できるようにする必要があります。これを行うには、creds.txt ファイルを作成するか、FORWARDER_NAME_auth.conf ファイルの splunk 設定セクションに user フィールドと password フィールドを追加します。次の 2 つの手順では、それぞれの方法について説明します。使用する方法は 1 つだけです。推奨される方法は、FORWARDER_NAME_auth.conf ファイルを使用することです。

FORWARDER_NAME_auth.conf ファイルを使用するには、以下に示すように、user フィールドと password フィールドを FORWARDER_NAME_auth.conf ファイルの splunk セクションに追加します。

output:
  identity:
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\\"PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/example-account-1%40example-account.iam.gserviceaccount.com"
      }

collectors:
  - splunk:
      common:
      user: myusername
      password: mypassword

minimum_window_size: Splunk クエリに渡される最小の時間範囲。デフォルト値は 10 秒です。このパラメータは、フォワーダーが安定した状態のときに Splunk サーバーにクエリを行う頻度を変更する必要がある場合に、調整に使用されます。また、遅延がある場合、Splunk API 呼び出しが複数回行われる場合があります。

maximum_window_size: Splunk クエリに渡される最大時間範囲。デフォルト値は 30 秒です。このパラメータは、遅延がある場合やクエリごとにより多くのデータが必要な場合に、調整に使用されます。

最小パラメータを変更する場合は、このパラメータを（同等以上の値に）変更します。遅延ケースは、Splunk のクエリ呼び出しが maximum_window_size よりも長い時間を要する場合に発生する可能性があります。

query_mode: 有効な値は、realtime だけです。Splunk のリアルタイム検索の詳細については、Splunk のドキュメントをご覧ください。

creds.txt ファイルを使用するには:

Splunk の認証情報のローカルファイルを作成し、creds.txt という名前を付けます。

注: 認証情報は安全に保管してください。Splunk の認証情報は、Google Cloud に転送しないでください。
最初の行にユーザー名を入力し、2 行目にパスワードを入力します。
```
cat creds.txt

myusername
mypassword
```
Chronicle フォワーダーを使用して Splunk インスタンスにアクセスする場合は、creds.txt ファイルを config ディレクトリ（構成ファイルと同じディレクトリ）にコピーします。次に例を示します。
```
cp creds.txt /opt/chronicle/config/creds.txt
```
creds.txt ファイルが正しい場所にあることを確認します。
```
ls /opt/chronicle/config
```

syslog データを収集する

Chronicle フォワーダーは、Syslog サーバーとして機能します。TCP または UDP 接続を介した syslog データの送信をサポートするアプライアンスまたはサーバーを構成して、データを Chronicle フォワーダーに転送できます。アプライアンスまたはサーバーが Chronicle フォワーダーに送信する正確なデータを制御できます。その結果、Chronicle フォワーダーがデータを Chronicle に転送できるようになります。

FORWARDER_NAME.conf 構成ファイル（Google Cloud が提供）では、転送されるデータの種類ごとにモニタリングするポートを指定します（例: ポート 10514）。Chronicle フォワーダーは、デフォルトで TCP 接続と UDP 接続の両方を受け入れます。

rsyslog を構成する

rsyslog を構成するには、各ポートのターゲット（例: 各データ型）を指定する必要があります。正しい構文については、システムのドキュメントをご覧ください。rsyslog のターゲット構成の例を次に示します。

TCP ログトラフィック: dns.* @@192.168.0.12:10514
UDP ログトラフィック: dns.* @192.168.0.12:10514

syslog 構成用の TLS の有効化

Chronicle フォワーダーへの syslog 接続用の TLS を有効にできます。Chronicle フォワーダーの構成ファイル（FORWARDER_NAME.conf）で、次の例に示すように、自己生成の証明書と証明書鍵の場所を指定します。

証明書	"/opt/chronicle/external/certs/client_generated_cert.pem"
certificate_key	"/opt/chronicle/external/certs/client_generated_cert.key"

表示された例に基づいて、次のように Chronicle フォワーダー構成ファイル（FORWARDER_NAME.conf）を変更します。

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
  tcp_address: 0.0.0.0:10515
  tcp_buffer_size: 65536
  connection_timeout_sec: 60
  certificate: "/opt/chronicle/external/certs/client_generated_cert.pem"
  certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
  minimum_tls_version: "TLSv1_3"

次の点に注意してください。

TCP バッファサイズを構成できます。デフォルトの TCP バッファサイズは 64 KB です。
connection_timeout のデフォルト値と推奨値は 60 秒です。指定した時間接続が非アクティブの場合、TCP 接続は終了します。
最小 TLS バージョンは、入力リクエストの TLS バージョンと照合されます。入力リクエストの TLS バージョンは、最小 TLS バージョンよりも大きくする必要があります。最小 TLS バージョンは、TLSv1_0、TLSv1_1、TLSv1_2、TLSv1_3 のいずれかの値にする必要があります。

構成ディレクトリの下に証明書ディレクトリを作成し、証明書ファイルを保存できます。

ファイルデータを収集する

1 つのログファイルから手動でログをアップロードする場合にこれを使用します。これは、特定のログファイルのログをバックフィルするために使用できます。

Docker コンテナから Chronicle フォワーダーを起動します。

  docker run \
    --name cfps \
    --log-opt max-size=100m \
    --log-opt max-file=10 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    -v /var/log/crowdstrike/falconhoseclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

この docker run コマンドは、読み込みボリュームをコンテナにマッピングするのに不可欠です。

この例に基づいて、Chronicle フォワーダー構成（FORWARDER_NAME.conf ファイル）を次のように変更する必要があります。

 collectors:
  - file:
       common:
         enabled: true
         data_type: CS_EDR
         data_hint:
         batch_n_seconds: 10
         batch_n_bytes: 1048576
       file_path: /opt/chronicle/edr/output/sample.txt
       filter:

パケットデータを収集する

Chronicle フォワーダーでは、Linux の libpcap を使用してネットワークインターフェースから直接パケットをキャプチャできます。libcap の詳細については、libcap - Linux マニュアルページをご覧ください。

パケットはキャプチャされ、ログエントリではなく Chronicle に送信されます。パケットキャプチャはローカルインターフェースからのみ処理されます。システムのパケットキャプチャを有効にするには、Chronicle のサポートにお問い合わせください。

Google Cloud は、パケットをキャプチャするために使用される Berkeley Packack Filter（BPF）式を使用して Chronicle フォワーダーを構成します（たとえば、localhost ではなく、ポート 53）。詳しくは、Berkeley パケットフィルタをご覧ください。

Kafka トピックからデータを収集する

Syslog と同様に、Kafka トピックからデータを取り込めます。コンシューマグループを活用することで、最大 3 つのフォワーダーをデプロイし、同じ Kafka トピックからデータを pull できます。詳細については、Kafka をご覧ください。

Kafka 消費者グループの詳細については、https://docs.confluent.io/platform/current/clients/consumer.html をご覧ください。

構成例: Kafka の入力

次のフォワーダー構成は、Kafka トピックからデータを取り込むようにフォワーダーを設定する方法を示しています。

FORWARDER_NAME.conf ファイル

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60s
      brokers: ["broker-1:9092", "broker-2:9093"]
      tls:
        insecureSkipVerify: true
        certificate: "/path/to/cert.pem"
        certificate_key: "/path/to/cert.key"
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

FORWARDER_NAME_auth.conf ファイル

collectors:
- kafka:
      username: user
      password: password
- syslog:

オプションの構成をカスタマイズする

データ圧縮を切り替える

ログ圧縮により、ログを Chronicle に転送する際のネットワーク帯域幅の使用量が削減されます。ただし、圧縮によって CPU 使用率が増加する場合があります。 CPU 使用率と帯域幅のトレードオフは、ログデータのタイプ、データの圧縮率、フォワーダーを実行しているホスト上の CPU サイクルの可用性、ネットワーク帯域幅の使用量の削減の必要性など、さまざまな要因によって決まります。

たとえば、テキストベースのログは圧縮率が高く、低い CPU 使用率によって帯域幅を大幅に削減できます。一方、未加工のパケットの暗号化されたペイロードは圧縮率が低く、CPU 使用率が高くなります。

デフォルトでは、ログ圧縮は無効になっています。ログ圧縮を有効にすると、帯域幅の消費が減少する可能性があります。ただし、ログ圧縮を有効にすると CPU 使用率も増加する可能性があります。トレードオフに注意してください。

ログ圧縮を有効にするには、次の例に示すように、Chronicle フォワーダー構成ファイルの compression フィールドを true に設定します。

FORWARDER_NAME.conf ファイル

output:
  compression: true
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
...

FORWARDER_NAME_auth.conf ファイル

output:
  identity:
    secret_key: |
    {
     "type": "service_account",
...
    }

ディスクバッファリングを構成する

ディスクバッファリングを使用すると、バックログにあるメッセージをメモリではなくディスクにバッファ保存できます。バックログにあるメッセージは、フォワーダーがクラッシュした場合や基盤となるホストがクラッシュした場合に保存されます。ディスクバッファリングを有効にするとパフォーマンスに影響する可能性があるので注意してください。

ディスクバッファリングが無効になっている場合、フォワーダーは、ログタイプごとに（たとえば、コネクタごとに）1 GB のメモリ（RAM）を使用します。max_memory_buffer_bytes 構成パラメータを指定します。最大許容サイズは 4 GB です。

Docker を使用してフォワーダーを実行している場合は、分離の目的のため、構成ボリュームとは別のボリュームをマウントすることをおすすめします。また、競合を避けるために、各入力を独自のディレクトリまたはボリュームで分離するべきです。

構成例: ディスクバッファリング

次の構成には、ディスクバッファリングを有効にする構文が含まれています。

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # /buffers/NIX_SYSTEM is part of the external mounted volume for the
forwarder
      write_to_disk_dir_path: /buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

正規表現フィルタを設定する

正規表現フィルタを使用すると、正規表現と未加工のログの照合に基づいてログをフィルタできます。

フィルタでは https://github.com/google/re2/wiki/Syntax で説明されている RE2 構文を使用します。

フィルタには正規表現を含める必要があります。また、必要に応じて、一致した場合の動作を定義します。一致のデフォルトの動作は「ブロック」です（ブロックとして明示的に構成できます）。

または、allow の動作を指定してフィルタを指定することもできます。allow フィルタを指定すると、フォワーダーによって、少なくとも 1 つの allow フィルタに一致しないログがブロックされます。

任意の数のフィルタを定義できます。ブロックフィルタは、allow フィルタよりも優先されます。

フィルタを定義するときに、名前を割り当てる必要があります。アクティブなフィルタの名前は、フォワーダーのヘルス指標を介して Chronicle に報告されます。構成のルートで定義されたフィルタは、コレクタレベルで定義されたフィルタと統合されます。名前が競合する場合は、コレクタレベルのフィルタが優先されます。ルートレベルまたはコレクタレベルでフィルタが定義されていない場合、この動作はすべて許可されます。

構成例: 正規表現フィルタ

次のフォワーダー構成では、ルートフィルタ（allow_filter）に一致しない WINEVTLOG ログがブロックされます。正規表現では、フィルタでは 0 から 99 の間の優先度を持つログのみが許可されます。ただし、「foo」または「bar」を含む NIX_SYSTEM ログは、allow_filter にかかわらずブロックされます。これは、フィルタでは論理 OR が使用されているためです。フィルタがトリガーされるまで、すべてのログが処理されます。

regex_filters:
  allow_filter:
    regexp: ^<[1-9][0-9]?$>.*$
    behavior_on_match: allow
collectors:
- syslog:
    common:
      regex_filters:
        block_filter_1:
          regexp: ^.*foo.*$
          behavior_on_match: block
        block_filter_2:
          regexp: ^.*bar.*$
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

任意のラベルを構成する

ラベルは、キーと値のペアを使用してログに任意のメタデータを追加するために使用されます。ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が指定されている場合、ラベルには、フォワーダーキーが重複する場合にコレクタのキーが優先してマージされます。

構成例: 任意のラベル

次のフォワーダー構成では、「foo=bar」と「meow=mix」のキーと値のペアの両方が WINEVTLOG ログにアタッチされ、「foo=baz」と「meow=mix」のキーと値のペアが NIX_SYSTEM のログにアタッチされます。

metadata:
  labels:
    foo: bar
    meow: mix
collectors:
syslog:
    common:
      metadata:
        labels:
          foo: baz
          meow: mix
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

名前空間を構成する

名前空間ラベルを使用して、異なるネットワークセグメントのログを識別し、重複する IP アドレスの競合を解決します。名前空間ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が含まれている場合、特定のコレクタの名前空間が優先されます。

フォワーダーに構成された名前空間は、関連するアセットとともに Chronicle のユーザーインターフェースに表示されます。Chronicle の検索機能を使用して名前空間を検索することもできます。

Chronicle のユーザーインターフェースで名前空間を表示する方法については、こちらをご覧ください。

構成例: 名前空間

次のフォワーダー構成では、WINEVTLOG ログが FORWARDER 名前空間にアタッチされ、NIX_SYSTEM ログが CORPORATE 名前空間にアタッチされます。

metadata:
  namespace: FORWARDER
collectors:
- syslog:
      common:
        metadata:
          namespace: CORPORATE
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      tcp_address: 0.0.0.0:30000
      connection_timeout_sec: 60
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

ロードバランシングと高可用性のオプションを構成する

Linux 用の Chronicle フォワーダーは、データソースとフォワーダーインスタンスの間にレイヤ 4 ロードバランサがインストールされている環境にデプロイできます。これにより、お客様は複数のフォワーダー間でログ収集を分散したり、フォワーダーに失敗した場合に別のフォワーダーにログを送信したりできます。この機能は、syslog コレクションタイプでのみサポートされています。

Linux フォワーダーには、ロードバランサからの HTTP ヘルスチェックに応答する組み込み HTTP サーバーが含まれています。また、HTTP サーバーは、フォワーダーの起動またはシャットダウン中にログが失われるのを防ぐこともできます。

フォワーダー構成ファイルの server セクションで、HTTP サーバー、ロードバランシング、高可用性オプションを構成します。これらのオプションは、コンテナスケジューラやオーケストレーションベースのデプロイで受信されるヘルスチェックや、従来のロードバランサで受信されるヘルスチェックに応じて返されるタイムアウト期間とステータスコードの設定をサポートします。

次の URL パスを使用して、ヘルス、readiness、liveness のチェックを行います。 <host:port> 値は、フォワーダー構成で定義されます。

http://<host:port>/meta/available: Kubernetes などのコンテナスケジューラ / オーケストレーターの liveness チェック。
http://<host:port>/meta/ready: readiness チェックと従来のロードバランサのヘルスチェック。

次のフォワーダー構成は、ロードバランシングと高可用性の例です。

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503

構成パス	説明
server : graceful_timeout	フォワーダーが不適切な readiness やヘルスチェックを返していながら新しい接続を引き続き受け入れている時間。これは、停止する信号を受信してから実際にサーバー自体のシャットダウンが開始されるまで、待機する時間でもあります。これにより、ロードバランサがプールからフォワーダーを削除する時間を確保できます。
server : drain_timeout	アクティブな接続がサーバーによって閉じられる前に、独自に正常に終了するまでフォワーダーが待機する時間。
server : http : port	HTTP サーバーがロードバランサからのヘルスチェックをリッスンするポート番号。1024 ～ 65535 にする必要があります。
server : http : host	IP アドレス、または、サーバーがリッスンする IP アドレスに解決できるホスト名。空の場合、デフォルト値はローカルシステム（0.0.0.0）です。
server : http : read_timeout	HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。ヘッダーと本文の両方のリクエスト全体の読み取りが許可される最大時間。read_timeout と read_header_timeout の両方を設定できます。
server : http : read_header_timeout	HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。リクエストヘッダーの読み取りが許可される最大時間。ヘッダーの読み取り後に、接続の読み取り期限がリセットされます。
server : http : write_timeout	HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。レスポンスの送信に許可される最大時間。新しいリクエストヘッダーが読み取られるとリセットされます。
server : http : idle_timeout	HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。アイドル状態の接続が有効である場合に、次のリクエストを待機する最大時間。idle_timeout が 0 の場合は、read_timeout の値が使用されます。両方がゼロの場合、read_header_timeout が使用されます。
routes : meta : ready_status	次のいずれかの状況でトラフィックを受け入れる準備ができた場合に、フォワーダーが返すステータスコード。準備チェックは、Kubernetes などのコンテナスケジューラまたはオーケストレーターから受信されます。ヘルスチェックは、従来のロードバランサから受信されます。
routes : meta : unready_status	トラフィックを受け入れる準備ができていない場合に、フォワーダーが返すステータスコード。
routes : meta : available_status	実行チェックが受信され、フォワーダーが利用可能な場合に、フォワーダーが返すステータスコード。Kubernetes などのコンテナのスケジューラ / オーケストレーターは、多くの場合、liveness チェックを行います。

よくある質問

フォワーダーを更新するにはどうすればよいですか？

Windows フォワーダーは、使用するお客様が少ないため、常に更新されるわけではありません。Linux フォワーダーは、Docker イメージのシェルスクリプトによって常に更新されるため、実行可能ファイルを提供する必要はありません。ただし、お客様がサポートケースを開いてフォワーダーの最新の Windows 実行可能ファイルを入手した場合は、サポートチームがサポートポータルを通じて EXE ファイルをお客様に提供します。

Docker コンテナとは何か教えてください。

Docker コンテナは、追加のセキュリティ、分離、リソース管理を提供する仮想マシンのようなものです。
仮想マシン - 特権スペース（Linux カーネル）とユーザースペース（libc、python、ls、tcpdump などを操作するすべてのもの）があります。
コンテナ - ユーザースペース（libc、python、ls、tcpdump などを操作するすべての）のみがあり、ホストの特権スペースに依存します。

コンテナを使用して Chronicle フォワーダーが配布される理由を教えてください。

分離によってセキュリティを強化します:
- お客様の環境と要件は、Chronicle フォワーダーには影響しません。
- Chronicle フォワーダーの環境と要件は、お客様には影響しません。
- コンテナ配布メカニズムはすでに存在しており、非公開にして、Google Cloud とお客様向けに分けることができます: https://cloud.google.com/container-registry/

コンテナに対応しているのが Linux のみであるのはなぜですか。Windows についてどうですか？

コンテナは最初に Linux 用に開発され、現在本番環境に対応しています。
コンテナの Windows サポートが進行中です。コンテナは Windows Server 2016 と Windows 10 で使用できます。

高度な Docker コマンドを使用する必要はありますか？

Chronicle フォワーダーは単一のコンテナを使用するため、Swarm、オーケストレーション、Kubernetes、その他の高度な Docker のコンセプトやコマンドについて学ぶ必要はありません。

Linux でフォワーダーをインストールして構成する

システム要件

Google IP アドレスの範囲

ファイアウォール構成を確認する

構成ファイルをカスタマイズする

設定例

構成例（単一のファイル）

Docker のインストール

Linux にフォワーダーをインストールする

ステップ 1. フォワーダー構成ファイルのダウンロード、転送、インストール

ステップ 2. Docker コンテナ内でフォワーダーを実行する

フォワーダーをアンインストールする

フォワーダーを更新する

データの収集

Splunk データを収集する

syslog データを収集する

rsyslog を構成する

syslog 構成用の TLS の有効化

ファイルデータを収集する

パケットデータを収集する

Kafka トピックからデータを収集する

構成例: Kafka の入力

オプションの構成をカスタマイズする

データ圧縮を切り替える

ディスク バッファリングを構成する

構成例: ディスク バッファリング

正規表現フィルタを設定する

構成例: 正規表現フィルタ

任意のラベルを構成する

構成例: 任意のラベル

名前空間を構成する

構成例: 名前空間

ロード バランシングと高可用性のオプションを構成する

よくある質問

ディスクバッファリングを構成する

構成例: ディスクバッファリング

ロードバランシングと高可用性のオプションを構成する