GSP474

概要

Google Cloud ネットワーキングのトラフィック ミラーリングは、セキュリティとネットワーク分析に使用する主要な機能です。この機能は、ネットワーク タップの機能や従来のネットワーキングでのスパン セッションの機能と似ています。つまり、Packet Mirroring は、選択された「ミラーリング対象のソース」からのネットワーク トラフィック（内向きと外向き）をキャプチャしてコピーし、そのコピーをコレクタに転送します。

Packet Mirroring は各パケットのペイロード全体をキャプチャするため、帯域幅の消費量が増えることにご注意ください。Packet Mirroring はサンプリング期間に基づくものではないので、トラブルシューティングやセキュリティ ソリューション、分析に基づく上位レイヤのアプリケーションに使用するのに適しています。

Packet Mirroring は「Packet Mirroring ポリシー」に基づいて構成されます。このポリシーには、次の属性が含まれます。

• リージョン
• VPC ネットワーク
• ミラーリング対象のソース
• コレクタ（宛先）
• ミラーリング対象のトラフィック（フィルタ）

次の要点も考慮する必要があります。

• ミラーリングできるのは、TCP、UDP、ICMP トラフィックのみですが、多くのユースケースに対応できます。
• 「ミラーリング対象のソース」と「コレクタ」は同じリージョン内にある必要がありますが、ゾーンは異なっていてもかまいません。さらに、VPC が適切にピアリングされている限り、異なる VPC 内に存在するソースとコレクタを使用することもできます。
• 特にゾーン間では、帯域幅の消費量が増えるため、追加の料金がかかります。ミラーリングするトラフィックを制限するには、フィルタを使用できます。

「Packet Mirroring」の主要なユースケースの 1 つは、Intrusion Detection System（IDS）ソリューションです。クラウドベースの IDS ソリューションによっては、特殊なサービスを各ソース VM で実行する必要があったり、ネットワークの送信元と宛先の間に IDS 仮想アプライアンスをインラインで配置する必要があったりします。いずれの場合も影響は多大なものになります。たとえば、サービスをベースとしたソリューションの場合、完全分散型であってもゲスト オペレーティング システムで同じソフトウェアをサポートする必要があります。「インライン」のソリューションの場合は、すべてのトラフィックが IDS アプライアンスを経由しなければならないため、ネットワークにボトルネックが生じる可能性があります。さらに、インライン ソリューションでは、同じ VPC にある VM 内部の「East-West」トラフィックをキャプチャできません。

Google Cloud の Packet Mirroring は、追加のソフトウェアを VM にインストールしなくても使用でき、ミラーリングされた各 VM に完全に分散されます。「コレクタ」としての IDS はトラフィック フローの外部に配置され、内部ネットワーク ロードバランサ（ILB）を使用して「North-South」トラフィックと「East-West」トラフィックの両方を受信します。

Packet Mirroring ラボの説明

Packet Mirroring を IDS で使用する方法を説明するために、このラボでは Suricata というオープンソースの IDS を使用する例を見ていきます。

• 1 つの VPC を作成し、その VPC 内に 2 つのサブネット（ミラーリング対象のソース用サブネットとコレクタ用サブネット）を作成します。
• パブリック IP アドレスを持つ 2 つのウェブサーバーを作成します。
• セキュリティ上の理由によりパブリック IP を割り当てない、1 つのコレクタ サーバー（IDS）を作成します。
• 必要に応じて、インターネット アクセスに対して CloudNAT を有効にします。
• わかりやすくするため、また、費用の理由からも、すべての VM を同じリージョン内の同じゾーンに作成します。

このラボでは、Google Cloud 環境を作成し、「コレクタ」としての ILB とパケット ミラーリング ポリシーを構成します。さらに、[Suricata]（https://suricata-ids.org/）を仮想インスタンスにインストールし、IDS として機能するように構成します。構成が完了したら、ネットワーク テストを行って、構成を検証するとともに、オープンソース IDS での Packet Mirroring の使用を検証します。デモを簡素化するために、かなり簡略化したルールセットと Suricata 構成を使用します。

目標:

• 上の図に示す Google Cloud ネットワーキング環境を構築する
• gcloud コマンドを使用して、ウェブサーバーとして機能する 2 つの仮想マシンを作成する
• gcloud コマンドを使用して、IDS として機能する 1 つの仮想マシンを作成する
• Packet Mirroring の「コレクタ」として機能する内部ロードバランサ（ILB）を作成する
• IDS VM にオープンソースの IDS（Suricata）をインストールして構成する
• 基本的な IDS アラートルールを確認する
• パケット ミラーリング ポリシーを作成する
• ネットワーク トラフィックを生成して「ミラーリング対象」のサブネットに送信し、Packet Mirroring をテストする
• IDS イベントをシミュレートするネットワーク トラフィックを生成して Suricata IDS をテストし、IDS のロギングを確認する

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。

このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。

• ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

   • [Google コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

   重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

5. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

2. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

3. [承認] をクリックします。

4. 出力は次のようになります。

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

タスク 1. ネットワーキングのフットプリントを構築する

このセクションでは、VPC を作成し、その VPC 内に 2 つのサブネットを作成します。この作業を行うために、Google Cloud Shell 内で gcloud CLI コマンドを使用します。

1. 次のコマンドを実行して、バーチャル プライベート ネットワークを作成します。

gcloud compute networks create dm-stamford \ --subnet-mode=custom

2. 内のミラーリングされたトラフィックのためにサブネットを VPC に追加します。

gcloud compute networks subnets create dm-stamford-{{{project_0.default_region | REGION}}} \ --range=172.21.0.0/24 \ --network=dm-stamford \ --region={{{project_0.default_region | REGION}}}

3. 内のコレクタに使用するサブネットを VPC に追加します。

gcloud compute networks subnets create dm-stamford-{{{project_0.default_region | REGION}}}-ids \ --range=172.21.1.0/24 \ --network=dm-stamford \ --region={{{project_0.default_region | REGION}}}

[進行状況を確認] をクリックして、目標を確認します。

ネットワーキングのフットプリントを構築する

タスク 2. ファイアウォール ルールと Cloud NAT を作成する

このラボを完了するには、全部で 3 つのファイアウォール ルールが必要です。

• ルール 1 ですべての送信元からのすべての VM へのトラフィックに対し、標準の HTTP ポート（TCP 80）と ICMP プロトコルを許可します。
• ルール 2 で IDS に対し、すべての送信元からの、すべてのトラフィックの受信を許可します。以降のセクションで、この IDS VM にパブリック IP を割り当てないよう注意してください。
• ルール 3 ですべての VM に対し、「Google Cloud IAP Proxy」IP 範囲を TCP ポート 22 で許可して、Cloud コンソールから SSH で VM に接続できるようにします。

次のコマンドを実行してファイアウォール ルールを作成します。

gcloud compute firewall-rules create fw-dm-stamford-allow-any-web \ --direction=INGRESS \ --priority=1000 \ --network=dm-stamford \ --action=ALLOW \ --rules=tcp:80,icmp \ --source-ranges=0.0.0.0/0 gcloud compute firewall-rules create fw-dm-stamford-ids-any-any \ --direction=INGRESS \ --priority=1000 \ --network=dm-stamford \ --action=ALLOW \ --rules=all \ --source-ranges=0.0.0.0/0 \ --target-tags=ids gcloud compute firewall-rules create fw-dm-stamford-iapproxy \ --direction=INGRESS \ --priority=1000 \ --network=dm-stamford \ --action=ALLOW \ --rules=tcp:22,icmp \ --source-ranges=35.235.240.0/20

[進行状況を確認] をクリックして、目標を確認します。

Cloud ファイアウォール ルールと Cloud NAT を作成する

Cloud Router を作成する

• Cloud NAT の前提条件として、先に Cloud Router を各リージョンで構成しておく必要があります。

gcloud compute routers create router-stamford-nat-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}} \ --network=dm-stamford

Cloud NAT を構成する

• パブリック IP を持たない VM にインターネットでアクセスできるようにするには、該当するリージョンに Cloud NAT を作成する必要があります。

