排解 Cloud Armor 問題

按照這些操作說明排解 Google Cloud Armor 安全性政策的問題。

一般問題

偵錯安全性政策

如要進一步瞭解特定事件觸發預先設定規則的原因，請參閱「使用要求記錄」，然後啟用詳細記錄。Cloud Logging 會在記錄中記錄更詳細的資訊，可用於分析及偵錯政策和規則。

即使 Cloud Armor 安全性政策中已設定拒絕規則，系統仍允許流量

如要修正這個問題，請按照下列步驟操作：

1. 確認 Cloud Armor 安全性政策已附加至目標後端服務。舉例來說，下列指令會說明與後端服務 BACKEND 相關聯的所有資料。傳回的結果應包含與這項後端服務相關聯的 Cloud Armor 安全性政策名稱。

   gcloud compute backend-services describe BACKEND
   

2. 查看 HTTP(S) 記錄，判斷流量符合哪些政策和規則，以及相關聯的動作。如要查看記錄，請使用 Cloud Logging。

   以下是允許要求時的記錄範例，並以螢光筆標示重要欄位。檢查下列欄位，確認這些欄位符合您設定的流量拒絕規則：

   • configuredAction 應與規則中設定的動作相符。
   • name 應與附加至這個後端服務的 Cloud Armor 安全性政策名稱相符。
   • outcome 應與 configuredAction 相符。
   • priority 應與規則的優先順序號碼相符。

     httpRequest:
      remoteIp: 104.133.0.95
      requestMethod: GET
      requestSize: '801'
      requestUrl: http://74.125.67.38/
      responseSize: '246'
      serverIp: 10.132.0.4
      status: 200
      userAgent: curl/7.35.0
        insertId: ajvis5ev4i60
        internalId:
          projectNumber: '895280006100'
        jsonPayload:
          '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry
          enforcedSecurityPolicy:
            configuredAction: ACCEPT
            name: mydev-policy-log-test1
            outcome: ACCEPT
            priority: 2147483647
          statusDetails: response_sent_by_backend
        logName: projects/mydev-staging/logs/requests
        resource:
          labels:
            backend_service_name: BACKEND_SERVICE_NAME
            forwarding_rule_name: FORWARDING_RULE_NAME
            project_id: PROJECT_ID
            target_proxy_name: TARGET_HTTP_PROXY_NAME
            url_map_name: URL_MAP_NAME
            zone: global
          type: http_load_balancer
        severity: INFO
        timestamp: '2017-04-18T18:57:05.845960288Z'
   

3. 請檢查規則的階層，確保系統比對的是正確規則。優先順序較高的規則可能允許流量通過。在 Google Cloud CLI 中，使用 security-policies 上的 describe 指令查看 Cloud Armor 安全性政策的內容。

   舉例來說，以下範例顯示優先順序較高的允許規則 (優先順序為 100) 如何比對來自 1.2.3.4 IP 位址的流量，避免觸發優先順序較低的拒絕規則 (優先順序為 200)，並封鎖流量。

   gcloud compute security-policies describe POLICY_NAME
   

   輸出：

     creationTimestamp: '2017-04-18T14:47:58.045-07:00
     description: ''
     fingerprint: Yu5spBjdoC0=
     id: '2560355463394441057'
     kind: compute#securityPolicy
     name: POLICY_NAME
     rules:
     -action: allow
      description: allow high priority rule
      kind: compute#securityPolicyRule
      match:
        srcIpRanges:
        -'1.2.3.4/32'
      preview: false
      priority: 100
     -action: deny
      description: deny lower priority rule
      kind: compute#securityPolicyRule
      match:
        srcIpRanges:
        -'1.2.3.0/24
      preview: false
      priority: 200
     -action: deny
      description: default rule
      kind: compute#securityPolicyRule
      match:
        srcIpRanges:
        -'*'
      preview: false
      priority: 2147483647
      selfLink: http://www.googleapis.com/compute/v1/projects/bigclustertestdev0-devconsole/global/securityPolicies/sp
   

預先設定的規則傳回誤報

