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. O Sophos WAF não suporta WebDAV; aplicações como o Nextcloud não são, portanto, publicações WAF suportadas. Planeie outra arquitetura com regras de firewall adequadas e proteção de acesso própria; publicar sem WAF não mantém automaticamente a sua autenticação nem a proteção da aplicação.

O WAF protege na camada 7 contra, entre outras ameaças, a manipulação de cookies, URLs e formulários. O servidor web, a Protection Policy e a Authentication Policy são associados através da regra WAF; são suportadas no máximo 60 regras WAF. A gestão do serviço WAF encontra-se em System services > Services. Reiniciar o serviço afeta as aplicações publicadas e não é a primeira resposta a uma falha de login individual.

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: Escolher outra arquitetura; um piloto não transforma a falta de suporte WAF numa solução suportada. Para outros protocolos especiais, verificar a compatibilidade separadamente antes da implementação.
• 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. Os valores predefinidos são 30 segundos para Default token timestep, 2 para Maximum verification code offset e 10 para Maximum initial verification code offset.
6. Guarde a configuração.

Quando Generate OTP token with next sign-in está ativo, User portal é selecionado automaticamente. Os utilizadores iniciam primeiro sessão no VPN portal ou User portal e digitalizam aí o código QR. O administrador predefinido pode usar a consola WebAdmin quando o MFA é imposto para o respetivo login no WebAdmin. Esta etapa de onboarding deve funcionar antes do primeiro acesso WAF. O planeamento geral do MFA está descrito em Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Acesso Remoto.

Os dois valores de offset não são a solução normal para um relógio incorreto. Com um timestep de 30 segundos, um Maximum verification code offset de 2, por exemplo, aceita um código ainda não utilizado dos 60 segundos anteriores. Uma janela maior torna o login mais tolerante, mas também prolonga a validade de códigos anteriores. Corrija primeiro o NTP e a hora do telemóvel e altere o offset apenas por um motivo documentado.

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.

O sistema operativo móvel também é relevante durante o rollout. A leitura do código QR na aplicação Okta não funciona para estes tokens em iOS nem Android. No iOS, a mesma restrição aplica-se também ao Google Authenticator, Duo e Microsoft Authenticator. Nesses casos, o utilizador deve introduzir manualmente o Base32 secret. Inclua esta etapa no guia do utilizador; uma configuração correta da firewall pode parecer avariada se o runbook só cobrir a leitura do QR.

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, defina o modo de cliente como Form. A autenticação baseada em formulário cria cookies de sessão e permite um logout dedicado; a firewall controla o login através do formulário e das 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.

A documentação da API XML do SFOS 23 descreve o parâmetro opcional RedirectToRequestedURL apenas para o modo de cliente Form, com os valores Enable e Disable. Com Enable, o utilizador é redirecionado para a URL originalmente pedida após uma autenticação bem-sucedida. A documentação não indica um valor predefinido para este parâmetro; o seu nome na API não é uma designação de campo da GUI confirmada. O redirecionamento não substitui nem a autenticação nem a verificação de permissões.

Escolher corretamente o encaminhamento de autenticação

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

• None: Não há autenticação do backend pela firewall; a autenticação prévia continua ativa. Para remover um cabeçalho Basic enviado pelo cliente, também é relevante Remove basic header.
• 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.

No modo de cliente Basic, Basic prompt é apenas a mensagem apresentada na caixa de diálogo do browser. No modo de encaminhamento Basic, Username affix adiciona um prefixo ou sufixo configurado quando é introduzido apenas o nome de utilizador. Verifique separadamente os nomes de login completos para evitar duplicar o domínio ou sufixo no backend. HTTP Basic segue a RFC 7617; a codificação não cifra as credenciais.

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. A lista de verificação seguinte e a associação através de Protected servers referem-se ao SFOS 22; para SFOS 23, são também necessários os controlos explícitos por caminho em Traffic routing descritos a seguir.

