Proteger o WAF do Sophos Firewall com MFA

Com o Sophos Firewall WAF MFA, é possível proteger aplicações web publicadas através do Web Application Firewall com Autenticação Multifator adicional. Isto é especialmente útil para portais internos, interfaces de administração, áreas de clientes ou acessos de parceiros que têm de estar acessíveis através de HTTPS, mas que não devem depender apenas da proteção da própria aplicação.

O WAF-MFA não substitui uma aplicação segura, gestão de patches ou um conceito de permissões bem estruturado. É uma camada de proteção adicional na firewall. A firewall verifica primeiro o login e o segundo fator antes de encaminhar o acesso ao servidor web protegido.

A versão é importante: o MFA integrado para WAF é uma funcionalidade do SFOS 22. Em versões de firmware mais antigas, as publicações WAF devem ser planeadas com outras arquiteturas, por exemplo autenticação externa, reverse proxy dedicado, VPN ou ZTNA.

Para a publicação básica de um servidor web através do WAF, siga primeiro as instruções em Sophos Firewall WAF: Publicar servidores web com segurança. Este artigo foca na autenticação prévia e no MFA.

Utilização e planeamento

Quando o WAF-MFA é útil

O WAF-MFA é especialmente eficaz quando uma aplicação web tem de estar acessível a partir da Internet, mas não se destina ao público em geral.

Casos típicos de uso:

• portais internos com acesso externo
• interfaces de administração de aplicações especializadas
• portais de parceiros ou clientes com um grupo de utilizadores limitado
• aplicações web legadas sem MFA robusto próprio
• aplicações onde é desejada uma proteção de acesso adicional antes do backend

Para sites públicos, lojas ou páginas informativas, o WAF-MFA normalmente não é adequado, pois cada visitante veria primeiro um login na firewall. Para aplicações privadas complexas, ZTNA, SSE ou um proxy reverso dedicado podem ser mais adequados do que o WAF-MFA. Se for necessário WebDAV, é preciso ter especial cuidado: o Sophos WAF não suporta corretamente o WebDAV, o que pode ser relevante para aplicações como o Nextcloud.

Quando o WAF-MFA não é suficiente

O WAF-MFA é uma camada de acesso prévia. No entanto, esta camada não responde a todas as questões de arquitetura. Especialmente nos portais críticos, é preciso decidir conscientemente se a aplicação deve estar acessível ao público.

• A aplicação destina-se apenas a alguns utilizadores internos: Verificar VPN, ZTNA, redes de origem fixas ou uma publicação não pública.
• A aplicação contém dados particularmente sensíveis: Verificar também as permissões do backend, o logging, a pista de auditoria e as sessões da aplicação.
• A aplicação necessita de WebDAV ou protocolos especiais: Testar a compatibilidade do WAF antes da implementação ou escolher outra arquitetura.
• Os parceiros externos acedem raramente: Documentar claramente a implementação de tokens, o processo de suporte e o fallback.
• O backend tem o seu próprio login e funções: Considerar o WAF-MFA apenas como uma camada adicional, não como substituto das funções do backend.

Se um portal permanecer acessível mundialmente, o MFA não deve ser a única medida. Redes de origem fixas, limitação de países, Threat Feeds, perfis de proteção e patches de backend bem aplicados reduzem o risco adicionalmente.

Pré-requisitos

Antes da configuração, os seguintes pontos devem ser esclarecidos:

• A aplicação web já está planeada ou publicada através de uma regra WAF.
• A firewall executa SFOS 22 ou posterior.
• Utilizadores ou grupos estão presentes na firewall, por exemplo, localmente, via AD, LDAP ou RADIUS.
• Os utilizadores conseguem configurar o respetivo token OTP.
• A hora do sistema da firewall está correta e o NTP funciona.
• Para a regra WAF, é utilizado HTTPS com um certificado adequado.
• Está definido se o servidor web de backend necessita de autenticação própria ou se a firewall deve assumir totalmente o login.
• Um utilizador de teste e um acesso administrativo de fallback estão disponíveis.

