フォワーダー構成ファイルを手動で管理する
このページでは、Google Security Operations フォワーダー構成ファイルを手動で作成して変更する方法について説明します。UI でフォワーダーを構成する場合（推奨）は、Google SecOps UI でフォワーダー構成を管理するをご覧ください。
デプロイされる各 Google SecOps フォワーダーには、フォワーダー構成ファイルが必要です。フォワーダー構成ファイルには、Google SecOps インスタンスにデータを転送する設定を指定します。
Google SecOps フォワーダーのインストールと構成方法、システム要件、構成設定の詳細については、フォワーダーのインストールと構成をご覧ください。
始める前に
構成ファイルを作成する前に、取り込むことができるデータの種類と、構成ファイル内で定義する必要がある主な属性を理解して、実装を計画します。
構成ファイルを作成する
構成ファイルを手動で作成する手順は次のとおりです。
UI から構成ファイルをダウンロードします。
次の命名規則を使用して、2 つのファイルを同じディレクトリに保存します。
FORWARDER_NAME.conf - このファイルを使用して、ログの取り込みに関連する構成設定を定義します。FORWARDER_NAME_auth.conf - このファイルを使用して、承認認証情報を定義します。ファイルに変更を加えて、フォワーダー インスタンスの構成を追加します。
取り込み方法のタイプ（Splunk や Syslog など）の設定の詳細については、構成ファイルでデータ型を定義するをご覧ください。データ圧縮やディスク バッファリングなど、各属性のカスタマイズの詳細については、構成ファイルで主要な属性を構成するをご覧ください。
入力に対応する認証の詳細がない場合でも、
FORWARDER_NAME_auth.conf ファイルに各入力のエントリが存在することを確認します。これは、データを正しくマッピングするために必要です。
構成ファイルに加えた変更は、5 分以内にフォワーダーによって自動的に適用されます。
構成例
次の構成ファイルをテンプレートとして参照して、独自の構成ファイルを作成できます。
2 つのファイルのサンプル構成
この 2 つのファイル システムでは、認証情報を別のファイルに保存してセキュリティを強化します。FORWARDER_NAME.conf ファイルは、バージョン管理リポジトリまたはオープン構成管理システムに保存できます。FORWARDER_NAME_auth.conf ファイルは、フォワーダーを実行している物理マシンまたは仮想マシンに直接保存できます。
次のコードサンプルは、フォワーダーの構成ファイルの形式を示しています。
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"
単一ファイルのサンプル構成
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 つのファイル システムに変換する
単一の構成ファイルを使用していて、2 つのファイル システムに移行する場合は、次の操作を行います。
既存の構成ファイルのコピーを作成します。
1 つのファイルを
FORWARDER_NAME.conf ファイルとして保存し、ファイルから認可認証情報を削除します。他のファイルを
FORWARDER_NAME_auth.conf ファイルとして保存し、認可以外のデータをすべてファイルから削除します。サンプル構成を参照してください。構成をカスタマイズするセクションで説明されている命名規則とその他のガイドラインに従ってください。
構成ファイルでデータ型を定義する
以降のセクションでは、Google SecOps インスタンスに転送されるさまざまな種類のデータを取り込むように Google SecOps フォワーダーを構成する方法について説明します。
Splunk データ
Splunk データを Google SecOps に転送するように Google SecOps フォワーダーを構成できます。Google Cloud は、次の情報を使用して Google SecOps フォワーダーを構成し、Splunk からデータを転送します。
Splunk REST API の URL（例: https://10.0.113.15:8089）。
必要な各データ型（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 SecOps フォワーダーが使用できるようにします。これは
creds.txtファイルを作成することによって可能になります。
creds.txt ファイルを使用するには:
Splunk の認証情報のローカル ファイルを作成し、
creds.txtという名前を付けます。最初の行にユーザー名を入力し、2 行目にパスワードを入力します。
cat creds.txt myusername mypassword
Google SecOps フォワーダーを使用して Splunk インスタンスにアクセスするには、
creds.txtファイルを config ディレクトリ（構成ファイルが存在するディレクトリ）にコピーします。Linux
cp creds.txt /opt/chronicle/config/creds.txt
Windows
cp creds.txt c:/opt/chronicle/config/creds.txt
creds.txtファイルが目的のディレクトリにあることを確認します。Linux
ls /opt/chronicle/config
Windows
ls c:/opt/chronicle/config
Syslog データ
フォワーダーは Syslog サーバーとして機能します。TCP または UDP 接続を介した syslog データの送信をサポートする任意のサーバーを構成して、Google SecOps フォワーダーにデータを転送できます。サーバーがフォワーダーに送信するデータを制御できます。フォワーダーは、データを Google SecOps に転送できます。
FORWARDER_NAME.conf 構成ファイル（Google Cloudが提供）では、転送されるデータの種類ごとにモニタリングするポートを指定します（例: ポート 10514）。デフォルトでは、Google SecOps フォワーダーは TCP 接続と UDP 接続の両方を受け入れます。
TCP バッファサイズはカスタマイズできます。デフォルトの TCP バッファサイズは 64 KB です。connection_timeout のデフォルト値と推奨値は 60 秒です。接続が 60 秒間非アクティブになると、TCP 接続は終了します。
rsyslog を構成する
rsyslog を構成するには、各ポートのターゲット（例: 各データ型）を指定する必要があります。次の例は、rsyslog のターゲット構成を示しています。
TCP ログ トラフィック:
dns.* @@192.168.0.12:10514UDP ログ トラフィック:
dns.* @192.168.0.12:10514
詳しくは、システムのドキュメントをご覧ください。
Syslog 構成用の TLS を有効にする
Google SecOps フォワーダーへの Syslog 接続で TLS を有効にできます。フォワーダーの構成ファイル（FORWARDER_NAME.conf）で、次の例に示すように、自己生成の証明書と証明書鍵の場所を指定します。configuration ディレクトリの下に certs ディレクトリを作成し、証明書ファイルを保存できます。
Linux:
| 証明書 | /opt/chronicle/external/certs/client_generated_cert.pem |
| certificate_key | /opt/chronicle/external/certs/client_generated_cert.key |
Windows:
| 証明書 | c:/opt/chronicle/external/certs/client_generated_cert.pem |
| certificate_key | c:/opt/chronicle/external/certs/client_generated_cert.key |
示している例に基づいて、フォワーダーの構成ファイル（FORWARDER_NAME.conf）を次のように変更します。
Linux:
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"
Windows:
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: "c:/opt/chronicle/external/certs/client_generated_cert.pem"
certificate_key: "c:/opt/chronicle/external/certs/client_generated_cert.key"
minimum_tls_version: "TLSv1_3"
入力リクエストの TLS バージョンは、最小 TLS バージョンより大きい必要があります。最小 TLS バージョンは、TLSv1_0、TLSv1_1、TLSv1_2、TLSv1_3 のいずれかの値にする必要があります。
ファイルデータ
ファイル コレクタは、Docker コンテナにバインドされているファイルからログを取得するように設計されています。1 つのログファイルから手動でログをアップロードする場合に使用できます。
Docker コンテナから Google SecOps フォワーダーを起動して、読み込みボリュームをコンテナにマッピングします。
Linux
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
Windows
docker run `
--name cfps `
--log-opt max-size=100m `
--log-opt max-file=10 `
-p 10514:10514 `
-v c:/opt/chronicle/config:c:/opt/chronicle/external `
-v c:/var/log/crowdstrike/falconhostclient:c:/opt/chronicle/edr `
gcr.io/chronicle-container/cf_production_stable_windows
複数のオプションまたは複数の範囲を使用して、複数のポートを追加できます。例: -p 3001:3000 -p 2023:2022、-p 7000-8000:7000-8000。サンプルコードに示されているポート番号は例です。ポート番号は、要件に応じて置き換えてください。
この例に基づいて、Google SecOps フォワーダーの構成（FORWARDER_NAME.conf ファイル）を次のように変更できます。
Linux
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:
Windows
collectors:
- file:
common:
enabled: true
data_type: CS_EDR
data_hint:
batch_n_seconds: 10
batch_n_bytes: 1048576
file_path: c:/opt/chronicle/edr/sample.txt
filter:
sample.txt ファイルは /var/log/crowdstrike/falconhostclient フォルダに存在する必要があります。
フラグの構成
skip_seek_to_end（bool）: このフラグはデフォルトで false に設定されており、ファイル入力では新しいログ行のみが入力として送信されます。これを true に設定すると、フォワーダーの再起動中に、以前のすべてのログ行が再送信されます。これにより、ログが重複します。このフラグを true に設定すると、特定の状況（停止時など）で役立ちます。フォワーダーを再起動すると、欠落したログ行が再度送信されるからです。
poll（bool）: ファイル コレクタは Tail ライブラリを使用して、ファイル システムの変更を確認します。このフラグを true に設定すると、Tail ライブラリはデフォルトの通知メソッドではなくポーリング メソッドを使用します。
パケットデータ
Google SecOps フォワーダーは、ログエントリではなくパケットをネットワーク インターフェースから直接キャプチャできます。
Linux システム
Google SecOps フォワーダーは、Linux の libcap を使用してパケットをキャプチャできます。libcap の詳細については、libcap - Linux のマニュアル ページをご覧ください。
ログエントリではなく、未加工のネットワーク パケットがキャプチャされ、Google Cloudに送信されます。このキャプチャはローカル インターフェースに限定されます。システムのパケット キャプチャを有効にするには、Google SecOps のサポートにお問い合わせください。
Google Cloud は、パケットをキャプチャするために使用される Berkeley Packet Filter（BPF）式を使用して Google SecOps フォワーダーを構成します（たとえば、localhost ではなく、ポート 53）。詳細については、Berkeley パケット フィルタをご覧ください。
Windows システム
Google SecOps フォワーダーは、Windows システムで Npcap を使用してパケットをキャプチャできます。
ログエントリではなく、未加工のネットワーク パケットがキャプチャされ、Google Cloudに送信されます。このキャプチャはローカル インターフェースに限定されます。パケット キャプチャ用に Google SecOps フォワーダーを構成するには、Google SecOps のサポートにお問い合わせください。
パケット キャプチャ PCAP フォワーダーの要件:
Microsoft Windows ホストに Npcap をインストールします。
Google SecOps フォワーダーに root または管理者権限を付与して、ネットワーク インターフェースをモニタリングします。
Npcap のインストールで、WinPcap 互換モードを有効にします。
PCAP フォワーダーを構成するには、 Google Cloud で、パケットのキャプチャに使用するインターフェースの GUID が必要です。Google SecOps フォワーダーをインストールするマシン（SPAN ポートをリッスンするサーバーまたはマシン）で getmac.exe を実行し、出力を Google SecOps に送信します。
別の方法では、構成ファイルを変更することでも可能です。PCAP セクションを見つけ、既存の GUID 値を getmac.exe の実行で取得した GUID に置き換えます。
たとえば、次のような元の PCAP セクションがあるとします。
- pcap:
common:
enabled: true
data_type: PCAP_DNS
batch_n_seconds: 10
batch_n_bytes: 1048576
interface: \Device\NPF_{1A7E7C8B-DD7B-4E13-9637-0437AB1A12FE}
bpf: udp port 53
getmac.exe の実行結果:
C:\>getmac.exe
Physical Address Transport Name
===========================================================================
A4-73-9F-ED-E1-82 \Device\Tcpip_{2E0E9440-ABFF-4E5B-B43C-E188FCAD1234}
新しい GUID で修正した PCAP セクション:
- pcap:
common:
enabled: true
data_type: PCAP_DNS
batch_n_seconds: 10
batch_n_bytes: 1048576
interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734}
bpf: udp port 53
トランスポート名の getmac.exe 出力は \Device\Tcpip で始まり、対応する pcap セクションは \Device\NPF で始まります。
Kafka トピックのデータ
Google Security Operations フォワーダーは、Kafka トピックから直接データを取り込むことをサポートしています。コンシューマー グループのコンセプトを利用して効率的な並列処理を行うと、最大 3 つのフォワーダをデプロイして同じ Kafka トピックからデータを pull できます。詳細については、Kafka をご覧ください。Kafka コンシューマ グループの詳細については、Kafka コンシューマをご覧ください。
次のフォワーダー構成は、Kafka トピックからデータを取り込むようにフォワーダーを設定する方法を示しています。
Linux
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:
Windows
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: "c:/path/to/cert.pem"
certificate_key: "c:/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 SecOps フォワーダーは、ネットワーク インターフェースから直接 WebProxy データをキャプチャできます。
Linux
Google SecOps フォワーダーは、Linux の libcap を使用して WebProxy データをキャプチャできます。libcap の詳細については、libcap - Linux のマニュアル ページをご覧ください。システムの WebProxy データ キャプチャを有効にするには、Google SecOps のサポートにお問い合わせください。
Google SecOps フォワーダーの構成（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
Windows
転送元は、Npcap を使用して WebProxy データをキャプチャし、 Google Cloudに送信できます。
システムの WebProxy データ キャプチャを有効にするには、Google SecOps のサポートにお問い合わせください。
WebProxy フォワーダーを実行する前に、次の手順を行います。
Microsoft Windows ホストに Npcap をインストールします。インストール時に WinPcap 互換モードを有効にします。
フォワーダーに root 権限または管理者権限を付与して、ネットワーク インターフェースをモニタリングします。
WebProxy パケットをキャプチャするインターフェースの GUID を取得します。
Google SecOps フォワーダーをインストールするマシンで
getmac.exeを実行し、出力を Google SecOps に送信します。別の方法では、構成ファイルを変更することでも可能です。WebProxy セクションを見つけ、インターフェースの横にある GUID を、getmac.exeの実行後に表示された GUID に置き換えます。Google SecOps フォワーダーの構成（
FORWARDER_NAME.conf）ファイルを次のように変更します。- webproxy: common: enabled : true data_type: <Your LogType> batch_n_seconds: 10 batch_n_bytes: 1048576 interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734} 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 | コレクタが受信できるデータ形式（通常は形式を記述するログファイル ヘッダー）。 |
構成ファイルで使用されるパラメータの一覧については、転送元の構成フィールドとコレクタの構成フィールドをご覧ください。
データ圧縮
デフォルトでは、ログ圧縮は無効になっています。ログ圧縮を有効にすると、帯域幅の使用量が削減される場合があります。ただし、ログ圧縮を有効にすると、CPU 使用量が増加することもあります。環境とログデータに基づいてトレードオフを評価します。
ログ圧縮を有効にするには、次の例に示すように、Google SecOps フォワーダー構成ファイルの 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",
...
}
ディスク バッファリング
ディスク バッファリングを使用すると、バックログにあるメッセージをメモリではなくディスクにバッファリングできます。
コレクタ間で動的に共有されるバッファを使用するように自動メモリ バッファリングを構成すると、トラフィックの急増に対応しやすくなります。動的に共有されるバッファを有効にするには、フォワーダー構成に次の行を追加します。
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
正規表現フィルタ
正規表現フィルタを使用すると、パターンと未加工のログデータを照合してログをフィルタできます。フィルタでは RE2 構文を使用します。フィルタには正規表現を含める必要があります。また、必要に応じて、一致した場合の動作を定義します。
一致した場合のデフォルトの動作は block です。allow 動作のフィルタを指定できます。allow フィルタを指定すると、フォワーダーによって、少なくとも 1 つの allow フィルタに一致しないログがブロックされます。
フィルタは任意の数を定義できます。Block フィルタは allow フィルタよりも優先されます。
フィルタを定義するときに、名前を割り当てる必要があります。アクティブなフィルタの名前は、フォワーダーのヘルス指標を介して Google SecOps に報告されます。構成のルートで定義されたフィルタは、コレクタ レベルで定義されたフィルタと統合されます。名前が競合する場合は、コレクタレベルのフィルタが優先されます。ルートレベルまたはコレクタ レベルでフィルタが定義されていない場合、すべてのログが許可されます。
構成の例:
次のフォワーダー構成では、ルートフィルタ（allow_filter）に一致しない WINEVTLOG ログがブロックされます。正規表現では、フィルタでは 0 から 99 の間の優先度を持つログのみが許可されます。
ただし、allow_filter にもかかわらず、「foo」または「bar」を含む NIX_SYSTEM ログはブロックされます。これは、フィルタが論理 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
任意のラベル
ラベルは、Key-Value ペアを使用してログにカスタム メタデータを追加するために使用されます。ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が存在する場合、キーが重複すると、コレクタレベルのラベルがフォワーダー レベルのラベルをオーバーライドします。
構成の例:
次のフォワーダー構成では、「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
Namespace
名前空間ラベルを使用して、異なるネットワーク セグメントのログを識別し、重複する IP アドレスの競合を解決できます。フォワーダーに構成された名前空間は、関連するアセットとともに Google SecOps のユーザー インターフェースに表示されます。Google SecOps の検索機能を使用して名前空間を検索することもできます。
Google SecOps のユーザー インターフェースで名前空間を表示する方法については、アセットの名前空間をご覧ください。
構成の例:
次のフォワーダー構成では、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
ロード バランシングと高可用性のオプション
HTTP サーバー、ロード バランシング、高可用性オプションは、フォワーダー構成ファイルの server セクションで構成できます。これらのオプションは、コンテナ スケジューラやオーケストレーション ベースのデプロイで受信されるヘルスチェックや、ロードバランサで受信されるヘルスチェックに応じて返されるタイムアウト期間とステータス コードの設定をサポートします。
次の URL パスを使用して、ヘルス、readiness、liveness のチェックを行います。
<host:port> 値は、フォワーダ構成で定義されます。
http://<host:port>/meta/available: コンテナ スケジューラまたはオーケストレーターの liveness チェックhttp://<host:port>/meta/ready: 準備状況チェックとロードバランサのヘルスチェック
次のフォワーダー構成は、ロード バランシングと高可用性の例です。
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 | 実行チェックが受信され、フォワーダーが利用可能な場合に、フォワーダーが返すステータス コード。コンテナのスケジューラまたはオーケストレーターは、多くの場合、liveness チェックを行います。 |