Slipp CoreDash-botene gjennom CDN-en eller brannmuren din

Noen ganger blokkerer en innstilling i brannmuren eller CDN-en CoreDash-botene. Denne siden viser deg hvordan du fikser det.

Trusted by market leaders · Client results

whowhatwearharvardcomparekpnnestleperionmarktplaatsvpnsnvworkivaebayerasmusmcdpg mediafotocasanina careloopearplugsmonarchsaturnaleteiamy work featured on web.devhappyhorizonadevinta

Slipp begge CoreDash-botene gjennom CDN-en eller brannmuren din

Kort oppsummert

  • Begge CoreDash-botene identifiserer seg med en user agent som starter med CoreDash/. Én regel på den slipper gjennom både cRUM-auditen og oppetidssjekken.
  • En regel på prosjektets bot-token er en tryggere variant av denne regelen.
  • Bot Fight Mode på Cloudflare Free-planen ignorerer reglene dine, så den krever en egen fiks.

CoreDash har to boter som besøker nettstedet ditt: cRUM-auditen og oppetidssjekken. For å få fullt utbytte av CoreDash må CDN-en eller brannmuren din slippe inn begge to. Noen ganger blokkeres de av en innstilling der. Denne siden viser hvordan du fikser det i Cloudflare og AWS WAF med én regel som dekker begge botene.

