Tipos de firewall: os três eixos que definem qual serve para a sua rede

Autor: Pedro Tebaldi PM do KeepGreen

Publicado ago/2026

Quase toda comparação de firewall começa errada. Ela alinha filtro de pacotes, NGFW, UTM e firewall de nuvem lado a lado, numerados de 1 a 6. No entanto, esses seis itens não são produtos concorrentes na mesma prateleira.

Um NGFW é, por definição, um firewall de inspeção de estado. Além disso, ele pode chegar como appliance na sala de racks ou como instância em uma VPC. Portanto, comparar NGFW com firewall de nuvem equivale a comparar motor com carroceria.

Este guia separa o assunto nos três eixos que realmente decidem a compra. Em seguida, entra na parte que nenhum comparativo cobre: o que cada tipo passa a exigir da operação depois de entrar em produção.

Quais são os tipos de firewall

Os tipos de firewall se organizam por método de inspeção, por pacote comercial e por posição na arquitetura. Estas são as seis categorias presentes em qualquer especificação técnica:

Filtro de pacotes (stateless): avalia cada pacote isoladamente por IP de origem, IP de destino, porta e protocolo.

Inspeção de estado (stateful): mantém uma tabela de conexões ativas e derruba pacotes fora da sequência esperada.

Gateway de aplicação (proxy): encerra a conexão, lê o conteúdo na camada 7 e abre uma segunda conexão até o destino.

NGFW: soma inspeção de estado, identificação por aplicação, IPS e inspeção profunda de pacotes.

UTM: reúne firewall, antivírus, filtro de conteúdo, antispam e VPN em um appliance e um contrato.

WAF: protege aplicações web contra injeção de SQL, cross-site scripting e abuso de sessão.

Cada uma dessas categorias responde a uma pergunta diferente. Por isso, colocá-las na mesma lista numerada produz a confusão que a próxima seção desfaz.

Por que a lista única não fecha a comparação

Existem três perguntas independentes por trás da escolha. Elas se combinam livremente. Ou seja: é justamente essa combinação que a lista numerada esconde.

A primeira pergunta é como o equipamento decide o que passa. A segunda é o que o fabricante embala na mesma caixa. Por fim, a terceira é onde ele fica e qual superfície protege.

Assim, todo firewall real responde às três ao mesmo tempo. Um FortiGate em modo UTM, na borda do datacenter, é stateful no eixo 1. Ao mesmo tempo, é UTM no eixo 2 e firewall de rede no eixo 3. Trocar UTM por NGFW mexe apenas no segundo eixo.

Quando a especificação trata os eixos como uma lista só, o time compra dois produtos para o mesmo problema. Pior ainda: acredita ter coberto a aplicação web porque instalou um NGFW na borda.

Eixo 1: como o firewall decide o que passa

Este eixo determina em que camada do tráfego a decisão acontece. Consequentemente, ele também determina o custo de processamento, porque ler mais fundo consome mais ciclo de CPU e mais latência.

Filtro de pacotes: rápido e sem memória

O filtro de pacotes trabalha nas camadas 3 e 4. Isto é: compara cada pacote contra a lista de regras, sem lembrar do que passou antes.

Segundo a publicação especial 800-41 do NIST, essa ausência de estado separa o filtro simples dos mecanismos posteriores.

Na prática, ele sobrevive hoje como ACL de roteador e como security group de nuvem. Assim, continua útil onde a regra é trivial e o volume é alto. Entretanto, ele não distingue uma resposta legítima de um pacote forjado que finge ser resposta.

Inspeção de estado: o padrão de mercado

A inspeção de estado guarda uma tabela de conexões abertas. Dessa forma, o equipamento sabe que aquele pacote de retorno pertence a uma sessão iniciada de dentro. Ele acompanha o handshake de três vias do TCP e descarta o que chega fora de ordem.

Todo firewall corporativo vendido hoje é stateful. Vale destacar esse ponto: quando um fornecedor oferece NGFW, ele oferece um stateful com camadas adicionais, não uma alternativa a ele.

O custo aparece na tabela de estado. Ela ocupa memória, tem limite de entradas e satura sob ataque volumétrico. Por isso, esse limite entra na lista dos primeiros indicadores a acompanhar depois da instalação.

