LIVCK Cloud

CDN & WAF-Integration

Läuft dein Ziel hinter einem CDN oder einer WAF (Web Application Firewall) -- Cloudflare, Bunny CDN, Fastly, Akamai, Sucuri und andere -- kann es passieren, dass LIVCK als Bot erkannt und geblockt wird. Typisches Symptom: Der Service ist im Browser erreichbar, LIVCK meldet ihn aber als Offline, und im Artifact steht eine Block-Seite wie

Sorry, you have been blocked
You are unable to access <deine-domain>
Cloudflare Ray ID: …

Diese Seite erklärt, wie du LIVCK bei deinem CDN-/WAF-Anbieter freigibst -- sicher, ohne die WAF für echte Angreifer aufzuweichen.

Warum das passiert

CDN- und WAF-Anbieter filtern automatisierten Traffic. Sie sehen unbekannte User-Agents, ungewöhnliche IPs oder fehlende Browser-Signale und blocken den Request -- meist mit einem 403 und einer Block-Seite. Das trifft legitime Uptime-Monitoring-Bots genauso wie Angriffe.

LIVCK sendet standardmäßig den User-Agent:

LIVCK-Worker/1.0 (+https://livck.cloud/bot)

Der ist öffentlich dokumentiert -- das ist Absicht (Transparenz für Seitenbetreiber, siehe unsere Bot-Seite), heißt aber auch: eine WAF-Regel, die nur auf diesen UA matcht, kann von Angreifern einfach durch curl -A "LIVCK-Worker/1.0 …" umgangen werden. Für eine echte Allowlist brauchst du etwas, das nur LIVCK kennt.

Der sichere Weg: geheimer Custom Header

Warum nicht einfach den User-Agent allowlisten?

Ein UA-Contains-Check ist unsicher, weil der LIVCK-UA öffentlich bekannt ist. Jeder Angreifer kann denselben UA senden und deine WAF-Regel umgehen. Eine sichere Allowlist braucht ein geheimes Merkmal, das nur LIVCK mit deinem Service teilt.

LIVCK kann pro Service einen individuellen HTTP-Header mitsenden. Diesen Header-Wert matcht du in deiner WAF-Regel. Weil nur LIVCK und du den Wert kennen, kann ein Angreifer ihn nicht erraten und die WAF nicht umgehen.

Schritt 1 -- Header festlegen

  1. Wähle einen Header-Namen und einen langen, zufälligen Wert. Beispiel:
    • Name: X-LIVCK-Bot
    • Wert: 9f3c2a1e8b7d4c6a5e2f9b1d8c7a6e3f (mindestens 32 Zeichen, zufällig)
  2. Erzeuge den Wert mit einem Passwort-Generator, KeePassXC, openssl rand -hex 24 oder 1Password. Keine erratbaren Werte wie livck oder monitoring.

Tipp

Behandle den Header-Wert wie ein Passwort. Je länger und zufälliger, desto sicherer. Ein 32-stelliger Hex-String reicht für die meisten Anforderungen.

Schritt 2 -- Header in LIVCK hinterlegen

  1. Öffne den Service unter Services → Service anklicken → Bearbeiten.
  2. Im Schritt Konfiguration scrolle zu Custom Headers.
  3. Trage Name und Wert ein (z.B. X-LIVCK-Bot → 9f3c2a1e8b7d4c6a5e2f9b1d8c7a6e3f).
  4. Speichern.

Werte werden verschlüsselt gespeichert

Header-Werte liegen verschlüsselt vor. Bestehende Werte werden im Formular nicht erneut angezeigt -- Feld leer lassen bedeutet behalten, neuen Wert eingeben ersetzt.

LIVCK sendet ab der nächsten Prüfung deinen Header mit jedem Request an diesen Service.

Schritt 3 -- WAF-Regel beim Anbieter anlegen

Die Regel lautet sinngemäß: Wenn der Header X-LIVCK-Bot gleich <dein Wert> ist, dann erlaube (Skip / Allow) -- und sonst die normale WAF-Logik weiterlaufen lassen. Konkrete Snippets für die häufigsten Anbieter:

Cloudflare

  1. Cloudflare-Dashboard → Security → WAF → Custom rules → Create rule.
  2. Feld-Ausdruck als Edit expression (oder via Builder):
(http.req.headers["x-livck-bot"] eq "9f3c2a1e8b7d4c6a5e2f9b1d8c7a6e3f")
  1. Action: Skip → aktiviere "All remaining custom rules" (damit keine nachfolgenden WAF-Regeln LIVCK-Requests treffen).
  2. Scope: Hostname gleich deine überwachte Domain.
  3. Deploy.

Skip, nicht Allow

Mit Skip umgehst du explizit alle nachfolgenden WAF-Regeln für den gematchten Request. Allow allein reicht oft nicht -- spätere Managed Rules oder Rate-Limits können sonst trotzdem zuschlagen. Wenn du nur die Bot-Fight-Mode-Blockade umgehen willst, reicht "Allow" oder "Log" als Action.

Bunny CDN (Shielding)

  1. Bunny-Dashboard → Shielding (oder Edge Rules je Zone).
  2. Neue Edge Rule anlegen:
    • Match: Request Header X-LIVCK-Bot equals 9f3c2a1e8b7d4c6a5e2f9b1d8c7a6e3f.
    • Action: Allow (oder Bypass Shielding).
  3. Speichern und publishen.

Bunny Edge Rules sind kostenpflichtig

Edge Rules in Bunny sind ein kostenpflichtiges Add-On. Für einfache Freigaben reicht oft die IP-Allowlist (siehe unten) statt einer Edge Rule.

Andere Anbieter (Fastly, Akamai, Sucuri, AWS WAF)

Das Prinzip ist überall gleich:

  1. Neue Regel / Custom Rule / Rule Statement anlegen.
  2. Match-Bedingung auf Request-Header X-LIVCK-Bot equals <dein Wert>.
  3. Action: Allow / Skip / Bypass WAF.
  4. Ggf. Scope auf den überwachten Host einschränken.

Bei AWS WAF (CloudFront / ALB) nutzt du eine Custom-WebACL-Regel mit ByteMatchStatement auf den Header-Wert und Action Allow.

Schritt 4 -- testen

  1. Speichere den Service in LIVCK, warte ein Intervall ab.
  2. Im Service-Detail sollte der Check jetzt Online sein und ein Status 200 zeigen.
  3. Bleibt der Service Offline: öffne das jüngste Artifact -- steht dort noch die Block-Seite, greift die WAF-Regel nicht. Prüfe Header-Namen, Wert und Scope (richtiger Host?).
  4. Kommt der Check durch, ist die Block-Seite verschwunden und du siehst die echte Antwort deines Ursprungs.

Alternative: IP-Allowlist

Wenn du keine Custom Header setzen willst, kannst du stattdessen die LIVCK-Egress-IPs in deiner WAF freigeben. Die IPs sind dynamisch -- du bekommst sie als Liste unter:

https://app.livck.cloud/ips

IP-Listen können sich ändern

LIVCK erweitert und rotiert Prüfstandorte. Allowlist-Einträge können dadurch veralten und müssen regelmäßig synchronisiert werden. Der Custom-Header-Weg ist robuster, weil er nicht von der IP-Adresse abhängt.

Bei Cloudflare legst du dafür eine WAF-Custom-Regel mit Match ip.src in {<IPs aus /ips>} und Action Skip an. Bei Bunny hinterlegst du die IPs in den Shielding-Allowlisten.

Sicherheitsnetz: Conditions für Block-Antworten

Egal welche Freigabe-Methode du nutzt -- lege zusätzlich eine Bedingung an, die eine Block-Antwort als Offline markiert. So bekommst du es sofort mit, falls die WAF-Regel aus Versehen deaktiviert wird oder der Anbieter die Konfiguration ändert:

FeldOperatorWertStatus
Statuscodegleich403Offline
Antwort-InhaltenthältSorry, you have been blockedOffline
Antwort-Inhaltenthältcf-rayBeeinträchtigt
Antwort-Headerenthält nichttext/html (dein echter Content-Type)Beeinträchtigt

Empfehlung

Mindestens die 403-Bedingung sollte jeder Service hinter CDN/WAF haben. Ohne sie meldet LIVCK die Block-Seite als "erfolgreiche Antwort" und der Service bleibt fälschlich Online -- das ist genau das Szenario, das du vermeiden willst.

Ohne eigene Bedingung gilt: erfolgreiche Antwort = Online. Eine 403-Block-Seite ist technisch eine erfolgreiche HTTP-Antwort und wird ohne explizite Bedingung nicht als Offline erkannt. Siehe Bedingungen für Details.

Was tun, wenn es trotzdem nicht klappt

  1. Artifact öffnen -- Service-Detailseite → jüngstes Artifact. Steht die Block-Seite noch drin? Dann greift die WAF-Regel nicht.
  2. Header-Wert prüfen -- exakt gleiche Schreibweise in LIVCK und in der WAF-Regel? Keine Leerzeichen am Anfang/Ende? LIVCK speichert den Header-Wert verschlüsselt, prüfe also in den Service-Einstellungen gegen.
  3. Scope der Regel -- matcht die Regel den überwachten Host? Oft ist eine Regel versehentlich auf eine andere Subdomain beschränkt.
  4. Reihenfolge / Priorität -- bei Cloudflare steht die Skip-Regel ganz oben, sonst kann eine frühere Managed Rule den Request schon blocken.
  5. Cache leeren -- manche CDNs cachen die Block-Antwort. Purge die URL nach Änderung der WAF-Regel.
  6. Alternative probieren -- wechsle zum IP-Allowlist-Weg, falls der Header-Weg hakt.

Zusammenfassung

WegSicherheitAufwandRobustheit
Custom Header (empfohlen)hoch -- geheimer Wert, nicht spoofbareinmalig: Header setzen + 1 WAF-Regelsehr robust -- unabhängig von IPs
IP-Allowlistmittel -- IPs öffentlich, aber rotierenIP-Liste abonnieren, regelmäßig syncenmittelmäßig -- veraltet bei IP-Rotation
User-Agent-Allowlistniedrig -- nicht empfohlenminimalUA ist öffentlich, von Angreifern spoofbar

Kombiniere den Custom-Header-Weg mit einer 403-Bedingung als Sicherheitsnetz -- so hast du eine saubere Freigabe und merkst sofort, wenn die WAF-Regel aus Versehen kippt.

Weiterführende Themen