Arquitetura
Fluxo de uma Requisição
Estágios do pipeline, do ingest à ação — passivo e edge inline
Fluxo de uma Requisição
O Sentry opera em dois modos de ingestão, definidos em
[deployment] mode:
- Passivo (default): sources read-only fazem tail de logs / recebem syslog / capturam pacotes. O pipeline analisa o evento e as actions reagem (block no Cloudflare/firewall, webhook, …) — a requisição já aconteceu.
- Inline (
sentry-edge): o Sentry é o reverse proxy na frente da aplicação. O request passa pelo mesmoArc<Pipeline>antes do upstream; o verdict decide se ele segue (e a fase de resposta é re-observada — ver abaixo).
Estágios em detalhe
- Ingest + dedupe — o loop do daemon drena o fan-in em lote
(
recv_many(64)) e consulta uma LRU por hashu64do evento; GETs idênticos dentro dededupe_ttl_secs(10 s) morrem antes do pipeline. Vejadaemon.rs. - Guardas de confiança (
trust.rs) — IPs emtrusted_ips(never-ban) recebem Allow imediato; IPs nablacklistlevam Block antes de qualquer detector. - Bot verification (
botverify.rs, F7.7) — UA que alega crawler é anotado com o resultado cacheado do rDNS (verificado → bypass de challenge; falsificado → sinalSpoofedBot). - Rules engine (
rules.rs,packs.rs) — fast path. Precedência:Allow(bypass total) >Block/Challenge/RateLimit(short-circuit) >Log/Tag(anota e continua). Packs default:sensitive_paths,crawlers_bad,crawlers_good,empty_ua,http_anomaly,vpn_proxy,tor,rate_scan,country_blocklist,host_allowlist. - Heurísticas (
heuristics.rs) — SQLi/XSS/path traversal/LFI/Log4Shell/cmd injection/sensitive path/bad crawler/UA vazio + scanners de upload (F10). Rodam sobre texto URL-decodificado (http_text) com prefilter Aho-Corasick: tráfego limpo executa zero regex. - Reputação (
reputation.rs) —TorExitNode,KnownBadIp,VpnProxy,PromiscuousScannera partir das feeds sincronizadas (F3.7). - Rotas (validador em
pipeline.rs) — path fora da allowlist (config ∪ DB) →UnknownRoute; método não permitido →MethodNotAllowed. Suporta exato, glob/api/*e templates/users/{id}. - Fase de resposta (F3.9.1) — sinais que dependem do status HTTP
(janelas 4xx) só existem depois da resposta. Na edge inline,
Pipeline::observe_responsealimenta os trackers com o status real (upstream ou 403/429/301 da própria edge) e enfileira os sinais (TTL 60 s, cap 16/IP); o próximo request do mesmo IP os drena para o scoring. Sem isso, scanners em tráfego inline ficariam para sempre em Allow. - Trackers de comportamento —
ScanTracker(≥ 8 paths 4xx distintos →RandomScan; ≥ 10 4xx →ScanBehavior),BehaviorTracker(auth brute-force, credential stuffing, directory brute-force, suspicious login success) eUploadTracker(flood de volume, F10). - Correlação (
correlation.rs, F3.10) — scan de um IP + ataque de outro IP no mesmo /24, /64 ou ASN dentro da janela →ScanAttackCorrelation. - Scorer + policy + escalada — soma dos pesos (cap 100) com bônus de
repetição,
VerdictPolicy(mapping nível→verdict + overrides DSL) eOffenderTracker(strikes sobem o verdict). Detalhes em Níveis de Risco. - Forks assíncronos — modelo ONNX, LLM e lookup externo de IP rodam
fora do caminho quente e re-entram por
rescore_from: só elevam score/verdict, nunca rebaixam. IPs never-ban são imunes. - Actions em duas lanes (F5) — contenção local (blocklist, log,
firewall) roda inline no loop de ingest; actions de rede (Cloudflare,
nginx, OPNsense, webhook, report) vão para workers postergados. Sob
overload a fila de actions enche primeiro: caem actions, nunca
eventos (
sentry_action_queue_drops_total). - Persistência — worker dedicado escreve em lote (um multi-INSERT
por
recv_many); eventos de segurança caem para escrita direta se a fila encher; eventos benignos são coalescidos/amostrados sob pressão. Ver Performance.
Edge inline: o que muda
No modo inline o request entra pela edge antes do upstream:
- Verdicts de contenção são espelhados no
ip_state+NOTIFY sentry_blocks_changed, então o fast-path nega o IP antes do pipeline em todos os nós. - Eventos chegam ao fan-in como
Incoming::Processed(verdict pronto); o daemon só persiste e despacha actions. - Detalhes completos (TLS, challenge, error pages, compressão) em Edge Inline.