Ligar ao Sophos Firewall por SSH

Muitas tarefas de suporte e resolução de problemas exigem acesso à Sophos Firewall por SSH. É o caso, por exemplo, da análise de logs, do reinício de serviços, de comandos específicos de diagnóstico ou do trabalho na Advanced Shell.

O SSH é também uma interface de administração de alto risco. Por isso, o acesso só deve ser permitido a partir de redes administrativas de confiança, através de uma regra de exceção Local Service ACL restrita ou de acesso de suporte claramente definido. Para proteger os serviços locais da firewall de forma mais abrangente, consulte Configurar Device Access corretamente.

Requisitos

Para uma ligação SSH à Sophos Firewall, é necessário:

• Acesso administrativo à Sophos Firewall.
• O endereço IP ou nome DNS da firewall.
• Acesso ao utilizador admin.
• Uma palavra-passe do administrador predefinido alterada e documentada de forma segura; a palavra-passe de fábrica não deve continuar a ser utilizada em produção.
• Uma origem administrativa de confiança, por exemplo, uma rede de gestão, VPN ou um IP de administração fixo.
• No macOS ou Linux: a aplicação Terminal pré-instalada com SSH.
• No Windows: Windows Terminal com OpenSSH ou PuTTY.
• Acesso SSH permitido em Administration > Device access ou através de uma Local service ACL exception rule.
• Para alterações planeadas na Advanced Shell: cópia de segurança, janela de manutenção e um plano claramente definido para reverter as alterações em caso de problemas.

⚠️ O SSH só deve ser permitido a partir de redes de confiança. Em produção, restrinja o acesso a um IP de gestão ou a uma rede administrativa, em vez de permitir SSH indiscriminadamente.

Definir a finalidade do acesso SSH

Nem toda a análise exige a Advanced Shell. Antes de iniciar sessão, determine qual a consola necessária e até que ponto a intervenção pode afetar o sistema.

• Encaminhamento, DNS, ping e comandos simples do sistema: a Device Console utiliza a CLI da Sophos e implica menos riscos do que a Advanced Shell.
• Informações detalhadas do sistema, bases de dados ou serviços do sistema: pode ser necessária a Advanced Shell. Sem instruções Sophos fiáveis e específicas do caso, limite-se a verificações só de leitura e não altere nem elimine nada.
• Estado de serviços ou depuração: utilize a Advanced Shell. Ative a depuração apenas para uma finalidade concreta e desative-a depois.
• Comandos desconhecidos: Verifique primeiro ou abra um caso de suporte. Não tente no sistema de produção.

A distinção é importante porque a Device Console e a Advanced Shell utilizam sintaxes diferentes. Muitos erros ocorrem simplesmente porque um comando correto foi introduzido no local errado. Encontra uma visão geral mais abrangente em Resolução de problemas da Sophos Firewall: serviços e logs.

Permitir acesso SSH à firewall

Para que a ligação seja possível, a Sophos Firewall deve permitir SSH na zona apropriada ou através de uma regra de exceção Local Service ACL.

1. Inicie sessão no WebAdmin da Sophos Firewall.
2. Abra Administration.
3. Selecione Device access.
4. Em Local service ACL, verifique se SSH está permitido para a zona administrativa de confiança prevista. Registe o estado atual antes de efetuar qualquer alteração.
5. Se pretender permitir deliberadamente o acesso a toda essa zona, ative SSH apenas para essa zona e guarde com Apply. Não é necessário voltar a alterar definições que já estejam corretas.

Para uma rede de administração interna de confiança, LAN pode, por exemplo, ser a zona adequada. No entanto, uma permissão ao nível da zona não se aplica apenas a um único computador de administração. Para restringir o acesso a um IP de administração ou a uma rede de gestão, utiliza-se antes a Local service ACL exception rule descrita abaixo; a permissão alargada ao nível da zona não é um passo adicional obrigatório para esse efeito. Não ativar SSH indiscriminadamente para WAN.

O Device Access controla o acesso à própria firewall. Não é o mesmo que uma regra de firewall normal que permite tráfego através da firewall. Se o SSH estiver permitido de forma demasiado abrangente no Device Access, um cliente pode alcançar o serviço SSH local da firewall mesmo que uma regra LAN-to-WAN clássica esteja corretamente configurada.

