Linux 向け Chronicle フォワーダー
このドキュメントでは、Linux にフォワーダーをインストールして構成する方法について説明します。Windows にフォワーダーをインストールするには、Windows フォワーダーをご覧ください。
フォワーダーは、お客様の環境から Chronicle インスタンスにログを送信するために使用されます。これは、お客様が Chronicle にログを直接送信し、クラウド バケットを使用してデータを取り込む必要がない場合、またはログタイプにサードパーティの API を介したネイティブ取り込みが行われない場合に使用されます。フォワーダーは、取り込み API を手動で組み込むのではなく、すぐにデプロイできるソリューションとして使用できます。
フォワーダーは、Debian、Ubuntu、Red Hat、Suse など、さまざまな Linux ディストリビューションにインストールできます。Google Cloud はフォワーダーの提供に Docker コンテナを使用します。Docker コンテナは、Linux を実行している物理マシンまたは仮想マシンで実行して、管理できます。
システム要件
一般的な最適化案は次のとおりです。 システムに固有の最適化案については、Chronicle のサポートにお問い合わせください。
RAM: Chronicle の取り込みのために収集されるデータタイプ(コレクタ)ごとに 1 GB。たとえば 4 つの異なるコレクタを指定した場合、4 つのコレクタすべてのデータを収集するためには 4 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 | 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 フォワーダーを構成するには、Chronicle UI で Linux フォワーダーの構成を管理するをご覧ください。
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 をシステムにインストールした後、Chronicle フォワーダーのインストール プロセスは、任意のタイプの 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 に問題がある場合、Chronicle のサポートチームは、このコマンドの出力をリクエストして、問題の修正とデバッグを行います。
Linux にフォワーダーをインストールする
このセクションでは、Docker コンテナを使用して Linux システムに Chronicle フォワーダーをインストールする方法について説明します。
ステップ 1. フォワーダー構成ファイルのダウンロード、転送、インストール
Chronicle には、オペレーティング システム(Linux または Windows)に固有のフォワーダー構成ファイルが用意されています。必要に応じて構成ファイルをダウンロードできます。以下の手順を完了したら、ノートパソコンからユーザーのホーム ディレクトリ内にあるフォワーダーの /opt/chronicle/config
ディレクトリに構成ファイルを転送します。
ターミナルから Linux フォワーダーのホストに接続します。
Linux フォワーダーのホストに新しいユーザーを作成します。
adduser
USERNAME
passwdUSERNAME
usermod -aG wheelUSERNAME
ディレクトリを、Docker コンテナを実行する新しいユーザーのホーム ディレクトリに変更します。
Chronicle フォワーダーの構成ファイルを格納するディレクトリを作成します。
mkdir /opt/chronicle/config
ディレクトリを移動します。
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
フォワーダーのログを表示する
Chronicle フォワーダーのログを表示するには、次のコマンドを実行します。
sudo docker logs cfps
ログが保存されているファイルのパスを表示するには、次のコマンドを実行します。
docker inspect --format='{{.LogPath}}' CONTAINER_NAME
実行中のログを表示するには、次のコマンドを実行します。
sudo docker logs cfps -f
ログをファイルに保存するには、次のコマンドを実行します。
sudo docker logs cfps &> logs.txt
フォワーダーをアンインストールする
以下の Docker コマンドを使用すると、Chronicle フォワーダーの停止とアンインストールや削除を行うことができます。
フォワーダー コンテナを停止またはアンインストールするには:
docker stop cfps
フォワーダー コンテナを削除するには:
docker rm cfps
フォワーダーを更新する
Chronicle フォワーダーには 2 つの部分があり、次のようにアップグレードされます。
フォワーダー バンドル - 自動更新されるため、再起動は必要ありません。
フォワーダー Docker イメージ - ステップ 2 で説明するように、既存のフォワーダーを停止し、新しいインスタンスを起動すると、手動で更新されます。
プロキシの背後でフォワーダーをインストールする
このセクションでは、プロキシの背後で Chronicle フォワーダーをインストールする方法について説明します。
プロキシを使用するようにマシンを構成します。
/etc/resolv.conf
ファイルに次の行を追加します。nameserver = 10.0.0.1 nameserver = 10.0.0.2
次の環境変数を設定します。
$HTTP_PROXY = http://proxy.example.com:80 $HTTPS_PROXY = https://proxy.example.com:80
プロキシを使用するように Docker を構成します。
Docker サービス用の systemd ドロップイン ディレクトリを作成します。
mkdir /etc/systemd/system/docker.service.d
環境変数
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/"
変更をフラッシュします。
$ sudo systemctl daemon-reload
構成が読み込まれていることを確認します。
$ sudo systemctl show --property Environment docker Environment=HTTP_PROXY=http://proxy.example.com:80/ Environment=HTTPS_PROXY=https://proxy.example.com:80/
Docker を再起動します。
$ sudo systemctl restart docker
Google Cloud から最新の Chronicle フォワーダー Docker イメージを取得します。
docker pull gcr.io/chronicle-container/cf_production_stable
プロキシ環境変数を追加して、Chronicle フォワーダー コンテナを実行します。
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
データの収集
以下のセクションでは、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
ファイルを作成することによって可能になります。
creds.txt
ファイルを使用するには:
Splunk の認証情報のローカル ファイルを作成し、
creds.txt
という名前を付けます。最初の行にユーザー名を入力し、2 行目にパスワードを入力します。
cat creds.txt myusername mypassword
Chronicle フォワーダーを使用して Splunk インスタンスにアクセスするには、
creds.txt
ファイルを構成ディレクトリ(構成ファイルと同じディレクトリ)にコピーします。次に例を示します。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 のいずれかの値にする必要があります。
構成ディレクトリの下に証明書ディレクトリを作成し、証明書ファイルを保存できます。
ファイルデータを収集する
ファイル コレクタはファイルからログを取得するように設計されています。このファイルは Docker コンテナにバインドする必要があります。
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/falconhostclient:/opt/chronicle/edr \ gcr.io/chronicle-container/cf_production_stable
この Docker の実行コマンドは、読み込みボリュームをコンテナにマッピングするために重要です。
この例に基づいて、Chronicle フォワーダーの構成(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 ライブラリはデフォルトの通知メソッドではなく、ポーリング メソッドを使用します。
パケットデータを収集する
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:
WebProxy データを収集する
Chronicle フォワーダーでは、Linux の libcap を使用してネットワーク インターフェースから直接 WebProxy データをキャプチャできます。libcap の詳細については、libcap - Linux のマニュアル ページをご覧ください。システムで WebProxy データ キャプチャを有効にするには、Chronicle のサポートにお問い合わせください。
Chronicle フォワーダーの構成(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 | コレクタが受信できるデータ形式(通常は、形式を記述したログファイルのヘッダー)。 |
構成ファイルで使用されるパラメータの広範なリストについては、フォワーダーの構成フィールドとコレクタの構成フィールドをご覧ください。
データ圧縮を切り替える
ログ圧縮により、ログを 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 です。
自動メモリ バッファリングを構成すると、コレクタ間で動的に共有されるバッファを使用できます。これにより、トラフィックの急増に対応できます。動的に共有されるバッファを有効にするには、フォワーダー構成に次の行を追加します。
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
フィルタよりも優先されます。
フィルタを定義する場合は、名前を割り当てる必要があります。アクティブなフィルタの名前は、フォワーダーのヘルス指標を介して 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: コンテナ スケジューラまたはオーケストレーターの 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 などを操作するすべての)のみがあり、ホストの特権スペースに依存します。
コンテナを使用して Chronicle フォワーダーが配布される理由を教えてください。
- 分離によってセキュリティを強化します:
- お客様の環境と要件は、Chronicle フォワーダーには影響しません。
- Chronicle フォワーダーの環境と要件は、お客様には影響しません。
- コンテナ配布メカニズムはすでに存在しており、非公開にして、Google Cloud とお客様向けに分けることができます: https://cloud.google.com/container-registry/
コンテナに対応しているのが Linux のみであるのはなぜですか。Windows についてどうですか?
コンテナは最初に Linux 用に開発され、現在本番環境に対応しています。
コンテナの Windows サポートは進行中です。コンテナは Windows Server 2016 と Windows 10 で使用できます。
高度な Docker コマンドを使用する必要はありますか?
- Chronicle フォワーダーは単一のコンテナを使用するため、Swarm、オーケストレーション、その他の高度な Docker のコンセプトやコマンドについて学ぶ必要はありません。