⚠️ O MFA para WAF deve ser testado primeiro com um grupo piloto. Uma combinação incorreta de grupo MFA, política de autenticação WAF e autenticação de backend pode bloquear utilizadores legítimos ou fazer com que uma aplicação pareça “avariada”.

Planear piloto, fallback e responsabilidades

O WAF-MFA atua antes da aplicação propriamente dita. Portanto, o rollout não deve ser tratado como uma regra de firewall normal, mas como uma alteração no processo de login da aplicação. Os utilizadores veem primeiro o login do Sophos Firewall e só depois, dependendo do backend, a aplicação propriamente dita.

Antes de ativar, os seguintes pontos devem estar definidos:

• Qual grupo de utilizadores testa primeiro?
• Quem pode desativar o acesso se o login falhar?
• Existe um segundo acesso de administrador que não depende da mesma regra WAF, do mesmo portal ou do mesmo utilizador de teste?
• Quais partes da aplicação devem ser testadas após um login bem-sucedido?
• Quem verifica reverseproxy.log, Log Viewer e logs de backend em caso de erros?
• Como os utilizadores serão informados sobre tokens, expiração de sessão e possível segundo login no backend?

Um erro comum de planeamento é misturar a autenticação da firewall com a autenticação do backend. O WAF pode verificar os utilizadores antes do backend. Isto não significa automaticamente que a própria aplicação deixe de necessitar de login, verificação de funções ou gestão de sessões. Especialmente nos portais de administração e nos dados de clientes, as permissões do backend devem ser mantidas de forma consciente.

Se o serviço publicado se destinar a poucas pessoas, devem restringir-se as origens além de aplicar MFA. Para a publicação básica e a limitação de origens, consulte Sophos Firewall WAF: Publicar servidores web com segurança. Se forem planeados direitos de utilizador ou MFA para acesso remoto, consulte Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Acesso Remoto.

Um rollback deve ser preparado antes da ativação. Na prática, isso significa: documentar o método de acesso antigo e funcional, nomear a regra WAF e a política de autenticação, definir a pessoa responsável e escolher um momento em que o feedback dos utilizadores e a verificação dos logs sejam possíveis. Se a aplicação for crítica para o negócio, o WAF-MFA deve ser ativado primeiro para um domínio de teste, um grupo piloto ou uma janela de manutenção.

Configuração

Componentes da configuração

Para o WAF-MFA, várias configurações devem estar alinhadas:

• Configuração de MFA: Define quais os utilizadores que usam MFA e se a Web application firewall é protegida.
• Política de autenticação WAF: Define o modo de login, utilizadores/grupos, template e comportamento da sessão.
• Regra WAF: Associa o servidor web publicado à política de autenticação.
• Encaminhamento de autenticação do backend: Define se a firewall transmite dados de login ao servidor web.
• Implementação de tokens: Garante que os utilizadores conseguem realmente gerar o respetivo código OTP.

A diferença mais importante: o MFA não é ativado apenas globalmente. A regra WAF afetada também deve usar uma política de autenticação adequada.

Ativar MFA para WAF

O caminho do menu é:

Authentication > Multi-factor authentication

Procedimento:

1. Em One-time password (OTP), selecione All users ou Specific users and groups.
2. Em Specific users and groups, adicione os utilizadores ou grupos afetados.
3. Ative Generate OTP token with next sign-in se os utilizadores tiverem de configurar o respetivo token no próximo login.
4. Em Require MFA for, ative a opção Web application firewall.
5. Defina conscientemente OTP hash algorithm e, se necessário, OTP timestep settings.
6. Guarde a configuração.

Se Generate OTP token with next sign-in estiver ativo, User portal é selecionado automaticamente como serviço para a configuração inicial do código QR. Os utilizadores devem conseguir ver o código QR num portal antes de o primeiro login WAF-MFA ser realista. Dependendo do ambiente, VPN Portal ou WebAdmin também podem ser relevantes. O planeamento geral do MFA está descrito em Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Acesso Remoto.

Preparar a implementação de tokens e a comunicação com os utilizadores

Em operação, o WAF-MFA falha muitas vezes não devido à própria regra WAF, mas devido à implementação dos tokens. Os utilizadores têm de saber onde aparece o código QR, qual a aplicação a utilizar, durante quanto tempo a sessão é válida e se, depois do login na firewall, ainda existe um segundo login na aplicação.

