Configurar acesso de suporte Avanet no Sophos Firewall

Num caso de suporte, a Avanet pode precisar temporariamente de acesso direto à consola WebAdmin de um Sophos Firewall. Este acesso só é seguro se estiver limitado a uma origem de suporte conhecida, ao serviço necessário e a um período claramente definido. As permissões WAN globais para HTTPS e SSH permanecem desativadas; o acesso é concedido através de uma Local service ACL exception rule específica.

Em muitos casos, uma partilha de ecrã ou um acesso de parceiro existente e controlado é suficiente. Um novo acesso WAN direto só faz sentido quando a Avanet precisa de analisar o problema ou efetuar alterações de forma autónoma. O SSH só é acrescentado quando são necessários a Device Console, a Advanced Shell ou ficheiros de registo.

Os fundamentos técnicos são explicados em Device Access e Local Service ACL no Sophos Firewall. Antes de efetuar alterações, também deve existir uma cópia de segurança atual do Sophos Firewall.

Importante: O acesso de suporte é um acesso administrativo à firewall. O utilizador, a regra ACL e a chave SSH têm de ser desativados ou removidos após a conclusão do caso, salvo se tiver sido acordado um acesso permanente.

Diagnostics > Support access não substitui este procedimento. A função gera um Access ID temporário exclusivamente para o Sophos Support, permitindo acesso ao WebAdmin e à shell sem credenciais de administrador. Esse ID não deve ser partilhado com a Avanet.

Definir o acesso e o período

Antes da configuração, devem ficar registados no ticket:

• os trabalhos que a Avanet está autorizada a realizar,
• se o WebAdmin é suficiente ou se também é necessário SSH,
• quando começa e termina o acesso,
• qual a origem de suporte Avanet utilizada,
• quem autoriza o acesso e verifica a sua remoção.

A Avanet deve indicar no ticket autenticado o IP público de saída exato ou um FQDN explicitamente destinado ao suporte. A origem não deve ser inferida de um site nem adivinhada. Antes da alteração, deve abrir-se e testar-se um acesso independente pela consola, LAN de gestão, VPN administrativa ou Sophos Fusion (anteriormente Sophos Central).

Um acesso Avanet ou de parceiro já existente não deve ser complementado com uma segunda conta permanente. Nesse caso, devem ser verificados o perfil, o MFA, a limitação da origem e o estado da conta existente. Para uma análise conjunta sem início de sessão direto, a partilha de ecrã é frequentemente a opção de menor risco.

Configurar o utilizador WebAdmin

O procedimento geral para contas pessoais, perfis, MFA e offboarding está em Configurar administradores e perfis Sophos Firewall em segurança. Esta secção acrescenta o caso específico de suporte, com intervalo de tempo, origem de suporte e remoção controlada.

Uma conta local do caso, por exemplo avanet-<ticket>, destina-se exclusivamente ao WebAdmin e permite atribuir melhor as alterações no Audit Trail. O SFOS guarda o nome em minúsculas e não permite alterá-lo posteriormente.

1. Abrir Authentication > Users.
2. Selecionar Add.
3. Introduzir o nome de utilizador e o nome de apresentação.
4. Definir User type como Administrator.
5. Selecionar um Profile adequado.
6. Introduzir uma palavra-passe forte, utilizada apenas para este acesso, e um endereço de e-mail.

Como Username, pode utilizar-se avanet-<ticket>, substituindo <ticket> pelo número interno. Este guia não publica palavras-passe nem endereços de suporte. O perfil Administrator concede acesso WebAdmin total e só deve ser usado quando necessário. Caso contrário, em Profiles > Device access, deve começar-se com Read-only e conceder Read-write apenas para alterações autorizadas.

Em Administrator advanced settings estão disponíveis duas limitações adicionais:

• Schedule for device access: permite o início de sessão na consola WebAdmin apenas durante o horário selecionado.
• Login restriction for device access: permite o início de sessão apenas a partir de endereços IPv4 selecionados ou de um intervalo IPv4.

Se o IP fixo de suporte for conhecido, também deve ser introduzido em Login restriction for device access. A Local Service ACL limita assim a acessibilidade da consola, enquanto a restrição do utilizador limita adicionalmente o início de sessão desta conta. Guardar com Save.