A CLI Console baseada na Web é uma via de acesso diferente de um cliente SSH: o cliente SSH utiliza TCP 22, enquanto a consola no navegador utiliza o acesso HTTPS ao WebAdmin. Para aceder pelo navegador, abre-se Administration > Device access, verifica-se em Local service ACL a permissão HTTPS para a zona administrativa de confiança prevista e, se necessário, ativa-se essa permissão com Apply. Em seguida, abre-se a lista pendente do administrador no canto superior direito do WebAdmin e seleciona-se Console. Não é necessária uma permissão de acesso SSH para esta via pelo navegador. Também não se permite HTTPS indiscriminadamente na WAN; as restrições de origem existentes mantêm-se.

A escolha da conta está sujeita ao limite documentado para SFOS 22 e 23: as instruções do PuTTY exigem explicitamente admin e excluem outros nomes de utilizador, mesmo no início de sessão com palavra-passe. Embora a descrição do perfil conceda ao perfil Administrator acesso completo à CLI e permita a sua atribuição a outros administradores, não especifica o método de transporte para esse acesso. Uma permissão associada a uma função não garante, portanto, que uma conta nominativa possa iniciar sessão por SSH através da rede. Também não está confirmado aqui um acesso geral à consola pelo navegador para todas as contas nominativas. Antes de utilizar uma via de acesso como alternativa de recurso, verifica-se o acesso concreto com a conta prevista na versão SFOS instalada. Se Console não estiver disponível ou o acesso for recusado, mantêm-se abertas as sessões existentes que funcionam; verificam-se a conta, o perfil e a via de acesso e, se necessário, esclarece-se o caso com o Sophos Support, em vez de alargar as permissões WAN ou ACL. Os passos SSH seguintes continuam a utilizar admin; a gestão exclusiva das SSH Public Keys pelo administrador predefinido é uma permissão separada.

Antes da alteração, registe as zonas em que SSH está atualmente ativo e as exceções SSH já existentes. Assim, poderá repor o estado inicial sem remover outra permissão intencional.

Em Local service ACL exception rule, clique em Add e defina os valores da forma mais restrita possível:

• Name: por exemplo, SSH-da-rede-admin; valor livre e inequívoco
• Rule position: a posição da exceção na Local Service ACL
• Description: finalidade, equipa responsável e data de fim para acesso temporário
• IP version: IPv4 ou IPv6 de acordo com a origem administrativa e o endereço de destino
• Source zone: a zona a partir da qual a administração ocorre
• Source Network / Host: o IP do administrador ou a rede de gestão
• Destination host: o IP da firewall ou a interface a administrar, se o acesso também puder ser limitado a um endereço de destino específico
• Services: SSH
• Action: Accept

Guarde com Save. Para um único sistema de administração, Source Network / Host pode ser um objeto host com 192.0.2.10. Este é um endereço de documentação; substitua-o pelo IP administrativo real, de preferência fixo. Destination host também limita o IP da firewall através do qual o serviço fica acessível. Não inclua todas as interfaces sem uma razão operacional.

Abra uma nova sessão SSH a partir da origem administrativa prevista. O teste é bem-sucedido quando o menu da consola aparece. Em seguida, teste a partir de uma rede deliberadamente não autorizada e confirme que não é estabelecida nenhuma sessão. Se o resultado for inesperado, mantenha a sessão WebAdmin existente aberta e verifique o IP de origem, Source zone, IP version, Destination host, a posição da regra e os filtros a montante.

Se o acesso era temporário, elimine apenas esta exceção em Administration > Device access > Local service ACL exception rule e confirme com OK. Se alterou uma caixa de zona, reponha apenas o estado registado e clique em Apply. Em seguida, teste a partir da mesma origem e confirme que o SSH voltou a estar acessível ou bloqueado exatamente como antes da alteração. Assim, o teste valida o estado inicial sem pressupor que o início de sessão deve sempre ser bem-sucedido ou falhar.

O SSH não deve ficar acessível de forma descontrolada a partir da Internet. Se o acesso externo for necessário, permita-o apenas através de um IP de origem claramente definido, de uma VPN ou de acesso de suporte dedicado.