Antes de ativar a regra WAF de produção, é preciso definir:

• Criação do token: Onde configura o utilizador o token OTP?
• Acesso ao portal: O User Portal ou outro caminho previsto para o código QR está acessível aos utilizadores afetados?
• Aplicação de autenticação: Qual é a aplicação aprovada e testada com o algoritmo escolhido?
• Fallback: Quem pode repor um token perdido ou com defeito?
• Códigos de emergência: Está definido se, e como, podem ser emitidos códigos únicos adicionais num caso de suporte?
• Caso de suporte: De que informações necessita o helpdesk em caso de problemas de login?
• Comunicação: Que sequência de login verão os utilizadores a partir do go-live?

Se for utilizada a opção Generate OTP token with next sign-in, o primeiro login deve ser testado de forma controlada. É importante verificar se os utilizadores veem o código QR no portal esperado e se conseguem aceder à aplicação WAF com a palavra-passe e o OTP. Os próprios portais são descritos em Portais do Sophos Firewall: WebAdmin, User Portal e VPN Portal.

Para muitos serviços da firewall, o código OTP é processado como uma combinação de palavra-passe e passcode. A comunicação aos utilizadores e o runbook do helpdesk devem indicar claramente que ecrã de introdução os utilizadores veem realmente e se palavra-passe e OTP devem ser introduzidos separadamente ou combinados. Com WAF-MFA e login baseado em Form, este ponto é particularmente importante, porque um segundo login de backend é rapidamente interpretado como “MFA avariado”.

Sophos Authenticator já não deve ser planeado como nova aplicação padrão, porque a app está End of Life desde 2022. Na prática, devem ser testados Intercept X for Mobile, Google Authenticator, Microsoft Authenticator, Duo Mobile, Okta Verify ou uma app aprovada internamente. O que importa não é apenas o nome da app, mas se suporta corretamente o algoritmo escolhido, o timestep e o código QR da firewall.

Para o helpdesk e a operação, deve documentar-se pelo menos:

• nome do host publicado da aplicação WAF
• grupo de utilizadores afetado
• política de autenticação utilizada
• algoritmo OTP utilizado
• aplicação de autenticação permitida
• procedimento para reposição do token
• mensagem esperada para palavra-passe ou OTP incorretos
• locais de log para verificação inicial: Log Viewer e reverseproxy.log

Especialmente para parceiros externos ou portais raramente utilizados, o primeiro login não deve ocorrer apenas numa emergência de produção. Um breve piloto com utilizadores normais revela muitas vezes problemas que os administradores não veem nos próprios testes: uma aplicação de autenticação diferente, falta de acesso ao portal, um segundo login no backend pouco claro ou timeouts de sessão demasiado curtos para a aplicação.

Criar uma política de autenticação WAF

O caminho do menu é:

Web server > Authentication policies

Para o WAF-MFA, o modo do cliente deve ser definido como Form. Com autenticação baseada em formulário, a firewall pode controlar o login através de um formulário e sessões.

Procedimento:

1. Abra Add.
2. Dê um nome descritivo, por exemplo, WAF_MFA_Portal_Users.
3. Em Mode, selecione a opção Form.
4. Selecione um Authentication template adequado.
5. Selecione os utilizadores ou grupos que terão acesso a esta publicação WAF.
6. Escolha conscientemente o Authentication forwarding mode.
7. Defina Session timeout e Session lifetime de acordo com a aplicação.
8. Guarde.

Escolher corretamente o encaminhamento de autenticação

O Authentication forwarding mode decide o que acontece entre a firewall e o backend.

• None: A firewall autentica o utilizador e o servidor web não recebe dados de login.
• Basic: A firewall transmite o nome de utilizador e a palavra-passe ao backend através de HTTP Basic Authentication.

Se a aplicação não precisar de autenticação própria ou se o login prévio na firewall for suficiente, None é muitas vezes mais limpo. Se o backend esperar HTTP Basic Authentication, o modo de encaminhamento deve corresponder à aplicação.