Testar previamente a palavra-passe e o MFA

A palavra-passe é transmitida por um canal seguro e não é colocada em mensagens ou tickets. Em Authentication > Multi-factor authentication, selecionar Specific users and groups para OTP, adicionar a conta do caso e ativar Web admin console em Require MFA for. O segredo, QR code e códigos únicos não pertencem ao ticket. Se o MFA não estiver tecnicamente disponível, deve usar-se partilha de ecrã ou VPN em vez de o omitir. Ver MFA para administradores.

Limitar a origem de suporte e a Local Service ACL

Criar o objeto de origem confirmado no ticket

Para uma janela curta, um host IP que contenha apenas o endereço público confirmado tem o menor âmbito de confiança. Se o ticket indicar explicitamente um FQDN, a Local Service ACL também aceita um host FQDN e confia em todos os endereços resolvidos até ao fim do TTL DNS. FQDN wildcard não é suportado.

1. Para um IP fixo, abrir Hosts and services > IP host, selecionar Add e guardar o endereço confirmado como host IPv4 único.
2. Apenas para um FQDN confirmado, abrir Hosts and services > FQDN host e selecionar Add.
3. Introduzir um Name do caso e copiar para FQDN o valor exato do ticket.
4. Guardar com Save, voltar a abrir o objeto e verificá-lo.

Para um FQDN, comparar todos os endereços resolvidos com o ticket. Um endereço inesperado ou não confirmado obriga a parar: utilizar o único IP confirmado ou pedir esclarecimento à Avanet.

Criar a Local Service ACL Exception Rule

HTTPS e SSH são serviços locais da firewall. As regras de firewall normais não controlam este tráfego. Por isso, a permissão é configurada em Administration > Device access.

1. Abrir Administration > Device access.
2. Na área Local service ACL, garantir que HTTPS e SSH não estão globalmente ativados para WAN.
3. Deslocar-se até à área Local service ACL exception rule e selecionar Add.
4. Criar a regra com os valores seguintes.

• Rule name: Avanet-Support
• Rule position: Top
• Description: número do ticket, finalidade e data de fim prevista
• IP version: IPv4
• Source zone: WAN
• Source Network / Host: exatamente o objeto IP ou FQDN confirmado
• Destination host: endereço público da firewall ou Any, se a firewall tiver de estar acessível através de vários endereços WAN adequados
• Services: HTTPS; SSH apenas quando a necessidade estiver confirmada; Ping/Ping6 apenas para um diagnóstico específico
• Action: Accept

Guardar com Save. A posição Top garante que a permissão específica é avaliada antes de uma regra Drop sobreposta. Ainda assim, é necessário verificar as Exception Rules existentes: uma regra Accept mais abrangente acima ou uma zona de origem incorreta pode alterar o modelo de segurança pretendido.

Não utilizar: Any ou 0.0.0.0 como Source. A Sophos impede por boas razões uma permissão WAN global para a consola WebAdmin. Para este procedimento, a caixa WAN de HTTPS ou SSH também não pode ser ativada.

Adicionar SSH apenas quando necessário

O SSH dá acesso à Device Console e à Advanced Shell, sendo assim muito mais abrangente do que um perfil WebAdmin limitado. Em muitos casos de suporte, Services deve, por isso, permanecer limitado a HTTPS.

O utilizador avanet não pode ser utilizado para SSH. O Sophos Firewall aceita apenas o utilizador predefinido admin para a CLI. Por esse motivo, a Public Key não é associada ao utilizador avanet, mas configurada globalmente em Public key authentication for admin.

1. Abrir Administration.
2. Selecionar Device access.
3. Deslocar-se até à área Public key authentication for admin.
4. Ativar Enable authentication.
5. Introduzir em Authorized keys a Public Key confirmada para o caso atual e adicioná-la através do símbolo de adição.
6. Selecionar Apply.

Apenas o administrador predefinido pode adicionar ou eliminar chaves SSH; para um administrador personalizado, o botão Apply não é apresentado. A Sophos suporta chaves RSA a partir de 2048 bits, bem como determinadas chaves DSA e ECDSA, mas não ED25519. Para uma nova chave de suporte, deve ser utilizada uma chave moderna, suficientemente forte e suportada pelo cliente SSH utilizado.

