Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Remote Access

Para a função OTP local, abre-se Authentication > Multi-factor authentication, seleciona-se primeiro Specific users and groups, ativam-se os serviços necessários e testa-se tudo com um grupo-piloto. All users só deve ser utilizado depois de os testes serem concluídos com êxito.

MFA protege WebAdmin, VPN Portal e o acesso remoto contra a utilização exclusiva de palavras-passe roubadas. No entanto, não substitui regras de acesso restritivas nem um acesso de emergência testado. Este artigo abrange, por isso, desde a ativação segura até à escolha da aplicação, recuperação e resolução de problemas.

Ativar Sophos OTP com segurança

Antes da ativação

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

• A firewall utiliza a hora correta em Administration > Time, idealmente através de NTP.
• Os utilizadores e grupos estão disponíveis localmente ou através de AD, LDAP ou outro servidor de autenticação.
• Existem um grupo-piloto e um segundo administrador testado.
• A consola e o procedimento de recuperação do admin predefinido são conhecidos.
• Estão disponíveis uma cópia de segurança atual e um processo documentado para repor tokens.

Para Active Directory clássico, Adicionar Active Directory ao Sophos Firewall explica como configurar a origem dos utilizadores.

Em Administration > Device access, definem-se as zonas a partir das quais WebAdmin, User Portal, VPN Portal e outros serviços locais estão acessíveis. As Local service ACL exception rules limitam ainda mais o acesso a redes de gestão, redes VPN ou endereços de origem conhecidos. Proteger o acesso ao Sophos Firewall: configurar corretamente Device Access explica este hardening em detalhe.

SSH não faz parte dos serviços protegidos por Sophos OTP. Deve ser limitado através de Device Access e utilizar uma chave pública sempre que possível; o procedimento está descrito em Ligar ao Sophos Firewall através de SSH.

⚠️ MFA reduz o risco associado a palavras-passe comprometidas, mas não diminui a superfície de ataque de um serviço acessível publicamente. WebAdmin, SSH e os portais nunca devem ficar expostos mais amplamente do que o necessário.

Antes de testes negativos, verifica-se também Administration > Admin and user settings > Login security > Block login. Várias tentativas falhadas intencionais podem bloquear o IP de origem para WebAdmin, CLI, VPN Portal e User Portal, impedindo também um administrador de fallback na mesma rede. Deve, por isso, estar disponível uma segunda origem ou o acesso à consola.

Configurar MFA para um grupo-piloto

1. Iniciar sessão no WebAdmin e abrir Authentication > Multi-factor authentication.
2. Em One-time password (OTP), selecionar primeiro Specific users and groups.
3. Abrir Add users and groups, selecionar o grupo-piloto e aplicar a seleção.
4. Ativar Generate OTP token with next sign-in quando for utilizada uma aplicação de autenticação.
5. Em Require MFA for, selecionar apenas as interfaces de início de sessão efetivamente necessárias.
6. Em OTP hash algorithm, escolher um algoritmo suportado pela aplicação prevista.
7. Alterar as definições opcionais de OTP timestep settings apenas se a aplicação suportar o mesmo intervalo; o valor predefinido é 30 segundos.
8. Guardar com Apply.

As opções de utilizador significam:

• No OTP: MFA está desativada.
• All users: MFA aplica-se a todos os utilizadores; utilizar apenas depois do piloto.
• Specific users and groups: MFA aplica-se apenas às contas ou aos grupos selecionados.

Quando Generate OTP token with next sign-in está ativado, os utilizadores registam uma aplicação no início de sessão seguinte. User Portal é então selecionado automaticamente como serviço MFA. Quando a opção está desativada, os tokens de hardware ou geridos manualmente são atribuídos em Issued tokens.

Selecionar os serviços de forma consciente

No SFOS 22, estão disponíveis os seguintes serviços em Require MFA for:

• User portal
• Web admin console
• VPN portal
• SSL VPN remote access
• IPsec remote access
• Web application firewall

MFA para User Portal também se aplica a Captive Portal e Client Authentication Agents. Os utilizadores de acesso remoto têm de registar primeiro o token através de VPN Portal ou User Portal.

Para WAF, a seleção do serviço por si só não é suficiente. A partir do SFOS 22, são necessários Webserver Protection, uma Authentication Policy baseada em formulário e a sua atribuição à regra WAF. O procedimento completo está descrito em Proteger o WAF do Sophos Firewall com MFA.