gcloud compute routers nats create nat-gw-dm-stamford-{{{project_0.default_region | REGION}}} \ --router=router-stamford-nat-{{{project_0.default_region | REGION}}} \ --router-region={{{project_0.default_region | REGION}}} \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges

作成される IDS VM にはパブリック IP が割り当てられません。これは、インターネットからアクセスできないようにするためですが、更新をダウンロードするにも、Suricata パッケージをインストールするにも、インターネットでアクセスする必要があります。

[進行状況を確認] をクリックして、目標を確認します。

Cloud Router を作成して Cloud NAT を構成する

タスク 3. 仮想マシンを作成する

ウェブサーバーのインスタンス テンプレートを作成する

• このテンプレートは、内に Ubuntu サーバーを準備して単純なウェブサービスをインストールするためのものです。

gcloud compute instance-templates create template-dm-stamford-web-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}} \ --network=dm-stamford \ --subnet=dm-stamford-{{{project_0.default_region | REGION}}} \ --machine-type=e2-small \ --image=ubuntu-1604-xenial-v20200807 \ --image-project=ubuntu-os-cloud \ --tags=webserver \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'

ウェブサーバーのマネージド インスタンス グループを作成する

• 次のコマンドで、前のステップで作成したインスタンス テンプレートを使用して 2 つのウェブサーバーを作成します。

gcloud compute instance-groups managed create mig-dm-stamford-web-{{{project_0.default_region | REGION}}} \ --template=template-dm-stamford-web-{{{project_0.default_region | REGION}}} \ --size=2 \ --zone={{{project_0.default_zone | "ZONE"}}}

IDS VM のインスタンス テンプレートを作成する

• このテンプレートは、内に、パブリック IP なしで Ubuntu サーバーを準備するためのものです。

gcloud compute instance-templates create template-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}} \ --network=dm-stamford \ --no-address \ --subnet=dm-stamford-{{{project_0.default_region | REGION}}}-ids \ --image=ubuntu-1604-xenial-v20200807 \ --image-project=ubuntu-os-cloud \ --tags=ids,webserver \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'

IDS VM のマネージド インスタンス グループを作成する

• 次のコマンドで、前のステップで作成したインスタンス テンプレートを使用して、IDS として構成する 1 つの VM を作成します。Suricata は、この後のセクションでインストールします。

gcloud compute instance-groups managed create mig-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --template=template-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --size=1 \ --zone={{{project_0.default_zone | "ZONE"}}}

[進行状況を確認] をクリックして、目標を確認します。

仮想マシンを作成する

タスク 4. 内部ロードバランサを作成する

Packet Mirroring では、ミラーリングされたトラフィックをコレクタのグループに転送するために、内部ロードバランサ（ILB）を使用します。この例では、コレクタ グループに含まれる VM は 1 つだけです。

1. バックエンド サービスの基本的なヘルスチェックを作成します。

gcloud compute health-checks create tcp hc-tcp-80 --port 80

2. ILB として使用するバックエンド サービスのグループを作成します。

gcloud compute backend-services create be-dm-stamford-suricata-{{{project_0.default_region | REGION}}} \ --load-balancing-scheme=INTERNAL \ --health-checks=hc-tcp-80 \ --network=dm-stamford \ --protocol=TCP \ --region={{{project_0.default_region | REGION}}}

3. 作成した IDS マネージド インスタンス グループを、前のステップで作成したバックエンド サービス グループに追加します。

gcloud compute backend-services add-backend be-dm-stamford-suricata-{{{project_0.default_region | REGION}}} \ --instance-group=mig-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --instance-group-zone={{{project_0.default_zone | "ZONE"}}} \ --region={{{project_0.default_region | REGION}}}

4. 収集エンドポイントとして機能するフロントエンドの転送ルールを作成します。

