Access Rules

Access Rules sind die eigene Sicherheits-Richtlinienebene: Sie werden vor allen anderen Regeln und vor der Web Application Firewall (WAF) ausgewertet — nur die Zonen- und globalen IP-Listen laufen davor (siehe Lebenszyklus einer Anfrage). Das ermöglicht präzise Kontrolle darüber, wer wie auf die Zone zugreifen kann.

Access Rules: die Sicherheitsschicht vor allen anderen Regeln.

Was sind Access Rules?

Mit Access Rules lässt sich der Zugriff auf die Zone basierend auf Anfrageeigenschaften wie IP-Adressen, geografischem Standort, User Agents, Headern und mehr kontrollieren. Sie sind speziell für Sicherheitsentscheidungen konzipiert und laufen ganz am Anfang der Regel-Pipeline, direkt nach den Zonen- und globalen IP-Listen.

Wichtige Eigenschaften:

• Werden zuerst in der Regelsequenz ausgeführt (vor Rewrite und Conditional Rules)
• Laufen vor der WAF-Verarbeitung
• Fokus auf Sicherheitsaktionen: Allow, Block, Challenge oder Skip für bestimmte Schutzfunktionen
• Werden in Positionsreihenfolge ausgewertet (1, 2, 3...)
• Alle passenden Regeln werden angewendet – mehrere Regeln können dieselbe Anfrage beeinflussen
• Optionaler Stop-Modus – stoppt die weitere Auswertung bei Bedarf

Der Editor für Access Rules: Name, Beschreibung, Schalter für Aktivierung und Stop-Modus, die Wenn-Bedingungen und die Dann-Aktion, mit der Regelliste in der linken Leiste.

Wie Access Rules funktionieren

Access Rules werden in aufsteigender Positionsreihenfolge (1 -> 2 -> 3...) für jede eingehende Anfrage ausgewertet. Wenn die Bedingungen einer Regel zutreffen, wird ihre Aktion angewendet und die Auswertung fährt fort zur nächsten Regel (es sei denn, der Stop-Modus ist aktiviert).

Positionsbasierte Auswertung

Anfrage kommt an
    |
Access Rule (Position 1) -> Treffer? -> Aktion anwenden -> WEITER
    |
Access Rule (Position 2) -> Treffer? -> Aktion anwenden -> WEITER
    |
Access Rule (Position 3) -> Treffer + Stop-Modus? -> Aktion anwenden -> STOP
    | (kein Treffer oder kein Stop)
Access Rule (Position 4) -> Treffer? -> Aktion anwenden -> WEITER
    |
Weiter zu Rewrite Rules...

Wichtig: Alle Access Rules werden ausgewertet, es sei denn, eine passende Regel hat den Stop-Modus aktiviert. Das ermöglicht mehrschichtige Sicherheitsrichtlinien, bei denen mehrere Regeln auf dieselbe Anfrage angewendet werden können.

Stop-Modus

Die Stop-Modus-Option steuert, ob die Auswertung nach einem Regeltreffer fortgesetzt wird.

Wie der Stop-Modus funktioniert

Wenn der Stop-Modus deaktiviert ist (Standard):

• Die Aktion der Regel wird angewendet
• Die Auswertung fährt mit der nächsten Access Rule fort
• Mehrere Regeln können dieselbe Anfrage beeinflussen

Wenn der Stop-Modus aktiviert ist:

• Die Aktion der Regel wird angewendet
• Alle nachfolgenden Access Rules werden übersprungen
• Die Verarbeitung fährt mit den Rewrite Rules fort

Wann der Stop-Modus zu verwenden ist

Der Stop-Modus eignet sich, wenn:

• Eine Regel endgültig sein soll und keine weiteren Access Rules angewendet werden sollen
• widersprüchliche Aktionen anderer Regeln verhindert werden sollen
• Vertrauenswürdiger Traffic alle verbleibenden Sicherheitsprüfungen überspringen soll

Beispiel:

Position 1: WENN (IP in office_range) DANN Allow + Stop-Modus
Position 2: WENN (Country = "XX") DANN Block [wird für Office-IPs nicht ausgewertet]
Position 3: WENN (URI = /admin) DANN Challenge [wird für Office-IPs nicht ausgewertet]

-> Office-IPs erhalten Allow und überspringen alle anderen Access Rules

Aktionen