Escolher o modelo MFA adequado

Sophos OTP local

Sophos OTP gere os tokens diretamente na firewall e não requer infraestrutura RADIUS ou de fornecedor de identidade adicional. É particularmente adequado para utilizadores locais normais, ambientes pequenos e um hardening rápido de WebAdmin ou do acesso remoto.

A contrapartida da implementação simples é um token separado dos processos Microsoft 365 existentes. Os utilizadores e o help desk têm de conhecer o registo da aplicação, a introdução da palavra-passe mais OTP e o processo de mudança de dispositivo.

RADIUS ou Entra ID SSO

Uma plataforma MFA existente pode integrar-se melhor na gestão central de identidades através de RADIUS ou SSO. No entanto, exige testes específicos por serviço:

• VPN Portal não suporta RADIUS com MFA de challenge.
• Sophos Connect não suporta um challenge OTP. O cliente envia a palavra-passe e o OTP em conjunto no formato passwordotp, mas suporta MFA por chamada e push.
• User Portal e WebAdmin suportam adicionalmente MFA baseada em challenge.
• Com Entra ID SSO, MFA ocorre no fornecedor de identidade; a MFA local de Sophos OTP não pode ser adicionada ao mesmo início de sessão SSO.
• Entra SSO com Sophos Connect exige, no Windows, pelo menos a versão 2.4 do cliente. WebAdmin SSO não está disponível no dispositivo auxiliar HA.

Para Remote Access, existe o guia separado Configurar Microsoft Entra ID SSO para Sophos Connect e VPN Portal. Se, pelo contrário, o Entra tiver de controlar o login do WebAdmin e as funções de administrador, Entra ID SSO para o WebAdmin do Sophos Firewall conduz pelo Role mapping, Least Privilege, login piloto e acesso de emergência local.

Sophos Connect ou SSL VPN: qual é a solução adequada? ajuda a escolher o modelo de acesso remoto; antes da implementação, também se deve verificar a versão do cliente Sophos Connect.

Independentemente do modelo, começa-se com um grupo-piloto. Só se adicionam mais utilizadores depois de WebAdmin, portais, clientes VPN reais, grupos, tempos limite, logging e fallback terem sido verificados.

Configurar tokens e a aplicação de autenticação

Registar e gerir tokens

Com Generate OTP token with next sign-in ativado, o utilizador inicia sessão no VPN Portal ou User Portal e digitaliza o código QR. Os administradores também podem registar o token no WebAdmin quando MFA é aí imposta. O código QR só aparece para os utilizadores e grupos para os quais MFA está configurado.

Em Authentication > Multi-factor authentication > Issued tokens, é possível verificar, desativar temporariamente, eliminar ou adicionar manualmente os tokens emitidos. Também é possível gerar códigos de utilização única adicionais e verificar ou sincronizar o desvio temporal de um token.

Se um smartphone for perdido ou a aplicação for alterada, elimina-se o token antigo depois de verificar a identidade do utilizador. Em seguida, o utilizador inicia sessão uma vez no portal apenas com a palavra-passe e regista o novo código QR apresentado. Um token antigo não deve continuar a existir em paralelo sem controlo.

A aplicação e o algoritmo hash têm de ser compatíveis

O SFOS 22 suporta SHA1, SHA256 e SHA512. A Sophos recomenda SHA256 ou SHA512, mas o algoritmo escolhido tem de ser suportado pela aplicação:

• Sophos Intercept X for Mobile e Google Authenticator suportam SHA256 e SHA512.
• Microsoft Authenticator não suporta estes dois algoritmos neste fluxo de trabalho Sophos. A digitalização do código QR pode ser bem-sucedida, mas o início de sessão posterior falha.
• Duo Mobile e Okta Verify estão entre as aplicações indicadas pela Sophos; a compatibilidade com o código QR e o algoritmo tem de corresponder ao sistema operativo e à configuração utilizados.
• Outras aplicações TOTP só são aprovadas depois de um teste-piloto real.

No iOS, a digitalização do código QR Sophos não funciona com Google Authenticator, Duo Mobile nem Microsoft Authenticator. A conta deve ser criada manualmente com a chave Base32 apresentada. Okta Verify exige o registo manual por Base32 tanto no iOS como no Android. No entanto, isto não resolve a falta de suporte de SHA256/SHA512 no Microsoft Authenticator.