gcloud compute forwarding-rules create ilb-dm-stamford-suricata-ilb-{{{project_0.default_region | REGION}}} \ --load-balancing-scheme=INTERNAL \ --backend-service be-dm-stamford-suricata-{{{project_0.default_region | REGION}}} \ --is-mirroring-collector \ --network=dm-stamford \ --region={{{project_0.default_region | REGION}}} \ --subnet=dm-stamford-{{{project_0.default_region | REGION}}}-ids \ --ip-protocol=TCP \ --ports=all Note: Even though TCP is listed as the protocol, the actual type of mirrored traffic will be configured in the Packet Mirror Policy in a future section. また、--is-mirroring-collector,フラグが設定されている点にも注意してください。

[進行状況を確認] をクリックして、目標を確認します。

内部ロードバランサを作成する

タスク 5. オープンソースの IDS として Suricata をインストールする

注: 次の 2 つのセクションでは、IDS VM に SSH で接続し、そのシェルでコマンドを実行します。Cloud Shell でコマンドを実行しないよう注意してください。

IDS VM に SSH で接続する

1. Cloud コンソールのナビゲーション メニューから、[Compute Engine] > [VM インスタンス] に移動します。

2. IDS VM の [SSH] ボタンをクリックします。

新しいウィンドウが開きます。このウィンドウを使用して、IDS VM 内部でコマンドを実行できます。

3. IDS VM を更新します。

sudo apt-get update -y

4. Suricata の依存関係をインストールします。

sudo apt-get install libpcre3-dbg libpcre3-dev autoconf automake libtool libpcap-dev libnet1-dev libyaml-dev zlib1g-dev libcap-ng-dev libmagic-dev libjansson-dev libjansson4 -y sudo apt-get install libnspr4-dev -y sudo apt-get install libnss3-dev -y sudo apt-get install liblz4-dev -y sudo apt install rustc cargo -y

5. Suricata をインストールします。

sudo add-apt-repository ppa:oisf/suricata-stable -y sudo apt-get update -y sudo apt-get install suricata -y 注: インストール中にエラーが表示された場合は、次のステップに進んで検証を行ってください。

インストールを確認する

• 次のコマンドで、インストールを確認し、インストールされている Suricata のバージョンを調べます。

suricata -V

出力は次のようになります。

This is Suricata version 5.0.3 RELEASE

タスク 6. Suricata を構成して確認する

このセクションのコマンドと手順も、IDS/Suricata VM の SSH 内で行う必要があります。

• Suricata サービスを停止して、デフォルトの構成ファイルをバックアップします。

sudo systemctl stop suricata sudo cp /etc/suricata/suricata.yaml /etc/suricata/suricata.backup

新しい Suricata 構成ファイルと簡略版のルールファイルをダウンロードして置き換える

新しい構成ファイルによりコレクタ インターフェースが更新されるだけでなく、my.rules ファイルと suricata.yaml ファイルで構成された、ごく一部のトラフィックに対するアラートがオンになります。デフォルトの Suricata ルールセットとアラートはかなり広範で、このラボには不要なものもあります。

• 次のコマンドを実行してファイルをコピーしてください。

wget https://storage.googleapis.com/tech-academy-enablement/GCP-Packet-Mirroring-with-OpenSource-IDS/suricata.yaml wget https://storage.googleapis.com/tech-academy-enablement/GCP-Packet-Mirroring-with-OpenSource-IDS/my.rules sudo mkdir /etc/suricata/poc-rules sudo cp my.rules /etc/suricata/poc-rules/my.rules sudo cp suricata.yaml /etc/suricata/suricata.yaml

Suricata サービスを起動する

サービスの再起動が必要になることがあります。その可能性を考慮して、この手順には restart コマンドを記載しています。

sudo systemctl start suricata sudo systemctl restart suricata

テスト対象の単純な Suricata ルールを確認する

このラボ用に、Suricata のルールセットは 4 つにまでトリミングされていますが、デフォルトの Suricata インストールには膨大で広範なルールセットが含まれています。

• 1 つひとつのルールを簡単にテストできるよう、このラボの演習で使用するアラートルールは、このように簡潔で短いリストに要約しています。

cat /etc/suricata/poc-rules/my.rules

出力には全部で 4 つのルールとそれぞれの説明が示されます。

