Sophos Firewall WAF: Publicar Servidor Web com Segurança

Com a Proteção de Servidor Web ou Web Application Firewall (WAF), publica-se aplicações web internas ou baseadas na nuvem através do Sophos Firewall. O firewall atua como um Proxy Reverso: os clientes conectam-se ao endereço público do firewall, que verifica o tráfego HTTP ou HTTPS e encaminha o pedido para o servidor web protegido.

Uma regra WAF não substitui automaticamente o desenvolvimento seguro de aplicações, a aplicação de patches, a autenticação forte ou o fortalecimento do servidor. No entanto, em comparação com um simples encaminhamento de porta, reduz significativamente a superfície de ataque, pois o tráfego HTTP(S) pode ser verificado, restrito e registado de forma mais direcionada.

Ainda assim, o WAF não é automaticamente a resposta certa para cada publicação. É crucial saber se a aplicação realmente funciona bem sobre HTTP ou HTTPS, se o firewall deve avaliar nomes de host e caminhos, e se a camada adicional de proxy reverso se adapta à aplicação.

Quando o WAF é mais adequado que o DNAT

Para serviços TCP ou UDP simples, continua-se a usar NAT e regras de firewall. Para aplicações web, o WAF é frequentemente a melhor escolha.

Se apenas um servidor web interno precisa ser rapidamente acessível por encaminhamento de porta, o guia Publicar servidor por DNAT no Sophos Firewall pode ajudar. Para aplicações web públicas, deve-se considerar primeiro o WAF.

⚠️ O WebDAV não é suportado pelo Sophos WAF. Aplicações como o Nextcloud não devem ser publicadas cegamente através do WAF, mas sim planeadas com regras de firewall e NAT adequadas ou outra arquitetura de publicação.

Decisão: WAF, DNAT ou acesso privado

A questão mais importante não é quão rapidamente uma publicação é construída, mas se pode ser operada, testada e revertida com segurança posteriormente. Esta classificação ajuda antes da implementação técnica:

Para aplicações privadas, uma regra WAF acessível mundialmente é frequentemente uma superfície de ataque excessiva. Se apenas algumas pessoas precisam de acesso, redes de origem fixas, VPN, ZTNA ou outra arquitetura de acesso privado são frequentemente mais limpas do que uma publicação web pública.

Pré-requisitos

Antes da primeira regra WAF, deve-se esclarecer estes pontos:

• Nome DNS público, por exemplo, portal.example.com
• Endereço IP público ou alias na interface WAN
• Certificado para o nome de host publicado
• Endereço IP interno ou FQDN do servidor web
• Porta de destino interna do servidor web
• Decisão sobre redirecionamento de HTTP para HTTPS
• Redes de origem permitidas, países ou grupos de utilizadores
• Perfil de proteção adequado e política IPS opcional
• Registo ativado para análise posterior
• Acesso de teste externo fora da própria LAN

O nome DNS público deve apontar para o endereço usado na regra WAF como Hosted address. No caso de HTTPS, o certificado deve corresponder ao nome de host publicado.

Planejar a liberação WAF antes da configuração

Uma regra WAF não deve ser planejada apenas na interface. Antes, deve-se esclarecer se o Sophos Firewall deve apenas publicar ou também assumir autenticação, perfis de proteção, regras de país e registo.

Estas perguntas são importantes antes de uma publicação produtiva:

Para certificados, deve-se esclarecer cedo se um certificado existente será importado, se o firewall deve criar e renovar um certificado Let’s Encrypt ou se é necessário um certificado gerado externamente. Para certificados wildcard, há um guia separado: Criar certificado Let’s Encrypt Wildcard.

Estrutura básica de uma regra WAF

Uma publicação WAF consiste em vários componentes:

A Sophos cria regras WAF na área das regras de firewall. A ação chama-se Protect with web server protection.

Criar regra WAF

O caminho do menu é:

Rules and policies > Firewall rules

Procedimento:

1. Selecionar IPv4.
2. Abrir Add firewall rule.
3. Selecionar New firewall rule.
4. Atribuir um nome descritivo à regra.
5. Na Action, escolher a opção Protect with web server protection.
6. Se não for necessário um modelo especial, deixar Preconfigured template em None.
7. Em Hosted server details, definir o endereço público, a porta de escuta, HTTPS, certificado e domínios.
8. Em Protected servers, selecionar ou criar o servidor web interno.
9. Definir conscientemente Allowed client networks. Para websites públicos, pode ser necessário Any IPv4; para portais, uma restrição é geralmente melhor.
10. Se necessário, definir Blocked client networks ou Blocked countries.
11. Verificar perfil de proteção, IPS e opções avançadas.
12. Guardar a regra e testar externamente.

Quando a regra é guardada, a Sophos reinicia as regras de Proteção de Servidor Web. Conexões ao vivo existentes através dessas regras podem ser interrompidas. Alterações em regras WAF produtivas devem ser feitas em uma janela de manutenção ou pelo menos conscientemente.

Planejar go-live e rollback

Uma publicação WAF não deve ser considerada concluída apenas com o armazenamento da regra. O que importa é se DNS, certificado, Hosted address, backend, perfil de proteção e registo funcionam juntos. Especialmente em encaminhamentos de porta existentes, a mudança deve ser tratada como uma pequena publicação.

Antes do go-live, verificar:

• Documentar a configuração atual do firewall ou pelo menos as configurações de regra e certificado afetadas.
• Identificar regras DNAT ou de firewall anteriores que afetam a mesma porta, IP público ou nome de host.
• Desativar regras DNAT antigas ou documentar claramente por que não competem com a regra WAF.
• Reduzir o TTL do DNS antes de uma mudança, se o nome de host público mudar de uma publicação antiga para o WAF.
• Fornecer acesso de teste externo, não testar apenas da LAN interna.
• Definir casos de teste: página inicial, login, upload, download, caminho da API, WebSocket, logout e mensagem de erro.
• Estabelecer pontos de registo esperados: Log Viewer, reverseproxy.log, registo de acesso do backend e registo de erros do backend.
• Estabelecer critério de rollback, por exemplo, login não possível, backend inacessível, certificado errado, alta taxa de erro ou partes críticas da aplicação defeituosas.

Na mudança, apenas uma publicação deve estar ativa. Se uma regra DNAT antiga e uma nova regra WAF usarem o mesmo IP público e porta, o comportamento é difícil de entender. Antes da mudança produtiva, deve estar claro qual regra realmente processa o tráfego.

Um rollback simples geralmente consiste em desativar a nova regra WAF e reativar a publicação anterior. Se o DNS também foi alterado, o TTL do DNS deve ser considerado. Em problemas de certificado ou nome de host, um rollback apenas através do DNS é frequentemente muito lento; nesses casos, a regra antiga deve ser reativável no mesmo Hosted address ou um acesso alternativo deve estar disponível.

Após o go-live, os primeiros acessos devem ser monitorados ativamente. Importante não são apenas códigos de status HTTP bem-sucedidos, mas também bloqueios WAF, erros de backend, redirecionamentos inesperados, problemas de sessão e informações de IP do cliente ausentes nos registos do backend.

Teste de aceitação após o go-live

Um teste WAF só está completo quando o mesmo pedido é rastreável de três perspectivas: cliente, firewall e backend. Isso ajuda a identificar rapidamente se um problema está no DNS, certificado, correspondência WAF, perfil de proteção ou aplicação.

Para aplicações produtivas, deve-se testar pelo menos estes casos:

• Acesso através do nome de host correto e através de um domínio não correspondente.
• Login com utilizador válido e inválido, se a aplicação ou WAF autenticar.
• Upload, download, função API ou WebSocket, se a aplicação usar tais funções.
• Acesso de uma fonte permitida e, se possível, de uma fonte conscientemente não permitida.
• Comportamento de um pedido de teste WAF conhecido e inofensivo, para que o registo e o caminho de bloqueio sejam visíveis.

Se a aplicação parecer funcionar após o go-live, mas não houver registos correspondentes visíveis, o teste ainda não está concluído. Pode ser que outra publicação esteja a corresponder, o registo esteja ausente ou o acesso não esteja a ocorrer pelo caminho esperado.