Guardar uma regra WAF reinicia todas as regras de proteção de servidores web. As ligações ativas que utilizam essas regras são interrompidas e têm de ser restabelecidas. Coordene a alteração com os responsáveis de todas as aplicações afetadas numa janela adequada, preserve as definições anteriores e verifique depois a acessibilidade, o login com OTP e o acesso ao backend. Este efeito e o procedimento de recuperação não foram testados aqui num equipamento.

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.

SFOS 23: Associar MFA a cada caminho do portal

A ação externa da regra Protect with web server protection, por si só, não é suficiente. A configuração do caminho deve estar correta para cada caminho do portal a proteger, em cada nome de host publicado e em cada regra WAF associada; os passos anteriores de MFA e os limites de sessão permanecem inalterados.

1. Em Traffic routing, edite ou adicione cada caminho protegido do portal e defina Action > Protect. Atribua os objetos backend previstos de Web server > Web servers.
2. No campo Authentication, selecione a política de autenticação pretendida. Esta deve utilizar o modo de cliente Form e incluir o grupo de utilizadores pretendido; a associação do grupo deve corresponder à configuração MFA. Verifique Allowed client networks e as restantes restrições de origem e acesso, incluindo os bloqueios de redes e países escolhidos conscientemente para cada caminho.
3. Se apenas determinados caminhos do portal são permitidos, mantenha / com Block como rota de fallback. Se pretender utilizar Protect para / para publicar toda a aplicação, atribua aí a mesma autenticação prevista e as restrições de acesso adequadas. Verifique explicitamente se os caminhos e nomes de host alternativos têm proteção equivalente ou um bloqueio intencional.
4. Mantenha os testes existentes de login bem-sucedido com palavra-passe e OTP, função de backend, logout, expiração da sessão e novo login. Um OTP incorreto e utilizadores fora do grupo permitido devem falhar; caminhos ou nomes de host alternativos não devem permitir acesso desprotegido. Correlacione o resultado no cliente com os logs WAF, de autenticação e de backend.

Limite da documentação sobre Passthrough: A visão geral das regras descreve a autenticação como uma função de Protect; ao mesmo tempo, a tabela de definições da ação de encaminhamento Passthrough disponibiliza um campo Authentication. Esta tensão não comprova nem a imposição de MFA nem a possibilidade de contornar MFA em Passthrough. Por isso, baseie o WAF-MFA necessário em caminhos Protect explicitamente configurados, não num comportamento de Passthrough não confirmado. Coordene separadamente os túneis WebSocket necessários com os responsáveis pelo encaminhamento WAF e pela autenticação.

Basic with passthrough designa um modo de autenticação para transmitir credenciais; Passthrough em Traffic routing, por outro lado, é uma ação de encaminhamento para tratar o tráfego. A semelhança do nome não implica qualquer propriedade de MFA. Para a publicação básica, os responsáveis devem verificar a configuração dos caminhos SFOS 23 em conjunto com a associação de MFA: o tutorial inalterado da Sophos sobre proteção contra ataques não constitui um guia completo de encaminhamento para SFOS 23, e as regras WAF suportam apenas IPv4.

Personalizar uma Authentication Template em segurança

Um formulário próprio é criado em Web server > Authentication templates > Add. No HTML devem ser mantidos o formulário com action="<?login_path?>" e method="POST", assim como os campos httpd_username e httpd_password. Para MFA, otp_field também tem de estar presente. Se estes elementos forem removidos ou renomeados, o login pode falhar mesmo que a página pareça correta.

Para imagens, estilos e scripts, o SFOS disponibiliza, entre outros, os placeholders <?assets_path?>, <?admin_contact?>, <?company_logo?> e <?company_text?>. Os assets que podem ser carregados estão limitados a .jpg, .jpeg, .png, .ico, .css e .js. O template deve ser testado primeiro com um utilizador piloto; credenciais de produção, trackers externos e JavaScript não verificado não devem fazer parte da página de login.

Depois de Add, introduza um nome, selecione o ficheiro HTML e os respetivos assets, clique em Upload e depois em Save. Selecione o template guardado na política de autenticação Form. Este formulário mínimo conserva os nomes técnicos necessários; é um exemplo documental, não um template testado num equipamento:

<form action="<?login_path?>" method="POST">
  <label>Username <input name="httpd_username" type="text"></label>
  <label>Password <input name="httpd_password" type="password"></label>
  <?otp_field?><label>OTP <input name="otp_field" type="password"></label><?otp_field?>
  <button type="submit">Login</button>
</form>

Contradições na documentação dos templates: Um exemplo curto de palavra-passe usa type="text", enquanto a definição do campo e o exemplo completo mostram type="password". Mantenha o campo da palavra-passe mascarado. Uma nota indica também que apenas <?login_path?> é substituído, mas a tabela opcional descreve substituições para <?assets_path?> e <?admin_contact?>. Isto não confirma o comportamento de todas as versões de firmware. Antes do rollout, verifique o formulário apresentado, os caminhos dos assets, a introdução de OTP e o login com um grupo piloto; não substitua um template funcional sem validação.

<?assets_path?> refere-se aos ficheiros auxiliares carregados, por exemplo em <link rel="stylesheet" href="<?assets_path?>/stylesheet.css">. Isto permite manter imagens e CSS fora do formulário. A descrição do campo associa <?admin_contact?> a Administration > Notification settings > Email settings > Send notifications to email address; verifique se esse endereço pode ser mostrado publicamente. Substitua <?company_logo?> pelo caminho do logótipo e <?company_text?> pelo texto visível pretendido, sem assumir uma substituição automática. Se os placeholders permanecerem visíveis ou o login falhar, volte ao template funcional guardado e investigue com o suporte em vez de desativar o MFA.

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.

Maximum sessions é partilhado por todas as regras WAF com autenticação Form. Ao atingir o limite, a firewall fecha sessões antigas ou expiradas para permitir novas sessões. Pedidos repetidos de login podem, portanto, indicar falta de capacidade global, não apenas o timeout de uma política.

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.

Gerir as definições globais WAF em segurança

Web server > General settings afeta todos os servidores web protegidos, não apenas o portal MFA. Antes de alterar, guarde os valores, identifique as aplicações afetadas e a compatibilidade dos clientes e planeie uma janela de manutenção e um caminho de recuperação. Estas indicações foram verificadas documentalmente; os efeitos e o rollback não foram testados num equipamento.

Slow HTTP protection limita a espera por cabeçalhos de pedido incompletos. Num DoS Slow HTTP, os fragmentos que chegam lentamente ocupam ligações até esgotar a capacidade:

• Soft limit: tempo mínimo para receber um cabeçalho de pedido.
• Hard limit: tempo máximo para receber o cabeçalho.
• Extension rate: quantidade de dados em bytes; cada vez que é excedida, o timeout soft aumenta um segundo.
• Skipped networks/hosts: exceções específicas. Use apenas os tipos de host IP IP e Network, não IP ranges nem IP lists. Exceções amplas também retiram a proteção a clientes indesejados.

Depois de ajustar, verifique clientes legítimos normais e lentos e as restantes aplicações WAF. Não adote timeouts arbitrários como solução geral para problemas de login.

TLS version settings determina as ligações permitidas dos clientes. Os perfis documentados também diferem nas cifras:

• TLS v1 or later: exclui SSLv3; é um perfil legacy, não uma recomendação para novos portais.
• TLS v1.1 or later: exclui SSLv3 e TLSv1; também não é uma configuração moderna por defeito.
• TLS v1.2 (wide compatibility): apenas TLSv1.2, incluindo cifras legacy não recomendadas.
• TLS v1.2 (strict): apenas TLSv1.2 com cifras recomendadas.
• TLS v1.3: apenas cifras TLSv1.3.

Verifique o suporte dos clientes antes de selecionar; por exemplo, IE 8 ou anterior e Windows XP não conseguem ligar com TLS 1.2. Não obtenha compatibilidade legacy enfraquecendo indiscriminadamente a segurança. Teste primeiro um perfil estrito com os clientes realmente necessários e todas as aplicações publicadas.

Em Custom TLS, Protocols, Cipher suite e TLS v1.3 cipher suite only usam sintaxe OpenSSL. As cifras TLSv1.3 pertencem apenas ao campo TLSv1.3 separado, não a Cipher suite. Protocolos ou cifras inválidos podem impedir o arranque do Apache e afetar o WAF. Não experimente Custom TLS em produção sem definições validadas; se falhar, reponha os valores guardados e verifique o estado do serviço e o acesso HTTPS a todos os portais afetados.