####RULES##### #UDP ALERTS alert udp $HOME_NET any -> 8.8.8.8 53 (msg:"BAD UDP DNS REQUEST"; sid:99996; rev:1;) #HTTP ALERTS alert http any any -> $HOME_NET 80 (msg:"BAD HTTP PHP REQUEST"; http.uri; content:"index.php"; sid:99997; rev:1;) #ICMP ALERTS alert icmp any any -> $HOME_NET any (msg:"BAD ICMP"; sid:99998; rev:1;) #TCP ALERTS alert tcp $HOME_NET any -> any 6667 (msg:"BAD TCP 6667 REQUEST"; sid:99999; rev:1;) 注: 通常、標準のルールファイルは /etc/suricata/rules/ または /var/lib/suricata/rules に配置されています。このラボではステップ 2 で、ファイルの場所を再構成して変更しています。

タスク 7. Packet Mirroring ポリシーを構成する

このセクションでは、再度 Cloud Shell を使用する

パケット ミラーリング ポリシーの設定は、1 つの単純なコマンドで（または GUI の「ウィザード」に従って）完了できます。このコマンドでは、Packet Mirroring の「概要」セクションに一覧されている 5 つの属性すべてを指定します。

• リージョン
• VPC ネットワーク
• ミラーリング対象のソース
• コレクタ（宛先）
• ミラーリング対象のトラフィック（フィルタ）

以下のコマンドに「ミラーリングするトラフィック」が含まれていないのは、「すべて」のトラフィックをミラーリングするようにポリシーを構成することから、フィルタは必要ないためです。このポリシーでは、上り（内向き）トラフィックと下り（外向き）トラフィックの両方をミラーリングして、コレクタ ILB の一部となっている Suricata IDS デバイスに転送します。

• Cloud Shell で以下のコマンドを実行して、Packet Mirroring ポリシーを構成します。

gcloud compute packet-mirrorings create mirror-dm-stamford-web \ --collector-ilb=ilb-dm-stamford-suricata-ilb-{{{project_0.default_region | REGION}}} \ --network=dm-stamford \ --mirrored-subnets=dm-stamford-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}}

この時点で、Packet Mirroring と Suricata の構成が完了します。以降のセクションで、両方の構成をテストします。

[進行状況を確認] をクリックして、目標を確認します。

Packet Mirroring ポリシーを構成する

タスク 8. Packet Mirroring をテストする

このセクションでは、IDS VM シェルにアクセスする必要があります。シェル ウィンドウがまだ開いている場合は、それを使用してください。シェル ウィンドウを閉じた場合は、再接続します。

また、「インターネット クライアント」として機能する Cloud Shell を使用する必要もあります。

少し時間をかけて、両方の WEB VM の外部 IP を確認します。

Cloud コンソールのナビゲーション メニューから、Compute Engine > VM インスタンスの順にクリックし、両方の WEB VM の外部 IPs を書き留めます。それぞれ [PUBLIC_IP_WEB1]、[PUBLIC_IP_WEB2] と表記されています。

Cloud Shell で次の gcloud コマンドを使用しても、同じ情報を取得できます。

gcloud compute instances list

IDS VM シェルに戻る

Packet Mirroring をテストする

• IDS/Suricata VM で、次のフィルタを使用してパケット キャプチャ（tcpdump）を実行します。

sudo tcpdump -i ens4 -nn -n "(icmp or port 80) and net 172.21.0.0/24" 注: 172.21.0.0/24 ネットワークはミラーリング対象のサブネットで、IDS VM はサブネットには属していませんが、Packet Mirroring が正しく構成されていれば、このサブネットのミラーリングされたトラフィックを受信します。

「ミラーリング対象」のサブネットへのトラフィックを生成する

1. Cloud Shell ターミナルを使用して、WEB1 に割り当てられたパブリック アドレスに対して ping を実行します。[PUBLIC_IP_WEB1] の部分は、「WEB1」のパブリック IP アドレスで置き換えてください。パブリック IP アドレスは Cloud コンソールで確認できます。

sudo apt install iputils-ping ping -c 4 [PUBLIC_IP_WEB1]

