O tráfego mudamais rápido que a análise manual de logs.
Para pequenas equipes que usam NGINX ou OpenResty
Responda a tráfego HTTP anômalo com limites, reversão e controle do operador.
DynoxWall detecta anomalias a partir de logs de acesso, permite que operadores inspecionem decisões em dry-run e pode aplicar ações limitadas e reversíveis no NGINX quando o modo ativo é explicitamente habilitado.
Estágio de demo técnica e piloto limitado
Request path and control loop
local NGINX actionHTTP traffic
NGINX / OpenResty
Application
ordinary traffic passes through
access log + traffic signals
DynoxWall anomaly detection
Safety checksprotected target allowlist, scope validation, rate and concurrent block limits, kill switch
temporary blocking rule
audit log
automatic unblock when TTL expires
Quando a resposta manual fica difícil de cronometrar
Bloqueio agressivopode afetar tráfego útil.
Ação manual cautelosapode chegar depois que recursos da aplicação foram esgotados.
O objetivo não é uma automação mais agressiva. É uma automação cujo impacto pode ser inspecionado, limitado, revertido e interrompido.
Como funciona
DynoxWall roda localmente ao lado do NGINX ou OpenResty e usa eventos relevantes dos logs de acesso.
- 1Observar eventos relevantes dos logs de acesso.
- 2Detectar tráfego HTTP anômalo.
- 3Avaliar a decisão em dry-run e verificações de segurança.
- 4Quando explicitamente habilitado, aplicar uma ação limitada no NGINX.
- 5Desbloquear automaticamente ou por controle do operador/emergência, e registrar o ciclo de vida.
HTTP traffic
Optional upstream protection
NGINX / OpenResty
Application
Access log -> DynoxWall
Dry-run or limited NGINX action
Operator, audit, and emergency controls
Controles de segurança
Confiança vem de controles concretos, não de uma afirmação de que a automação é sem risco.
Dry-run
Decisões podem ser inspecionadas antes de qualquer ação ativa ser habilitada.
Allowlist protegida
Fontes ou escopos definidos podem ser protegidos contra bloqueio automatizado.
Limites de escopo
Ações são restringidas ao escopo de tráfego configurado.
Limites de duração
Bloqueios são limitados no tempo em vez de permanecerem indefinidos.
Limites de taxa e bloqueios simultâneos
A taxa e o número de ações ativas são limitados.
Proteção contra duplicidade
Tentativas repetidas de bloquear o mesmo alvo são controladas.
Desbloqueio automático
Ação temporária pode expirar sem limpeza manual.
Kill switch
Operadores podem interromper globalmente a ação ativa.
Desbloqueio de emergência
Operadores podem remover bloqueios ativos por um caminho de emergência.
Trilha de auditoria
Decisões e ciclo de vida das ações são registrados para revisão.
Fluxo do operador
A ação ativa permanece limitada e recuperável.
Mecanismos implementados e testados; validação descartável com NGINX concluída; resultado em produção de cliente ainda não validado
Anomaly detected
Decision and safety checks
Dry-run record
Live action explicitly enabled
Limited NGINX action
Automatic unblock
Manual or emergency unblock
Audit trail
Adequação e limites
Boa adequação quando
- Linux com NGINX/OpenResty.
- Pequena equipe com responsabilidade de produção.
- Tráfego HTTP anômalo é visível em logs de acesso.
- Análise ou mitigação de incidentes ainda é substancialmente manual.
- A equipe quer avaliar dry-run antes de ação ativa limitada.
Não é a camada certa quando
- O link externo está saturado por tráfego volumétrico L3/L4.
- Não existe caminho de log de acesso suportado.
- O requisito é um serviço global de scrubbing totalmente gerenciado.
- Espera-se zero responsabilidade do operador ou garantia de zero falsos positivos.
DynoxWall foi projetado para complementar proteção upstream, não substituí-la.
Demo técnica
A demo é uma apresentação técnica isolada, não um benchmark de produção nem estudo de caso de cliente.
Solicitar demo técnica- 01
Um alvo NGINX isolado.
- 02
DynoxWall em dry-run.
- 03
Uma anomalia HTTP controlada.
- 04
A decisão e as verificações de segurança sem impacto ativo.
- 05
Uma ação limitada explicitamente habilitada no alvo de teste.
- 06
Desbloqueio automático ou de emergência.
- 07
A trilha de auditoria e o estado final.
- 08
As medições propostas para um piloto separado.
Solicitar demo técnica
A solicitação é revisada por adequação técnica. Sucesso no envio não significa que o lead está qualificado.
Texto em português brasileiro requer revisão humana competente antes da publicação.
FAQ
Como DynoxWall difere de rate limits e scripts manuais no NGINX?
Ele combina detecção de anomalias, dry-run, verificações de segurança, ação limitada, desbloqueio automático e ciclo de auditoria.
Ele substitui Cloudflare, AWS Shield, Akamai ou scrubbing?
Não. DynoxWall complementa proteção upstream.
Quais cenários de tráfego estão no escopo?
O escopo inicial inclui HTTP flood, bots agressivos, scraping e carga HTTP anômala visível em logs de acesso do NGINX/OpenResty.
O que impede um bloqueio amplo ou longo demais?
Salvaguardas incluem allowlists, limites de escopo/duração/ação, proteção contra duplicidade, auto-desbloqueio, kill switch, desbloqueio de emergência e trilha de auditoria.
Podemos começar apenas em dry-run?
Dry-run pode ser avaliado antes do modo ativo.
Quais dados o DynoxWall lê e retém?
Campos de dados exatos, retenção e comportamento de rede são confirmados antes de um piloto.
Quais são os requisitos de infraestrutura?
O alvo atual de piloto é Linux com NGINX/OpenResty e acesso relevante a logs de acesso; versões, formatos e permissões exatos são revisados.
Qual é o status atual do produto?
Mecanismos técnicos estão implementados e testados, mas resultado em produção de cliente não está validado.
Quais idiomas de produto e documentação estão disponíveis?
A interface do produto e a documentação são em inglês; os idiomas do landing são inglês, português brasileiro e ucraniano.
Existe preço público?
Não existe preço público durante a validação inicial.