Fai passare i bot di CoreDash attraverso la CDN o il firewall

Fai passare entrambi i bot di CoreDash attraverso la CDN o il firewall

CoreDash usa due bot per visitare il sito: l'audit cRUM e l'uptime check. Per ottenere il massimo da CoreDash, la CDN o il firewall deve lasciarli passare entrambi. A volte una configurazione li blocca. Questa pagina mostra come risolvere il problema su Cloudflare e AWS WAF, con un'unica regola che copre entrambi i bot.

Cosa fanno i due bot:

• L'audit cRUM. Quando selezioni una pagina sotto cRUM (beta) nel menu di CoreDash, CoreDash apre la pagina in Chrome sul proprio server di audit, esattamente come farebbe un visitatore, e mostra cosa la rallenta. Il suo user agent è CoreDash/1.0 (audit; +https://www.coredash.app/bot).
• L'uptime check. Ogni 30 minuti CoreDash richiede ciascun sito monitorato dai propri server e segnala quando uno di essi va giù. Invia CoreDash/1.0 (uptime; +https://www.coredash.app/bot).

Lo user agent è la stringa che un browser o un bot invia con ogni richiesta per identificarsi. Entrambi quelli di CoreDash iniziano con CoreDash/, ed è questo che cercherà la regola.

Come si presenta un audit o un uptime check bloccato

Il firewall o la CDN rileva una visita da un data center con uno user agent diverso da quello di un browser. La scambia per un bot non attendibile e risponde con un codice di errore o una pagina di challenge. Ogni bot mostra questo blocco a modo suo.

Un audit cRUM bloccato si interrompe con il messaggio «Audit failed» e un errore sottostante. Oppure viene eseguito comunque, ma sulla pagina di blocco: in questo caso il Page load filmstrip mostra una challenge o una pagina di errore al posto della pagina del sito, e ogni metrica dell'audit appartiene a quella schermata.

L'uptime monitor mostra lo stato Blocked, e l'avviso «A firewall blocks the checker» indica il codice di stato ricevuto dai check e da quanto tempo. CoreDash esclude i check bloccati dal calcolo del downtime, quindi il blocco non abbassa l'uptime. Tuttavia, finché ogni check viene bloccato, nessuno raggiunge il sito e il monitor non può segnalare quando il sito va giù.

La pagina del monitor per example-shop.com quando Cloudflare risponde a ogni uptime check con un 403.

Come il firewall riconosce CoreDash

Per CoreDash basta creare un'eccezione nel firewall o nella CDN, e nella maggior parte dei casi conviene farlo sullo user agent: un'unica regola su CoreDash/ fa passare sia l'audit sia l'uptime check. Il bot token del progetto permette di creare una regola più restrittiva, perché viene inviato solo dai bot del progetto stesso. Gli indirizzi IP di CoreDash servono quando non passa nient'altro. Cambiano quando CoreDash aggiunge o sposta un server, quindi una regola basata su IP va aggiornata manualmente.

Quale impostazione richieda l'eccezione lo dicono i log del firewall. I log di Cloudflare sono trattati nella sezione successiva. Per AWS WAF, vai alla sezione «Autorizza CoreDash in AWS WAF sopra Bot Control» più in basso.

Individua cosa ha bloccato CoreDash su Cloudflare