Access Rules unterstützen vier Sicherheitsaktionen:

Der Aktions-Picker: Auswahl zwischen Zulassen, Überspringen, Challenge oder Blockieren; Überspringen zeigt die Optionen zum Umgehen von WAF, Rate-Limiting und Challenge.

1. Allow

Lässt die Anfrage durch und umgeht dabei alle Sicherheitsschutzmaßnahmen, einschließlich Under Attack Mode und alle zukünftigen Sicherheitsmaßnahmen, die hinzugefügt werden könnten.

Wann zu verwenden:

• Vertrauenswürdiger Traffic, der niemals von einer Sicherheitsfunktion blockiert werden soll
• Anfragen, die alle aktuellen und zukünftigen Sicherheitsmaßnahmen umgehen müssen
• Interne Tools oder Monitoring-Dienste, die garantierten Zugang benötigen
• Office-IPs, die vollen, uneingeschränkten Zugang benötigen

Beispiel:

Bedingung: IP in [203.0.113.0/24] (vertrauenswürdiges internes Netzwerk)
Aktion: Allow
Stop-Modus: Aktiviert
-> Interner Traffic umgeht alle Sicherheit und überspringt verbleibende Access Rules

Hinweis: Allow umgeht automatisch alle Sicherheitsmaßnahmen, einschließlich aller neuen, die in Zukunft hinzugefügt werden. Dies ist die permissivste Aktion.

2. Block

Blockiert die Anfrage sofort und gibt eine Fehlerantwort zurück.

Wann zu verwenden:

• Bekannte bösartige IPs blockieren
• Anfragen aus bestimmten Ländern blockieren
• Verdächtige User Agents oder Bots blockieren
• Zugang zu sensiblen Bereichen verhindern

Beispiel:

Bedingung: Country = "XX"
Aktion: Block
-> Alle Anfragen aus diesem Land werden blockiert

3. Challenge

Stellt eine Proof-of-Work-Challenge, die der Client lösen muss, bevor er fortfahren kann. Dies wird automatisch vom Browser des Clients gehandhabt – der Benutzer muss kein CAPTCHA oder ein visuelles Rätsel lösen.

Wann zu verwenden:

• Schutz gegen automatisierte Bots
• Rechenkosten für verdächtigen Traffic hinzufügen, ohne vollständig zu blockieren
• Login-Seiten oder Formulare vor Brute-Force-Angriffen schützen
• Ungewöhnliche Traffic-Muster herausfordern

Beispiel:

Bedingung: User Agent enthält "bot" ODER "crawler"
Aktion: Challenge
-> Verdächtige Bots müssen eine rechnerische Challenge absolvieren

4. Skip

Umgeht bestimmte Sicherheitsfunktionen für vertrauenswürdigen Traffic, während andere Sicherheitsmaßnahmen aktiv bleiben. Diese Aktion hat drei optionale Flags, die kombiniert werden können.

Skip-Flags

waf-Flag:

• Wenn true: Web Application Firewall für diese Anfrage umgehen
• Wenn false: WAF wird weiterhin angewendet

rateLimiting-Flag:

• Wenn true: Rate-Limiting für diese Anfrage umgehen – die Anfrage wird nie gedrosselt oder wegen überschrittener Ratenlimits abgewiesen, auch wenn ein verwaltetes Sicherheitsszenario den Client als zu aggressiv einstuft
• Wenn false: Rate-Limiting wird weiterhin angewendet

challenge-Flag:

• Wenn true: Challenge für diese Anfrage umgehen, einschließlich Under Attack Mode
• Wenn false: Challenge und Under Attack Mode werden weiterhin angewendet

Wann zu verwenden:

• WAF für Tools umgehen, die False Positives auslösen
• Rate-Limiting für legitime Clients mit hohem Anfragevolumen umgehen, etwa Feed-Abrufe oder Batch-API-Clients
• Under Attack Mode für vertrauenswürdigen Traffic umgehen, während WAF aktiv bleibt
• Feingranulare Kontrolle darüber, welche Sicherheitsfunktionen deaktiviert werden sollen
• API-Clients oder Webhooks, die bestimmte Schutzmaßnahmen umgehen müssen

Beispiele:

Bedingung: User Agent = "Monitoring-Tool/1.0"
Aktion: Skip
Flags: waf=true
-> Monitoring-Tool umgeht nur WAF, Rate-Limiting und Challenge gelten weiterhin