SFOS 23 – Worker customization: A firewall calcula a capacidade WAF a partir da CPU e RAM. Os valores calculados são otimizados para o hardware; a maioria das implementações não requer alterações. Valores superiores podem piorar o desempenho WAF e a utilização dos recursos. Ative Use custom worker profile apenas após uma avaliação cuidadosa da capacidade e do impacto, não como solução genérica para falhas de login:

• Start servers: processos worker no arranque do servidor web.
• Server limit: número máximo de processos worker.
• Minimum spare threads: número mínimo de threads livres mantidas disponíveis.
• Maximum spare threads: limiar de threads livres acima do qual são removidas as excedentes.
• Threads per child: número máximo de threads por processo worker.
• Asynchronous request worker factor: controla a escalabilidade dos processos para ligações e pedidos assíncronos.

Não copie valores universais de outros sistemas. Guarde os valores iniciais, observe carga representativa e recursos e volte a testar login, OTP, sessões e acesso ao backend após cada alteração justificada. Se o desempenho piorar, reponha a configuração inicial guardada; não se afirma aqui que tenha sido realizado um rollback bem-sucedido.

Automatizar a autenticação WAF através da XML API

Para a automatização, três objetos distintos funcionam em conjunto: FormTemplate disponibiliza o formulário de início de sessão, ReverseAuthentication define a autenticação do cliente e do backend, e FirewallRule associa a política à publicação ou aos respetivos caminhos. Primeiro, fazer uma cópia de segurança do modelo funcional, da política e de todas as regras que os utilizam. O acesso, as operações de escrita explícitas, a avaliação das respostas e as repetições seguras são explicados em Proteger o acesso à Sophos Firewall XML API. As informações seguintes descrevem as referências SFOS-22/23, não um procedimento de escrita testado num appliance. Antes de fazer alterações, consultar a API help da build instalada; não executar operações de escrita se houver campos ou associações de upload por esclarecer.

Distinguir o modo do cliente, o backend e as sessões

No objeto ReverseAuthentication, Name, VirtualWebserverMode e RealWebserverMode são descritos como campos obrigatórios. Name permite, no máximo, 60 caracteres. VirtualWebserverMode seleciona Basic ou Form para o cliente; o valor predefinido documentado Basic não é uma recomendação de MFA. Para MFA no WAF, Form continua a ser necessário. BasicPrompt é o texto informativo opcional para Basic, com um máximo de 255 caracteres. FormTemplate referencia o modelo guardado no modo Form. UserGroupList contém entradas UserGroup repetíveis para utilizadores ou grupos existentes; esta seleção deve continuar a corresponder ao grupo de MFA. A palavra Mode nas notas de aplicabilidade não é uma etiqueta XML adicional comprovada.

RealWebserverMode seleciona, de forma independente, Basic ou None para o backend; também aqui a tabela indica Basic como valor predefinido. Com Basic, UsernameAffix faz parte da autenticação no backend. Prefix e Suffix são textos opcionais, cada um com um máximo de 255 caracteres, previstos apenas para a seleção de afixo correspondente. Com None, é relevante, em alternativa, RemoveBasicHeader, com Enable ou Disable. O valor predefinido ON aí indicado não é, por si só, um valor de entrada permitido; utilizar valores explícitos apenas após verificar a build. As verificações existentes de HTTPS, backend e nomes de utilizador continuam a ser necessárias.

