Sophos Firewall WAF: Publique servidores web com segurança

Web Server Protection ou Web Application Firewall (WAF) publica aplicações web internas ou baseadas na cloud por meio de Sophos Firewall. A firewall atua como um proxy reverso: os clientes ligam-se ao endereço público da firewall, a firewall inspeciona o tráfego HTTP ou HTTPS e encaminha a solicitação ao servidor web protegido.

Para o contexto geral de hardening, consultar 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, aplicação de patches, autenticação forte ou proteção de servidor. No entanto, comparado a um simples encaminhamento de porta, reduz significativamente a superfície de ataque, pois o tráfego HTTP(S) pode ser inspecionado, restrito e registrado mais especificamente.

Mesmo assim, WAF não é automaticamente a resposta correta para todas as postagens. O que é crucial é se a aplicação realmente funciona bem em HTTP ou HTTPS, se a firewall deve avaliar nomes de host e rotas e se a camada adicional de proxy reverso é adequada à aplicação.

Decisão antes da publicação

Quando é conveniente usar WAF em vez de DNAT

Para serviços TCP ou UDP simples, NAT e regras de firewall ainda são usadas. Para aplicações web, WAF geralmente é a melhor escolha.

• DNAT é adequado para serviços não HTTP, encaminhamento de porta simples e protocolos especiais. Nesse caso, a firewall principalmente traduz e permite o tráfego.
• WAF / Web Server Protection é adequado para aplicações HTTP e HTTPS quando nome de host, certificado, rotas, perfis de proteção, autenticação ou regras de 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 altamente controlado ou não público.

Se for necessário apenas tornar rapidamente um servidor web interno acessível via encaminhamento de porta, o guia Publicar servidor usando DNAT para Sophos Firewall pode ser útil. Para aplicações web públicas, WAF deve ser considerado primeiro.

⚠️ Sophos WAF não suporta WebDAV. Portanto, aplicações como Nextcloud não devem ser publicadas cegamente via WAF, mas sim planeadas com regras adequadas de firewall e NAT ou outra arquitetura de publicação.

Decisão: WAF, DNAT ou acesso privado

A questão mais importante não é a rapidez com que uma versão pode ser construída, mas se ela pode ser operada, testada e desativada com segurança posteriormente. Esta classificação ajuda antes da implementação técnica:

• Site público ou aplicação HTTPS simples: WAF geralmente é o ponto de partida apropriado. DNS, certificado, nome do host, perfil de proteção, criação de log e acessibilidade de backend devem ser testados.
• Portal do Cliente, Portal do Parceiro ou Interface Administrativa: WAF com limitação de fonte e opcionalmente MFA pode fazer sentido. Deve primeiro ser esclarecido se WAF-MFA, regras do país ou redes domésticas fixas são possíveis.
• Serviço TCP ou UDP puro: DNAT geralmente é uma opção melhor. A regra de firewall, a regra NAT, o servidor de destino, o caminho de retorno e o registo devem ser revistos em conjunto.
• Aplicação Web com WebDAV ou protocolo especial: não utilize WAF automaticamente. Teste recursos suportados, comportamento do cliente e publicação alternativa.
• Aplicativo apenas para utilizadores internos: revisão VPN, ZTNA ou WAF fortemente restrita. A acessibilidade pública deve ser questionada criticamente.

Para aplicações privadas, uma regra WAF acessível globalmente geralmente representa uma superfície de ataque muito grande. Se apenas algumas pessoas precisarem de acesso, as redes domésticas fixas, VPN, ZTNA ou outra arquitetura de acesso privado são geralmente mais limpas do que uma publicação pública na web.

Planeamento e pré-requisitos

Pré-requisitos

Antes da primeira regra WAF, estes pontos devem ser esclarecidos:

• Nome público DNS, por exemplo, portal.example.com
• Endereço IP público ou alias na interface WAN
• Certificado para o nome do host publicado
• Endereço IP interno ou FQDN do servidor web
• Porta de destino interna do servidor web
• Decisão se HTTP será redirecionado para HTTPS
• Redes domésticas, países ou grupos de utilizadores permitidos
• Perfil de proteção apropriado e política IPS opcional
• Log ativado para análise posterior
• Acesso de teste externo fora de LAN

O nome público DNS deve apontar para o endereço utilizado na regra WAF como Hosted address. Em HTTPS, o certificado deve corresponder ao nome do host publicado.

