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.

O procedimento principal configura o Sophos OTP local. Mais adiante, RADIUS e Entra ID SSO são comparados como alternativas.

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. No SFOS 23, selecionar também Share QR code: Email envia o código QR para o endereço de correio eletrónico do utilizador no próximo início de sessão no VPN Portal ou User Portal. Portals apresenta-o no User Portal e VPN Portal depois do próximo início de sessão no VPN Portal, User Portal ou WebAdmin. Esta escolha não diz respeito ao assistente do admin predefinido descrito abaixo.
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.

Depois de Apply, concluir imediatamente o processo com um utilizador-piloto: consoante o serviço selecionado, iniciar primeiro sessão no User Portal ou VPN Portal apenas com a palavra-passe, registar o código QR ou a chave Base32 na aplicação de autenticação e abrir depois uma nova sessão com <password><passcode>. Um código deliberadamente incorreto tem de ser recusado e a tentativa deve aparecer no Log viewer. All users só deve ser considerado depois deste teste positivo e negativo.

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.

Para utilizadores autenticados externamente, a remoção de um grupo MFA não produz efeito imediato no primeiro início de sessão seguinte. A Sophos ainda exige um início de sessão com MFA; o OTP deixa de ser necessário apenas nos acessos posteriores. Por isso, uma alteração de grupo é verificada com uma sessão nova e pelo menos dois inícios de sessão controlados.

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 regista o código QR numa aplicação compatível. No SFOS 22, o QR é apresentado; os administradores também podem registar o token no WebAdmin quando MFA é aí imposta. No SFOS 23, a entrega segue Share QR code: com Email, utiliza-se o QR recebido por correio eletrónico; com Portals, o apresentado nos portais. Um início de sessão no WebAdmin pode desencadear a apresentação nos portais com Portals, mas não o envio por correio eletrónico. O registo aplica-se apenas aos utilizadores e grupos para os quais MFA está configurado.

No registo inicial no SFOS 23 com Generate OTP token with next sign-in em ON, aplica-se a seguinte regra aos utilizadores MFA selecionados: o QR gerado expira se não for utilizado para iniciar sessão nas 24 horas seguintes à geração. Para gerar outro, o utilizador inicia sessão no VPN Portal ou User Portal apenas com a palavra-passe; o novo QR é entregue de acordo com Email ou Portals. Depois, regista-se na aplicação e verifica-se um novo início de sessão com <password><passcode>. Esta duração do QR é distinta da janela de 300 segundos do primeiro código. O fluxo não se aplica a um token emitido com estado OFF nem à reemissão manual de um seed; não se pressupõe para o SFOS 22 nem para todos os fluxos do assistente do admin predefinido.

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.

Definir o estado do token como OFF impede o utilizador de iniciar sessão; não permite acesso apenas com a palavra-passe. Isto não equivale a eliminar e voltar a registar o token nem a ignorar MFA para um único início de sessão através da Device Console.

Se um smartphone for perdido ou a aplicação for alterada, verifica-se primeiro a identidade do utilizador. Imediatamente antes da eliminação, verifica-se em Authentication > Multi-factor authentication que Generate OTP token with next sign-in está em ON; no SFOS 23, define-se também Share QR code como Email ou Portals. Se o modo manual OFF for intencional, prepara-se antes uma nova emissão manual com um novo seed; o fluxo QR automático abaixo não se aplica. Só depois se elimina o token antigo em Issued tokens. O utilizador inicia sessão uma vez no VPN Portal ou User Portal apenas com a palavra-passe e regista o novo QR: o SFOS 22 apresenta-o, enquanto o SFOS 23 o envia por correio eletrónico ou o apresenta no portal conforme a escolha. Depois, verifica-se um novo início de sessão com <password><passcode>. Um token antigo não deve continuar a existir em paralelo sem controlo.

Neste fluxo de mudança de aplicação ou substituição no SFOS 23, o QR gerado expira se não for utilizado para iniciar sessão nas 24 horas seguintes à geração. Voltar a iniciar sessão apenas com a palavra-passe gera um novo QR, novamente entregue através de Email ou Portals. As 24 horas referem-se ao QR, não à janela de 300 segundos do primeiro código explicada abaixo. Não se pressupõe esta duração do QR para o SFOS 22 nem para todos os fluxos do assistente do admin predefinido.

Disponibilizar manualmente um token de hardware ou software

Se a firewall não tiver de gerar um código QR, Generate OTP token with next sign-in permanece desativado. Os tokens já registados continuam a funcionar; para novos utilizadores, o seed é guardado manualmente em Authentication > Multi-factor authentication > Issued tokens > Add token (for hardware tokens). O nome do botão é mais restrito do que a função, porque o mesmo diálogo também pode ser utilizado para um token de software disponibilizado manualmente.

