Fehlersuche

Diese Anleitung hilft bei typischen Rollout- und Betriebsfragen. Teilen Sie keine Secrets, Produktzugangsdaten, Tokens, privaten Schlüssel oder unbereinigten Sicherheitslogs in öffentlichen Tickets oder Chat-Tools.

Erste Prüfung bei jedem Problem

• WAF-Prozess oder Container läuft.
• Erwartete Konfiguration wird geladen.
• DNS zeigt auf den richtigen Einstiegspunkt.
• Upstream ist aus der WAF-Umgebung erreichbar.
• Logs und Metriken sind aktiv.
• Domain läuft bewusst im Audit Mode oder Blocking Mode.
• Hostname passt zum konfigurierten Tenant.

Schnelle Laufzeitprüfung:

curl -sS http://127.0.0.1/healthz
curl -sS http://127.0.0.1/readyz

Wenn Metriken aktiviert sind:

curl -sS http://127.0.0.1/metrics

Anwendung lädt nicht

Prüfen:

• Domainname in der Anfrage entspricht dem Tenant.
• Upstream-URL ist aus der WAF-Laufzeitumgebung erreichbar.
• Upstream-Dienst hört auf dem erwarteten Port.
• Firewall und Security Groups erlauben Traffic von WAF zu Upstream.
• TLS-Terminierung ist wie geplant.
• Load-Balancer-Health-Checks nutzen einen gültigen Pfad.

Nützlicher Test:

curl -H "Host: app.example.test" http://127.0.0.1/

Erwarteter Block passiert nicht

Prüfen:

• waf_enabled ist true.
• Die Domain bindet das erwartete Regelprofil ein.
• Die Anfrage erreicht den richtigen Tenant.
• Die Regel passt zu Pfad, Header, Body oder Methode.
• audit_mode ist nicht weiterhin aktiv.

Im Audit Mode werden auffällige Anfragen geloggt, aber nicht blockiert.

Legitime Nutzer werden blockiert

Vorgehen:

• Zeitstempel, Domain, Pfad und Nutzerwirkung erfassen.
• Sicherheitsereignis in Logs suchen.
• Betroffene Domain bei hoher Wirkung zurück in Audit Mode setzen.
• Ursache prüfen, bevor eine Ausnahme ergänzt wird.
• Exakten Nutzer-Workflow erneut testen.

Vermeiden Sie breite Allow-Lists. Ausnahmen sollten eng und fachlich begründet sein.

Zu viele Sicherheitsereignisse

Häufige Ursachen:

• Scanner treffen öffentliche Pfade.
• Bots prüfen CMS- und Adminpfade.
• Alte API-Clients senden unerwartete Parameter.
• Testwerkzeuge erzeugen auffällige Requests.
• Profil ist für den ersten Rollout zu streng.
• Paranoia-Level wurde erhöht, ohne neue False Positives zu prüfen.
• API- oder CMS-Profil trifft auf nicht passende Anwendungspfade.

Empfohlen:

• Ereignisse nach Domain, Pfad und Regel gruppieren.
• Echten Nutzer-Traffic von Scannern trennen.
• Laute Scanner-Blocks beibehalten, wenn keine Nutzerwirkung entsteht.
• False Positives zuerst im Audit Mode tunen.
• Regelprofil, Paranoia-Level und letzte Regeländerung notieren.

API- oder GraphQL-Clients schlagen fehl

Prüfen:

• Token-Prüfung passt zum Identity Provider.
• JWKS-Endpunkt ist aus der WAF-Umgebung erreichbar.
• Rate Limits berücksichtigen Batch- und Retry-Verhalten.
• GraphQL-Tiefe und Batch-Grenzen passen zur echten Client-Nutzung.
• Content-Type und Methodenregeln blockieren keine gültigen Clients.
• Strenge API-Profile passen zu Uploads, Webhooks und Form-Posts.

LLM-Endpunkte erzeugen zu viele Treffer

Prüfen:

• Richtige Pfade stehen in inspect_paths.
• Richtige JSON-Felder stehen in inspect_json_fields.
• Regel läuft zuerst mit action: "audit".
• Echte Nutzerprompts sind von Tests oder Red-Team-Prompts getrennt.
• Blocking ist fachlich freigegeben.

LLM-Schutz sollte nicht ohne Prüfung produktiver Prompts auf deny gestellt werden.

Länder- oder IP-Regeln treffen gültige Nutzer

GeoIP und IP-Regeln können VPNs, Remote Worker, Mobilfunknetze und Support-Dienstleister betreffen.

Vor Durchsetzung:

• fachlichen Grund prüfen
• Support- und Betriebsteams testen lassen
• Ausnahmen dokumentieren
• erste Produktionsstunden beobachten

Rate Limits greifen zu früh

Prüfen:

• normale Spitzenlast
• Browser-Assets
• API-Batching
• Monitoring und Health Checks
• NAT- oder Proxy-Situationen mit vielen Nutzern hinter einer IP

Passen Sie Limits pro Domain an, statt globale Werte unnötig zu lockern.

TLS- oder Zertifikatsprobleme

Prüfen:

• DNS zeigt auf den erwarteten Einstiegspunkt.
• Domaininhaberschaft ist für Zertifikatssetup bereit.
• Alte Proxy- oder CDN-Einstellungen widersprechen dem neuen Pfad nicht.
• Zertifikatsspeicher ist persistent, falls erforderlich.
• Systemuhren sind korrekt.

Bei Managed-Service-Rollouts synit.io kontaktieren, bevor DNS mehrfach geändert wird.

Produktzugang oder Abonnement

Prüfen:

• Zugangswerte sind im Deployment vorhanden.
• Secrets wurden nicht abgeschnitten oder falsch escaped.
• Deployment nutzt das aktuelle Handoff-Paket.
• Laufzeit kann erforderliche Produkt-Endpunkte erreichen.

Veröffentlichen Sie keine Produktzugangsdaten. Kontaktieren Sie synit.io mit Kundenname, betroffener Domain, Deployment-Modell und Zeitstempeln.

Angaben für eine Supportanfrage

Angeben:

• betroffene Domain
• Managed oder Self-Hosted
• Zeitfenster und Zeitzone
• erwartetes Verhalten
• tatsächliches Verhalten
• aktiver Audit- oder Blocking-Modus
• bereinigte Log-Auszüge
• letzte Konfigurationsänderungen
• aktive Regelprofile und Paranoia-Level
• Image-Tag oder Release-Version

Nicht angeben:

• Produktzugangsdaten
• Tokens
• Passwörter
• private Schlüssel
• vollständige Kundendatenexporte