Use estas instruções para resolver problemas com as políticas de segurança do Google Cloud Armor.
Problemas gerais
Depuração de políticas de segurança
Se precisar de informações adicionais sobre o que um evento específico aciona as regras pré-configuradas, leia o artigo Usar o registo de pedidos e, em seguida, ative o registo detalhado. O Cloud Logging regista um nível mais elevado de detalhes nos seus registos que pode usar para analisar e depurar as suas políticas e regras.
O tráfego é permitido apesar de existir uma regra de recusa configurada na política de segurança do Cloud Armor
Para corrigir este problema, siga estes passos:
Certifique-se de que a política de segurança do Cloud Armor está anexada a um serviço de back-end de destino. Por exemplo, o comando seguinte descreve todos os dados associados ao serviço de back-end
BACKEND. Os resultados devolvidos 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
Reveja os registos HTTP(S) para determinar a política e a regra que corresponderam ao seu tráfego, juntamente com a ação associada. Para ver os registos, use os Registos na nuvem.
Segue-se um exemplo de um registo de um pedido permitido com os campos interessantes realçados. Verifique os seguintes campos e certifique-se de que correspondem à regra que configurou para recusar o tráfego:
configuredActiondeve corresponder à ação configurada na regra.namedeve corresponder ao nome da política de segurança do Cloud Armor anexada a este serviço de back-end.outcomedeve corresponder aconfiguredAction.prioritydeve 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'Reveja a hierarquia das regras para garantir que é encontrada a regra correta. É possível que uma regra de prioridade mais elevada com uma ação de permissão esteja a corresponder ao seu tráfego. Use o comando
describenasecurity-policiesna CLI gcloud para ver o conteúdo da política de segurança do Cloud Armor.Por exemplo, o exemplo seguinte mostra como uma regra de permissão de prioridade mais elevada (com prioridade 100) corresponde ao tráfego proveniente do endereço IP 1.2.3.4, impedindo que a regra de rejeição de prioridade mais baixa (com prioridade 200) seja acionada e bloqueie 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 devolve falsos positivos
A deteção de XSS e SQLi baseia-se na correspondência de assinaturas estáticas nos cabeçalhos de pedidos HTTP e noutros parâmetros da camada 7. Estes padrões de expressões regulares são propensos a falsos positivos. Pode usar a regra pré-configurada para a deteção de XSS e SQLi no modo de pré-visualização e, em seguida, verificar o registo para quaisquer falsos positivos.
Se encontrar um falso positivo, pode comparar o conteúdo do tráfego com as regras da CRS da OWASP.
Se a regra for inválida ou não for relevante, desative-a através da expressão evaluatePreconfiguredWaf e especifique o ID da regra no argumento exclude ID list.
Depois de rever os registos e remover todos os falsos positivos, desative o modo de pré-visualização.
Para adicionar uma regra pré-configurada no modo de pré-visualização:
Crie uma política de segurança com o conjunto de expressões pré-configurado no modo de pré-visualização:
gcloud compute security-policies rules create 1000 --security-policy POLICY_NAME --expression "evaluatePreconfiguredWaf('xss-stable')" --action deny-403 --previewReveja os registos HTTP(S) para campos de pedidos HTTP, como
urlecookie. Por exemplo, arequestUrltem uma comparação positiva com o ID da regra 941180 do OWASP CRS: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 da regra OWASP CRS 941180 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 \ --previewReveja novamente os registos e, em seguida, desative o modo de pré-visualização para implementar a regra.
Os clientes com assinaturas recusadas não são bloqueados nem recusados
Se estiver a usar o Cloud Armor com o Cloud CDN, as políticas de segurança são aplicadas apenas a pedidos de conteúdo dinâmico, falhas de cache ou outros pedidos destinados ao servidor de origem da RFC. Os resultados da cache são apresentados mesmo que a política de segurança do Cloud Armor a jusante impeça esse pedido de chegar ao servidor de origem da RFC.
Problemas com listas de endereços IP com nome
Esta secção fornece informações para resolver problemas com listas de endereços IP denominados.
Endereços IP numa lista de endereços IP com nome
Os endereços IP nas listas correspondem sempre aos endereços IP nos websites dos fornecedores indicados no guia de listas de endereços IP com nome do Cloud Armor. Se tiver dúvidas sobre as listas, contacte a equipa de apoio técnico do Google Cloud.
Os endereços IP numa lista de endereços IP com nome estão desatualizados no Cloud Armor
O Cloud Armor sincroniza as respetivas listas com fornecedores de listas de endereços IP diariamente. É possível ter dados desatualizados com um atraso de algumas horas ou um dia em relação aos dados de um fornecedor. No entanto, se considerar que os dados desatualizados estão mais atrasados do que o esperado, por exemplo, mais de uma semana, contacte a equipa de apoio técnico da nuvem.
Dificuldade em criar uma política de segurança que faça referência a uma lista de endereços IP com nome
Pode tentar criar uma política de segurança que faça referência a uma lista de endereços IP com nome, 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 apresentado tem um aspeto semelhante ao seguinte:
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
is not a valid preconfigured expression set.
Certifique-se de que o fornecedor específico é suportado e que o nome da lista de endereços IP é indicado corretamente. Pode verificar esta situação através do seguinte comando gcloud para listar os conjuntos de expressões pré-configurados atuais:
gcloud compute security-policies list-preconfigured-expression-sets
O tráfego é bloqueado apesar de existir uma regra pré-configurada para uma lista de autorizações de endereços IP com nome
Pode verificar que o tráfego está bloqueado a partir de um endereço IP que se encontra numa lista de endereços IP denominada:
Certifique-se de que o tráfego é proveniente de um endereço IP que se encontra numa lista de autorizações de endereços IP com nome.
Verifique se existem outras regras de segurança com uma prioridade superior que possam bloquear o tráfego. Se o problema persistir, contacte a equipa de apoio técnico do Google Cloud.
Certifique-se de que a política de segurança está anexada ao serviço de back-end correto:
gcloud compute backend-services describe BACKEND_SERVICE
Verifique as regras que estão na política de segurança. Por exemplo:
gcloud compute security-policies describe POLICY_NAME
O comando devolve 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 regra de recusa predefinida, uma regra de permissão para os endereços IP da Fastly e uma regra de recusa para um referenciador que contenha
altostrat. As respetivas prioridades também são apresentadas.Reveja os registos para determinar a regra que corresponde ao seu tráfego e a ação associada. Para ver informações sobre o registo, consulte o artigo Usar o Explorador de registos.
Segue-se um exemplo de um registo:
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" } …A partir do registo anterior, o pedido é proveniente de
23.230.32.10, que está coberto pela lista de endereços IP públicos da Fastly. No entanto, o pedido é correspondido com uma regra de recusa com uma prioridade mais elevada de 50. Comparando isto com o que está na política de segurança, a regra corresponde à regra de recusa para um referenciador que contémaltostrat. Uma vez que o pedido tem um referenciador dehttp://www.altostrat.com/, a aplicação da regra de segurança está a funcionar corretamente.
Problemas com as conclusões do Security Command Center
Esta secção contém informações sobre problemas com as conclusões do Security Command Center.
O cartão do Cloud Armor não aparece no Security Command Center
Ative as conclusões do Cloud Armor na interface do Security Command Center.
As conclusões do Cloud Armor não aparecem no Security Command Center
Se as conclusões do Cloud Armor não aparecerem no Security Command Center, o tráfego para os serviços de back-end pode não cumprir os critérios para gerar uma conclusão.
Para questões sobre o volume de tráfego para os seus back-ends, verifique as estatísticas de pedidos nos painéis de controlo do Cloud Monitoring em Políticas de segurança de rede.
Os resultados são demasiado ruidosos
Para receber assistência com este problema, contacte a equipa de apoio técnico do Google Cloud.
Problemas com a proteção adaptativa do Google Cloud Armor
Use estas instruções para ajudar a resolver problemas com a Proteção adaptativa.
A Proteção adaptativa está ativada para uma política de segurança, mas não existem registos no Cloud Logging
Os registos da proteção adaptativa são gerados separadamente dos registos de pedidos do Cloud Armor e aparecem num recurso diferente no Cloud Logging. Os registos e os eventos da proteção adaptativa encontram-se no recurso Política de segurança de rede no Cloud Logging. Existe um período de preparação de, pelo menos, uma hora após a ativação da Proteção adaptativa numa política de segurança antes de a Proteção adaptativa começar a gerar alertas para ataques suspeitos. Durante o período de formação, a proteção adaptativa aprende com o tráfego de pedidos recebidos e desenvolve referências distintas para cada serviço de back-end protegido por essa política de segurança. Posteriormente, a Proteção adaptativa consegue identificar atividade suspeita.
Se ativar a proteção adaptativa para uma política de segurança e não observar alertas após um período de formação de uma hora, isto sugere que não existe atividade que possa ser identificada como segmentação potencialmente maliciosa de nenhum dos serviços de back-end associados a essa política de segurança.
Se o potencial ataque ou tráfego anómalo persistir durante períodos mais longos, excedendo várias horas, a proteção adaptativa começa a considerar esse comportamento como comportamento de base e não continua a emitir alertas sobre padrões de tráfego semelhantes. Depois de o potencial ataque diminuir e os padrões de tráfego voltarem à linha de base original, quer o ataque tenha terminado ou o tenha bloqueado com as regras do Cloud Armor adequadas, a Proteção adaptativa envia alertas sobre comportamentos de tráfego futuros que sejam considerados desvios da linha de base.
A proteção adaptativa analisa o tráfego que, de outra forma, seria permitido através de uma política de segurança do Cloud Armor. Se definir a regra predefinida para negar o acesso com uma lista de autorizações restrita de tráfego, a proteção adaptativa apenas deteta atividade maliciosa no tráfego que passa na avaliação relativamente à lista de autorizações.
Existem demasiados alertas ou registos no Cloud Logging da Proteção adaptativa
Um alerta de proteção adaptativa fornece uma classificação de confiança, indicando a força com que os modelos de proteção adaptativa identificam a atividade detetada como anómala e potencialmente um ataque. Pode filtrar a entrada específica do registo através do Cloud Logging para apresentar (ou encaminhar para jusante) apenas os alertas que tenham uma pontuação de confiança acima de um determinado limite.
A proteção adaptativa oferece um mecanismo para comunicar alertas como falsos positivos, o que é descrito na secção Monitorização, feedback e comunicação de erros de eventos. Tenha em atenção que os relatórios de falsos positivos podem não resultar em alterações imediatas aos alertas da Proteção Adaptativa. Ao longo do tempo, os modelos de proteção adaptável aprendem que estes padrões de tráfego são normais e aceitáveis, e a proteção adaptável deixa de emitir alertas sobre estes padrões.
Se os alertas de proteção adaptável forem demasiado frequentes num subconjunto de serviços de back-end numa política de segurança, pode sugerir que o tráfego normal destes serviços de back-end tem flutuações significativas que são constantemente identificadas pela proteção adaptável como comportamentos anómalos. Pode criar uma política de segurança separada sem a Proteção adaptável ativada e associar estes serviços de back-end à nova política de segurança.
Um incidente específico comunicado pela proteção adaptativa é considerado um falso positivo ou não é relevante
A proteção adaptativa oferece um mecanismo para comunicar alertas de falsos positivos. Siga o procedimento descrito na secção Monitorização, feedback e relatórios de erros de eventos. Tenha em atenção que os relatórios de falsos positivos podem não resultar em alterações imediatas ao que a Proteção Adaptativa alerta. Ao longo do tempo, os modelos de proteção adaptativa aprendem que estes padrões de tráfego são normais e aceitáveis, e a proteção adaptativa deixa de emitir alertas sobre estes padrões.
Como posso saber se as minhas políticas de segurança de limite estão a ser aplicadas?
Pode verificar as ações realizadas nas suas políticas de segurança de limite ao consultar os painéis de controlo de monitorização, as métricas de monitorização ou o registo por pedido.
Painéis de controlo de monitorização
O Cloud Monitoring está disponível na página Políticas de segurança de rede em Monitorização. Pode usar a discriminação por política de segurança na página para medir o número de pedidos permitidos e recusados pela política de segurança de limite configurada. Também pode examinar a discriminação por serviço de back-end para depurar um serviço de back-end específico. Para ver detalhes sobre o painel de controlo do Cloud Monitoring, consulte o artigo Monitorizar políticas de segurança do Cloud Armor.
Métricas de monitorização
As métricas não processadas que medem os pedidos permitidos e recusados estão disponíveis para políticas de segurança de limite. Para mais informações, consulte o artigo Monitorizar métricas para políticas de segurança.
Registo por pedido
A decisão da política de segurança de limite é registada nos registos de pedidos de equilíbrio de carga
em enforcedEdgeSecurityPolicy. Isto é separado da
enforcedSecurityPolicy, que capta a decisão da política de segurança de back-end.
Gestão de bots
Esta secção contém informações sobre a resolução de problemas com a gestão de bots.
Os utilizadores não estão isentos conforme esperado
Pode ter configurado regras de política de segurança com a ação de redirecionamento para a avaliação do reCAPTCHA e verificado que alguns utilizadores que considera legítimos não foram isentos conforme esperado. Siga os passos abaixo para resolver problemas.
Primeiro, verifique os registos por pedido para ver se existe uma regra de política de segurança com uma prioridade superior que corresponda ao tráfego, na qual a ação seja diferente. Em particular, procure os campos configured_action e outcome.
Tenha em atenção que, para um utilizador ser isento, estão envolvidos, pelo menos, dois pedidos. O pedido inicial é feito sem um cookie de isenção e os pedidos subsequentes são feitos com um cookie de isenção se o utilizador passar na avaliação do reCAPTCHA. Por conseguinte, são esperadas, pelo menos, duas entradas de registo.
- Se vir
GOOGLE_RECAPTCHAcomo a ação configurada eREDIRECTcomo o resultado, o pedido foi redirecionado para avaliação do reCAPTCHA; - Se vir
GOOGLE_RECAPTCHAcomo a ação configurada eACCEPTcomo o resultado, o pedido foi isento de ser redirecionado para a avaliação do reCAPTCHA. - Se vir valores diferentes nos campos acima, significa que foi encontrada uma regra com uma ação diferente. Nesse caso, espera-se que o utilizador não seja redirecionado nem isento.
Em segundo lugar, existem vários requisitos do lado do utilizador para que este seja isento de redirecionamento para avaliação do reCAPTCHA.
- O utilizador tem de estar a usar um navegador.
- O navegador tem de ativar o JavaScript para permitir o carregamento adequado da página de redirecionamento com o JavaScript do reCAPTCHA incorporado.
- O navegador tem de ativar os cookies para permitir a definição e a anexação automática do cookie de isenção.
- O utilizador tem de passar na avaliação do reCAPTCHA. Por exemplo, tem de resolver os desafios de pop-up, se existirem.
Tenha em atenção que os utilizadores que não conseguem cumprir nenhum dos requisitos acima não recebem isenção, mesmo que seja encontrada uma regra com a ação de redirecionamento para a avaliação do reCAPTCHA.
Em terceiro lugar, a avaliação do reCAPTCHA só é executada quando a página de redirecionamento que incorpora o JavaScript do reCAPTCHA é renderizada. Por esse motivo, o redirecionamento para a avaliação do reCAPTCHA só é aplicável a pedidos que esperam uma resposta que resulte na renderização de uma página completa. Outros pedidos, como o carregamento de recursos numa página ou pedidos provenientes de um script incorporado que não esperam que a resposta seja renderizada, não devem receber uma avaliação do reCAPTCHA. Como tal, recomendamos que aplique esta ação com uma condição de correspondência para caminhos de URL que satisfaçam esta condição.
Por exemplo, suponhamos que tem uma página Web que contém elementos incorporados, como imagens, links para outras páginas Web e scripts. Não quer aplicar a ação de redirecionamento para a avaliação do reCAPTCHA para caminhos de URL que alojam imagens ou que se destinam a ser acedidos por scripts em que não se espera uma renderização de página completa. Em alternativa, pode aplicar a ação de redirecionamento para a avaliação do reCAPTCHA para caminhos de URL que alojam páginas Web, como a página Web principal ou outras páginas Web com links.
Por último, se a página de redirecionamento for renderizada com êxito, verifique na ferramenta para programadores fornecida pelo navegador se foi definido um cookie de isenção e se este está anexado nos pedidos subsequentes para o mesmo site. Para receber mais assistência, pode contactar a equipa de apoio técnico do Google Cloud.
Problemas com a limitação de taxa
O tráfego não é limitado como esperado
Pode verificar que um endereço IP do cliente está a enviar níveis elevados de tráfego para uma aplicação a uma taxa que excede o limite definido, mas o tráfego não é limitado como esperado. Siga estes passos para investigar o problema.
Primeiro, confirme se uma regra de prioridade mais elevada está a permitir tráfego desse endereço IP. Examine os registos para ver se foi acionada uma regra ALLOW para o endereço IP. Pode ser uma regra ALLOW por si só ou noutra regra THROTTLE ou RATE_BASED_BAN.
Se encontrar uma regra de prioridade mais elevada, faça uma das seguintes ações:
- Altere as prioridades para garantir que a regra de limitação de taxa tem uma prioridade mais elevada, atribuindo-lhe 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 o facto de o limite estar definido incorretamente. Se for este o caso, é feita a correspondência precisa dos pedidos, mas a ação de conformidade é acionada. Examine os registos para confirmar se é este o caso e, em seguida, reduza o limite na sua regra.
Por último, o endereço IP pode não corresponder à regra de limitação ou proibição baseada na taxa. Para corrigir este problema, verifique se existe um erro na condição de correspondência e, em seguida, altere a condição de correspondência da regra para o valor correto.