Não incorporar contradições num payload: Para UsernameAffix, o exemplo XML apresenta None/Prefix/Suffix/PrefixAndSuffix, mas a tabela indica Basic, Prefix, Suffix, PrefixandSuffix e, simultaneamente, o valor predefinido None. Não adivinhar a grafia nem valores de seleção adicionais. Da mesma forma, o exemplo apresenta SessionTimeout e SessionLifetime como interruptores, os respetivos campos Limit como inteiros e os campos Scope como Hours/Minutes/Days. A tabela confirma o intervalo de 1 a 9999 para SessionTimeoutLimit, mas troca os tipos inteiro e interruptor em SessionLifetime e SessionLifetimeLimit; indicações como ON e 8 Hours não correspondem de forma consistente aos tipos de dados. Estas inconsistências não comprovam valores predefinidos fiáveis nem uma configuração de sessão executável. Confirmar o limite de inatividade e a duração máxima pretendidos na build instalada, consultar o estado guardado e executar os testes existentes de sessão, fim de sessão e novo início de sessão. A adição RedirectToRequestedURL do SFOS-23 e o respetivo teste separado de redirecionamento de retorno permanecem independentes disso.

Associar o modelo e os ficheiros complementares

A referência FormTemplate apresenta FormTemplate como um objeto com Name, Description, Template e Assets, incluindo entradas Asset repetíveis. Name e Template são campos obrigatórios: o nome permite, no máximo, 60 caracteres; Template é uma string com um máximo de 255 caracteres para selecionar e carregar o modelo HTML. Description é opcional. As strings opcionais Asset permitem, cada uma, um máximo de 255 caracteres e vários valores para imagens, folhas de estilo ou ficheiros JavaScript utilizados.

O exemplo deixa Template e Asset vazios. Assim, não define nomes de partes multipart, caminhos de ficheiros, uma codificação Base64 nem conteúdo HTML diretamente transmissível. Não aplicar aos FormTemplates uma associação de upload de certificados. Sem um contrato de upload confirmado, utilizar a sequência existente na GUI Upload > Save e, em seguida, selecionar o modelo guardado através de FormTemplate na política Form. Os campos de formulário obrigatórios e os tipos de ficheiros de recursos permitidos da secção anterior continuam a aplicar-se. Verificar o formulário renderizado, os recursos e o início de sessão com OTP utilizando um utilizador de teste; guardar o objeto com êxito, por si só, não comprova que o formulário funciona.

Associar a Authentication Policy à regra

Em FirewallRule, esta associação diz respeito ao ramo WAF HTTPBasedPolicy, não a NetworkPolicy ou UserPolicy. A tabela de parâmetros descreve Authentication como uma string escalar opcional para uma Authentication Policy. No exemplo de caminhos, a associação correspondente aparece como AccessPaths > AccessPath > auth_profile. O comentário do exemplo separa de AccessPaths a variante ao nível da regra com Authentication e controlos de origem; não comprova qualquer combinação arbitrária nem herança automática. Não misturar as formas de escrita ao nível da regra e ao nível do caminho sem as verificar, nem presumir que uma política existente na firewall já protege todos os caminhos.

No SFOS 23, a tabela descreve path como um array obrigatório de strings com vários valores, com um máximo de 63 caracteres, sem vírgula e com suporte para UTF-8; o SFOS 22 indica aqui um escalar. O exemplo utiliza tanto path como Path. backend é opcional na tabela do SFOS-23; isso não garante que um portal protegido funcione sem backend. O novo action ao nível do caminho apresenta literalmente 0/1/2/3, sem uma correspondência fiável com as ações da GUI. Não adivinhar a correspondência numérica nem equiparar estes valores ao campo de rede Action. O encaminhamento, o backend e o perfil de proteção são explicados em WAF: Publicar servidores Web de forma segura.

Para alterar a autenticação, começar por consultar os nomes de host e os caminhos efetivos da regra de destino, associar a política Form pretendida a cada caminho protegido e, em seguida, comparar o estado guardado com o estado pretendido. Testar todos os caminhos, nomes de host e regras alternativos, bem como OTP incorreto e utilizadores fora do grupo. Os controlos Protect já descritos, o limite da documentação de Passthrough e a janela de alteração para regras WAF continuam a aplicar-se sem alterações.

Avaliar as respostas dos objetos antes de uma nova tentativa

As correspondências seguintes são valores de estado XML e símbolos Message.* literais, não resolvidos, da referência, não códigos de estado HTTP nem textos de mensagens de execução comprovados. Para a associação de FirewallRule, as diferenças entre Add e Edit são particularmente importantes:

• Add firewall rule: 200 / Message.FWRuleAddSuccess, 500 / Message.FWRuleAddFail, 502 / Message.FWRuleRecordExists.
• Edit firewall rule: 200 / Message.FWRuleEditSuccess, 202 / Message.FirewallRuleUpdateWithRename, 500 / Message.FWRuleEditFail, 502 / Message.FWRuleUpdateRecordExist. Com 202, consultar também o nome efetivo e todas as associações.
• Correspondências diferentes: Add 541 / Message.VHIPRangeConflict, Edit 541 / Message.FWRuleFailMaxUser; Add 543 / Message.CannotSetupRedirectionFromHTTP, Edit 543 / Message.CannotUseDefaultPort; Add 544 / Message.CannotUseDefaultPort, Edit 544 / Message.CannotSetupRedirectionFromHTTP. O mesmo código, por si só, não é suficiente para a interpretação.
• Outras linhas diferenciadoras: Edit 552 / Message.CannotImportDiffPolicytypeWithSameName; Add 554 / Message.CannotUseFQDNWildCardAsProtectedServer, Edit 554 / Message.CannotUpdateFQDNWildCardAsProtectedServer.
• Delete firewall rule: 200 / Message.FWDelSuccess, 500 / Message.FWRuleDeleteFail, 596 / Message.CMLOCALOperationrestriction. 596 também aparece em Add e Edit; esclarecer o estado efetivo das permissões e da gestão, sem o contornar através de repetições cegas ou eliminações. Eliminar uma regra não é uma forma de corrigir uma associação de autenticação em falta.

Os dois objetos prévios também têm respostas próprias:

• Add Authentication Policy: 200 / Message.ReverseAuthAddSuccess, 500 / Message.ReverseAuthAddFail, 502 / Message.ReverseAuthRecodExist.
• Edit Authentication Policy: 200 / Message.ReverseAuthUpdateSuccess, 500 / Message.ReverseAuthUpdateFail.
• Add FormTemplate: 200 / Message.FormTemplateAddSuccess, 500 / Message.FormTemplateAddFail.
• Edit FormTemplate: 200 / Message.FormTemplateUpdateSuccess, 500 / Message.FormTemplateUpdateFail, 502 / Message.FormTemplateRecodExist. A grafia Recod nestes símbolos mantém-se literalmente; não deduzir dela um estado adicional para outra operação.

Registar em conjunto a operação, o código, a resposta efetiva e o estado guardado do modelo, da política e da regra de destino. Em caso de erros, avisos ou resposta pouco clara, verificar primeiro o que foi realmente aplicado; não contornar a situação através de um segundo nome, de um grupo mais abrangente ou de um caminho desprotegido. Se a sintaxe ou a associação de upload não estiverem esclarecidas, parar e recorrer ao suporte com dados expurgados. Só após a confirmação de que os dados foram guardados devem ser executados os testes positivos e negativos existentes de MFA, backend, sessão, fim de sessão, redirecionamento de retorno e caminhos alternativos. A verificação documental não substitui a validação na própria firewall.

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 testar também o regresso à URL pedida no SFOS 23, abra uma URL efetivamente protegida com um caminho diferente de /, sem uma sessão WAF válida. Após um login bem-sucedido com palavra-passe e OTP, com RedirectToRequestedURL definido como Enable, verifique se é atingida exatamente a URL originalmente pedida e se o acesso ao backend respeita as permissões previstas. Um redirecionamento bem-sucedido, por si só, não comprova MFA nem autorização de acesso; todos os testes anteriores de recusa, backend, sessão, logout, novo login e caminhos alternativos continuam a ser necessários.

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. Este problema está corrigido a partir do SFOS 22.0 MR1 Build 490.

A correção do código OTP não removido tem também a referência NC-177201. Os identificadores não são intercambiáveis: NC-177509 associa as builds afetadas e corrigidas, enquanto NC-177201 identifica o texto específico da correção. Num caso de suporte, indique o sintoma, a build e ambas as referências.

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, não altere o fluxo de autenticação sem validação; use os dados guardados para abrir um caso no Sophos Support. 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