Com None, também é necessário verificar se deve ativar-se Remove basic header. Isto evita que um cabeçalho Basic Authentication enviado pelo cliente seja encaminhado desnecessariamente para o servidor web. É especialmente importante quando clientes antigos, dados guardados no browser ou publicações anteriores ainda geram cabeçalhos Basic.

⚠️ A autenticação Basic só deve ser utilizada com HTTPS. Além disso, deve estar claro se o backend deve realmente processar os dados de login transmitidos pela firewall.

O modo de cliente Basic não cria cookies de sessão nem oferece um logout dedicado. Por isso, a Sophos exige o modo de cliente Form para WAF-MFA. Independentemente disso, o Authentication forwarding mode deve corresponder ao backend.

Usar a política de autenticação na regra WAF

A regra WAF é editada em Rules and policies > Firewall rules. A ação é Protect with web server protection.

Na regra WAF afetada, os seguintes pontos devem estar alinhados:

• Endereço Hosted address e porta de escuta corretos.
• Domínio correto e certificado HTTPS adequado.
• Servidor web protegido correto.
• Política de Authentication policy desejada selecionada.
• Grupo de utilizadores na política de autenticação corresponde ao grupo MFA.
• Restrições de acesso através de Allowed client networks, países ou Threat Feeds são definidas conscientemente.

Para portais públicos ou fortemente expostos, o MFA não deve ser a única medida de proteção. Limitação de países e fontes é descrita em Sophos Firewall: Bloquear países e IPs maliciosos. Para listas de bloqueio dinâmicas, veja Sophos Firewall Threat Feeds.

Planear sessões e timeout

Com autenticação WAF baseada em formulário, a firewall trabalha com sessões. Na política de autenticação, define-se:

• Session timeout: após qual inatividade os utilizadores devem fazer login novamente
• Session lifetime: quanto tempo um login permanece válido no máximo

Além disso, em Web server > General settings, há o número máximo de sessões simultâneas para autenticação de proxy reverso baseada em formulário. O valor padrão é 25,000, o intervalo suportado é de 100 a 100,000.

Sessões curtas aumentam a segurança, mas podem incomodar os utilizadores. Sessões muito longas são mais cómodas, mas aumentam o risco de um acesso ao browser roubado ou partilhado permanecer utilizável durante mais tempo. Nos portais de administração, deve começar-se de forma conservadora e observar o comportamento em operação.

Se muitos utilizadores ou vários portais WAF usam a mesma firewall, o limite global de sessões não deve ser verificado apenas quando surgem erros. A autenticação WAF baseada em Form é um parâmetro operacional partilhado do reverse proxy e deve entrar no planeamento de capacidade e monitorização.

Algoritmo OTP e aplicação de autenticação

Além de SHA1, o SFOS 22 suporta SHA256 e SHA512 para tokens OTP. Isto é adequado do ponto de vista da segurança, mas só funciona se a aplicação de autenticação utilizada suportar o algoritmo escolhido.

Pontos importantes:

• SHA256 ou SHA512 são mais seguros que SHA1.
• Nem todas as aplicações de autenticação suportam estes algoritmos neste contexto.
• O Microsoft Authenticator pode ler o código QR com SHA256 ou SHA512, mas o login pode falhar depois.
• Se o algoritmo for alterado, os tokens antigos devem ser eliminados e lidos novamente.
• As alterações ao timestep do token aplicam-se apenas a tokens gerados de novo e devem corresponder à aplicação utilizada.

Para implementações em produção, deve testar-se a aplicação pretendida e o algoritmo com um pequeno grupo piloto. Só depois se devem migrar os utilizadores existentes em maior escala.

Se um utilizador perder a app ou se o algoritmo for alterado, muitas vezes não basta repetir a comunicação aos utilizadores. Em Authentication > Multi-factor authentication > Issued tokens, os tokens podem ser repostos ou podem ser gerados códigos únicos adicionais. Este processo deve ser regulado internamente porque tem forte impacto de segurança.

Validação e operação

Plano de teste após a configuração

Após a configuração, não se deve apenas verificar se a página de login aparece. É importante testar todo o caminho de acesso.