Certificados e nomes de host

Para HTTPS, a regra WAF deve usar um certificado que corresponda ao nome de host público. O certificado é importado ou criado em Certificates > Certificates e selecionado posteriormente na regra WAF.

Pontos importantes:

• O nome DNS deve corresponder ao certificado.
• Com vários nomes de host no mesmo IP, o firewall usa SNI.
• Certificados wildcard são possíveis, mas devem ser bem documentados.
• O backend pode usar um nome interno diferente, se o cabeçalho do host e a aplicação puderem lidar com isso.
• Em problemas com links absolutos, Rewrite HTML pode ser relevante.

Se vários servidores web virtuais estiverem a funcionar no mesmo IP e porta, o firewall decide no HTTPS com base no SNI e no nome de host qual regra WAF se aplica.

Planejar IP do cliente e registos de backend

Em publicações WAF, o servidor web interno frequentemente não vê o IP real do cliente como endereço de origem direta. O Sophos Firewall atua como um Proxy Reverso e estabelece a conexão com o backend por si só. Para a aplicação e os registos do servidor web, pode ser que o endereço do firewall seja visível primeiro.

Se a aplicação ou o backend precisar do IP original do cliente, deve-se verificar cedo se X-Forwarded-For ou um cabeçalho comparável é avaliado. Isso é importante para:

• Registos de aplicação e avaliação de segurança
• Limites de taxa ou proteção de login ao nível da aplicação
• Análise de erros com referência ao utilizador ou IP de origem
• Correlação de SIEM ou monitorização
• Avaliação forense após um incidente

Importante é o limite de confiança: um backend deve tratar tais cabeçalhos como confiáveis apenas se o pedido realmente vier do Sophos Firewall ou de um Proxy Reverso definido. Clientes públicos não devem poder definir X-Forwarded-For diretamente como prova de segurança. Na prática, o servidor web deve confiar apenas no IP do firewall e ignorar ou sobrescrever cabeçalhos de outras fontes.

Para resolução de problemas, isso significa: Log Viewer, reverseproxy.log e registo de backend devem cobrir o mesmo momento de teste. Se no backend apenas o IP do firewall for visível, isso não é automaticamente um erro WAF, mas frequentemente um comportamento normal de Proxy Reverso.

Restringir acesso do cliente

Nem toda aplicação web precisa ser acessível mundialmente. Já na regra WAF, pode-se limitar o acesso.

Restrições sensatas:

• Permitir apenas endereços IP de origem conhecidos ou redes de parceiros.
• Bloquear países não necessários.
• Bloquear IPs de países desconhecidos apenas se o risco de um bloqueio próprio tiver sido avaliado.
• Para portais, usar adicionalmente WAF-MFA ou autenticação prévia.
• Bloquear fontes maliciosas conhecidas através de Threat Feeds.

Para bloqueio de países e IPs maliciosos, ajuda Sophos Firewall: Bloquear países e IPs maliciosos. Para listas de ameaças dinâmicas, Sophos Firewall Threat Feeds é relevante.

Planejar Threat Feeds e Active Threat Response

Em aplicações web acessíveis publicamente, não se deve considerar apenas a regra WAF em si. Desde o SFOS 22, os Threat Feeds também são mais relevantes para tráfego de entrada encaminhado, como publicações WAF e DNAT. O firewall pode comparar tais acertos com MDR Threat Feeds, NDR Essentials e Third-Party Threat Feeds.

Para administradores, isso significa: WAF é a camada de publicação, Threat Feeds e Active Threat Response podem bloquear ou tornar visíveis fontes maliciosas conhecidas adicionais. No entanto, isso não substitui a gestão de patches, uma autenticação limpa e o fortalecimento da aplicação.

Na prática, deve-se verificar:

• Está Active Threat Response configurado de forma sensata no ambiente?
• Estão os Threat Feeds relevantes a ser usados e verificados regularmente?
• Estão os eventos WAF, registos de Active Threat Response e registos de backend visíveis em operação?
• Existe um processo para falsos positivos, lista de permissões e liberações de emergência?
• Está claro quem reage aos acertos e se apenas se regista ou se bloqueia ativamente?