Packet Mirroring により、トラフィックが複製されて IDS VM に転送されます。トラフィックが転送されたことは、ステップ 1 のパケット キャプチャで確認できます。IDS VM での出力は次のようになります。X.X.X.X は、ICMP リクエストの送信元 IP アドレスです。tcpdump の出力に、ウェブサーバーのプライベート IP が示されていることを確認してください。Google Cloud はネットワーク変換をエッジで行います。

00:55:32.980666 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 0, length 64 00:55:32.980801 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 0, length 64 00:55:33.968920 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 1, length 64 00:55:33.968965 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 1, length 64 00:55:34.980472 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 2, length 64 00:55:34.980521 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 2, length 64 00:55:35.986354 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 3, length 64 00:55:35.986445 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 3, length 64

---

WEB2 のパブリック アドレスに対して ping を実行する場合も同様です。

2. WEB2 に割り当てられたパブリック IP アドレスに対して ping を実行するには、[PUBLIC_IP_WEB2] の部分を「WEB2」のパブリック IP アドレスで置き換えます。

ping -c 4 [PUBLIC_IP_WEB2]

Packet Mirroring により、トラフィックが IDS VM に転送されます。トラフィックが転送されたことは、ステップ 1 のパケット キャプチャで確認できます。IDS VM での出力は次のようになります。tcpdump の出力に、ウェブサーバーのプライベート IP が示されていることを確認してください。Google Cloud はネットワーク変換をエッジで行います。

00:00:45.309407 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 0, length 64 00:00:45.309736 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 0, length 64 00:00:46.309406 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 1, length 64 00:00:46.309602 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 1, length 64 00:00:47.306278 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 2, length 64 00:00:47.306406 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 2, length 64 00:00:48.314506 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 3, length 64 00:00:48.314698 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 3, length 64

Packet Mirroring で確認できるのはレイヤ 3 のヘッダーだけではないことを実証するために、次のテストでは一方のウェブサーバーに対して標準の HTTP GET リクエストを行い、初期の TCP 3-way handshake を含む出力を生成します。

1. ブラウザで新しいタブを開き、HTTP プロトコルで WEB1 に割り当てられたパブリック アドレスにアクセスします。Cloud Console で「curl」ユーティリティを使用することもできます。

2. [PUBLIC_IP_WEB1] の部分は、「WEB1」のパブリック IP アドレスで置き換えます。

http://[PUBLIC_IP_WEB1]/

Packet Mirroring により、トラフィックが IDS VM に転送されます。トラフィックが転送されたことは、ステップ 1 のパケット キャプチャで確認できます。

IDS VM での出力は次のようになります。

00:00:46.761748 IP X.X.X.60835 > 172.21.0.2.80: Flags [S]... 00:00:46.763037 IP 172.21.0.2.80 > X.X.X.60835: Flags [S.], ... ack ... 00:00:46.816407 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ... 00:00:46.823624 IP X.X.X.60835 > 172.21.0.2.80: Flags [P.], ... HTTP: GET / HTTP/1.1 00:00:46.823832 IP 172.21.0.2.80 > X.X.X.60835: Flags [.], ack ... 00:00:46.824549 IP 172.21.0.2.80 > X.X.X.60835: Flags [P.], ... HTTP: HTTP/1.1 200 OK 00:00:46.879214 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ... 00:00:46.888477 IP X.X.X.60835 > 172.21.0.2.80: Flags [F.], ... 00:00:46.888662 IP 172.21.0.2.80 > X.X.X.60835: Flags [F.], ... ack... 00:00:46.943915 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ...

---

3. WEB2 のパブリック アドレスにアクセスする場合も同様です。[PUBLIC_IP_WEB2] の部分は、「WEB2」のパブリック IP アドレスで置き換えます。

http://[PUBLIC_IP_WEB2]/

Packet Mirroring により、トラフィックが IDS VM に転送されます。トラフィックが転送されたことは、ステップ 1 のパケット キャプチャで確認できます。

IDS VM での出力は次のようになります。

