Sophos Firewall WAF: Publique servidores web com segurança

Com Web Server Protection ou Web Application Firewall (WAF), publicam-se aplicações web internas ou baseadas na cloud através da Sophos Firewall. A firewall atua como proxy reverso: os clientes ligam-se ao endereço público da firewall, que inspeciona o tráfego HTTP ou HTTPS e encaminha o pedido para o servidor web protegido.

Para o contexto geral de hardening, consulte o hub Sophos Firewall Hardening: melhores práticas para uma configuração segura.

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

Ainda assim, WAF não é automaticamente a resposta certa para todas as publicações. O que importa é se a aplicação funciona corretamente através de HTTP ou HTTPS, se a firewall deve avaliar nomes de host e caminhos e se a camada adicional de proxy reverso é adequada à aplicação.

PHP2Shell — situação em 24 de outubro de 2026: Para CVE-2026-109618 e CVE-2026-109619, a Sophos não indica proteção específica através do WAF da Sophos Firewall no advisory de 22 de outubro, versão 4. Os ambientes de execução PHP afetados no backend têm de ser atualizados; a publicação através do WAF não substitui essa atualização. As assinaturas IPS disponibilizadas desde 22 de outubro destinam-se a detetar tentativas de ataque. Verifica-se separadamente se uma política IPS adequada inspeciona o percurso real dos dados e que ação executa; o guia de IPS explica essas verificações. A ausência de alarmes não comprova um estado de atualização seguro.

Decisão antes da publicação

Antes de criar uma regra WAF, deve estar claro se WAF, DNAT, VPN ou ZTNA é adequado à aplicação. Esta decisão é mais importante do que o próprio formulário na firewall, porque determina a superfície de ataque, a operação e a resolução de problemas.

Quando faz sentido usar WAF em vez de DNAT

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

DNAT é adequado para serviços não HTTP, encaminhamento de portas simples e protocolos especiais. Neste caso, a firewall limita-se sobretudo a traduzir e permitir o tráfego.
WAF / Web Server Protection é adequado para aplicações HTTP e HTTPS quando o nome de host, o certificado, os caminhos, os perfis de proteção, a autenticação ou as regras por país são relevantes.
Proxy reverso ou ZTNA é adequado para plataformas web complexas, integração de identidade e aplicações privadas quando o acesso deve ser fortemente controlado ou não deve ser público.

Se apenas for necessário tornar rapidamente um servidor web interno acessível através de encaminhamento de portas, pode ser útil o guia Publicar um servidor por DNAT na Sophos Firewall. Para aplicações web públicas, deve avaliar-se primeiro WAF.

⚠️ O Sophos WAF não suporta WebDAV. Por isso, aplicações como Nextcloud não devem ser publicadas indiscriminadamente através de WAF; a publicação deve ser planeada com regras de firewall e NAT adequadas ou com outra arquitetura de publicação.

Decisão: WAF, DNAT ou acesso privado

A questão mais importante não é a rapidez com que se configura uma publicação, mas se esta poderá depois ser operada, testada e desativada com segurança. Esta classificação ajuda antes da implementação técnica:

Site público ou aplicação HTTPS simples: WAF é geralmente o ponto de partida adequado. É necessário testar DNS, certificado, nome de host, perfil de proteção, registo e acessibilidade do backend.
Portal de clientes, portal de parceiros ou interface de administração: WAF com restrição das origens e, opcionalmente, MFA pode fazer sentido. Deve esclarecer-se previamente se é possível utilizar WAF-MFA, regras por país ou redes de origem fixas.
Serviço exclusivamente TCP ou UDP: DNAT é geralmente mais adequado. A regra de firewall, a regra NAT, o servidor de destino, a rota de retorno e o registo têm de ser verificados em conjunto.
Aplicação web com WebDAV ou protocolo especial: não utilize WAF automaticamente. Teste as funções suportadas, o comportamento dos clientes e uma alternativa de publicação.
Aplicação apenas para utilizadores internos: avalie VPN, ZTNA ou WAF com fortes restrições. A acessibilidade pública deve ser questionada criticamente.

Para aplicações privadas, uma regra WAF acessível a partir de todo o mundo representa frequentemente uma superfície de ataque excessiva. Se apenas algumas pessoas precisarem de acesso, redes de origem fixas, VPN, ZTNA ou outra arquitetura de acesso privado são muitas vezes uma solução mais adequada do que uma publicação web pública.

Planeamento e pré-requisitos

Uma publicação WAF estável requer DNS, certificado, acessibilidade do backend, registo e um plano de reversão. Estes pontos devem estar definidos antes da configuração.

Pré-requisitos

Antes da primeira regra WAF, devem esclarecer-se 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 o redirecionamento de HTTP para HTTPS
Redes de origem, países ou grupos de utilizadores permitidos
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 tem de apontar para o endereço utilizado na regra WAF como Hosted address. Em HTTPS, o certificado tem de corresponder ao nome de host publicado.

Além disso, a firewall precisa de um objeto web server em Web server > Web servers. Nesse objeto, o servidor de destino interno ou externo é definido com host, protocolo e porta. O host é um objeto de host IP ou FQDN. Para os backends, é possível utilizar HTTP ou HTTPS; as portas predefinidas são 80 e 443. Se o servidor web backend entregar respostas demoradas ou precisar de keep-alive, Keep alive e Timeout devem ser verificados criteriosamente, em vez de serem aceites sem avaliação.

O Timeout do backend pode variar entre 1 e 65,535 segundos; o valor predefinido é 300 segundos. Quando este tempo expira, a WAF envia 502 ao cliente. Disable backend connection pooling força uma nova ligação ao backend para cada acesso e pode reduzir o desempenho. Por isso, esta opção só deve ser utilizada numa análise direcionada para isolar uma falha, devendo depois ser reposta no estado anterior documentado.

Os limites de Web Server Protection também devem ser considerados desde cedo. A Sophos indica, entre outros, um limite de 60 regras WAF por firewall. Este limite é suficiente para muitos ambientes, mas, com numerosos portais de clientes, tenants, sistemas de teste ou nomes de host separados, pode tornar-se relevante mais cedo do que o esperado. Nesse caso, em vez de criar indiscriminadamente mais regras individuais, devem rever-se o esquema de nomes, os caminhos, os servidores web virtuais e as alternativas de publicação.

O SFOS 22 não suporta regras WAF através de IPv6. Por isso, uma aplicação não pode ser planeada como publicação IPv6 com esta função; o resumo Suporte IPv6 e limites na Sophos Firewall com SFOS 22 distingue WAF das funções IPv6 suportadas para regras e proteção. Os modelos do Exchange também não constituem uma autorização geral para ambientes modernos do Exchange: a Sophos documenta que as regras WAF atualmente não suportam versões do Exchange posteriores a 2013.

Os modelos pré-configurados pertencem a uma geração mais antiga de aplicações Microsoft: Exchange Autodiscover, Outlook Anywhere e Exchange General ficam limitados ao Exchange 2013; os restantes guias da Sophos referem Microsoft Lync, Remote Desktop Gateway ou RD Web 2008/R2 e SharePoint 2010/2013. Por isso, não constituem uma base atual para Microsoft 365, versões modernas do Exchange, Teams ou implementações RDS atuais. Antes de utilizar um modelo, devem comparar-se os caminhos, os métodos de autenticação e os perfis de proteção realmente necessários com a arquitetura Microsoft atual; numa aplicação moderna, em caso de dúvida, Preconfigured template deve permanecer em None.

Criar um objeto backend com um exemplo claro

O nome público e o nome do backend desempenham funções diferentes. No exemplo seguinte, os utilizadores abrem portal.example.com; a firewall acede ao servidor através de backend.example.com. Ambos os nomes são exemplos e têm de ser substituídos pelos seus próprios nomes DNS. Do ponto de vista da firewall, o nome do backend tem de resolver para o servidor real, e não novamente para o endereço público da própria WAF: caso contrário, não existe um caminho adequado para o backend.

Em Hosts and services > FQDN host > Add, crie um objeto chamado WAF_Backend_Portal com FQDN backend.example.com e guarde-o. Em alternativa, utilize um objeto de host IP para um servidor backend com endereço fixo. Segundo a documentação do produto, os hosts FQDN oferecem maior compatibilidade com servidores; ainda assim, é necessário verificar a resolução DNS e o servidor de destino.
Em Web server > Web servers > Add, crie um objeto web server WAF_Portal_Server e selecione o objeto backend em Host.
Defina Type e Port de acordo com o listener real do backend: no exemplo HTTPS, HTTPS e 443; num backend HTTP, HTTP e, por exemplo, 80. A porta de escuta externa só é definida na regra WAF e não tem de ser igual à porta do backend. Num backend HTTP, proteja adequadamente o segmento não encriptado; um frontend HTTPS, por si só, não encripta esse segmento.
Ative Keep alive apenas se o servidor web suportar a reutilização de ligações. Avalie inicialmente Timeout com o valor predefinido de 300 segundos. Este valor refere-se ao tempo de espera por dados enviados para ou recebidos do backend, e não a uma duração máxima total fixa de cada pedido: enquanto os dados chegarem dentro do prazo, uma resposta pode demorar mais tempo. Por isso, perante um 502, verifique os logs do backend e as pausas na transferência de dados, em vez de aumentar imediatamente o valor.
Durante a operação normal, não ative Disable backend connection pooling como otimização de desempenho. Guarde o objeto, verifique a associação à regra WAF ou ao caminho Protect do SFOS 23 e teste um acesso representativo ao backend.

Planear a publicação WAF antes da configuração

Uma regra WAF não deve ser planeada apenas no formulário de configuração. Deve estar previamente claro se a Sophos Firewall deve apenas publicar a aplicação ou se também deve assegurar a autenticação, os perfis de proteção, as regras por país e o registo.

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

Trata-se realmente de uma aplicação HTTP ou HTTPS? Para outros protocolos, DNAT é geralmente mais adequado.
A aplicação tem de ser acessível publicamente? Portais de administração privados são frequentemente mais adequados a VPN, ZTNA ou redes de origem restritas.
Que nome de host e certificado serão utilizados? DNS, SNI, certificado e Domains da WAF têm de corresponder.
Quantas publicações estão planeadas? O limite de regras WAF e a facilidade de gestão posterior influenciam o desenho da solução.
A firewall deve autenticar os utilizadores? Para portais, WAF-MFA pode ser útil.
Que perfis de proteção estão ativos? Exceções demasiado amplas enfraquecem a WAF; perfis demasiado restritivos podem impedir o funcionamento das aplicações.
Como serão feitos o registo e os testes? O Log Viewer, reverseproxy.log e os logs do backend devem ser conhecidos antes da entrada em produção.

