Linux 用 Google Security Operations フォワーダー

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

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

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

システム要件

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

RAM: Google Security Operations の取り込みのために収集されるデータタイプ（コレクタ）ごとに 1 GB。たとえば 4 つの異なるコレクタを指定した場合、4 つのコレクタすべてのデータを収集するためには 4 GB の RAM が必要になります。
CPU: 2 個の CPU は、10,000 EPS（1 秒あたりイベント数）（すべてのデータ型の合計）未満を処理するには十分です。10,000 EPS を超えるイベントを転送する予定の場合は、4～6 個の CPU をプロビジョニングします。
ディスク: Google Security Operations フォワーダーで処理するデータの量に関係なく、100 MB のディスク容量で十分です。バックログにあるメッセージをメモリではなくディスクにバッファリングする必要がある場合は、ディスクバッファリングをご覧ください。Google Security Operations フォワーダーは、デフォルトでメモリにバッファリングします。

Google IP アドレスの範囲

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

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

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

接続タイプ	宛先	ポート
TCP	malachiteingestion-pa.googleapis.com	443
TCP	asia-northeast1-malachiteingestion-pa.googleapis.com	443
TCP	asia-south1-malachiteingestion-pa.googleapis.com	443
TCP	asia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	australia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	europe-malachiteingestion-pa.googleapis.com	443
TCP	europe-west2-malachiteingestion-pa.googleapis.com	443
TCP	europe-west3-malachiteingestion-pa.googleapis.com	443
TCP	europe-west6-malachiteingestion-pa.googleapis.com	443
TCP	me-central2-malachiteingestion-pa.googleapis.com	443
TCP	me-west1-malachiteingestion-pa.googleapis.com	443
TCP	northamerica-northeast2-malachiteingestion-pa.googleapis.com	443
TCP	accounts.google.com	443
TCP	gcr.io	443
TCP	oauth2.googleapis.com	443
TCP	storage.googleapis.com	443

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

Google Cloud は、出力セクションに示されているように、構成ファイルを特定のメタデータを使用してフォワーダーインスタンスに合わせて調整します。要件に応じて構成ファイルをダウンロードし、コレクタセクションに取り込むログタイプに関する情報を追加できます。構成の詳細については、構成設定のリファレンスをご覧ください。

Linux フォワーダーを構成する

UI を使用して Linux フォワーダーを構成するには、Google SecOps UI を使用してフォワーダー構成を管理するをご覧ください。

Linux フォワーダーを手動で構成するには、次のことを行います。

ソフトウェアに付属の構成ファイルテンプレートのコピーを作成します。
UI を使用して構成ファイルをダウンロードします。
次の命名規則を使用して、2 つのファイルを同じディレクトリに保存します。

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

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

構成ファイルに加えられた変更は、フォワーダーによって 5 分以内に自動的に適用されます。

設定例

次のコードサンプルは、フォワーダーの構成ファイルの形式を示しています。取り込み方法のタイプ（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

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

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

既存の構成のコピーを作成します。
1 つのファイルを FORWARDER_NAME.conf ファイルとして保存し、そのファイルから認証情報を削除します。
他のファイルを FORWARDER_NAME_auth.conf ファイルとして保存し、ファイルからすべての非承認データを削除します。このガイドで提供されているサンプル構成ファイルをリファレンスとして使用します。
構成ファイルをカスタマイズするセクションに記載されている命名規則と他のガイドラインを必ず遵守してください。

Docker のインストール

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

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

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

   docker ps

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

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

便利な Docker コマンド

次のコマンドを使用して、Docker のインストールに関する追加情報を収集できます。
```
docker info
```
Docker サービスはデフォルトで無効にできる。無効になっているかどうかを確認するには、次のコマンドを実行します。
```
systemctl is-enabled docker
```

Docker サービスを有効にしてすぐに開始するには、次のいずれかのコマンドを実行します。

sudo systemctl enable --now docker

