排解 Cloud Armor 問題

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

一般問題

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

偵錯安全性政策

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

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

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

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

    gcloud compute backend-services describe BACKEND
    

    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'
    

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

    • 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 要求欄位,例如 urlcookie。舉例來說,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 原始伺服器,仍會執行快取命中要求。

已有名稱的 IP 位址清單有問題

本節提供資訊,協助解決具名 IP 位址清單的問題。

已有名稱的 IP 位址清單中的 IP 位址

清單中的 IP 位址一律與 Cloud Armor 已命名 IP 位址清單指南中列出的供應商網站的 IP 位址相符。如對清單有任何疑問,請與 Cloud 支援團隊聯絡

Cloud Armor 中已命名 IP 位址清單內的 IP 位址過時

Cloud Armor 每天會與 IP 位址清單供應商同步處理清單。資料可能過時,比供應商的資料延遲幾小時或一天。不過,如果您認為過時資料的延遲時間超出預期 (例如超過一週),請與 Cloud 支援團隊聯絡

難以建立參照已命名 IP 位址清單的安全政策

您可能會嘗試建立參照具名 IP 位址清單的安全政策,使用類似這樣的指令:

gcloud compute security-policies rules create 750 \
    --security-policy my \
    --expression "evaluatePreconfiguredExpr('sourceiplist-example')" \
    --action "allow"

如果指令失敗,您看到的錯誤訊息會類似於下列內容:

ERROR: (gcloud.compute.security-policies.rules.create) Could not fetch resource:
 - Invalid value for field 'resource.match.expr': '{  "expression": "evaluatePreconfiguredExpr(\u0027sourceiplist-example\u0027)"}'.
Error parsing Cloud Armor rule matcher expression: sourceiplist-example
isn't a valid preconfigured expression set.

請確認系統支援該特定供應商,並正確提供 IP 位址清單名稱。您可以使用下列 gcloud 指令列出目前預先設定的運算式集,藉此進行檢查:

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

即使已預先設定指定 IP 位址許可清單的規則,流量仍遭到封鎖

您可能會發現來自已命名 IP 位址清單中 IP 位址的流量遭到封鎖:

  1. 確認流量來自已命名 IP 位址允許清單中的 IP 位址。

  2. 檢查是否有優先順序較高的其他安全規則會封鎖流量。如果問題仍未解決,請與 Cloud 支援團隊聯絡

  3. 確認安全性政策已附加至正確的後端服務:

    gcloud compute backend-services describe BACKEND_SERVICE
    
  4. 檢查安全性政策中的規則。例如:

    gcloud compute security-policies describe POLICY_NAME
    

    指令會傳回類似下列的資訊:

    ---
    …
    name: POLICY_NAME
    rules:
    -action: allow
    description: allow fastly ip addresses
    kind: compute#securityPolicyRule
    match:
       expr:
         expression: evaluatePreconfiguredExpr('sourceiplist-fastly')
    preview: false
    priority: 100
    -action: deny(403)
    description: Default rule, higher priority overrides it
    kind: compute#securityPolicyRule
    match:
       config:
         srcIpRanges:
         -'*'
       versionedExpr: SRC_IPS_V1
    preview: false
    priority: 2147483647
    -action: deny(404)
    description: deny altostrat referer
    kind: compute#securityPolicyRule
    match:
       expr:
         expression: request.headers['Referer'].contains('altostrat')
    preview: false
    priority: 50
    …
    

    上述安全政策包含三項規則:預設拒絕規則、Fastly IP 位址的允許規則,以及包含 altostrat 的參照網址拒絕規則。這些規則的優先順序也列於上方。

  5. 查看記錄,判斷流量符合哪項規則和相關聯的動作。如要瞭解記錄,請參閱「Logs Explorer」。

    以下是記錄範例:

    httpRequest: {
       referer: "http://www.altostrat.com/"
       remoteIp: "23.230.32.10"
       requestMethod: "HEAD"
       requestSize: "79"
       requestUrl: "http://www.example.com/"
       responseSize: "258"
       status: 404
       userAgent: "Mozilla/5.0"
     }
     …
     jsonPayload: {
       @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
       enforcedSecurityPolicy: {
         configuredAction: "DENY"
         name: "POLICY_NAME"
         outcome: "DENY"
         priority: 50
       }
       statusDetails: "denied_by_security_policy"
     }
     …
    

    從上述記錄檔中,要求來自 23.230.32.10,這屬於 Fastly 的公開 IP 位址清單。不過,這項要求符合優先順位較高的拒絕規則 (優先順位為 50)。與安全性政策中的內容比較後,這項規則對應於含有 altostrat 的參照網址的拒絕規則。由於要求具有 http://www.altostrat.com/ 的參照網址,因此安全規則強制執行功能運作正常。