00:00:58.819740 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [S]... 00:00:58.820027 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [S.], ... ack ... 00:00:58.875301 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [.], ack ... 00:00:58.875329 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [P.], ... HTTP: GET / HTTP/1.1 00:00:58.875448 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [.], ack ... 00:00:58.876204 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [P.], ... HTTP: HTTP/1.1 200 OK 00:00:58.929015 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [.], ack ... 00:00:58.929047 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [F.], ... 00:00:58.929244 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [F.], ... ack... 00:00:58.993844 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [.], ack ...

IDS VM 内部で Ctrl+c キーを押して tcpdump を終了します。

タスク 9. Suricata IDS の検査とアラートをテストする

このラボの最後のセクションでは、Packet Mirroring とオープンソース IDS の Suricata との統合をテストします。「Suricata を構成して確認する」セクションのステップ 4 でアラート対象として設定した、4 つの Suricata ルールを確認してください。

####RULES##### #UDP ALERTS alert udp $HOME_NET any -> 8.8.8.8 53 (msg:"BAD UDP DNS REQUEST"; sid:99996; rev:1;) #HTTP ALERTS alert http any any -> $HOME_NET 80 (msg:"BAD HTTP PHP REQUEST"; http.uri; content:"index.php"; sid:99997; rev:1;) #ICMP ALERTS alert icmp any any -> $HOME_NET any (msg:"BAD ICMP"; sid:99998; rev:1;) #TCP ALERTS alert tcp $HOME_NET any -> any 6667 (msg:"BAD TCP 6667 REQUEST"; sid:99999; rev:1;)

次の 4 つの手順に沿って、上記のルールのそれぞれをトリガーするネットワーク トラフィックを生成します。ルールごとのアラートは、Suricata イベントログ ファイルで確認できます。

注: IDS VM とウェブサーバー VM の SSH ウィンドウが両方とも開いていることを確認してください。このセクションを完了するには、両方のウィンドウを同時に確認する必要があります。

テスト 1 とテスト 2 はウェブサーバーで開始して、外向きトラフィックをテストします。

テスト 3 とテスト 4 は Cloud Shell で開始して、内向きトラフィックをテストします。

テスト 1: 外向き UDP ルール / アラートをテストする

1. いずれかのウェブサーバーで次のコマンドを実行して、外向き DNS トラフィックを生成します。

dig @8.8.8.8 example.com

2. IDS VM 上の Suricata イベントログ ファイルで、アラートを確認します。

IDS VM の SSH ウィンドウに切り替えます。

3. IDS VM の SSH ウィンドウで次のコマンドを実行します。

egrep "BAD UDP DNS" /var/log/suricata/eve.json

次のようなログエントリが記録されていることを確認します。

@GCP: {"timestamp":"2020-08-14T01:23:14.903210+0000","flow_id":412864167987242,"in_iface":"ens4","event_type":"alert","src_ip":"172.21.0.2","src_port":47020,"dest_ip":"8.8.8.8","dest_port":53,"proto":"UDP","alert":{"action":"allowed","gid":1,"signature_id":99996,"rev":1,"signature":"BAD UDP DNS REQUEST","category":"","severity":3},"dns":{"query":[{"type":"query","id":17268,"rrname":"EXAMPLE.COM","rrtype":"A","tx_id":0}]},"app_proto":"dns","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":82,"bytes_toclient":0,"start":"2020-08-19T18:23:14.903210+0000"}}

テスト 2: 外向き「TCP」ルール / アラートをテストする

1. いずれかのウェブサーバーから次のコマンドを実行して、外向き TCP トラフィックを生成します。

telnet 100.64.1.1 6667

2. Ctrl+c キーを押して終了します。

3. IDS VM 上の Suricata イベントログ ファイルで、アラートを確認します。

IDS VM の SSH ウィンドウに切り替えます。

4. IDS VM の SSH ウィンドウで次のコマンドを実行します。

egrep "BAD TCP" /var/log/suricata/eve.json

次のようなログエントリが記録されていることを確認します。

