Tem uma aplicação web num VPS. O registo de acessos mostra tentativas de login em /wp-admin, pedidos com UNION SELECT na query string e tráfego constante de gamas de IP de datacenters que nada têm a fazer no seu site. Quer filtrar o lixo óbvio antes que chegue à sua aplicação.
É neste momento que a maioria das pessoas encontra o termo WAF SaaS. Para muitos leitores, «o WAF» e «Cloudflare» são a mesma coisa, porque Cloudflare foi o primeiro que apareceu. Não são a mesma coisa. WAF SaaS é uma categoria: uma firewall de aplicações web entregue a partir da cloud, que inspeciona o seu tráfego HTTP na edge do fornecedor antes de o encaminhar para a sua origem. A Cloudflare é um produto dentro dessa categoria.
Este artigo percorre o funcionamento do WAF SaaS, o que cobram os principais fornecedores, onde falha na prática e quando executar o seu próprio WAF num VPS Linux é a melhor opção.
TL;DR
- O WAF SaaS é uma firewall de aplicações web entregue a partir da cloud. Encaminha o tráfego pelo fornecedor ou associa a WAF a um recurso cloud suportado; o serviço avalia os pedidos HTTP(S) antes de a aplicação protegida os processar.
- Os grandes fornecedores usam três formas gerais de preço: escalões de subscrição (Cloudflare e Sucuri), faturação por utilização (AWS WAF) e orçamentos comerciais (Imperva e Fastly). Os custos por utilização sobem com os pedidos processados e com as funcionalidades opcionais, ao passo que os planos de subscrição são em geral mais previsíveis.
- Existe uma crítica documentada ao WAF SaaS, e é abordada mais abaixo. Aponta para a latência, os falsos positivos, os bloqueios opacos e o encaminhamento de dados por terceiros.
- As WAF em self-hosting num VPS são uma opção real. SafeLine e BunkerWeb são os dois projetos open source com dinâmica atual. Funcionam como proxy inverso à frente da sua aplicação.
- Não usar WAF pode ser uma escolha defensável quando a segurança aplicacional é madura, a exposição está controlada, a monitorização é sólida e o risco remanescente está documentado e aceite.
Como funciona o WAF SaaS
Um pedido para example.com chega primeiro à edge do fornecedor, porque o seu DNS aponta para lá. O nó de edge termina o TLS, analisa o pedido HTTP, passa-o por um motor de regras e depois encaminha-o para a sua origem, bloqueia-o, desafia-o (CAPTCHA, teste JavaScript) ou limita a taxa da origem. Se o encaminhar, a sua aplicação vê o pedido como se viesse do IP do fornecedor, com o IP do cliente original transmitido num cabeçalho como X-Forwarded-For ou CF-Connecting-IP.
Muitos produtos WAF SaaS usam um proxy inverso gerido pelo fornecedor ou uma integração na edge, mas nem todos os serviços são implementados através de uma alteração de DNS. Cloudflare, Sucuri e Fastly ficam habitualmente no caminho do pedido, na edge. Já o AWS WAF é associado ao CloudFront ou a recursos AWS suportados como Application Load Balancers, APIs do API Gateway e APIs AppSync. Em todos os casos, os pedidos HTTP(S) são avaliados antes de a aplicação protegida os processar.
Uma WAF inspeciona dados da camada 7, como cabeçalhos de pedido, caminhos, query strings, métodos, cookies e a porção configurada dos corpos de pedido. Uma firewall de rede tradicional decide sobretudo nas camadas 3 e 4, usando endereços, protocolos e portas. O nosso guia de firewall de hardware vs software cobre a distinção mais ampla.
A proteção WAF gerida costuma beber de três fontes de regras:
- O OWASP Core Rule Set (CRS) é uma base open source para o ModSecurity e motores WAF compatíveis. Cobre categorias de ataque comuns como injeção de SQL, cross-site scripting, injeção de comandos e inclusão de ficheiros locais. Os produtos construídos sobre o ModSecurity costumam incluir o CRS, ao passo que muitos fornecedores cloud usam regras geridas proprietárias.
- Os conjuntos de regras geridos pelo fornecedor são regras proprietárias que ele mantém atualizadas. As «Managed Rules» da Cloudflare, as «AWS Managed Rules» do AWS WAF e o feed de threat intelligence da Imperva encaixam aqui.
- As regras personalizadas são as que escreve você. «Bloquear pedidos para /admin que não venham desta gama de IP», «limitar /api/login a 5 por minuto por IP».
Uma regra de injeção de SQL pode sinalizar um padrão conhecido como ' OR 1=1 -- num parâmetro de query ou no corpo do pedido. Isso apanha as sondagens preguiçosas, mas uma WAF continua a poder falhar payloads ofuscados, falhas de lógica e pedidos maliciosos que se parecem com tráfego normal da aplicação. Avalia sinais observáveis do pedido, não a intenção de negócio.
Contra o que protege, em termos simples:
- Ataques de injeção cujo payload corresponde a uma assinatura conhecida
- Tráfego de bots proveniente de scanners conhecidos
- Padrões simples de força bruta
- DDoS volumétrico, quando o fornecedor também faz scrubbing de DDoS
- Abuso básico de API
O que não faz:
- Corrigir a sua aplicação
- Substituir a validação de entradas no seu código
- Travar ataques que se parecem com tráfego normal
A segurança aplicacional continua a vir da aplicação. Uma WAF sobe o chão face a ataques comuns e automatizados, mas é o código seguro, o patching, a autorização, o tratamento de entradas, a monitorização e a resposta a incidentes que define o teto.
WAF SaaS vs appliance on-premise vs self-hosting num VPS
Em 2026 há três modelos comuns de implementação de WAF: WAF SaaS na cloud (Cloudflare, AWS WAF, Fastly e outros), appliances físicos ou virtuais (incluindo as ofertas da F5 e da Imperva) e software em self-hosting num VPS ou no seu próprio servidor.
Os três diferem em quatro perguntas práticas: quem opera o plano de inspeção, quem paga a capacidade, quem afina as regras e o que acontece quando a WAF bloqueia algo que não devia. O resto do artigo usa estas quatro como grelha de comparação.
WAF SaaS na cloud
Encaminha o tráfego pela edge do fornecedor ou associa a WAF a um recurso cloud suportado. O fornecedor opera a capacidade de inspeção e as atualizações geridas, enquanto você seleciona regras, cria políticas específicas da aplicação e afina exceções. Entre as opções comuns estão Cloudflare, AWS WAF, Imperva, Sucuri e Fastly.
O compromisso: a capacidade e a operação são problema de outra pessoa. Mas cada pedido HTTP também passa pela infraestrutura de outra pessoa. O seu tráfego HTTP atravessa a infraestrutura do fornecedor, e metadados de pedido ou excertos de payload detetados podem ser registados consoante o fornecedor, o produto e as definições de registo.
WAF em appliance on-premise
Um appliance físico ou virtual fica no caminho da sua rede. Os compradores são normalmente organizações com operações de segurança de rede consolidadas, requisitos de capacidade fixa, controlos de implementação rígidos ou relações já existentes com fornecedores. A capacidade, as atualizações, a alta disponibilidade e a afinação continuam a cargo do cliente.
Para muitas equipas pequenas e médias, a aquisição do appliance, a capacidade fixa e a carga operacional tornam este o caminho menos prático. Ainda assim, pode encaixar em organizações que precisam de um plano de controlo dentro da rede e têm pessoal para o operar.
WAF em self-hosting no seu próprio VPS
Instala uma WAF num VPS Linux, aponta o seu DNS para esse VPS e a WAF fica como proxy inverso à frente da sua aplicação. É você que a opera. É você que a afina. É você que entra às 2 da manhã quando uma atualização de regras geridas bloqueia um pedido legítimo e não há mais ninguém a quem ligar.
Dois projetos open source têm dinâmica atual: SafeLine, uma WAF open source que usa um motor de análise semântica em vez de simples correspondência por expressões regulares, e BunkerWeb, uma WAF baseada em NGINX que integra o ModSecurity. As licenças, modelos de implementação e consumo de recursos aparecem mais à frente, na secção de self-hosting.
O compromisso é o inverso do modelo SaaS. Você controla o plano de inspeção, a capacidade, os registos e a afinação. Isso reduz a dependência de um fornecedor WAF externo, mas as redes upstream e os alojadores continuam a transportar o tráfego. Os limites de infraestrutura, a largura de banda, o patching e a resposta a incidentes passam a ser seus.
WAF SaaS vs WAF em self-hosting no seu VPS
A tabela comparativa abaixo foca-se nas diferenças práticas que os administradores de sistemas têm de operar e orçamentar.
| Critérios | WAF SaaS na cloud | WAF em self-hosting num VPS |
|---|---|---|
| Quem opera o plano de inspeção | O fornecedor, na edge da rede | Você, no seu VPS |
| Quem paga a capacidade | O fornecedor, que lha refatura por subscrição ou por pedido | Você, custo fixo do VPS |
| Quem afina as regras | Você configura; o fornecedor entrega as atualizações das regras geridas | Você, de ponta a ponta |
| Recurso perante falsos positivos | Afinar regras e exceções dentro dos controlos do fornecedor; escalar os problemas de plataforma | Editar a regra você mesmo; reimplementar em minutos |
| Encaminhamento de dados | Os pedidos passam pela infraestrutura de inspeção do fornecedor | Os pedidos passam por infraestrutura que você controla antes de chegarem à origem |
| Como se comporta o custo num pico de tráfego | As componentes por utilização podem subir com o volume de pedidos | Normalmente mais previsível, mas a largura de banda e o escalonamento ainda podem acrescentar custo |
| Carga operacional | Baixa, limitada à configuração e à afinação | É você que opera o VPS e a WAF |
Preços de WAF SaaS em 2026
Os preços de WAF SaaS costumam combinar escalões de subscrição, encargos por utilização ou orçamentos comerciais. Os preços públicos não são diretamente comparáveis porque cada fornecedor empacota de forma diferente as regras geridas, os controlos de bots, o registo, o suporte e as funcionalidades anti-DDoS.
| Provedor | Modelo de preços | Preço de entrada | O que inclui o escalão de entrada | Notas |
|---|---|---|---|---|
| Cloudflare | Escalão de subscrição | Gratuito; Pro 20 $/mês anual ou 25 $/mês mensal; Business 200 $/mês anual ou 250 $/mês mensal | Free Managed Ruleset; os controlos mais amplos variam consoante o plano pago | Verifique as regras, os limites e as funcionalidades de segurança incluídas antes de comprar |
| AWS WAF | Por pedido | $5 per web ACL/month plus $1 per rule or rule group/month plus $0.60 per million requests | Regras geridas por si; as AWS Managed Rules podem ser adicionadas como grupos de regras geridas | Capacidade extra, inspeção do corpo, grupos geridos premium, CAPTCHA, Challenge, Bot Control e Fraud Control podem acrescentar encargos |
| Imperva | Orçamento empresarial | Contactar vendas | Regras geridas, threat intelligence e opções de segurança de API | Sem preço público de WAF self-service diretamente comparável |
| Sucuri Platform | Escalão de subscrição | Basic Firewall 9,99 $/mês; Basic Platform 229 $/ano | Plano firewall: WAF/CDN; o pacote Platform acrescenta análise e limpeza | A firewall autónoma e o pacote Platform anual são produtos diferentes |
| Fastly | Através da equipa comercial | Contactar vendas | Inspeção na edge ou distribuída, regras geridas e proteção de API | Sem preço público de WAF self-service diretamente comparável |
O AWS WAF publica preços por componente, ao passo que Cloudflare e Sucuri publicam preços de planos self-service. Imperva e Fastly usam preços via equipa comercial para ofertas WAF comparáveis.
Verificado a 29 de julho de 2026: a página de planos da Cloudflare indica o Pro a 20 $ por mês com faturação anual ou 25 $ com faturação mensal, e o Business a 200 $ por mês anual ou 250 $ mensal. A página de preços da firewall Sucuri lists Basic Firewall at $9.99 per month and Basic Platform at $229 per year. The firewall and platform bundles are different products. The AWS WAF figures above come from os preços do AWS WAF as of the same date.
A Imperva e a Fastly não publicam preços de WAF self-service diretamente comparáveis, por isso trate ambas como opções de contactar a equipa comercial em vez de confiar em estimativas de terceiros.
A página de preços do AWS WAF indica encargos base de 5 $ por web ACL por mês, 1 $ por regra ou grupo de regras por mês e 0,60 $ por milhão de pedidos processados. Podem aplicar-se encargos adicionais por capacidade extra, inspeção de corpo maior, ações CAPTCHA ou Challenge, grupos geridos premium e controlos de fraude ou de bots. O tráfego de ataque pode, portanto, aumentar a fatura, mas o impacto depende do volume, da duração e das funcionalidades ativadas. As regras baseadas em taxa protegem a aplicação; não tornam gratuitos os pedidos WAF já processados.
Onde o WAF SaaS fica aquém
Os falsos positivos são a primeira limitação prática. Um upload legítimo, uma chamada de API ou o envio de um formulário podem parecer um padrão de ataque e disparar uma regra gerida. O operador tem então de identificar a regra que fez correspondência, estreitá-la ou excluí-la, e confirmar que a exceção não cria um bypass mais amplo.
As WAF decidem a partir de sinais do pedido, não da intenção de negócio. Regras estritas podem bloquear tráfego legítimo; exceções amplas podem enfraquecer a proteção. Os serviços cloud costumam disponibilizar registos de eventos, substituições de regras e respostas personalizadas, mas a visibilidade e os controlos de afinação variam consoante o plano e o fornecedor.
Dica de profissional. Arranque as regras novas ou alteradas de forma significativa em modo deteção ou contagem. Observe tráfego representativo, teste os fluxos críticos e os pouco frequentes, reveja os falsos positivos e acrescente exclusões bem delimitadas antes de ativar o bloqueio. As orientações atuais de afinação do CRS recomendam uma a duas semanas, ou até que o tráfego de pico e os fluxos críticos tenham sido exercitados.
A segunda limitação é a sobrecarga de desempenho. Um benchmark do ModSecurity de 2023 mediu 9.462 uploads de ficheiros pequenos em 7,36 segundos com o CRS ativado, contra 4,55 segundos sem ele. O débito caiu de 2.079 para 1.285 pedidos por segundo, enquanto o pico de CPU do nginx subiu de 8 % para 73 %. Era uma única configuração e uma única carga de trabalho, por isso encare-o como prova de que a inspeção tem um custo, não como um rácio universal de dimensionamento.
A terceira limitação é o encaminhamento de dados. Cada pedido HTTP, corpo incluído, passa pela infraestrutura do fornecedor. Para aplicações que lidam com dados pessoais, transações financeiras ou dados de saúde, esta é uma questão concreta de soberania de dados. Uma aplicação alojada na UE que encaminha os pedidos dos clientes por um fornecedor WAF norte-americano tem um rasto de auditoria mais difícil de justificar, e mais algumas cláusulas contratuais para aceitar, do que a mesma aplicação com um proxy inverso em self-hosting num VPS na mesma jurisdição.
A quarta limitação é a carga de afinação. Os desafios de afinar uma WAF incluem os falsos positivos, o contexto aplicacional limitado e as regras que têm de acompanhar mudanças frequentes no código. A fonte é a perspetiva de um fornecedor, mas o padrão operacional é real: ou as equipas investem em afinação contínua, ou deixam mais regras em modo apenas deteção.
Essa mesma crítica de 2023 defende que as WAF podem tornar-se teatro de segurança quando as equipas se apoiam nelas em vez de corrigir a aplicação. O argumento é mais forte para equipas com segurança aplicacional madura: acesso parametrizado à base de dados, autorização sólida, análise regular de dependências, implementações imutáveis e monitorização eficaz. Em ambientes menos maduros, uma WAF pode ainda assim reduzir a exposição a sondagens automatizadas comuns. Ambas as coisas podem ser verdade.
As WAF são uma camada de defesa em profundidade. Não substituem a segurança aplicacional, e também não são teatro de segurança. O valor marginal de uma WAF é alto para algumas equipas e baixo para outras. O que decide é o estado da aplicação por baixo.
Quando faz sentido fazer self-hosting de uma WAF
O self-hosting ganha em três situações. Perde noutras três. Comecemos pelas que ganha.
O self-hosting ganha quando restrições de política ou de soberania de dados excluem a inspeção por um intermediário WAF SaaS externo, quando os padrões de tráfego tornam o preço por utilização menos atrativo do que operar infraestrutura dedicada, e quando uma equipa quer controlo direto sobre as decisões de bloqueio e sobre a correção de falsos positivos.
O self-hosting perde quando não há capacidade operacional, quando a aplicação vive numa plataforma gerida cujo modelo de encaminhamento torna um proxy externo incómodo, ou quando um escalão gratuito gerido pelo fornecedor já cobre os controlos necessários com menos complexidade.
O plano gratuito da Cloudflare pode ser um ponto de partida prático para equipas pequenas e médias que já usam o seu DNS ou a sua CDN e aceitam o seu modelo de inspeção de tráfego. O self-hosting torna-se mais atrativo quando o encaminhamento de dados, o controlo direto das regras ou custos de infraestrutura previsíveis pesam mais do que minimizar a operação.
SafeLine e BunkerWeb
Vale a pena conhecer duas WAF open source para self-hosting.
O SafeLine é licenciado sob GPL-3.0, implementa-se com Docker Compose e assenta em análise semântica em vez de um conjunto de regras CRS puro. O repositório do SafeLine reporta 71,65 % de deteção, 0,07 % de falsos positivos e 99,45 % de precisão global em modo Balance, na sua própria avaliação de 33.669 amostras. São medições dos mantenedores do projeto, não um benchmark independente, e não devem ser generalizadas para lá desse conjunto de testes.
O BunkerWeb é licenciado sob AGPL-3.0 e usa NGINX por baixo. Integra o ModSecurity com o OWASP Core Rule Set e suporta vários modelos de implementação, incluindo Linux, Docker, Swarm e Kubernetes.
Dimensione qualquer um dos projetos a partir de um volume de pedidos medido, das proteções ativadas, do trabalho de TLS e da retenção de registos. Para uma implementação SafeLine de baixo tráfego, 2 vCPU e 4 GB de RAM são um ponto de partida conservador, com folga acima do mínimo de instalação. As orientações atuais do quickstart do BunkerWeb recomenda pelo menos 2 vCPU e 8 GB de RAM para testes ou muito poucos serviços, e 4 vCPU com 16 GB de RAM para ambientes de produção que protejam muitos serviços. O armazenamento depende sobretudo do ritmo de registos e da retenção: meça-o em vez de prometer um número fixo de meses.
Dica de profissional. Execute a WAF em self-hosting na mesma região que a origem da aplicação sempre que possível. Um proxy distante acrescenta uma ida e volta de rede inter-regional a cada pedido e pode degradar a latência sem dar nas vistas. Meça o tempo de resposta ponta a ponta a partir das regiões dos seus utilizadores antes da passagem para produção.
É você que opera a WAF, o que significa que a infraestrutura por baixo também é da sua responsabilidade: disponibilidade, correções de segurança, certificados TLS, cópias de segurança, rotação de registos, monitorização, capacidade e recuperação. Teste o comportamento em caso de falha com o mesmo cuidado que dá às regras de filtragem, para que a WAF não se torne um ponto único de falha.
Um Marco de Decisão
Existem quatro caminhos: o escalão gratuito da Cloudflare, uma WAF SaaS cloud paga, uma WAF em self-hosting num VPS e nenhuma WAF. A condição que escolhe cada um é diferente.
Escolha um escalão gratuito de WAF cloud quando as regras geridas e os limites disponíveis correspondem ao risco da aplicação, o modelo de encaminhamento de dados é aceitável e minimizar o trabalho operacional é a prioridade. Teste fluxos reais antes de assumir que os valores por omissão chegam.
Escolha uma WAF SaaS paga quando precisar de mais regras geridas, registo, controlos personalizados, proteção de bots ou de API, suporte ou capacidade do que o escalão gratuito oferece. Compare a matriz exata de funcionalidades e limites, não apenas o nome do plano. O AWS WAF brilha quando a aplicação já usa recursos AWS suportados e a equipa está à vontade a prever encargos por componente.
Escolha uma WAF em self-hosting quando se aplicarem as condições de self-hosting acima e a sua equipa souber operar o proxy de forma fiável. SafeLine e BunkerWeb são os dois projetos a avaliar primeiro.
Não usar WAF pode ser uma escolha defensável quando a segurança aplicacional é madura, a exposição está deliberadamente controlada, a monitorização é sólida e o risco residual está documentado e aceite. Não deve tornar-se a opção por omissão só porque uma framework valida entradas.
Conclusão
Escolha WAF SaaS pela capacidade gerida pelo fornecedor e por menos carga operacional. Escolha o self-hosting pelo controlo direto, quando a equipa souber operar o proxy de forma fiável. Em qualquer dos modelos: implemente as regras por fases, meça a latência e os falsos positivos, e mantenha a segurança aplicacional em primeiro lugar.
Se o self-hosting encaixa nos seus requisitos, comece com um Linux VPS na mesma região que a origem. A Cloudzy também disponibiliza implementações de marketplace com um clique para SafeLine e para BunkerWeb, para que possa começar a testar sem montar a stack base à mão.
Construa num VPS Linux com acesso root, NVMe e o poder do AMD EPYC.
Ver planos LinuxPerguntas frequentes
O que é WAF as a service?
O WAF as a service é uma firewall de aplicações web entregue a partir da cloud. O tráfego chega ao serviço por encaminhamento DNS ou proxy inverso, por integração na edge ou por associação a um recurso cloud suportado. O fornecedor opera a capacidade de inspeção e as atualizações geridas; você escolhe políticas, afina exceções e acrescenta regras específicas da aplicação.
A Cloudflare é uma WAF?
Sim. A Cloudflare fornece funcionalidades de WAF como parte de uma plataforma de edge mais ampla, que inclui também DNS, CDN e proteção DDoS. Os planos gratuitos recebem o Cloudflare Free Managed Ruleset; conjuntos de regras mais amplos, controlos, análises e gestão de bots dependem do plano escolhido e dos extras.
A WAF gratuita da Cloudflare chega?
Depende da superfície de ataque da aplicação, das regras necessárias, das necessidades de registo e retenção, dos controlos de API ou de bots, dos requisitos de suporte e da sua tolerância a falsos positivos. O Free Managed Ruleset pode ser uma base útil, mas autenticação, pagamentos ou dados regulados não correspondem automaticamente a um plano pago concreto. Compare os limites de funcionalidades atuais e valide-os face ao seu modelo de ameaças.
Qual é a diferença entre uma WAF e uma firewall?
Uma firewall de rede tradicional filtra o tráfego sobretudo com informação das camadas 3 e 4: endereços, protocolos e portas. Uma WAF avalia pedidos HTTP(S) da camada 7, incluindo cabeçalhos, caminhos, parâmetros e conteúdos de corpo configurados. Os produtos de segurança modernos podem esbater estas fronteiras, mas os dois controlos continuam complementares e não intermutáveis.
O que é WAAP e em que difere de uma WAF?
WAAP significa Web Application and API Protection. É mais amplo do que uma WAF tradicional: os fornecedores costumam combinar regras WAF com descoberta ou imposição de políticas de API, gestão de bots e controlos de DDoS ou de abuso na camada aplicacional. O pacote exato varia consoante o fornecedor, por isso o WAAP não deve ser tratado como um conjunto padronizado de funcionalidades.
Preciso de uma WAF se a minha framework já valida as entradas?
Nem sempre. Os controlos da framework reduzem o risco, mas não cobrem todos os padrões de abuso automatizado. Acrescente uma WAF apenas quando esta responder a um risco definido que justifique o seu custo e a sua afinação.