Security Command Center 發現項目問題

本節提供有關 Security Command Center 發現項目問題的資訊。

Security Command Center 未顯示 Cloud Armor 資訊卡

在 Security Command Center 介面中啟用 Cloud Armor 發現項目。

Cloud Armor 的發現項目不會顯示在 Security Command Center 中

如果 Security Command Center 未顯示 Cloud Armor 的發現項目,可能是因為後端服務的流量不符合提出發現項目的條件。

如要瞭解後端的流量,請查看「Network Security Policies」下方的 Cloud Monitoring 資訊主頁中的要求統計資料。

發現項目過於雜亂

如需解決這個問題的協助,請與 Cloud 支援團隊聯絡

Google Cloud Armor Adaptive Protection 的相關問題

請按照這些操作說明解決 Adaptive Protection 問題。

已為安全性政策啟用自動調整式防護機制,但 Cloud Logging 中沒有任何記錄

系統會分開產生 Adaptive Protection 記錄和 Cloud Armor 請求記錄,並顯示在 Cloud Logging 的不同資源下。Adaptive Protection 記錄和事件位於 Cloud Logging 的「Network Security Policy」(網路安全政策) 資源下方。在安全性政策中啟用 Adaptive Protection 後,系統至少需要一小時的訓練期,才會開始針對疑似攻擊產生快訊。在訓練日期範圍內,Adaptive Protection 會從傳入的要求流量中學習,並為受該安全性政策保護的每個後端服務,開發不同的基準。Adaptive Protection 隨後就能識別可疑活動。

如果您為安全性政策啟用 Adaptive Protection,且在 1 小時的訓練日期範圍後未收到任何快訊,表示與該安全性政策相關聯的後端服務,沒有任何活動可識別為潛在惡意目標。

如果潛在攻擊或異常流量持續較長時間 (超過數小時),Adaptive Protection 就會開始將該行為視為基準行為,不會繼續針對類似的流量模式發出快訊。潛在攻擊平息後,流量模式會恢復到原始基準。這可能是因為攻擊結束,或是您使用適當的 Cloud Armor 規則封鎖攻擊。屆時,如果未來的流量行為偏離基準,Adaptive Protection 就會發出快訊。

Adaptive Protection 會分析可能透過 Cloud Armor 安全性政策允許的流量。如果將預設規則設為拒絕存取,並限制允許的流量,Adaptive Protection 就只會偵測通過允許清單評估的流量中,是否有惡意活動。

Cloud Logging 中來自 Adaptive Protection 的快訊或記錄過多

適應性防護警報會提供信賴分數,指出適應性防護模型偵測到的活動有多大可能是異常活動或攻擊。您可以透過 Cloud Logging 篩選記錄檔的特定項目,只顯示 (或轉送至下游) 信賴分數高於特定門檻的警報。

自動調整式防護機制提供回報誤判快訊的機制,詳情請參閱「監控、意見回饋和回報事件錯誤」一節。 請注意,回報誤判情形後,自動調整式防護機制可能不會立即變更快訊內容。但隨著時間推移,自動調整式防護機制模型會瞭解這類流量模式屬於正常且可接受的範圍,並停止針對這些模式發出快訊。

如果安全性政策中部分後端服務的 Adaptive Protection 警報過於頻繁,可能表示這些後端服務的正常流量有顯著波動,Adaptive Protection 會不斷將這些波動視為異常行為。您可以建立未啟用 Adaptive Protection 的獨立安全性政策,並將這些後端服務與新的安全性政策建立關聯。

自動調整式防護機制回報的特定事件屬於誤判或不相關

Adaptive Protection 提供回報誤報快訊的機制。請按照「監控、意見回饋和回報事件錯誤」一節所述程序操作。請注意,回報誤報可能不會立即影響 Adaptive Protection 的快訊內容。隨著時間推移,Adaptive Protection 模型會瞭解這類流量模式屬於正常且可接受的範圍,並停止針對這些模式發出快訊。

