Criar e gerir utilizadores locais na Sophos Firewall

Um utilizador local é guardado diretamente na Sophos Firewall e autenticado através da base de dados local de utilizadores. Este modelo é adequado para ambientes pequenos, contas-piloto, colaboradores externos individuais ou um acesso de contingência mantido de forma deliberada. No entanto, a criação da conta, por si só, não concede acesso. O grupo, o método de autenticação, o portal ou cliente, a política de firewall ou VPN e a validação posterior têm de estar alinhados.

O percurso curto e seguro é o seguinte:

1. Definir o caso de utilização, o grupo de destino e o serviço necessário.
2. Preparar um grupo restritivo do tipo Normal em Authentication > Groups.
3. Em Authentication > Users > Add, introduzir um nome de utilizador permanente e selecionar User type: User.
4. Atribuir uma palavra-passe individual forte e o grupo correto.
5. Deixar os campos de políticas do utilizador inalterados quando devem ser aplicados os valores do grupo.
6. Limitar conscientemente Simultaneous sign-ins e Sign-in restriction.
7. Em Authentication > Services, confirmar que Local está selecionado para o serviço utilizado.
8. Configurar separadamente e com o menor âmbito possível o portal, a regra de utilizador ou a política de Remote Access.
9. Usar uma conta-piloto para testar um início de sessão positivo, um negativo e tráfego real.
10. Só depois ativar MFA, criar mais utilizadores e documentar o offboarding.

⚠️ O nome de utilizador não pode ser alterado posteriormente. Por isso, antes de guardar, é necessário definir o esquema de nomes, o tipo de conta e a responsabilidade. Uma nova conta com outro nome cria uma nova identidade e pode separar regras, quotas, atribuições VPN, logs e rastos de auditoria.

Quando um utilizador local é adequado

Os utilizadores locais não necessitam de Active Directory nem de um servidor RADIUS ou LDAP externo. Isto simplifica a implementação, mas transfere totalmente para a firewall a gestão de palavras-passe, MFA, grupos, desativação e revisões. É prático para algumas contas geridas de forma consciente. Com muitos colaboradores ou entradas e saídas frequentes, um diretório central é normalmente mais fácil de manter.

Um utilizador local normal é adequado, por exemplo, para:

• uma conta-piloto para Captive Portal, User Portal ou Remote Access;
• um ambiente pequeno sem serviço de diretório;
• um prestador externo individual com duração e responsabilidade claras;
• um acesso de contingência documentado quando uma fonte externa de utilizadores está temporariamente indisponível.

Não se recomenda uma conta local partilhada por várias pessoas. Credenciais partilhadas dificultam alterações de palavra-passe, MFA, quotas, auditoria e um offboarding limpo.

Não misturar tipos de utilizador

O SFOS disponibiliza vários tipos de utilizador semelhantes que resolvem tarefas diferentes:

• Um utilizador local normal inicia sessão com nome de utilizador e palavra-passe e recebe políticas através de um grupo normal ou de substituições deliberadas ao nível do utilizador.
• Um utilizador convidado tem duração limitada, utiliza as definições Guest User e é normalmente usado através de Captive Portal.
• Um Clientless User é identificado por um endereço IP e não efetua um início de sessão interativo.
• Um administrador local recebe User type: Administrator e um perfil Device Access para permissões WebAdmin.
• Um utilizador AD, LDAP, RADIUS ou Entra é autenticado por uma fonte externa. Dependendo do método, o respetivo registo local só é criado no primeiro início de sessão bem-sucedido.

Para uma pessoa que deva iniciar sessão em Captive Portal ou num serviço VPN, utiliza-se User type: User. Isto não concede à conta acesso WebAdmin nem SSH.

Planear o exemplo e os requisitos

O exemplo seguinte utiliza:

• nome de utilizador pilotuser01;
• nome apresentado Local Pilot User;
• endereço de e-mail pilotuser01@example.com;
• grupo Local_Pilot_Users;
• regra de firewall Local-Pilot-to-WAN;
• origem de início de sessão permitida 10.20.30.0/24.

