Preciso mudar algo no meu deploy ou no meu código?

Não. A ativação é por anúncio BGP, na rede: não há agente, SDK, middleware ou variável de ambiente a adicionar. Pipeline, balanceador e aplicação continuam como estão.

Funciona se eu estiver em cloud pública?

Depende de você anunciar prefixos próprios por BGP. Se a sua operação usa só endereçamento do provedor de nuvem, o desenho muda e é avaliado caso a caso. Fale com a engenharia antes de assumir qualquer resposta.

A proteção cobre HTTP flood contra a minha API?

Não neste escopo. HTTP flood e abuso de API são camada de aplicação, tratada por WAF e por bot management, que são produtos separados. Esta proteção absorve o volume que saturaria o link; sem ela, o WAF não recebe a requisição.

E o meu ambiente de staging?

Está coberto se estiver dentro do bloco anunciado. A proteção é por rede, não por hostname: não há lista de domínios a cadastrar nem inventário a manter.

O que exatamente entra sob proteção?

A unidade de proteção é o bloco /24 IPv4. Tudo o que estiver atrás do prefixo anunciado está coberto: site, portal, API, DNS, VoIP, VPN, painel interno — inclusive serviço que você ainda não publicou. Para empresas que anunciam vários blocos, o escopo pode ser o ASN completo, com todos os prefixos.

Preciso instalar algo na minha infraestrutura?

Nenhum hardware e nenhum agente. A proteção acontece na rede, antes de o pacote chegar até você. Também não há terminação de TLS nem inspeção de payload: a sua chave privada não sai do seu lado.

O que acontece com a latência?

O tráfego passa pela mitigação em São Paulo, em Equinix SP2 ou Ascenty SP3, antes de chegar até você. Em túnel GRE existe o overhead de encapsulamento e o MTU precisa de ajuste. Em cross-connect o circuito é direto, sem encapsulamento no caminho.

Quanto tempo leva a ativação?

A ativação começa quando o handoff está pronto e inclui a sessão BGP, o anúncio dos prefixos e um teste de desvio controlado antes do go-live. O prazo do handoff depende da forma escolhida: GRE não exige circuito novo, enquanto cross-connect segue o prazo do data center. Peça o prazo do seu cenário à engenharia na qualificação.

DDoS Defense · SaaS e tecnologia

Proteção DDoS para plataformas e SaaS

O seu SLA não pergunta de quem foi a culpa. Ele só conta os minutos.

Mitigação de rede para quem vende disponibilidade como produto. O ataque volumétrico é absorvido antes de consumir o seu link, sem agente na aplicação e sem mudança no deploy.

Falar com a engenharia

Empresas que confiam na UPX

Controles auditados

O risco

Indisponibilidade é o seu produto falhando

Em SaaS, o contrato com o cliente tem um número de disponibilidade. Quando o link satura, o cliente não distingue um ataque de uma falha sua: o painel dele está fora.

Quando o prefixo fica inacessível, não é o site que sai do ar.

O compromisso de SLA

Cada minuto fora conta no indicador contratado e no crédito que ele gera. O crédito é só a parte mensurável do custo.

A API que outros produtos consomem

Se a sua plataforma é dependência de outra, a indisponibilidade se propaga. O incidente passa a ser investigado por vários times.

Webhook e integração

Entrega que falha gera fila, retentativa e inconsistência de estado para resolver depois do ataque.

Onboarding e trial em curso

Quem avalia o produto durante o ataque dificilmente faz uma segunda tentativa.

Exposição

Escalar não resolve saturação de link

A reação natural de um time de engenharia é escalar. Mas mais instâncias atrás de um circuito saturado continuam inalcançáveis: o gargalo é a banda de entrada.

Autoescala dispara, custa e não devolve o serviço
Health check falha e remove instância saudável do balanceador
A fila de retentativa cresce e prolonga o incidente depois do ataque

Nas três janelas a mitigação já está ativa: o tráfego entra pela rede da UPX e a filtragem parte da detecção, sem acionamento.

A proteção, traduzida para a sua operação.

A oferta técnica é a mesma do resto do pilar. O que muda é o que ela significa aqui.

