排解 Cloud Armor 問題

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

一般問題

本節說明使用 Cloud Armor 時常見的問題。

偵錯安全性政策

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

找出記錄中遭封鎖的要求並建立關聯

當 Cloud Armor 封鎖全域外部應用程式負載平衡器或傳統版應用程式負載平衡器上的要求時,您可以設定使用 {cloud_trace_id} 變數的自訂回應標頭,將不重複的追蹤 ID 傳回用戶端。接著,您可以使用這個追蹤記錄 ID 在 Logging 中尋找記錄項目,並判斷要求遭到封鎖的原因。

如要在 Logging 中公開追蹤 ID 並找出遭封鎖的要求,請按照下列步驟操作:

  1. 在後端服務上,使用 {cloud_trace_id} 變數設定自訂回應標頭。舉例來說,下列指令會將 X-Cloud-Trace-Id 回應標頭新增至後端服務 BACKEND_SERVICE_NAME:

    gcloud compute backend-services update BACKEND_SERVICE_NAME \
       --global \
       --custom-response-header='X-Cloud-Trace-Id:{cloud_trace_id}'
    

    將 BACKEND_SERVICE_NAME 替換為後端服務名稱。

    詳情請參閱「設定自訂回應標頭」。

  2. 當 Cloud Armor 安全性政策拒絕要求時,請檢查傳回用戶端的 HTTP 回應標頭,取得 X-Cloud-Trace-Id 標頭的 32 個字元十六進位值。

  3. 在「Logs Explorer」頁面中,使用回應標頭中的追蹤記錄 ID 查詢 trace 欄位,找出相符的記錄項目:

    resource.type="http_load_balancer"
    trace="projects/PROJECT_ID/traces/TRACE_ID"
    

    更改下列內容:

    • PROJECT_ID:負載平衡器轉送規則和網址對應所在專案的 ID
    • TRACE_ID:自訂回應標頭中傳回的 32 個字元十六進位追蹤 ID

Cloud Armor 安全性政策中設有拒絕規則,但流量仍獲准通過

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

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

    gcloud compute backend-services describe BACKEND
    

    將 BACKEND 替換為後端服務名稱。

  2. 查看 HTTP(S) 記錄,判斷流量符合哪些政策和規則,以及相關聯的動作。如要查看記錄,請使用 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'
    

    這項輸出內容包含下列值:

    • BACKEND_SERVICE_NAME:後端服務名稱
    • FORWARDING_RULE_NAME:轉送規則的名稱
    • PROJECT_ID:專案 ID
    • TARGET_HTTP_PROXY_NAME:目標 HTTP Proxy 的名稱
    • URL_MAP_NAME:網址對應的名稱
  3. 請檢查規則階層,確保比對到正確的規則。優先順序較高且含有允許動作的規則,可能與您的流量相符。在 Google Cloud CLI 中,對 security-policies 使用 describe 指令,查看 Cloud Armor 安全性政策的內容。

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

    gcloud compute security-policies describe POLICY_NAME
    

    將 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 規則進行比較。如果您是從舊版 CRS 遷移,請參閱「WAF 規則版本比較」,查看規則變更和重新命名的清單。如果規則無效或不相關,請使用 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
    

    將 POLICY_NAME 替換為安全性政策名稱。

  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-v042200-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'
    

    這份記錄包含下列值:

    • POLICY_NAME:安全性政策名稱
    • BACKEND_SERVICE:後端服務名稱
  3. 更新 Cloud Armor 安全性政策中的規則,排除 OWASP CRS 規則 ID 941180:

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

    將 POLICY_NAME 替換為安全性政策名稱。

  4. 再次查看記錄,然後停用預覽模式,即可實施規則。

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

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

要求主體檢查問題

Cloud Armor 會在收到資料時逐步評估,直到達到設定的檢查限制,因此規則可能會根據不完整的主體資料進行評估。為避免可能出現偽陽性或不完整的結果,請編寫規則來比對資料是否存在,而非資料是否不存在。詳情請參閱「要求主體檢查限制」。

在記錄中查看相符的子運算式

排解規則問題時,您可以將 --log-level 旗標設為 VERBOSE,啟用詳細記錄功能,並使用 Logging 查看規則中哪些子運算式相符。如果規則包含多個子運算式,Cloud Armor 只會記錄最近比對成功的子運算式詳細資料。

以下範例運算式包含兩個子運算式:

request.url.contains('__') && request.body.contains('abc')

如果您將主體為 abc 的 POST 要求傳送至網址 example.com/etc/pass__word,運算式就會相符。由於子運算式是由左至右評估,因此 request.body.contains('abc') 子運算式會最後評估。下列記錄摘錄顯示相符的 request.body 子運算式詳細資料:

jsonPayload: {
  [...]
  enforcedSecurityPolicy: {
    [...]
    matchedFieldType: "request.body",
    matchedFieldName: "request.body",
    matchedFieldValue: "abc",
    matchedFieldLength: 3,
    matchedOffset: 0,
    matchedLength: 3,
  }
  [..*]
}

頻率限制問題

本節說明如何排解頻率限制的常見問題。

流量未如預期受到限制

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

首先,請確認是否有優先順序較高的規則允許來自該 IP 位址的流量。檢查記錄,確認是否為該 IP 位址觸發 ALLOW 規則。這可以是單獨的 ALLOW 規則,也可以是另一個 THROTTLE 或 RATE_BASED_BAN 規則。

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

  1. 變更優先順序,為頻率限制規則指派「較低」的數值,確保該規則的優先順序較高。
  2. 在優先順序較高的規則中,從相符運算式排除該 IP 位址。

也可能是門檻設定有誤。在這種情況下,系統會準確比對要求,但會觸發符合動作。請查看記錄,確認是否為這種情況,然後降低規則中的門檻。

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

後續步驟