example.com é um domínio reservado para documentação; 10.20.30.0/24 é usado aqui apenas como rede privada de exemplo. O nome de utilizador, endereço de e-mail, grupo, regra e rede devem ser substituídos por valores do ambiente real. O nome de utilizador é deliberadamente neutro e não contém um endereço de e-mail, para que uma alteração posterior do e-mail não mude a identidade de início de sessão. Num ambiente de produção, o esquema de nomes deve estar alinhado com o helpdesk, o offboarding e os nomes já existentes no diretório.

Antes de criar a conta, é necessário esclarecer:

• Que serviço autentica o utilizador: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec ou outro acesso suportado?
• Que grupo normal contém a configuração comum?
• Que política de firewall ou Remote Access permite o acesso posterior?
• A partir de que endereços IPv4 a conta pode iniciar sessão?
• Quantos inícios de sessão simultâneos são realmente necessários?
• É necessário MFA local e através de que portal será efetuado o registo inicial?
• Quem desativa a conta e verifica as sessões existentes durante o offboarding?

Gerir grupos de utilizadores e Main Group na Sophos Firewall explica a lógica comum dos grupos. Para utilizadores locais normais, usa-se um grupo do tipo Normal. Um grupo do tipo Clientless pertence ao modelo baseado em IP e não é a base adequada para este fluxo de início de sessão.

Criar o utilizador local

A conta é criada em Authentication > Users > Add:

1. Em Username, introduzir pilotuser01.
2. Em Name, introduzir Local Pilot User.
3. Definir User type como User.
4. Introduzir e confirmar uma palavra-passe longa e individual proveniente do processo de palavras-passe previsto.
5. Em Email, introduzir pilotuser01@example.com ou o endereço real do responsável.
6. Em Group, selecionar Local_Pilot_Users.
7. Alterar os campos de políticas e Remote Access apenas quando se pretende uma exceção de utilizador documentada.
8. Definir adequadamente Simultaneous sign-ins e Sign-in restriction.
9. Guardar com Save.

O SFOS rejeita palavras-passe usadas com frequência e palavras detetadas pela verificação de dicionário. O artigo não apresenta deliberadamente uma palavra-passe de exemplo. Uma palavra-passe copiável numa documentação tornar-se-ia imediatamente um segredo conhecido e não seria um modelo seguro.

Valores do grupo ou substituições do utilizador

No registo do utilizador podem ser definidos Surfing quota, Access time, Network traffic e Traffic shaping, além de vários campos de Remote Access. Os valores específicos do utilizador têm prioridade sobre os valores do grupo. Se o grupo deve continuar a ser a configuração de base fácil de manter, estes campos não são substituídos preventivamente.

Uma substituição do utilizador é adequada para uma exceção claramente documentada, por exemplo um Access Time mais restritivo durante uma intervenção temporária. É necessário registar:

• que campo difere do valor do grupo;
• por que motivo a exceção é necessária;
• quando será revista ou removida;
• como o valor original do grupo voltará a ser aplicado.

Access Time para utilizadores e quotas de Surfing e Network Traffic explicam integralmente cada política. No objeto de utilizador só se atribui uma política cujo funcionamento já seja compreendido.

Limitar o número e a origem dos inícios de sessão

Simultaneous sign-ins limita as sessões simultâneas. Global setting adota o valor aplicável aos novos utilizadores em Authentication > Services. Em alternativa, pode definir-se um valor próprio ou escolher Unlimited. Sessões ilimitadas raramente são necessárias para um utilizador pessoal normal e dificultam a deteção de credenciais partilhadas.

Sign-in restriction limita os endereços IPv4 a partir dos quais o utilizador pode iniciar sessão:

• Any node: permitir o início de sessão a partir de qualquer origem alcançável;
• User group nodes: herdar o valor do grupo;
• Selected nodes: indicar endereços IPv4 individuais previstos;
• Node range: permitir um intervalo IPv4 contínuo.

No exemplo utiliza-se a rede real de gestão, utilizadores ou VPN, em vez de copiar cegamente 10.20.30.0/24. Uma seleção demasiado restrita bloqueia inícios de sessão legítimos. Any node, por outro lado, apenas amplia a possível origem de início de sessão e não substitui uma regra de firewall, uma ACL do portal ou MFA.