如何確認邊緣安全性政策是否已強制執行?

如要查看對邊緣安全政策採取的動作,請查看監控資訊主頁、監控指標或每個要求的記錄。

Monitoring 資訊主頁

您可以在「監控」下的「網路安全政策」頁面使用 Cloud Monitoring。您可以使用頁面上的安全性政策細目,評估設定的邊緣安全性政策允許和拒絕的要求數量。您也可以檢查後端服務的細目,以便對特定後端服務進行偵錯。如要瞭解 Cloud Monitoring 資訊主頁,請參閱「監控 Cloud Armor 安全性政策」。

監控指標

邊緣安全政策提供可衡量允許和拒絕要求的原始指標。詳情請參閱「監控安全政策的指標」。

記錄每項要求

邊緣安全政策的決策會記錄在 enforcedEdgeSecurityPolicy 下的負載平衡要求記錄中。這與enforcedSecurityPolicy不同,後者會擷取後端安全政策的政策裁決。

機器人管理

本節提供有關排解機器人管理問題的資訊。

使用者未如預期獲得豁免

您可能已設定安全政策規則,將 reCAPTCHA 評估結果重新導向,但發現部分您認為是正當的使用者並未如預期獲得豁免。請按照下列步驟進行疑難排解。

首先,請檢查每個要求的記錄,看看是否有優先順序較高的安全性政策規則與流量相符,且動作不同。特別是 configured_actionoutcome 欄位。請注意,如要豁免使用者,至少需要兩個要求。初始要求不含豁免 Cookie,如果使用者通過 reCAPTCHA 評估,後續要求就會包含豁免 Cookie。因此,至少會有兩筆記錄項目。

  • 如果設定的動作是 GOOGLE_RECAPTCHA,結果是 REDIRECT,表示要求已重新導向至 reCAPTCHA 評估;
  • 如果設定的動作是 GOOGLE_RECAPTCHA,結果是 ACCEPT,表示系統已豁免將要求重新導向至 reCAPTCHA 評估。
  • 如果上述欄位顯示不同的值,表示系統比對到動作不同的規則。在這種情況下,使用者不會遭到重新導向或豁免。

其次,使用者必須符合幾項規定,才能免於重新導向至 reCAPTCHA 評估。

  1. 使用者必須使用瀏覽器。
  2. 瀏覽器必須啟用 JavaScript,才能正確載入內嵌 reCAPTCHA JavaScript 的重新導向頁面。
  3. 瀏覽器必須啟用 Cookie,才能設定並自動附加豁免 Cookie。
  4. 使用者必須通過 reCAPTCHA 評估,例如解決對話方塊中的人機驗證。

請注意,即使系統比對到含有 reCAPTCHA 評估重新導向動作的規則,不符合上述任一條件的使用者也不會獲得豁免。

第三,只有在轉址網頁 (內嵌 reCAPTCHA JavaScript) 經過算繪時,才會執行 reCAPTCHA 評估。因此,轉址進行 reCAPTCHA 評估只適用於預期回應會導致完整網頁算繪的要求。其他要求 (例如網頁中載入的資產,或來自內嵌指令碼且預期回應不會算繪的要求) 則不會進行 reCAPTCHA 評估。因此,建議您針對符合這項條件的網址路徑,套用這項動作和相符條件。

舉例來說,假設您有一個網頁,其中包含圖片、其他網頁的連結和指令碼等嵌入式元素。您不想對託管圖片的網址路徑,或應由指令碼存取的網址路徑套用 reCAPTCHA 評估的重新導向動作,因為這些路徑不應完整呈現網頁。不過,您可以針對託管網頁的網址路徑 (例如主要網頁或其他連結的網頁),套用 reCAPTCHA 評估的重新導向動作。

最後,如果重新導向頁面順利顯示,請在瀏覽器提供的開發人員工具中,檢查是否已設定豁免 Cookie,以及是否附加在相同網站的後續要求中。如需進一步協助,請與 Cloud 支援團隊聯絡。

頻率限制問題

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

流量未依預期受到節流

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

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

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

  1. 將優先順序改為較低的數值,確保速率限制規則的優先順序較高。
  2. 從優先順序較高的規則中,排除與規則運算式相符的 IP 位址。

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

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

後續步驟