O tráfego de bots e abuso frequentemente não aparece como uma explosão, mas como um comportamento lento e contínuo. Um IP pode estar fazendo 30-50 requisições por minuto; isso por si só não é catástrofe, mas quando persiste por 10 minutos pode se transformar em scraping, automação ou tentativa de senha. O rate-limit instantâneo nem sempre captura corretamente o caráter dessse comportamento que se distribui no tempo.
As assinaturas WAAP resolvem uma questão diferente: esta requisição corresponde a um padrão de ataque conhecido? Padrões de conteúdo malicioso como SQL injection, XSS ou command injection podem ser detectados. Mas scraping, monitoramento de preços, tentativas de conta ou uso agressivo de API que parecem legítimos mas geram tráfego intenso podem escapar da proteção baseada em assinaturas.
Entre essas duas abordagens é necessário um modelo de isolamento temporário. Se uma determinada fonte apresentou comportamento acima do limite nos últimos N minutos, ela deve ser colocada em quarentena por M minutos sem ser banida permanentemente. Durante esse período seu tráfego pode ser bloqueado, levado a uma página explicativa ou redirecionado para outro fluxo. Quando o prazo expira, a fonte é liberada automaticamente.
Esse modelo exige dois mecanismos distintos: a janela de monitoramento que mede o comportamento e a janela de quarentena que aplica o isolamento. O monitoramento pode ser curto e a quarentena mais longa; ou o inverso, conforme a sensibilidade da aplicação. A ação também não deve ser de tipo único: para algumas fontes um bloqueio silencioso, para outras uma página explicativa, para outras um redirecionamento pode ser mais adequado.
A Quarentena de Tráfego TR7 entrega esse modelo: duas janelas de tempo distintas para monitoramento e quarentena, quatro tipos de chave, três tipos de ação, a possibilidade de usar o estado de quarentena como condição em outras regras e visibilidade em tempo real com intervenção manual a partir da tela do vService.
A Quarentena de Tráfego TR7 combina o monitoramento de comportamento com o isolamento temporário no mesmo motor de políticas.
Em cada regra de quarentena, a janela de monitoramento e a janela de quarentena são definidas separadamente. A janela de monitoramento mede o comportamento da fonte; a janela de quarentena determina quanto tempo a ação durará depois que o limite for ultrapassado.
A fonte não precisa ser identificada apenas por IP. Com as opções IP, IP+user agent, Host+IP e Host+IP+user agent, faz-se uma distinção mais precisa em cenários de múltiplos domínios, NAT e multi-tenant.
Durante a quarentena, o tráfego pode ser bloqueado, redirecionado para outra URL ou ter uma página de conteúdo personalizada exibida. Assim, é possível aplicar bloqueio silencioso ao tráfego do atacante, mensagem explicativa ao usuário real ou um redirecionamento adequado ao fluxo de trabalho.
Uma fonte colocada em quarentena se transforma em um sinal de estado utilizável em todo o sistema. Outras regras de tráfego, redirecionamento e conteúdo podem usar esse sinal como condição para construir uma política composta.
A Quarentena de Tráfego reúne monitoramento de comportamento, isolamento temporário e controle do operador em um único modelo de operação.
Em cada regra, o tempo de monitoramento e o tempo de quarentena são ajustados de forma independente. Dentro da janela de monitoramento, o comportamento da fonte é contado; quando o limite é ultrapassado, a fonte é mantida em uma lista separada durante a janela de quarentena. Quando o prazo expira, o registro é descartado automaticamente. Essa estrutura proporciona um isolamento controlado e temporizado em vez de banimento permanente.
A opção `ip` proporciona o clássico monitoramento por IP de origem. `ipUa` separa os diferentes user agents por trás do mesmo IP. `hostIp` conta separadamente, em ambientes de múltiplos domínios, o comportamento do mesmo IP destinado a hosts diferentes. Já `hostIpUa` proporciona a distinção mais granular em ambientes multi-tenant e multi-cliente.
O operador pode definir um limite para o número de requisições em uma determinada janela de tempo. Regras como "mais de 100 requisições nos últimos 10 minutos" iniciam a quarentena baseada em comportamento. A decisão não se baseia em uma única requisição, mas no comportamento total dentro da janela. Diferentemente do rate-limit, essa abordagem se baseia em observação.
A ação `block` é usada para descartar silenciosamente o tráfego da fonte em quarentena. Em tráfego de bots e automação esse comportamento costuma ser mais eficaz; o atacante não recebe uma resposta clara da aplicação. Essa ação é adequada para cenários de abuso de alto risco em que não é necessário exibir explicação. O impacto sobre usuários reais pode ser acompanhado pela tela de monitor do vService.
`showContent` retorna à fonte em quarentena um código de status HTTP e conteúdo específicos. Por exemplo, pode-se exibir uma página explicando que ela foi temporariamente limitada por excesso de requisições. Esse modelo se comporta de forma mais suave que o bloqueio em cenários com possibilidade de falso positivo ou em que a experiência do usuário é importante. O conteúdo da mensagem pode ser preparado conforme a linguagem de suporte e de marca da organização.
`redirect` é usada para encaminhar a fonte em quarentena para uma URL diferente. O destino pode ser uma página de CAPTCHA, um portal explicativo, uma página de upgrade de assinatura ou uma página de suporte. Assim, a quarentena deixa de ser apenas bloqueio e passa a ser uma ferramenta para levar o usuário ao fluxo de trabalho correto. Em cenários multi-tenant e SaaS essa opção é especialmente valiosa.
O fato de uma fonte estar em quarentena pode ser usado como condição em outras regras. As fontes em quarentena podem ser redirecionadas para um backend diferente, receber um header específico, ver uma resposta de conteúdo específica ou entrar no escopo de uma segunda regra mais rígida. Esse recurso transforma uma única regra de quarentena em um sinal que dispara mudança de comportamento em todo o sistema. É um dos pontos diferenciadores mais importantes do TR7.
A Quarentena de Tráfego pode ser usada tanto para serviços HTTP quanto TCP. No lado HTTP, o comportamento é monitorado por requisição; no lado TCP, a decisão é tomada no nível da conexão. O resultado técnico da ação pode variar conforme o protocolo; mas o modelo básico é o mesmo: monitorar, colocar quem ultrapassa o limite em isolamento temporário e liberar quando o prazo expira.
Na tela de monitoramento em tempo real do vService são listadas as fontes ativas em quarentena. O operador pode ver qual chave, por causa de qual regra e por quanto tempo está em quarentena. Em caso de falso positivo ou usuário prioritário, é possível fazer a remoção manual. Como os registros cujo prazo expira são limpos automaticamente, a intervenção manual não é obrigatória.
Sob o mesmo vService, várias regras de quarentena podem operar em conjunto. Por exemplo, enquanto a primeira regra exibe uma página de aviso em caso de excesso de requisições, a segunda regra pode bloquear por mais tempo a fonte que ainda persiste. São suportadas 5 regras de quarentena paralelas por vService. Essa estrutura cria um controle de abuso que avança do suave ao severo.
A Quarentena de Tráfego é gerenciada operacionalmente em conjunto com o ciclo de vida das tabelas, o comportamento em cluster, o efeito do reload, a tela de monitoramento e os registros de auditoria.
Cada regra de quarentena usa duas áreas de monitoramento em tempo real separadas, para monitoramento e para quarentena. Os registros são mantidos por um período e limpos automaticamente quando o TTL expira. À medida que novas requisições chegam, o comportamento da janela de monitoramento é atualizado. Essa estrutura mantém a quarentena como um controle de comportamento temporizado, não como um banimento permanente.
A cada requisição, primeiro a fórmula da chave é calculada, depois o valor de monitoramento é atualizado e a condição de quarentena é avaliada. Se a fonte já estiver em quarentena, a ação definida é aplicada. Se a fonte não estiver em quarentena, o fluxo normal de tráfego continua. A decisão ocorre com baixo custo no data path.
Em instalações de dois nós, as tabelas de quarentena podem ser projetadas para operar de forma local ou síncrona. Se a sincronização não estiver ativa, após o failover o novo nó ativo reconstrói o histórico de quarentena do zero. Quando a sincronização está ativa, o estado de quarentena pode ser preservado após o failover. Essa escolha deve ser avaliada conforme a necessidade operacional e o modelo de instalação.
As tabelas de quarentena são mantidas em memória e não se comportam como uma blacklist permanente. Após um soft reload ou reset de tabela, o estado de quarentena ativo pode ser limpo. Esse é um comportamento aceitável, pois a quarentena é um mecanismo de isolamento temporário. Se for necessário um banimento de longa duração, ela deve ser usada em conjunto com feeds de reputação de IP.
Na tela de monitor do vService é possível ver os registros de quarentena ativos, e o operador pode remover uma fonte específica da quarentena. Essa operação apaga o registro da tabela; a próxima requisição é avaliada no fluxo normal. Proporciona intervenção rápida em caso de usuário VIP, falso positivo ou solicitação de suporte.
Os eventos de entrada e saída de quarentena podem ser gravados nos registros de auditoria. Se o SIEM log streaming estiver ativo, os eventos podem ser enviados a um coletor externo. Posteriormente é possível analisar qual chave, por causa de qual regra, com qual ação e por quanto tempo foi colocada em quarentena.
O número de chaves ativas e o tipo de chave afetam o consumo de memória. Chaves baseadas em IP são mais enxutas; chaves combinadas como Host+IP+user agent consomem mais espaço. Como são suportadas 5 regras de quarentena paralelas por vService, o plano de capacidade deve ser feito conforme o perfil de tráfego.
Um site de e-commerce pode monitorar com a chave `ipUa` as fontes que fazem scraping de preços. A combinação IP+user agent que ultrapassa 100 requisições em 5 minutos é bloqueada por 30 minutos; diferentes usuários reais por trás do mesmo IP podem ser avaliados como chaves separadas.
Um portal bancário pode monitorar tentativas repetidas no endpoint de login por IP ou IP+user agent. Quando o limite é ultrapassado, a fonte é levada por 60 minutos a uma página explicativa e o motivo da restrição temporária é mostrado ao usuário real.
Uma plataforma SaaS que hospeda múltiplos domínios pode monitorar separadamente o tráfego de cada tenant com a chave `hostIp`. O uso agressivo de um tenant pode ser levado a uma ação de redirect ou bloqueio temporário sem afetar o tráfego dos demais tenants.
A primeira regra redireciona por 10 minutos a uma página de aviso a fonte que envia requisições em excesso. Se a fonte continuar gerando tráfego enquanto está em quarentena, a segunda regra entra em ação e aplica bloqueio por 60 minutos. O fato de o estado de quarentena ser condição em outras regras torna possível esse modelo gradual.
Isolamento temporário baseado em comportamento, estrutura de regras compostas e visibilidade do operador em tempo real. Vamos analisar juntos como funciona no seu próprio ambiente.