フォワーダーをインストールして構成する
このドキュメントでは、Docker を使用して Linux システムと Windows システムに Google Security Operations フォワーダーをインストールして構成する方法について説明します。
フォワーダーは、ネットワーク内のマシンまたはデバイス(サーバーなど)にインストールできるソフトウェア コンポーネントです。ログデータを収集し、そのデータを Google SecOps インスタンスに転送します。
フォワーダーを使用すると、サポートされていないログタイプにクラウド バケットやサードパーティ API を使用することなく、環境から Google SecOps にログを直接送信できます。フォワーダーは、すぐにデプロイできるソリューションとして機能するため、Ingestion API との手動統合は必要ありません。
Google SecOps は、安全なフォワーダーのデプロイ用に Docker コンテナを提供します。Docker コンテナは、物理マシンまたは仮想マシンで実行して、管理できます。
システム要件
一般的な最適化案は次のとおりです。システムに固有の最適化案については、Google SecOps のサポートにお問い合わせください。
Linux システム
フォワーダーは、Debian、Ubuntu、Red Hat、Suse などのさまざまな Linux ディストリビューションでサポートされています。最適なパフォーマンスを得るには、Docker バージョン 20.10.21 以降を使用する必要があります。
RAM: Google SecOps の取り込みのために収集されるデータタイプごとに 1 GB の RAM が必要です。たとえば 4 つの異なるコレクタを指定した場合、4 つのコレクタすべてのデータを収集するためには 4 GB の RAM が必要になります。
CPU: 2 個の CPU は、すべてのデータ型で最大 10,000 EPS(1 秒あたりイベント数)を処理するには十分です。転送元が 10,000 を超える EPS を処理すると予想される場合は、4~6 個の CPU を割り当てます。
ディスク: フォワーダーで処理するデータの量に関係なく、20 GB のディスク容量が推奨されます。
Windows システム
フォワーダーは Microsoft Windows Server 2022 でサポートされています。最適なパフォーマンスを得るには、Docker バージョン 20.10.21 以降を使用する必要があります。
RAM: Google SecOps が取り込みのために受け入れる収集されたデータタイプごとに 1.5 GB の RAM が必要です。たとえば 4 つの異なるコレクタを指定した場合、4 つのコレクタすべてのデータを収集するためには 6 GB の RAM が必要になります。
CPU: 2 個の CPU は、すべてのデータ型で最大 10,000 EPS(1 秒あたりイベント数)を処理するには十分です。転送元が 10,000 を超える EPS を処理すると予想される場合は、4~6 個の CPU を割り当てます。
ディスク: フォワーダーで処理するデータの量に関係なく、20 GB のディスク容量が推奨されます。
始める前に
フォワーダーの実装を開始する前に、次の点を考慮してください。
Google IP アドレスの範囲
フォワーダーを構成するときに、IP アドレス範囲の指定を含むファイアウォール設定の調整が必要になる場合があります。Google API とサービスで使用されるデフォルト ドメインの IP 範囲は動的に割り当てられ、頻繁に変更されます。詳細については、Google IP アドレス範囲を取得するをご覧ください。
ファイアウォール構成を確認する
フォワーダー コンテナがファイアウォールまたは認証プロキシの背後で実行されている場合は、次のホストへのアウトバウンド アクセスを許可します。
| 接続タイプ | 宛先 | ポート |
|---|---|---|
| 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 | eu-chronicle.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 | europe-west9-malachiteingestion-pa.googleapis.com |
443 |
| TCP | europe-west12-malachiteingestion-pa.googleapis.com |
443 |
| TCP | me-central1-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 | southamerica-east1-malachiteingestion-pa.googleapis.com |
443 |
| TCP | accounts.google.com |
443 |
| TCP | gcr.io |
443 |
| TCP | cloud.google.com/artifact-registry |
443 |
| TCP | oauth2.googleapis.com |
443 |
| TCP | www.googleapis.com |
443 |
| TCP | storage.googleapis.com |
443 |
実装を計画する
フォワーダーの構成を開始する前に、実装を計画します。これにより、データソースと構成属性を、セキュリティ目標、インフラストラクチャ機能、スケーラビリティ要件に合わせることができます。
取り込むデータを決定する
次のオプションから、フォワーダーに最も関連性の高いデータソースを特定します。
Splunk: すでに Splunk をログ管理に使用している場合に最適です。
Syslog: さまざまなデバイスのシステムログとアプリケーション ログに対応する汎用性。
File: 任意のログファイルを柔軟に取り込むことができます。
パケット: 未加工のトラフィックをキャプチャすることで、ネットワークを詳細に可視化します。
Kafka: 分散システムからの大量のリアルタイム ログ集計に最適です。
WebProxy: ウェブ トラフィックとユーザー行動に関する分析情報を得るのに最適です。
制限
データフィードのログ行サイズの上限は 4 MB です。
構成を決定する
フォワーダーをインストールする前に、次の重要な属性を決定して、実装を成功させます。
データ圧縮
データまたはログの圧縮により、ログを Google SecOps に転送する際のネットワーク帯域幅の使用量が削減されます。ただし、それによって CPU 使用率が増加する場合があります。帯域幅の節約と CPU 使用率の最適なバランスは、ログタイプ、データの圧縮率、使用可能な CPU リソース、ネットワーク帯域幅の制約など、複数の要因によって異なります。
たとえば、テキストベースのログは通常圧縮率が高く、低い CPU 使用率によって帯域幅を大幅に削減できますが、暗号化されたデータやバイナリデータは効率的に圧縮されず、CPU 使用率が高くなる可能性があります。
デフォルトでは、ログ圧縮は無効になっています。特定の環境とログデータの性質に基づいて、トレードオフを評価します。
ディスク バッファリング
ディスク バッファリングを有効にすることをおすすめします。ディスク バッファリングを使用すると、バックログにあるメッセージをメモリではなくディスクにバッファリングできます。これにより、フォワーダーまたはホストがクラッシュした場合のデータ損失を防ぐことができます。ただし、ディスク バッファリングを有効にするとパフォーマンスに影響する可能性があります。
ディスク バッファリングが無効になっている場合、フォワーダーは、ログタイプ(たとえば、コネクタ)ごとに 1 GB のメモリ(RAM)を割り当てます。ディスク バッファリングに許容される最大メモリは 4 GB です。
正規表現フィルタ
正規表現フィルタを使用すると、RE2 構文を使用して、未加工のログデータに対してパターンを評価できます。各フィルタには正規表現を含める必要があります。また、必要に応じて、一致した場合の動作を定義できます。
任意のラベル
ラベルは、Key-Value ペアを使用してログにカスタム メタデータを追加するために使用されます。ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が存在する場合、キーが重複すると、コレクタレベルのラベルがフォワーダー レベルのラベルをオーバーライドします。
名前空間
名前空間ラベルを使用すると、異なるネットワーク セグメントのログを識別し、重複する IP アドレスの競合を解決できます。名前空間ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が存在する場合、コレクタレベルの名前空間がフォワーダーレベルの名前空間をオーバーライドします。
ログタイプ
Google SecOps はさまざまなログタイプをサポートしています。包括的なリストについては、サポートされているデータセットをご覧ください。
ロード バランシングと高可用性のオプション
ロード バランシングは、syslog コレクション タイプでのみサポートされます。
フォワーダーは、レイヤ 4 ロードバランサがデータソース インスタンスとフォワーダー インスタンスの間にインストールされる環境にデプロイできます。これにより、ログ収集を複数のフォワーダーに分散できます。また、障害が発生した場合にログを別のフォワーダーにリダイレクトすることで、信頼性を高めることができます。
フォワーダーには、ロードバランサからのヘルスチェックに応答し、起動時とシャットダウン時のログの損失を防ぐ HTTP サーバーが組み込まれています。HTTP サーバー、ロード バランシング、高可用性オプションを構成して、ヘルスチェックのタイムアウト期間とステータス コードを指定できます。この構成は、コンテナベースのデプロイとロードバランサの両方に対応しています。
| 設定 | 説明 |
|---|---|
| グレースフル タイムアウト | フォワーダーがヘルスチェックに応答して unready ステータスを返した後に、新しい接続が受け入れられる時間。これは、停止する信号を受信してから実際にサーバー自体のシャットダウンが開始されるまで、待機する時間でもあります。これにより、ロードバランサがプールからフォワーダーを削除する時間を確保できます。有効な値は秒単位です。たとえば、10 秒を指定するには、「 10.」と入力します。小数値は使用できません。デフォルト: 15 秒 |
| ドレイン タイムアウト | アクティブな接続がサーバーによって閉じられる前に、独自に終了するまでフォワーダーが待機する時間。たとえば、5 秒を指定するには、「5.」と入力します。小数値は使用できません。デフォルト: 10 秒 |
| ポート | HTTP サーバーがロードバランサからのヘルスチェックをリッスンするポート番号。値は 1,024~65,535 の中から指定してください。 デフォルト: 8000 |
| IP アドレスまたはホスト名 | IP アドレス、または、サーバーがリッスンする IP アドレスに解決できるホスト名。 デフォルト:0.0.0.0(ローカル システム) |
| 読み取りタイムアウト | HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。ヘッダーと本文の両方のリクエスト全体の読み取りが許可される最大時間。読み取りタイムアウト フィールドと読み取りヘッダー タイムアウト フィールドの両方を設定できます。 デフォルト: 3 秒 |
| 読み取りヘッダー タイムアウト | HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。リクエスト ヘッダーの読み取りに許可される最大時間。ヘッダーの読み取り後に、接続の読み取り期限がリセットされます。 デフォルト: 3 秒 |
| 書き込みタイムアウト | HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。レスポンスの送信に許可される最大時間。新しいリクエスト ヘッダーが読み取られると、リセットされます。 デフォルト: 3 秒 |
| アイドル タイムアウト | HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。アイドル接続が有効になっている場合に、次のリクエストを待機する最大時間。[アイドル タイムアウト] フィールドが 0 に設定されている場合は、[読み取りタイムアウト] フィールドの値が使用されます。両方が 0 の場合は、読み取りヘッダー タイムアウト フィールドが使用されます。 デフォルト: 6 秒 |
| 利用可能なステータス コード | 実行チェックが受信され、フォワーダーが利用可能な場合に、フォワーダーが返すステータス コード。コンテナのスケジューラ / オーケストレーターは、多くの場合、liveness チェックを行います。 デフォルト: 204 |
| 準備完了ステータス コード | 次のいずれかの状況でトラフィックを受け入れる準備ができた場合に、フォワーダーが返すステータス コード。
|
| 準備ができていないステータス コード | トラフィックを受け入れる準備ができていない場合に、フォワーダーが返すステータス コード。 デフォルト: 503 |
ステップ 1: フォワーダー構成を定義する
デプロイされた各フォワーダーには、フォワーダー構成ファイルが必要です。フォワーダー構成ファイルでは、Google SecOps インスタンスにデータを転送する設定を指定します。各ホストに関連付けられたコレクタを明確に区別するために、ホストごとに新しい構成ファイルを生成することをおすすめします。
Google Cloud は、各フォワーダー インスタンスの特定のメタデータを使用して、これらの構成ファイルをカスタマイズします。これらのファイルは、特定の要件に合わせて変更し、取り込むログの種類に関する詳細を組み込むことができます。
フォワーダー構成ファイルは、UI、API、または手動で生成できます。
UI には、フォワーダーを構成するためのグラフィカル インターフェースが用意されています。これは、フォワーダー構成を作成する際におすすめの方法です。これは最も簡単な方法であり、プログラミングは必要ありません。Google SecOps ユーザー インターフェースを使用して構成ファイルをダウンロードするには、Google SecOps UI でフォワーダー構成を管理するをご覧ください。
この API は、フォワーダーをプログラムで構成する方法を提供します。フォワーダー構成をプログラムでダウンロードするには、Forwarder Management API をご覧ください。
構成ファイルを手動で作成し、構成オプションを追加できます。精度を確保し、潜在的なエラーを最小限に抑えるため、UI メソッドを使用して構成ファイルを生成することをおすすめします。ファイルを手動で生成するには、フォワーダー構成ファイルを手動で管理するをご覧ください。
ステップ 2: Docker をインストールする
このセクションでは、システムに Docker をインストールする方法について説明します。
Artifact Registry での Docker 認証
Docker のインストールの一環として、Docker を認証する必要があります。docker を認証するには、Google Cloud CLI コマンドライン インターフェース(CLI)を使用します。Google Cloud CLI(コマンドライン インターフェース)をインストールできない場合は、VM で新しいサービス アカウント JSON を作成します。
方法 1: Google Cloud CLI コマンドライン インターフェース(CLI)を使用する
次のコマンドを実行して Docker を認証します。
gcloud auth configure-docker gcr.io
方法 2: 仮想マシン(VM)で新しいサービス アカウント JSON を作成してダウンロードする。
Google Cloud CLI(コマンドライン インターフェース)をインストールできない場合は、この方法を使用します。
次のコマンドを実行して Docker を認証します。
cat key.json | docker login -u _json_key --password-stdin https://gcr.io
Docker 認証のその他の方法については、Docker 用に Artifact Registry への認証を構成するをご覧ください。
Linux システム
Docker はオープンソースであり、必要なドキュメントはすべてオープンソースの Docker コミュニティから入手できます。Docker のインストール手順については、Docker Engine をインストールするをご覧ください。
Docker がシステムに適切にインストールされているかどうかを確認するには、次のコマンドを実行します(昇格権限が必要)。
docker ps
次のレスポンスは、Docker が適切にインストールされていることを示しています。
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Windows システム
管理者権限で Windows PowerShell を起動し、次の手順で Google Cloud へのネットワーク接続を確認します。
[開始] をクリックします。
「
PowerShell」と入力し、[Windows PowerShell] を右クリックします。[管理者として実行] をクリックします。
次のコマンドを実行します。
C:\> test-netconnection <host> -port <port>コマンド出力は、
TcpTestSucceededステータスがtrueであることを示しています。例:
C:\> test-netconnection malachiteingestion-pa.googleapis.com -port 443 ComputerName : malachiteingestion-pa.googleapis.com RemoteAddress : 198.51.100.1 RemotePort : 443 InterfaceAlias : Ethernet SourceAddress : 203.0.113.1 TcpTestSucceeded : True
Docker をインストールするには、Windows サーバーで次の操作を行います。
Microsoft Windows コンテナ機能を有効にします。
Install-WindowsFeature containers -RestartPowerShell の管理者モードで次のコマンドを実行して、Docker CE をインストールします。
Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -o install-docker-ce.ps1 .\install-docker-ce.ps1docker psコマンドを実行して Docker コマンドライン インターフェースをテストします。このコマンドは、実行中のコンテナのリストを返します。Docker が正しくインストールされていない場合は、エラーが表示されます。詳細については、Get started: Prep Windows for containers をご覧ください。
エンタープライズ デプロイの場合は、Mirantis Container Runtime をインストールします(Docker EE とも呼ばれます)。
ステップ 3: フォワーダーをインストールする
このセクションでは、Docker コンテナを使用してフォワーダーをインストールする方法について説明します。
ステップ 3a: 構成ファイルをフォワーダー ディレクトリに移動する
フォワーダーのインストール プロセスの最初のステップでは、指定されたフォワーダー ディレクトリ内に必要な構成ファイルを配置します。
Linux システム
次の手順で、構成ファイルをフォワーダー ディレクトリに配置します。
ターミナルを使用して Linux フォワーダー ホストに接続します。
Docker コンテナを実行するホーム ディレクトリに移動します。
フォワーダーの構成ファイルを格納するディレクトリを作成します。
mkdir /opt/chronicle/'CONFIG'
ディレクトリ名
CONFIGは任意の名前に置き換えることができます。docker runコマンドの実行時に同じディレクトリ名を使用してください。ディレクトリを変更します。
cd /opt/chronicle/config
ファイルが転送されたら、構成ファイルが
/opt/chronicle/configディレクトリにあることを確認します。ls -l
Windows システム
C:\config フォルダを作成し、その中に構成ファイルを配置します。フォルダ名 config は任意の名前に置き換えることができます。docker run コマンドの実行時に同じフォルダ名を使用してください。
ステップ 3b: フォワーダーを実行する
構成ファイルを指定されたフォワーダー ディレクトリに配置したら、フォワーダーを起動するか、Google SecOps コンテナの最新バージョンにアップグレードできます。
コンテナをアップグレードする場合は、次のコマンドを実行して、以前に実行した Docker をクリーンアップします。
docker stop 'cfps'
docker rm 'cfps'
この例では、Docker コンテナ名は cfps です。
フォワーダーを初めて起動する場合、または Google SecOps コンテナの最新バージョンにアップグレードする場合は、次の操作を行います。
Google Cloudから最新の Docker イメージを取得します。
Linux システム:
docker pull gcr.io/chronicle-container/cf_production_stableWindows システム:
docker pull gcr.io/chronicle-container/cf_production_stable_windowsDocker コンテナからフォワーダーを起動します。
Linux システム:
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(Linux システムの場合は省略可)Docker コンテナからフォワーダーを起動するときに、
/var/log/から特定のサブディレクトリをマウントすることもできます。
特定のサブディレクトリをマウントするには、次の行をコマンドに追加し、<parser-name>プレースホルダを、ログを収集するホストシステム上のディレクトリの名前に置き換えます。-v /var/log/<parser-name>:/opt/chronicle/edr \Linux システム(特定のサブディレクトリをマウントするオプションを含む):
`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 \ -v /var/log/<parser-name>:/opt/chronicle/edr \ gcr.io/chronicle-container/cf_production_stable`Windows システム:
docker run ` --detach ` --name cfps ` --restart=always ` --log-opt max-size=100m ` --log-opt max-file=10 ` -p 0.0.0.0:10515-10520:10515-10520/udp ` -v C:\config\:C:/opt/chronicle/external ` gcr.io/chronicle-container/cf_production_stable_windows
--log-opt オプションは、Docker 1.13 以降で使用できます。これらのオプションはコンテナ ログファイルのサイズを制限するものであり、使用している Docker のバージョンがサポートしている限り、使用する必要があります。
フォワーダーを管理する
以降のセクションでは、フォワーダーの管理に関するガイダンスを提供します。
フォワーダーのログを表示する
フォワーダーのログを表示するには、次のコマンドを実行します。
docker logs cfpsログが保存されているファイルのパスを表示するには、次のコマンドを実行します。
docker inspect --format='{{.LogPath}}' CONTAINER_NAMEライブ実行ログを表示するには、次のコマンドを実行します。
docker logs cfps -fログをファイルに保存するには、次のコマンドを実行します。
docker logs cfps &> logs.txt
フォワーダーをアンインストールする
次の Docker コマンドは、フォワーダーの停止、アンインストール、削除に役立ちます。
フォワーダー コンテナを停止またはアンインストールするには、次のコマンドを実行します。
docker stop cfps
フォワーダー コンテナを削除するには、次のコマンドを実行します。
docker rm cfps
フォワーダーを更新する
フォワーダーは 2 つのコンポーネントで構成されており、それぞれに次のような更新プロセスがあります。
フォワーダー バンドル: このコンポーネントは自動的に更新されるため、再起動は必要ありません。
フォワーダー Docker イメージ: このコンポーネントの更新は手動で行われます。ステップ 3b で説明されているように、現在のフォワーダー インスタンスを停止して新しいインスタンスを開始する必要があります。
特定のデータセットに対するフォワーダーの取り込みガイド
フォワーダーを使用して特定のデータセットを取り込む方法については、以下をご覧ください。
- Carbon Black Event Forwarder をインストールする
- Cisco ASA ファイアウォール ログを収集する
- Corelight Sensor ログを収集する
- Fluentd ログを収集する
- Linux 監査と Unix システムログを収集する
- Microsoft Windows AD データを収集する
- Microsoft Windows DHCP データを収集する
- Microsoft Windows の DNS データを収集する
- Microsoft Windows Event データを収集する
- Microsoft Windows Sysmon データを収集する
- osquery ログを収集する
- OSSEC ログを収集する
- Palo Alto Networks ファイアウォール ログを収集する
- Splunk CIM ログを収集する
- Zeek ログを収集する
さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。