Bedingung: IP in partner_crawler_ips
Aktion: Skip
Flags: rateLimiting=true
-> Partner-Crawler wird nie ratenlimitiert, WAF und Challenge gelten weiterhin

Bedingung: IP in payment_webhook_ips
Aktion: Skip
Flags: challenge=true
-> Zahlungs-Webhooks umgehen Under Attack Mode, WAF gilt weiterhin

Bedingung: IP in trusted_api_clients
Aktion: Skip
Flags: waf=true, rateLimiting=true, challenge=true
-> API-Clients umgehen WAF, Rate-Limiting und Under Attack Mode

Unterschied zu Allow: Skip erlaubt die Wahl, welche spezifischen Sicherheitsfunktionen umgangen werden sollen. Allow umgeht alles automatisch, einschließlich aller zukünftigen Sicherheitsfunktionen. Skip eignet sich für granulare Kontrolle, Allow für eine vollständige Umgehung.

Bedingungen & Ausdrücke

Access Rules verwenden einen umfangreichen Bedingungs-Builder, mit dem sich Anfragen basierend auf verschiedenen Eigenschaften abgleichen lassen, darunter:

• IP-Adressen und IP-Bereiche
• Geografischer Standort (Land, Stadt, EU-Status)
• HTTP-Header (User Agent, Referer, benutzerdefinierte Header)
• Anfrageeigenschaften (URI, Methode, Host)
• Cookies und Query-Parameter

Der Bedingungs-Builder: Anfragen anhand von IP, Standort, Headern und mehr mit UND/ODER-Logik abgleichen.

Mehrere Bedingungen lassen sich mit AND/OR-Logik kombinieren, um ausgefeilte Abgleichsregeln zu erstellen:

(IP in office_range ODER IP in partner_ips) UND URI beginnt mit /admin

Der Bedingungs-Builder ist dasselbe System, das von Conditional Rules verwendet wird, und bietet leistungsstarke und flexible Abgleichsmöglichkeiten für Sicherheitsrichtlinien.

Best-Practice-Workflow

Der empfohlene Ansatz für Access Rules ist:

1. ALLOW-Regeln zuerst definieren (Positionen 1-3)

Zunächst vollständig vertrauenswürdigen Traffic auf die Whitelist setzen, der alle Sicherheit umgehen soll, einschließlich zukünftiger Funktionen. Den Stop-Modus verwenden, um weitere Auswertung zu verhindern.

Position 1: WENN (IP in office_range) DANN Allow + Stop-Modus
Position 2: WENN (IP in trusted_partners) DANN Allow + Stop-Modus
Position 3: WENN (User Agent = "internal-api-client") DANN Allow + Stop-Modus

2. SKIP-Regeln für teilweise Umgehung definieren (Positionen 4-6)

Als Nächstes Regeln für Traffic hinzufügen, der bestimmte Sicherheitsfunktionen umgehen soll, aber weiterhin anderen unterliegt.

Position 4: WENN (IP in monitoring_tools) DANN Skip (waf=true)
Position 5: WENN (User Agent = "payment-webhook") DANN Skip (challenge=true)
Position 6: WENN (IP in api_clients) DANN Skip (waf=true, challenge=true)

3. BLOCK/CHALLENGE-Regeln zuletzt definieren (Positionen 7+)

Nach dem Whitelisting von vertrauenswürdigem Traffic die restriktiven Regeln hinzufügen. Diese haben höhere Positionsnummern.

Position 7: WENN (Country in ["XX", "YY"]) DANN Block
Position 8: WENN (User Agent enthält "malicious-bot") DANN Block
Position 9: WENN (URI beginnt mit "/admin") DANN Challenge

Warum der Stop-Modus wichtig ist

Ohne Stop-Modus werden alle Regeln ausgewertet. Mit Stop-Modus bei den Allow-Regeln überspringt vertrauenswürdiger Traffic die verbleibenden Sicherheitsprüfungen:

Ohne Stop-Modus:

Position 1: Allow IP = office (kein Stop)
Position 2: Challenge URI = /admin
-> Office beim Zugriff auf /admin wird trotzdem gechallengt!

Mit Stop-Modus:

Position 1: Allow IP = office + Stop-Modus
Position 2: Challenge URI = /admin
-> Office überspringt die Challenge-Regel vollständig

