pfSense vs Firewall Linux Nativo: segurança para hospedagem

pfSense vs firewall nativo para hospedagem é a comparação entre proteger a borda da rede com um firewall dedicado e aplicar regras diretamente no Linux do servidor web. Para escolher e validar a opção correta sem perder acesso administrativo, siga estes passos:

1. Mapeie portas reais da hospedagem, como SSH, HTTP, HTTPS, painel e banco exposto apenas quando necessário.
2. Defina se a proteção ficará na borda com pfSense, no próprio Linux com UFW ou nftables, ou nas duas camadas.
3. Teste primeiro regras permissivas para o seu IP administrativo antes de negar tráfego por padrão.
4. Aplique regras mínimas para hospedagem web: liberar 80 e 443, restringir SSH e bloquear serviços internos.
5. Valide conectividade externa, logs e rollback antes de considerar o firewall em produção.

Pré-requisitos

Segurança de hospedagem web começa com inventário claro de serviços, acesso de recuperação e conhecimento da topologia. Antes de comparar pfSense e firewall Linux nativo, confirme se você administra apenas um servidor web ou se existe uma rede com múltiplos servidores, IPs públicos, clientes, banco de dados separado e regras internas.

• Acesso root ou usuário com sudo no servidor Linux que hospeda sites, painel ou aplicações PHP.
• Console de recuperação disponível antes de alterar regras de firewall, especialmente se o acesso principal for SSH.
• Distribuição estável, como Debian 12+, AlmaLinux 9+ ou Rocky Linux 9+, quando o firewall nativo for usado no próprio servidor.
• Porta SSH correta anotada e IP administrativo conhecido, por exemplo 203.0.113.10.
• Lista de portas públicas necessárias: 80 para HTTP, 443 para HTTPS e a porta administrativa realmente usada.
• Acesso ao painel do pfSense, caso ele esteja na borda da rede, com permissão para criar regras de WAN, LAN e NAT quando aplicável.

Se o servidor ainda está em implantação, revise também Configuração e Implantação Fácil de Servidores VPS na AviraHost. Para acesso remoto, mantenha à mão o procedimento de Acessando servidores VPS Linux da AviraHost, pois ele ajuda em testes e recuperação de conectividade.

Decisão prática: qual firewall escolher para seu servidor

pfSense vs firewall nativo para hospedagem deve ser decidido pela arquitetura, não apenas pela preferência da equipe. pfSense faz sentido quando existe uma camada de rede antes dos servidores, com necessidade de regras centralizadas, segmentação entre redes e controle visual. O firewall nativo do Linux faz mais sentido quando o servidor web é isolado, recebe tráfego diretamente e precisa bloquear portas no próprio sistema operacional com regras simples e auditáveis. Ferramentas como UFW, nftables e o legado iptables atuam nessa camada local, sendo nftables o padrão moderno nas distribuições atuais.

• pfSense: indicado para borda de rede, múltiplos servidores, separação entre WAN e LAN, regras por rede e administração via interface web.
• Firewall Linux nativo: indicado para um servidor único, regras locais, liberação de portas específicas e menor dependência de uma camada externa.
• Uso combinado: indicado quando pfSense filtra a entrada geral e o Linux restringe serviços locais, como SSH, banco e painéis administrativos.
• Evite escolher só pela ferramenta: a regra mal desenhada continua insegura tanto no pfSense quanto no UFW ou nftables.

pfSense vs firewall nativo em cenários reais de hospedagem

Em um site WordPress ou aplicação PHP hospedada em um único Linux, o firewall nativo costuma ser suficiente se você liberar somente 80 e 443 para a internet e restringir SSH ao seu IP. Em uma operação com vários sites, redes internas, servidores de banco separados e regras por cliente, pfSense tende a simplificar a gestão, porque as decisões ficam centralizadas antes dos servidores. Em ambientes críticos, a abordagem em camadas é mais segura operacionalmente: pfSense atua como firewall de borda reduzindo a exposição na entrada, enquanto o Linux impede que serviços locais fiquem acessíveis por engano. Essa segurança em camadas também reduz o impacto de latência de rede ao concentrar filtragem pesada na borda, deixando o servidor com throughput máximo para servir conteúdo.

