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 フォワーダーを構成するには:
ソフトウェアに提供されている構成ファイルのテンプレートのコピーを作成します。
次の命名規則を使用して、同じディレクトリに 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
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
フォワーダーをアンインストールする
以下の 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 という名前を付けます。
最初の行にユーザー名を入力し、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 | 次のいずれかの状況でトラフィックを受け入れる準備ができた場合に、フォワーダーが返すステータス コード。
|
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 のコンセプトやコマンドについて学ぶ必要はありません。