Diagnostics > Support access é um mecanismo separado. Não expõe simplesmente o SSH à Internet: permite ao Sophos Support acesso temporário através de um canal de suporte estabelecido pela firewall. Este acesso também deve ser limitado no tempo e desativado após o caso de suporte.

Ao ativar Support access, escolhe-se uma duração; depois, a firewall gera um Access ID único para o Sophos Support. Este Access ID mantém-se válido durante o período escolhido; Support access pode ser desativado antecipadamente a qualquer momento. O Sophos Support pode assim aceder ao WebAdmin e à shell sem necessitar das credenciais administrativas habituais. A própria firewall estabelece as ligações de suporte de saída tanto para HTTPS como para SSH através de TCP 22; em termos operacionais, isto é diferente de permitir SSH de entrada a partir da WAN.

Antes de qualquer ativação – incluindo no WebAdmin – verifica-se primeiro o canal de suporte existente em 4. Device Console, com o comando só de leitura:

show support_access

O comando mostra se Support access está ativo e, quando o acesso está ativo, também o Access ID e a duração. O estado inicial, bem como a duração e o Access ID apresentados, são registados exclusivamente no caso de suporte autenticado correspondente. A informação apresentada, por si só, não comprova a que caso pertence o canal; essa associação e o consentimento para o acesso devem ser esclarecidos com a equipa responsável e o Sophos Support.

Se já estiver ativo um canal para outro caso ou se não estiver claro quem é responsável pelo canal, interrompe-se o procedimento e coordena-se a atuação seguinte, sem voltar a ativar, substituir ou desativar o canal. Um canal ativo já autorizado para o mesmo caso também não é novamente ativado; a sua utilização posterior e o seu encerramento são acordados no caso existente. O procedimento autónomo de ativação, análise e desativação só é iniciado quando se confirma que o estado inicial é inativo e existe consentimento explícito para este caso de suporte. Esta condição aplica-se às duas vias de acesso seguintes.

Para proceder no WebAdmin, abre-se Diagnostics > Support access, ativa-se Support access e confirma-se com OK. Depois, seleciona-se a duração necessária para o caso de suporte concreto, clica-se em Apply e confirma-se novamente com OK. A firewall estabelece uma ligação de controlo segura com o seu proxy de acesso; o access ID gerado encontra-se em Access status e é comunicado exclusivamente ao Sophos Support pelo canal de suporte acordado.

Controlar Support access a partir da Device Console

O SFOS 22 também pode ativar o canal de suporte em 4. Device Console. Imediatamente antes do comando de escrita, repete-se aí a verificação descrita acima com show support_access. O canal só é ativado quando se confirma que está inativo e existe consentimento para este caso:

set support_access enable

Após uma ativação bem-sucedida, o comando mostra o Access ID e a duração do acesso. A duração efetivamente apresentada é comparada com o consentimento relativo ao caso; a sintaxe CLI documentada não contém nenhum parâmetro para definir uma duração. Se for necessária uma duração específica, utiliza-se a via WebAdmin descrita acima, após a mesma verificação prévia. O Access ID e a duração são comunicados apenas no caso de suporte autenticado correspondente e não são copiados para documentação geral, chats ou cofres de palavras-passe.

Após a conclusão da análise, independentemente do tempo restante, desativa-se exclusivamente o próprio canal criado com consentimento para este caso. Antes disso, verifica-se com show support_access e o Access ID registado que continua a ser esse canal. Se já estiver inativo, não se executa o comando de escrita; se o ID for diferente ou não estiver claro quem é responsável pelo canal, interrompe-se o procedimento e coordena-se a atuação, em vez de desativar um canal que poderá pertencer a outro caso:

set support_access disable

Em seguida, confirma-se em Diagnostics > Support access ou com show support_access que o próprio canal já não está ativo. disable não altera a configuração SSH normal em Device Access nem as Local Service ACL Exception Rules; por isso, as permissões temporárias de administrador e SSH são revertidas separadamente para o estado anteriormente registado, apenas no âmbito das alterações efetuadas pelo próprio.

