フォワーダーをインストールして構成する
このドキュメントでは、Docker を使用して Linux システムと Windows システムに Google Security Operations フォワーダーをインストールして構成する方法について説明します。
フォワーダーは、ネットワーク内のマシンまたはデバイス(サーバーなど)にインストールできるソフトウェア コンポーネントです。ログデータを収集し、そのデータを Google SecOps インスタンスに転送します。
転送ツールを使用すると、サポートされていないログタイプにクラウド バケットやサードパーティ API を使用せずに、環境から Google SecOps にログを直接送信できます。フォワーダーはすぐにデプロイできるソリューションとして機能し、取り込み 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 | 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 | storage.googleapis.com | 443 |
実装を計画する
転送元の構成を開始する前に、実装を計画します。これにより、データソースと構成属性をセキュリティ目標、インフラストラクチャ機能、スケーラビリティ要件に合わせることができます。
取り込むデータを特定する
次のオプションから、転送元に最も関連性の高いデータソースを特定します。
Splunk: ログ管理に Splunk をすでに使用している場合に最適です。
Syslog: さまざまなデバイスのシステムログとアプリケーションログに汎用性があります。
ファイル: 任意のログファイルを柔軟に取り込むことができます。
Packet: 未加工のトラフィックをキャプチャして、詳細なネットワーク可視化を提供します。
Kafka: 分散システムからの大量のリアルタイム ログの集計に最適です。
WebProxy: ウェブ トラフィックとユーザー行動に関する分析情報の収集に最適です。
制約事項
データフィードでは、ログ行の最大サイズは 4 MB です。
構成を決定する
フォワーダをインストールする前に、実装を成功させるために次の重要な属性を決定します。
データ圧縮
データまたはログの圧縮により、ログを Google SecOps に転送する際のネットワーク帯域幅の使用量が削減されます。ただし、CPU 使用率が増加する可能性があります。帯域幅の削減と CPU 使用量の最適なバランスは、ログタイプ、データの圧縮率、使用可能な CPU リソース、ネットワーク帯域幅の制約など、複数の要因によって異なります。
たとえば、テキストベースのログは通常圧縮率が高く、低い CPU 使用率によって帯域幅を大幅に削減できますが、暗号化されたデータやバイナリ データは効率的に圧縮されず、CPU 使用率が高くなる可能性があります。
デフォルトでは、ログ圧縮は無効になっています。特定の環境とログデータの性質に基づいてトレードオフを評価します。
ディスク バッファリング
ディスク バッファリングを有効にすることをおすすめします。ディスク バッファリングを使用すると、バックログにあるメッセージをメモリではなくディスクにバッファリングできるため、フォワーダーまたはホストのクラッシュが発生した場合にデータが失われるのを防ぐことができます。ただし、ディスク バッファリングを有効にするとパフォーマンスに影響する可能性があります。
ディスク バッファリングが無効になっている場合、フォワーダーは、ログタイプ(たとえば、コネクタ)ごとに 1 GB のメモリ(RAM)を割り振ります。ディスク バッファリングで許容される最大メモリは 4 GB です。
正規表現フィルタ
正規表現フィルタを使用すると、パターンと未加工のログデータを照合してログをフィルタできます。フィルタでは RE2 構文が使用されます。フィルタには正規表現を含める必要があります。また、必要に応じて、一致した場合の動作を定義します。
任意のラベル
ラベルは、Key-Value ペアを使用してログにカスタム メタデータを追加するために使用されます。ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が存在する場合、キーが重複すると、コレクタレベルのラベルがフォワーダー レベルのラベルをオーバーライドします。
Namespace
名前空間ラベルを使用すると、異なるネットワーク セグメントのログを識別し、重複する IP アドレスの競合を解決できます。名前空間ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方がある場合、コレクタレベルの名前空間がフォワーダレベルの名前空間をオーバーライドします。
ログタイプ
Google SecOps はさまざまなログタイプをサポートしています。詳細なリストについては、サポートされているデータセットをご覧ください。
ロード バランシングと高可用性のオプション
ロード バランシングは、Syslog 収集タイプでのみサポートされます。
フォワーダーは、レイヤ 4 ロードバランサがデータソース インスタンスとフォワーダー インスタンスの間にインストールされている環境にデプロイできます。これにより、ログ収集を複数のフォワーダーに分散できます。障害が発生した場合にログを別のフォワーダーにリダイレクトすることで、信頼性を高めることができます。
フォワーダーには、ロードバランサからのヘルスチェックに応答し、起動時とシャットダウン時にログが失われるのを防ぐ HTTP サーバーが組み込まれています。HTTP サーバー、ロード バランシング、高可用性のオプションを構成して、ヘルスチェックのタイムアウト時間とステータス コードを指定できます。この構成は、コンテナベースのデプロイとロードバランサの両方に対応しています。
設定 | Description |
---|---|
グレースフル タイムアウト | フォワーダーがヘルスチェックに応答して unready ステータスを返した後、新しい接続が受け入れられる時間。これは、停止する信号を受信してから実際にサーバー自体のシャットダウンが開始されるまで、待機する時間でもあります。これにより、ロードバランサがプールからフォワーダーを削除する時間を確保できます。有効な値は秒単位です。たとえば、10 秒を指定するには、 10. と入力します。小数値は使用できません。デフォルト: 15 秒 |
ドレイン タイムアウト | アクティブな接続がサーバーによって閉じられる前に、独自に終了するまでフォワーダーが待機する時間。たとえば、5 秒を指定するには、5. と入力します。小数値は使用できません。デフォルト: 10 秒 |
ポート | HTTP サーバーがロードバランサからのヘルスチェックをリッスンするポート番号。値は 1,024 ~ 65,535 の範囲で指定してください。 デフォルト: 8000 |
IP アドレスまたはホスト名 | IP アドレス、または、サーバーがリッスンする IP アドレスに解決できるホスト名。 デフォルト:0.0.0.0(ローカル システム) |
読み取りタイムアウト | HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。ヘッダーと本文の両方のリクエスト全体の読み取りが許可される最大時間。[read timeout] フィールドと [read header timeout] フィールドの両方を設定できます。 デフォルト: 3 秒 |
ヘッダーの読み取りタイムアウト | HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。リクエスト ヘッダーの読み取りに許可される最大時間。ヘッダーの読み取り後に、接続の読み取り期限がリセットされます。 デフォルト: 3 秒 |
書き込みタイムアウト | HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。レスポンスの送信に許可される最大時間。新しいリクエスト ヘッダーが読み取られるとリセットされます。 デフォルト: 3 秒 |
アイドル タイムアウト | HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。アイドル状態の接続が有効になっている場合に、次のリクエストを待機する最大時間。アイドル状態のタイムアウト フィールドがゼロに設定されている場合、読み取りタイムアウト フィールドの値が使用されます。両方がゼロの場合、read header timeout フィールドが使用されます。 デフォルト: 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 をインストールする方法について説明します。
Linux システム
Docker はオープンソースであり、必要なドキュメントはすべてオープンソースの Docker コミュニティで入手できます。Docker のインストール手順については、Docker Engine をインストールするをご覧ください。
Docker がシステムに適切にインストールされているかどうかを確認するには、次のコマンドを実行します(昇格権限が必要です)。
docker ps
次のレスポンスは、Docker が適切にインストールされていることを示しています。
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Windows システム
管理者権限で Windows PowerShell を起動し、次の手順で Google Cloud へのネットワーク接続を確認します。
[Start] をクリックします。
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 -Restart
PowerShell 管理者モードで次のコマンドを実行して 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.ps1
Docker コマンドライン インターフェースをテストするには、
docker ps
コマンドを実行します。このコマンドは、実行中のコンテナのリストを返します。Docker が正しくインストールされていない場合は、エラーが表示されます。詳細については、スタートガイド: コンテナ用に Windows を準備するをご覧ください。
エンタープライズ デプロイの場合は、Docker EE とも呼ばれる Mirantis Container Runtime をインストールします。
ステップ 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_stable
Windows システム:
docker pull gcr.io/chronicle-container/cf_production_stable_windows
Docker コンテナからフォワーダーを起動します。
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
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 ログを収集する