@GCP: {"timestamp":"2020-08-14T01:27:45.058526+0000","flow_id":479376049300638,"in_iface":"ens4","event_type":"alert","src_ip":"172.21.0.2","src_port":36168,"dest_ip":"100.64.1.1","dest_port":6667,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":99999,"rev":1,"signature":"BAD TCP 6667 REQUEST","category":"","severity":3},"flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":74,"bytes_toclient":0,"start":"2020-08-19T18:27:45.058526+0000"}}

テスト 3: 内向き「ICMP」ルール / アラートをテストする

1. Cloud Shell で次のコマンドを実行して内向き ICMP トラフィックを生成します。

2. [PUBLIC_IP_WEB1] の部分は、「WEB1」のパブリック IP アドレスで置き換えます。

ping -c 3 [PUBLIC_IP_WEB1]

3. IDS VM 上の Suricata イベントログ ファイルで、アラートを確認します。

egrep "BAD ICMP" /var/log/suricata/eve.json

次のようなログエントリが記録されていることを確認します。

@GCP: {"timestamp":"2020-08-14T01:24:46.065250+0000","flow_id":1114966772874978,"in_iface":"ens4","event_type":"alert","src_ip":"X.X.X.X","dest_ip":"172.21.0.2","proto":"ICMP","icmp_type":8,"icmp_code":0,"alert":{"action":"allowed","gid":1,"signature_id":99998,"rev":1,"signature":"BAD ICMP","category":"","severity":3},"flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":98,"bytes_toclient":0,"start":"2020-08-19T18:24:46.065250+0000"}}

テスト 4: 内向き「HTTP」ルール / アラートをテストする

ローカル ワークステーションのウェブブラウザを使用するか、Cloud Shelll で curl を使用して、HTTP プロトコルで WEB1 のページ「index.php」に割り当てられたパブリック アドレスにアクセスします。

1. [PUBLIC_IP_WEB1] の部分は、「WEB1」のパブリック IP アドレスで置き換えます。

http://[PUBLIC_IP_WEB1]/index.php

2. IDS VM 上の Suricata イベントログ ファイルで、アラートを確認します。

egrep "BAD HTTP" /var/log/suricata/eve.json

次のようなログエントリが記録されていることを確認します。

@GCP: {"timestamp":"2020-08-14T01:26:36.794124+0000","flow_id":1901424684045611,"in_iface":"ens4","event_type":"alert","src_ip":"X.X.X.X","src_port":61132,"dest_ip":"172.21.0.3","dest_port":80,"proto":"TCP","tx_id":0,"alert":{"action":"allowed","gid":1,"signature_id":99997,"rev":1,"signature":"BAD HTTP PHP REQUEST","category":"","severity":3},"http":{"hostname":"PUBLIC_IP_WEB1","url":"\/index.php","http_user_agent":"curl\/7.64.1","http_content_type":"text\/html","http_method":"GET","protocol":"HTTP\/1.1","status":404,"length":275},"app_proto":"http","flow":{"pkts_toserver":7,"pkts_toclient":6,"bytes_toserver":658,"bytes_toclient":1284,"start":"2020-08-19T18:26:36.660779+0000"}}

お疲れさまでした

これで、ラボ「Google Cloud Packet Mirroring use with the Open Source IDS Suricata」は完了です。

クエストを完了する

このセルフペース ラボは「Security & Identity Fundamentals」クエストと「Networking in Google Cloud」クエストの構成要素です。クエストとは学習プログラムを構成する一連のラボのことで、完了すると成果が認められて上のようなバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクできます。このラボの修了後、このラボが含まれるクエストに登録すれば、すぐにクレジットを受け取ることができます。受講可能なすべてのクエストについては、Google Cloud Skills Boost カタログをご覧ください。

次のラボを受講する

「Multiple VPC Networks」に進んでクエストを続けるか、以下の Google Cloud Skills Boost のラボをご確認ください。

• Setting Up a Private Kubernetes Cluster
• Getting Started with Cloud KMS

次のステップと詳細情報

Packet Mirroring について詳しくは、以下をご覧ください。

• Packet Mirroring の概要

• Packet Mirroring を使用する

Suricata について詳しくは、https://suricata-ids.org/ にアクセスしてください。

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2023 年 9 月 6 日

ラボの最終テスト日: 2023 年 9 月 6 日

Copyright 2024 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。