sudo systemctl enable /usr/lib/systemd/system/docker.service

出力:

Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service

フォワーダーを起動したら、次のコマンドを実行して、フォワーダーを自動再起動に設定します。
```
sudo docker run --restart=always `IMAGE_NAME`
```
IMAGE_NAME は、フォワーダーのイメージ名です。

Docker サービスのステータスと詳細を確認するには、次のコマンドを実行します。

sudo systemctl status docker

出力:

● docker.service - Docker Application Container Engine
    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
    Active: active (running) since Sat 2020-07-18 11:14:05 UTC; 15s ago
TriggeredBy: ● docker.socket
      Docs: https://docs.docker.com
  Main PID: 263 (dockerd)
      Tasks: 20
    Memory: 100.4M
    CGroup: /system.slice/docker.service
            └─263 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
Jul 18 11:14:05 swarm-kraken dockerd[263]: time="2020-07-18T11:14:05.713787002Z" level=info msg="API listen on /run/docker.sock"
Jul 18 11:14:05 swarm-kraken systemd[1]: Started Docker Application Container Engine

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

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

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

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

Google Security Operations には、ご使用のオペレーティングシステム（Linux または Windows）に固有のフォワーダー構成ファイルが用意されています。要件に応じて構成ファイルをダウンロードできます。以下の手順を完了したら、ノートパソコンからユーザーのホームディレクトリ内にあるフォワーダーの /opt/chronicle/config ディレクトリに構成ファイルを転送します。

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

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

Google Security Operations フォワーダーを初めて起動し、最新バージョンの Google Security Operations コンテナにアップグレードするには、次の手順を使用します。

--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 コンテナから Google Security Operations フォワーダーを起動します。

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

フォワーダーログを表示する

Google Security Operations フォワーダーのログを表示するには、次のコマンドを実行します。

  sudo docker logs cfps

ログが保存されているファイルのパスを表示するには、次のコマンドを実行します。

docker inspect --format='{{.LogPath}}' CONTAINER_NAME

実行中のログを表示するには、次のコマンドを実行します。

  sudo docker logs cfps -f

ログをファイルに保存するには、次のコマンドを実行します。

  sudo docker logs cfps &> logs.txt

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

次の Docker コマンドを使用すると、Google Security Operations フォワーダーの停止、アンインストール、削除ができます。

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

    docker stop cfps

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

    docker rm cfps

フォワーダーを更新する

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

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

プロキシの背後にフォワーダーをインストールする

このセクションでは、プロキシの背後に Google Security Operations フォワーダーをインストールする方法について説明します。

プロキシを使用するようにマシンを構成します。
1. /etc/resolv.conf ファイルに次の行を追加します。
```
nameserver = 10.0.0.1
nameserver = 10.0.0.2
```
2. 次の環境変数を設定します。
```
$HTTP_PROXY = http://proxy.example.com:80
$HTTPS_PROXY = https://proxy.example.com:80
```
プロキシを使用するように Docker を構成します。
1. Docker サービス用の systemd ドロップインディレクトリを作成します。
```
mkdir /etc/systemd/system/docker.service.d
```
2. 環境変数 HTTP_PROXY と HTTPS_PROXY を追加するファイル /etc/systemd/system/docker.service.d/http-proxy.conf を作成します。
```
[Service]
Environment="HTTP_PROXY=http://proxy.example.com:80/"
Environment="HTTPS_PROXY=https://proxy.example.com:80/"
```
3. 変更をフラッシュします。
```
$ sudo systemctl daemon-reload
```
4. 構成が読み込まれていることを確認します。
```
$ sudo systemctl show --property Environment docker
Environment=HTTP_PROXY=http://proxy.example.com:80/
Environment=HTTPS_PROXY=https://proxy.example.com:80/
```
5. Docker を再起動します。
```
$ sudo systemctl restart docker
```
Google Cloud から最新の Google Security Operations フォワーダー Docker イメージを取得します。
```
docker pull gcr.io/chronicle-container/cf_production_stable
```