Se existir outro router ou filtro de saída à frente da firewall, este deve permitir TCP 22 para *.apu.sophos.com. Para isso, não se cria nenhuma regra WAN de entrada na Sophos Firewall. As sessões de suporte inativas são encerradas após 15 minutos; a duração total selecionada e a possibilidade de desativar manualmente Support access permanecem independentes desse tempo limite.

Verificar serviços e portas de saída da Sophos Firewall organiza os restantes destinos do fabricante para atualizações, licenças, RED, Central, reporting e backups.

Support access via XML API: esclarecer antes de efetuar escritas

A ajuda da XML API para SFOS 22 e 23 identifica o objeto como SupportAccess, mas contém duas contradições: No exemplo XML, a tag de duração chama-se GrantAccessFor, enquanto na tabela de parâmetros se chama GrantAccessForr. Para ConfigOption, a tabela indica o valor predefinido ON, mas permite apenas Enable e Disable. Daqui não se pode deduzir nem que ON seja um valor válido num pedido nem que o acesso de suporte esteja ativo por predefinição. Antes de uma escrita, esclarecer a grafia válida da tag para o build instalado em API help ou com o Sophos Support.

A tabela identifica ambos os campos como valores escalares opcionais e indica os períodos 1 day, 2 days, 1 week, 2 weeks, 1 month e 2 months. Isto não esclarece o que acontece efetivamente quando se omite um campo. Por isso, antes de uma alteração automatizada, consulta-se a ajuda da API específica do objeto na build SFOS instalada e esclarecem-se com o Sophos Support as dúvidas pendentes sobre a tag, os valores ou o comportamento em caso de omissão. Enquanto a contradição não estiver esclarecida, interrompem-se as operações de escrita via XML; não se inventa um payload nem se experimentam ambas as grafias no sistema de produção. Para um caso de suporte aprovado, a via WebAdmin descrita acima continua a ser a alternativa, sem alargar as permissões WAN ou ACL.

A referência indica para esta operação 200 com Operation Successful. e 500 com Operation Fail.. Verifique a resposta concreta do objeto, em vez de repetir às cegas uma operação de escrita falhada ou com resultado incerto. Após uma alteração confirmada, verifica-se o estado real de ativação e a duração em Diagnostics > Support access ou com o comando show support_access descrito acima. Após o caso de suporte, desativa-se exclusivamente o próprio canal autorizado para esse caso, aplicando as verificações de responsabilidade descritas acima, e confirma-se o estado inativo; as permissões temporárias SSH/ACL continuam a ser revertidas separadamente.

Registar uma chave pública para admin

Para o acesso SSH, a autenticação por chave pública é o método preferido. Na Sophos Firewall, a chave pública do utilizador admin pode ser guardada em Administration > Device access. O início de sessão com palavra-passe pode ser necessário em situações de emergência, mas não deve continuar a ser a opção de acesso mais conveniente por predefinição.

⚠️ O início de sessão por SSH na Sophos Firewall só é possível com o utilizador admin. Os outros utilizadores do WebAdmin não podem iniciar sessão por SSH.

Importante: apenas o administrador predefinido pode alterar a autenticação por chave pública para SSH, ou seja, adicionar ou remover chaves SSH. Estas alterações às chaves SSH devem integrar um processo administrativo documentado e não ser tratadas como um atalho de suporte improvisado.

O administrador predefinido não é uma conta de função normal que possa ser simplesmente substituída. A Sophos indica que esta conta não pode ser renomeada nem eliminada. Por isso, a palavra-passe do administrador predefinido, as informações de MFA ou recuperação para inícios de sessão administrativos interativos e as chaves públicas SSH guardadas devem ser geridas em conjunto no processo operacional administrativo. Uma chave pública não substitui a gestão adequada desta conta.

Os administradores nominais do WebAdmin são geridos separadamente e não podem iniciar sessão por SSH com o próprio nome de utilizador. Gerir administradores locais e perfis de Device Access segundo o princípio do menor privilégio explica o ciclo de vida e as permissões destas contas.

Antes de registar a chave pública na firewall, gere no seu próprio cliente de administração um par de chaves pública e privada correspondentes, utilizando uma ferramenta de chaves SSH. Pode reutilizar um par de chaves existente, adequado e cujas chaves correspondam entre si. Para o tipo e o comprimento da chave, siga as indicações da secção seguinte sobre os tipos de chaves SSH suportados. Guarde e proteja a chave privada exclusivamente no cliente de administração; nunca a partilhe nem a carregue para a firewall. Para os passos seguintes, copie apenas a chave pública.