Além disso, a firewall precisa de um objeto web server em Web server > Web servers. Aí é descrito o servidor de destino interno ou externo com host, protocolo e porta. O host é um objeto IP ou FQDN. Para backends são possíveis HTTP ou HTTPS; as portas padrão são 80 e 443. Se o servidor web backend entregar respostas longas ou precisar de keep-alive, Keep alive e Timeout devem ser verificados conscientemente em vez de serem aceites por acaso.

O Timeout do backend pode variar entre 1 e 65,535 segundos; o valor padrão é 300 segundos. Quando 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 usada numa análise de erro dirigida e depois reposta no estado inicial documentado.

Além disso, os limites de Web Server Protection devem ser considerados antecipadamente. A Sophos menciona, entre outros, um limite de 60 regras WAF por firewall. Isso é suficiente para muitos ambientes, mas pode se tornar relevante mais cedo do que o esperado com muitos portais de clientes, locatários, sistemas de teste ou nomes de host separados. Portanto, não devem ser criadas mais regras individuais sem pensar, mas sim rever o conceito de nomes, rotas, servidores web virtuais e caminhos de publicação alternativos.

O SFOS 22 não suporta regras WAF através de IPv6. Por isso, uma aplicação não deve 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 são uma autorização geral para ambientes modernos do Exchange: os documentos Sophos que regem WAF atualmente não suportam versões do Exchange posteriores a 2013.

Os modelos pré-configurados pertencem a um cenário de aplicações Microsoft mais antigo: Exchange Autodiscover, Outlook Anywhere e Exchange General terminam no limite do 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, métodos de autenticação e políticas 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.

Planeja lançar WAF antes da configuração

A regra WAF não deve ser escalonada apenas na interface. Deve primeiro ficar claro se o Sophos Firewall deve apenas publicar ou se também deve cuidar da autenticação, dos perfis de proteção, das regras do país e do registo.

Estas perguntas são importantes antes de uma postagem produtiva:

• Esta é realmente uma aplicação HTTP ou HTTPS? Para outros protocolos, DNAT geralmente é mais adequado.
• A aplicação deve ser acessível publicamente? Portais de gestão privados geralmente se adaptam melhor a redes VPN, ZTNA ou redes de origem restrita.
• Qual nome de host e certificado serão usados? Os domínios DNS, SNI, certificado e WAF devem corresponder.
• Quantas publicações estão planeadas? O limite da regra WAF e a subsequente operabilidade influenciam o design.
• A firewall deve autenticar os utilizadores? Para portais, WAF-MFA pode ser útil.
• Quais perfis de proteção estão ativos? Exceções muito amplas enfraquecem WAF, perfis muito rígidos podem quebrar aplicações.
• Como ele será registrado e testado? Log Viewer, reverseproxy.log e logs de back-end devem ser conhecidos antes da entrada em operaçã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 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 regra WAF

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 onde 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 do 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: fontes 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.

O Sophos cria regras WAF na área Firewall Rules. 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 dela. É criada uma publicação de proxy reverso. Por isso, Hosted address, Listening port, Domains, certificado, Protected server e Allowed client networks devem corresponder. Se um desses campos não corresponder, o erro geralmente parece um problema de certificado, DNS ou backend.

Criar uma regra WAF

O caminho do menu é:

Rules and policies > Firewall

Procedimento:

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.

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

SFOS 23: Publicar caminhos em Traffic routing

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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 é salva, o Sophos reinicia as regras do Web Server Protection. As ligações ativas existentes por meio dessas regras podem ser interrompidas. Portanto, alterações nas regras produtivas do WAF devem ser feitas em uma 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.

Entrada em operação e aceitação

Planear entrada em operação e reversão

Uma publicação WAF não deve ser considerada completa apenas por salvar a regra. O crucial é se DNS, certificado, Hosted address, backend, perfil de proteção e registo funcionam juntos. Especialmente em port forwards existentes, a mudança deve ser tratada como uma pequena publicação.

Antes de entrar em operação, verifique:

• Documente a configuração atual da firewall ou pelo menos as configurações de regras e certificados afetadas.
• Identifique DNAT anteriores ou regras de firewall que afetam a mesma porta, IP público ou nome de host.
• Desative as regras DNAT antigas ou documente claramente por que elas não competem com a regra WAF.
• Reduza o TTL de DNS antes de uma alteração se o nome do host público mudar de uma publicação antiga para WAF.
• Fornece acesso de teste externo, não apenas teste do LAN interno.
• Definir casos de teste: home page, login, upload, download, rota API, WebSocket, logout e mensagem de erro.
• Definir pontos de log esperados: Log Viewer, reverseproxy.log, log de acesso de backend e log de erros de backend.
• Defina critérios de reversão, por exemplo, login não possível, back-end não acessível, certificado inválido, alta taxa de erros ou partes críticas da aplicação com defeito.