Primeiro, selecionam-se OTP hash algorithm e o intervalo de tempo exigidos pelo token ou pela aplicação de autenticação em causa. Para Secret, aplicam-se depois as seguintes regras:

• Num token de hardware, introduz-se a chave individual fornecida pelo fabricante.
• Num token de software, utiliza-se um seed hexadecimal único e suficientemente aleatório. Se a aplicação exigir Base32, o seed é convertido localmente com uma ferramenta offline controlada.
• Um seed de produção não deve ser introduzido num site público de conversão, nem incluído num ticket, numa mensagem de correio eletrónico não cifrada ou num comando shell guardado no histórico. Quem conhecer o seed pode gerar códigos OTP válidos.

Se o token individual for diferente do Default token timestep global, ativa-se Use custom timestep apenas para esse token e introduz-se o intervalo efetivamente suportado. Sem esta opção aplica-se o valor global; a compatibilidade da aplicação e do hardware é verificada antes de guardar.

Em seguida, seleciona-se exatamente o utilizador previsto e guarda-se com Save. O token de hardware ou o seed Base32 é entregue uma única vez através de um canal protegido. Depois, testa-se um código correto e outro deliberadamente incorreto e, se necessário, sincroniza-se o desvio temporal em Issued tokens. Se o seed puder ter sido exposto, o token não deve continuar a ser utilizado: elimina-se o token e emite-se outro com um novo seed.

Disponibilizar códigos de utilização única adicionais de forma controlada

Se o acesso à aplicação ou ao token de hardware estiver indisponível apenas temporariamente, edita-se o utilizador afetado em Authentication > Multi-factor authentication > Issued tokens. Em Additional codes, o botão de adição gera códigos adicionais e Save associa-os ao token. A firewall remove automaticamente cada código da lista depois de este ser utilizado.

Antes da disponibilização, verifica-se a identidade do utilizador. Os códigos são entregues uma única vez através de um canal protegido exclusivamente a esse utilizador e não são colocados em conjunto num ticket ou numa mensagem de correio eletrónico sem proteção. Os códigos adicionais não substituem a reemissão de um token perdido de forma permanente ou potencialmente copiado: elimina-se o token antigo e regista-se outro com um novo seed.

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.

O Sophos Intercept X for Mobile suporta um timestep de token personalizado. A maioria das outras aplicações de autenticação suporta apenas o valor predefinido de 30 segundos, pelo que o valor global não é alterado unicamente para uma aplicação.

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.

Depois de uma atualização a partir de uma versão anterior ao SFOS 22, podem permanecer tokens SHA1 existentes, porque as versões anteriores do SFOS geravam tokens MFA com SHA1. A seleção de um algoritmo global mais forte não converte estes tokens existentes.

Para migrar de SHA1 para um algoritmo mais forte:

1. Testar a aplicação-piloto com SHA256 ou SHA512.
2. Ativar Generate OTP token with next sign-in. No SFOS 23, escolher também Email ou Portals em Share QR code antes de Apply.
3. Selecionar o novo algoritmo em Authentication > Multi-factor authentication.
4. Guardar com Apply.
5. Eliminar os tokens SHA1 antigos em Issued tokens. Para eliminar o token do admin predefinido, é necessário ter sessão iniciada como esse utilizador; outro administrador não o pode eliminar. Manter previamente disponíveis o acesso de fallback testado e o acesso à consola.
6. Fazer com que os utilizadores normais iniciem sessão no VPN Portal ou User Portal apenas com a palavra-passe e registem novamente o QR ou a chave Base32 numa aplicação compatível com SHA256/SHA512. No SFOS 23, a entrega do QR segue Email ou Portals. Para o admin predefinido, o novo registo após a eliminação começa, em contrapartida, com um início de sessão no WebAdmin apenas com a palavra-passe, não através do User Portal ou VPN Portal; seguir o fluxo de registo aí apresentado. Isto é a migração SHA, não Use an existing token no assistente de reativação. Não pressupor um seletor Share QR code adicional no assistente para esta exceção.
7. 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.

Limitar o intervalo de tempo e as janelas de tolerância

Em OTP timestep settings, configura-se não só o intervalo dos novos códigos, mas também duas janelas de verificação. Os três valores têm efeitos diferentes:

• Default token timestep define o intervalo em que a aplicação ou o token de hardware gera um novo código. O valor predefinido é de 30 segundos. Uma alteração aplica-se apenas aos tokens gerados posteriormente e não modifica os tokens existentes.
• Maximum verification code offset determina durante quantos intervalos um código ainda não utilizado permanece válido. Com o valor predefinido 2 e um intervalo de 30 segundos, também são aceites códigos não utilizados dos 60 segundos anteriores.
• Maximum initial verification code offset aplica-se ao primeiro código depois da leitura do código QR. Com o valor predefinido 10 e um intervalo de 30 segundos, a janela é de 300 segundos se o código ainda não tiver sido utilizado.