A chave pública é adicionada na área Public key authentication for admin:

1. Abra Administration.
2. Selecione Device access.
3. Desloque-se até à área Public key authentication for admin.
4. Ative Enable authentication.
5. Adicione a chave pública em Authorized keys.
6. Guarde com Apply.

Mantenha a sessão WebAdmin ou SSH existente aberta enquanto testa a nova chave numa segunda sessão SSH. Só remova uma chave antiga ou altere o acesso alternativo por palavra-passe depois de o menu da consola aparecer nessa segunda sessão. Se o teste falhar, o acesso atual continua disponível: verifique o tipo de chave, a entrada da chave pública, a chave privada correspondente e a origem permitida e remova apenas a nova entrada incorreta.

A chave privada permanece sempre no cliente de administração e não deve ser partilhada. Apenas a chave pública é guardada na firewall.

Se vários administradores utilizarem SSH, não devem partilhar a mesma chave privada. É preferível utilizar clientes de administração separados, documentar as chaves públicas e rever quais continuam a ser necessárias. Após mudanças de pessoal ou de prestador de serviços, verifique a área Authorized keys.

Tipos de chave SSH suportados

Nem todos os tipos modernos de chaves SSH são igualmente adequados para a Sophos Firewall. Antes da implementação, verifique se o tipo de chave é suportado.

• RSA: Utilize pelo menos 2.048 bits.
• DSA: Pelo menos 2.048 bits, se necessário por motivos de compatibilidade.
• ECDSA: Suportado; ED25519 não é aceite para esta finalidade.
• ED25519: Não utilize este tipo para SSH Public Key Authentication na Sophos Firewall.

Para novos acessos administrativos, uma chave RSA devidamente gerida ou uma chave ECDSA suportada costuma ser uma opção mais prática do que um tipo moderno que a firewall ou uma ferramenta SSH mais antiga não aceita.

Ligar a partir de macOS ou Linux

O macOS e o Linux costumam incluir um cliente SSH. Estabeleça a ligação no terminal.

Exemplo:

ssh admin@192.0.2.1

192.0.2.1 é substituído pelo endereço IP ou nome DNS do seu próprio Sophos Firewall.

Na primeira ligação, o cliente SSH pergunta se deve aceitar a impressão digital do sistema de destino. Verifique-a antes de a confirmar. Se surgir um aviso de chave de host alterada após a reinstalação da imagem do sistema, a substituição de hardware ou uma alteração de IP, não aceite a nova impressão digital sem verificação. Confirme primeiro se a firewall em causa foi realmente substituída, reinstalada ou passou a utilizar outro IP. Só depois deve remover a entrada antiga em ~/.ssh/known_hosts e aceitar a nova impressão digital.

Consoante a configuração, é depois solicitada a palavra-passe do utilizador admin ou o início de sessão é efetuado através da chave SSH guardada.

Para utilizar uma chave privada específica:

ssh -i ~/.ssh/sophos-admin-key admin@192.0.2.1

Para acessos recorrentes, documentam-se o caminho da chave privada, o IP de origem permitido e a finalidade. A entrada known_hosts não deve ser copiada para pedidos de suporte ou históricos de conversas. Perante avisos de chave de host, o histórico de alterações é mais importante do que uma solução de contorno rápida.

Ligar com PuTTY

No Windows, pode utilizar o Windows Terminal com OpenSSH ou o PuTTY.

No Windows Terminal, a ligação é estabelecida de forma semelhante à do macOS ou Linux:

ssh admin@192.0.2.1

Para o PuTTY: se o programa ainda não estiver disponível, descarrega-se primeiro da página oficial de transferências do PuTTY e configura-se no computador de administração. Em seguida, estabelece-se a ligação:

1. Abra o PuTTY.
2. Introduza o endereço IP ou nome DNS da Sophos Firewall em Host Name.
3. Defina Port como 22.
4. Defina Connection type como SSH.
5. Estabeleça a ligação com Open.
6. Verifique e confirme a impressão digital SSH.
7. Inicie sessão como utilizador admin e utilize a palavra-passe ou a chave SSH, consoante a configuração.