Inventário de portas antes de escolher pfSense ou UFW

UFW para hospedagem web só deve ser ativado depois que você souber quais serviços estão escutando no servidor. Ao rodar os comandos abaixo, você verá portas, endereços e processos associados. Isso evita bloquear um painel legítimo ou deixar exposto um serviço que deveria aceitar conexões apenas localmente.

ss -tulpen

Output esperado:
Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:22          sshd
tcp   LISTEN 0.0.0.0:80          nginx
tcp   LISTEN 0.0.0.0:443         nginx
tcp   LISTEN 127.0.0.1:3306      mysqld

O resultado acima mostra uma base comum de hospedagem: SSH, HTTP, HTTPS e banco aceitando apenas conexões locais. Se o banco aparecer em 0.0.0.0:3306, trate como alerta e revise se isso é realmente necessário. Para conexões remotas controladas ao banco via painel, consulte Conectando remotamente ao MySQL - cPanel antes de liberar portas amplamente.

ip -brief addr

Output esperado:
lo               UNKNOWN        127.0.0.1/8
eth0             UP             198.51.100.20/24
eth1             UP             10.0.0.20/24

Use esse mapeamento para decidir onde cada regra entra. Se o servidor recebe tráfego direto no IP público 198.51.100.20, o firewall nativo é obrigatório para reduzir a superfície de ataque. Se o IP público está no pfSense e o servidor fica em rede interna, pfSense controla a borda, mas o Linux ainda pode bloquear acessos indevidos entre máquinas internas.

Configurar firewall Linux nativo para hospedagem com UFW

Firewall Linux nativo para hospedagem deve começar permitindo o que mantém o servidor administrável. O erro mais comum é negar entrada antes de liberar SSH para o IP correto. Em servidores Debian 12+, Ubuntu atual ou derivados compatíveis com UFW, use regras explícitas e confirme o status antes e depois da ativação. Quem migra de iptables para nftables ou UFW deve revisar as regras antigas antes de desativar qualquer camada existente.

ufw status verbose

Output esperado:
Status: inactive

Atenção: os próximos comandos alteram a política de entrada do servidor. Execute com console de recuperação disponível e confirme se 203.0.113.10 representa o seu IP administrativo real antes de aplicar.

ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH administrativo"
ufw allow 80/tcp comment "HTTP hospedagem"
ufw allow 443/tcp comment "HTTPS hospedagem"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

Output esperado:
Rule added
Rule added
Rule added
Default incoming policy changed to deny
Default outgoing policy changed to allow
Firewall is active and enabled on system startup

Depois de ativar, valide as regras. Ao rodar o comando abaixo, você deve ver SSH restrito ao IP administrativo e HTTP/HTTPS liberados publicamente. Esse desenho atende a maior parte dos servidores web isolados, desde que serviços internos não estejam expostos em interfaces públicas.

ufw status numbered

Output esperado:
Status: active

[ 1] 22/tcp ALLOW IN 203.0.113.10
[ 2] 80/tcp ALLOW IN Anywhere
[ 3] 443/tcp ALLOW IN Anywhere

Se sua porta SSH não for 22, substitua pelo valor real antes de ativar a política de negação. Se você administra painel, banco remoto ou serviço adicional, libere apenas a origem necessária. Evite regras amplas como liberar todas as portas para qualquer origem, pois isso reduz o firewall a uma formalidade sem proteção prática.

Desenhar regras no pfSense para hospedagem web

