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:
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
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:
configuredActiondeve corresponder à ação configurada na regranamedeve corresponder ao nome da política de segurança do Google Cloud Armor atrelada ao serviço de back-endoutcomeprecisa 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'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
describenosecurity-policiesna 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:
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 --previewRevise os registros HTTP(S) para campos de solicitação HTTP, como
urlecookie. Por exemplo, orequestUrlse 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'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 \ --previewRevise 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.
Verifique se o tráfego é proveniente de um endereço IP que está em uma lista de permissões de endereço IP nomeada.
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.
Verifique se 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 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
altostratpara criar um anexo da VLAN de monitoramento. As respectivas prioridades também são listadas.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émaltostrat. Como a solicitação tem um referenciador dehttp://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 vai 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 teste reCAPTCHA 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
têm um cookie de isenção se o usuário for aprovado na avaliação do
reCAPTCHA. Portanto, pelo menos duas entradas de registro são esperadas.
- Se você vir
GOOGLE_RECAPTCHAcomo a ação configurada eREDIRECTcomo o resultado, a solicitação foi redirecionada para a teste reCAPTCHA. - Se você vir
GOOGLE_RECAPTCHAcomo a ação configurada eACCEPTcomo o resultado, a solicitação estará isenta de ser redirecionada para teste reCAPTCHA. - 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 teste reCAPTCHA.
- O usuário precisa estar usando um navegador.
- O navegador precisa ativar o JavaScript para permitir o carregamento adequado da página de redirecionamento com o JavaScript do reCAPTCHA incorporado.
- O navegador precisa ativar os cookies para permitir a configuração e a anexação automática do cookie de isenção.
- O usuário precisa ser aprovado teste reCAPTCHA. 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 teste reCAPTCHA seja correspondida.
Terceiro, teste reCAPTCHA só é executada quando a página de redirecionamento que incorpora o JavaScript do reCAPTCHA é renderizada. Por esse motivo, o redirecionamento para teste reCAPTCHA 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 teste reCAPTCHA. 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 teste reCAPTCHA 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 teste reCAPTCHA 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:
- 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.