Anwendungsfälle & Beispiele

Beispiel 1: Vollzugriff für Office-IPs

Szenario: Das Team benötigt vollen Zugang ohne jegliche Sicherheitsprüfungen, einschließlich während des Under Attack Mode.

Position: 1
Bedingung: IP in [203.0.113.0/24, 198.51.100.50]
Aktion: Allow
Stop-Modus: Aktiviert

Ergebnis: Office-Traffic umgeht ALLE Sicherheit und überspringt verbleibende Access Rules

Beispiel 2: Bösartige Länder mit Ausnahmen blockieren

Szenario: Traffic aus Ländern mit hoher Bot-Aktivität blockieren, außer legitime Benutzer.

Position: 1
Bedingung: IP = "203.0.113.45" (eigener VPN-Exit)
Aktion: Allow
Stop-Modus: Aktiviert

Position: 2
Bedingung: Country in ["XX", "YY", "ZZ"]
Aktion: Block

Ergebnis: Das eigene VPN wird erlaubt und stoppt die Auswertung, andere aus diesen Ländern werden blockiert

Beispiel 3: Under Attack Mode für Webhooks umgehen

Szenario: Die Webhooks des Zahlungsanbieters müssen die Zone auch während des Under Attack Mode erreichen können, sollten aber trotzdem von der WAF geprüft werden.

Position: 1
Bedingung: IP in payment_provider_ips
Aktion: Skip
Flags: challenge=true
Stop-Modus: Aktiviert

Ergebnis: Zahlungs-Webhooks umgehen Under Attack Mode, aber WAF gilt weiterhin

IP-Listen verwenden

Statt IPs in jeder Regel fest zu codieren, lassen sich wiederverwendbare IP-Listen in den Kontoeinstellungen erstellen:

1. Eine IP-Liste namens "office_ips" mit den Office-IP-Bereichen erstellen
2. In den Access-Rule-Bedingungen referenzieren

Vorteil: Die IP-Liste wird einmal aktualisiert, und alle Regeln, die sie verwenden, werden automatisch auf allen Zonen aktualisiert.

Eindeutigkeit

Jede Zone kann nur eine Access Rule pro eindeutigem Ausdruck haben. Beim Versuch, ein Duplikat zu erstellen, erscheint: "Die Regel für diesen Ausdruck existiert bereits."

Das verhindert widersprüchliche Regeln und hält die Konfiguration sauber.

Häufige Fehler

Stop-Modus bei Allow-Regeln vergessen

Position 1: Allow IP = office (kein Stop)
Position 2: Block Country = "US"
-> Office in US wird erlaubt, aber dann auch blockiert!

Stop-Modus für vertrauenswürdigen Traffic aktiviert

Position 1: Allow IP = office + Stop-Modus
Position 2: Block Country = "US"
-> Office wird erlaubt und überspringt alle anderen Regeln

---

Allow verwendet, obwohl Skip ausreicht

Aktion: Allow
-> Umgeht ALLE Sicherheit, einschließlich zukünftiger Funktionen

Skip für granulare Kontrolle einsetzen

Aktion: Skip (waf=true)
-> Umgeht nur WAF, andere Schutzmaßnahmen bleiben aktiv

---

Challenge-Flag während Under Attack Mode vergessen

Aktion: Skip (waf=true)
-> Under Attack Mode challengt die Anfrage trotzdem!

Challenge-Flag bei Bedarf hinzufügen

Aktion: Skip (waf=true, challenge=true)
-> Umgeht sowohl WAF als auch Under Attack Mode

---

Zu breite Bedingungen

Bedingung: URI enthält "admin"
-> Betrifft /administrator, /admin, /admin-panel, /user-admin-settings

Spezifische Bedingungen

Bedingung: URI beginnt mit "/admin/"
-> Betrifft nur den tatsächlichen Admin-Bereich

---

Widersprüchliche Aktionen ohne Stop-Modus

Position 1: Allow IP = partner (kein Stop)
Position 2: Block URI = /internal
-> Partner beim Zugriff auf /internal wird erlaubt, dann blockiert!

Stop-Modus einsetzen, um Konflikte zu vermeiden

Position 1: Allow IP = partner + Stop-Modus
Position 2: Block URI = /internal
-> Partner überspringt die Block-Regel