Para os certificados, deve esclarecer-se desde cedo se um certificado existente será importado com a chave privada e a cadeia da CA, se a própria firewall deve criar e renovar um certificado Let’s Encrypt ou se é necessário um certificado criado externamente. Para certificados wildcard, existe um guia separado: Criar um certificado wildcard Let’s Encrypt.

Configurar uma regra WAF

A regra WAF propriamente dita é composta pelo endereço público, nomes de host, certificado, servidor de destino, origens permitidas e perfil de proteção. Estes campos devem ser considerados em conjunto, e não como opções individuais isoladas.

Estrutura básica de uma regra WAF

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

Hosted address: endereço IP público ou alias através do qual os clientes acedem à aplicação.
Listening port: porta pública, geralmente 80 ou 443.
Domains: nomes de host que devem corresponder à regra WAF.
HTTPS certificate: certificado para o nome de host publicado.
Web server: objeto web server criado previamente, com host, protocolo, porta e definições de ligação.
Allowed client networks: redes de origem que podem aceder.
Blocked client networks / countries: origens ou países que serão bloqueados.
Protection policy: proteção WAF contra ataques web típicos.
Authentication: autenticação prévia opcional através da firewall.

Na Sophos, as regras WAF são criadas na área das regras de firewall. A ação chama-se Protect with web server protection.

Importante: uma regra WAF não é uma regra de firewall normal com NAT por trás. Cria uma publicação por proxy reverso. Por isso, Hosted address, Listening port, Domains, certificado, Protected server e Allowed client networks têm de corresponder. Se um destes campos não for adequado, a falha parece frequentemente um problema de certificado, DNS ou backend.

Criar uma regra WAF

O caminho do menu é:

Rules and policies > Firewall

Procedimento:

As novas regras estão ativadas por predefinição. Por isso, numa publicação preparada mas ainda não autorizada, verifique explicitamente o estado da regra e mantenha-a desativada até à entrada em produção planeada. Rule position permite escolher Top ou Bottom; Rule group associa a regra a um grupo existente ou criado através de Create new. Automatic utiliza o primeiro grupo adequado ao tipo de regra e às zonas de origem/destino. O agrupamento facilita a gestão, mas não substitui a verificação do acesso.

O procedimento numerado seguinte com Protected servers aplica-se apenas ao SFOS 22 e permanece inalterado para esta versão. As regras WAF suportam apenas IPv4. A ação externa da regra Protect with web server protection não equivale à ação por caminho Action > Protect em Traffic routing no SFOS 23; para o SFOS 23, aplicam-se as instruções separadas imediatamente após este procedimento.

Selecione IPv4.
Abra Add firewall rule.
Selecione New firewall rule.
Atribua um nome descritivo à regra.
Defina Rule position conscientemente, sobretudo se já existirem regras WAF mais gerais ou publicações antigas.
Em Action, escolha a opção Protect with web server protection.
Se não for necessário um modelo específico, deixe Preconfigured template em None.
Em Hosted server details, defina o endereço público, a porta de escuta, HTTPS, o certificado e os domínios.
Em Protected servers, selecione o objeto de servidor web adequado ou crie-o primeiro em Web server > Web servers.
Defina Allowed client networks conscientemente. Para sites públicos, Any IPv4 pode ser necessário; para portais, uma restrição é geralmente melhor.
Se necessário, defina Blocked client networks ou Blocked countries.
Nas políticas avançadas, verifique conscientemente Protection, Intrusion prevention e Traffic shaping.
Guarde a regra e teste externamente.

SFOS 23: Publicar caminhos em Traffic routing

Em Rules and policies > Firewall, crie ou edite uma regra IPv4. Continue a selecionar Protect with web server protection como Action externa e configure adequadamente o endereço público, a porta, o certificado HTTPS e os domínios. Uma nova regra contém, por predefinição, / com Block: sem configuração adicional de encaminhamento, os pedidos são rejeitados, não publicados.
Em Traffic routing, utilize Edit ou Add new path para editar ou adicionar o caminho específico pretendido. Em Action, selecione explicitamente Protect e atribua os objetos backend necessários de Web server > Web servers. Embora um modelo crie caminhos com Protect, continua a ser necessário atribuir os backends.
Para cada caminho protegido, atribua a política de autenticação pretendida no campo Authentication e defina conscientemente Allowed client networks, sem deixar o campo vazio. Verifique especificamente Blocked client networks, Blocked countries e Block IP addresses of unknown country-origin; para origens de país desconhecido, tenha também em conta o risco de autobloqueio.
Se apenas determinados caminhos devem ser publicados, mantenha conscientemente / com Block como rota de fallback. Defina / como Protect apenas se pretender publicar toda a aplicação; verifique explicitamente o backend, a autenticação, as restrições de acesso e as partes da aplicação que ficam assim acessíveis. Os caminhos mais longos e mais específicos são avaliados primeiro, independentemente da ordem na tabela.
Distinga as ações: Block rejeita pedidos para o caminho selecionado e não os encaminha para o backend. Protect aplica a política de proteção da regra, bem como as definições de autenticação e acesso configuradas. Redirect envia ao cliente um redirecionamento para o destino configurado, em vez de publicar um backend. Passthrough cria um túnel para o backend sem inspeção WAF e sem aplicar a política de proteção. Protection aplica-se apenas a caminhos com Protect.
Depois de guardar, teste externamente um caminho que deve ser permitido, um caminho deliberadamente bloqueado e um caminho sem correspondência específica. Se forem utilizados, verifique também Redirect e Passthrough separadamente. Correlacione o resultado no cliente, o Log Viewer, reverseproxy.log e os logs de backend com base no mesmo pedido e no mesmo momento.

O caminho predefinido pode ser editado, clonado ou eliminado. Um clone não herda a autorização funcional: volte a verificar a ação, o backend, a autenticação e as origens para a nova associação. Não remova / inadvertidamente se este constituir a rota de fallback deliberadamente bloqueadora.

Regras existentes após a atualização: Segundo a documentação da Sophos, as regras WAF existentes são automaticamente convertidas para Protect durante a atualização para SFOS 23; as rotas específicas por caminho existentes são preservadas. Isto difere da predefinição / com Block nas novas regras e da migração mais antiga das ModSecurity Protection Policies no SFOS 18. Mesmo assim, após a atualização, verifique para cada caminho a ação, o backend, a autenticação, as restrições de acesso e a rota efetiva, e realize um teste de aceitação externo; a migração automática não substitui a aceitação.

Contexto do tutorial: O tutorial da Sophos sobre proteção de um servidor web contra ataques continua a utilizar o procedimento com Protected servers e menciona IPv4 or IPv6, embora a referência das regras WAF limite WAF a IPv4. Por isso, o tutorial não constitui um guia completo de encaminhamento para SFOS 23. Para a configuração atual, aplicam-se IPv4 e as ações explícitas por caminho descritas acima.

Quando a regra é guardada, a Sophos reinicia as regras de Web Server Protection. As ligações ativas existentes através destas regras podem, por isso, ser interrompidas. As alterações a regras WAF em produção devem, portanto, ser realizadas numa janela de manutenção ou, pelo menos, de forma consciente.

Se Allowed client networks estiver vazio, a regra WAF não funciona corretamente; o navegador pode receber um 400 Bad Request. Para uma aplicação pública, Any IPv4 pode ser possível, mas não é automaticamente correto. Para portais de administração, portais de parceiros ou ferramentas internas, devem ser revistas primeiro redes de origem fixas, limitação por país, WAF-MFA, VPN ou ZTNA.

Os conflitos de porta devem ser esclarecidos antes de guardar. WebAdmin e User Portal necessitam cada um de uma porta exclusiva. WAF e VPN Portal utilizam TCP; se utilizarem a mesma porta, as respetivas Hosted address ou os endereços IP WAN têm de ser diferentes. WAF pode diferenciar-se de SSL VPN pelo endereço IP WAN, pela porta ou pelo protocolo, porque SSL VPN suporta TCP ou UDP. Um FQDN ou nome SNI diferente, por si só, não é suficiente para separar estes listeners. Se outro serviço ou uma publicação DNAT antiga já estiver a escutar num endereço IP público, a atribuição deve ser testada por endereço IP, porta e protocolo antes da entrada em produção.

A porta predefinida do User Portal é 4443; os listeners dos portais e os respetivos limites são descritos na visão geral dos portais.

SFOS 23: Definir concretamente as respostas de Block e Redirect

Uma ação de encaminhamento pode agrupar várias entradas em Paths se todas necessitarem do mesmo tratamento. Em Traffic routing > Add new path, selecione os caminhos e a ação, preencha os campos específicos da ação e guarde a entrada de caminho. Utilize entradas separadas quando os backends, as regras de acesso ou os destinos de redirecionamento forem diferentes.

Para Block, Response code determina a resposta. Um exemplo é /admin/ com Forbidden (403), enquanto / permanece em Block como rota de fallback. A seleção documentada inclui 400 a 417, bem como 422, 423, 424 e 426. Escolha o código de acordo com a mensagem pretendida: 403 indica acesso negado e 404 indica conteúdo não encontrado. Selecionar o código 401 não configura uma política de autenticação; o código de estado, por si só, não constitui proteção de autenticação. No teste de aceitação, verifique o estado configurado e a ausência de um pedido correspondente ao backend.

Para Redirect, além de Paths e Action, a configuração inclui os campos Response code, Protocol, Host, Path e Port. Exemplo: /old-portal/ com Temporary Redirection (307), Protocol HTTPS, um host FQDN para portal.example.com, Path /portal/ e Port 443. Substitua os nomes e caminhos pelos da sua aplicação de destino. 307 indica um redirecionamento temporário que mantém o método do pedido; é adequado para um piloto controlado se o destino processar o mesmo método. Ainda assim, teste separadamente o navegador e o cliente API, sobretudo os pedidos POST. O destino /portal/ tem de estar acessível e protegido por si próprio, por exemplo, através de um caminho Protect adequado; um redirecionamento, por si só, não cria aí uma configuração de backend ou de acesso.