pfSense para hospedagem web é mais adequado quando há uma borda controlando tráfego antes do Linux. A lógica é diferente do UFW: primeiro você pensa em interfaces, redes e destino; depois cria regras de WAN para o que deve entrar e regras de LAN para o que os servidores podem acessar. Em hospedagem, o objetivo é expor somente serviços públicos e manter administração e banco protegidos.

1. Identifique a interface WAN que recebe tráfego da internet e a rede interna onde o servidor web está.
2. Crie regra permitindo TCP 80 da internet para o endereço do servidor web ou para o encaminhamento configurado.
3. Crie regra permitindo TCP 443 da internet para o mesmo destino.
4. Permita SSH apenas do IP administrativo 203.0.113.10 para o servidor web, se a administração passar pela borda.
5. Bloqueie tráfego externo para banco, painéis internos e serviços que não precisam ser públicos.
6. Registre logs nas regras sensíveis para confirmar tentativas negadas sem depender de suposições.

No pfSense, a ordem das regras importa. Coloque permissões específicas acima de bloqueios gerais e mantenha uma regra final de negação implícita ou explícita conforme sua política operacional. Para hospedagem com múltiplos servidores, separe regras por função: web público, administração restrita e tráfego interno. Isso facilita auditoria e reduz mudanças arriscadas quando um novo site ou serviço entra em produção.

A vantagem operacional do pfSense aparece quando você precisa repetir políticas para vários servidores, isolar redes de clientes ou concentrar logs de tráfego na borda. A desvantagem é que uma regra incorreta pode afetar mais de um servidor ao mesmo tempo. Por isso, mesmo com pfSense, mantenha regras locais mínimas no Linux para SSH, HTTP e HTTPS.

Validação de acesso após aplicar as regras

Teste de firewall em servidor web precisa confirmar o que abre e o que permanece bloqueado. Faça os testes a partir de uma máquina externa, porque testar de dentro do próprio servidor não comprova a exposição real na internet. Ao validar, documente origem, destino, porta e resultado esperado.

curl -I http://seudominio.com.br

Output esperado:
HTTP/1.1 301 Moved Permanently
Location: https://seudominio.com.br/

curl -I https://seudominio.com.br

Output esperado:
HTTP/2 200
server: nginx

O retorno 301 em HTTP e 200 em HTTPS é comum quando o site redireciona para conexão segura. Se você está ajustando redirecionamento, veja Como redirecionar um site http para https?. Em firewall, o ponto principal é confirmar que 80 e 443 respondem e que portas administrativas não aparecem abertas para qualquer origem.

ssh [email protected]

Output esperado quando executado a partir do IP autorizado:
[email protected] password:

ssh [email protected]

Output esperado quando executado fora do IP autorizado:
Connection timed out

Se o servidor usa pfSense na borda, valide também os logs da regra correspondente. Se usa UFW no Linux, use o status numerado e confirme se não há regra genérica liberando SSH. A decisão final entre pfSense e firewall nativo deve considerar manutenção: quem vai alterar regras, com que frequência e com qual plano de rollback.

Problemas comuns e como resolver

Sintoma: site saiu do ar depois de ativar o firewall

Causa: as portas 80 e 443 não foram liberadas ou a regra foi aplicada na interface errada, especialmente quando há pfSense na borda e firewall nativo no Linux.

Solução: pelo console de recuperação, verifique o status do UFW e libere HTTP e HTTPS. No pfSense, confira se a regra de WAN aponta para o destino correto e se está acima de bloqueios gerais.

Sintoma: SSH parou de responder após negar tráfego por padrão

Causa: a porta SSH real não foi liberada, o IP administrativo está incorreto ou a regra ficou abaixo de uma negação mais ampla.

Solução: use console, confirme a porta com ss -tulpen e recrie a regra permitindo SSH apenas do IP correto. Se necessário, desative temporariamente a política de negação enquanto corrige a ordem das regras.

Sintoma: banco de dados aparece acessível externamente