XSS 和 SQLi 偵測功能會根據 HTTP 要求標頭和其他第 7 層參數的靜態簽章比對結果判斷。這些規則運算式模式容易出現誤報。您可以在預覽模式中使用預先設定的規則偵測 XSS 和 SQLi，然後檢查記錄是否有任何誤判。

如果發現偽陽性，可以將流量內容與 OWASP CRS 規則進行比較。如果規則無效或不相關，請使用 evaluatePreconfiguredWaf 運算式停用規則，並在 exclude ID list 引數中指定規則的 ID。

檢查記錄並移除所有誤判結果後，請停用預覽模式。

如要在預覽模式中新增預先設定的規則，請按照下列步驟操作：

1. 在預覽模式中，使用預先設定的運算式集建立安全性政策：

   gcloud compute security-policies rules create 1000
      --security-policy POLICY_NAME
      --expression "evaluatePreconfiguredWaf('xss-stable')"
      --action deny-403
      --preview
   

2. 查看 HTTP(S) 記錄，瞭解 HTTP 要求欄位，例如 url 和 cookie。舉例來說，requestUrl 與 OWASP CRS 規則 ID 941180 相比，結果為正：

   httpRequest:
     remoteIp: 104.133.0.95
     requestMethod: GET
     requestSize: '801'
     requestUrl: http://74.125.67.38/foo?document.cookie=1010"
     responseSize: '246'
     serverIp: 10.132.0.4
     status: 200
     userAgent: curl/7.35.0
   insertId: ajvis5ev4i60
   internalId:
     projectNumber: '895280006100'
   jsonPayload:
     '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry
     enforcedSecurityPolicy:
       configuredAction: ACCEPT
       name: POLICY_NAME
       outcome: ACCEPT
       priority: 2147483647
       preconfiguredExprIds: [ 'owasp-crs-v030001-id941180-xss' ]
     statusDetails: response_sent_by_backend
   logName: projects/mydev-staging/logs/requests
   resource:
     labels:
       backend_service_name: BACKEND_SERVICE
       forwarding_rule_name: mydev-forwarding-rule
       project_id: mydev-staging
       target_proxy_name: mydev-target-http-proxy
       url_map_name: mydev-url-map
       zone: global
     type: http_load_balancer
   severity: INFO
   timestamp: '2017-04-18T18:57:05.845960288Z'
   

3. 更新 Cloud Armor 安全性政策中的規則，排除 OWASP CRS 規則 ID 941180：

   gcloud compute security-policies rules update 1000 \
       --security-policy POLICY_NAME \
       --expression "evaluatePreconfiguredWaf('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \
       --action deny-403 \
       --preview
   

4. 再次檢查記錄，然後停用預覽模式，即可套用規則。

系統不會封鎖或拒絕簽章遭拒的用戶端

如果將 Cloud Armor 與 Cloud CDN 搭配使用，系統僅會針對下列要求強制執行安全性政策：動態內容、快取失敗，或其他目的地為 CDN 原始伺服器的要求。即使下游 Cloud Armor 安全性政策會防止快取命中要求抵達 CDN 原始伺服器，仍會執行快取命中要求。

頻率限制問題

流量未依預期受到節流

您可能會發現，用戶端 IP 位址以超過您設定的門檻速率，將大量流量傳送至應用程式，但流量並未如預期受到節流。請按照下列步驟調查問題。

首先，請確認優先順序較高的規則是否允許來自該 IP 位址的流量。檢查記錄，確認 IP 位址是否觸發 ALLOW 規則。這可能是獨立的 ALLOW 規則，也可能是其他 THROTTLE 或 RATE_BASED_BAN 規則。

如果找到優先順序較高的規則，請執行下列任一操作：

1. 變更優先順序，將速率限制規則的優先順序調高，方法是為該規則指派「較低」的數值。
2. 在優先順序較高的規則中，從相符的運算式排除 IP 位址。

問題也可能是門檻設定有誤。如果是這種情況，系統會準確比對要求，但會觸發「符合」動作。請檢查記錄檔確認是否為此情況，然後降低規則中的門檻。

最後，IP 位址可能不符合節流或以速率為準的禁止規則。如要修正這個問題，請檢查比對條件是否有誤，然後將規則的比對條件變更為正確值。

後續步驟

• 取得支援