Uma Public Key tem, por exemplo, a estrutura seguinte:

ssh-rsa <base64-public-key> avanet-support-<ticket>

A chave privada permanece com o técnico de suporte e nunca é guardada na firewall. Após a conclusão do caso de suporte, a Public Key associada ao caso é removida e o SSH é retirado da Exception Rule, salvo se tiver sido acordado um acesso permanente. O procedimento prático de início de sessão é explicado em Ligar ao Sophos Firewall através de SSH.

Testar o acesso e identificar erros

Um início de sessão bem-sucedido a partir da origem permitida não é suficiente para aceitar a configuração. Também deve ser confirmado que o acesso permanece bloqueado a partir de outra origem na Internet.

1. Abrir o WebAdmin através da origem de suporte Avanet acordada e da porta de administração configurada. A porta predefinida é TCP 4444, mas pode ter sido alterada em Administration > Admin and user settings.
2. Iniciar sessão com avanet e verificar se o perfil selecionado permite aceder aos menus necessários.
3. Utilizar uma segunda origem na Internet que não esteja autorizada. A consola WebAdmin não pode estar acessível a partir dessa origem.
4. Se o SSH tiver sido autorizado, testar o início de sessão como admin com a Private Key associada ao caso. O SSH por palavra-passe não é necessário para este teste.
5. Verificar os eventos de autenticação no Log viewer. As alterações de configuração são verificadas adicionalmente no Audit Trail.
6. Documentar no ticket o resultado do teste e a hora de fim do acesso.

Se o WebAdmin não estiver acessível

A verificação começa na origem e prossegue até à firewall:

• O IP de saída efetivo corresponde ao objeto de origem e, para um FQDN, à resolução DNS atual?
• O acesso é realmente proveniente da zona selecionada em Source zone?
• O endereço WAN utilizado corresponde ao Destination host?
• A Exception Rule está em Top e inclui HTTPS?
• Está a ser utilizada a porta WebAdmin correta?
• Um router do fornecedor, um dispositivo NAT a montante ou uma ACL upstream está a bloquear o acesso?
• A opção Login restriction for device access permite a ligação TCP, mas impede o início de sessão do utilizador?

As caixas WAN globais de HTTPS ou SSH não são ativadas para resolver problemas. Se a Exception Rule estiver correta, não são necessárias para este acesso específico.

Se o início de sessão falhar

Se a consola estiver acessível, mas não for possível iniciar sessão, devem ser verificados o estado do utilizador, a palavra-passe, o MFA, o perfil, Schedule for device access, Login restriction for device access e as definições globais de bloqueio de início de sessão em Administration > Admin and user settings. Após várias tentativas falhadas, o Sophos Firewall pode bloquear temporariamente o endereço IP de origem em todos os serviços de autenticação.

Remover o acesso de forma controlada

Após a conclusão do caso de suporte, devem ser verificadas separadamente as alterações acordadas e o próprio acesso:

1. Verificar no Audit Trail que alterações de configuração foram efetuadas com avanet.
2. Em alterações mais extensas ao conjunto de regras, o Sophos Firewall Config Studio pode ajudar a comparar o antes e o depois.
3. Desativar ou eliminar primeiro a Local Service ACL Exception Rule para fechar o caminho externo.
4. Confirmar a partir da origem anterior que WebAdmin e SSH não estão acessíveis e que o acesso de gestão independente continua a funcionar.
5. Remover apenas a chave SSH do caso; desativar Enable authentication apenas se nenhuma outra chave depender dela.
6. Desativar ou eliminar a conta do caso e o token MFA, salvo acesso permanente expressamente aprovado.
7. Uma segunda pessoa compara ACL, conta, chaves, Audit Trail e ticket com o estado inicial.

Um acesso de parceiro mantido intencionalmente continua a exigir MFA, uma origem estritamente limitada, uma pessoa responsável e uma revisão regular. Um ticket inativo não justifica um acesso de gestão permanentemente aberto.

Perguntas frequentes