プロキシ環境変数を追加して、Google Security Operations フォワーダーコンテナを実行します。

docker run \
--env HTTP_PROXY="http://proxy.example.com:80/" \
--env HTTPS_PROXY="https://proxy.example.com:80/" \
--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

データの収集

次のセクションは、Google Security Operations インスタンスに転送されるさまざまな種類のデータを取り込むように Google Security Operations フォワーダーを構成するのに役立ちます。

Splunk データを収集する

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

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 アカウントの認証情報を Google Security Operations フォワーダーが使用できるようにします。これはcreds.txtファイルを作成することによって可能になります。

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

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

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

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

syslog データを収集する

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

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

rsyslog を構成する

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

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

syslog 構成用の TLS の有効化

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

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

示している例に基づいて、Google Security Operations フォワーダーの構成ファイル（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 のいずれかの値にする必要があります。

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

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

ファイルコレクタはファイルからログを取得するように設計されています。このファイルは Docker コンテナにバインドする必要があります。

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

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

  docker run \
    --detach \
    --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/falconhostclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

この docker run コマンドは、負荷ボリュームをコンテナにマッピングするために重要です。

この例に基づいて、Google Security Operations フォワーダーの構成（FORWARDER_NAME.conf ファイル）を次のように変更します。sample.txt ファイルは、/var/log/crowdstrike/falconhostclient フォルダに存在する必要があります。

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

フラグ構成

skip_seek_to_end（bool）: このフラグはデフォルトで false に設定され、ファイル入力では新しいログ行のみが入力として送信されます。これを true に設定すると、フォワーダーの再起動中に、以前のすべてのログ行が再送信されます。これにより、ログが重複します。このフラグを true に設定すると、特定の状況（停止時など）で役立ちます。フォワーダーを再起動すると、欠落したログ行が再度送信されるからです。

poll（bool）: ファイルコレクタは Tail ライブラリを使用して、ファイルシステムの変更を確認します。このフラグを true に設定すると、Tail ライブラリはデフォルトの通知メソッドではなく、ポーリングメソッドを使用します。

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

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

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

Google Cloud は、パケットをキャプチャするために使用される Berkeley Packack Filter（BPF）式を使用して Google Security Operations フォワーダーを構成します（たとえば、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:

WebProxy データを収集する

Google Security Operations フォワーダーでは、Linux の libcap を使用してネットワークインターフェースから直接 WebProxy データをキャプチャできます。libcap の詳細については、libcap - Linux のマニュアルページをご覧ください。システムの WebProxy データキャプチャを有効にするには、Google Security Operations のサポートにお問い合わせください。

Google Security Operations フォワーダーの構成（FORWARDER_NAME.conf ファイル）を次のように変更します。

- webproxy:
      common:
        enabled : true
        data_type: <Your LogType>
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: any
      bpf: tcp and dst port 80

構成をカスタマイズする

次の表に、フォワーダー構成ファイルで使用される重要なパラメータを示します。

パラメータ	説明
data_type	コレクタが収集、処理できるログデータのタイプ。
メタデータ	メタデータ。グローバルメタデータをオーバーライドします。
max_file_buffer_bytes	ディスクまたはファイルバッファに蓄積できる最大バイト数。デフォルト値は `1073741824` で、1 GB です。
max_memory_buffer_bytes	メモリバッファに蓄積できる最大バイト数。デフォルト値は `1073741824` で、1 GB です。
write_to_disk_dir_path	ファイルまたはディスクバッファに使用されるパス。
write_to_disk_buffer_enabled	`true` の場合、メモリバッファの代わりにディスクバッファが使用されます。デフォルト値は `false` です。
batch_n_bytes	コレクタが累積できる最大バイト数。これを超えると、データがバッチ処理されます。デフォルト値は `1048576` で、1 MB です。
batch_n_seconds	コレクタが収集したデータがバッチ処理されるまでの秒数。デフォルト値は 11 秒です。
data_hint	コレクタが受信できるデータ形式（通常は、形式を記述したログファイルのヘッダー）。