Gateway de aplicação: lê o conteúdo, cobra em latência

O proxy, ou gateway de aplicação, encerra a conexão do cliente e abre outra até o servidor. Como ele vê o conteúdo inteiro, consegue bloquear um comando específico dentro do protocolo. A porta deixa de ser o único critério.

Em contrapartida, ele dobra o número de conexões e adiciona latência mensurável. Além disso, precisa de um módulo por protocolo. Logo, a maioria das arquiteturas reserva o proxy para saída web e protocolos sensíveis.

Gateway de nível de circuito: o menos comum

Este tipo valida o estabelecimento da sessão na camada 5. Depois disso, libera o fluxo sem inspecionar conteúdo. SOCKS, por exemplo, é o caso clássico.

Ele aparece em quase toda lista por tradição. Todavia, raramente vira uma decisão de compra isolada em 2026, porque hoje existe embutido em produtos maiores. Para situar cada mecanismo, vale revisar as camadas do modelo OSI.

Eixo 2: o que o fabricante embala na mesma caixa

Este eixo não trata de tecnologia de inspeção. Ele trata de empacotamento comercial. Nesse sentido, concentra a maior parte das dúvidas de compra.

NGFW: profundidade e controle por aplicação

O NGFW acrescenta ao stateful a identificação da aplicação independentemente da porta. Por exemplo, ele reconhece que o tráfego na porta 443 é um serviço de armazenamento em nuvem, não apenas HTTPS genérico. Somado a isso, traz IPS integrado e inspeção TLS.

Recentemente, o mercado mudou o nome da própria categoria. Em agosto de 2025, o Gartner publicou o primeiro quadrante mágico da categoria Hybrid Mesh Firewall. Ela cobre múltiplos formatos de implantação sob um plano de gestão único em nuvem. Em resumo: o mercado parou de classificar por caixa.

UTM: várias funções, um contrato

Já o UTM entrega firewall, antivírus de borda, filtro de URL, antispam e concentrador de VPN no mesmo appliance. A vantagem real não é técnica. Ou seja, ela é operacional: uma renovação, um fornecedor, uma interface, um time para treinar.

Em contrapartida, a desvantagem também é operacional. Ligar todos os módulos derruba o throughput anunciado, às vezes pela metade. Afinal, o número do datasheet quase sempre pressupõe inspeção mínima.

NGFW ou UTM: o critério que decide

O critério não é o porte da empresa, apesar de o mercado repetir isso. O critério é quantas políticas distintas a rede precisa expressar.

Se o ambiente exige segmentação fina, regras por identidade de usuário e integração com o pipeline de deploy, o NGFW paga o preço. Por outro lado, quando a necessidade é cobrir muitas funções com equipe pequena, o UTM entrega mais por real investido. Assim, uma filial com 40 pessoas e um datacenter com 400 servidores justificam escolhas opostas na mesma empresa.

Eixo 3: onde ele fica e o que protege

O terceiro eixo trata de posição na arquitetura. Aqui, os tipos convivem, porque quase nenhuma empresa opera apenas um.

Firewall de rede, de host e de nuvem

Na fronteira entre segmentos, o firewall de rede concentra o tráfego norte-sul. Já o firewall de host roda dentro do servidor. Assim, ele costuma ser a única defesa contra movimento lateral depois que alguém já entrou.

O firewall de nuvem, por sua vez, aparece como security group ou appliance virtual e acompanha a instância. Essa distribuição sustenta a arquitetura zero trust. Nela, o perímetro deixa de ser um anel único e vira decisão tomada a cada conexão.

WAF: a camada da aplicação web

Já o WAF inspeciona HTTP e HTTPS e bloqueia padrões de ataque contra a aplicação. Um NGFW de borda não substitui essa função. Afinal, a requisição maliciosa chega em sessão TLS válida, na porta certa, vinda de um IP sem reputação ruim.

A recíproca também vale. Um WAF não protege o SSH exposto do servidor. Portanto, são camadas complementares, com telemetria distinta: veja o que acompanhar em um WAF em produção.

Firewall de contêiner e microssegmentação

