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. Isso é especialmente útil para portais internos, interfaces de administração, áreas de clientes ou acessos de parceiros que precisam ser acessíveis via HTTPS, mas não devem ser protegidos apenas pela aplicação em si.

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.

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.

Quando o WAF-MFA é útil

O WAF-MFA é especialmente eficaz quando uma aplicação web precisa ser acessível da internet, mas não é destinada 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 usuários 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 geralmente 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 o WebDAV for necessário, deve-se ter cuidado especial: o Sophos WAF não suporta o WebDAV de forma adequada, 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, essa camada não responde a todas as questões de arquitetura. Especialmente para portais críticos, deve-se decidir conscientemente se a aplicação deve ser acessível publicamente.

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á planejada ou publicada através de uma regra WAF.
• Usuários ou grupos estão presentes na firewall, por exemplo, localmente, via AD, LDAP ou RADIUS.
• Os usuários podem configurar seu token OTP.
• O horário do sistema da firewall está correto e o NTP está funcionando.
• Para a regra WAF, é utilizado HTTPS com um certificado adequado.
• Está claro se o servidor web backend precisa de autenticação própria ou se a firewall deve assumir completamente o login.
• Um usuário 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 usuários legítimos ou fazer com que uma aplicação pareça “quebrada”.

Planejar 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 usuários 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 usuários 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 usuário 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 usuários serão informados sobre tokens, expiração de sessão e possível segundo login no backend?

Um erro comum de planejamento é a mistura de autenticação de firewall e autenticação de backend. O WAF pode verificar usuários antes do backend. Isso não significa automaticamente que a aplicação em si não precisa mais de um login próprio, verificação de funções ou gerenciamento de sessões. Especialmente em portais de administração e dados de clientes, a permissão de backend deve ser mantida conscientemente.

Se o serviço publicado for destinado a poucas pessoas, além do MFA, deve-se restringir as fontes. Para a publicação básica e limitação de fontes, veja Sophos Firewall WAF: Publicar servidores web com segurança. Se direitos de usuário ou MFA de acesso remoto forem planejados, veja 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 usuários 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.

Componentes da configuração

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

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 usuários ou grupos afetados.
3. Ative Generate OTP token with next sign-in se os usuários devem configurar seu token no próximo login.
4. Em Require MFA for, ative a opção Web application firewall.
5. Salve a configuração.

Se os usuários devem configurar seu token por conta própria, eles precisam ter acesso a um portal onde o código QR é exibido. Em muitos ambientes, isso é relevante para o User Portal ou VPN Portal. O planejamento geral do MFA está descrito em Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Acesso Remoto.

Preparar implementação de tokens e comunicação com usuários

O WAF-MFA muitas vezes falha na operação não por causa da regra WAF em si, mas por causa da implementação de tokens. Os usuários precisam saber onde o código QR aparece, qual aplicativo deve ser usado, quanto tempo uma sessão é válida e se após o login na firewall ainda há um segundo login na aplicação.

Antes de ativar a regra WAF produtiva, deve-se definir:

Se Generate OTP token with next sign-in for usado, o primeiro login deve ser testado de forma controlada. É importante verificar se os usuários veem o código QR no portal esperado e se conseguem acessar a aplicação WAF com sucesso usando senha mais OTP. Os próprios portais são descritos em Portais do Sophos Firewall: WebAdmin, User Portal e VPN Portal.

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

• nome do host publicado da aplicação WAF
• grupo de usuários afetado
• política de autenticação usada
• algoritmo OTP usado
• aplicativo autenticador permitido
• procedimento para redefinição de token
• mensagem esperada para senha ou OTP incorretos
• locais de log para verificação inicial: Log Viewer e reverseproxy.log

Especialmente para parceiros externos ou portais raramente usados, o primeiro login não deve ocorrer apenas em uma emergência produtiva. Um breve piloto com usuários normais frequentemente revela problemas que os administradores não veem em seus próprios testes: aplicativo autenticador diferente, falta de acesso ao portal, segundo login de backend não claro ou timeouts de sessão que são muito curtos para a aplicação.

