Solução de problemas do Google 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 Google Cloud Armor

Para corrigir isso, siga estas etapas:

  1. Verifique se a política de segurança do Google 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 Google Cloud Armor associada a este serviço de back-end.

    gcloud compute backend-services describe BACKEND
    
  2. 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 Google 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'
    
  3. 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 Google 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 ModSecurity. Se a regra for inválida ou não relevante, desative-a usando a expressão evaluatePreconfiguredExpr 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:

  1. 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 "evaluatePreconfiguredExpr('xss-stable')"
       --action deny-403
       --preview
    
  2. 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 ModSecurity:

    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. Exclua o ID 941180 da regra de CRS do ModSecurity atualizando a regra na política de segurança do Google Cloud Armor.

    gcloud compute security-policies rules update 1000 \
        --security-policy POLICY_NAME \
        --expression "evaluatePreconfiguredExpr('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \
        --action deny-403 \
        --preview
    
  4. 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 Google 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 Google Cloud Armor impedir que a solicitação chegue ao servidor de origem da CDN.

Redução de risco em corpo POST que excede 8 KB ao usar regras WAF pré-configuradas

Quando uma regra do WAF pré-configurada é avaliada em uma política de segurança do Google Cloud Armor, até 8 KB do corpo do POST são inspecionados para a correspondências de assinatura nas regras do WAF. Essa abordagem oferece inspeção e proteção de baixa latência para a camada 7, mantendo a disponibilidade para outros clientes do Google.

É possível reduzir o risco de solicitações POST maiores ao criar uma regra nas políticas de segurança para garantir que nenhum conteúdo não inspecionado chegue aos back-ends. Crie uma regra para negar o tráfego que excede 8 KB (8192 bytes) no tamanho do corpo POST. O exemplo de código a seguir mostra como criar essa regra:

gcloud compute security-policies rules create 10 \
    --security-policy my-policy \
    --expression "int(request.headers['content-length']) > 8192" \
    --action deny-403 \
    --description "Block requests great than 8KB"

Problemas com listas de endereços IP nomeadas

Nesta seção, você encontra informações para resolver problemas com listas de endereços IP nomeadas.

Endereços IP de uma lista de endereços IP nomeada

Os endereços IP das listas sempre correspondem aos endereços IP dos sites dos provedores listados no guia Listas de endereços IP do Google Cloud Armor. Se você tiver dúvidas sobre as listas, entre em contato com a equipe de suporte do Cloud.

Os endereços IP de uma lista de endereços IP nomeados estão desatualizados no Google Cloud Armor

O Google Cloud Armor sincroniza diariamente as listas com provedores de listas de endereços IP. É possível que haja dados desatualizados com algumas horas ou um dia de atraso em relação aos dados de um provedor. No entanto, se você achar que os dados desatualizados tiverem um atraso maior que o esperado, por exemplo, mais de uma semana, entre em contato com a equipe de suporte do Cloud.

Dificuldades para criar uma política de segurança que se refira a uma lista de endereços IP nomeada

Tente criar uma política de segurança que se refira a uma lista de endereços IP nomeados usando um comando como este:

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

Se o comando falhar, o erro exibido será algo assim:

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 Google Cloud Armor rule matcher expression: sourceiplist-example
is not a valid preconfigured expression set.

Verifique se o provedor em questão é compatível e se o nome da lista de endereços IP foi fornecido corretamente. É possível verificar isso usando o seguinte comando gcloud para listar os conjuntos de expressões pré-configuradas atuais:

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

O tráfego está bloqueado, apesar de haver uma regra pré-configurada para uma lista de permissões de endereços IP nomeada

É possível descobrir que o tráfego está bloqueado de um endereço IP que está em uma lista de endereços IP nomeada.

  1. Verifique se o tráfego é proveniente de um endereço IP que está em uma lista de permissões de endereço IP nomeada.

  2. Verifique se há outras regras de segurança com prioridade mais alta que podem bloquear o tráfego. Se o problema persistir, entre em contato com a equipe de suporte do Cloud.

  3. Verifique se a política de segurança está anexada ao serviço de back-end correto:

    gcloud compute backend-services describe BACKEND_SERVICE
    
  4. Verifique as regras que estão na política de segurança. Exemplo:

     gcloud compute security-policies describe POLICY_NAME
    

    O comando retorna informações semelhantes às seguintes:

    ---
    …
    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
    …
    

    A política de segurança anterior contém três regras: uma de negação padrão, uma regra de permissão para Endereços IP de Fastly e uma regra de negação para um referenciador que contém altostrat para criar um anexo da VLAN de monitoramento. As respectivas prioridades também são listadas.

  5. Revise os registros para determinar qual regra corresponde ao seu tráfego e à ação associada. Para informações sobre geração de registros, consulte Como usar o Explorador de registros.

    Veja a seguir um exemplo de registro:

     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"
      }
      …
    

    No registro anterior, a solicitação vem de 23.230.32.10, que é coberto pela Lista de endereços IP públicos do Fastly. No entanto, a solicitação é correspondida com uma regra de negação de prioridade mais alta de 50. Em comparação com o que está na política de segurança, a regra corresponde à regra de negação para um referenciador que contém altostrat. Como a solicitação tem um referenciador de http://www.altostrat.com/, a aplicação da regra de segurança está funcionando corretamente.

