GSP879

概要

Google Cloud Armor は、DDoS 保護、WAF ルールの適用、柔軟な適応型管理機能を提供する Google のエンタープライズ エッジ ネットワーク セキュリティ ソリューションです。

Cloud Armor では、OWASP トップ 10 で挙げられているウェブ アプリケーションのセキュリティ脆弱性を軽減するために、構成済みの WAF ルールセットが拡張されています。このルールセットは、OWASP Modsecurity コアルール セット バージョン 3.0.2 に基づいており、最も一般的なセキュリティ リスク（ローカル ファイル インクルード（LFI）、リモート ファイル インクルード（RFI）、リモートコード実行（RCE）など）からウェブ アプリケーションを保護するためのルールです。

このラボでは、Google Cloud Armor WAF ルールを使用して、一般的な脆弱性を軽減する方法について学びます。

学習内容

このラボでは、次の方法について学びます。

• サービスをサポートするインスタンス グループとグローバル ロードバランサを設定する
• 事前構成の WAF ルールを使用して、LFI、RCE、スキャナ、プロトコル攻撃、セッション固定を防止するための Cloud Armor セキュリティ ポリシーを構成する
• ログを観察して、Cloud Armor が攻撃を軽減したことを検証する

OWASP Juice Shop アプリケーションは、セキュリティの学習やトレーニングに役立つツールです。OWASP トップ 10 に挙げられているセキュリティの脆弱性が意図的に埋め込まれていて、攻撃者の視点でそれらを発見し、テスト目的で悪用することができます。このラボでは、これを使用してアプリケーション攻撃を実演してから、Cloud Armor WAF ルールを適用してアプリケーションを保護します。アプリケーションのフロントエンドに Google Cloud ロードバランサを配置し、Cloud Armor のセキュリティ ポリシーとルールを適用します。公共のインターネット上で公開しているため、ほぼどこからでもアクセスできるこのアプリケーションを、Cloud Armor と VPC ファイアウォール ルールを使用して保護します。

設定と要件

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

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

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

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

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

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

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。

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

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

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

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。

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

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

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] ペインでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] ペインでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

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

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

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

Cloud Shell をアクティブにする

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

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

2. ウィンドウで次の操作を行います。

   • Cloud Shell 情報ウィンドウで操作を進めます。
   • Cloud Shell が認証情報を使用して Google Cloud API を呼び出すことを承認します。

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

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

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

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

gcloud auth list

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

出力:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

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

gcloud config list project

出力:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

始める前に

• Cloud Shell で、プロジェクト ID を設定します。

gcloud config list project export PROJECT_ID=$(gcloud config get-value project) echo $PROJECT_ID gcloud config set project $PROJECT_ID

タスク 1. VPC ネットワークを作成する

• Cloud Shell で、次のコマンドを入力して VPC ネットワークを作成します。

gcloud compute networks create {{{project_0.startup_script.network_name| Network Name}}} --subnet-mode custom Created NAME SUBNET_MODE BGP_ROUTING_MODE {{{project_0.startup_script.network_name| Network Name}}} CUSTOM REGIONAL

サブネットを作成する

• Cloud Shell で、次のコマンドを入力してサブネットを作成します。

gcloud compute networks subnets create {{{project_0.startup_script.subnet_name| Subnet Name}}} \ --network {{{project_0.startup_script.network_name| Network Name}}} --range 10.0.0.0/24 --region {{{project_0.startup_script.region_1| Region}}} Created NAME REGION NETWORK RANGE {{{project_0.startup_script.subnet_name| Subnet Name}}} {{{project_0.startup_script.region_1| Region}}} {{{project_0.startup_script.network_name| Network Name}}} 10.0.0.0/24

VPC ファイアウォール ルールを作成する

VPC とサブネットを作成したら、ファイアウォール ルールをいくつか設定します。

• 最初のファイアウォール ルールは allow-js-site という名前で、ポート 3000 ですべての IP がテスト アプリケーションのウェブサイトの外部 IP にアクセスすることを許可します。
• 2 つ目のファイアウォール ルールは allow-health-check という名前で、ロードバランサの送信元 IP からのヘルスチェックを許可します。

1. Cloud Shell で次のコマンドを入力して、すべての IP にアプリケーションへのアクセスを許可するファイアウォール ルールを作成します。

gcloud compute firewall-rules create {{{project_0.startup_script.firewall_rule| Firewall Name}}} --allow tcp:3000 --network {{{project_0.startup_script.network_name| Network Name}}}

出力:

Creating firewall...done. NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED {{{project_0.startup_script.firewall_rule| Firewall Name}}} {{{project_0.startup_script.network_name| Network Name}}} INGRESS 1000 tcp:3000 False

2. Cloud Shell で、次のコマンドを入力して、Google のヘルスチェックの範囲からのヘルスチェックを許可するファイアウォール ルールを作成します。

gcloud compute firewall-rules create {{{project_0.startup_script.firewall_rule1| Firewall Name1}}} \ --network={{{project_0.startup_script.network_name| Network Name}}} \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-healthcheck \ --rules=tcp

出力:

Creating firewall...done. NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED {{{project_0.startup_script.firewall_rule1| Firewall_Name1}}} {{{project_0.startup_script.network_name| Network Name}}} INGRESS 1000 tcp False

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 VPC ネットワークを作成する

タスク 2. テスト アプリケーションを設定する

テスト アプリケーション（ここでは OWASP Juice Shop ウェブサーバー）を作成します。コンピューティング インスタンスを作成する際に、コンテナ イメージを使用して、サーバーに適切なサービスが確実に含まれるようにします。このサーバーを にデプロイし、ヘルスチェックを可能にするネットワーク タグを設定します。

OWASP Juice Shop アプリケーションを作成する

• よく知られているオープンソースの OWASP Juice Shop アプリケーションを使い、脆弱なアプリケーションとして構成します。このアプリケーションは、OWASP ウェブサイトが主催する OWASP セキュリティ チャレンジに使われることもあります。

gcloud compute instances create-with-container {{{project_0.startup_script.vm_instance| vm_instance}}} --container-image bkimminich/juice-shop \ --network {{{project_0.startup_script.network_name| Network Name}}} \ --subnet {{{project_0.startup_script.subnet_name| Subnet Name}}} \ --private-network-ip=10.0.0.3 \ --machine-type n1-standard-2 \ --zone {{{project_0.startup_script.zone| Zone}}} \ --tags allow-healthcheck

出力:

NAME ZONE MACHINE_TYPE PREEMPTIBLE {{{project_0.startup_script.vm_instance| vm_instance}}} {{{project_0.startup_script.zone| Zone}}} n1-standard-2 INTERNAL_IP EXTERNAL_IP STATUS 10.0.0.3 RUNNING

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 テスト アプリケーションを設定する

Cloud ロードバランサ コンポーネントを設定する: インスタンス グループ

1. Cloud Shell で次のコマンドを入力して、非マネージド インスタンス グループを作成します。

gcloud compute instance-groups unmanaged create {{{project_0.startup_script.vm_instance_group| Instance Group}}} \ --zone={{{project_0.startup_script.zone| Zone}}}

出力:

NAME LOCATION SCOPE NETWORK MANAGED INSTANCES {{{project_0.startup_script.vm_instance_group| Instance Group}}} {{{project_0.startup_script.zone| Zone}}} zone 0

2. Juice Shop の Google Compute Engine（GCE）インスタンスを非マネージド インスタンス グループに追加します。

gcloud compute instance-groups unmanaged add-instances {{{project_0.startup_script.vm_instance_group| Instance Group}}} \ --zone={{{project_0.startup_script.zone| Zone}}} \ --instances={{{project_0.startup_script.vm_instance| VM Instance}}}

出力:

Updated [https://www.googleapis.com/compute/v1/projects//zones/{{{project_0.startup_script.zone| Zone}}}/instanceGroups/{{{project_0.startup_script.vm_instance_group| Instance_Group}}}].

3. 名前付きポートを Juice Shop アプリケーションのポートに設定します。

gcloud compute instance-groups unmanaged set-named-ports \ {{{project_0.startup_script.vm_instance_group| Instance Group}}} \ --named-ports=http:3000 \ --zone={{{project_0.startup_script.zone| Zone}}}

出力:

Updated [https://www.googleapis.com/compute/v1/projects//zones/{{{project_0.startup_script.zone| Zone}}}/instanceGroups/{{{project_0.startup_script.vm_instance_group| Instance Group}}}].

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud ロードバランサ コンポーネントを設定する: インスタンス グループ

Cloud ロードバランサ コンポーネントを設定する: ヘルスチェック

非マネージド インスタンス グループを作成したので、次はヘルスチェック、バックエンド サービス、URL マップ、ターゲット プロキシ、転送ルールを作成します。

• Cloud Shell で次のコマンドを入力して、Juice Shop サービスポートのヘルスチェックを作成します。

gcloud compute health-checks create tcp tcp-port-3000 \ --port 3000

出力:

Created NAME PROTOCOL tcp-port-3000 TCP

Cloud ロードバランサ コンポーネントを設定する: バックエンド サービス

1. Cloud Shell で次のコマンドを入力して、バックエンド サービスのパラメータを作成します。

gcloud compute backend-services create juice-shop-backend \ --protocol HTTP \ --port-name http \ --health-checks tcp-port-3000 \ --enable-logging \ --global

出力:

NAME BACKENDS PROTOCOL juice-shop-backend HTTP

2. Juice Shop インスタンス グループをバックエンド サービスに追加します。

gcloud compute backend-services add-backend juice-shop-backend \ --instance-group={{{project_0.startup_script.vm_instance_group| Instance Group}}} \ --instance-group-zone={{{project_0.startup_script.zone| Zone}}} \ --global

出力:

Updated [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/backendServices/juice-shop-backend].

Cloud ロードバランサ コンポーネントを設定する: URL マップ

• Cloud Shell で次のコマンドを入力して、受信リクエストをバックエンドに送信する URL マップを作成します。

gcloud compute url-maps create juice-shop-loadbalancer \ --default-service juice-shop-backend

出力:

NAME DEFAULT_SERVICE juice-shop-loadbalancer backendServices/juice-shop-backend

Cloud ロードバランサ コンポーネントを設定する: ターゲット プロキシ

• Cloud Shell で次のコマンドを入力して、URL マップに受信リクエストをルーティングするターゲット プロキシを作成します。

gcloud compute target-http-proxies create juice-shop-proxy \ --url-map juice-shop-loadbalancer

出力:

NAME URL_MAP juice-shop-proxy juice-shop-loadbalancer

Cloud ロードバランサ コンポーネントを設定する: 転送ルール

• Cloud Shell で次のコマンドを入力して、ロードバランサの転送ルールを作成します。

gcloud compute forwarding-rules create juice-shop-rule \ --global \ --target-http-proxy=juice-shop-proxy \ --ports=80

出力:

Created [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/forwardingRules/juice-shop-rule].

Juice Shop サービスがオンラインであることを確認する

1. Cloud Shell から:

PUBLIC_SVC_IP="$(gcloud compute forwarding-rules describe juice-shop-rule --global --format="value(IPAddress)")" echo $PUBLIC_SVC_IP

出力:

<public VIP of service>

数分待ってから続行してください。待たなければ、「HTTP/1.1 404 見つかりません」レスポンスが返される可能性があります。

2. Cloud Shell から:

curl -Ii http://$PUBLIC_SVC_IP

出力:

HTTP/1.1 200 OK <...>

ブラウザに移動して Juice Shop を表示することもできます。

これで、Juice Shop の脆弱性を調べ、Cloud Armor WAF ルールセットを適用して脆弱性を狙われないよう保護する準備が整いました。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud ロードバランサ コンポーネントを設定する: ヘルスチェック

タスク 3. 既知の脆弱性を実演する

このラボでは、Cloud Armor WAF ルールが伝播される前後の状態を、簡潔な手順で確認します。

LFI の脆弱性を確認する: パス トラバーサル

ローカル ファイル インクルードは、リクエストの入力を検証する機能に不備がある場合に、それを悪用してサーバー上にあるファイルを閲覧し、漏洩などの目的で機密データを読み込むことを可能にするプロセスです。次の例は、パス トラバーサルが可能であることを示しています。お使いのブラウザまたは curl で、このアプリケーションが既存のパスを提供してしまうことを確認します。

1. Cloud Shell から:

curl -Ii http://$PUBLIC_SVC_IP/ftp

出力:

HTTP/1.1 200 OK <...>

パス トラバーサルも可能であることを確認します。

2. Cloud Shell から:

curl -Ii http://$PUBLIC_SVC_IP/ftp/../

出力:

HTTP/1.1 200 OK <...>

RCE の脆弱性を確認する

リモートコード実行には、UNIX や Windows のコマンド インジェクションを発生させるさまざまな シナリオがあり、攻撃者はそれらを利用して、通常なら適切な権限を持つユーザーにのみ制限されている OS コマンドを実行します。単純な ls コマンドが実行されてしまう例を次に示します。

• Cloud Shell から:

curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls

出力:

HTTP/1.1 200 OK <...>

curl フラグを削除して、完全な出力を確認します。

よく知られたスキャナのアクセスを確認する

商用とオープンソースの両方のスキャン アプリケーションが、脆弱性の発見など、さまざまな目的で使用されています。これらのツールは、よく知られた User-Agent などのヘッダーを使用します。よく知られた User-Agent ヘッダーが、検査されずに動作してしまうことを curl で確認します。

• Cloud Shell から:

curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"

出力:

HTTP/1.1 200 OK <...>

プロトコル攻撃を観察する: HTTP 分割

一部のウェブ アプリケーションでは、ユーザーからの入力を利用してレスポンスのヘッダーを生成します。入力を適切にフィルタリングしないアプリケーションの場合、攻撃者は入力パラメータを %0d%0a シーケンス（行区切りのために使用される CRLF シーケンス）で汚染する可能性があります。

このレスポンスは、レスポンスを解析できるもの（中間プロキシ サーバーなど）に送信されると 2 つのレスポンスとして解釈され、後続のリクエストに偽のコンテンツが提供される可能性があります。入力パラメータにシーケンス %0d%0a を挿入すると、偽装されたページを提供してしまう可能性があります。

• Cloud Shell から:

curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"

出力:

HTTP/1.1 200 OK <...>

セッション固定を観察する

• Cloud Shell から:

curl -Ii http://$PUBLIC_SVC_IP -H session_id=X

出力:

HTTP/1.1 200 OK <...>

タスク 4. Cloud Armor WAF ルールを定義する

1. Cloud Shell で次のコマンドを使用して、事前構成された WAF ルールを一覧表示します。

gcloud compute security-policies list-preconfigured-expression-sets EXPRESSION_SET Sqli-canary RULE_ID owasp-crs-v030001-id942110-sqli owasp-crs-v030001-id942120-sqli <...>

2. Cloud Shell で次のコマンドを使用して、Cloud Armor セキュリティ ポリシーを作成します。

gcloud compute security-policies create {{{project_0.startup_script.policy_name| Policy Name}}} \ --description "Block with OWASP ModSecurity CRS"

3. Cloud Shell で、セキュリティ ポリシーのデフォルト ルールを更新します。

注: デフォルトのルールの優先度の数値は 2147483647 です。 gcloud compute security-policies rules update 2147483647 \ --security-policy {{{project_0.startup_script.policy_name| Policy Name}}} \ --action "deny-403"

4. デフォルト ルールはアクション拒否で構成されているため、自分の IP からのアクセスを許可する必要があります。次の方法でパブリック IP を確認します（curl、ipmonkey、whatismyip など）。

MY_IP=$(curl ifconfig.me)

5. 最初のルールを追加して、自分の IP からのアクセスを許可します（以下に自分の IP を挿入してください）。

gcloud compute security-policies rules create 10000 \ --security-policy {{{project_0.startup_script.policy_name| Policy Name}}} \ --description "allow traffic from my IP" \ --src-ip-ranges "$MY_IP/32" \ --action "allow"

6. Cloud Shell で、LFI 攻撃をブロックするようにセキュリティ ポリシーを更新します。

ローカル ファイル インクルードのパス トラバーサルを防止するために、OWASP ModSecurity Core Rule Set を適用します。

gcloud compute security-policies rules create 9000 \ --security-policy {{{project_0.startup_script.policy_name| Policy Name}}} \ --description "block local file inclusion" \ --expression "evaluatePreconfiguredExpr('lfi-stable')" \ --action deny-403

7. Cloud Shell で、リモートコード実行（RCE）をブロックするようにセキュリティ ポリシーを更新します。

OWASP ModSecurity Core Rule Set に従って、コマンド インジェクションなどの RCE を見つけるためのルールを適用します。一般的な OS コマンドを検出してブロックします。

gcloud compute security-policies rules create 9001 \ --security-policy {{{project_0.startup_script.policy_name| Policy Name}}} \ --description "block rce attacks" \ --expression "evaluatePreconfiguredExpr('rce-stable')" \ --action deny-403

8. セキュリティ ポリシーを更新して、セキュリティ スキャナをブロックします。

OWASP ModSecurity Core Rule Set を適用して、よく知られたセキュリティ スキャナ、スクリプト HTTP クライアント、ウェブ クローラをブロックします。

gcloud compute security-policies rules create 9002 \ --security-policy {{{project_0.startup_script.policy_name| Policy Name}}} \ --description "block scanners" \ --expression "evaluatePreconfiguredExpr('scannerdetection-stable')" \ --action deny-403

9. Cloud Shell で、プロトコル攻撃をブロックするようにセキュリティ ポリシーを更新します。

OWASP ModSecurity Core Rule Set に従って、キャリッジ リターン（CR）の %0d とラインフィード（LF）の %0a の文字や、HTTP リクエスト スマグリングなどの他のタイプのプロトコル攻撃を検出するルールを適用します。

gcloud compute security-policies rules create 9003 \ --security-policy {{{project_0.startup_script.policy_name| Policy Name}}} \ --description "block protocol attacks" \ --expression "evaluatePreconfiguredExpr('protocolattack-stable')" \ --action deny-403

10. セッション固定をブロックするようにセキュリティ ポリシーを更新します。

OWASP ModSecurity Core Rule Set に従って、Cloud Shell を使用して次のルールを適用します。

gcloud compute security-policies rules create 9004 \ --security-policy {{{project_0.startup_script.policy_name| Policy Name}}} \ --description "block session fixation attacks" \ --expression "evaluatePreconfiguredExpr('sessionfixation-stable')" \ --action deny-403

11. セキュリティ ポリシーをバックエンド サービスに接続します。

gcloud compute backend-services update juice-shop-backend \ --security-policy {{{project_0.startup_script.policy_name| Policy Name}}} \ --global

ルールの伝播に時間がかかる場合があります（ただし 10 分以内）。

12. 十分な時間が経過したら次のステップに進み、先に実演した脆弱性をテストして、Cloud Armor WAF ルールが適用されていることを確認しましょう。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Armor セキュリティ ポリシーを作成する

OWASP ModSecurity Core Rule Set による Cloud Armor の保護を確認する

1. Cloud Shell で、LFI の脆弱性が軽減されたことを確認します。

curl -Ii http://$PUBLIC_SVC_IP/?a=../

出力:

HTTP/1.1 403 Forbidden <...>

2. Cloud Shell で、RCE 攻撃が軽減されていることを確認します。

curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls

出力:

HTTP/1.1 403 Forbidden <..>

3. Cloud Shell で、よく知られたスキャナの検出を確認します。

curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"

出力:

HTTP/1.1 403 Forbidden <..>

4. Cloud Shell で、プロトコル攻撃が軽減されたことを確認します。

OWASP ModSecurity Core Rule Set ver.3.0.2 により、プロトコル攻撃は次のように軽減されます。

curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"

出力:

HTTP/1.1 403 Forbidden <..>

5. Cloud Shell で、セッション固定化の試みがブロックされていることを確認します。

curl -Ii http://$PUBLIC_SVC_IP/?session_id=a

出力:

HTTP/1.1 403 Forbidden <..>

タスク 5. Cloud Armor セキュリティ ルールを確認する

セキュリティ ポリシーを作成したので、どのようなルールが構成されているか確認してみましょう。

ルールは優先度の値が小さいものから先に評価されます。ルールがトリガーされると、そのルールより優先度の値が大きいルールが続けて処理されることはありません。

• 優先度 9000 - LFI（ローカル ファイル インクルード）をブロックする
• 優先度 9001 - RCE（リモートコード実行 / コマンド インジェクション）をブロックする
• 優先度 9002 - 検出されたスキャナをブロックする
• 優先度 9003 - HTTP 分割や HTTP スマグリングなどのプロトコル攻撃をブロックする
• 優先度 9004 - セッション固定攻撃をブロックする
• 優先度 10000 - IP からウェブサイトへのアクセスを許可する
• 優先度 デフォルト - 拒否。

注: 「IP を許可」ルールは優先度の値が最大で、サイトへのアクセス許可し、攻撃をすべてブロックするように構成されています。

タスク 6. Cloud Armor セキュリティ ポリシーのログを確認する

Cloud Armor コンソール ページで、セキュリティ ポリシーの詳細を表示し、[ログ] タブをクリックして [ポリシーログを表示] リンクをクリックすると、Cloud Logging のページに移動します。関心のあるセキュリティ ポリシーに基づいて自動的にフィルタリングされます（例: resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:）。403 エラー レスポンス コードを確認し、ログの詳細を表示して、適用されたセキュリティ ポリシーの名前、一致したフィールド値、さらに下にある事前構成された式 ID（またはシグネチャ ID）を確認します。

関心のあるセキュリティ ポリシーに基づいて自動的にフィルタリングされます（例: resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:()）。

• 403 エラー レスポンス コードを確認し、ログの詳細を表示して、適用されたセキュリティ ポリシーの名前、一致したフィールド値、さらに下にある事前構成された式 ID（またはシグネチャ ID）を確認します。

次のスクリーンショットは、このラボで構成され適用されたセキュリティ ポリシーのログの例を示しています。

LFI のログ

RCE のログ

スキャナ検出のログ

プロトコル攻撃のログ

セッション固定のログ

お疲れさまでした

Google Cloud Armor WAF ルールを使用して、一般的な脆弱性の一部を軽減することができました。

マニュアルの最終更新日: 2025 年 5 月 12 日

ラボの最終テスト日: 2025 年 5 月 12 日

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