A anterior aplicação Sophos Authenticator atingiu o End of Life em 31 de julho de 2022 e já não deve ser planeada para novas implementações.

Para migrar de SHA1 para um algoritmo mais forte:

1. Testar a aplicação-piloto com SHA256 ou SHA512.
2. Selecionar o novo algoritmo em Authentication > Multi-factor authentication.
3. Eliminar os tokens SHA1 antigos em Issued tokens.
4. Fazer com que os utilizadores iniciem sessão apenas com a palavra-passe e registem novamente o código QR ou a chave Base32.
5. Realizar testes controlados de início de sessão com um código correto e outro incorreto.

Durante a migração, podem existir em paralelo tokens com algoritmos diferentes. No entanto, os tokens que não forem eliminados continuam a utilizar o algoritmo anterior.

Introduzir corretamente a palavra-passe e o OTP

Para inícios de sessão Sophos OTP nativos, o formato oficial é <password><passcode>, sem espaços nem separadores.

Exemplo:

Palavra-passe: MinhaPalavraPasseSegura
Código OTP:    123456
Introdução:    MinhaPalavraPasseSegura123456

Sophos Connect pode apresentar um terceiro campo separado através de otp: true. O cliente acrescenta internamente o código à palavra-passe. Esta apresentação não altera o formato enviado ao servidor de autenticação.

Proteger e recuperar o administrador predefinido

Ativar MFA para o admin predefinido

O utilizador local admin predefinido não é ativado através da lista normal de utilizadores. Abre-se Administration > Device access, ativa-se MFA for default admin e configura-se aí o token de hardware ou software.

Antes disso, o segundo administrador, o acesso de gestão e o acesso à consola têm de funcionar. Os códigos de utilização única adicionais são guardados de forma segura, por exemplo num gestor de palavras-passe. O admin predefinido continua a ser uma conta de emergência e não é utilizado na administração diária.

Outros administradores não podem ativar, desativar, editar nem eliminar o token do admin predefinido. O OTP hash algorithm global selecionado também se aplica a este token.

Recuperação através da Device Console

Se o token estiver apenas temporariamente indisponível, a Device Console permite um único início de sessão sem MFA:

1. Introduzir 2 para System Configuration.
2. Introduzir 6 para Skip multi-factor authentication for next Admin user login.
3. Iniciar sessão no WebAdmin e verificar o token.

Em caso de dispositivo perdido ou token permanentemente inutilizável, repõe-se MFA:

1. Introduzir 2 para System Configuration.
2. Introduzir 7 para Reset multi-factor authentication for Admin user.
3. Confirmar com y.
4. Iniciar sessão uma vez no WebAdmin apenas com a palavra-passe de administrador.
5. Seguir as instruções para registar MFA novamente e, em seguida, voltar a testar o início de sessão com MFA.

Estas duas opções alteram apenas o estado de MFA. Se a palavra-passe do admin predefinido também for desconhecida, o artigo separado sobre recuperação da palavra-passe explica o procedimento série documentado para appliances físicos e os limites quando a palavra-passe e o MFA são perdidos em simultâneo.

Testar, verificar logs e implementar

Testar cada serviço separadamente

Um início de sessão WebAdmin bem-sucedido não prova que os portais e clientes VPN funcionam da mesma forma. Antes de uma implementação ampla, verifica-se:

• WebAdmin: Iniciar sessão com o administrador-piloto utilizando um OTP correto e outro intencionalmente incorreto.
• Default admin: Verificar o caminho Device Access separado e o procedimento de recuperação documentado.
• User Portal e VPN Portal: Testar o registo por QR ou Base32 e o início de sessão com <password><passcode>.
• SSL VPN e IPsec Remote Access: Testar clientes reais e exatamente o grupo de utilizadores utilizado em produção.
• Sophos Connect: Quando aplicável, testar o terceiro campo OTP, os perfis de cliente atuais e o comportamento de chamada/push.
• RADIUS ou Entra SSO: Verificar tempos limite, logs do IdP e o comportamento de challenge efetivamente suportado.
• Device Access: Testar o acesso a partir de uma rede de origem permitida e outra não permitida.