A seleção disponibiliza 300, 301, 302, 303, 304, 305, 307 e 308. Nem todos os códigos disponibilizados representam um redirecionamento normal para uma nova página: 304 descreve a validação da cache. 305 está obsoleto devido a preocupações de segurança e não é recomendado para aplicações públicas. Utilize 301 ou 308 apenas quando pretender uma alteração permanente e tenha em conta o comportamento dos clientes e da cache em caso de reversão. As portas predefinidas do destino são 80 para HTTP e 443 para HTTPS. Redirect não realiza inspeção WAF nem envia o pedido para um backend desta rota; por isso, verifique no cliente o estado e o destino do redirecionamento e, em seguida, a proteção da aplicação de destino.

Ajustar de forma direcionada o cabeçalho Host, o HTML e a compressão

As Advanced settings de uma regra WAF ajudam a resolver problemas concretos de proxy reverso. Não são opções que devam ser todas ativadas indiscriminadamente:

Pass host header encaminha para o backend o cabeçalho Host solicitado pelo cliente. Quando existem vários sites num servidor, isto pode permitir selecionar o host virtual correto. Configure o vHost do backend de acordo com o nome publicado e verifique no log de acesso que não é outro site a responder.
Rewrite HTML adapta os links nas páginas devolvidas. Por exemplo, se um link absoluto apontar para http://backend.example.com/, enquanto a aplicação é publicada através do nome público, poderá ser necessária uma reescrita. Se os nomes de host públicos já forem adequados ou se todos os links forem relativos, normalmente não é necessária. O processamento abrange os Content-Types text/* e *xml*; os downloads binários têm de ser servidos com o Content-Type correto, caso contrário poderão ser corrompidos. Depois, teste separadamente os links públicos, os downloads e as funções da aplicação.
Rewrite cookies reescreve os cookies nas páginas devolvidas. Se houver problemas de sessão, examine os cookies efetivamente definidos, bem como o início e o fim de sessão, em vez de confundir a reescrita de cookies com Cookie signing: a reescrita e a proteção contra manipulação desempenham funções diferentes.
Disable compression support é uma ajuda direcionada para páginas apresentadas incorretamente ou erros de Content-Encoding. Neste caso, a firewall solicita dados não comprimidos ao backend e entrega-os sem compressão, independentemente da codificação solicitada. Documente o estado anterior, repita o acesso à mesma página e desative a opção se esta não resolver o erro.

Algumas portas estão reservadas para serviços do sistema, mesmo quando o respetivo serviço não é utilizado. O facto de uma porta não ter um listener ativo não a torna disponível para WAF; a visão geral Portas reservadas da Sophos Firewall ajuda no planeamento. Traffic shaping atribui à publicação largura de banda e priorização em função do horário. Trata-se de uma decisão operacional, não de proteção adicional da aplicação; com a política ativada, teste também os uploads e downloads sob uma carga representativa.

Entrada em operação e aceitação

A publicação ainda não está concluída depois de guardar a regra. Só os testes externos, os logs adequados e um rollback claro tornam a alteração pronta para produção.

Planear a entrada em operação e o rollback

Uma publicação WAF não deve ser considerada concluída apenas por se guardar a regra. O que importa é se DNS, certificado, Hosted address, backend, perfil de proteção e registo funcionam em conjunto. Sobretudo quando existem encaminhamentos de portas, a transição deve ser tratada como uma pequena publicação.

Antes da entrada em produção, verifique:

Documente a configuração atual da firewall ou, pelo menos, as definições de regras e certificados afetadas.
Identifique as regras DNAT ou de firewall anteriores que afetam a mesma porta, o mesmo IP público ou o mesmo nome de host.
Desative as regras DNAT antigas ou documente claramente por que motivo não competem com a regra WAF.
Reduza o TTL de DNS antes da transição se o nome de host público passar de uma publicação antiga para WAF.
Disponibilize acesso de teste externo; não teste apenas a partir da LAN interna.
Defina casos de teste: página inicial, início de sessão, upload, download, caminho API, WebSocket, fim de sessão e mensagem de erro.
Defina os locais de registo esperados: Log Viewer, reverseproxy.log, log de acesso do backend e log de erros do backend.
Defina um critério de rollback, por exemplo, impossibilidade de iniciar sessão, backend inacessível, certificado incorreto, taxa elevada de erros ou falhas em partes críticas da aplicação.

Durante a transição, apenas uma publicação deve estar ativa de cada vez. Se uma regra DNAT antiga e uma regra WAF nova utilizarem o mesmo IP público e a mesma porta, o comportamento torna-se difícil de compreender. Antes da mudança para produção, deve estar claro qual a regra que efetivamente processa o tráfego.

Um rollback simples consiste frequentemente em desativar a nova regra WAF e reativar a publicação anterior. Se o DNS também tiver sido alterado, é necessário ter em conta o TTL do DNS. Em caso de problemas com certificados ou nomes de host, um rollback apenas através do DNS é muitas vezes demasiado lento; nestes casos, deve ser possível reativar a regra antiga na mesma Hosted address, ou deve estar disponível um acesso alternativo.

Após a entrada em produção, os primeiros acessos devem ser monitorizados ativamente. Não são importantes apenas os códigos de estado HTTP bem-sucedidos, mas também os bloqueios WAF, os erros de backend, os redirecionamentos inesperados, os problemas de sessão e a ausência de informações sobre o IP do cliente nos logs de backend.

Teste de aceitação após a entrada em produção

Um teste WAF só está completo quando o mesmo pedido pode ser rastreado a partir de três perspetivas: cliente, firewall e backend. Isto permite identificar mais rapidamente se um problema está no DNS, no certificado, na correspondência WAF, no perfil de proteção ou na aplicação.

Cliente externo: Verifique a resolução DNS, o certificado, o estado HTTP, o início de sessão e os caminhos importantes. A aplicação deve abrir através do nome de host público sem avisos de certificado.
Sophos Firewall: Verifique o Log Viewer, a regra WAF, reverseproxy.log e as assinaturas bloqueadas. A regra WAF correta deve processar o acesso e os logs devem mostrar pedidos permitidos ou bloqueados com uma justificação.
Servidor web backend: Verifique o log de acesso, o log de erros, a sessão da aplicação e X-Forwarded-For. O pedido deve chegar ao vHost ou ao caminho correto, e a lógica do IP do cliente deve ser compreendida.

Para aplicações em produção, devem testar-se, pelo menos, estes casos:

Acesso através do nome de host correto e de um domínio que não corresponda.
Início de sessão com um utilizador válido e um inválido, caso a aplicação ou a WAF efetue a autenticação.
Funções de upload, download, API ou WebSocket, caso a aplicação as utilize.
Acesso a partir de uma origem permitida e, se possível, de uma origem deliberadamente não permitida.
Comportamento de um pedido de teste WAF conhecido e inofensivo, para tornar visíveis o registo e o percurso de bloqueio.

Se a aplicação parecer funcionar após a entrada em produção, mas não forem visíveis logs correspondentes, o teste ainda não está concluído. Pode estar a corresponder outra publicação, pode faltar o registo ou o acesso pode não estar a seguir o caminho esperado.

Garantir proteção e acesso

Nas aplicações web públicas, a WAF é apenas uma camada de proteção. Os certificados, as restrições de origem, os Threat Feeds, os perfis de proteção e o registo no backend têm de ser planeados em conjunto.

Certificados e nomes de host

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

Pontos importantes:

O nome DNS tem de corresponder ao certificado.
O certificado HTTPS selecionado pode preencher automaticamente a lista de domínios na regra WAF ou substituir entradas de domínio existentes.
Com vários nomes de host no mesmo IP, a firewall utiliza SNI.
É possível utilizar certificados wildcard, mas estes devem ser devidamente documentados.
Os domínios wildcard só são utilizados depois das regras de domínio mais específicas. *. só é permitido no início, por exemplo, *.example.com; é possível incluir vários domínios wildcard numa regra.
Os underscores no elemento mais à esquerda do domínio não constituem um nome DNS adequado e devem ser evitados nos domínios WAF.
O backend pode utilizar um nome interno diferente se o cabeçalho Host e a aplicação forem compatíveis com esse nome.
Em caso de problemas com ligações absolutas, Rewrite HTML pode ser relevante.

Se vários servidores web virtuais funcionarem no mesmo IP e na mesma porta, a firewall decide, em HTTPS, com base no SNI e no nome de host, qual a regra WAF que corresponde.

Por isso, os domínios da regra WAF devem corresponder exatamente ao DNS e ao certificado. Os wildcards podem ser úteis, mas não devem substituir um conceito de publicação bem definido. Se várias aplicações funcionarem com nomes de host semelhantes, é necessária documentação clara das regras e dos certificados; caso contrário, será difícil determinar posteriormente qual a regra WAF que efetivamente correspondeu. É útil realizar um teste com um subdomínio deliberadamente não correspondente: assim, é possível identificar se responde a regra específica, uma regra wildcard ou se não existe um servidor web virtual correspondente.

O nome do objeto de certificado só pode conter caracteres alfanuméricos do conjunto de caracteres US-ASCII; não deve ser confundido com o nome DNS no certificado. Após a seleção, verifique os Domains preenchidos automaticamente e, se necessário, edite, acrescente ou elimine entradas. HTTPS torna o listener acessível através de HTTPS, não também através de HTTP. Redirect HTTP redireciona separadamente os acessos da porta 80 para a porta 443; por isso, estes listeners e os possíveis conflitos de portas também devem ser planeados.

Quando o nome de subdomínio não corresponde, não tem necessariamente de aparecer uma página gráfica de bloqueio. A documentação mostra, por exemplo, 403 para um acesso através de outro subdomínio. Por isso, verifique o estado HTTP e reverseproxy.log, e não apenas o aspeto da página no navegador.

Planear o IP do cliente e os logs de backend

Nas publicações WAF, o servidor web interno muitas vezes não vê o IP real do cliente como endereço de origem direto. A Sophos Firewall atua como proxy reverso e estabelece ela própria a ligação ao backend. Por isso, na aplicação e nos logs do servidor web, pode aparecer primeiro o endereço da firewall.

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