Não se ativa MAC binding neste fluxo básico. Suporta autenticação baseada no cliente, mas não Remote Access VPN nem Captive Portal. Se for ativado sem um endereço MAC, o SFOS associa automaticamente o primeiro endereço MAC detetado no primeiro início de sessão. Em dispositivos móveis, após uma mudança de Wi-Fi ou em clientes partilhados, isto pode tornar-se rapidamente uma dependência inesperada.

Associar o método de autenticação e o acesso

Um utilizador guardado só pode iniciar sessão num serviço que consulte realmente a base de dados local. Por isso, em Authentication > Services, seleciona-se Local para o serviço previsto.

As áreas estão separadas:

• Firewall authentication methods para tráfego de firewall e Captive Portal;
• User portal authentication methods para User Portal;
• VPN portal authentication methods para VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods para estes métodos VPN;
• SSL VPN authentication methods para Remote Access SSL VPN.

Quando existem várias fontes, são consultadas pela ordem apresentada. Assim, um teste bem-sucedido em User Portal não prova automaticamente que o mesmo utilizador está configurado corretamente para SSL VPN ou IPsec.

Portal, regra ou política VPN permanecem separados

A identidade local não abre um caminho de rede. Captive Portal requer adicionalmente Device Access, Web Authentication e uma regra de utilizador adequada. O fluxo completo é apresentado em Configurar e testar Captive Portal na Sophos Firewall.

User Portal e VPN Portal também são serviços separados. O modelo de portais da Sophos Firewall explica portas, finalidade, Device Access e limites WAN. As políticas de Remote Access são mantidas nos respetivos guias VPN e não são consideradas concluídas apenas porque foi definido um campo no objeto do utilizador.

Para uma regra de firewall baseada em utilizadores, a origem, o destino, o serviço e o utilizador ou grupo são definidos com o menor âmbito possível. Log firewall traffic permanece ativo durante a validação. Os fundamentos são explicados em Compreender e configurar com segurança as regras da Sophos Firewall.

Validar com testes positivos e negativos

Uma conta visível com estado Active ainda não comprova o sucesso. A conta-piloto é testada através do serviço que será realmente utilizado:

1. Iniciar sessão como pilotuser01 numa janela privada do navegador ou a partir de um cliente de teste limpo.
2. Em Current activities > Live users, verificar o nome de utilizador, o IP de origem e o Client Type.
3. Em Log Viewer > Authentication, verificar o início de sessão bem-sucedido, a autenticação local e a hora.
4. Gerar o tráfego previsto e verificar a regra ou política esperada no log da firewall ou VPN.
5. Usar uma origem ou função expressamente não permitida como teste negativo.
6. Se estiver ativa uma quota ou um Access Time, testar separadamente o efeito dentro e fora do limite.
7. Documentar o resultado, o grupo utilizado, as substituições do utilizador e o método de autenticação.

Um teste de início de sessão negativo não deve falhar apenas porque se usou intencionalmente uma palavra-passe incorreta. Também se confirma que uma origem não autorizada, um utilizador sem o grupo adequado ou uma função não prevista não obtêm realmente acesso. Desta forma, separa-se a validação da palavra-passe do efeito das políticas e regras.

Se ainda não estiver claro se falha a base de dados local, a seleção do serviço, o estado do utilizador, o grupo ou a regra posterior, resolver sistematicamente erros de autenticação da Sophos Firewall apresenta toda a sequência de verificação. Para uma análise aprofundada, /log/access_server.log contém eventos de autenticação, autorização e contabilização; Log Viewer continua a ser o primeiro passo.

Gerir palavras-passe, MFA e utilização

Um utilizador local pode alterar a própria palavra-passe em User Portal > Personal > Change Password. Isto aplica-se à base de dados local, não a contas AD, LDAP ou RADIUS autenticadas externamente. User Portal só é disponibilizado a partir das zonas necessárias e não é aberto de forma geral à WAN apenas para a gestão de palavras-passe.

Para proteção adicional, a conta pode ser selecionada em Authentication > Multi-factor authentication. Com Generate OTP token with next sign-in, o utilizador regista o token através de User Portal ou VPN Portal. MFA para Sophos Firewall explica o algoritmo de hash, o acesso ao portal, a recuperação e a fase piloto. A MFA só é ativada quando o início de sessão normal e o caminho de recuperação funcionam.