Após iniciar sessão, aparece o menu da consola da Sophos Firewall.

Se o PuTTY for utilizado com uma chave privada, esta tem de corresponder à chave pública guardada na firewall. Após uma mudança de pessoal ou de prestador de serviços, não basta alterar a palavra-passe; as chaves públicas antigas também devem ser removidas de Authorized keys.

Abrir Device Console ou Advanced Shell

Após iniciar sessão com êxito, aparece o Main Menu. A representação seguinte serve de orientação para selecionar as opções do menu:

Main Menu

  1. Network Configuration
  2. System Configuration
  3. Route Configuration
  4. Device Console
  5. Device Management
  6. VPN Management
  7. Shutdown/Reboot Device
  0. Exit

Select Menu Number [0-7]:

Na linha de pedido Select Menu Number [0-7]:, introduz-se o número da opção pretendida, por exemplo, 1 para Network Configuration. Para comandos de diagnóstico, as duas vias seguintes são especialmente importantes. 7. Shutdown/Reboot Device dá acesso a ações que podem interromper o funcionamento; esta opção de menu não se destina a experiências.

Para muitos comandos SFOS, selecione a Device Console:

4. Device Console

Para tarefas mais aprofundadas no Linux ou no sistema de ficheiros, aceda à Advanced Shell através de:

5. Device Management
3. Advanced Shell

A Advanced Shell oferece acesso muito amplo ao sistema. Execute comandos nesta shell apenas quando estiver claro o que fazem.

Segundo a Sophos, alterações de configuração efetuadas diretamente na Advanced Shell, por exemplo em interfaces, regras ou políticas, não persistem após um reinício e não são incluídas nas cópias de segurança. Por isso, esta não é uma via normal de configuração. Os ficheiros em /tmp/ também são eliminados no reinício.

• Device Console: ping, dnslookup, traceroute, show, encaminhamento ou opções de sistema.
• Advanced Shell: informações detalhadas do sistema, bases de dados, serviços do sistema e diagnóstico específico orientado pelo Sophos Support.

Para analisar logs, identificar serviços e interpretar padrões de erro típicos, Resolução de problemas da Sophos Firewall: serviços e logs é um ponto de partida melhor do que memorizar comandos individuais.

Compreender as famílias de comandos set e system

Em 4. Device Console, set define as configurações e os parâmetros de vários componentes do sistema, enquanto system configura parâmetros do sistema. Ambas as famílias podem alterar a configuração. Para as conhecer, utiliza-se apenas a ajuda, não um comando de alteração completo. A documentação de SFOS 22 e 23 utiliza estes esquemas gerais de sintaxe; não são comandos para copiar:

set [command] [option 1|option 2] <value>
system [command] [option 1|option 2] <value>

• set ou system é o prefixo literal, introduzido exatamente como indicado.
• Substitui-se [command] pelo comando documentado pretendido, por exemplo, advanced-firewall para set ou firewall-acceleration para system.
• [option 1|option 2] significa escolher uma das alternativas documentadas. Não se introduzem os parênteses retos nem |; aqui não significam que se possa simplesmente omitir a escolha.
• <value> é um marcador de posição para um valor adequado à opção selecionada. Substitui-se esse marcador, incluindo os sinais angulares, pelo valor necessário. Os argumentos efetivamente exigidos são determinados pela ajuda do comando específico, não apenas por este esquema geral.

Apenas para explicar a sintaxe, não executar: no exemplo do fabricante set advanced-firewall icmp-error-message allow, set é o prefixo, advanced-firewall o comando escolhido, icmp-error-message a opção e allow o valor concreto que substitui <value>. Trata-se de uma alteração de configuração, não de um passo necessário para SSH. O exemplo system firewall-acceleration enable também não é um exercício: system é o prefixo, firewall-acceleration o comando escolhido e enable a opção selecionada. Este exemplo específico não contém um valor adicional; não se acrescenta <value> sem verificação nem se ativa a aceleração para experimentar.