Durante a troca, apenas uma publicação deve estar ativa por vez. Se uma regra DNAT antiga e uma nova regra WAF usarem o mesmo IP e porta públicos, o comportamento será difícil de entender. Antes de passar para a produção, deve ficar 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. Caso DNS também tenha sido alterado, deve ser considerado o TTL de DNS. No caso de problemas com certificados ou nomes de host, uma reversão apenas via DNS geralmente é muito lenta; nesses casos, a regra antiga deve poder ser reativada na mesma Hosted address ou deve existir um acesso alternativo.

Após o Go-live, os primeiros acessos devem ser monitorados ativamente. Não apenas os códigos de status HTTP bem-sucedidos são importantes, mas também travamentos do WAF, erros de back-end, redirecionamentos inesperados, problemas de sessão e informações de IP do cliente ausentes nos logs de back-end.

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

Um teste WAF só é concluído quando a mesma solicitação pode ser rastreada a partir de três perspectivas: cliente, firewall e backend. Isso permite identificar mais rapidamente se um problema está no DNS, certificado, correspondência WAF, perfil de proteção ou aplicação.

• Cliente externo: revise resolução DNS, certificado, status HTTP, login e rotas importantes. A aplicação deve abrir usando o nome de host público sem aviso de certificado.
• Sophos Firewall: revise Log Viewer, regra WAF, reverseproxy.log e assinaturas bloqueadas. A regra WAF correta deve processar o acesso e os logs devem mostrar solicitações permitidas ou bloqueadas com justificativa.
• Servidor web backend: revise log de acesso, log de erros, sessão da aplicação e X-Forwarded-For. A solicitação deve chegar ao vHost ou rota correta e a lógica do IP do cliente deve ser compreendida.

Para aplicações produtivas, pelo menos estes casos devem ser testados:

• Acesso através do nome de host correto e através de um domínio incompatível.
• Login com utilizador válido e inválido, caso a aplicação ou WAF autentique.
• Função de upload, download, API ou WebSocket, caso a aplicação utilize tais funções.
• Acesso de uma fonte permitida e, se possível, de uma fonte deliberadamente não permitida.
• Comportamento de uma solicitação de teste WAF conhecida e inofensiva, de forma que o log e o caminho de bloqueio fiquem visíveis.

Se a aplicação parecer funcionar após o Go-live, mas nenhum log correspondente for visto, o teste ainda não foi concluído. Pode ser que outra publicação corresponda, falte o registo ou o acesso não seja pelo caminho esperado.

Garantir proteção e acesso

Certificados e nomes de host

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

Pontos importantes:

• O nome DNS deve corresponder ao certificado.
• O certificado HTTPS selecionado pode preencher automaticamente a lista de domínios na regra WAF ou sobrescrever entradas de domínio existentes.
• Com vários nomes de host no mesmo IP, a firewall usa SNI.
• Certificados curinga são possíveis, mas devem ser devidamente documentados.
• Domínios wildcard só são usados depois de regras de domínio mais específicas.
• Underscores no label esquerdo do domínio não são um nome DNS limpo e devem ser evitados para domínios WAF.
• O backend pode usar um nome interno diferente se o cabeçalho do Host e a aplicação puderem lidar com isso.
• Em caso de problemas com links absolutos, Rewrite HTML pode ser relevante.

Se vários servidores web virtuais forem executados no mesmo IP e porta, a firewall decide em HTTPS com base no SNI e no nome do host qual regra WAF é apropriada.

Os domínios da regra WAF devem corresponder exatamente a DNS e ao certificado. Os curingas podem ajudar, mas não devem substituir um conceito de publicação limpo. Se várias aplicações forem executadas sob nomes de host semelhantes, será necessária uma documentação clara de regras e certificados; caso contrário, posteriormente será difícil entender qual regra WAF realmente correspondeu. Um teste com um subdomínio deliberadamente não correspondente é útil: assim se percebe se responde a regra específica, uma regra wildcard ou nenhum servidor web virtual correspondente.

Planear IP do cliente e logs de back-end

Nas publicações WAF, o servidor web interno geralmente não vê o IP real do cliente como um endereço de origem direto. Sophos Firewall atua como um proxy reverso e estabelece sozinho a ligação com o backend. Portanto, para os logs da aplicação e do servidor web, o endereço da firewall pode ficar visível primeiro.

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

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