Logs da aplicação e análise de segurança
Limites de taxa ou proteção do início de sessão ao nível da aplicação
Análise de erros associados ao utilizador ou ao IP de origem
Correlação no SIEM ou na monitorização
Análise forense após um incidente

O limite de confiança é importante: um backend só deve considerar estes cabeçalhos fiáveis quando o pedido provém efetivamente da Sophos Firewall ou de um proxy reverso definido. Os clientes públicos não devem poder definir diretamente X-Forwarded-For como prova de segurança. Na prática, o servidor web deve, por isso, confiar apenas no IP da firewall e ignorar ou substituir cabeçalhos provenientes de outras origens.

Para a resolução de problemas, isto significa que o Log Viewer, reverseproxy.log e o log de backend têm de abranger o mesmo momento de teste. Se no backend só for visível o IP da firewall, isso não constitui automaticamente um erro WAF, mas é muitas vezes o comportamento normal de um proxy reverso.

Restringir o acesso dos clientes

Nem todas as aplicações web têm de estar acessíveis a partir de todo o mundo. O acesso pode ser limitado logo na regra WAF.

Restrições sensatas:

Permitir apenas endereços IP de origem conhecidos ou redes de parceiros.
Bloquear países desnecessários.
Bloquear endereços IP de origem geográfica desconhecida apenas se o risco de autobloqueio tiver sido avaliado.
Para portais, utilizar adicionalmente WAF-MFA ou pré-autenticação.
Bloquear origens maliciosas conhecidas através de Threat Feeds.

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

Planear Threat Feeds e Active Threat Response

Nas aplicações web acessíveis ao público, não se deve considerar apenas a regra WAF em si. Desde o SFOS 22, os Threat Feeds têm também maior relevância para o tráfego de entrada e encaminhado, como as publicações WAF e DNAT. A firewall pode verificar estas correspondências com MDR Threat Feeds, NDR Essentials e Third-Party Threat Feeds.

Para os administradores, isto significa que a WAF é a camada de publicação, enquanto os Threat Feeds e o Active Threat Response podem bloquear ou tornar visíveis outras origens maliciosas conhecidas. No entanto, isto não substitui a gestão de patches, uma autenticação adequada nem o hardening da aplicação.

Na prática, deve verificar-se:

O Active Threat Response está configurado de forma adequada ao ambiente?
Os Threat Feeds relevantes são utilizados e revistos regularmente?
Os eventos WAF, os logs do Active Threat Response e os logs de backend estão visíveis durante a operação?
Existe um processo para falsos positivos, listas de permissões e autorizações de emergência?
Está claro quem reage às correspondências e se estas são apenas registadas ou levam a um bloqueio ativo?

Sobretudo nos portais de clientes, interfaces de administração ou acessos de parceiros, esta verificação deve ocorrer antes da entrada em produção. Se um feed vier a bloquear tráfego de produção, a equipa de operações tem de saber onde consultar a correspondência e como decidir de forma fundamentada: 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, utilizam-se políticas de proteção, políticas IPS opcionais e exceções.

Áreas de proteção típicas:

Manipulação de cookies
Proteção de URLs
Proteção de formulários
Cross-site scripting
Ataques a aplicações
Verificação antivírus
Clientes com má reputação

Em Web server > General settings, existem definições globais adicionais para Web Server Protection, incluindo controlo das versões TLS e proteção contra padrões de ataques HTTP DoS lentos. Estas definições não se aplicam apenas a uma única regra. Por isso, as alterações devem ser planeadas conscientemente e coordenadas com as publicações WAF existentes.

SFOS 23: Ajustar o perfil de workers de forma direcionada

Em Web server > General settings > Worker customization, a firewall calcula os valores predefinidos com base nos recursos de CPU e RAM disponíveis; estes são adequados para a maioria das instalações. Valores mais elevados podem afetar negativamente o desempenho WAF e os recursos do sistema. Por isso, ative Use custom worker profile apenas após confirmar a necessidade e avaliar os impactos. Antes disso, documente os valores atuais e se o estado é calculado ou personalizado, crie uma cópia de segurança da configuração e planeie uma janela de manutenção e o rollback para exatamente esse estado anterior. Este ajuste não é uma alteração de Maximum sessions.

Start servers: Número de processos worker iniciados no arranque do servidor web.
Server limit: Número máximo de processos worker que podem ser executados em simultâneo.
Minimum spare threads: Número mínimo de threads inativas mantidas disponíveis para novos pedidos.
Maximum spare threads: Número máximo de threads inativas antes de serem removidas as threads excedentes.
Threads per child: Número máximo de threads worker por processo worker.
Asynchronous request worker factor: Controla o dimensionamento dos processos worker para ligações e pedidos assíncronos.

Na autenticação de proxy reverso baseada em formulários, o campo global Maximum sessions limita as sessões de utilizador simultâneas de todas as regras WAF que utilizam este método de autenticação. O valor predefinido é 25,000 e o intervalo permitido vai de 100 a 100,000. Ao atingir o limite, a firewall encerra sessões antigas ou expiradas para admitir novas. Portanto, não é uma capacidade por regra: dimensione o valor para os inícios de sessão simultâneos das aplicações abrangidas e, após uma alteração, verifique o início de sessão, o fim de sessão e a mudança de sessão.

Em Slow HTTP protection, Soft limit é o intervalo de tempo concedido inicialmente para receber o cabeçalho do pedido. Hard limit define o limite superior absoluto. Extension rate determina quantos bytes adicionais recebidos prolongam o soft limit em um segundo. Estes três valores devem ser testados em conjunto e com clientes realmente lentos; um único valor demasiado permissivo pode enfraquecer desnecessariamente a proteção.

Em Slow HTTP protection, as exceções devem ser limitadas ao mínimo necessário, isto é, a um único endereço IP ou à rede mais restrita possível. A Sophos suporta aqui objetos de host IP e de rede, mas não intervalos IP nem listas de hosts. A Minimum TLS version também é global; antes de a tornar mais restritiva, devem ser testados os clientes mais antigos e todas as aplicações publicadas através de um teste externo real.

Como definições TLS globais, o SFOS oferece, entre outras, TLS v1.2 (wide compatibility), TLS v1.2 (strict) e TLS v1.3. As opções Custom protocol configuration e Custom cipher configuration só devem ser alteradas com valores OpenSSL documentados e testados; as cipher suites para TLS 1.3 são geridas separadamente. Valores inválidos podem impedir o arranque do serviço Apache gerido pelo SFOS e, consequentemente, da Web Server Protection. O plano de alteração deve incluir os valores anteriores, uma cópia de segurança da configuração, uma janela de manutenção e um acesso administrativo alternativo. Depois, todas as publicações WAF devem ser testadas e reverseproxy.log verificado; se o serviço não arrancar, devem ser revertidos os últimos valores personalizados, em vez de se testarem mais variantes em produção.

Nas políticas de proteção, o modo é importante. Reject bloqueia e gera eventos visíveis no Log Viewer para regras WAF. Monitor apenas regista, mas estas mensagens WAF não aparecem necessariamente no Log Viewer; nesse caso, é necessário verificar reverseproxy.log. Monitor pode ser útil num projeto-piloto, mas, para proteção em produção, deve estar claro se os ataques são apenas observados ou efetivamente rejeitados.

O Common threat filter trabalha com quatro níveis de filtragem. O Level 1 é o mais tolerante e não é registado; a partir do Level 2, os resultados aparecem em /log/reverseproxy.log, aumentando também o risco de falsos positivos. Só devem ser excluídas regras individuais com base no Rule ID comprovado no log, em Skip filter rules. Desativar indiscriminadamente uma categoria inteira ou um nível superior não substitui uma análise adequada.

Static URL hardening distingue maiúsculas de minúsculas, não aceita wildcards e não ajuda com URLs criados dinamicamente por JavaScript. Form hardening compara a estrutura do formulário e suporta formulários até 8,000 bytes. Se conteúdo binário for entregue incorretamente como HTML ou XML, ambas as funções podem danificá-lo; deve corrigir-se primeiro o Content-Type do backend, em vez de desativar amplamente a proteção.

No scan antivírus, um limite de tamanho aplica-se ao volume total do upload num pedido, não a cada ficheiro individual. O Request size limit adicional para o corpo HTTP varia de 1 a 1,024 MB e tem o valor predefinido de 10 MB. HTTP Strict Transport Security só adiciona o cabeçalho HSTS quando a regra WAF utiliza Redirect HTTP; MIME-type sniffing protection define X-Content-Type-Options: nosniff. Por isso, uploads, downloads e cabeçalhos devem ser testados com a aplicação real.

IPS numa regra WAF deve ser avaliado separadamente. A Sophos só aplica IPS para WAF quando a comunicação entre a firewall e o servidor web utiliza HTTP. Se o backend estiver ligado por HTTPS, não se deve esperar automaticamente que uma política IPS selecionada tenha o mesmo efeito.

As exceções devem ser definidas de forma restrita. Se uma aplicação não funcionar devido a um caminho específico ou a uma determinada origem, não se deve desativar todo o perfil de proteção. É preferível uma exceção direcionada, com caminho, origem e justificação claros.

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

Criar uma política de proteção e compreender a sua eficácia

Em Web server > Protection policies > Add, atribua um nome descritivo, por exemplo, WAF_Portal_Protection, configure as funções de proteção necessárias e selecione Save. Depois, selecione a política no campo Protection da regra WAF; no SFOS 23, esta aplica-se apenas a caminhos com Protect. Uma política predefinida existente, por exemplo, para Exchange Autodiscover, só deve ser utilizada no caso de utilização correspondente.

Para um piloto da própria aplicação, comece por decidir claramente entre Monitor e Reject. Monitor não bloqueia e não apresenta as mensagens WAF correspondentes no Log Viewer; para isso, é necessário consultar reverseproxy.log. A maior visibilidade de Reject não deve ser confundida com uma compatibilidade da aplicação já testada. Pass Outlook anywhere permite que clientes Outlook externos contornem a proteção do servidor web para aceder ao Exchange. Esta opção não é uma solução geral de compatibilidade para portais modernos e deve permanecer desativada na ausência de um caso de utilização legado devidamente justificado.

Compreender corretamente a proteção de cookies, URLs e formulários

