SentrySentry
Architecture

Request Flow

Sequence of stages from log to action

Request Flow

When an access log line arrives, Sentry normalizes it into an Event, sends it to the pipeline, which fans out in parallel to heuristics, AI and the route validator. Results converge in the scorer, producing an AnalysisResult. The decider applies policy and dispatches to actions.

Valid route detection

  1. Controlled discovery: the user supplies valid routes via config (allowlist) or Sentry learns in learn mode (a baseline period with no attacks).
  2. Structure: a trie of paths with allowed methods + expected parameters.
  3. Derived signals:
    • Non-existent route → +points (scan/directory brute-force).
    • Many 404s from the same IP within a window → scan behavior.
    • Hits on sensitive paths (/.env, /wp-admin, /api/admin) even when non-existent → high weight.
  4. Output: a sentry routes report showing known vs. attempted routes.

Cloudflare integration (challenge synergy)

  • Tokens via env (SENTRY_CF_TOKEN, SENTRY_CF_ZONE).
  • Local cache of already-challenged IPs (configurable TTL) to avoid hammering the API.
  • Modes: block, js_challenge, managed_challenge, rate_limit.
  • Important: in phase 1 Sentry is read-only + Cloudflare action. There is no inline proxy. Inline is a future phase (sentry-proxy).

On this page