Hva de to botene gjør for deg:

  • cRUM-auditen. Når du velger en side under cRUM (beta) i CoreDash-menyen, åpner CoreDash siden i Chrome på audit-serveren sin, akkurat som en vanlig besøkende, og viser hva som gjør den treg. User agenten dens er CoreDash/1.0 (audit; +https://www.coredash.app/bot).
  • Oppetidssjekken. Hvert 30. minutt gjør CoreDash en request til hvert nettsted du overvåker fra serverne sine, og varsler deg hvis et av dem går ned. Den sender CoreDash/1.0 (uptime; +https://www.coredash.app/bot).

En user agent er navnet en nettleser eller bot sender med hver request for å fortelle hvem den er. Begge fra CoreDash starter med CoreDash/, og det er dette regelen din skal se etter.

Slik ser en blokkert audit eller oppetidssjekk ut

Brannmuren eller CDN-en din ser en besøkende fra et datasenter, der user agenten ikke tilhører en nettleser. Den antar at den besøkende er en bot den ikke stoler på, og svarer med en feilkode eller en challenge-side. De to botene viser dette på hver sin måte.

En blokkert cRUM-audit stopper med meldingen «Audit failed» og en feil under. Eller så kjører den likevel, mot blokkeringssiden: Page load filmstrip viser da en challenge- eller feilside i stedet for siden din, og alle tallene i auditen gjelder denne siden.

Oppetidsovervåkingen viser statusen Blocked, og varselet «A firewall blocks the checker» oppgir hvilken statuskode sjekkene fikk og fra hvilket tidspunkt. CoreDash utelater blokkerte sjekker fra nedetiden din, så blokkeringen reduserer ikke oppetiden din. Men så lenge alle sjekkene blokkeres, når ingen av dem fram til nettstedet ditt, og overvåkingen kan ikke varsle deg hvis nettstedet går ned.

CoreDash-oppetidsovervåking for example-shop.com merket Blocked: alle sjekker siden 17. okt. fikk en 403 fra Cloudflare, med lenker til denne siden og til bot-tokenet

Overvåkingssiden for example-shop.com når Cloudflare svarer på hver oppetidssjekk med 403.

Hvordan brannmuren gjenkjenner CoreDash

Du lager ett unntak for CoreDash i brannmuren eller CDN-en din, og de fleste baserer det på user agent: én regel på CoreDash/ slipper gjennom både auditen og oppetidssjekken. Prosjektets bot-token gjør regelen enda sikrere, fordi bare botene fra ditt eget prosjekt sender det. IP-adressene til CoreDash bruker du hvis ingenting annet slipper gjennom. De endres når CoreDash legger til eller flytter en server, så en slik regel må du holde oppdatert selv.

Loggen i brannmuren forteller deg hvilken innstilling som krever unntaket. Cloudflare-loggen omtales i neste avsnitt. For AWS WAF går du til avsnittet «Tillat CoreDash i AWS WAF, over Bot Control» lenger ned.

Finn ut hva som stoppet CoreDash i Cloudflare

Åpne domenet ditt i Cloudflare og gå til Security › Analytics, under fanen Events. Under Sampled logs finner du en request med en CoreDash-user-agent. På et travelt nettsted klikker du på Filter, velger User agent som felt og limer inn hele user agenten som verdi: CoreDash/1.0 (uptime; +https://www.coredash.app/bot) for oppetidssjekken eller CoreDash/1.0 (audit; +https://www.coredash.app/bot) for auditen.

Klikk på requesten for å åpne den. Service-linjen viser hvilken Cloudflare-funksjon som stoppet den.

Cloudflare Security Events for www.example-shop.com: en request med CoreDash-oppetids-user-agent, action Block, Service Browser integrity check

Browser Integrity Check blokkerte denne oppetidssjekken på example-shop.com.

Service-linjen avgjør fiksen:

  • Bot fight mode: dette er bot-beskyttelsen på Cloudflare Free-planen, og reglene dine kan ikke gjøre unntak for den. Hopp rett til avsnittet om Bot Fight Mode lenger ned.
  • Alt annet, som Browser integrity check i skjermbildet, en managed rule eller Super Bot Fight Mode: lag Skip-regelen nedenfor.

Slipp CoreDash gjennom Cloudflare med en Skip-regel

En Skip-regel ber Cloudflare la alle requester med en CoreDash-user-agent passere uforstyrret for funksjonene du velger. Den dekker auditen og oppetidssjekken samtidig, og du kan opprette den på alle Cloudflare-planer.

  1. Gå til Security › Security rules. Under Custom rules klikker du på Create rule.
Cloudflare Security rules-siden for example-shop.com, med en tom Custom rules-seksjon og Create rule-knappen

Security rules for example-shop.com, før den første egendefinerte regelen.

  1. Gi regelen navnet CoreDash. Under «When incoming requests match» klikker du på «Edit expression», og limer inn denne linjen i tekstfeltet som åpnes.
    http.user_agent contains "CoreDash/"
Cloudflare New custom rule med navn CoreDash og uttrykket http.user_agent contains "CoreDash/"

Regelnavn og uttrykk etter klikk på «Edit expression». Skråstreken etter CoreDash skal være med.

  1. Under «Then take action» velger du Skip, og markerer hva Cloudflare skal hoppe over for CoreDash. Under «WAF components to skip» huker du av for «All managed rules» og «All Super Bot Fight Mode Rules». Klikk på «More components to skip» for å åpne den, og huk av for «Browser Integrity Check» i tillegg. La «Log matching requests» stå på, så ser du regelen i arbeid under Events senere.
Cloudflare custom rule satt til Skip, med All managed rules, All Super Bot Fight Mode Rules og Browser Integrity Check avkrysset

Handlingen Skip, med de tre boksene avkrysset.

  1. Klikk på Deploy. Hvis domenet ditt allerede har andre custom rules, spør Cloudflare hvor denne skal plasseres: legg den øverst.
Bunnen av skjemaet for Cloudflare custom rule: status Active, regelvalidering bestått, Deploy-knapp

Uten andre custom rules er det ingenting å plassere, så Deploy er siste klikk.

  1. Sjekk at CoreDash slipper gjennom. Når neste audit eller oppetidssjekk kommer, lister Events i Cloudflare den opp med handlingen Skip. Sjekk boten du bruker, eller begge, i CoreDash.

For cRUM-auditen velger du siden under cRUM (beta) på nytt, eller laster nettleserfanen den er åpen i på nytt, så starter en ny audit. Når den slipper gjennom, viser Page load filmstrip din egen side som lastes i Chrome, bilde for bilde.

CoreDash cRUM-audit, kortet Page load filmstrip: en side som lastes bilde for bilde over fem sekunder, med markører for TTFB, DCL, Load, FCP, LCP og CLS

En fullført audit, med TTFB, FCP, LCP og CLS markert på bildene.

Oppetidssjekken krever ingen klikk: CoreDash sjekker hver hele og halve time, så innen 30 minutter får overvåkingen statusen Up og de nye stolpene blir grønne.

CoreDash-oppetidsovervåking for example-shop.com tilbake til Up: oransje stolper mens Cloudflare blokkerte sjekkene med 403, grønne etter at regelen kom på plass

example-shop.com har status Up igjen: 38 sjekker fikk 403, og hver sjekk etter at regelen kom på plass fikk 200.

En tryggere Cloudflare-regel med CoreDash-bot-tokenet ditt

Hvem som helst kan sende en user agent som starter med CoreDash/, så ondsinnede boter som utgir seg for å være CoreDash slipper også gjennom Skip-regelen. Prosjektets bot-token er hemmelig: hver audit og oppetidssjekk sender det med i en header som heter X-CoreDash-Bot. En regel basert på dette tokenet slipper bare gjennom botene fra ditt eget prosjekt.

For å hente det åpner du Project settings i CoreDash og går til fanen «CoreDash bot token». Bare prosjekteieren har tilgang her. Hvis overvåkingen viser Blocked, fører lenken «View your CoreDash bot token» i varselet deg også dit. Klikk på «Copy Cloudflare rule»: da får du hele uttrykket ferdig utfylt med ditt token.

Project settings, CoreDash bot token for Example Shop: tokenet er skjult, med Show, Copy token og Copy Cloudflare rule

«Copy Cloudflare rule» legger uttrykket med tokenet ditt i utklippstavlen.

Hvis du allerede har laget Skip-regelen, går du til Security › Security rules og åpner CoreDash-regelen. Erstatt user agent-linjen i uttrykket med det du kopierte, og lagre regelen. Handlingen og de avkryssede boksene forblir uendret. Har du ikke laget regelen ennå, følger du trinnene for Skip-regelen ovenfor og limer inn token-linjen i trinn 2.

Tokenet sendes bare til prosjektets eget nettsted og tilhørende subdomener. En overvåking eller audit av en side på et annet domene sender ikke noe token, så det domenet må beholde regelen for user agent. Hvis tokenet noen gang havner på avveie, klikker du på «Make a new token». Det gamle tokenet slutter å virke umiddelbart, så legg det nye inn i Cloudflare-regelen din med en gang.

Bot Fight Mode på Cloudflare Free-planen

Dette avsnittet gjelder hvis Service-linjen under Events viste Bot fight mode.

Cloudflare Security Events for www.example-shop.com: en request med CoreDash-oppetids-user-agent, action Managed Challenge, Service Bot fight mode

En CoreDash-oppetidssjekk med handlingen Managed Challenge og Service Bot fight mode.

Bot Fight Mode utfordrer enkle boter som kjører på skyservere, og for Cloudflare er begge CoreDash-botene nettopp det. Dokumentasjonen til Cloudflare slår fast at Skip- og Allow-regler ikke biter på dette. Du må derfor enten slå det av, eller la det stå på og slippe gjennom IP-adressene til CoreDash.

Slå av Bot Fight Mode

Gå til Security › Settings og filtrer på Bot traffic. Finn raden «Bot fight mode» og slå av bryteren. Cloudflare slutter da å utfordre disse enkle botene på hele nettstedet ditt. Vil du heller beholde denne typen beskyttelse, har Pro-planen Super Bot Fight Mode i stedet, og den lytter til Skip-regelen. Når bryteren er slått av, må du også opprette Skip-regelen ovenfor, slik at ikke Browser Integrity Check eller en managed rule stopper CoreDash etterpå.

Cloudflare Security Settings filtrert på Bot traffic, med Bot fight mode-raden og bryteren

Bryteren for Bot fight mode ligger i Status-kolonnen. Her er den allerede slått av.

Behold Bot Fight Mode på og tillat IP-adressene til CoreDash

Før du starter: disse adressene er ikke faste. Reglene dine under IP access rules forblir nøyaktig slik du skrev dem inn, mens den gjeldende listen alltid finnes på app.coredash.app/bot/ips.json. Hvis CoreDash blir blokkert igjen en gang, sammenligner du reglene dine med denne listen først.

En IP access-regel slipper én IP-adresse forbi brannmurreglene dine, og Bot Fight Mode lar en request passere hvis den matcher en slik regel først. Gå til Security › Security rules og klikk på Create rule under IP access rules. Hvis Cloudflare foreslår å bygge den som en custom rule, velger du «No, go to IP access rules». Skriv inn 51.195.222.219, velg Allow og «This website», og klikk på Create. Lag én regel per adresse: 51.195.222.219 og 51.195.222.220 for oppetidssjekken, 135.125.202.210 for cRUM-auditen.

Cloudflare New IP access rule som tillater 51.195.222.219, en oppetidsadresse for CoreDash, på dette nettstedet

Én IP access-regel per CoreDash-adresse, satt til Allow på dette nettstedet.

Etter at du har gjort en av disse endringene, sjekker du at CoreDash slipper gjennom, på samme måte som i trinn 5 for Skip-regelen.

Tillat CoreDash i AWS WAF, over Bot Control

I AWS WAF er det som regel Bot Control som stopper CoreDash. Dette er den administrerte regelgruppen AWS tilbyr mot boter. Du løser det med en Allow-regel for CoreDash-user-agenten plassert over Bot Control. Denne ene regelen slipper gjennom både auditen og oppetidssjekken. AWS-skjermbildene her er hentet fra et demooppsett for acme-aws.com, laget for denne siden.

  1. I AWS WAF-konsollen åpner du nettstedets web ACL (regelsettet som beskytter det) og går til fanen Sampled requests. Klikk på requestens URI for å se headerne: CoreDash-forespørslene har en user agent som starter med CoreDash/. Kolonnen «Rule inside rule group» viser navnet på regelen som blokkerte dem.
AWS WAF Sampled requests i et demooppsett for acme-aws.com: CoreDash-sjekker blokkert av Bot Control-regelen SignalNonBrowserUserAgent

Bot Control-regelen SignalNonBrowserUserAgent blokkerer CoreDash-oppetidssjekkene på acme-aws.com.

  1. I web ACL-en klikker du på Add rules › «Add my own rules and rule groups» for å åpne Rule builder (i den nye AWS-konsollen kalles dette Custom rule). Fyll ut skjemaet som i skjermbildet: en vanlig regel med navn CoreDash som sjekker user-agent-headeren og tillater alle requester der den starter med CoreDash/. Rull deretter ned under skjemaet og klikk på «Add rule».
AWS WAF Rule builder i et demooppsett: regelen CoreDash, single header user-agent starter med CoreDash/, action Allow

CoreDash-regelen: Single header user-agent, Starts with string CoreDash/, action Allow.

  1. AWS åpner deretter «Set rule priority». Velg CoreDash, klikk på «Move up» til den ligger øverst, og klikk på Save. AWS kjører reglene ovenfra og ned, og en request som matcher en Allow-regel evalueres ikke videre. Dermed ser aldri Bot Control noen CoreDash-request.
AWS WAF Set rule priority i et demooppsett: CoreDash med action Allow øverst, over regelgruppen Bot Control

CoreDash øverst, over regelgruppen Bot Control.

  1. Sjekk at CoreDash slipper gjennom. Under Sampled requests viser de nyeste CoreDash-requestene nå CoreDash-regelen din med handlingen Allow.
AWS WAF Sampled requests i et demooppsett for acme-aws.com: CoreDash-sjekkene matcher nå CoreDash-regelen, action Allow

De nyeste CoreDash-sjekkene på acme-aws.com matcher CoreDash-regelen og slipper gjennom.

I CoreDash sjekker du boten du bruker, på samme måte som i trinn 5 for Skip-regelen i Cloudflare: en ny audit viser din egen side i Page load filmstrip, og overvåkingen får statusen Up etter neste oppetidssjekk.

Akkurat som i Cloudflare gjør prosjektets bot-token denne regelen tryggere. Hvorfor, og hvilke nettsteder som får tokenet, finner du i avsnittet om Cloudflare-tokenet ovenfor. Slik endrer du AWS-regelen til å bruke tokenet:

  1. I CoreDash åpner du Project settings, går til fanen «CoreDash bot token» og klikker på «Copy token».
  2. I AWS WAF åpner du CoreDash-regelen i web ACL-en din igjen. Dette er skjemaet fra Rule builder-skjermbildet ovenfor.
  3. Endre header-feltnavnet fra user-agent til x-coredash-bot. AWS skiller ikke mellom store og små bokstaver i headernavn, så dette tilsvarer X-CoreDash-Bot-headeren.
  4. Sett match type til «Exactly matches string», lim inn tokenet ditt som strengen som skal matches, og lagre regelen.

Origin-sjekken får timeout bak CDN-en din

Dette gjelder bare oppetidssjekken, og kun hvis du fylte ut Origin IP under Advanced da du satte opp overvåkingen. CoreDash sjekker da også serveren din direkte, utenom CDN-en. Enkelte servere godtar bare requester fra CDN-ens egne adresser. Overvåkingen får da statusen Down med meldingen «The origin check fails: Connect timeout», selv om vanlige besøkende fortsatt får sider fra CDN-en.

CoreDash-overvåking for example-shop.com merket Down: CDN-en leverer fortsatt cachede sider, origin-sjekken får en connect timeout

CDN-en leverer fortsatt cachede sider, mens sjekken mot selve serveren får timeout.

Her hjelper det ikke med en regel på user agent eller token: en slik server avviser sjekken basert på hvor den kommer fra, før den leser noen header. Derfor må den kjenne igjen CoreDash på IP-adressene. Tillat de to oppetidsadressene, 51.195.222.219 og 51.195.222.220, i brannmuren på serveren din, eller be hostingleverandøren din om å gjøre det. Hvis origin-sjekken begynner å få timeout igjen senere, sjekker du den oppdaterte listen først: adressene kan ha endret seg.

CoreDash er fortsatt blokkert

Hvis overvåkingen fortsatt viser Blocked eller auditen fortsatt feiler, åpner du loggen igjen og klikker på den nyeste CoreDash-requesten: Events i Cloudflare, Sampled requests i AWS. Funksjonen som oppgis der, er det som stopper CoreDash nå. De vanligste årsakene:

  • En annen funksjon enn før, som Browser integrity check etter at du slo av Bot Fight Mode. Lag Skip-regelen i tillegg.
  • Regelen er ikke aktiv, eller i AWS ligger den ikke øverst. I Cloudflare skal CoreDash-regelen ha statusen Active under Custom rules. AWS krever at den ligger øverst i «Set rule priority».
  • Regelen er satt opp annerledes enn i veiledningen. Cloudflare krever contains og CoreDash/ med skråstrek; AWS krever headeren user-agent og «Starts with string».
  • En av dine egne Cloudflare-regler, for eksempel en regel som blokkerer land. Skip-regelen lar dine egne custom rules fortsette å kjøre, så endre regelen slik at den unntar CoreDash. Events viser hvilket land requesten kom fra.
  • Under Attack Mode. Den utfordrer alle besøkende, inkludert CoreDash, helt til du slår den av.
  • En request som slapp gjennom, eller ingen CoreDash-request i det hele tatt. Da står det en annen brannmur foran eller bak Cloudflare eller AWS, for eksempel hostingleverandørens brannmur eller en regel på serveren din. Tillat CoreDash/-user-agenten der også.

Står du fortsatt fast? Kontakt CoreDash med URL-en til overvåkingen eller siden som ble auditet, samt tidspunktet den ble blokkert.

Hva begge botene sender og hvorfor, finner du på CoreDash-botsiden. Mer om overvåking: oppetidsovervåking, og for skript, Uptime API.

Slipp CoreDash-botene gjennom Cloudflare og AWS WAF Core Web Vitals Slipp CoreDash-botene gjennom Cloudflare og AWS WAF