按照這些操作說明排解 Google Cloud Armor 安全性政策的問題。
一般問題
偵錯安全性政策
如要進一步瞭解特定事件觸發預先設定規則的原因,請參閱「使用要求記錄功能」,然後啟用詳細記錄功能。Cloud Logging 會在記錄中記錄更詳細的資訊,可用於分析及偵錯政策和規則。
即使 Cloud Armor 安全性政策中已設定拒絕規則,系統仍允許流量
如要修正這個問題,請按照下列步驟操作:
確認 Cloud Armor 安全性政策已附加至目標後端服務。舉例來說,下列指令會說明與後端服務
BACKEND相關聯的所有資料。傳回的結果必須包含與這項後端服務相關聯的 Cloud Armor 安全性政策名稱。gcloud compute backend-services describe BACKEND
將
BACKEND改為後端服務的名稱。請查看 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:專案 IDTARGET_HTTP_PROXY_NAME:目標 HTTP Proxy 的名稱URL_MAP_NAME:網址對應的名稱
請檢查規則的階層,確保系統比對的是正確規則。優先順序較高的規則可能允許流量通過。在 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。
檢查記錄並移除所有誤判結果後,請停用預覽模式。
如要在預覽模式中新增預先設定的規則,請按照下列步驟操作:
在預覽模式中,使用預先設定的運算式集建立安全性政策:
gcloud compute security-policies rules create 1000 --security-policy POLICY_NAME --expression "evaluatePreconfiguredWaf('xss-stable')" --action deny-403 --preview將
POLICY_NAME替換為安全性政策名稱。查看 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:後端服務名稱
更新 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替換為安全性政策名稱。再次檢查記錄,然後停用預覽模式,即可實作規則。
簽章遭拒的用戶端不會遭到封鎖或拒絕
如果將 Cloud Armor 與 Cloud CDN 搭配使用,系統僅會針對下列要求強制執行安全性政策:動態內容、快取失敗,或其他目的地為 CDN 原始伺服器的要求。即使下游 Cloud Armor 安全性政策會防止快取命中要求抵達 CDN 原始伺服器,仍會執行快取命中要求。
已命名 IP 位址清單的問題
本節提供資訊,協助解決具名 IP 位址清單的問題。
已有名稱的 IP 位址清單中的 IP 位址
清單中的 IP 位址一律與 供應商網站列出的 IP 位址相符,如 Cloud Armor 已命名 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 位址的流量遭到封鎖:
確認流量來自已命名的 IP 位址允許清單。
檢查是否有優先順序較高的其他安全性規則會封鎖流量。如果問題仍未解決,請與 Cloud 支援團隊聯絡。
確認安全性政策已附加至正確的後端服務:
gcloud compute backend-services describe BACKEND_SERVICE
檢查安全性政策中的規則。例如:
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的參照網址拒絕規則。並列出各自的優先順序。查看記錄,判斷流量符合哪項規則和相關動作。如要瞭解記錄功能,請參閱「使用 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 安全性政策允許的流量。如果您將預設規則設為拒絕存取,並限制允許的流量,則「適應性防護」只會偵測通過允許清單評估的流量中,是否有惡意活動。
Cloud Logging 中來自 Adaptive Protection 的快訊或記錄過多
Adaptive Protection 快訊會提供信賴分數,指出 Adaptive Protection 模型有多大把握,認為偵測到的活動異常且可能為攻擊。您可以透過 Cloud Logging 篩選記錄的特定項目,只顯示 (或轉送至下游) 信心分數高於特定門檻的快訊。
適應性防護機制提供回報快訊為誤判的機制,詳情請參閱「監控、意見回饋和回報事件錯誤」一節。請注意,回報偽陽性後,Adaptive Protection 的警報內容可能不會立即變更。隨著時間推移,Adaptive Protection 模型會瞭解這類流量模式屬於正常且可接受的範圍,並停止對這些模式發出警報。
如果安全性政策中部分後端服務的 Adaptive Protection 警告過於頻繁,可能表示這些後端服務的正常流量有顯著波動,Adaptive Protection 會不斷將這些波動視為異常行為。您可以建立未啟用 Adaptive Protection 的獨立安全性政策,並將這些後端服務與新的安全性政策建立關聯。
自動調整式防護機制回報的特定事件屬於偽陽性或不相關
Adaptive Protection 提供回報偽陽性警示的機制。請按照「監控、意見回饋和回報事件錯誤」一節所述的程序操作。請注意,回報偽陽性後,Adaptive Protection 警報的偵測結果可能不會立即變更。一段時間後,Adaptive Protection 模型會瞭解這類流量模式屬於正常且可接受的範圍,並停止對這些模式發出警報。
如何確認邊緣安全政策是否已強制執行?
如要查看對邊緣安全政策採取的動作,請查看監控資訊主頁、監控指標或每個要求的記錄。
Monitoring 資訊主頁
您可以在「監控」下方的「網路安全政策」頁面使用 Cloud Monitoring。您可以使用頁面上的安全性政策細目,評估設定的邊緣安全性政策允許和拒絕的要求數量。您也可以檢查後端服務的細目,以便對特定後端服務進行偵錯。如要進一步瞭解 Cloud Monitoring 資訊主頁,請參閱「監控 Cloud Armor 安全性政策」。
監控指標
邊緣安全政策提供原始指標,可衡量允許和拒絕的要求。詳情請參閱「安全政策的監控指標」。
記錄每個要求
邊緣安全政策的決策會記錄在 enforcedEdgeSecurityPolicy 下的負載平衡要求記錄中。這與 enforcedSecurityPolicy 不同,後者會擷取後端安全政策的決策。
機器人管理
本節提供有關排解機器人管理問題的資訊。
使用者未如預期獲得豁免
您可能已設定安全性政策規則,將 reCAPTCHA 評估結果重新導向,但發現系統未如預期豁免您認為是正當的使用者。請按照下列步驟進行疑難排解。
首先,請查看每個要求的記錄,確認是否有優先順序較高的安全性政策規則與流量相符,且動作不同。請特別留意 configured_action 和 outcome 欄位。
請注意,如要豁免使用者,至少需要兩項要求。初始要求不含豁免 Cookie,如果使用者通過 reCAPTCHA 評估,後續要求就會包含豁免 Cookie。因此,系統應會記錄至少兩筆記錄。
- 如果設定的動作是
GOOGLE_RECAPTCHA,結果是REDIRECT,表示要求已重新導向至 reCAPTCHA 評估; - 如果設定的動作是
GOOGLE_RECAPTCHA,結果是ACCEPT,表示要求已豁免,不會重新導向進行 reCAPTCHA 評估。 - 如果上述欄位顯示不同的值,表示系統比對到動作不同的規則。在這種情況下,使用者應該不會遭到重新導向或豁免。
其次,使用者必須符合幾項規定,才能免於重新導向至 reCAPTCHA 評估。
- 使用者必須使用瀏覽器。
- 瀏覽器必須啟用 JavaScript,才能正確載入內嵌 reCAPTCHA JavaScript 的重新導向網頁。
- 瀏覽器必須啟用 Cookie,才能設定並自動附加豁免 Cookie。
- 使用者必須通過 reCAPTCHA 評估,例如解決彈出式驗證問題 (如有)。
請注意,即使系統比對到含有 reCAPTCHA 評估重新導向動作的規則,不符合上述任一條件的使用者也不會獲得豁免。
第三,只有在系統算繪嵌入 reCAPTCHA JavaScript 的重新導向頁面時,才會執行 reCAPTCHA 評估。因此,重新導向以進行 reCAPTCHA 評估,僅適用於預期回應會導致完整網頁呈現的要求。其他要求 (例如網頁中載入的資產,或來自內嵌指令碼的要求,這些要求不希望系統算繪回應) 則不應取得 reCAPTCHA 評估。因此,建議您對符合這項條件的網址路徑套用這項動作,並設定相符條件。
舉例來說,假設您有一個網頁,其中包含圖片、其他網頁的連結和指令碼等嵌入式元素。您不想對託管圖片的網址路徑,或應由指令碼存取的網址路徑套用 reCAPTCHA 評估的重新導向動作,因為這些路徑不應完整算繪網頁。不過,您可以針對託管網頁的網址路徑 (例如主要網頁或其他連結的網頁),套用 reCAPTCHA 評估的重新導向動作。
最後,如果重新導向頁面順利顯示,請在瀏覽器提供的開發人員工具中,檢查是否已設定豁免 Cookie,以及是否附加在相同網站的後續要求中。如需進一步協助,請與 Cloud 支援團隊聯絡。
頻率限制問題
流量未依預期受到節流
您可能會發現,用戶端 IP 位址以超過您設定的門檻速率,將大量流量傳送至應用程式,但流量並未如預期受到節流。請按照下列步驟調查問題。
首先,請確認優先順序較高的規則是否允許來自該 IP 位址的流量。檢查記錄,確認 IP 位址是否觸發 ALLOW 規則。這可能是獨立的 ALLOW 規則,也可能是其他 THROTTLE 或 RATE_BASED_BAN 規則。
如果找到優先順序較高的規則,請執行下列任一操作:
- 變更優先順序,將速率限制規則的優先順序調高,方法是為該規則指派「較低」的數值。
- 從優先順序較高的規則中,排除與運算式相符的 IP 位址。
也可能是因為門檻設定有誤。如果是這種情況,系統會準確比對要求,但會觸發「符合」動作。查看記錄檔確認是否為此情況,然後降低規則中的門檻。
最後,IP 位址可能不符合節流或以速率為準的禁止規則。如要修正這個問題,請檢查比對條件是否有誤,然後將規則的比對條件變更為正確值。