Especialmente em portais de clientes, interfaces de administração ou acessos de parceiros, essa verificação deve ocorrer antes do go-live. Se um feed bloquear tráfego produtivo mais tarde, a operação deve saber onde ver o acerto e como decidir corretamente: ataque real, falso alarme ou aplicação publicada incorretamente.

Perfis de proteção e exceções

Uma regra WAF não deve apenas publicar, mas também proteger. Para isso, usam-se Políticas de Proteção, políticas IPS opcionais e exceções.

Áreas de proteção típicas:

• Manipulação de cookies
• Endurecimento de URL
• Endurecimento de formulário
• Cross-Site Scripting
• Ataques a aplicações
• Verificação de antivírus
• Clientes de má reputação

As exceções devem ser definidas de forma restrita. Se uma aplicação não funcionar devido a um único caminho ou fonte específica, não se deve desativar todo o perfil de proteção. Melhor é uma exceção direcionada com caminho, fonte e justificativa clara.

⚠️ Cada exceção reduz a eficácia da proteção. Caminho, fonte, motivo, data e data de revisão devem ser documentados para que soluções temporárias não se tornem permanentes.

Roteamento específico de caminho, WebSocket e Balanceamento de Carga

O WAF pode encaminhar pedidos para diferentes servidores de backend dependendo do caminho. Isso é útil quando uma aplicação tem vários componentes ou um único nome de host deve ser distribuído por vários serviços internos.

Exemplos:

• /api/ vai para um servidor API.
• /shop/ vai para um sistema de loja.
• / vai para o servidor web padrão.

Deve-se notar que o firewall não avalia caminhos simplesmente pela ordem das linhas da tabela. Caminhos específicos devem ser bem planejados e testados. Se o WebSocket for necessário, pode-se ativar WebSocket passthrough. O tráfego WebSocket é então passado sem a mesma verificação WAF, pois o protocolo não pode ser verificado da mesma forma que o tráfego HTTP normal.

Com vários servidores de backend, sessões persistentes ou standby quente são possíveis. Isso ajuda em casos simples de alta disponibilidade ou distribuição de carga, mas não substitui um conceito completo de balanceamento de carga de aplicação.

Erros típicos

Resolução de problemas

Se uma publicação WAF não funcionar, deve-se verificar sistematicamente:

1. O nome DNS público aponta para o IP público correto?
2. Está o endereço Hosted address correto selecionado na regra WAF?
3. Está a porta de escuta livre e não ocupada por WebAdmin, User Portal, VPN Portal ou outra publicação?
4. O certificado corresponde ao nome de host chamado?
5. Está o servidor web interno acessível a partir do firewall?
6. Estão Allowed client networks, Blocked client networks e Blocked countries corretamente definidos?
7. Existe uma regra WAF mais geral que corresponde antes?
8. O acesso é exibido no Log Viewer como permitido, bloqueado ou descartado?
9. Existem indicações em /log/reverseproxy.log?

Para a primeira análise, o Log Viewer é útil. Para uma resolução de problemas mais profunda, os registos de Proteção de Servidor Web no firewall ajudam. Uma visão geral dos ficheiros de registo e serviços está em Sophos Firewall Troubleshooting: Serviços e Logs.

Lista de verificação para regras WAF produtivas

• Nome da regra descreve aplicação, nome de host e ambiente.
• Pessoa responsável ou proprietário do sistema está documentado.
• DNS, certificado e Hosted address foram verificados.
• Acessibilidade do backend foi testada a partir do firewall.
• Publicação anterior e rollback estão documentados.
• Regras DNAT ou de firewall antigas não competem com a regra WAF.
• Testes de go-live externos estão definidos.
• Acesso é restrito a fontes ou países necessários.
• Threat Feeds e Active Threat Response foram avaliados para aplicações públicas.
• Registo está ativo.
• Perfil de proteção não está desnecessariamente desativado.
• Exceções são restritas, justificadas e temporárias.
• Alteração foi testada externamente.
• Data de expiração ou revisão está documentada.

Perguntas frequentes