Deixe passar os bots da CoreDash pela sua CDN ou firewall

Deixe passar ambos os bots da CoreDash pela CDN ou firewall

A CoreDash tem dois bots que visitam o seu site: a auditoria cRUM e a verificação de uptime. Para tirar o máximo partido da CoreDash, a sua CDN ou firewall tem de deixar passar ambos. Por vezes, uma dessas configurações bloqueia-os. Esta página mostra como resolver isso na Cloudflare e no AWS WAF, com uma única regra que cobre ambos os bots.

O que os dois bots fazem:

• A auditoria cRUM. Ao escolher uma página em cRUM (beta) no menu da CoreDash, a CoreDash abre essa página no Chrome, no seu servidor de auditoria, tal como faria um visitante, e mostra o que a está a tornar lenta. O respetivo user agent é CoreDash/1.0 (audit; +https://www.coredash.app/bot).
• A verificação de uptime. A cada 30 minutos, a CoreDash faz um pedido a partir dos seus próprios servidores a cada site monitorizado e avisa quando algum vai abaixo. Envia CoreDash/1.0 (uptime; +https://www.coredash.app/bot).

O user agent é o nome que um browser ou bot envia em cada pedido para se identificar. Ambos os da CoreDash começam por CoreDash/, e é isso que a regra vai procurar.

O que acontece quando uma auditoria ou verificação de uptime é bloqueada

A sua firewall ou CDN deteta um visitante vindo de um datacenter cujo user agent não é o de um browser. Trata esse visitante como um bot em que não confia e responde com um código de erro ou uma página de desafio. Cada bot mostra isso à sua maneira.

Uma auditoria cRUM bloqueada para com a mensagem "Audit failed" e um erro por baixo. Ou então é executada na mesma, mas na página de bloqueio: o Page load filmstrip passa a mostrar uma página de desafio ou de erro em vez da sua, e todos os valores da auditoria pertencem a essa página.

O monitor de uptime indica Blocked, e o aviso "A firewall blocks the checker" mostra o código de estado recebido pelas verificações e desde quando. A CoreDash não inclui as verificações bloqueadas no tempo de inatividade, pelo que o bloqueio não reduz o seu uptime. Mas enquanto todas as verificações forem bloqueadas, nenhuma chega ao site, e o monitor não consegue avisar se o site for abaixo.

A página do monitor para example-shop.com quando a Cloudflare responde a todas as verificações de uptime com um 403.

Como a firewall reconhece a CoreDash

Basta criar uma exceção para a CoreDash na sua firewall ou CDN, e a maioria fá-lo com base no user agent: uma regra para CoreDash/ deixa passar a auditoria e a verificação de uptime. O bot token do seu projeto torna essa regra mais restrita, porque só os bots do seu próprio projeto o enviam. Os endereços IP da CoreDash servem para quando nada mais funciona. Mudam quando a CoreDash adiciona ou transfere um servidor, por isso terá de manter essa regra atualizada manualmente.

O log da firewall mostra qual é a configuração que precisa da exceção. O log da Cloudflare é abordado na secção seguinte. Para o AWS WAF, consulte a secção "Permita a CoreDash no AWS WAF, acima do Bot Control" mais abaixo.

Descubra o que bloqueou a CoreDash na Cloudflare

Abra o seu domínio na Cloudflare e aceda a Security › Analytics, separador Events. Em Sampled logs, procure um pedido com um user agent da CoreDash. Num site com muito tráfego, clique em Filter, escolha User agent no campo e cole o user agent completo no valor: CoreDash/1.0 (uptime; +https://www.coredash.app/bot) para a verificação de uptime ou CoreDash/1.0 (audit; +https://www.coredash.app/bot) para a auditoria.

Clique no pedido para o abrir. A linha Service indica a funcionalidade da Cloudflare que o bloqueou.

O Browser Integrity Check bloqueou esta verificação de uptime em example-shop.com.

Essa linha Service dita a solução:

• Bot fight mode: é a proteção contra bots do plano Free da Cloudflare, e as suas regras não conseguem abrir uma exceção para ela. Avance para a secção sobre o Bot Fight Mode mais abaixo.
• Qualquer outra indicação, como o Browser integrity check na captura de ecrã, uma regra gerida ou o Super Bot Fight Mode: crie a regra Skip indicada abaixo.

Deixe passar a CoreDash na Cloudflare com uma regra Skip

Uma regra Skip diz à Cloudflare para ignorar os pedidos com o user agent da CoreDash nas funcionalidades que escolher. Cobre a auditoria e a verificação de uptime de uma só vez, e pode ser criada em qualquer plano da Cloudflare.

1. Aceda a Security › Security rules. Em Custom rules, clique em Create rule.

Security rules de example-shop.com, antes da primeira custom rule.

2. Dê o nome CoreDash à regra. Em "When incoming requests match", clique em "Edit expression" e cole esta linha na caixa de texto que se abre.

   http.user_agent contains "CoreDash/"

Nome da regra e expressão, após o clique em "Edit expression". A barra a seguir a CoreDash faz mesmo parte da expressão.

3. Em "Then take action", escolha Skip e defina o que a Cloudflare deve ignorar no caso da CoreDash. Em "WAF components to skip", assinale "All managed rules" e "All Super Bot Fight Mode Rules". Clique em "More components to skip" para expandir e assinale também "Browser Integrity Check". Deixe "Log matching requests" ativo, para que a secção Events mostre a regra a funcionar mais tarde.

A ação Skip, com as três opções assinaladas.

4. Clique em Deploy. Se o seu domínio já tiver outras custom rules, a Cloudflare pergunta onde colocar esta: coloque-a em primeiro lugar.

Sem outras custom rules não há nada para posicionar, pelo que clicar em Deploy é o último passo.

5. Confirme que a CoreDash passa. Assim que chegar a próxima auditoria ou verificação de uptime, a secção Events na Cloudflare lista o pedido com a ação Skip. Na CoreDash, verifique o bot que utiliza, ou ambos.

Para a auditoria cRUM, selecione novamente a página em cRUM (beta), ou recarregue o separador do browser onde ela está aberta, e uma nova auditoria terá início. Assim que passar, o Page load filmstrip mostra a sua própria página a carregar no Chrome, fotograma a fotograma.

Uma auditoria concluída, com o TTFB, FCP, LCP e CLS assinalados nos fotogramas.

A verificação de uptime não exige qualquer clique: a CoreDash faz verificações à hora certa e à meia hora, pelo que no prazo de 30 minutos o monitor passa a Up e as novas barras ficam verdes.

example-shop.com está de novo em Up: 38 verificações receberam um 403, e todas as verificações após a regra receberam um 200.

Uma regra mais segura na Cloudflare com o bot token da CoreDash

Qualquer pessoa pode enviar um user agent que comece por CoreDash/, pelo que um bot malicioso que se faça passar pela CoreDash também passaria pela regra Skip. O bot token do seu projeto é confidencial: cada auditoria e verificação de uptime envia-o num header chamado X-CoreDash-Bot. Uma regra baseada nesse token deixa passar apenas os bots do seu próprio projeto.

Para o obter, abra Project settings na CoreDash e aceda ao separador "CoreDash bot token". Apenas o proprietário do projeto o pode abrir. Enquanto um monitor indicar Blocked, o link "View your CoreDash bot token" no respetivo aviso também o leva até lá. Clique em "Copy Cloudflare rule" para obter a expressão completa já com o seu token.

"Copy Cloudflare rule" coloca a expressão com o seu token na área de transferência.

Se já criou a regra Skip, aceda a Security › Security rules e abra a regra CoreDash. Substitua a linha do user agent na expressão pelo que copiou e guarde a regra. A ação e as caixas assinaladas mantêm-se como estão. Se ainda não tiver a regra, siga os passos da regra Skip acima e cole a linha do token no passo 2.

O token só é enviado para o site do próprio projeto e respetivos subdomínios. A monitorização ou auditoria de uma página noutro domínio não envia qualquer token, pelo que esse domínio deve manter a regra pelo user agent. E se o token alguma vez for parar onde não devia, clique em "Make a new token". O token antigo deixa de funcionar no mesmo instante, pelo que deve atualizar a regra da Cloudflare logo a seguir com o novo.

Bot Fight Mode no plano Free da Cloudflare

Esta parte aplica-se se a linha Service em Events indicava Bot fight mode.

Uma verificação de uptime da CoreDash com a ação Managed Challenge e o Service Bot fight mode.

O Bot Fight Mode lança desafios a bots simples que correm em servidores cloud e, para a Cloudflare, ambos os bots da CoreDash encaixam nesse perfil. A documentação da Cloudflare refere que as regras Skip e Allow não têm efeito sobre ele. Por isso, ou o desativa, ou o mantém ativo e deixa passar os endereços IP da CoreDash.

Desativar o Bot Fight Mode

Aceda a Security › Settings e filtre por Bot traffic. Localize a linha "Bot fight mode" e desligue o interruptor. A Cloudflare deixa então de colocar desafios a esses bots simples em todo o site. Se preferir manter esse tipo de proteção, o plano Pro inclui o Super Bot Fight Mode, que já respeita a regra Skip. Com o interruptor desligado, crie também a regra Skip indicada acima, para evitar que o Browser Integrity Check ou uma regra gerida bloqueiem a CoreDash a seguir.

O interruptor do Bot fight mode fica na coluna Status. Nesta captura de ecrã já está desligado.

Manter o Bot Fight Mode ativo e autorizar os endereços IP da CoreDash

Antes de começar: estes endereços não são fixos. As suas IP access rules mantêm-se exatamente como as introduzir, ao passo que a lista atual está sempre em app.coredash.app/bot/ips.json. Se a CoreDash voltar a ser bloqueada no futuro, compare primeiro as suas regras com essa lista.

Uma IP access rule deixa passar um endereço IP pelas regras da firewall, e o Bot Fight Mode não mexe no pedido se este corresponder primeiro a essa regra. Aceda a Security › Security rules e clique em Create rule sob IP access rules. Se a Cloudflare sugerir criá-la como custom rule, escolha "No, go to IP access rules". Introduza 51.195.222.219, escolha Allow e "This website", e clique em Create. Crie uma regra por endereço: 51.195.222.219 e 51.195.222.220 para a verificação de uptime, e 135.125.202.210 para a auditoria cRUM.

Uma IP access rule por endereço da CoreDash, definida como Allow em this website.

Após aplicar qualquer uma das soluções, confirme que a CoreDash passa, tal como no passo 5 da regra Skip.

Permita a CoreDash no AWS WAF, acima do Bot Control

No AWS WAF, o que bloqueia a CoreDash costuma estar no Bot Control, o grupo de regras geridas que a AWS disponibiliza contra bots. O problema resolve-se com uma regra Allow para o user agent da CoreDash, colocada acima do Bot Control; essa regra única deixa passar a auditoria e a verificação de uptime. As capturas de ecrã da AWS aqui apresentadas pertencem a um ambiente de demonstração para acme-aws.com, criado para esta página.

1. Na consola do AWS WAF, abra a web ACL do seu site (o conjunto de regras que o protege) e aceda ao separador Sampled requests. Clique no URI de um pedido para ver os respetivos headers: os da CoreDash têm um user agent que começa por CoreDash/. A coluna "Rule inside rule group" indica a regra que os bloqueou.

A regra SignalNonBrowserUserAgent do Bot Control bloqueia as verificações de uptime da CoreDash em acme-aws.com.

2. Na web ACL, clique em Add rules › "Add my own rules and rule groups" para abrir o Rule builder (na nova consola da AWS chama-se Custom rule). Preencha o formulário como na captura de ecrã: uma regra normal com o nome CoreDash, que analisa o header user-agent e autoriza todos os pedidos em que este comece por CoreDash/. De seguida, deslize até abaixo do formulário e clique em "Add rule".

A regra da CoreDash: Single header user-agent, Starts with string CoreDash/, ação Allow.

3. A AWS abre então "Set rule priority". Selecione CoreDash, clique em "Move up" até ficar no topo e clique em Save. A AWS executa as regras de cima para baixo. Como um pedido que corresponda a uma regra Allow não avança mais, o Bot Control nunca chega a ver qualquer pedido da CoreDash.

A CoreDash no topo, acima do grupo de regras do Bot Control.

4. Confirme que a CoreDash passa. Em Sampled requests, os pedidos mais recentes da CoreDash mostram agora a regra CoreDash com a ação Allow.

As verificações mais recentes da CoreDash em acme-aws.com correspondem à regra CoreDash e passam.

Na CoreDash, verifique o bot que utiliza, tal como no passo 5 da regra Skip da Cloudflare: uma nova auditoria mostra a sua própria página no Page load filmstrip, e o monitor passa a Up após a próxima verificação de uptime.

Tal como na Cloudflare, o bot token do seu projeto torna esta regra mais segura. A explicação, e que sites recebem o token, estão na secção sobre o token da Cloudflare acima. Para mudar a regra da AWS para o token:

1. Na CoreDash, abra Project settings, aceda ao separador "CoreDash bot token" e clique em "Copy token".
2. No AWS WAF, volte a abrir a regra CoreDash na sua web ACL. Trata-se do formulário visível na captura de ecrã do Rule builder acima.
3. Altere o nome do campo do header de user-agent para x-coredash-bot. A AWS lê os nomes dos headers sem distinguir maiúsculas de minúsculas, pelo que este é o header X-CoreDash-Bot.
4. Defina o match type como "Exactly matches string", cole o seu token como a string a corresponder e guarde a regra.

A verificação da origem dá timeout atrás da CDN

Esta parte diz respeito apenas à verificação de uptime, e só no caso de ter preenchido o campo Origin IP em Advanced ao configurar o monitor. Nesse cenário, a CoreDash também verifica o seu servidor diretamente, contornando a CDN. Alguns servidores só aceitam pedidos dos próprios endereços da CDN. O monitor passa então a Down com a mensagem "The origin check fails: Connect timeout", apesar de os visitantes continuarem a receber páginas através da CDN.

A CDN continua a servir páginas em cache, e a verificação no próprio servidor dá timeout.

Uma regra no user agent ou no token não resolve a situação: o servidor rejeita a verificação com base na proveniência, antes sequer de ler qualquer header. Por isso, tem de reconhecer a CoreDash pelos respetivos endereços IP. Autorize os dois endereços de uptime, 51.195.222.219 e 51.195.222.220, na firewall do servidor, ou peça ao seu alojamento que o faça. Se a verificação da origem voltar a dar timeout mais tarde, consulte primeiro a lista atual: os endereços podem ter mudado.

A CoreDash continua bloqueada

Se o monitor continuar a indicar Blocked ou se a auditoria continuar a falhar, abra novamente o log e clique no pedido mais recente da CoreDash: Events na Cloudflare, Sampled requests na AWS. O elemento aí identificado é o que está a bloquear a CoreDash agora. Os motivos mais comuns:

• Uma funcionalidade diferente da anterior, como o Browser integrity check após ter desativado o Bot Fight Mode. Crie também a regra Skip.
• A regra não está ativa ou, na AWS, não está no topo. Na Cloudflare, a regra CoreDash deve indicar Active sob Custom rules. A AWS exige que esteja no topo de "Set rule priority".
• A regra está configurada de forma diferente do indicado nos passos. A Cloudflare precisa de contains e CoreDash/ com a barra; a AWS precisa do header user-agent e de "Starts with string".
• Uma das suas próprias regras da Cloudflare, como uma regra de bloqueio por país. A regra Skip mantém as suas custom rules ativas, por isso altere essa regra para deixar a CoreDash de fora. A secção Events mostra o país de origem do pedido.
• Under Attack Mode. Apresenta um desafio a cada visitante, incluindo a CoreDash, até ser desativado.
• Um pedido que passou, ou nenhum pedido da CoreDash registado. Nesse caso, há outra firewall à frente ou atrás da Cloudflare ou da AWS, como a firewall do seu alojamento ou uma regra no servidor. Autorize também aí o user agent CoreDash/.

Continua sem conseguir resolver? Contacte a CoreDash indicando o URL do monitor ou da página auditada e a hora a que ocorreu o bloqueio.

O que ambos os bots enviam, e porquê, está na página do bot da CoreDash. Mais sobre monitores: monitorização de uptime e, para scripts, a Uptime API.