1. Use um navegador externo ou rede de teste externa.
2. Abra a URL WAF com um utilizador do grupo permitido.
3. Teste o login com palavra-passe correta e OTP.
4. Teste o login com OTP incorreto.
5. Teste utilizador fora do grupo permitido.
6. Verifique a expiração da sessão após inatividade.
7. Verifique a função de backend da aplicação.
8. Verifique o Log Viewer e reverseproxy.log para anomalias.
9. Verifique logout, novo login e expiração da sessão com o mesmo browser.
10. Teste com um segundo hostname ou caminho alternativo se a aplicação usa várias regras WAF.

Para os ficheiros de log, consulte Resolução de problemas do Sophos Firewall: Serviços e logs. Os eventos WAF estão normalmente associados ao Reverse Proxy e também aparecem no Log Viewer.

Para a aceitação, cada caso de teste deve ser associado a um resultado visível:

• Utilizador: Aparece o login da firewall, é pedido o OTP e depois abre-se a aplicação esperada.
• Sophos Firewall: O Log Viewer e reverseproxy.log mostram a autenticação WAF permitida ou negada.
• Fonte de autenticação: AD, LDAP, RADIUS ou a fonte local de utilizadores mostra o login bem-sucedido ou falhado esperado.
• Backend: A aplicação apresenta o estado correto de utilizador ou convidado e não mostra uma segunda página de erro inesperada.

Se apenas o browser parecer funcionar, mas não existir qualquer log correspondente, a aceitação está incompleta. Deve então verificar-se se a regra WAF correta está a ser aplicada, se a política de autenticação está realmente ativa e se os logs estão no local esperado.

Go-live e operação após a ativação

Depois de um teste bem-sucedido, o WAF-MFA não deve ser simplesmente ativado para todos e depois esquecido. As primeiras horas após o go-live são importantes, pois os utilizadores reais usam browsers diferentes, aplicações de autenticação diferentes, palavras-passe guardadas, favoritos antigos e outros estados de sessão que um teste de administrador não cobre.

Para o go-live, um pequeno plano de operação é sensato:

• Grupo de implementação: Primeiro o grupo piloto e depois outros grupos de utilizadores.
• Janela de suporte: Manter o helpdesk ou os administradores responsáveis disponíveis durante os primeiros logins.
• Monitorização: Observar o Log Viewer, reverseproxy.log e a fonte de autenticação.
• Reposição do token: Definir um procedimento claro para tokens OTP perdidos ou configurados incorretamente.
• Comportamento da sessão: Verificar o timeout e o tempo de vida da sessão após utilização real.
• Caminho de fallback: Manter documentadas a regra WAF, a política de autenticação e as etapas da alteração.

Para aplicações críticas para o negócio, o go-live não deve ser agendado para um momento em que ninguém possa verificar problemas de login de forma adequada. É melhor uma janela controlada com utilizadores de teste de diferentes grupos, seguida por uma breve revisão dos logs e só então a expansão para mais utilizadores.

Após alguns dias, a configuração deve ser revista:

• Existem utilizadores que contornam o MFA porque acedem através de outra regra WAF ou de outra URL?
• O acesso continua a ser permitido apenas aos grupos planeados?
• A duração da sessão e o timeout de inatividade são adequados para a aplicação?
• Os logins recusados e os problemas de token são realmente detetados em operação?
• Existem casos de suporte que indicam uma comunicação pouco clara com os utilizadores ou uma aplicação de autenticação incorreta?
• Regras de teste antigas, domínios de teste ou exceções temporárias foram removidos?

Este acompanhamento é especialmente importante se vários nomes de host, caminhos ou regras WAF apontarem para a mesma aplicação. Caso contrário, pode acontecer que um caminho esteja protegido com MFA de forma adequada, mas um segundo caminho permaneça acessível sem autenticação prévia.

Resolução de problemas

Outros erros frequentes