Problemas com as descobertas do Security Command Center

Esta seção contém informações sobre problemas com as descobertas do Security Command Center.

O cartão do Google Cloud Armor não aparece no Security Command Center

Ative as descobertas do Google Cloud Armor na interface do Security Command Center.

As descobertas do Google Cloud Armor não aparecem no Security Command Center

Se as descobertas do Google Cloud Armor não aparecerem no Security Command Center, o tráfego para os serviços de back-end poderá não atender aos critérios para gerar uma descoberta.

Para perguntas sobre o volume de tráfego dos back-ends, verifique as estatísticas de solicitações nos painéis do Cloud Monitoring em Políticas de segurança de rede.

As descobertas contêm muito ruído

Para receber ajuda para esse problema, entre em contato com a equipe de suporte do Cloud.

Problemas com a proteção adaptativa do Google Cloud Armor

Use estas instruções para resolver problemas com a Proteção adaptativa.

O Proteção adaptativa está ativado para uma política de segurança, mas não há registros no Cloud Logging

Os registros de proteção adaptativa são gerados separadamente dos registros de solicitação do Google Cloud Armor e aparecem em um recurso diferente no Cloud Logging. Os registros e eventos da proteção adaptativa estão no recurso Política de segurança de rede no Cloud Logging. Há um período de treinamento de pelo menos uma hora depois da ativação da proteção adaptativa em uma política de segurança antes que ela seja iniciada para gerar alertas sobre ataques suspeitos. Durante o período de treinamento, a Proteção adaptável aprende com o tráfego de solicitações recebidas e desenvolve valores de referência distintos para cada serviço de back-end protegido por essa política de segurança. A Proteção adaptativa consegue identificar atividades suspeitas posteriormente.

Se você ativar a Proteção adaptativa para uma política de segurança e não observar nenhum alerta após um período de treinamento de uma hora, isso indicará que não há atividade que possa ser identificada como uma segmentação potencialmente maliciosa de qualquer { 101}os serviços de back-end associados a essa política de segurança.

Se o possível ataque ou tráfego anômalo persistir por mais tempo, excedendo várias horas, a Proteção adaptativa começará a considerar esse comportamento como comportamento de referência e não continuará a alertar sobre padrões de tráfego semelhantes. Depois que o tráfego e os padrões de tráfego em potencial retornam ao valor de referência original, seja porque o ataque terminou ou você o bloqueou com as regras apropriadas do Google Cloud Armor, os alertas da Proteção adaptativa sobre os comportamentos futuros de tráfego que estão considera as partidas do valor de referência.

A Proteção adaptativa analisa o tráfego que seria permitido por meio de uma política de segurança do Google Cloud Armor. Se você definir a regra padrão para negar acesso com uma lista de permissão de tráfego restrita, o Proteção adaptável detectará apenas a atividade mal-intencionada no tráfego que passar pela avaliação junto com a lista de permissão.

Há muitos alertas ou registros no Cloud Logging pela Proteção adaptativa

Um alerta de proteção adaptativa proporciona um índice de confiança que indica como os modelos da Proteção adaptativa identificam a atividade detectada como nocivo e possivelmente um ataque. É possível filtrar a entrada específica do registro por meio do Cloud Logging para exibir ou encaminhar para os alertas que têm uma pontuação de confiança acima de um limite específico.

A Proteção adaptativa fornece um mecanismo para relatar alertas como falsos positivos, descrito na seção Como monitorar erros de evento, feedback e relatório. Os relatórios de falsos positivos podem não resultar em alterações imediatas nos alertas de Proteção adaptativa. Com o tempo, os modelos de Proteção adaptativa aprendem que esses padrões de tráfego são normais e aceitáveis, e a Proteção adaptativa deixa de alertar sobre esses padrões.

Se os alertas da Proteção adaptativa forem muito frequentes em um subconjunto de serviços de back-end em uma política de segurança, ele poderá sugerir que o tráfego normal desses serviços de back-end tenha flutuações significativas que são constantemente identificadas pela Proteção adaptativa como comportamentos anômalos. para criar um anexo da VLAN de monitoramento. É possível criar uma política de segurança separada sem a Proteção adaptável ativada e associar esses serviços de back-end à nova política de segurança.

Um incidente específico informado pela Proteção adaptativa é considerado um falso positivo ou não é relevante

O Proteção adaptativa fornece um mecanismo para denunciar alertas positivos falsos. Siga o procedimento descrito na seção Como monitorar erros de feedback, feedback e geração de relatórios. Os relatórios de falsos positivos podem não resultar em alterações imediatas sobre os alertas de Proteção adaptativa. Com o tempo, os modelos de Proteção adaptativa aprendem que esses padrões de tráfego são normais e aceitáveis e que, por padrão, o Alerta de segurança para de alertar esses padrões.

Como sei que minhas políticas de segurança de borda estão sendo aplicadas?