Cookie signing acrescenta a um cookie definido pelo servidor um segundo cookie com um hash calculado a partir do nome, do valor e de um segredo conhecido apenas pela firewall. Se o cliente não enviar o par correspondente, o cookie é descartado. Isto protege contra manipulação, mas não substitui sessões seguras da aplicação nem a configuração correta dos cookies no backend. Após a ativação, teste o início de sessão, o carrinho de compras e outros processos dependentes de cookies.

Com Static URL hardening, a firewall assina os links estáticos e avalia, a partir da resposta do servidor, quais os links subsequentes permitidos. Entry URLs define os URLs de entrada que podem ser acedidos sem uma assinatura de hardening; num site simples, / pode ser o ponto de entrada. Esta lista não é uma lista geral de encaminhamento. Respeite a distinção entre maiúsculas e minúsculas e não introduza wildcards. As aplicações com URLs gerados por JavaScript ou links diretos legítimos para páginas internas exigem uma verificação separada. Form hardening assina a estrutura original do formulário e rejeita formulários manipulados. O limite existente de 8,000 bytes e o Content-Type correto de HTML/XML continuam a ser fundamentais.

O exemplo simples documentado de proteção contra ataques utiliza Reject, Static URL hardening com entrada /, Form hardening, Antivirus, Block clients with bad reputation e Common threat filter. Nesse exemplo, Cookie signing, Pass Outlook anywhere e Skip remote lookups for clients with bad reputation estão desativados. Trata-se de um perfil de teste para esse procedimento específico, não de uma recomendação universal nem de uma prova de que os valores predefinidos são adequados a todas as aplicações. Num portal moderno, avalie cada uma destas opções com base no tráfego real da aplicação. A opção Basic with passthrough aí mencionada também não é uma recomendação de MFA; o modo do cliente, a transmissão de credenciais e os modelos são explicados no artigo sobre autenticação WAF e MFA.

Configurar o antivírus e a reputação de forma consciente

Em Antivirus, Mode determina se são utilizados um ou dois motores de análise; no modo de análise única, selecione o motor. Direction define se a análise abrange uploads, downloads ou ambas as direções. Block unscannable content bloqueia, por exemplo, ficheiros encriptados ou danificados que não possam ser analisados. Isto reforça a aplicação da proteção, mas pode afetar documentos encriptados legítimos; por isso, defina previamente os processos de negócio permitidos e o procedimento de suporte.

Limit scan size limita o volume a analisar; 0 ou um campo vazio significa que não existe limite de tamanho para a análise. Por exemplo: com um limite de análise de 50 MB e ficheiros de 45, 5 e 10 MB num único upload, o último ficheiro não é analisado. Assim, um upload bem-sucedido não comprova que todos os ficheiros nele incluídos foram analisados. Este limite de análise deve ser distinguido de Request size limit, que se aplica à totalidade do corpo HTTP: um limite de corpo maior não torna automaticamente mais conteúdo analisável. Escolha os limites de acordo com os uploads efetivamente necessários, os recursos e os requisitos de segurança, e teste uploads com vários ficheiros e conteúdo não analisável num ambiente de teste autorizado.

Block clients with bad reputation utiliza informações RBL e GeoIP: Sophos SXL para RBLs e MaxMind para GeoIP. Também estão documentados bloqueios para as classificações A1 (proxies anónimos ou serviços VPN) e A2 (ISP por satélite). Isto pode afetar acessos legítimos de parceiros. Skip remote lookups for clients with bad reputation pode melhorar o desempenho, mas altera a avaliação através de consultas remotas; não ative esta opção inadvertidamente nem a equipare a uma lista de origens permitidas.

Avaliar o Common threat filter por categoria e intensidade

As categorias respondem a questões diferentes e devem ser escolhidas de forma consciente para a aplicação:

Application attacks: Deteta, entre outros, acessos não permitidos a caminhos e tentativas típicas de execução de comandos, incluindo após uma possível intrusão.
SQL injection attacks: Analisa os argumentos dos pedidos à procura de comandos SQL incorporados e caracteres de escape.
XSS attacks: Analisa as entradas à procura de tags de script e código incorporados.
Protocol enforcement: Verifica a conformidade com o protocolo, cabeçalhos típicos como Host e User-Agent, limites dos argumentos e a utilização permitida de HTTP. Por isso, um cliente legítimo invulgar também pode ser sinalizado.
Scanner detection: Deteta padrões típicos de bots, crawlers e scans; os acessos pretendidos de motores de pesquisa ou de monitorização devem, ainda assim, ser testados.
Data leakage: Impede que informações sensíveis cheguem ao cliente, por exemplo, através de mensagens de erro do servidor. Quando Application attacks ou SQL injection attacks estiver ativo, esta categoria também deve ser avaliada, porque os âmbitos de deteção se sobrepõem.

Filter strength tem o Level 1 como valor predefinido e gera o menor número de falsos positivos. O Level 2 acrescenta, por exemplo, expressões regulares para injeção SQL/XSS e outras palavras-chave de injeção de código; o Level 3 acrescenta regras, listas de palavras-chave e limites de caracteres especiais; o Level 4 restringe ainda mais os caracteres especiais e exige testes particularmente rigorosos de falsos positivos antes da entrada em produção. As limitações de registo descritas anteriormente mantêm-se: o Level 1 não é registado, e o Level 2 e superiores aparecem em /log/reverseproxy.log. Não considere uma intensidade superior validada como segura apenas porque a página inicial abre.

Verificar HSTS e a proteção MIME antes de os ativar

Com HTTP Strict Transport Security e Redirect HTTP ativado, a firewall adiciona este cabeçalho:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

31536000 corresponde a um ano. Isto não afeta apenas o ponto de entrada testado: includeSubDomains abrange os subdomínios, e os navegadores podem guardar esta política. Antes da ativação, HTTPS, os certificados e todos os subdomínios abrangidos têm de funcionar de forma duradoura; desativar posteriormente a caixa de seleção não reverte imediatamente as políticas já guardadas pelos navegadores. A presença de preload no cabeçalho, por si só, não comprova a inclusão numa lista de preload de um navegador. MIME-type sniffing protection adiciona X-Content-Type-Options: nosniff; por isso, corrija os tipos MIME incorretos no backend, em vez de remover indiscriminadamente o cabeçalho. Verifique ambos os cabeçalhos no cliente externo.

Criar exceções tão restritas quanto necessário