O ataque não chega ao seu balanceador
A filtragem acontece na rede da UPX, em Equinix SP2 e Ascenty SP3. O seu ingress recebe o tráfego já filtrado.
Nada na aplicação
Cobertura sem inventário
Dado para o post-mortem

Como funciona

Quatro etapas, nenhuma dentro da sua rede.

A ativação é por anúncio BGP: sem hardware no seu rack, sem agente na aplicação e sem redesenho de rede. Você continua dono dos prefixos e da política de roteamento.

01
Anúncio BGP
Os seus prefixos passam a ser anunciados pela rede da UPX.
02
Desvio do tráfego
Todo o tráfego de entrada dos prefixos passa pela rede da UPX.
03
Filtragem
O ataque é filtrado na rede da UPX, antes de consumir o seu link.
04
Tráfego filtrado
O tráfego filtrado é devolvido à sua infraestrutura.

Ver a arquitetura completa

Conformidade e evidência

O que o seu cliente enterprise vai perguntar

Na due diligence de fornecedor, a pergunta sobre proteção de disponibilidade vem junto com criptografia e segregação de ambiente. Estas são as respostas objetivas.

Mecanismo de mitigação

Mitigação em nuvem por anúncio BGP, com 98 Tbps de capacidade de mitigação e dupla mitigação física em São Paulo: Equinix SP2 e Ascenty SP3.

Tempo de resposta

Mitigação automática a partir da detecção, sem abertura de chamado. O SOC da UPX acompanha a campanha e o contato é direto com a engenharia.

Evidência por incidente

Relatório e ticket automáticos por campanha, com histórico consultável na plataforma.

Tratamento de dado

Sem terminação de TLS e sem inspeção de payload: a mitigação atua em cabeçalho de rede e transporte.

Começar

Fale com a engenharia

A engenharia que opera a rede responde com o handoff recomendado e a proposta para a sua operação.

Está sofrendo um ataque DDoS?

Se sua operação está sob ataque, fale diretamente com nossa equipe para solicitar atendimento emergencial.

Solicitar atendimento emergencial

Perguntas frequentes

Dúvidas de quem opera neste segmento.

Preciso mudar algo no meu deploy ou no meu código?
Não. A ativação é por anúncio BGP, na rede: não há agente, SDK, middleware ou variável de ambiente a adicionar. Pipeline, balanceador e aplicação continuam como estão.
Funciona se eu estiver em cloud pública?
Depende de você anunciar prefixos próprios por BGP. Se a sua operação usa só endereçamento do provedor de nuvem, o desenho muda e é avaliado caso a caso. Fale com a engenharia antes de assumir qualquer resposta.
A proteção cobre HTTP flood contra a minha API?
Não neste escopo. HTTP flood e abuso de API são camada de aplicação, tratada por WAF e por bot management, que são produtos separados. Esta proteção absorve o volume que saturaria o link; sem ela, o WAF não recebe a requisição.
E o meu ambiente de staging?
Está coberto se estiver dentro do bloco anunciado. A proteção é por rede, não por hostname: não há lista de domínios a cadastrar nem inventário a manter.
O que exatamente entra sob proteção?
A unidade de proteção é o bloco /24 IPv4. Tudo o que estiver atrás do prefixo anunciado está coberto: site, portal, API, DNS, VoIP, VPN, painel interno — inclusive serviço que você ainda não publicou. Para empresas que anunciam vários blocos, o escopo pode ser o ASN completo, com todos os prefixos.
Preciso instalar algo na minha infraestrutura?
Nenhum hardware e nenhum agente. A proteção acontece na rede, antes de o pacote chegar até você. Também não há terminação de TLS nem inspeção de payload: a sua chave privada não sai do seu lado.
O que acontece com a latência?
O tráfego passa pela mitigação em São Paulo, em Equinix SP2 ou Ascenty SP3, antes de chegar até você. Em túnel GRE existe o overhead de encapsulamento e o MTU precisa de ajuste. Em cross-connect o circuito é direto, sem encapsulamento no caminho.
Quanto tempo leva a ativação?
A ativação começa quando o handoff está pronto e inclui a sessão BGP, o anúncio dos prefixos e um teste de desvio controlado antes do go-live. O prazo do handoff depende da forma escolhida: GRE não exige circuito novo, enquanto cross-connect segue o prazo do data center. Peça o prazo do seu cenário à engenharia na qualificação.