É possível verificar as ações realizadas nas políticas de segurança de borda verificando os painéis de monitoramento, as métricas de monitoramento ou a geração de registros por solicitação.

Monitoramento de painéis

O Cloud Monitoring está disponível na página Políticas de segurança de rede em Monitoramento. Use o detalhamento por política de segurança na página para medir o número de solicitações permitidas e negadas pela política de segurança perimetral configurada. Também é possível examinar o detalhamento por serviço de back-end para depurar um determinado serviço de back-end. Para detalhes sobre o painel do Cloud Monitoring, consulte Como monitorar políticas de segurança do Google Cloud Armor.

Como monitorar métricas

As métricas brutas que medem as solicitações permitidas e negadas estão disponíveis para políticas de segurança de borda. Para mais informações, consulte Métricas de monitoramento das políticas de segurança.

Geração de registros por solicitação

A decisão sobre a política de segurança perimetral é registrada nos registros de solicitação de balanceamento de carga em enforcedEdgeSecurityPolicy. Isso é separado da enforcedSecurityPolicy, que captura a decisão da política de segurança de back-end.

Gerenciamento de bots

Esta seção contém informações sobre como solucionar problemas com o gerenciamento de bots.

Os usuários não estão isentos conforme o esperado

Você pode ter configurado regras de política de segurança com a ação de redirecionamento para a avaliação do reCAPTCHA Enterprise e descobrir que alguns usuários que você acha que são legítimos não foram isentos conforme o esperado. Siga as etapas abaixo para resolver problemas.

Primeiro, verifique os registros por solicitação para ver se há uma regra de política de segurança com maior prioridade que corresponda ao tráfego, em que a ação é diferente. Procure especificamente os campos configured_action e outcome. Para que um usuário seja isento, há pelo menos duas solicitações envolvidas. A solicitação inicial vem sem um cookie de isenção, e as solicitações subsequentes vêm com um cookie de isenção se o usuário for aprovado na avaliação do reCAPTCHA Enterprise. Portanto, pelo menos duas entradas de registro são esperadas.

  • Se você vir GOOGLE_RECAPTCHA como a ação configurada e REDIRECT como o resultado, a solicitação será redirecionada para a avaliação do reCAPTCHA Enterprise;
  • Se você vir GOOGLE_RECAPTCHA como a ação configurada e ACCEPT como o resultado, a solicitação estará isenta de ser redirecionada para a avaliação do reCAPTCHA Enterprise.
  • Se você vir valores diferentes nos campos acima, uma regra com uma ação diferente foi correspondida. Nesse caso, é esperado que o usuário não seja redirecionado ou isento.

Segundo, há vários requisitos do lado do usuário para que eles sejam isentos do redirecionamento para a avaliação do reCAPTCHA Enterprise.

  1. O usuário precisa estar usando um navegador.
  2. O navegador precisa ativar o JavaScript para permitir o carregamento adequado da página de redirecionamento com o JavaScript do reCAPTCHA Enterprise incorporado.
  3. O navegador precisa ativar os cookies para permitir a configuração e a anexação automática do cookie de isenção.
  4. O usuário precisa ser aprovado na avaliação do reCAPTCHA Enterprise; Por exemplo, eles precisam resolver desafios de pop-up, se houver.

Os usuários que não atenderem a nenhum dos requisitos acima não receberão isenção, mesmo que uma regra com a ação de redirecionamento para avaliação do reCAPTCHA Enterprise seja correspondida.

Em terceiro lugar, a avaliação do reCAPTCHA Enterprise só é executada quando a página de redirecionamento que incorpora o JavaScript do reCAPTCHA Enterprise é renderizada. Por esse motivo, o redirecionamento para a avaliação do reCAPTCHA Enterprise só é aplicável a solicitações que esperam uma resposta que leve a uma renderização de página inteira. Outras solicitações, como o carregamento de recursos em uma página ou solicitações provenientes de um script incorporado que não esperam que a resposta seja renderizada, não podem receber a avaliação do reCAPTCHA Enterprise. Assim, recomendamos que você aplique essa ação com uma condição de correspondência para caminhos de URL que satisfaçam essa condição.

Por exemplo, imagine que você tenha uma página da Web que contenha elementos incorporados, como imagens, links para outras páginas da Web e scripts. Você não quer aplicar a ação de redirecionamento para a avaliação do reCAPTCHA Enterprise para caminhos de URL que hospedam imagens ou que devem ser acessados por scripts em que uma renderização de página inteira não é esperada. Em vez disso, você pode aplicar a ação de redirecionamento para a avaliação do reCAPTCHA Enterprise para caminhos de URL que hospedam páginas da Web, como a página da Web principal ou outras páginas vinculadas.

Por fim, se a página de redirecionamento for renderizada, verifique na Ferramenta de desenvolvedor fornecida pelo navegador para ver se um cookie de isenção está definido e se ele está anexado nas solicitações subsequentes do mesmo site. Para receber mais assistência, entre em contato com a equipe de suporte do Cloud.

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:

  1. 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.
  2. 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