Em Add new exception, defina Paths, Sources, Operation e as verificações específicas a ignorar. Os caminhos das exceções distinguem maiúsculas de minúsculas e permitem wildcards, por exemplo, /products/*/images/*. Isto distingue-os dos Entry URLs sem wildcards da política de Static URL Hardening. Em Operation, a combinação booleana é decisiva: exigir a correspondência simultânea de um caminho e de uma origem é mais restritivo do que exigir a correspondência de um caminho ou de uma origem. Verifique a interseção pretendida antes de guardar, para que uma origem de um parceiro não fique inadvertidamente isenta de proteção em todos os caminhos.

Para Sources de uma exceção, estão documentados endereços IP, intervalos, listas e redes. Isto não deve ser extrapolado para outros campos: em Path-specific routing do SFOS 22 e nos campos Allowed client networks e Blocked client networks de Passthrough do SFOS 23, só estão documentados os tipos de host IP e Network, não IP ranges nem IP lists. Para uma restrição de acesso previsível, utilize nesses campos objetos IP individuais ou objetos de rede.

As opções de uma exceção permitem ignorar, entre outros, Cookie signing, Static URL hardening, Form hardening, Antivirus, Block clients with bad reputation e categorias selecionadas do Common threat filter. Duas opções exigem precauções adicionais:

Never change HTML during static URL hardening or form hardening impede a reescrita da página HTML, por exemplo, quando a aplicação depende de links inalterados. Isto não significa automaticamente que os links não assinados sejam aceites; para isso, pode ser necessária uma exceção de hardening específica.
Accept unhardened form data aceita dados de formulários sem assinatura de hardening. Uma exceção de Form hardening, por si só, não o faz. Esta permissão adicional elimina mais uma verificação e só é adequada para um processo rigorosamente delimitado e justificado.

Antes da alteração, guarde o pedido legítimo que falhou, a hora e o Rule ID comprovado. Depois, repita o mesmo pedido e faça uma verificação adicional com uma origem ou um caminho não abrangido pela exceção. A exceção só está devidamente delimitada quando o processo necessário funciona e a restante proteção se mantém; em caso de dúvida, exclua um único Rule ID comprovado em Skip filter rules, em vez de uma área inteira de proteção.

Voltar a validar as políticas de proteção migradas

Desde o SFOS 18, a Web Server Protection utiliza o OWASP ModSecurity Core Rule Set 3.0. Durante a migração de políticas de proteção anteriores, as categorias existentes foram combinadas, os IDs das regras foram reatribuídos e foram introduzidos níveis de filtragem. Se uma das categorias combinadas estava ativa, a nova categoria conjunta pode, por isso, ficar ativa mesmo que outra parte estivesse anteriormente desativada.

Depois de uma atualização deste tipo, não basta comparar apenas o nome da política. As categorias ativas, as exceções e os níveis de filtragem devem ser verificados face à documentação anterior. Em seguida, devem realizar-se testes positivos e negativos controlados com tráfego real da aplicação e verificar-se o Log Viewer e o reverseproxy.log. A política migrada só fica validada quando os pedidos legítimos continuam a funcionar e os ataques de teste esperados são detetados.

Para a antiga migração do SFOS 18, são importantes as seguintes correspondências: Protocol violations, Protocol anomalies, Request limits e HTTP policy foram combinados em Protocol enforcement; Generic attacks e Tight security, em Application attacks; Bad robots, em Scanner detection; Outbound, em Data leakage. Rigid filtering migra para Level 1 e deve ser reavaliado de forma consciente. A categoria Trojans foi eliminada; o antivírus assume a proteção correspondente. As regras já excluídas que tenham um novo Rule ID atribuído mantêm-se excluídas, enquanto os IDs sem correspondência, removidos ou combinados numa nova regra são retirados da lista de exclusões. Por isso, não copie a antiga lista de exceções sem a verificar; compare-a com a política atual e os logs atuais.

Encaminhamento específico por caminho, WebSocket e balanceamento de carga

WAF pode encaminhar pedidos para diferentes servidores backend consoante o caminho. Isto é útil quando uma aplicação tem vários componentes ou quando se pretende distribuir um único nome de host 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 predefinido.

A firewall não avalia os caminhos pela ordem na tabela, mas dá prioridade aos caminhos mais longos e, portanto, mais específicos, antes da rota de fallback. Esta associação deve ser testada de forma direcionada. Apenas para SFOS 22: Pode ativar-se a caixa de seleção WebSocket passthrough para o caminho necessário do site; neste caso, o tráfego WebSocket é transmitido sem proteção WAF, porque os dados WebSocket não podem ser inspecionados como tráfego HTTP normal. Para SFOS 23: Em Traffic routing, configure exclusivamente o caminho WebSocket necessário com Action > Passthrough e o backend previsto. Este túnel funciona sem inspeção WAF e sem política de proteção; os restantes caminhos da aplicação permanecem em Protect. Nunca altere todo o portal para Passthrough como solução alternativa. Teste separadamente o upgrade da ligação, a transferência de dados e a reconexão. Isto não permite concluir nada sobre a imposição de MFA em Passthrough; se for necessária autenticação, esclareça a responsabilidade com a pessoa responsável pela autenticação.

Apenas para SFOS 22: No procedimento com Protected servers, o caminho predefinido / encaminha os pedidos sem correspondência mais específica para o servidor predefinido atribuído. Se esta rota predefinida for removida, a firewall rejeita esses pedidos com 404 Not Found. Para SFOS 23: Os pedidos sem correspondência mais específica utilizam a ação de /; nas novas regras, esta é Block por predefinição. Mantenha conscientemente esta rota de fallback se apenas caminhos individuais devem ser publicados. Protect para / só faz sentido quando se pretende publicar toda a aplicação e exige uma verificação da acessibilidade adicional. Para SFOS 23, não é garantido um estado 404 fixo: a resposta de Block é configurada através de Response code.

Com vários servidores backend, são possíveis sessões persistentes ou hot standby. Isto 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ções.

Sem uma associação adicional, os pedidos são distribuídos pelos vários servidores web selecionados. Sticky session cookie associa o navegador a um servidor backend; se este falhar, o cookie é atualizado e a sessão passa para outro servidor. Isto não garante a transferência do estado da aplicação: um carrinho de compras pode, por exemplo, necessitar de um armazenamento de sessões partilhado.

Hot-standby mode envia inicialmente todos os pedidos para o primeiro servidor selecionado e utiliza os restantes como reserva. Quando o servidor principal volta a estar disponível, as sessões regressam, em princípio, a esse servidor; com Sticky session cookie ativado, a sessão existente permanece no servidor de reserva. Por isso, valide separadamente o servidor principal, a ordem dos servidores de reserva, a falha, o regresso e uma operação de início de sessão ou de carrinho de compras que dependa efetivamente do estado da aplicação.

O campo Authentication também consta da tabela do SFOS 23 para Passthrough, enquanto a descrição geral das funções associa a autenticação a Protect. Esta divergência na documentação não deve ser resolvida com suposições. Se for necessário WAF-MFA, baseie a parte protegida em Protect e numa política explícita; a delimitação e os testes encontram-se em Autenticação WAF com MFA.

Alcançar backends WAF remotos através de SD-WAN

Se o servidor web protegido não estiver na rede local da firewall, o encaminhamento e o SD-WAN devem ser verificados com especial atenção. Para backends através de ligações entre locais, MPLS ou route-based IPsec, pode ser necessária uma SD-WAN Route adequada para que a firewall alcance o Protected Server de forma fiável e o caminho de retorno esteja correto. Com route-based IPsec também é importante: WAF através de route-based IPsec com Traffic Selectors para sub-redes não é suportado pela Sophos; as ligações Any-to-Any são a alternativa documentada.

O desenho documentado pela Sophos começa com uma regra WAF funcional e um túnel route-based alcançável. Em Routing > Gateways, cria-se um objeto gateway para o caminho remoto com o endereço IP do peer, a interface XFRM com endereço atribuído e um host de monitorização fiável atrás do peer. Só depois se cria em Routing > SD-WAN routes a rota direcionada para o tráfego proxy WAF:

Em Routing > Gateways > IPv4 gateway > Add, crie e guarde o gateway. No exemplo, chama-se gw6, utiliza Gateway IP 10.12.13.2 e Interface xfrm1-10.12.13.1. Em Monitoring condition, utilize um host atrás do gateway que responda de forma fiável; o exemplo documentado utiliza 10.12.13.2. Substitua estes endereços privados e a interface pelo endereçamento real do túnel e por um host de monitorização adequado.
Em Routing > SD-WAN routes, selecione IPv4 e Add, por exemplo, com o nome SD-WAN_WAF_Portal. Em Destination networks, remova Any e selecione a interface WAN pública ou a Hosted address através da qual o cliente alcança a regra WAF; no exemplo, #Port1. Nesta rota WAF documentada, não se trata simplesmente do endereço IP privado do backend.
Em Services, remova Any e selecione o Listening Port externo da regra WAF, no exemplo, TCP 8080. Se for diferente da porta interna do backend, deve ser usada aqui explicitamente a porta externa. A porta não predefinida também deve ser tida em conta no pedido de teste externo.
Em Link selection settings, selecione Primary and Backup gateways e, em Primary gateway, defina o gateway XFRM gw6 criado anteriormente. Guarde a rota. Se várias publicações utilizarem o mesmo gateway, a mesma SD-WAN Route pode conter vários endereços WAN públicos e Listening Ports. Para gateways diferentes são necessárias rotas separadas.

O procedimento SD-WAN remete para um guia sobre VPN route-based com Traffic Selectors; no entanto, a referência das regras WAF exclui explicitamente Traffic Selectors baseados em sub-redes. Por isso, para este caso de utilização WAF, planeie uma ligação Any-to-Any e não interprete o título do guia referido como uma autorização para configurações com seletores de sub-redes.

A validação separa depois as camadas: o teste externo deve corresponder à regra WAF esperada; no Log Viewer devem correlacionar-se a regra WAF, os erros do proxy reverso e a hora; na firewall devem estar ativos a interface XFRM, o monitor do gateway e a SD-WAN Route; e o servidor backend deve receber o pedido e responder pelo caminho previsto. Um túnel verde, por si só, não comprova nem a correspondência SD-WAN nem a acessibilidade do backend.

Operação e resolução de problemas

Durante a operação, importa que a publicação continue a ser rastreável: qual a regra que corresponde, quais os logs relevantes, que exceções existem e como proceder em caso de falhas.

Erros comuns

Nome público DNS aponta para o IP errado: A regra WAF nunca é alcançada.
O certificado não corresponde ao nome do host: Os navegadores apresentam erros de certificado ou a correspondência SNI não é correta.
Hosted address incorreta selecionada: A firewall corresponde a outra regra ou não identifica tráfego WAF.
Allowed client networks vazio: A regra não funciona como esperado.
Limite de regras WAF não considerado: Não é possível configurar corretamente publicações adicionais.
Publicação de uma versão do Exchange posterior a 2013 planeada com um modelo WAF: O modelo não se enquadra no limite de suporte WAF.
Conflito de porta com User Portal, VPN Portal ou outro serviço: A aplicação não está acessível ou responde um serviço da firewall.
Backend não acessível internamente: Os clientes externos recebem erros, embora o DNS e o certificado estejam corretos.
Timeout de backend mal definido: As respostas longas terminam com erros, embora a aplicação esteja, em princípio, acessível.
Backend através de VPN ou SD-WAN sem rota adequada: A regra WAF corresponde, mas o Protected Server não é alcançado de forma fiável.
Route-based IPsec com Traffic Selectors para o backend: WAF através deste caminho não é suportado.
Exceção WAF demasiado ampla: A eficácia da proteção é reduzida desnecessariamente.
Aplicação WebDAV publicada através de WAF: A aplicação não funciona de forma fiável ou não é suportada.
O caminho do URL contém %2F: WAF responde com 404 Not Found, embora o recurso esteja acessível diretamente no backend. %2F é a forma codificada num URL de uma barra / e deve ser distinguida de um erro 404 normal do backend.
Alteração de regra sem janela de manutenção: As ligações existentes podem ser interrompidas quando as regras WAF são reiniciadas.
A antiga regra DNAT e a nova regra WAF competem: Não está claro qual publicação processa o tráfego.

Resolução de problemas

Se uma publicação WAF não funcionar, deve ser verificada sistematicamente:

O nome público DNS aponta para o endereço IP público correto?
A Hosted address correta está selecionada na regra WAF?
O Listening Port está livre e não está ocupado por WebAdmin, User Portal, VPN Portal ou outra publicação?
O certificado corresponde ao nome do host acedido?
O servidor web interno está acessível a partir da firewall?
Allowed client networks, Blocked client networks e Blocked countries estão configurados corretamente?
O Protected Server está acessível através de uma rota, SD-WAN Route ou ligação VPN realmente adequada do ponto de vista da firewall?
Existe uma regra WAF mais geral que corresponda primeiro?
O acesso aparece no Log Viewer como permitido, bloqueado ou descartado?
Existem indícios em /log/reverseproxy.log?
A Protection Policy está definida como Monitor ou Reject?
O Timeout do objeto web server é adequado à aplicação?

Para a análise inicial, o Log Viewer é útil. Para uma resolução de problemas mais aprofundada, ajudam os logs de Web Server Protection na firewall. Uma visão geral dos ficheiros de log e serviços encontra-se em Resolução de problemas da Sophos Firewall: serviços e logs.

WAF responde com 404 quando o caminho contém `%2F`

Um erro específico afeta URLs que contêm uma barra codificada. Um pedido como https://portal.example.com/api/files/project%2Freport.pdf pode devolver 404 Not Found através do Sophos WAF, embora o recurso exista diretamente no backend. A Sophos acompanha este comportamento sob a referência NC-159041 e atualmente não indica uma versão SFOS específica afetada ou corrigida nem uma solução alternativa suportada.

Para delimitar a causa, o mesmo pedido deve ser comparado, de forma controlada, através de WAF e diretamente no backend. São importantes o URL exato e a hora do teste:

Verifique se o caminho contém realmente %2F. Uma barra normal / ou a ausência do caminho predefinido constituem um erro diferente.
Compare a hora no Log Viewer, em /log/reverseproxy.log e no log de acesso do servidor web.
Se não aparecer uma entrada correspondente ao pedido no backend, este foi provavelmente rejeitado antes de chegar ao servidor web. Um teste direto no backend permite também excluir a possibilidade de o próprio recurso não existir.

Uma exceção WAF ampla não resolve este problema de forma específica e reduziria desnecessariamente a proteção. A configuração do Apache gerida pelo SFOS também não deve ser alterada: o tratamento restritivo de barras codificadas ajuda a impedir que os controlos de caminho ou de acesso sejam contornados.

A solução mais limpa é a aplicação ou o fabricante gerar URLs sem barras codificadas. Se isso não for possível, deve ponderar-se conscientemente outro método de publicação, como DNAT, um proxy reverso adequado ou acesso privado, face à perda da proteção WAF. Para aplicações que não podem ser alteradas, o Sophos Support deve verificar a build SFOS concreta e o caso de utilização. As formas project%2Freport.pdf e project/report.pdf são apenas um padrão de diagnóstico e não são automaticamente equivalentes em termos funcionais.

Lista de verificação para regras WAF em produção

O nome da regra descreve a aplicação, o nome do host e o ambiente.
A pessoa responsável ou o proprietário do sistema está documentado.
DNS, certificado e Hosted address foram verificados.
A acessibilidade do backend foi testada a partir da firewall.
A publicação anterior e o rollback estão documentados.
As regras DNAT ou de firewall antigas não competem com a regra WAF.
Os testes externos de entrada em produção estão definidos.
O acesso está restrito às origens ou aos países necessários.
Threat Feeds e Active Threat Response foram avaliados para aplicações públicas.
O registo está ativo.
O perfil de proteção não está desativado desnecessariamente.
As exceções são restritas, justificadas e temporárias.
A alteração foi testada externamente.
A data de expiração ou de revisão está documentada.

Enquadrar os objetos WAF através da XML API

Nas automatizações, a publicação, o backend e a política de proteção estão interligados, mas continuam a ser objetos distintos. FirewallRule com PolicyType HTTPBased contém HTTPBasedPolicy; RealServers descreve o servidor Web de backend e ProtocolSecurity a Protection Policy. A regra WAF referencia estes objetos, não substitui a sua configuração. O acesso, a verificação de TLS, os segredos, as operações explícitas de escrita e a avaliação do estado XML são explicados em Limitar o acesso à XML API de forma segura.

Os mapeamentos seguintes explicam as referências do SFOS 22/23, mas não são modelos de pedidos executáveis. Antes de qualquer escrita, comparar a API help do build instalado com o objeto existente, preparar uma cópia de segurança e um procedimento de reversão e verificar primeiro uma consulta de leitura inofensiva. Se a sintaxe, a unidade ou o mapeamento das ações não estiverem esclarecidos, não escrever; solicitar antes o esclarecimento junto do suporte. Isto aplica-se especialmente após uma mudança de versão.

Não confundir a publicação com os caminhos de acesso

Name identifica a FirewallRule; a referência permite, no máximo, 60 caracteres, sem vírgulas e em UTF-8. Position é obrigatório e indica Bottom, Top, After ou Before; nas duas últimas variantes, é também necessário indicar a regra de referência pelo nome. Para Status, a tabela indica o valor predefinido ON e os valores de escrita Disable e Enable: omitir este campo não é uma forma segura de preparar uma publicação desativada. Segundo a tabela, LogTraffic tem o valor predefinido Disable; verificar explicitamente o registo de tráfego. IPFamily também disponibiliza IPv6 no contrato comum de FirewallRule, mas HTTPBasedPolicy está expressamente limitado a IPv4. As regras de rede e de utilizador são abordadas em Regras de firewall, não devem ser incorporadas como payload WAF.

Na secção WAF, HostedAddress, ListenPort, HTTPS, HTTPSCertificate e Domains/Domain correspondem ao listener público. A tabela apresenta HostedAddress, ListenPort, HTTPS e Domains como campos obrigatórios. ListenPort é um inteiro de 1 a 65535; estão documentados 80 com HTTPS desativado e 443 com HTTPS ativado. Esta não é a porta do backend. RedirectHTTP é o redirecionamento HTTP separado. Verificar em conjunto o nome público, o certificado e o listener após cada alteração.

Os mapeamentos de caminhos encontram-se em HTTPBasedPolicy/AccessPaths/AccessPath. Neles, backend referencia os objetos de servidor Web; allowed_networks, denied_networks, blocked_countries e block_unknown_country descrevem o acesso dos clientes. stickysession_status e hot_standby dizem respeito à afinidade de sessão e à seleção do backend. Uma Authentication Policy referenciada é enquadrada no artigo sobre autenticação WAF; a existência de um campo não confirma a aplicação de MFA a cada ação.

Diferença entre versões: A tabela do SFOS 22 descreve path como uma única string e backend como um array obrigatório. No SFOS 23, path é um array com vários valores, enquanto backend é apresentado como opcional. Segundo a tabela, os valores dos caminhos estão limitados a 63 caracteres e não podem conter vírgulas. Aqui, opcional não significa que faça sentido publicar um caminho Protect ou Passthrough sem um backend atribuído: a UI atual exige a seleção de um backend para estas ações, enquanto Block e Redirect não publicam um backend.

O SFOS 23 acrescenta action, em minúsculas, com os valores permitidos 0, 1, 2, 3, bem como response_code, redirect_protocol, redirect_host, redirect_port e redirect_path. A referência não associa os quatro números às ações da UI. Não estabelecer um mapeamento com base na ordem ou em suposições; o mapeamento confirmado para o build instalado é um pré-requisito para qualquer alteração automatizada. Action, com inicial maiúscula, com Accept, Drop, Reject, aparece no exemplo sob UserPolicy ou NetworkPolicy, não no bloco WAF. Não substitui nem a ação WAF exterior da UI nem AccessPath/action. Para redirect_protocol, a tabela indica literalmente http e https; para redirect_port, 1 a 65535; e para redirect_path, no máximo 8192 caracteres. Nela, response_code é descrito apenas como um inteiro; a seleção na UI indicada acima continua a ser determinante para a configuração concreta.

O exemplo também não constitui prova do esquema: mistura path e Path, contém referências vazias e marcadores de posição e não apresenta HTTPSCertificate nem LogTraffic de forma completa no bloco WAF. O SFOS 22 ainda apresenta websocket_passthrough; o SFOS 23 utiliza o modelo de ações. Por isso, confirmar a grafia, o aninhamento, os campos necessários e o registo de tráfego no contrato específico do build, em vez de completar mecanicamente o exemplo. ProtocolSecurity no bloco WAF referencia a política de proteção. Os controlos avançados PassHostHeader, RewriteHTML, RewriteCookies e CompressionSupport pertencem aos ajustes de reverse proxy explicados acima; não uniformizar valores contraditórios do exemplo e da tabela em enumerações próprias.

O exemplo apresenta ainda SourceNetworks/Network e ExceptionNetworks/Network, enquanto o respetivo comentário menciona, em alternativa, Authentication, AllowFrom, BlockFrom ou AccessPaths. Não deduzir daí equivalência entre aliases, combinações permitidas ou regras de precedência. Nos objetos existentes com esta representação do acesso, esclarecer a estrutura e o efeito no build instalado; se continuarem por esclarecer, não efetuar escritas automatizadas.

As exceções têm um bloco próprio, Exceptions/Exception. Nele, path, source e op ligam as condições; para op, a tabela indica literalmente and, or, AND, OR. skipcookie, skipurl, skipform, skipav e skipbadclients omitem as respetivas verificações. Em contrapartida, skiphtmlrewrite impede a alteração dos conteúdos correspondentes, e skipform_missingtoken permite dados de formulário sem assinatura de hardening, para além da exceção de formulário. A linha correspondente da tabela troca a descrição e o valor predefinido; não deduzir daí um valor predefinido fiável. As consequências de segurança de ambas as opções descritas acima continuam a ser determinantes. skip_threats_filter_categories utiliza tokens diferentes dos da política de proteção, por exemplo application_attacks e data_leakages. Não confundir estes tokens de exceção com os nomes apresentados na política. O texto desatualizado da descrição relativo a categorias anteriores também não constitui uma autorização para utilizar tokens antigos. Após uma alteração, verificar separadamente o caminho permitido, o caminho bloqueado, a rota de recurso e um pedido não abrangido por exceções.

A tabela descreve path para rotas Site-Path; o exemplo de exceção, por sua vez, mostra vários elementos path dentro de uma Exception, sem um contrato próprio claramente definido na tabela. Portanto, não se devem aplicar às exceções a cardinalidade e os limites dos caminhos de roteamento. Antes de fazer alterações automatizadas em exceções, confirmar a estrutura, a quantidade e os valores permitidos no build instalado; se o contrato não estiver esclarecido, não efetuar gravações.

Verificar com segurança o contrato do backend e o timeout

Em RealServers, Name, Host, Port e TimeOut estão documentados como campos obrigatórios. Name permite, no máximo, 60 caracteres UTF-8 sem vírgulas. Host é a referência a um objeto de host IP ou FQDN, não um nome público WAF livremente intercambiável. Port varia de 1 a 65535, com o valor predefinido da API 80; Type indica literalmente Plaintext (HTTP) ou Encrypted (HTTPS). Por isso, para um backend HTTPS, confirmar explicitamente o listener e a porta efetivos, em vez de adotar a porta predefinida da API.

A API descreve TimeOut com o valor predefinido 300, o intervalo de 1 a 65535 e a indicação de que só se aplica com Keep alive ativado. A GUI, em contrapartida, explica Timeout como o tempo de espera por dados enviados para ou recebidos do backend e indica um HTTP-502 após esse tempo expirar. Trata-se de uma descrição diferente, não de uma prova de comportamento idêntico com Keep-alive desativado. Para configurações na UI, utilizar o teste de pausa na transmissão de dados descrito acima; antes de uma automatização, esclarecer a dependência e o valor guardado no build instalado. Não deduzir daí um aumento global do timeout.

Para KeepAlive, o exemplo apresenta Enable/Disable, mas a tabela indica apenas 0 e Enable, bem como o valor predefinido ON. Não corrigir silenciosamente esta divergência com um Disable presumido. DisableReuse indica Disable e Enable e corresponde a Disable backend connection pooling. Salvaguardar o estado anterior, voltar a ler o objeto alterado e só depois verificar uma transferência de dados representativa e os registos do backend. Uma resposta da API, por si só, não comprova nem a acessibilidade do backend nem a adequação das definições de ligação.

Política de proteção e opções dependentes

Segundo a tabela, ProtocolSecurity requer Name, Mode e RequestSizeLimit. Para Name, aplicam-se, no máximo, 60 caracteres UTF-8 sem vírgulas; Mode indica Monitor e Reject. Os controlos CookieSigning, StaticUrlHardening e FormHardening correspondem à proteção de cookies, URLs e formulários descrita acima. Segundo a tabela, PassOutlookAnywhere tem o valor predefinido OFF: a API descreve o acesso ao Exchange apenas de forma sucinta, enquanto a GUI indica expressamente que se contorna a Web Server Protection. Por isso, deixá-lo desativado na ausência de um caso de utilização de sistemas legados devidamente justificado; não o tratar como um controlo de compatibilidade comum. Com StaticUrlHardening ativado, a referência descreve EntryURLType com Manual, SitemapFile, SitemapURL; para o caso manual, o exemplo apresenta EntryURLList/EntryURL, com vários URLs de entrada de, no máximo, 255 caracteres cada. Não deduzir daí que a GUI disponibiliza todas as variantes da API de forma idêntica.

A tabela da API apresenta CookieSigning, StaticUrlHardening, FormHardening, AntiVirus, BlockClientsWithBadReputation e ThreatsFilter, cada um com Default OFF, e ParanoiaLevel com Default 1. Portanto, uma Policy nova ou referenciada não comprova, por si só, que as verificações de proteção estejam ativadas. Ao criar uma nova Policy, definir explicitamente as opções pretendidas e consultar os valores gravados. Ao usar Edit sem um contrato de atualização confirmado, não presumir nem a preservação dos campos omitidos nem a reposição dos valores Default.

Com AntiVirus ativado, tornam-se relevantes AVMode (Avira, Sophos, DualScan), Direction (Uploads, Downloads, UploadsAndDownloads), BlockUnscannableContent e LimitScanSize. O inteiro Megabytes depende adicionalmente de LimitScanSize estar ativado. Isto continua a ser separado do limite do corpo do pedido. SkipRemoteLookups depende de BlockClientsWithBadReputation; não deduzir o efeito da verificação de reputação apenas a partir da breve descrição da API.

ThreatsFilter ativa o Common threat filter. Este inclui ThreatFilters/Filter, ParanoiaLevel com 1 a 4 e SkipFilterRules/FilterRules como lista de IDs de regras inteiros. Os tokens de filtro permitidos são, literalmente, Application attacks, SQL injection attacks, XSS attacks, Protocol enforcement, Scanner detection, Data leakages. O último token difere do nome na GUI Data leakage. Criar exceções específicas apenas para falsos positivos comprovados e verificar depois a restante proteção; o nível, a categoria e a exceção são decisões distintas.

RequestSizeLimit continua a apresentar um conflito entre fontes: A tabela da API indica que é obrigatório, o valor predefinido 10, a descrição «Megabytes» e um intervalo de inteiros de 1 a 1073741824. A GUI atual, em contrapartida, documenta 1 a 1024 MB, com o valor predefinido 10 MB. No exemplo da API, RequestSizeLimit está totalmente ausente. Não deduzir daí uma conversão entre bytes e MB, um limite alargado para utilização em produção ou que a sua omissão seja segura. Para a GUI, utilizar o intervalo documentado em MB; utilizar um valor de escrita na API apenas após confirmar a unidade, o intervalo e o comportamento do campo obrigatório no build instalado. O mesmo se aplica à designação da tabela HSTS Enforcement, que não aparece no exemplo: não inventar uma tag XML a partir do nome. XContentTypeOptions descreve a proteção MIME; verificar externamente a associação guardada à política e os cabeçalhos efetivos.

Distinguir as respostas XML por operação

Os números seguintes são estados de objetos XML, não códigos de estado HTTP. Aqui, Message.* designa um nome simbólico não resolvido da referência, não uma mensagem de erro traduzida nem uma prova de uma causa exata. Verificar em conjunto a resposta, a operação e o estado guardado do objeto; perante erros, avisos ou uma possível alteração parcial, nunca voltar a escrever às cegas. O guia central de segurança da API explica o procedimento seguro de verificação e escalamento.

Nas respostas de FirewallRule relevantes para WAF, são especialmente importantes as seguintes diferenças:

Add firewall rule: 200 → Message.FWRuleAddSuccess, 500 → Message.FWRuleAddFail, 502 → Message.FWRuleRecordExists. Edit firewall rule: 200 → Message.FWRuleEditSuccess, 202 → Message.FirewallRuleUpdateWithRename, 500 → Message.FWRuleEditFail, 502 → Message.FWRuleUpdateRecordExist. No caso de 202, voltar também a ler o nome do objeto e as referências, não apenas reutilizar o nome antigo.
Add firewall rule 541 → Message.VHIPRangeConflict. Em contrapartida, Edit firewall rule 541 tem Message.FWRuleFailMaxUser; o mesmo código não deve desencadear o mesmo diagnóstico.
Add firewall rule 543 e Edit firewall rule 544 → Message.CannotSetupRedirectionFromHTTP. Add firewall rule 544 e Edit firewall rule 543 → Message.CannotUseDefaultPort. O mapeamento está trocado entre Add e Edit: verificar o listener, a porta e o redirecionamento, não classificar apenas pelo número.
Em Add firewall rule e Edit firewall rule: 542 → Message.CannotUseTypeHTTP, 545 → Message.PortAlreadyExists, 546 → Message.CannotConfigureDomainWithAddrTypePort, 550 → Message.PortUsedInUserPortal, 553 → Message.CannotConfigureDomainWithHTTPSRedirection. Conferir a configuração existente do listener e dos domínios; não alterar permissões de portas com base em suposições.
Em ambas as operações: 547 → Message.warn_update_business_policy; 548 e 549 utilizam ambos Message.MaxIPv4ForAppServerAllowed. O mapeamento duplicado do símbolo não comprova limites diferentes inventados. Verificar o aviso e o estado WAF efetivamente guardado.
Add firewall rule 554 → Message.CannotUseFQDNWildCardAsProtectedServer; Edit firewall rule 554 → Message.CannotUpdateFQDNWildCardAsProtectedServer. Não confundir domínios públicos wildcard com um host de backend adequado. Edit firewall rule 552 → Message.CannotImportDiffPolicytypeWithSameName: verificar o nome e o tipo de política, não substituir um objeto alheio.
Em Add, Edit e Delete firewall rule: 596 → Message.CMLOCALOperationrestriction. Para Delete, constam ainda 200 → Message.FWDelSuccess e 500 → Message.FWRuleDeleteFail. Esclarecer a responsabilidade de gestão e as referências antes de uma nova tentativa. A página de Delete designa Name como opcional e utiliza um texto de descrição inadequado sobre Before/After; isto não constitui um modelo seguro de eliminação. Confirmar o alvo exato e o contrato de Remove específico do build; caso contrário, não eliminar.

O backend e a política de proteção também têm os seus próprios conjuntos de respostas: Add Web Server 200/500/502 correspondem a Message.RealServerAddSuccess/Message.RealServerAddFail/Message.RealServerRecodExist; Update Web Server 200/500 a Message.RealServerUpdateSuccess/Message.RealServerUpdateFail. Add Protection Policy 200/500/502 correspondem a Message.ProtocolSecurityAddSuccess/Message.ProtocolSecurityAddFail/Message.ProtocolSecurityRecodExist; Edit Protection Policy 200/500 a Message.ProtocolSecurityUpdateSuccess/Message.ProtocolSecurityUpdateFail. As grafias RecodExist são mantidas literalmente, não são nomes simbólicos corrigidos. Em caso de colisões de nomes, ler primeiro o objeto existente; eliminar e voltar a criar não é uma forma segura de repetir a operação por predefinição.

Para o objeto global WAFSlowHTTP, RequestHeaderTimeoutEnabled, RequestHeaderTimeoutSoftLimit, RequestHeaderTimeoutHardLimit e RequestHeaderTimeoutExtensionRate correspondem ao controlo e aos três limites explicados acima. Os quatro estão documentados como campos obrigatórios; o controlo indica Disable e Enable, e os restantes valores são inteiros sem intervalo especificado. NetworkExceptions/Host é uma lista opcional de referências a hosts. Os valores do exemplo 10, 30, 5000 não são valores predefinidos comprovados. SlowHTTP Protection indica 200 com Operation Successful. e 500 com Operation Fail.. As alterações continuam a ser globais: verificar os valores guardados e as exceções estritamente delimitadas e validar todas as publicações afetadas com clientes legítimos lentos.

Perguntas frequentes

O WAF substitui a aplicação de patches ao servidor web?

Não. WAF pode detetar ou bloquear ataques, mas não pode compensar permanentemente uma aplicação insegura. O sistema operativo, o servidor web, os frameworks, os plugins e o código da aplicação devem continuar a ser mantidos.

É necessário DNAT adicionalmente?

Normalmente não para a mesma publicação web. A regra WAF trata da publicação através da Hosted address e encaminha para o servidor web protegido. DNAT continua a ser relevante para outros protocolos ou aplicações web não suportadas.

Porque é que o servidor web não vê o IP real do cliente?

A firewall atua como um proxy reverso. Por isso, o servidor web vê frequentemente a firewall como endereço de origem. O IP original do cliente está no cabeçalho X-Forwarded-For, desde que a aplicação ou o servidor web interprete este cabeçalho.

É possível publicar vários sites através do mesmo IP público?

Sim, em HTTPS a firewall utiliza SNI e o nome do host para selecionar a regra WAF adequada ou o servidor web virtual correspondente. Para isso, o DNS, o certificado e os domínios na regra WAF devem corresponder corretamente entre si.

Deve utilizar-se WAF para Nextcloud?

Não sem uma análise cuidadosa. WebDAV está documentado como um caso não suportado por WAF. Como o Nextcloud utiliza WebDAV intensamente, a publicação através de WAF não é adequada em muitos ambientes.

Os Threat Feeds também protegem as regras WAF?

No SFOS 22, os Threat Feeds também podem ser relevantes para tráfego de entrada encaminhado, como nas publicações WAF e DNAT. No entanto, para que isso resulte numa proteção efetiva, é necessário gerir corretamente os feeds, o registo, os alertas, as responsabilidades e o processo de tratamento de falsos positivos.