Estas janelas não substituem uma sincronização correta da hora. Primeiro, verificam-se o NTP da firewall e a hora do dispositivo; depois, mantém-se cada offset tão pequeno quanto seja praticável para as aplicações e os tokens de hardware utilizados. Uma janela maior aceita durante mais tempo um código intercetado que ainda não tenha sido utilizado. Após uma alteração, testa-se um novo token piloto; não se pressupõe que um token existente utilize o timestep alterado.

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. O seu assistente próprio encontra-se em Administration > Device access, não em Issued tokens > Add token (for hardware tokens) para utilizadores normais.

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.

Antes de começar, verificam-se também a hora, a compatibilidade da aplicação ou do hardware e Block login, como descrito acima. Os novos tokens de hardware e software utilizam o algoritmo definido em Authentication > Multi-factor authentication > OTP hash algorithm; não é escolhido separadamente no assistente do administrador predefinido. Uma leitura bem-sucedida do QR não comprova a compatibilidade do algoritmo. Continuam a aplicar-se as limitações de aplicações e Base32 já descritas.

1. Iniciar sessão no WebAdmin como admin predefinido e abrir Administration > Device access.
2. Ativar MFA for default admin e clicar em Apply.
3. Selecionar o método de token adequado no assistente e clicar em Next. Em seguida, concluir a opção correspondente:

• Configure a hardware token: Introduzir a chave individual fornecida pelo fabricante do dispositivo e o intervalo de tempo correspondente ao token de hardware. Clicar em Next e introduzir a palavra-passe do administrador predefinido imediatamente seguida do código atual do hardware, no formato <password><passcode>, sem espaços nem separadores. Clicar em Validate e, após uma validação bem-sucedida, concluir com Apply.
• Generate a software token: Instalar uma aplicação de autenticação compatível no dispositivo móvel e digitalizar o código QR apresentado. Introduzir a palavra-passe do administrador predefinido imediatamente seguida do código atual da aplicação, no formato <password><passcode>. Clicar em Validate e, após uma validação bem-sucedida, concluir com Apply.
• Use an existing token: Se já existir um token de hardware ou software para o admin predefinido e apenas se estiver a reativar MFA, selecionar esta opção e introduzir a palavra-passe imediatamente seguida do código atual. Para configurar antes um novo token de software, selecionar Generate a software token e registar o código QR na aplicação. Esta escolha não é uma migração dos tokens de utilizador SHA1 existentes.

O primeiro Apply inicia a configuração; os novos tokens de hardware e software continuam a exigir Validate e o Apply final. Se a validação falhar, verificar primeiro a palavra-passe mais o código, a hora, o intervalo e o algoritmo, em vez de repetir tentativas ao acaso. Manter a sessão existente aberta durante a verificação e, após concluir a configuração, testar uma nova sessão WebAdmin separada como admin predefinido com a palavra-passe mais um código novo. Considerar a configuração concluída apenas depois de um início de sessão bem-sucedido e do armazenamento seguro dos códigos de utilização única; o segundo administrador não substitui a gestão do token do administrador predefinido nem o procedimento de recuperação pela consola descrito abaixo.

Recuperação através da Device Console

As opções de menu 6 e 7 só aparecem se MFA for default admin já tiver sido configurado em Administration > Device access. Se não aparecerem, não se deve assumir automaticamente um erro da consola; verificar primeiro esta definição e se a conta é realmente o utilizador predefinido admin. As opções não se aplicam a outras contas de administrador.

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.

Para sincronizar, abre-se Authentication > Multi-factor authentication > Issued tokens, seleciona-se Synchronize token time offset para o token afetado, introduz-se o código atual gerado pela aplicação ou pelo token de hardware e clica-se em Check. O desvio temporal é sincronizado com a firewall, corrigindo a diferença entre os relógios. Depois, testa-se de forma controlada um novo início de sessão; mantém-se o fallback disponível e verifica-se Block login antes de mais tentativas falhadas.

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. No SFOS 22, os administradores também podem efetuar o registo no WebAdmin se MFA estiver aí ativa. No SFOS 23, verifica-se primeiro Share QR code: com Email, verifica-se a caixa de entrada depois do início de sessão no portal em vez de esperar um QR no portal; com Portals, o QR é apresentado nos portais, também depois de um início de sessão no WebAdmin que desencadeie essa apresentação. Além disso, o portal e a origem têm de estar permitidos em Administration > Device access. No registo inicial ou na substituição da aplicação no SFOS 23 com a geração de tokens ativada, verifica-se também a duração de 24 horas explicada acima: se o QR não tiver sido utilizado para iniciar sessão nesse período, inicia-se sessão no VPN Portal ou User Portal apenas com a palavra-passe e regista-se o novo QR entregue de acordo com Email ou Portals.

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.