Só se executa um número controlado de tentativas falhadas depois de verificar Block login. O resultado esperado não é apenas um início de sessão bem-sucedido: um código incorreto tem de ser rejeitado, a tentativa registada e o serviço acessível exclusivamente a partir das redes previstas.

Interpretar corretamente os logs de autenticação

No Log viewer, verificam-se os inícios de sessão bem-sucedidos e falhados, juntamente com serviço, utilizador, origem, hora e motivo documentado. Dependendo do evento, o SFOS pode fornecer apenas uma indicação genérica, como credenciais incorretas. Sem provas adicionais, não se deve concluir que apenas a palavra-passe, o OTP ou um código expirado causou a falha.

Com MFA externa, os logs de RADIUS, NPS ou IdP fazem parte da mesma verificação. Resolução de problemas do Sophos Firewall: serviços e logs ajuda com ficheiros de log locais e o mapeamento de serviços. Para retenção e correlação mais prolongadas, consultar Enviar Syslog do Sophos Firewall para um SIEM.

Antes da implementação ampla

• Grupo-piloto testado com êxito em todos os serviços necessários.
• Segundo administrador, códigos de utilização única e recuperação através da Device Console documentados.
• Utilizadores informados sobre o registo da aplicação e palavra-passe mais OTP.
• Reposição de tokens definida para smartphones perdidos ou novos.
• Device Access, bloqueios de início de sessão e retenção central de logs verificados.
• Responsabilidades, tempos limite e fallback definidos para MFA externa.

Resolução de problemas

Token, código QR e introdução

O código OTP não é aceite

Primeiro, comparam-se a hora da firewall e do smartphone, a aplicação utilizada, o algoritmo hash e o intervalo. Em Issued tokens, é possível verificar e sincronizar o desvio temporal. Depois de uma migração de algoritmo, o token antigo tem de ter sido eliminado e registado novamente.

Uma alteração do servidor NTP deve ser planeada separadamente, porque a firewall volta a ligar os túneis IPsec existentes.

O código QR não aparece ou não pode ser digitalizado

O utilizador tem de pertencer ao grupo MFA selecionado e iniciar sessão no VPN Portal ou User Portal. Os administradores também podem efetuar o registo no WebAdmin se MFA estiver aí ativa. Além disso, o portal e a origem têm de estar permitidos em Administration > Device access.

No iOS ou com Okta Verify, utiliza-se a chave Base32 em vez da digitalização do código QR quando se aplicam as limitações indicadas.

O início de sessão indica uma palavra-passe incorreta

Num início de sessão Sophos OTP nativo, o código tem de ser introduzido imediatamente após a palavra-passe. Sem um campo OTP separado, a palavra-passe por si só está incompleta.

Acesso, grupos e Remote Access

O portal não está acessível

Primeiro, verificam-se a zona, a origem e o serviço necessário em Administration > Device access. Uma Local Service ACL Exception Rule restritiva é mais segura do que uma permissão WAN geral.

MFA não se aplica ao Remote Access

As configurações de MFA e Remote Access têm de utilizar o mesmo grupo de utilizadores efetivamente importado. Em seguida, volta-se a importar ou distribuir o perfil de cliente e testa-se a ligação com o cliente real. Antes da primeira ligação VPN, o token tem de estar registado através de VPN Portal ou User Portal.

MFA aplica-se apenas a alguns utilizadores

Não se devem comparar apenas os nomes de grupos visíveis, mas os grupos efetivamente correspondentes através de AD, LDAP, RADIUS ou Entra ID. Depois de remover um utilizador AD de um grupo MFA, pode ainda ser necessário um último início de sessão com MFA; só os inícios seguintes deixam de exigir OTP.

Bloqueio e MFA externa

O administrador está bloqueado

Para o admin predefinido, utilizam-se as opções 6 ou 7 da Device Console descritas acima. Para outro administrador, utiliza-se o segundo administrador preparado a partir de uma origem permitida e, em seguida, verificam-se os grupos, o token e o estado do bloqueio de início de sessão.

RADIUS ou Entra MFA não funciona de forma fiável

Verificam-se os tempos limite de RADIUS, os logs do IdP, os grupos e o comportamento de challenge do serviço específico. Um teste bem-sucedido do servidor de autenticação não prova um início de sessão em produção através de VPN Portal, Sophos Connect ou WebAdmin. Cada um destes caminhos deve ser testado separadamente.