• A política de autenticação não usa Form: O comportamento da MFA não corresponde à configuração WAF esperada.
• Sophos Authenticator planeado como nova aplicação padrão: A aplicação está EOL e já não deve servir de base a uma nova implementação.
• O acesso de fallback depende da mesma regra WAF: Os administradores não conseguem reverter corretamente a alteração em caso de erro.
• A implementação de tokens não foi testada: Os utilizadores falham no primeiro login, embora a regra WAF esteja tecnicamente correta.
• Uma segunda URL ou regra WAF permanece ativa sem MFA: Os utilizadores contornam involuntariamente a MFA prévia.
• As exceções temporárias do piloto não são removidas: A proteção em produção fica inconsistente e difícil de auditar.

MFA não é solicitado

Primeiro, verifique se Web application firewall está ativado em Require MFA for. Em seguida, confirme se a regra WAF utiliza realmente uma política de autenticação e se essa política contém os utilizadores ou grupos esperados.

Login funciona, mas a aplicação não abre

Nesse caso, o problema encontra-se normalmente depois do login na firewall. Verifique a acessibilidade do backend, o certificado, o cabeçalho do host, o caminho, a política de proteção e o encaminhamento de autenticação. Se o backend exigir autenticação própria, o modo de encaminhamento deve corresponder.

Utilizador não consegue fazer login após troca de algoritmo

Se tiver mudado de SHA1 para SHA256 ou SHA512, os tokens existentes devem ser eliminados e lidos novamente. Além disso, a aplicação de autenticação deve suportar o novo algoritmo.

Backend pede novo login após MFA bem-sucedido

Em SFOS 22.0 GA Respin Build 411 pode ocorrer NC-177509: o WAF-MFA baseado em formulário é concluído com êxito, mas o backend exige depois um login adicional que não pode ser ignorado. O código OTP não é separado da palavra-passe antes de a firewall encaminhar as credenciais para o backend. A Sophos inclui o problema na Known Issues List e indica SFOS 22.0 MR1 Build 490 como versão corrigida.

As notas de versão do SFOS 22.0 documentam uma correção tecnicamente equivalente como NC-177201.

Verificar:

• WAF Authentication Policy utiliza Form.
• Authentication forwarding mode está ativo e corresponde à aplicação backend.
• A regra WAF afetada usa exatamente essa Authentication Policy.
• O erro ocorre após MFA bem-sucedido, não já no login da firewall.
• reverseproxy.log, Log Viewer e o log de acesso do backend abrangem o mesmo momento de teste.
• A versão SFOS utilizada foi verificada.

Num sistema GA afetado, deve guardar-se reverseproxy.log, o Log Viewer e o log do backend, e planear a atualização para MR1 Build 490 ou posterior. Se não for possível atualizar atempadamente, a Sophos indica o contacto com Sophos Support como solução temporária. Não se deve enfraquecer genericamente a MFA nem alterar o Authentication Forwarding sem análise: None só é adequado se o backend não necessitar de credenciais encaminhadas. Nos portais de produção, o plano deve incluir utilizadores de teste, rollback e comunicação aos utilizadores.

Sessões em excesso ou antigas

Verifique o timeout da sessão, o tempo de vida da sessão e as definições globais de sessão WAF. Em ambientes de produção, deve estar claro se são pretendidas sessões longas ou se os utilizadores devem voltar a autenticar-se rapidamente após um período de inatividade.

Lista de verificação

• Regra WAF está documentada e testada externamente.
• Certificado HTTPS corresponde ao nome do host publicado.
• MFA é aplicável ao grupo de utilizadores correto.
• Require MFA for > Web application firewall está ativado.
• Política de autenticação WAF usa Form.
• Encaminhamento de autenticação corresponde à aplicação de backend.
• Implementação de token, acesso ao portal e procedimento de helpdesk estão preparados.
• Timeout de sessão e tempo de vida da sessão são definidos conscientemente.
• Aplicação OTP e algoritmo de hash foram testados.
• Acesso de administrador de fallback está disponível.
• Rollback e pessoa responsável estão documentados.
• Fonte de autenticação e login de backend foram verificados separadamente.
• Log Viewer e reverseproxy.log foram verificados após o teste.
• A janela de suporte do go-live e o procedimento de reposição do token estão definidos.
• Nomes de host alternativos, caminhos e regras WAF foram verificados para contorno de MFA.
• Exceções temporárias de piloto foram removidas após o rollout.

Perguntas frequentes