Em Authentication > Users > > View usage é possível ver as quotas atribuídas, o tempo de Surfing e o consumo de dados. Para isso, o tráfego tem de corresponder a uma regra de firewall baseada em utilizadores com Log firewall traffic. Reset user accounting reinicia os contadores de Surfing e Network Traffic e, por isso, não é utilizado como correção geral para problemas de início de sessão.

Desativar e remover a conta de forma segura

Quando uma pessoa sai ou termina a finalidade da conta, esta não é eliminada imediatamente sem verificação:

1. Verificar dependências em regras, grupos, políticas Remote Access, quotas, MFA e documentação.
2. Em Authentication > Users, selecionar o utilizador e usar Change status para o tornar inativo.
3. Efetuar um novo início de sessão como teste negativo.
4. Em Current activities > Live users, verificar as sessões existentes e usar Disconnect para um utilizador normal quando necessário.
5. Verificar os logs da firewall e VPN quanto a novas tentativas ou tráfego residual.
6. Eliminar a conta apenas depois de esclarecer as dependências ou mantê-la inativa de acordo com o processo de retenção.

A desativação não é tratada como garantia de encerramento automático de todas as ligações existentes. Sessões, túneis e tráfego são verificados separadamente. Depois de uma reativação, repetem-se os testes positivos e negativos.

Utilizadores e grupos partilham identificadores internos. Um grande número de objetos, por si só, não prova um problema. Contudo, se um utilizador apresentar uma User ID superior a 65535 e não for autenticado, utiliza-se o fluxo separado relativo ao limite de User ID da Sophos Firewall, em vez de alterar palavras-passe ou regras por tentativa.

Delimitar erros por sintoma

O nome de utilizador e a palavra-passe são rejeitados

Em Authentication > Users, verificar se a conta é local, está ativa e existe com o nome de utilizador esperado. Depois, em Authentication > Services, confirmar se Local está selecionado para o serviço específico. Um início de sessão bem-sucedido noutro portal não comprova esta seleção do serviço.

O início de sessão funciona, mas a regra de utilizador não corresponde

Em Current activities > Live users, verificar a identidade, o IP de origem e o Client Type. Depois, controlar no Log Viewer a posição da regra, Source Zone, o utilizador ou grupo e Firewall Rule ID. Uma regra de rede acima da regra de utilizador pode já ter assumido o fluxo.

Uma alteração do grupo não tem efeito

Procurar no utilizador valores específicos para quota, Access Time, Traffic Shaping ou Remote Access. Estas substituições têm prioridade sobre o grupo. O valor só é reposto na herança do grupo depois de ser comparado com a exceção documentada.

O utilizador pode iniciar sessão a partir de uma origem inesperada

Verificar Sign-in restriction no utilizador e no grupo. Confirmar também o serviço efetivamente utilizado, Device Access e a regra de rede. Uma definição Any node não é automaticamente compensada por MFA nem por uma regra de firewall restritiva.

View usage permanece vazio

Verificar se o utilizador é reconhecido como Live User e se o tráfego corresponde a uma regra baseada em utilizadores com Log firewall traffic. Depois, controlar o período, a atribuição de quota e o tráfego real de teste. Reset user accounting não gera logs em falta nem corrige uma regra errada.

Lista de verificação operacional

• O caso de utilização, o responsável e a data de expiração da conta estão documentados.
• O nome e o tipo de utilizador foram escolhidos conscientemente antes de guardar.
• Um grupo do tipo Normal contém a configuração comum.
• As substituições do utilizador são evitadas ou justificadas.
• Simultaneous sign-ins e Sign-in restriction são adequados ao caso de utilização.
• Local está selecionado para cada serviço de autenticação necessário.
• O portal, a regra de firewall ou a política VPN foram configurados separadamente.
• Foram verificados o início de sessão positivo, o negativo e o tráfego real.
• Live Users, Authentication Log e a regra ou política esperada estão alinhados.
• MFA e a recuperação foram testados, caso se utilize MFA.
• Uma pessoa responsável gere alterações de palavra-passe, utilização e offboarding.
• Desativação, sessões existentes e eliminação posterior são passos separados.

Perguntas frequentes