構成ファイルで使用されるパラメータの広範なリストについては、フォワーダーの構成フィールドとコレクタの構成フィールドをご覧ください。

データ圧縮を切り替える

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

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

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

ログ圧縮を有効にするには、次の例に示すように、Google Security Operations フォワーダー構成ファイルの 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 です。

自動メモリバッファリングを構成すると、コレクタ間で動的に共有されるバッファを使用できます。これにより、トラフィックの急増に対応できます。動的に共有されるバッファを有効にするには、フォワーダー構成に次の行を追加します。

auto_buffer:
  enabled: true
  target_memory_utilization: 80

自動ディスクバッファリングが有効になっていても、target_memory_utilization が定義されていない場合は、デフォルト値の 70 が使用されます。

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 フィルタよりも優先されます。

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

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

次のフォワーダー構成では、ルートフィルタ（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 アドレスの競合を解決します。名前空間ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が含まれている場合、特定のコレクタの名前空間が優先されます。

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

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

構成例: 名前空間

次のフォワーダー構成では、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 向け Google Security Operations フォワーダーは、レイヤ 4 ロードバランサがデータソースインスタンスとフォワーダーインスタンスの間にインストールされる環境にデプロイできます。これにより、ログ収集を複数のフォワーダーに分配できます。また、障害が発生しても別のフォワーダーにログを送信することもできます。この機能は、syslog コレクションタイプでのみサポートされています。

Linux フォワーダーには、ロードバランサからの HTTP ヘルスチェックに応答する HTTP サーバーが組み込まれています。HTTP サーバーはまた、フォワーダーの起動時またはシャットダウン中にログが失われないようにします。

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

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

http://<host:port>/meta/available: コンテナスケジューラまたはオーケストレーターの 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	次のいずれかの状況でトラフィックを受け入れる準備ができた場合に、フォワーダーが返すステータスコード。準備チェックは、コンテナスケジューラまたはオーケストレーターから受信されます。ヘルスチェックは、従来のロードバランサから受信されます。
routes : meta : unready_status	トラフィックを受け入れる準備ができていない場合に、フォワーダーが返すステータスコード。
routes : meta : available_status	実行チェックが受信され、フォワーダーが利用可能な場合に、フォワーダーが返すステータスコード。多くの場合、コンテナのスケジューラまたはオーケストレーターは実行チェックを送信します。

よくある質問

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

Linux フォワーダーは、Docker イメージのシェルスクリプトによって常に更新されます。Docker イメージを更新するには、フォワーダーを実行します。

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

Docker コンテナは、セキュリティ、分離、リソースの管理を強化する仮想マシンに似ています。
仮想マシン - 特権空間（Linux カーネル）とユーザー空間（libc、python、ls、tcpdump などのすべて）の両方があります。
コンテナ - ユーザースペース（libc、python、ls、tcpdump などを操作するすべての）のみがあり、ホストの特権スペースに依存します。

コンテナを使用して Google Security Operations フォワーダーを配布するのはなぜですか?

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

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

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

Linux 用 Google Security Operations フォワーダー

システム要件

Google IP アドレスの範囲

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

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

Linux フォワーダーを構成する

設定例

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

Docker のインストール

便利な Docker コマンド

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

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

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

フォワーダー ログを表示する

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

フォワーダーを更新する

プロキシの背後にフォワーダーをインストールする

データの収集

Splunk データを収集する

syslog データを収集する

rsyslog を構成する

syslog 構成用の TLS の有効化

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

フラグ構成

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

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

構成例: Kafka の入力

WebProxy データを収集する

構成をカスタマイズする

データ圧縮を切り替える

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

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

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

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

任意のラベルを構成する

構成例: 任意のラベル

名前空間を構成する

構成例: 名前空間

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

よくある質問

フォワーダーログを表示する

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

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

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