Cloud Armor の事前構成 WAF ルールの Codelab

1. はじめに

こんにちは。Cloud Armor の事前構成 WAF ルールの Codelab へようこそ。

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

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

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

学習内容

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

必要なもの

Google Compute Engine に関する基本的な知識（ハンズオンラボ）
ネットワークと TCP/IP に関する基本的な知識
Unix / Linux コマンドラインに関する基本的な知識
Networking in the Google Cloud で GCP のネットワーキングのツアーを完了していると、手順を進める上で役立ちます。
（省略可）Cloudnet20 Cloud Armor ラボを完了して、SQL インジェクション、IP ベース、位置情報ベースのルールでワークロードを保護する方法を学習します。

Codelab のトポロジとユースケース

図 1 - Cloud Armor WAF ルールの Codelab トポロジ

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

2. 設定と要件

セルフペース型の環境設定

Cloud コンソールにログインして、新しいプロジェクトを作成するか、既存のプロジェクトを再利用しますGmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

プロジェクト ID を忘れないようにしてください。プロジェクト ID はすべての Google Cloud プロジェクトを通じて一意の名前にする必要があります（上記の名前はすでに使用されているので使用できません）。以降、このコードラボでは PROJECT_ID と呼びます。

次に、Google Cloud リソースを使用するために、Cloud Console で課金を有効にする必要があります。

このコードラボを実行しても、費用はほとんどかからないはずです。このチュートリアル以外で請求が発生しないように、リソースのシャットダウン方法を説明する「クリーンアップ」セクションの手順に従うようにしてください。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアルプログラムをご利用いただけます。

Cloud Shell の起動

Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。

GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。

プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。

この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホームディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。

始める前に

Cloud Shell で、プロジェクト ID が設定されていることを確認します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
PROJECT_ID=[YOUR-PROJECT-NAME]
echo $PROJECT_ID

API を有効にする

必要なサービスをすべて有効にする

gcloud services enable compute.googleapis.com
gcloud services enable logging.googleapis.com        
gcloud services enable monitoring.googleapis.com

3. VPC ネットワークを作成する

VPC ネットワークを作成する

Cloud Shell から

gcloud compute networks create ca-lab-vpc --subnet-mode custom

出力

Created
NAME        SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
ca-lab-vpc  CUSTOM       REGIONAL

サブネットを作成する

Cloud Shell から

gcloud compute networks subnets create ca-lab-subnet \
        --network ca-lab-vpc --range 10.0.0.0/24 --region us-central1

出力

Created 
NAME           REGION       NETWORK       RANGE
ca-lab-subnet  us-central1  ca-lab-vpc    10.0.0.0/24

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

VPC とサブネットを作成したら、ファイアウォールルールをいくつか設定します。最初のファイアウォールルールは、すべての IP がポート 3000 でテストアプリケーションのウェブサイトの外部 IP にアクセスできるようにするために使用されます。2 つ目のファイアウォールルールは、ロードバランサの送信元 IP からのヘルスチェックを許可するために使用されます。

Cloud Shell から

gcloud compute firewall-rules create allow-js-site --allow tcp:3000 --network ca-lab-vpc

出力

Creating firewall...done.
NAME           NETWORK     DIRECTION  PRIORITY  ALLOW     DENY  DISABLED
allow-js-site  ca-lab-vpc  INGRESS    1000      tcp:3000        False

Google ヘルスチェック範囲からのヘルスチェックを許可する FW ルールを作成します。

Cloud Shell から

gcloud compute firewall-rules create allow-health-check \
    --network=ca-lab-vpc \
    --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
allow-health-check  ca-lab-vpc  INGRESS    1000      tcp          False

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

次のステップでは、テストアプリケーション（ここでは OWASP Juice Shop ウェブサーバー）を作成します。

コンピューティングインスタンスを作成する際に、コンテナイメージを使用して、サーバーに適切なサービスが確実に含まれるようにします。このサーバーは us-central1-c にデプロイされ、ヘルスチェックを可能にするネットワークタグが設定されます。

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

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

Cloud Shell から

gcloud compute instances create-with-container owasp-juice-shop-app --container-image bkimminich/juice-shop \
     --network ca-lab-vpc \
     --subnet ca-lab-subnet \
     --private-network-ip=10.0.0.3 \
     --machine-type n1-standard-2 \
     --zone us-central1-c \
     --tags allow-healthcheck

出力

NAME                  ZONE           MACHINE_TYPE   PREEMPTIBLE  
owasp-juice-shop-app  us-central1-c  n1-standard-2               

INTERNAL_IP  EXTERNAL_IP     STATUS
10.0.0.3     <public IP>     RUNNING

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

非マネージドインスタンスグループを作成します。

Cloud Shell から

gcloud compute instance-groups unmanaged create juice-shop-group \
    --zone=us-central1-c

出力

NAME              LOCATION       SCOPE  NETWORK  MANAGED  INSTANCES
juice-shop-group  us-central1-c  zone                     0

Juice Shop GCE インスタンスを非マネージドインスタンスグループに追加します。

Cloud Shell から