Para explorar em segurança, introduz-se apenas set na Device Console e prime-se Tab três vezes para listar as configurações disponíveis. Tab seguido de ? apresenta as respetivas descrições. Repete-se com o prefixo system para explorar a outra família. O resultado esperado é a apresentação da ajuda, não uma configuração alterada. Depois, limpa-se a linha de introdução sem enviar um comando de alteração com Enter. Se a ajuda esperada não aparecer, verifica-se primeiro a consola e a documentação da versão SFOS instalada, em vez de experimentar um comando de exemplo.

Terminar a ligação

⚠️ Os comandos antigos da Device Console enableremote e disableremote não constituem uma forma normal de terminar sessão: para SFOS 22 e 23, a Sophos indica que disableremote não só impede novas ligações SSH na porta 22, como também termina as sessões SSH existentes. Por isso, não execute estes comandos para terminar sessão nem para retirar uma permissão ACL temporária. Antes de qualquer utilização expressamente aprovada destes comandos, deve ter sido testada uma via de acesso de recuperação funcional e independente do SSH de rede: uma consola série local ou fora de banda para appliances físicas, ou a consola da plataforma adequada para firewalls virtuais ou na cloud. Sem este acesso e um plano de recuperação confirmado para a versão instalada, interrompa o procedimento e esclareça o caso com o Sophos Support. A descrição de enableremote menciona uma porta Ethernet; não se deduz daí nem uma sintaxe de porta TCP nem um comando inverso genérico. Para as permissões de acesso temporárias, continua a ser obrigatório o procedimento de remoção específico descrito acima em Administration > Device access; o canal de saída estabelecido em Diagnostics > Support access é distinto.

Na Advanced Shell, utiliza-se o comando seguinte para sair da shell. Este comando não substitui a seleção de um número no menu da consola:

exit

Se estiver num submenu, regressa-se primeiro ao Main Menu. Aí, 0. Exit termina a sessão da consola: introduzir 0 na linha de pedido do menu. O comando da shell e o número do menu são, portanto, utilizados em locais diferentes.

A Sophos Firewall encerra as sessões SSH inativas após 15 minutos. Isto não substitui o encerramento deliberado da sessão: feche as sessões abertas, desative a depuração e remova as regras de acesso temporárias quando deixarem de ser necessárias.

Se o acesso SSH tiver sido permitido apenas para um caso de suporte, retira-se depois exatamente essa permissão temporária de acesso. Uma Local service ACL exception rule criada para esse efeito é eliminada conforme descrito acima; uma caixa de seleção de zona que tenha sido alterada é reposta no estado anteriormente registado, guardando com Apply. As outras permissões que continuem a ser necessárias mantêm-se. Isto é especialmente importante no caso de endereços IP de origem externos ou de acessos de prestadores de serviços.

Após intervenções profundas, também deve ser verificado o seguinte:

• A depuração está desativada novamente?
• Uma regra de exceção temporária de ACL foi removida ou desativada?
• Ficaram ficheiros temporários, dumps de suporte ou gravações desnecessários na firewall?
• Os excertos de logs, a hora, o comando e o resultado estão documentados no pedido de suporte ou no registo de alteração?
• A chave SSH foi usada apenas para acesso agendado de administração ou suporte?

Problemas comuns

Ligação recusada

Se a ligação for recusada, é frequente o SSH não estar permitido para a zona ou origem selecionada. Por isso, em Administration > Device access, verificam-se a definição de SSH e as entradas Local service ACL exception rule existentes. Deve também confirmar-se se uma permissão mais alargada ao nível da zona foi retirada deliberadamente. Uma restrição deste tipo não deve ser anulada sem verificação prévia.

A ligação excede o tempo limite

Um tempo limite costuma indicar que a firewall não está acessível através do IP selecionado, que falta uma rota ou que uma firewall a montante está a bloquear o acesso.

Se uma firewall ainda não totalmente configurada continuar a usar a palavra-passe predefinida de fábrica, o SFOS descarta intencionalmente as ligações SSH provenientes da zona WAN sem apresentar uma mensagem de erro. Trata-se de uma medida de proteção. A palavra-passe deve primeiro ser alterada por uma via de administração local autorizada; o Device Access ou a ACL não devem ser alargados como alternativa.

Sem acesso de rede à firewall