Apri il dominio in Cloudflare e vai su Security › Analytics, scheda Events. Sotto Sampled logs, cerca una richiesta con uno user agent di CoreDash. Su un sito con molto traffico, clicca su Filter, scegli User agent come campo e incolla lo user agent completo come valore: CoreDash/1.0 (uptime; +https://www.coredash.app/bot) per l'uptime check o CoreDash/1.0 (audit; +https://www.coredash.app/bot) per l'audit.

Clicca sulla richiesta per aprirla. La riga Service indica la funzionalità di Cloudflare che l'ha bloccata.

Browser Integrity Check ha bloccato questo uptime check su example-shop.com.

Quella riga Service indica come intervenire:

• Bot fight mode: è la protezione bot del piano Cloudflare Free, e le regole personalizzate non possono creare eccezioni per questa funzione. Salta direttamente alla sezione su Bot Fight Mode più in basso.
• Qualsiasi altra voce, come Browser integrity check nello screenshot, una managed rule o Super Bot Fight Mode: crea la regola Skip descritta di seguito.

Fai passare CoreDash su Cloudflare con una regola Skip

Una regola Skip dice a Cloudflare di non applicare le funzionalità selezionate alle richieste con user agent CoreDash. Copre contemporaneamente l'audit e l'uptime check, e si può creare su qualsiasi piano Cloudflare.

1. Vai su Security › Security rules. Sotto Custom rules, clicca su Create rule.

Security rules per example-shop.com, prima della prima custom rule.

2. Assegna alla regola il nome CoreDash. Sotto «When incoming requests match», clicca su «Edit expression» e incolla questa riga nel campo di testo che compare.

   http.user_agent contains "CoreDash/"

Nome ed espressione della regola, dopo aver cliccato su «Edit expression». La barra dopo CoreDash è necessaria.

3. Sotto «Then take action», scegli Skip e seleziona cosa Cloudflare deve saltare per CoreDash. In «WAF components to skip», spunta «All managed rules» e «All Super Bot Fight Mode Rules». Clicca su «More components to skip» per aprirlo e spunta anche «Browser Integrity Check». Lascia attivo «Log matching requests», così che Events mostri la regola in azione.

L'azione Skip, con le tre caselle selezionate.

4. Clicca su Deploy. Se il dominio ha già altre custom rule, Cloudflare chiede dove posizionare questa: mettila per prima.

Senza altre custom rule non c'è nulla da ordinare, quindi Deploy è l'ultimo clic.

5. Verifica che CoreDash passi. Al successivo audit o uptime check, Events in Cloudflare mostrerà la richiesta con l'azione Skip. In CoreDash, controlla il bot che usi, o entrambi.

Per l'audit cRUM, seleziona di nuovo la pagina sotto cRUM (beta) oppure ricarica la scheda del browser in cui è aperta per avviare un nuovo audit. Quando la richiesta passa, il Page load filmstrip mostra la pagina mentre si carica in Chrome, fotogramma per fotogramma.

Un audit completato, con TTFB, FCP, LCP e CLS indicati sui fotogrammi.

L'uptime check non richiede alcun clic: CoreDash esegue il controllo allo scoccare dell'ora e della mezz'ora, quindi entro 30 minuti lo stato del monitor diventa Up e le nuove barre diventano verdi.

example-shop.com è di nuovo Up: 38 check hanno ricevuto un 403, mentre ogni check successivo alla regola ha restituito un 200.

Una regola Cloudflare più sicura con il bot token di CoreDash

Chiunque può inviare uno user agent che inizia con CoreDash/: anche un bot malevolo che si finge CoreDash passerebbe attraverso la regola Skip. Il bot token del progetto è segreto: ogni audit e uptime check lo invia in un header chiamato X-CoreDash-Bot. Una regola basata su questo token fa passare solo i bot del progetto.

Per recuperarlo, apri Project settings in CoreDash e vai alla scheda «CoreDash bot token». Solo il proprietario del progetto può aprirla. Quando un monitor indica Blocked, anche il link «View your CoreDash bot token» nell'avviso porta alla stessa schermata. Clicca su «Copy Cloudflare rule»: otterrai l'espressione completa con il token già inserito.

«Copy Cloudflare rule» copia negli appunti l'espressione con il token.

Se hai già creato la regola Skip, vai su Security › Security rules e apri la regola CoreDash. Sostituisci la riga dello user agent nell'espressione con quella copiata e salva la regola. L'azione e le caselle selezionate restano invariate. Se non hai ancora creato una regola, segui i passaggi della regola Skip sopra e incolla la riga del token al passaggio 2.

Il token viene inviato solo al sito del progetto e ai relativi sottodomini. Un monitor o un audit di una pagina su un altro dominio non invia alcun token, quindi quel dominio mantiene la regola sullo user agent. Se il token finisce dove non dovrebbe, clicca su «Make a new token». Il vecchio token smette subito di funzionare, quindi inserisci immediatamente quello nuovo nella regola di Cloudflare.

Bot Fight Mode sul piano Cloudflare Free

Questa sezione serve se la riga Service in Events riportava Bot fight mode.

Un uptime check di CoreDash con azione Managed Challenge e Service Bot fight mode.

Bot Fight Mode blocca con challenge i bot semplici in esecuzione su server cloud, e per Cloudflare entrambi i bot di CoreDash rientrano in questa definizione. La documentazione di Cloudflare indica che le regole Skip e Allow non hanno effetto su questa modalità. Le opzioni sono due: disattivarla, oppure lasciarla attiva e consentire il passaggio degli indirizzi IP di CoreDash.

Disattiva Bot Fight Mode

Vai su Security › Settings e filtra per Bot traffic. Trova la riga «Bot fight mode» e disattiva l'interruttore. A quel punto Cloudflare smette di inviare challenge a quei bot semplici sull'intero sito. Se preferisci mantenere questo tipo di protezione, il piano Pro offre Super Bot Fight Mode, che invece rispetta la regola Skip. Con l'interruttore disattivato, crea comunque la regola Skip descritta sopra, così che Browser Integrity Check o una managed rule non blocchino CoreDash subito dopo.

L'interruttore di Bot fight mode si trova nella colonna Status. In questo screenshot è già disattivato.

Mantieni attiva Bot Fight Mode e autorizza gli indirizzi IP di CoreDash

Prima di iniziare: questi indirizzi non sono fissi. Le regole IP access rules restano esattamente come le imposti, mentre l'elenco aggiornato si trova sempre su app.coredash.app/bot/ips.json. Se un giorno CoreDash dovesse risultare di nuovo bloccato, confronta prima le regole con questo elenco.

Una IP access rule lascia passare un singolo indirizzo IP oltre le regole del firewall, e Bot Fight Mode non tocca la richiesta se corrisponde prima a una regola di questo tipo. Vai su Security › Security rules e clicca su Create rule sotto IP access rules. Se Cloudflare suggerisce di crearla come custom rule, scegli «No, go to IP access rules». Inserisci 51.195.222.219, scegli Allow e «This website», poi clicca su Create. Crea una regola per ogni indirizzo: 51.195.222.219 e 51.195.222.220 per l'uptime check, 135.125.202.210 per l'audit cRUM.

Una IP access rule per ogni indirizzo di CoreDash, impostata su Allow su questo sito.

Dopo aver applicato una delle due soluzioni, controlla che CoreDash passi, esattamente come al passaggio 5 della regola Skip.

Autorizza CoreDash in AWS WAF sopra Bot Control

Su AWS WAF, ciò che blocca CoreDash si trova di solito in Bot Control, il gruppo di managed rule offerto da AWS contro i bot. Si risolve con una regola Allow per lo user agent di CoreDash posizionata sopra Bot Control: quest'unica regola lascia passare sia l'audit sia l'uptime check. Gli screenshot di AWS mostrati qui provengono da una configurazione dimostrativa per acme-aws.com, creata appositamente per questa pagina.

1. Nella console di AWS WAF, apri la web ACL del sito (l'insieme di regole che lo protegge) e vai alla scheda Sampled requests. Clicca sull'URI di una richiesta per vederne gli header: quelle di CoreDash hanno uno user agent che inizia con CoreDash/. La colonna «Rule inside rule group» indica la regola che le ha bloccate.

La regola SignalNonBrowserUserAgent di Bot Control blocca gli uptime check di CoreDash su acme-aws.com.

2. Sulla web ACL, clicca su Add rules › «Add my own rules and rule groups» per aprire il Rule builder (nella nuova console AWS si chiama Custom rule). Compilalo come nello screenshot: una regola normale con nome CoreDash che controlla l'header user-agent e consente ogni richiesta in cui inizia con CoreDash/. Scorri quindi sotto il form e clicca su «Add rule».

La regola CoreDash: Single header user-agent, Starts with string CoreDash/, azione Allow.

3. AWS apre quindi «Set rule priority». Seleziona CoreDash, clicca su «Move up» finché non si trova in cima e clicca su Save. AWS valuta le regole dall'alto verso il basso: una richiesta che soddisfa una regola Allow non va oltre, quindi Bot Control non vede mai una richiesta di CoreDash.

CoreDash in cima, sopra il gruppo di regole Bot Control.

4. Verifica che CoreDash passi. In Sampled requests, le richieste più recenti di CoreDash mostrano ora la regola CoreDash con l'azione Allow.

I check più recenti di CoreDash su acme-aws.com corrispondono alla regola CoreDash e passano.

In CoreDash, controlla il bot che usi, come al passaggio 5 della regola Skip di Cloudflare: un nuovo audit mostra la pagina nel Page load filmstrip, e il monitor torna Up dopo il successivo uptime check.

Come su Cloudflare, il bot token del progetto rende questa regola più sicura. Il motivo e quali siti ricevono il token sono spiegati nella sezione dedicata al token su Cloudflare più in alto. Per passare al token nella regola di AWS:

1. In CoreDash, apri Project settings, vai alla scheda «CoreDash bot token» e clicca su «Copy token».
2. In AWS WAF, riapri la regola CoreDash sulla web ACL: è il form dello screenshot del Rule builder qui sopra.
3. Modifica il nome del campo header da user-agent a x-coredash-bot. AWS legge i nomi degli header senza distinzione tra maiuscole e minuscole, quindi equivale all'header X-CoreDash-Bot.
4. Imposta il match type su «Exactly matches string», incolla il token come stringa da confrontare e salva la regola.

L'origin check va in timeout dietro la CDN

Questa parte riguarda solo l'uptime check, e unicamente se hai indicato un Origin IP sotto Advanced durante la configurazione del monitor. In questo caso CoreDash controlla anche il server direttamente, bypassando la CDN. Alcuni server accettano richieste solo dagli indirizzi della CDN stessa. Il monitor passa quindi a Down con l'errore «The origin check fails: Connect timeout», mentre i visitatori continuano a ricevere le pagine dalla CDN.

La CDN serve ancora pagine in cache, e il controllo sul server stesso va in timeout.

Una regola sullo user agent o sul token qui non serve a nulla: il server scarta il check a causa della provenienza, prima ancora di leggere qualsiasi header. Deve quindi riconoscere CoreDash dai suoi indirizzi IP. Autorizza i due indirizzi di uptime, 51.195.222.219 e 51.195.222.220, nel firewall del server o chiedi all'hosting di farlo. Se in seguito l'origin check ricomincia ad andare in timeout, controlla prima l'elenco aggiornato: gli indirizzi potrebbero essere cambiati.

CoreDash è ancora bloccato

Se il monitor dice ancora Blocked o l'audit fallisce ancora, riapri il log e clicca sulla richiesta di CoreDash più recente: Events in Cloudflare, Sampled requests in AWS. La voce indicata è ciò che blocca CoreDash in questo momento. I motivi più comuni:

• Una funzionalità diversa da prima, come Browser integrity check dopo aver disattivato Bot Fight Mode. Crea anche la regola Skip.
• La regola non è attiva o su AWS non si trova in cima. In Cloudflare, la regola CoreDash deve risultare Active sotto Custom rules. AWS richiede che sia in cima a «Set rule priority».
• La regola è impostata diversamente rispetto ai passaggi. Cloudflare richiede contains e CoreDash/ con la barra; AWS richiede l'header user-agent e «Starts with string».
• Una delle tue regole su Cloudflare, come una regola che blocca determinati paesi. La regola Skip lascia attive le tue custom rule, quindi modifica quella regola per escludere CoreDash. Events mostra da quale paese proviene la richiesta.
• Under Attack Mode. Sottopone a challenge ogni visitatore, CoreDash compreso, finché non la disattivi.
• Una richiesta andata a buon fine, o nessuna richiesta di CoreDash. In tal caso c'è un altro firewall a monte o a valle di Cloudflare o AWS, come il firewall dell'hosting o una regola sul server. Autorizza lo user agent CoreDash/ anche lì.

Ancora bloccato? Contatta CoreDash con l'URL del monitor o della pagina sottoposta ad audit e l'orario del blocco.

Cosa inviano entrambi i bot e per quale motivo si trova nella pagina dei bot di CoreDash. Altro sul monitoraggio: monitoraggio dell'uptime, e per gli script le Uptime API.