gcloud compute instance-groups unmanaged add-instances juice-shop-group \
    --zone=us-central1-c \
    --instances=owasp-juice-shop-app

出力

Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].

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

Cloud Shell から

gcloud compute instance-groups unmanaged set-named-ports \
juice-shop-group \
   --named-ports=http:3000 \
   --zone=us-central1-c

出力

Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].

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

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

Juice Shop サービスポートのヘルスチェックを作成します。

Cloud Shell から

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

出力

Created 
NAME           PROTOCOL
tcp-port-3000  TCP

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

バックエンドサービスパラメータを作成します。

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

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

Cloud Shell から

 gcloud compute backend-services add-backend juice-shop-backend \
        --instance-group=juice-shop-group \
        --instance-group-zone=us-central1-c \
        --global

出力

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

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

バックエンドに送信する URL マップを作成します。

Cloud Shell から

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

出力

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

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

URL マップのフロントエンドとしてターゲットプロキシを作成します。

Cloud Shell から

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 サービスがオンラインであることを確認する

Cloud Shell から

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

Cloud Shell から

echo $PUBLIC_SVC_IP

出力

<public VIP of service>

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

Cloud Shell から

curl -Ii http://$PUBLIC_SVC_IP

出力

HTTP/1.1 200 OK
<...>

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

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

5. 既知の脆弱性を実演する

時間を節約するため、Cloud Armor WAF ルールが伝播される前後の状態を、簡潔な手順で確認します。

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

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

Cloud Shell から

curl -Ii http://$PUBLIC_SVC_IP/ftp

出力

HTTP/1.1 200 OK
<...>

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

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
<...>

6. Cloud Armor WAF ルールを定義する

事前構成済みの WAF ルールを一覧表示します。

Cloud Shell から

gcloud compute security-policies list-preconfigured-expression-sets

出力

EXPRESSION_SET
Sqli-canary
RULE_ID
    owasp-crs-v030001-id942110-sqli
    owasp-crs-v030001-id942120-sqli
<...>

Cloud Armor セキュリティポリシーを作成する

Cloud Shell から:

gcloud compute security-policies create block-with-modsec-crs \
    --description "Block with OWASP ModSecurity CRS"

セキュリティポリシーのデフォルトルールを更新する

デフォルトのルールの優先度の数値は 2147483647 です。

Cloud Shell から:

gcloud compute security-policies rules update 2147483647 \
    --security-policy block-with-modsec-crs \
    --action "deny-403"

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

Cloud Shell から:

MY_IP=$(curl ifconfig.me)

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

Cloud Shell から:

gcloud compute security-policies rules create 10000 \
    --security-policy  block-with-modsec-crs  \
    --description "allow traffic from my IP" \
    --src-ip-ranges "$MY_IP/32" \
    --action "allow"

LFI 攻撃をブロックするようにセキュリティポリシーを更新する

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

Cloud Shell から:

gcloud compute security-policies rules create 9000 \
    --security-policy block-with-modsec-crs  \
    --description "block local file inclusion" \
     --expression "evaluatePreconfiguredExpr('lfi-stable')" \
    --action deny-403

リモートコード実行（RCE）をブロックするようにセキュリティポリシーを更新する

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

Cloud Shell から:

gcloud compute security-policies rules create 9001 \
    --security-policy block-with-modsec-crs  \
    --description "block rce attacks" \
     --expression "evaluatePreconfiguredExpr('rce-stable')" \
    --action deny-403

セキュリティポリシーを更新してセキュリティスキャナをブロックする

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

Cloud Shell から:

gcloud compute security-policies rules create 9002 \
    --security-policy block-with-modsec-crs  \
    --description "block scanners" \
     --expression "evaluatePreconfiguredExpr('scannerdetection-stable')" \
    --action deny-403

プロトコル攻撃をブロックするようにセキュリティポリシーを更新する

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

Cloud Shell から:

gcloud compute security-policies rules create 9003 \
    --security-policy block-with-modsec-crs  \
    --description "block protocol attacks" \
     --expression "evaluatePreconfiguredExpr('protocolattack-stable')" \
    --action deny-403

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

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

Cloud Shell から:

gcloud compute security-policies rules create 9004 \
    --security-policy block-with-modsec-crs  \
    --description "block session fixation attacks" \
     --expression "evaluatePreconfiguredExpr('sessionfixation-stable')" \
    --action deny-403

セキュリティポリシーをバックエンドサービスに接続する

Cloud Shell から:

gcloud compute backend-services update juice-shop-backend \
    --security-policy block-with-modsec-crs \
    --global

ルールの伝播に時間がかかる場合があります（ただし 10 分以内）。十分な時間が経過したことを確認したら、次のステップに進み、先に実演した脆弱性をテストして、Cloud Armor WAF ルールが適用されていることを確認しましょう。

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

LFI の脆弱性が軽減されたことを確認する

Cloud Shell から

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

出力

HTTP/1.1 403 Forbidden
<...>

RCE 攻撃が軽減されていることを確認する

Cloud Shell から

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

出力

HTTP/1.1 403 Forbidden
<..>

よく知られたスキャナの検出を確認する

Cloud Shell から

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

出力

HTTP/1.1 403 Forbidden
<..>