O limite de confiança é importante: um backend só deve tratar esses cabeçalhos como de confiança se a solicitação realmente vier de Sophos Firewall ou de um proxy reverso definido. Os clientes públicos não devem poder definir X-Forwarded-For diretamente como um teste de segurança. Na prática, o servidor web deve confiar apenas no IP da firewall e ignorar ou sobrescrever cabeçalhos de outras fontes.

Para resolução de problemas, isso significa: Log Viewer, reverseproxy.log e o log de backend devem cobrir o mesmo tempo de teste. Se apenas o IP da firewall estiver visível no backend, não é automaticamente um erro WAF, mas geralmente um comportamento normal do proxy reverso.

Restringir acesso do cliente

Nem todas as aplicações web devem ser globalmente acessíveis. O acesso já pode ser limitado na regra WAF.

Restrições sensatas:

• Permitir apenas endereços IP de origem conhecidos ou redes parceiras.
• Bloqueie países desnecessários.
• Bloqueie endereços IP de origem de países desconhecidos apenas se o risco de autobloqueio tiver sido avaliado.
• Para portais utilizar adicionalmente WAF-MFA ou pré-autenticação.
• Bloqueie fontes maliciosas conhecidas via Threat Feeds.

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

Programação Threat Feeds e Active Threat Response

Em aplicações web acessíveis ao público, não apenas a regra WAF em si deve ser considerada. Desde SFOS 22, os Threat Feeds também são relevantes para o tráfego de entrada e encaminhamento como as publicações WAF e DNAT. A firewall pode comparar essas correspondências 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 adicionais conhecidas. No entanto, isso não substitui a gestão de patches, a autenticação limpa e o fortalecimento de aplicações.

Na prática, deve-se verificar o seguinte:

• Active Threat Response está configurado adequadamente em seu ambiente?
• Os Threat Feeds relevantes são usados e revistos regularmente?
• Os eventos WAF, logs Active Threat Response e logs de back-end são visíveis em operação?
• Existe um processo para falsos positivos, listas brancas e autorizações de emergência?
• Está claro quem reage às correspondências e se elas são apenas registradas ou bloqueadas ativamente?

Principalmente em portais de clientes, interfaces de administração ou acessos de parceiros, esta revisão deve ser realizada antes do Go-live. Se um feed bloquear posteriormente o tráfego de produção, a operação deve saber onde a correspondência é vista e como decidir de forma clara: ataque real, alarme falso ou aplicação mal publicada.

Perfis de proteção e exceções

Uma regra WAF deve não apenas publicar, mas também proteger. Para isso, são utilizadas 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 URL
• Endurecimento de Forma
• Script entre sites
• Ataques a aplicações
• Inspeção antivírus
• Clientes com má reputação

Em Web server > General settings existem definições globais adicionais para Web Server Protection, incluindo controlo de versões TLS e proteção contra padrões 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 início de sessão, fim de sessão e mudança de sessão.

Em Slow HTTP protection, Soft limit é o timeout 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 a uma rede restrita. 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 uma ligação externa 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 o reverseproxy.log verificado; se o serviço não arrancar, devem ser restaurados os últimos valores personalizados em vez de se testarem mais variantes em produção.

Nas Protection Policies, 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 piloto, mas para proteção produtiva deve estar claro se os ataques são apenas observados ou realmente rejeitados.

O Common threat filter trabalha com quatro Filtering Strengths. 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 false positives. Só devem ser ignoradas regras individuais com base no Rule ID comprovado no log, em Skip filter rules. Desativar globalmente uma categoria inteira ou um nível superior não substitui esta análise.

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 request, não a cada ficheiro individual. O Request size limit adicional para o body HTTP varia de 1 a 1,024 MB e tem o valor padrão de 10 MB. HTTP Strict Transport Security só adiciona o header HSTS quando a regra WAF utiliza Redirect HTTP; MIME-type sniffing protection define X-Content-Type-Options: nosniff. Por isso, uploads, downloads e headers 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 firewall e web server usa 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 estiver funcionando devido a um caminho específico ou a uma determinada fonte, todo o perfil de proteção não deve ser desativado. Uma exceção específica com caminho, origem e justificativa claros é melhor.

⚠️ Cada exceção reduz a eficácia da proteção. A rota, a origem, o motivo, a data e a data da revisão devem ser documentadas para que as correções temporárias não se tornem permanentes.

Voltar a validar Protection Policies migradas

Desde o SFOS 18, a Web Server Protection utiliza o OWASP ModSecurity Core Rule Set 3.0. Durante a migração de Protection Policies anteriores, as categorias existentes foram combinadas, os Rule IDs foram reatribuídos e foram introduzidas Filtering Strengths. 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 policy. As categorias ativas, as exceções e as Filtering Strengths devem ser verificadas com a documentação anterior. Em seguida, realizam-se testes positivos e negativos controlados com tráfego real da aplicação e verificam-se o Log Viewer e o reverseproxy.log. A policy migrada só fica validada quando os pedidos legítimos continuam a funcionar e os ataques de teste esperados são detetados.