Se nem o WebAdmin nem o SSH estiverem acessíveis, não se devem permitir precipitadamente acessos adicionais pela WAN ou por outras zonas. Para um appliance físico, a consola série local é a via de contingência, por exemplo, quando o Device Access, o encaminhamento ou a atribuição de zonas às interfaces estão incorretos. Utiliza-se o cabo de consola RJ45 adequado ou, nos modelos compatíveis, Micro-USB, e configura-se o programa de terminal para 38400 baud.

Se Micro-USB e RJ45 estiverem ligados em simultâneo, Micro-USB tem prioridade e a firewall redireciona a saída da consola para essa ligação. Se o terminal não apresentar conteúdo, verificam-se primeiro a porta série correta, o cabo e esta prioridade. O valor de 38400 baud está desativado no BIOS para impedir alterações acidentais; por isso, não se deve tentar ajustá-lo aí.

Os passos concretos para estabelecer a ligação encontram-se em Estabelecer uma ligação série. Se a palavra-passe de admin for conhecida, utiliza-se essa palavra-passe para iniciar sessão após estabelecer a ligação e não é necessário repor a palavra-passe. Utilizam-se apenas os passos de ligação do artigo referido, não o respetivo procedimento de reposição. O aparecimento do menu da consola confirma o êxito da ligação; para firewalls virtuais ou na cloud, é necessário utilizar o acesso à consola adequado ao respetivo tipo de plataforma.

Falha no início de sessão

Se o início de sessão falhar, verifique o utilizador admin, a palavra-passe ou a chave SSH e as redes de origem permitidas. Mensagens como Permission denied (publickey,password) indicam uma palavra-passe incorreta, uma chave privada incorreta ou a ausência de configuração da chave pública.

Se o início de sessão por chave pública falhar, verifique também o tipo e o comprimento da chave, se está a utilizar a chave privada correta, o formato da chave do PuTTY e a entrada em Authorized keys. Permitir corretamente o serviço SSH não resolve o problema se a chave não corresponder à chave pública guardada.

Se a palavra-passe do admin predefinido tiver sido realmente perdida, Repor a palavra-passe de admin do Sophos Firewall descreve a recuperação pela consola série sem um Factory Reset completo. Este caminho aplica-se a appliances físicos com ligação de consola; para firewalls virtuais e cloud, é necessário verificar a consola da plataforma e o caminho de recuperação suportado.

Surge um aviso de chave de host

Um aviso de chave de host pode ser inofensivo se a firewall tiver sido reinstalada ou substituída. Também pode indicar um sistema de destino incorreto ou uma confusão de endereços IP. Verifique primeiro a firewall, o endereço IP, o DNS e o histórico de alterações. Só depois deve remover a entrada antiga em known_hosts.

Está aberta a consola errada

Se um comando Sophos CLI documentado não for reconhecido, pode estar aberta a consola errada ou a sintaxe pode estar incompleta. Na Device Console, Tab apresenta os comandos e argumentos disponíveis; ? mostra as descrições. Não introduza aí instruções da shell Linux nem experimente comandos não documentados na Advanced Shell.

Lista de verificação operacional

• Permitir SSH apenas a partir de origens administrativas de confiança.
• Alterar a palavra-passe predefinida de fábrica antes de utilizar SSH em produção.
• Sempre que possível, utilizar uma Local service ACL exception rule em vez de uma permissão alargada ao nível da zona.
• Preferir a autenticação por chave pública para a conta admin ao início de sessão com palavra-passe.
• Documentar separadamente a palavra-passe do administrador predefinido, as informações de MFA e recuperação e as chaves SSH.
• Utilizar um tipo de chave suportado e documentar o comprimento da chave.
• Não partilhar chaves privadas.
• Verificar a impressão digital SSH no primeiro início de sessão.
• Tratar de forma consciente os avisos de chave de host após a reinstalação da imagem ou a substituição do hardware.
• Não confundir Device Console e Advanced Shell.
• Efetuar alterações na Advanced Shell apenas com uma finalidade clara.
• Retirar as permissões temporárias de acesso SSH após os casos de suporte.
• Eliminar as chaves públicas antigas após mudanças de pessoal ou de prestador de serviços.

Perguntas frequentes