Lass die CoreDash-Bots durch dein CDN oder deine Firewall

Lass beide CoreDash-Bots durch dein CDN oder deine Firewall

CoreDash nutzt zwei Bots, die deine Website besuchen: das cRUM-Audit und den Uptime-Check. Um CoreDash voll zu nutzen, müssen dein CDN oder deine Firewall beide durchlassen. Manchmal blockiert eine Einstellung die Bots. Diese Seite zeigt dir, wie du das in Cloudflare und AWS WAF behebst – mit einer einzigen Regel für beide Bots.

Was die beiden Bots für dich tun:

• Das cRUM-Audit. Wenn du im CoreDash-Menü unter cRUM (beta) eine Seite auswählst, öffnet CoreDash diese Seite in Chrome auf seinem Audit-Server – genau wie ein Besucher – und zeigt dir, was sie verlangsamt. Sein User-Agent lautet CoreDash/1.0 (audit; +https://www.coredash.app/bot).
• Der Uptime-Check. Alle 30 Minuten ruft CoreDash jede von dir überwachte Website von eigenen Servern ab und meldet, wenn eine ausfällt. Er sendet CoreDash/1.0 (uptime; +https://www.coredash.app/bot).

Ein User-Agent ist der Name, den ein Browser oder Bot bei jedem Request mitsendet, um sich auszuweisen. Bei beiden Bots von CoreDash beginnt er mit CoreDash/, und genau darauf achtet deine Regel.

Wie ein blockiertes Audit oder ein blockierter Uptime-Check aussieht

Deine Firewall oder dein CDN sieht einen Besucher aus einem Rechenzentrum, dessen User-Agent nicht zu einem Browser gehört. Sie stuft diesen Besucher als nicht vertrauenswürdigen Bot ein und antwortet mit einem Fehlercode oder einer Challenge-Seite. Beide Bots zeigen das auf ihre eigene Weise.

Ein blockiertes cRUM-Audit bricht mit der Meldung „Audit failed“ und einem Fehler darunter ab. Oder es läuft trotzdem durch – allerdings auf der Sperrseite: Der Page load filmstrip zeigt dann statt deiner Seite eine Challenge- oder Fehlerseite, und alle Messwerte im Audit stammen von dieser Seite.

Der Uptime-Monitor meldet Blocked. Der Hinweis „A firewall blocks the checker“ nennt den Statuscode der Checks und seit wann er auftritt. CoreDash rechnet blockierte Checks nicht zur Ausfallzeit; die Blockade senkt deine Uptime also nicht. Solange aber jeder Check blockiert wird, erreicht keiner deine Website. Der Monitor kann dir dann nicht melden, wenn deine Seite ausfällt.

Die Monitor-Seite für example-shop.com, wenn Cloudflare jeden Uptime-Check mit einem 403 beantwortet.

Wie deine Firewall CoreDash erkennt

Du richtest eine Ausnahme für CoreDash in deiner Firewall oder deinem CDN ein. Meistens genügt der User-Agent: Eine Regel für CoreDash/ lässt Audit und Uptime-Check durch. Das Bot-Token deines Projekts macht diese Regel noch sicherer, weil nur die Bots deines eigenen Projekts es mitsenden. Die IP-Adressen von CoreDash nutzt du nur, wenn sonst nichts durchkommt. Sie ändern sich, wenn CoreDash Server hinzufügt oder umzieht. Eine IP-Regel musst du also selbst aktuell halten.

Welche Einstellung die Ausnahme braucht, verrät dir das Log deiner Firewall. Das Cloudflare-Log behandeln wir im nächsten Abschnitt. Für AWS WAF springe direkt zum Abschnitt „CoreDash in AWS WAF vor Bot Control erlauben“ weiter unten.

Herausfinden, was CoreDash in Cloudflare blockiert hat

Öffne deine Domain in Cloudflare und gehe zu Security › Analytics, Tab Events. Suche unter Sampled logs nach einem Request mit einem CoreDash-User-Agent. Bei viel Traffic klickst du auf Filter, wählst User agent als Feld und fügst den vollständigen User-Agent als Wert ein: CoreDash/1.0 (uptime; +https://www.coredash.app/bot) für den Uptime-Check oder CoreDash/1.0 (audit; +https://www.coredash.app/bot) für das Audit.

Klicke auf den Request, um ihn zu öffnen. Die Zeile Service nennt die Cloudflare-Funktion, die ihn gestoppt hat.

Browser Integrity Check hat diesen Uptime-Check auf example-shop.com blockiert.

Diese Service-Zeile bestimmt deinen Fix:

• Bot fight mode: Das ist der Bot-Schutz im Cloudflare-Free-Tarif. Deine Regeln können dafür keine Ausnahme machen. Springe direkt zum Abschnitt zum Bot Fight Mode weiter unten.
• Alles andere, wie Browser integrity check im Screenshot, eine Managed Rule oder Super Bot Fight Mode: Erstelle die unten beschriebene Skip-Regel.

CoreDash mit einer Skip-Regel durch Cloudflare lassen

Eine Skip-Regel weist Cloudflare an, Requests mit einem CoreDash-User-Agent bei den ausgewählten Funktionen in Ruhe zu lassen. Sie deckt Audit und Uptime-Check gleichzeitig ab und lässt sich in jedem Cloudflare-Tarif anlegen.

1. Gehe zu Security › Security rules. Klicke unter Custom rules auf Create rule.

Security rules für example-shop.com vor der ersten Custom Rule.

2. Gib der Regel den Namen CoreDash. Klicke unter „When incoming requests match“ auf „Edit expression“ und füge diese Zeile in das erscheinende Textfeld ein.

   http.user_agent contains "CoreDash/"

Regelname und Ausdruck nach dem Klick auf „Edit expression“. Der Schrägstrich nach CoreDash gehört dazu.

3. Wähle unter „Then take action“ die Aktion Skip und lege fest, was Cloudflare für CoreDash überspringt. Setze unter „WAF components to skip“ ein Häkchen bei „All managed rules“ und „All Super Bot Fight Mode Rules“. Klicke auf „More components to skip“, um den Bereich zu öffnen, und hake auch „Browser Integrity Check“ an. Lass „Log matching requests“ aktiviert, damit Events die Regel später im Einsatz anzeigt.

Die Aktion Skip mit allen drei gesetzten Häkchen.

4. Klicke auf Deploy. Falls deine Domain bereits andere Custom Rules hat, fragt Cloudflare nach der Position: Setze diese Regel an die erste Stelle.

Ohne andere Custom Rules gibt es nichts zu sortieren – Deploy ist der letzte Klick.

5. Prüfe, ob CoreDash durchkommt. Sobald das nächste Audit oder der nächste Uptime-Check ankommt, führt Events in Cloudflare den Request mit der Aktion Skip auf. Prüfe in CoreDash den Bot, den du nutzt – oder beide.

Für das cRUM-Audit: Wähle die Seite unter cRUM (beta) erneut aus oder lade den Browser-Tab neu, in dem sie geöffnet ist, und ein neues Audit startet. Sobald es durchkommt, zeigt der Page load filmstrip, wie deine eigene Seite in Chrome lädt – Frame für Frame.

Ein fertiges Audit mit Markierungen für TTFB, FCP, LCP und CLS auf den Frames.

Der Uptime-Check braucht keinen Klick: CoreDash prüft zur vollen und zur halben Stunde. Innerhalb von 30 Minuten wechselt der Monitor auf Up und die neuen Balken werden grün.

example-shop.com ist wieder Up: 38 Checks erhielten einen 403, jeder Check seit der Regel einen 200.

Sicherere Cloudflare-Regel mit deinem CoreDash-Bot-Token

Jeder kann einen User-Agent senden, der mit CoreDash/ beginnt. Ein bösartiger Bot, der sich als CoreDash ausgibt, käme also ebenfalls durch die Skip-Regel. Das Bot-Token deines Projekts ist geheim: Jedes Audit und jeder Uptime-Check sendet es im Header X-CoreDash-Bot mit. Eine Regel auf dieses Token lässt nur die Bots deines eigenen Projekts durch.

Öffne dafür die Project settings in CoreDash und wechsle zum Tab „CoreDash bot token“. Nur der Projektinhaber kann diesen Bereich öffnen. Solange ein Monitor auf Blocked steht, führt dich auch der Link „View your CoreDash bot token“ in dessen Hinweis dorthin. Klicke auf „Copy Cloudflare rule“: Du erhältst den vollständigen Ausdruck mit deinem Token.

„Copy Cloudflare rule“ kopiert den Ausdruck mit deinem Token in die Zwischenablage.

Wenn du die Skip-Regel bereits angelegt hast: Gehe zu Security › Security rules und öffne die CoreDash-Regel. Ersetze die User-Agent-Zeile im Ausdruck durch das, was du kopiert hast, und speichere die Regel. Die Aktion und die gesetzten Häkchen bleiben unverändert. Hast du noch keine Regel, folge den obigen Schritten für die Skip-Regel und füge die Token-Zeile in Schritt 2 ein.

Das Token geht nur an die eigene Website deines Projekts und deren Subdomains. Ein Monitor oder Audit für eine Seite auf einer anderen Domain sendet kein Token – diese Domain behält also die User-Agent-Regel. Und falls das Token jemals dort landet, wo es nicht hin soll: Klicke auf „Make a new token“. Das alte Token wird sofort ungültig. Trage das neue direkt danach in deine Cloudflare-Regel ein.

Bot Fight Mode im Cloudflare-Free-Tarif

Dieser Abschnitt ist für dich, wenn die Service-Zeile in Events „Bot fight mode“ angezeigt hat.

Ein CoreDash-Uptime-Check mit der Aktion Managed Challenge und dem Service Bot fight mode.

Der Bot Fight Mode fordert einfache Bots heraus, die auf Cloud-Servern laufen – und für Cloudflare sind beide CoreDash-Bots genau solche Bots. Laut Cloudflares Dokumentation haben Skip- und Allow-Regeln keine Auswirkung darauf. Du musst ihn also entweder ausschalten oder aktiv lassen und die IP-Adressen von CoreDash durchlassen.

Bot Fight Mode ausschalten

Gehe zu Security › Settings und filtere nach Bot traffic. Suche die Zeile „Bot fight mode“ und schalte den Schalter aus. Cloudflare stellt diese einfachen Bots dann auf deiner gesamten Website nicht mehr vor eine Challenge. Wenn du diesen Schutz behalten willst: Der Pro-Tarif bietet stattdessen Super Bot Fight Mode, und dieser beachtet die Skip-Regel. Erstelle bei ausgeschaltetem Schalter auch die obige Skip-Regel, damit nicht als Nächstes der Browser Integrity Check oder eine Managed Rule CoreDash stoppt.

Der Schalter für den Bot Fight Mode sitzt in der Spalte Status. In diesem Screenshot ist er bereits aus.

Bot Fight Mode anlassen und CoreDash-IP-Adressen erlauben

Bevor du beginnst: Diese Adressen sind nicht fix. Deine IP-Access-Regeln bleiben exakt so, wie du sie eingetippt hast, während die aktuelle Liste immer unter app.coredash.app/bot/ips.json liegt. Falls CoreDash eines Tages wieder blockiert wird, vergleiche deine Regeln zuerst mit dieser Liste.

Eine IP-Access-Regel lässt eine IP-Adresse an deinen Firewall-Regeln vorbei, und der Bot Fight Mode lässt einen Request in Ruhe, wenn vorher eine solche Regel gegriffen hat. Gehe zu Security › Security rules und klicke unter IP access rules auf Create rule. Schlägt Cloudflare vor, stattdessen eine Custom Rule zu erstellen, wähle „No, go to IP access rules“. Gib 51.195.222.219 ein, wähle Allow sowie „This website“ und klicke auf Create. Erstelle eine Regel pro Adresse: 51.195.222.219 und 51.195.222.220 für den Uptime-Check, 135.125.202.210 für das cRUM-Audit.

Eine IP-Access-Regel pro CoreDash-Adresse, eingestellt auf Allow auf dieser Website.

Prüfe nach beiden Lösungen, ob CoreDash durchkommt – genau wie in Schritt 5 der Skip-Regel.

CoreDash in AWS WAF vor Bot Control erlauben

In AWS WAF liegt die Ursache meist in Bot Control, der Managed-Rule-Gruppe von AWS gegen Bots. Du behebst das mit einer Allow-Regel für den CoreDash-User-Agent, die vor Bot Control liegt. Diese eine Regel lässt Audit und Uptime-Check durch. Die AWS-Screenshots hier stammen aus einem Demo-Setup für acme-aws.com, das für diese Seite erstellt wurde.

1. Öffne in der AWS-WAF-Konsole die Web-ACL deiner Website (den Regelsatz, der sie schützt) und gehe zum Tab Sampled requests. Klicke auf die URI eines Requests, um seine Header zu sehen: Die CoreDash-Requests haben einen User-Agent, der mit CoreDash/ beginnt. Die Spalte „Rule inside rule group“ nennt die Regel, die sie blockiert hat.

Die Bot-Control-Regel SignalNonBrowserUserAgent blockiert die CoreDash-Uptime-Checks auf acme-aws.com.

2. Klicke in der Web-ACL auf Add rules › „Add my own rules and rule groups“, um den Rule builder zu öffnen (in der neuen AWS-Konsole heißt das Custom rule). Fülle ihn wie im Screenshot aus: eine reguläre Regel namens CoreDash, die den Header user-agent prüft und jeden Request erlaubt, bei dem er mit CoreDash/ beginnt. Scrolle dann unter das Formular und klicke auf „Add rule“.

Die CoreDash-Regel: Single header user-agent, Starts with string CoreDash/, Aktion Allow.

3. AWS öffnet dann „Set rule priority“. Wähle CoreDash aus, klicke auf „Move up“, bis die Regel ganz oben steht, und klicke auf Save. AWS arbeitet die Regeln von oben nach unten ab. Ein Request, der auf eine Allow-Regel trifft, läuft nicht weiter – Bot Control bekommt einen CoreDash-Request also nie zu sehen.

CoreDash ganz oben, über der Regelgruppe Bot Control.

4. Prüfe, ob CoreDash durchkommt. In Sampled requests zeigen die neuesten CoreDash-Requests jetzt deine CoreDash-Regel mit der Aktion Allow.

Die neuesten CoreDash-Checks auf acme-aws.com treffen auf die CoreDash-Regel und kommen durch.

Prüfe in CoreDash den Bot, den du nutzt – wie in Schritt 5 der Cloudflare-Skip-Regel: Ein neues Audit zeigt deine eigene Seite im Page load filmstrip, und der Monitor springt nach dem nächsten Uptime-Check auf Up.

Wie bei Cloudflare macht das Bot-Token deines Projekts diese Regel sicherer. Warum das so ist und welche Websites das Token erhalten, steht im Abschnitt zum Cloudflare-Token oben. So stellst du die AWS-Regel auf das Token um:

1. Öffne in CoreDash die Project settings, wechsle zum Tab „CoreDash bot token“ und klicke auf „Copy token“.
2. Öffne in AWS WAF erneut die CoreDash-Regel in deiner Web-ACL. Es ist das Formular aus dem Rule-builder-Screenshot oben.
3. Ändere den Namen des Header-Felds von user-agent zu x-coredash-bot. AWS ignoriert Groß- und Kleinschreibung bei Headern – das ist also der Header X-CoreDash-Bot.
4. Setze den Match type auf „Exactly matches string“, füge dein Token als Vergleichswert ein und speichere die Regel.

Der Origin-Check läuft hinter deinem CDN ins Timeout

Dieser Teil betrifft nur den Uptime-Check – und das nur, wenn du beim Einrichten des Monitors unter Advanced eine Origin IP eingetragen hast. CoreDash prüft deinen Server dann auch direkt, am CDN vorbei. Manche Server akzeptieren Requests nur von den IP-Adressen des CDNs. Der Monitor springt dann mit „The origin check fails: Connect timeout“ auf Down, während Besucher weiterhin Seiten aus dem CDN erhalten.

Das CDN liefert weiterhin gecachte Seiten aus, während der Check auf dem Server selbst ins Timeout läuft.

Eine Regel für den User-Agent oder das Token hilft hier nicht: Ein solcher Server verwirft den Check wegen seiner Herkunft, noch bevor er irgendeinen Header liest. Er muss CoreDash also an seinen IP-Adressen erkennen. Erlaube die beiden Uptime-Adressen 51.195.222.219 und 51.195.222.220 in der Firewall deines Servers oder bitte deinen Hoster darum. Wenn der Origin-Check später wieder ins Timeout läuft, schau dir zuerst die aktuelle Liste an: Die Adressen könnten sich geändert haben.

CoreDash wird immer noch blockiert

Wenn der Monitor weiterhin Blocked meldet oder das Audit fehlschlägt: Öffne erneut das Log und klicke auf den neuesten CoreDash-Request – Events in Cloudflare, Sampled requests in AWS. Was dort genannt wird, blockiert CoreDash jetzt. Die typischen Ursachen:

• Eine andere Funktion als zuvor – wie Browser integrity check, nachdem du den Bot Fight Mode ausgeschaltet hast. Erstelle zusätzlich die Skip-Regel.
• Die Regel ist nicht aktiv oder in AWS nicht ganz oben. In Cloudflare sollte die CoreDash-Regel unter Custom rules als Active stehen. AWS verlangt sie an oberster Stelle unter „Set rule priority“.
• Die Regel weicht von der Anleitung ab. Cloudflare verlangt contains und CoreDash/ mit Schrägstrich; AWS benötigt den Header user-agent und „Starts with string“.
• Eine deiner eigenen Cloudflare-Regeln, etwa ein Länder-Blocker. Die Skip-Regel lässt deine eigenen Custom Rules weiterlaufen. Ändere die Regel so, dass sie CoreDash ausnimmt. Events zeigt dir, aus welchem Land der Request kam.
• Under Attack Mode. Er stellt jeden Besucher vor eine Challenge – auch CoreDash –, bis du ihn ausschaltest.
• Ein Request, der durchging, oder gar kein CoreDash-Request im Log. Dann sitzt eine weitere Firewall vor oder hinter Cloudflare oder AWS, etwa die deines Hosters oder eine Regel auf deinem Server. Erlaube den User-Agent CoreDash/ auch dort.

Kommst du nicht weiter? Kontaktiere CoreDash mit der URL des Monitors oder der geprüften Seite und dem Zeitpunkt der Blockade.

Was beide Bots senden und warum, erfährst du auf der CoreDash-Bot-Seite. Mehr zu Monitoren: Uptime-Monitoring, und für Skripte die Uptime-API.