Encaminhamento Específico de Caminho, WebSocket e Balanceamento de Carga

WAF pode encaminhar solicitações para diferentes servidores backend com base no caminho. Isso é útil quando uma aplicação possui vários componentes ou um único nome de host está espalhado 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.

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 workaround. 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 padrão / encaminha os pedidos sem correspondência mais específica para o servidor padrão atribuído. Se esta rota padrão 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, sessões persistentes ou hot standby 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.

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

Se o servidor web protegido não estiver na rede local da firewall, o routing 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 endereçada 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:

1. Destination networks corresponde à interface WAN pública ou Hosted address através da qual o cliente alcança a regra WAF.
2. Services contém o Listening Port externo da regra WAF. Se for diferente da porta interna do backend, deve ser usada explicitamente a porta externa.
3. Em Primary gateway, seleciona-se o gateway XFRM criado anteriormente.
4. 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.

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 reverse proxy 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

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 exibem erros de certificado ou a correspondência de SNI não corresponde.
• Hosted address incorreta escolhida: a firewall corresponde a outra regra ou não vê o tráfego WAF.
• Allowed client networks vazias: a regra não funciona conforme o esperado.
• Limite de regra WAF não considerado: Nenhuma outra postagem pode ser renderizada corretamente.
• Lançamento planeado do Exchange pós-2013 com modelo WAF: O modelo não se ajusta ao limite WAF suportado.
• Conflito de porta com User Portal, VPN Portal ou outro serviço: A aplicação não está acessível ou um serviço de firewall está respondendo.
• Backend não acessível internamente: clientes externos recebem erros mesmo que DNS e certificado estejam corretos.
• Timeout de backend mal definido: respostas longas terminam com erros, embora a aplicação esteja basicamente acessível.
• Backend via VPN ou SD-WAN sem rota adequada: A regra WAF corresponde, mas o Servidor Protegido não é alcançado de forma confiável.
• IPsec baseado em rota com Traffic Selectors para o backend: WAF para esta rota não é suportado.
• Exceção WAF muito ampla: A eficácia da proteção é reduzida desnecessariamente.
• Aplicação WebDAV publicada por WAF: A aplicação não funciona de maneira confiá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 reiniciando as regras WAF.
• A antiga regra DNAT e a nova regra WAF competem: Não está claro qual publicação está processando o tráfego.

Resolução de problemas

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

1. O nome público DNS aponta para o IP público correto?
2. A Hosted address correta foi selecionada na regra WAF?
3. A porta de escuta está livre e não ocupada por WebAdmin, User Portal, VPN Portal ou outra publicação?
4. O certificado corresponde ao nome do host chamado?
5. O servidor web interno pode ser acedido pela firewall?
6. Allowed client networks, Blocked client networks e Blocked countries estão configuradas corretamente?
7. O Servidor Protegido está atrás de uma rota, Rota SD-WAN ou VPN que realmente se ajusta a partir de uma perspectiva de firewall?
8. Existe uma regra WAF mais geral que corresponda antes?
9. O acesso consta em Log Viewer como permitido, bloqueado ou dispensado?
10. Há alguma pista em /log/reverseproxy.log?
11. A Protection Policy está definida como Monitor ou Reject?
12. O timeout do objeto web server é adequado à aplicação?

Para análise inicial, Log Viewer é útil. Para uma resolução de problemas mais profunda, os logs do Web Server Protection na firewall são úteis. Uma visão geral dos ficheiros de log e serviços está em Mapear corretamente os logs de serviço Sophos Firewall.

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 quando é acedido 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 um workaround suportado.

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

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

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 produtivas WAF

• O nome da regra descreve a aplicação, o nome do host e o ambiente.
• A pessoa responsável ou proprietário do sistema está documentada.
• DNS, certificado e Hosted address são verificados.
• A acessibilidade de back-end foi testada a partir da firewall.
• A postagem anterior e a reversão estão documentadas.
• DNAT ou regras de firewall mais antigas não competem com a regra WAF.
• Testes Go-live externos são definidos.
• O acesso é restrito às fontes ou 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 é desativado desnecessariamente.
• As exceções são restritas, justificadas e temporárias.
• A alteração foi testada externamente.
• A data de vencimento ou data de revisão está documentada.

Perguntas frequentes