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 o 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 ao 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 privados quando o acesso deve ser altamente controlado ou não público.

Se é necessárior 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 publicados cegamente via WAF, mas sim planeados usanda firewall apropriado e regras 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.

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.

As regras WAF são voltadas para publicações IPv4. Se uma aplicação precisar ser publicada em IPv6, o design deve ser revisto separadamente. 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.

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.
• O 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 certificados, deve ser esclarecido antecipadamente se um certificado existente será importado, se a firewall deve criar e renovar um certificado Let’s Encrypt ou se um certificado gerado externamente é necessário. Para certificados curinga, há um guia separado: Criar certificado Let’s Encrypt Wildcard.

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 rules

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. Ative Log firewall traffic se a regra deve ser rastreável no Log Viewer e nos relatórios.
9. Em Hosted server details, defina o endereço público, porta de escuta, HTTPS, certificado e domínios.
10. Em Protected servers, selecione o objeto web server adequado ou crie-o primeiro em Web server > Web servers.
11. Configure conscientemente Allowed client networks. Para sites públicos, Any IPv4 pode ser necessário; para portais, uma restrição geralmente é melhor.
12. Se necessário, configure Blocked client networks ou Blocked countries.
13. Revise o perfil de proteção, IPS e opções avançadas.
14. Salve a regra e teste externamente.

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.

Conflitos de porta devem ser esclarecidos antes de salvar. Dependendo da Hosted address, WAF pode usar a mesma porta que SSL VPN, mas não a mesma porta que User Portal. Se WebAdmin, VPN Portal, User Portal ou uma publicação DNAT antiga já estiverem a escutar num IP público, a atribuição deve ser inequívoca. Caso contrário, o erro parecerá mais tarde um problema WAF, embora outra função esteja a responder.

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 do 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. O 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 do 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 depermitidamente 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 o 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 o 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ários aplicações forem executados 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 do 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 Feedss 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 o 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 Feedss 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.

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.

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 um 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.

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 um 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.

Deve-se observar que a firewall não avalia rotas simplesmente com base na ordem das linhas da tabela. A Sophos prioriza rotas mais longas e, portanto, mais específicas. Rotas específicas devem ser cuidadosamente planeadas e testadas. Se WebSocket for necessário, WebSocket passthrough poderá ser ativado. O tráfego WebSocket é transmitido sem a mesma inspeção WAF, pois o protocolo não pode ser inspecionado da mesma forma que o tráfego HTTP normal.

O caminho padrão / deve permanecer definido conscientemente. Se for removido, caminhos não correspondentes não são encaminhados para um servidor padrão, mas rejeitados com 404 Not Found. Isto pode ser intencional, mas em caso de erro rapidamente parece um problema de backend.

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.

Se o servidor web protegido não estiver na rede local da firewall, o encaminhamento e o SD-WAN devem ser revistos com especial cuidado. Para backends sobre links de sede, MPLS ou IPsec baseado em rota, uma rota SD-WAN apropriada pode ser necessária para que a firewall alcance de forma confiável o servidor protegido e o caminho de retorno esteja correto. No IPsec baseado em rota também é importante: a Sophos não suporta WAF via IPsec baseado em rota com Traffic Selectors para sub-redes; conexões Any-to-Any são o caminho documentado.

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: O 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.
• Aplicativo WebDAV publicado por WAF: O aplicação não funciona de maneira confiável ou não é suportado.
• 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.

Lista de verificação para regras produtivas WAF

• O nome da regra descreve o 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