Em ambientes com Kubernetes, o controle migra para network policies e para o service mesh. Nesse caso, o objeto que decide passa a ser o namespace ou o rótulo do pod. O endereço IP muda a cada reinício. Consequentemente, quem trata contêiner como sub-rede comum escreve regras que expiram sozinhas.

Tabela de decisão: qual tipo para qual problema

A tabela cruza os seis tipos com quatro perguntas que costumam ficar sem resposta nos comparativos. A saber: onde atua, o que enxerga, o que custa manter e quando ele é a escolha errada.

O que muda na operação depois que você escolhe

Aqui está a parte que os comparativos não contam. Cada tipo cria um conjunto próprio de sinais. Da mesma forma, cada um cria um ponto cego diferente quando ninguém olha.

O filtro de pacotes gera contagem de descarte por regra. Já o stateful gera ocupação da tabela de conexões. Essa métrica, inclusive, prevê saturação antes que o usuário perceba lentidão. O proxy gera latência por transação. Por sua vez, o NGFW gera decisão por aplicação e volume de bloqueio do IPS.

Essa diferença deixou de ser detalhe técnico. A Verizon mediu a virada na edição 2026 do seu relatório anual. Foi a primeira vez em 19 edições que a exploração de vulnerabilidades superou o roubo de credenciais.

Segundo o relatório de violações de dados, ela responde por 31% das violações. Só 26% das falhas críticas do catálogo CISA KEV foram corrigidas em 2025, contra 38% no ano anterior. O prazo mediano subiu para 43 dias.

Traduzindo para o perímetro: o equipamento que protege a rede virou alvo preferencial. Além disso, a janela entre a divulgação da falha e a correção continua se alargando. Sem coleta de versão, sem alerta de sessão saturada e sem detecção de ameaças a partir de logs, o equipamento vira uma caixa fechada. Ninguém sabe dizer se ele ainda funciona.

Por isso, a escolha do tipo precisa vir junto com a definição de quais indicadores o equipamento precisa expor. Sem visibilidade do tráfego que atravessa cada enlace, a regra escrita há dois anos segue valendo. Entretanto, ninguém consegue dizer o que ela ainda bloqueia.

Quatro erros de seleção que aparecem em produção

Por fim, os quatro padrões abaixo se repetem em ambientes que já passaram por uma troca de perímetro.

NGFW rodando como filtro de pacotes. A empresa compra a licença completa, mantém as regras antigas por IP e porta e, inclusive, nunca ativa o controle por aplicação. Ou seja, paga por camada 7 e opera em camada 4.

UTM subdimensionado. Antes de tudo, o appliance foi escolhido pelo throughput de firewall puro. Depois de ligar antivírus, filtro de conteúdo e inspeção TLS, o enlace começa a formar fila no horário de pico.

WAF tratado como substituto do perímetro. A aplicação web fica protegida. No entanto, serviços administrativos seguem expostos em portas altas, fora de qualquer inspeção.

Regra órfã acumulada. Cada projeto adiciona liberações. Em contrapartida, nenhum remove. Depois de alguns anos, a base tem centenas de regras que ninguém explica. Consequentemente, a revisão vira um risco maior que a manutenção do que já existe.

Onde a escolha realmente se paga

A pergunta que abre a maioria dos projetos, qual o melhor tipo de firewall, não tem resposta fora do contexto. A pergunta útil é outra. Isto é: quantas políticas distintas a rede precisa expressar, com que profundidade de inspeção, em quantos pontos da arquitetura.

Respondidas essas três, o tipo se define quase sozinho. Um ambiente com filiais, nuvem e aplicação web exposta nunca fica em um só. Ele combina stateful na borda, host firewall nos servidores críticos, WAF na frente da aplicação e política nativa na nuvem.

No final das contas, o que decide o resultado não é a marca escolhida. É saber, em qualquer terça-feira comum, quantas sessões o equipamento sustenta. Também é saber quais regras dispararam nas últimas 24 horas e há quantos dias ele roda a versão atual. Afinal, um perímetro bem escolhido e mal observado falha do mesmo jeito que um perímetro mal escolhido.

Quer avaliar o que a sua operação enxerga hoje do próprio perímetro? Fale com um especialista da OpServices e conheça o que dá para medir no ambiente que você já tem.