Causa: o serviço está escutando em interface pública ou existe uma regra ampla liberando a porta do banco para a internet.

Solução: restrinja o serviço à interface local quando possível e remova permissões públicas. Se acesso remoto for obrigatório, permita somente IPs específicos e registre logs para auditoria.

Sintoma: regras funcionam no Linux, mas não no tráfego real

Causa: o tráfego pode estar sendo filtrado antes pelo pfSense, por NAT incorreto ou por uma regra de borda que não encaminha a conexão ao servidor.

Solução: valide primeiro a borda, depois o Linux. Em ambientes com pfSense e UFW, a conexão precisa passar pelas duas camadas: regra de entrada no pfSense e regra local permitindo o serviço no servidor.

Perguntas frequentes sobre segurança e firewall em hospedagem

pfSense é melhor que firewall Linux nativo para hospedagem web?

pfSense pode ser melhor quando a hospedagem precisa de firewall dedicado, interface web, segmentação de rede e regras centralizadas. O firewall Linux nativo costuma ser suficiente quando a proteção será aplicada diretamente no próprio servidor web, com regras mais simples e administração por linha de comando.

Quando usar nftables ou UFW em vez de pfSense?

Use nftables ou UFW quando você administra um único servidor Linux, precisa liberar portas específicas como 80, 443 e SSH, e quer manter a segurança no próprio sistema operacional. Essa abordagem reduz camadas externas, mas exige cuidado para não bloquear o acesso administrativo.

pfSense substitui o firewall do servidor Linux?

pfSense não elimina a necessidade de regras locais no Linux em todos os cenários. Em hospedagem web, o ideal pode ser combinar pfSense na borda da rede com firewall nativo no servidor para restringir portas, serviços e acessos administrativos.

Qual firewall escolher para cPanel, WordPress e sites PHP?

Para cPanel, WordPress e sites PHP, a escolha depende da arquitetura. Em um servidor isolado, firewall Linux nativo com regras bem definidas pode atender; em ambientes com múltiplos servidores, redes internas ou regras por cliente, pfSense tende a facilitar a gestão centralizada.

Existe risco de perder acesso SSH ao configurar firewall Linux?

Sim, regras aplicadas incorretamente podem bloquear SSH e impedir o acesso remoto ao servidor. Antes de alterar firewall, mantenha console de recuperação disponível, registre a porta SSH correta e aplique regras de teste antes de negar tráfego por padrão.

Conclusão

Escolha de firewall para hospedagem deve seguir a arquitetura do ambiente e o risco operacional de cada mudança. pfSense é forte na borda e em redes com múltiplos servidores; firewall Linux nativo é direto, eficiente para servidor único e indispensável como proteção local. Em muitos ambientes de hospedagem, a decisão mais segura é combinar as duas camadas sem duplicar regras desnecessárias.

• Use firewall nativo quando o servidor web recebe tráfego direto e precisa liberar apenas SSH restrito, HTTP e HTTPS.
• Use pfSense quando houver borda de rede, segmentação, múltiplos servidores ou gestão centralizada de regras.
• Teste sempre por origem externa, mantenha console de recuperação e documente cada regra antes de aplicar negação por padrão.

Leia também

• Comparativo: Firewall Linux Nativo (iptables/nftables) vs. Firewall Gerenciado em Servidor Dedicado
• Otimizar Firewall Linux: por que a distro muda a segurança
• Passo a passo para configurar firewall com nftables em VPS Linux e servidor dedicado

Precisa de ajuda para configurar firewall em seu servidor?

A AviraHost pode ajudar você a planejar uma arquitetura de hospedagem com regras de firewall coerentes, reduzindo exposição de serviços sem comprometer o acesso administrativo. A escolha entre pfSense, UFW ou nftables fica mais segura quando parte do desenho real do servidor e das portas necessárias.

Conheça as opções de Servidor VPS da AviraHost