Criar 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 usuários 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. Salve.

Escolher corretamente o encaminhamento de autenticação

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

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.

⚠️ A autenticação básica deve ser usada apenas com HTTPS. Além disso, deve estar claro se o backend realmente deve processar os dados de login passados pela firewall.

Usar 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 usuários 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.

Planejar 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 usuários 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 usuários. Sessões muito longas são mais convenientes, mas aumentam o risco de um acesso ao navegador roubado ou compartilhado permanecer utilizável por mais tempo. Para portais de administração, deve-se começar de forma conservadora e observar o comportamento na operação.

Algoritmo OTP e aplicativo autenticador

O SFOS 22 suporta, além do SHA1, também SHA256 e SHA512 para tokens OTP. Isso é sensato do ponto de vista de segurança, mas só funciona se o aplicativo autenticador usado suportar o algoritmo escolhido.

Pontos importantes:

• SHA256 ou SHA512 são mais seguros que SHA1.
• Nem todo aplicativo autenticador suporta esses algoritmos neste contexto.
• O Microsoft Authenticator pode escanear o código QR com SHA256 ou SHA512, mas o login pode falhar depois.
• Se o algoritmo for alterado, os tokens antigos devem ser excluídos e escaneados novamente.

Para implementações produtivas, deve-se testar o aplicativo desejado e o algoritmo com um pequeno grupo piloto. Só depois os usuários existentes devem ser amplamente migrados.

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 usuário do grupo permitido.
3. Teste o login com senha correta e OTP.
4. Teste o login com OTP incorreto.
5. Teste usuário 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.

Para os arquivos de log, veja Solução de problemas do Sophos Firewall: Serviços e Logs. Eventos WAF geralmente estão no 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:

Se apenas o navegador parecer bem-sucedido, mas nenhum log correspondente for visível, a aceitação está incompleta. Deve-se então verificar se a regra WAF correta está correspondendo, 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

Após um teste bem-sucedido, o WAF-MFA não deve ser simplesmente ativado amplamente e depois esquecido. As primeiras horas após o go-live são importantes, pois usuários reais trazem navegadores diferentes, aplicativos autenticadores diferentes, senhas salvas, 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:

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 usuários de teste de diferentes grupos, seguida por uma breve revisão dos logs e só então a expansão para mais usuários.

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

• Existem usuários que contornam o MFA porque acessam através de outra regra WAF ou outra URL?
• O acesso continua sendo permitido apenas para os grupos planejados?
• A duração da sessão e o timeout de inatividade são adequados para a aplicação?
• Logins negados e problemas de token são realmente vistos na operação?
• Existem casos de suporte que indicam comunicação de usuário não clara ou aplicativo autenticador incorreto?
• 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.

Erros comuns

Solução de problemas

MFA não é solicitado

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

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

Então, o problema geralmente está após o login na firewall. Verifique a acessibilidade do backend, certificado, cabeçalho do host, caminho, política de proteção e encaminhamento de autenticação. Se o backend esperar autenticação própria, o modo de encaminhamento deve corresponder.

Usuário não consegue fazer login após troca de algoritmo

Se foi feita a troca de SHA1 para SHA256 ou SHA512, os tokens existentes devem ser excluídos e escaneados novamente. Além disso, o aplicativo autenticador deve suportar o novo algoritmo.

Senha e OTP são passados para o backend

No WAF-MFA, deve-se verificar se a versão da firewall está atualizada. Nas Notas de Lançamento do SFOS-22.0 está documentado um erro WAF corrigido, onde o código OTP não era removido da senha antes de os dados serem passados para o backend.

Muitas ou sessões antigas

Verifique o timeout de sessão, tempo de vida da sessão e as configurações globais de sessão WAF. Em ambientes produtivos, deve estar claro se sessões longas são desejadas ou se os usuários devem se autenticar novamente rapidamente após 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 usuários 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.
• Aplicativo 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.
• Janela de suporte do go-live e procedimento de redefinição de 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