Algumas ou todas as informações nesta página podem não se aplicar à nuvem confiável da S3NS. Consulte Diferenças do Google Cloud para mais detalhes.

Esta página foi traduzida pela API Cloud Translation.

Resolver problemas do Cloud Armor

Use estas instruções para solucionar problemas com as políticas de segurança do Google Cloud Armor.

Problemas gerais

Como depurar políticas de segurança

Se você precisar de mais informações sobre quais eventos específicos acionam regras pré-configuradas, leia Como usar a geração de registros de solicitações e ative o registro detalhado. O Cloud Logging grava um nível mais alto de detalhes nos registros que pode ser usado para analisar e depurar as políticas e regras.

O tráfego é permitido, apesar de uma regra de negação estar configurada na política de segurança do Cloud Armor

Para corrigir isso, siga estas etapas:

Verifique se a política de segurança do Cloud Armor está atrelada a um serviço de back-end de destino. Por exemplo, o comando a seguir descreve todos os dados associados ao serviço de back-end BACKEND. Os resultados retornados devem incluir o nome da política de segurança do Cloud Armor associada a este serviço de back-end.
```
gcloud compute backend-services describe BACKEND
```

Revise os registros HTTP(S) para determinar qual política e regra tiveram correspondência com o tráfego junto com a ação associada. Para visualizar os registros, use o Cloud Logging.

A seguir, um exemplo de registro de uma solicitação permitida com os campos interessantes destacados. Verifique os campos a seguir e verifique se eles correspondem à regra que você configurou para negar o tráfego:

configuredAction deve corresponder à ação configurada na regra
name deve corresponder ao nome da política de segurança do Cloud Armor atrelada ao serviço de back-end.
outcome precisa corresponder a configuredAction.
priority deve corresponder ao número de prioridade da regra

  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'

Revise a hierarquia de regras para garantir que a regra correta seja correspondida. É possível que uma regra de prioridade mais alta com uma ação de permissão corresponda ao seu tráfego. Use o comando describe no security-policies na Google Cloud CLI para ver o conteúdo da política de segurança do Cloud Armor.

Por exemplo, o exemplo a seguir mostra como uma regra de permissão de maior prioridade (com prioridade 100) corresponde ao tráfego proveniente do endereço IP 1.2.3.4, impedindo que a regra de negação de prioridade mais baixa (com prioridade 200) seja acionada e bloqueada. o tráfego.

gcloud compute security-policies describe POLICY_NAME

Saída:

  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

A regra pré-configurada retorna falsos positivos

A detecção XSS e SQLi é baseada na correspondência estática de assinaturas nos cabeçalhos de solicitação HTTP e outros parâmetros L7. Esses padrões de expressão regular são propensos a falsos positivos. É possível usar a regra pré-configurada para a detecção de XSS e SQLi no modo de visualização e verificar se há algum falso positivo no registro.

Se encontrar um falso positivo, compare o conteúdo do tráfego com as regras de CRS do OWASP. Se a regra for inválida ou não relevante, desative-a usando a expressão evaluatePreconfiguredWaf e especifique o ID da regra no argumento exclude ID list.

Após revisar os registros e remover todos os falsos positivos, desative o modo de visualização.

Para adicionar uma regra pré-configurada no modo de visualização, siga as etapas abaixo:

Crie uma política de segurança com a expressão pré-configurada definida no modo de visualização:

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

Revise os registros HTTP(S) para campos de solicitação HTTP, como url e cookie. Por exemplo, o requestUrl se compara positivamente ao ID da regra 941180 do CRS do OWASP:

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'

Exclua o ID 941180 da regra de CRS do OWASP atualizando a regra na política de segurança do Cloud Armor:

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

Revise os registros novamente e desative o modo de visualização para implementar a regra.

Clientes com assinaturas negadas não são bloqueados ou negados

Se você estiver usando o Cloud Armor com o Cloud CDN, as políticas de segurança serão aplicadas apenas para solicitações de conteúdo dinâmico, ausências no cache ou outras solicitações destinadas ao servidor de origem da CDN. As ocorrências em cache serão exibidas mesmo se a política de segurança downstream do Cloud Armor impedir que a solicitação chegue ao servidor de origem da CDN.

Problemas com a limitação de taxa

O tráfego não está limitado como esperado

Você pode descobrir que um endereço IP de cliente está enviando altos níveis de tráfego para um aplicativo a uma taxa que excede o limite definido, mas o tráfego não é limitado como esperado. Siga estas etapas para investigar o problema.

Primeiro, confirme se uma regra de prioridade mais alta permite o tráfego desse endereço IP. Examine os registros para ver se uma regra ALLOW foi acionada para o endereço IP. Pode ser uma regra ALLOW sozinha ou em outra regra THROTTLE ou RATE_BASED_BAN.

Se você encontrar uma regra de prioridade mais alta, siga um destes procedimentos:

Altere as prioridades para garantir que a regra de limitação de taxa tenha uma prioridade maior, atribuindo a ela um valor numérico inferior.
Exclua o endereço IP da expressão correspondente na regra que tem uma prioridade mais alta.

O problema também pode ser que o limite está definido incorretamente. Se esse for o caso, as solicitações serão correspondidas com precisão, mas a ação de conformidade será acionada. Examine os registros para confirmar que esse é o caso e reduza o limite na sua regra.

Por fim, o endereço IP pode não corresponder à limitação ou à regra de proibição baseada em taxa. Para corrigir isso, verifique se há um erro na condição de correspondência e altere a condição de correspondência da regra para o valor correto.

A seguir

Receber suporte