プロトコル攻撃が軽減されたことを確認する

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

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 403 Forbidden
<..>

セッション固定化の試みがブロックされていることを確認する

Cloud Shell から

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

出力

HTTP/1.1 403 Forbidden
<..>

8. Cloud Armor セキュリティルールを確認する

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

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

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

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

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

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

LFI のログ

RCE のログ

スキャナ検出のログ

プロトコル攻撃のログ

セッション固定のログ

10. ラボのクリーンアップ

ラボが完了したので、リソースをクリーンアップします。

次のコマンドを実行して、Cloud Armor セキュリティポリシー、ロードバランサ、インスタンス、ファイアウォールルール、VPC ネットワークを削除します。

バックエンドサービスから Cloud Armor セキュリティポリシーを削除する

gcloud -q compute backend-services update juice-shop-backend --security-policy "" --global

Cloud Armor セキュリティポリシーを削除する

セキュリティポリシーを削除すると、関連付けられたルールも自動的に削除されます。

gcloud -q compute security-policies delete block-with-modsec-crs

ロードバランサリソースを削除する

削除されるロードバランサリソースには、転送ルール、ターゲット HTTP プロキシ、URL マップ、バックエンド、ヘルスチェック、インスタンスグループが含まれます。

gcloud -q compute forwarding-rules delete juice-shop-rule --global

gcloud -q compute target-http-proxies delete juice-shop-proxy

gcloud -q compute url-maps delete juice-shop-loadbalancer

gcloud -q compute backend-services delete juice-shop-backend \
    --global

gcloud -q compute health-checks delete tcp-port-3000

gcloud -q compute instance-groups unmanaged delete juice-shop-group --zone=us-central1-c

インスタンスを削除する

gcloud -q compute instances delete owasp-juice-shop-app --zone us-central1-c

ファイアウォールルール、サブネット、VPC を削除する

gcloud -q compute firewall-rules delete allow-health-check
gcloud -q compute firewall-rules delete allow-js-site
gcloud -q compute networks subnets delete ca-lab-subnet --region us-central1
gcloud -q compute networks delete ca-lab-vpc

11. 完了

Cloud Armor の事前構成 WAF ルールの Codelab を完了しました。

学習した内容

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

次のステップ

Cloud Armor の事前構成済み WAF ルールを使用して、OWASP トップ 10 の脆弱性からアプリケーションを保護する
機密性レベルに基づいてルールを微調整する
より具体的なセキュリティの適用には、カスタムルール言語リファレンスを使用します。

Cloud Armor の事前構成 WAF ルールの Codelab

1. はじめに

学習内容

必要なもの

Codelab のトポロジとユースケース

2. 設定と要件

セルフペース型の環境設定

Cloud Shell の起動

始める前に

API を有効にする

3. VPC ネットワークを作成する

VPC ネットワークを作成する

サブネットを作成する

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

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

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

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

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

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

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

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

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

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

5. 既知の脆弱性を実演する

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

RCE の脆弱性を確認する

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

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

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

6. Cloud Armor WAF ルールを定義する

Cloud Armor セキュリティ ポリシーを作成する

セキュリティ ポリシーのデフォルト ルールを更新する

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

LFI 攻撃をブロックするようにセキュリティ ポリシーを更新する

リモートコード実行（RCE）をブロックするようにセキュリティ ポリシーを更新する

セキュリティ ポリシーを更新してセキュリティ スキャナをブロックする

プロトコル攻撃をブロックするようにセキュリティ ポリシーを更新する

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

セキュリティ ポリシーをバックエンド サービスに接続する

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

LFI の脆弱性が軽減されたことを確認する

RCE 攻撃が軽減されていることを確認する

よく知られたスキャナの検出を確認する

プロトコル攻撃が軽減されたことを確認する

セッション固定化の試みがブロックされていることを確認する

8. Cloud Armor セキュリティ ルールを確認する

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

LFI のログ

RCE のログ

スキャナ検出のログ

プロトコル攻撃のログ

セッション固定のログ

10. ラボのクリーンアップ

バックエンド サービスから Cloud Armor セキュリティ ポリシーを削除する

Cloud Armor セキュリティ ポリシーを削除する

ロードバランサ リソースを削除する

インスタンスを削除する

ファイアウォール ルール、サブネット、VPC を削除する

11. 完了

学習した内容

次のステップ

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

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

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

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

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

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

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

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

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

Cloud Armor セキュリティポリシーを作成する

セキュリティポリシーのデフォルトルールを更新する

LFI 攻撃をブロックするようにセキュリティポリシーを更新する

リモートコード実行（RCE）をブロックするようにセキュリティポリシーを更新する

セキュリティポリシーを更新してセキュリティスキャナをブロックする

プロトコル攻撃をブロックするようにセキュリティポリシーを更新する

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

セキュリティポリシーをバックエンドサービスに接続する

8. Cloud Armor セキュリティルールを確認する

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

バックエンドサービスから Cloud Armor セキュリティポリシーを削除する

Cloud Armor セキュリティポリシーを削除する

ロードバランサリソースを削除する

ファイアウォールルール、サブネット、VPC を削除する