Sophos Firewall: Device Access e Local Service ACL

Em Administration > Device access, define-se a partir de que zonas os serviços locais da Sophos Firewall ficam acessíveis. Estes incluem HTTPS para WebAdmin e API, SSH, Ping, DNS, SNMP, SSL VPN, User Portal e VPN Portal.

Estes serviços terminam diretamente na firewall e constituem a sua superfície de gestão e de serviços. Se uma permissão for demasiado ampla, bots, clientes internos comprometidos ou atacantes externos podem aceder diretamente às páginas de início de sessão, à API e ao SSH para testar credenciais, vulnerabilidades conhecidas ou configurações incorretas. MFA e palavras-passe seguras continuam a ser importantes, mas não limitam o acesso pela rede: o Device Access reduz a superfície de ataque antes do início de sessão e, por isso, é uma das primeiras medidas de hardening.

A fonte de identidade continua separada. Se o WebAdmin deve utilizar credenciais TACACS+ centrais, TACACS+ para administradores da Sophos Firewall explica a ligação do servidor, a atribuição local de perfis, o início de sessão-piloto e o fallback; a acessibilidade HTTPS continua a ser limitada aqui.

O destino da ligação é determinante:

• Tabela de zonas do Device Access: permite, por princípio, um serviço local da firewall a partir de uma zona.
• Local service ACL exception rule: permite ou bloqueia um serviço local para origens, destinos e serviços específicos.
• Regra de firewall: controla o tráfego através da firewall, por exemplo, de LAN para um servidor em DMZ.

Ao abrir, por exemplo, https://172.16.16.16:4444, a ligação termina na firewall. Por isso, uma regra de firewall normal não substitui uma permissão no Device Access.

⚠️ O WebAdmin, o SSH e os portais só devem estar acessíveis a partir das redes que realmente necessitam deles. Para administração externa, uma VPN de administração, o Sophos Central Firewall Management no Sophos Fusion (início de sessão em fusion.sophos.com), uma rede de gestão ou uma exceção ACL restrita são mais seguros do que uma permissão WAN abrangente.

Duas situações especiais podem contornar a tabela de zonas para serviços HTTP e HTTPS:

• Web Proxy: os pedidos através do Web Proxy são considerados internos e não podem ser controlados por zona de origem no Device Access. Quem estiver autorizado a utilizar o proxy pode, assim, aceder ao WebAdmin, Captive Portal, VPN Portal e User Portal, mesmo que o serviço esteja desativado para a respetiva zona.
• Port Sharing: se o VPN Portal e a SSL VPN utilizarem a mesma porta e o mesmo protocolo, o VPN Portal fica acessível a partir de todas as zonas de acesso SSL VPN. Além disso, as definições em Login security deixam de se aplicar.

Estes dois caminhos devem ser testados separadamente durante a validação. O artigo geral Hardening da Sophos Firewall enquadra o Device Access na proteção global do sistema.

Planear zonas e serviços locais

A tabela de zonas é adequada para permissões básicas claras, como DNS a partir de LAN, Ping a partir de uma zona de monitorização ou HTTPS a partir de uma rede de gestão. Se apenas um endereço IP ou uma pequena rede necessitar de acesso, uma ACL Exception Rule é mais precisa.

Uma zona agrupa interfaces. Numa zona personalizada, o acesso aos serviços locais também pode ser permitido ou bloqueado em Network > Zones. Antes de uma alteração, é necessário identificar a interface de entrada efetiva e a respetiva zona. Devem também ser preparados o objeto de origem restrito, o Interface Host necessário como destino e a porta realmente utilizada pelo serviço. Os IP Hosts existentes encontram-se em Hosts and services > IP host; os Interface Hosts são geridos através de Network > Interfaces.

Interpretar a matriz predefinida como ponto de partida

Uma nova configuração do SFOS 22 permite, por predefinição, os serviços locais a partir das zonas seguintes. Esta matriz não é um objetivo de hardening: restore, migração, assistente e alterações posteriores podem resultar noutro estado, e os serviços desnecessários são removidos após um teste positivo e negativo.

Decisões típicas:

• HTTPS: WebAdmin e API apenas a partir de redes de gestão ou origens administrativas bem definidas.
• SSH: Apenas para administração ou suporte e, de preferência, com chave pública. Para SSH pela rede, a via de início de sessão documentada no SFOS 22/23 utiliza a conta integrada admin; uma permissão de perfil para acesso à CLI não confirma uma via de início de sessão SSH para uma conta de administrador nominativa. Apenas o administrador predefinido gere as definições e as chaves públicas.
• DNS: apenas para zonas de clientes internos que utilizem a firewall como resolvedor DNS. DNS a partir de WAN não é um cenário normal de cliente.
• Ping/Ping6: para a monitorização necessária, não indiscriminadamente a partir de zonas não seguras.
• SNMP: apenas a partir do sistema ou da rede de monitorização; a configuração é descrita em Monitorização de hardware por SNMP.
• RADIUS SSO: Apenas a partir do remetente fixo de accounting. RADIUS SSO com accounting explica a associação entre o IP do cliente e o utilizador.
• SSL VPN: externamente tão aberta quanto necessário e com MFA, logging e porta e protocolo escolhidos de forma consciente.
• VPN Portal: desde o SFOS 20, disponibiliza o Sophos Connect e configurações IPsec e SSL VPN.
• User Portal: destina-se, entre outros, a dados pessoais, tokens OTP, quarentena, exceções e Policy Overrides, não ao download da configuração VPN.
• RED, SMTP Relay e Dynamic Routing: apenas nas redes previstas para esse fim ou para pares definidos. A verificação deste limite para Neighbors Multicast é explicada em Configurar PIM-SM na Sophos Firewall; para pequenos domínios de routing IPv4, configurar RIPv2 na Sophos Firewall explica a autorização separada da zona do peer e do tráfego de dados.

A janela de serviços disponibiliza ainda AD SSO, Captive portal, Chromebook SSO, Clients, IPsec, Web proxy e Wireless Protection. O facto de um serviço poder ser selecionado não recomenda uma permissão alargada da zona; cada seleção requer um percurso concreto de cliente, peer ou administração. Os campos de pesquisa Source Network / Host, Destination host e Services também pesquisam atributos. Por exemplo, introduzir 53 encontra o serviço DNS.

O WebAdmin, o VPN Portal e o User Portal suportam TLS 1.3 desde o SFOS 22. No entanto, uma boa encriptação não reduz a superfície de ataque de um serviço desnecessariamente acessível.

O Device Access apenas determina a partir de que rede a WebAdmin Console está acessível. Se o login for efetuado através do Microsoft Entra ID, Entra ID SSO para o WebAdmin do Sophos Firewall explica o mapeamento separado de funções e grupos Entra para perfis de administrador locais.

Além disso, restrict-admin-console-wan-access pode bloquear globalmente o acesso WebAdmin a partir de todas as origens WAN. Verificar Advanced Firewall Settings em segurança explica a lógica enable/disable deliberadamente invertida e a separação da Local Service ACL.

Restringir as origens

Uma ACL Exception Rule suporta como origem Country, Country group, FQDN host/group, Host group, IP address/list/range, MAC address/list e Network. Não são suportados FQDNs wildcard.

O WebAdmin a partir de WAN não deve ser permitido para todas as origens. O SFOS não permite criar a exceção ACL quando Source Network / Host está definido como Any ou o endereço IP de origem é 0.0.0.0. Esta restrição do produto não torna automaticamente seguras outras redes de grandes dimensões. Um IP de administração fixo, uma pequena rede de gestão ou um objeto FQDN mantido são significativamente mais seguros. Para utilizadores móveis com endereços de origem variáveis, o acesso administrativo deve ser efetuado através de VPN ou Sophos Fusion.

Desde o SFOS 19.5 MR2, as permissões WAN abrangentes para WebAdmin e User Portal são automaticamente desativadas após 90 dias consecutivos sem um início de sessão bem-sucedido. As origens WAN específicas em ACL Exception Rules não são afetadas e devem continuar a ser verificadas regularmente. O Sophos Firewall Health Check ajuda na revisão periódica dos acessos de gestão, MFA e configuração.

Verificar antecipadamente o Web Proxy e o Port Sharing

Antes do hardening, anote as portas e os protocolos utilizados em Administration > Admin and user settings e nas SSL VPN global settings.

• O WebAdmin utiliza por predefinição TCP 4444, o User Portal TCP 4443 e o VPN Portal TCP 443.
• No SFOS 22/23, TCP 443 é o valor predefinido documentado para WAF; antes de verificar possíveis conflitos, anote os listeners WAF efetivamente configurados.
• A SSL VPN utiliza TCP 8443 por predefinição; também é possível selecionar UDP como protocolo.
• O WebAdmin e o User Portal não podem partilhar a respetiva porta com outros serviços.
• O VPN Portal e a SSL VPN não devem utilizar a mesma porta e o mesmo protocolo, pois, caso contrário, os bloqueios por zona e a Login Security não funcionam como esperado.

Se o Web Proxy estiver ativo, um teste sem proxy não é suficiente. O mesmo acesso ao portal ou ao WebAdmin também deve ser testado através do proxy explícito a partir de uma zona que, em princípio, está bloqueada.

Configurar o Direct Web Proxy com um ficheiro PAC explica como limitar o listener do proxy a um cliente-piloto e validar esta exposição de forma controlada.

Criar uma Local Service ACL Exception Rule restrita

Antes do acesso direto ao WebAdmin a partir de WAN: Na Device Console, utilizar primeiro o comando apenas de leitura show advanced-firewall para registar o valor real de restrict-admin-console-wan-access e o build instalado. Para SFOS 22/23, a Sophos descreve enable como um bloqueio do WebAdmin a partir de todas as origens WAN e como o valor predefinido; este valor não substitui o valor anterior registado. As instruções ACL descrevem exceções WAN restritas, mas não esclarecem a sua precedência em relação a esta restrição global. Por isso, não pressupor que a exceção ACL abaixo, por si só, torna o WebAdmin acessível a partir de WAN. Com enable, manter a restrição e utilizar a via de acesso autorizada e já testada através de VPN de administração, rede de gestão ou Fusion. Se o acesso WAN direto for inevitável e a interação para o build instalado não estiver claramente estabelecida, interromper a alteração de acesso WAN direto e esclarecer o ponto com o Sophos Support. Se um teste positivo falhar, verificar primeiro este requisito em vez de alargar a ACL.

Este exemplo ACL não é uma instrução para definir o parâmetro global como disable. Alterar a restrição global exige uma alteração autorizada separadamente, com uma via administrativa independente funcional, o valor anterior real documentado, testes próprios a partir de origens WAN permitidas e bloqueadas e a reposição exata desse valor anterior em caso de interrupção e após o fim do acesso temporário. Não efetuar a alteração se não for possível determinar de forma fiável o valor inicial ou a via de recuperação. Aplicar o exemplo WAN restrito abaixo apenas depois de esclarecer estes requisitos.

Uma exceção típica permite o WebAdmin a partir de WAN apenas para um IP de suporte fixo. O caminho do menu é Administration > Device access > Local service ACL exception rule > Add.

1. Rule name: admin-https-from-support-ip
2. Rule position: selecionar Top para uma exceção WAN específica e verificar as restantes regras quanto a sobreposições.
3. Description: documentar a finalidade, o ticket e a data de expiração prevista.
4. IP version: selecionar de acordo com a origem, normalmente IPv4.
5. Source zone: WAN
6. Source Network / Host: selecionar um IP de administração específico ou um objeto restrito e devidamente mantido.
7. Destination host: limitar ao endereço ou à interface necessária da firewall. Any alarga os endereços ou interfaces de destino acessíveis, não os serviços selecionados em Services.
8. Services: selecionar apenas HTTPS, sem acrescentar SSH por conveniência.
9. Action: Accept

Os valores do exemplo não devem ser copiados sem adaptação. Para uma rede de gestão interna, o mesmo padrão pode utilizar Source zone: LAN ou uma zona de gestão personalizada, Source Network / Host: mgmt-net, o Interface Host do IP de gestão como Destination host, HTTPS e Accept. Para excluir uma origem conhecida numa zona que, de resto, necessita de acesso, utiliza-se uma regra separada, posicionada corretamente, com o objeto de origem restrito, apenas os serviços afetados e Drop. Um grupo de países é, no máximo, um limite de rede aproximado, não um substituto de uma origem de administração fixa ou de uma VPN.

Em seguida, guarda-se a configuração e testa-se a partir de uma origem permitida e de outra não permitida. A posição da regra é importante: regras superiores podem influenciar o resultado. Quando existem regras sobrepostas, o efeito real deve, por isso, ser verificado na firewall e não apenas deduzido da lista.

Acesso à API

Para a API, três condições têm de estar alinhadas:

1. A API está ativada em Administration > API access.
2. O endereço de origem encontra-se em Allowed IP hosts.
3. O Device Access permite HTTPS a partir da zona em causa ou através de uma exceção ACL adequada.

Desde o SFOS 22, a configuração da API encontra-se em Administration e suporta objetos IP Host para endereços, intervalos e redes. São possíveis até 64 objetos. Não é necessária uma permissão HTTPS abrangente. A configuração completa encontra-se em Restringir em segurança o acesso à API da Sophos Firewall.

Automação XML: definição de zona, não exceção ACL

A documentação XML de zonas para SFOS 22/23 coloca HTTPS e SSH em Zone/ApplianceAccess/AdminServices/HTTPS e Zone/ApplianceAccess/AdminServices/SSH, respetivamente. Trata-se do acesso a serviços locais ao nível da zona: não é uma regra de firewall para tráfego de passagem nem uma Local service ACL exception rule limitada a uma origem específica. Alterar este ramo afeta a acessibilidade da gestão a partir da zona; não limita o acesso a um único IP de administração. Para uma permissão de origem restrita, a exceção ACL descrita acima continua a ser o limite adequado.

A documentação contradiz-se quanto aos valores: o exemplo XML apresenta Enable/Disable, enquanto a tabela conjunta de parâmetros repete Enable e inclui também 12 e 40. Não é possível deduzir daqui uma codificação booleana ou numérica fiável. Antes de qualquer escrita automatizada, esclarecer a sintaxe para o firmware instalado; esta explicação da hierarquia não é um modelo executável para conceder acesso.

Também Zone/MemberPorts não é uma instrução de escrita: o comentário no exemplo XML assinala explicitamente que as portas pertencentes à zona são apenas de leitura. A linha CSV opcional da tabela descreve a sua apresentação, não uma forma verificada de as alterar. Antes de qualquer alteração automatizada de zona, testar uma via de recuperação independente com uma sessão iniciada e, depois, verificar as origens permitidas e bloqueadas como descrito na implementação abaixo.

Remover uma zona personalizada em segurança

Eliminar uma Local service ACL exception rule remove apenas essa exceção, não a zona identificada pelo nome. Desativar um serviço local também não elimina uma zona. Zonas e interfaces explica as associações.

1. Em Network > Zones, identificar o nome exato da zona personalizada que já não é necessária em produção e documentar o seu estado anterior. Retired_Test é apenas um exemplo, não um alvo de eliminação a copiar. Primeiro, iniciar sessão e testar a via administrativa independente descrita na implementação abaixo; não pode depender desta zona nem das interfaces ou regras a alterar.
2. Em Network > Interfaces, inspecionar todas as associações a esta zona e, em Rules and policies > Firewall rules, todas as referências como Source zone ou Destination zone. Não eliminar interfaces nem regras necessárias: reatribuí-las à zona restante prevista apenas no âmbito de uma alteração autorizada e verificar o efeito. Se as referências tiverem de permanecer ou a sua utilização não for clara, manter a zona e as dependências e interromper a eliminação. Não eliminar em cascata dependências de produção para forçar a remoção.
3. Só depois de esclarecer as dependências, remover exclusivamente esta zona identificada pelo nome. A documentação XML de SFOS 22/23 exige Name com um máximo de 60 caracteres: primeiro A-Za-z1-9 (não 0), depois A-Za-z0-9_. Isto não comprova suporte para wildcards nem eliminação automática em cascata; não se prescreve aqui um pedido XML ou um diálogo de eliminação não fundamentado.
4. Depois, verificar que falta apenas a zona prevista, que as associações de interfaces e regras de firewall restantes estão corretas e que o tráfego de passagem necessário continua a funcionar. Voltar a testar os serviços locais a partir de origens permitidas e bloqueadas e a via administrativa independente. Se houver diferenças, interromper e utilizar essa via para reverter seletivamente as alterações documentadas, não alargar permissões.

Os estados XML documentados são 200 (ZoneDeleteSuccess), 500 (ZoneDeleteFailed), 503 (ZoneInterfaceExists) e 504 (ZoneFirewallRuleExists). Perante 503 ou 504, voltar a verificar as referências às interfaces ou regras correspondentes em vez de eliminar indiscriminadamente objetos dependentes. 500 não indica sucesso; nem mesmo 200 substitui a verificação posterior.

DNS a partir de WAN

Uma exceção ACL de DNS a partir de WAN, por si só, não faz com que a firewall responda a pedidos DNS nessa zona. Para isso, seria também necessário configurar um DNS Host estático com Publish on WAN em Network > DNS. Isto só deve ser feito para um caso de utilização autoritativo específico; a firewall não pode tornar-se, por esse motivo, um resolvedor recursivo público. Configurar e testar DNS Host Entries na Sophos Firewall explica a delegação, a DNS Host Entry e os testes positivos e negativos.

Detalhes operacionais antes da alteração

Após uma atualização ou reposição a partir de uma versão anterior ao SFOS 20, o VPN Portal herda a porta anterior do User Portal, incluindo uma porta personalizada. O User Portal passa para 4443, ou para 65040 se essa porta estiver ocupada. Verifique a porta configurada, não apenas a predefinida, antes de investigar uma permissão ACL aparentemente em falta. Os utilizadores ou grupos do VPN Portal também têm de pertencer a uma política Remote Access adequada; a acessibilidade, por si só, não concede autorização ao utilizador.

O listener WAF tem de diferir do VPN Portal no IP WAN ou na porta. Em relação à SSL VPN, um protocolo diferente também é suficiente: WAF e VPN Portal utilizam TCP, enquanto a SSL VPN pode utilizar TCP ou UDP. Separar listeners não é o mesmo que conceder uma permissão ACL; volte a testar os serviços afetados após cada alteração de porta.

Dynamic Routing permite atualizações de routing para a firewall, não o tráfego de dados que a atravessa. Ative-o para a zona real do peer, não automaticamente para WAN. No exemplo WAN com duas firewalls RIP, só o lado com acesso ativado recebe atualizações; o outro rejeita-as e não aprende as redes anunciadas. Se faltarem rotas num só lado, verifique a zona do peer em ambos os lados e depois a configuração do protocolo no artigo de routing ligado.

O widget Messages do Control center pode alertar para acesso WAN a HTTPS e SSH. Verifique as permissões de zona e as exceções ACL e limite o acesso a uma VPN ou a hosts e redes específicos. As mensagens não podem ser eliminadas manualmente; algumas desaparecem depois de cumprido o requisito. O desaparecimento não substitui testes positivos e negativos. As mensagens sobre chave mestra, registo, licenças, relatórios e firmware pertencem aos respetivos procedimentos operacionais, não a uma regra ACL adicional.

Implementar alterações sem bloqueio de acesso

As alterações ao Device Access têm efeito imediato.

A via de recuperação tem de continuar a funcionar após a alteração prevista de zona ou porta. Um segundo separador do browser que use a mesma via bloqueada não é independente. Antes de começar, registe as definições anteriores exatas e identifique quem tem acesso à consola; sem uma via de recuperação funcional, não efetue a alteração remotamente. Durante trabalhos remotos, a segunda via de administração deve estar efetivamente autenticada e testada antes da alteração.

1. Documentar as permissões de zona, exceções ACL, portas e serviços necessários atuais.
2. Abrir uma via de acesso independente, como a consola local, a LAN de gestão, uma VPN de administração ou o Sophos Fusion.
3. Para alterações mais abrangentes, manter disponíveis um backup atual e a Secure Storage Master Key.
4. Criar a nova exceção Accept restrita sem remover ainda a permissão abrangente existente.
5. Testar o acesso permitido como referência. Enquanto a permissão de zona abrangente estiver ativa, este teste ainda não prova que a nova exceção está a ser aplicada.
6. Em Diagnostics > Packet capture, definir um filtro restrito para origem, destino e porta e ativar Trace On.
7. Remover a antiga permissão de zona abrangente através da via de administração independente.
8. Imediatamente depois, testar funcionalmente o serviço a partir da origem permitida. Um acesso TCP/TLS ou ao serviço bem-sucedido e, normalmente, Status: Consumed confirmam o caso positivo; Reason: LOCAL_ACL não tem de aparecer.
9. Testar o mesmo serviço a partir de uma origem não permitida. Para a tentativa bloqueada, são normalmente esperados Status: Violation e Reason: LOCAL_ACL.
10. Para HTTP/HTTPS, testar também o caminho do Web Proxy e, para os portais, as zonas de acesso SSL VPN.
11. Parar o Packet Capture e verificar eventos adicionais do serviço ou de início de sessão no Log viewer. A Rule-ID apresentada no Packet Capture é a ID da regra de firewall, não a ID da ACL Exception Rule, e pode ser 0 para tráfego local.
12. Documentar a regra, a finalidade, o responsável, o ticket, a origem, o serviço e a data de revisão ou expiração.

Interrupção e reposição: se o acesso permitido falhar, utilize a via independente para repor a última definição alterada no valor anterior documentado e volte a testar o acesso. Se uma origem bloqueada ainda alcançar o serviço, não alargue a permissão: investigue o proxy, o Port Sharing e as regras ACL sobrepostas e limite o caminho indesejado sem perder o acesso de recuperação. Repita ambos os testes apenas após a correção.

Exemplos de documentação concisa facilitam a revisão posterior:

• HTTPS: regra admin-https-from-mgmt, origem mgmt-net, finalidade WebAdmin, revisão trimestral.
• SSH: origem support-ip-temporary, finalidade caso de suporte, eliminar após o encerramento do ticket.
• SNMP: origem monitoring-server, finalidade monitorização de hardware e interfaces, revisão semestral.
• SSL VPN: origem WAN, finalidade Remote Access, revisão mensal dos logs.

Quando existem várias firewalls ou um cluster HA, deve começar-se por um sistema com uma boa opção de reposição. A alternância de funções e o acesso de manutenção são tratados em Configurar High Availability na Sophos Firewall.

Casos especiais e proteção adicional

User Portal, VPN Portal e SSL VPN

Primeiro, é necessário determinar qual o portal realmente necessário. Os clientes e as configurações VPN pertencem ao VPN Portal; o User Portal desempenha outras funções para os utilizadores. Consulte Comparação dos portais da Sophos Firewall.

Se um serviço de Remote Access tiver de estar disponível em todo o mundo, MFA, grupos de utilizadores restritos e logging são mais importantes do que uma restrição geográfica inadequada. A configuração é apresentada em MFA para WebAdmin, VPN Portal e Remote Access. Ainda assim, o Port Sharing deve ser evitado: a autenticação não substitui um controlo de acessibilidade correto.

Os inícios de sessão de WebAdmin, User Portal, VPN Portal e SSL VPN acessíveis publicamente são rapidamente encontrados por scanners e bots. Mesmo com MFA, isto gera tráfego de força bruta, ruído nos logs e carga adicional.

Se já ocorrerem muitas falhas de login no VPN Portal ou bloqueios de contas, Proteger o VPN Portal da Sophos Firewall contra ataques de força bruta reúne a verificação de logs, o controlo de identidade, a contenção através de ACL e a verificação posterior num processo de resposta a incidentes.

Se um portal tiver de permanecer acessível em todo o mundo, Sophos Firewall Threat Feeds com a ação Block podem bloquear adicionalmente origens IPv4 maliciosas conhecidas provenientes de Third-Party Feeds como Cybora, incluindo tráfego destinado à própria firewall. Os IoCs de domínio ou URL não protegem um início de sessão contra um IP de origem malicioso; atualmente, as origens IPv6 não são suportadas. Por isso, os Threat Feeds são uma proteção adicional e não substituem ACLs restritas. O artigo ligado explica a configuração, os testes e o allowlisting.

SSH e regras temporárias de suporte

O SSH só deve estar acessível quando necessário, a partir de uma rede de gestão, através de VPN ou para um IP de suporte fixo. É preferível utilizar autenticação por Public Key. Após um caso de suporte, elimina-se a exceção ACL temporária; não se deve pressupor um estado de desativação que não esteja confirmado na interface atual. Os passos adicionais encontram-se em Ligar à Sophos Firewall por SSH.

Uma permissão de acesso à CLI não equivale a um início de sessão SSH: Segundo a descrição do perfil para SFOS 22/23, o perfil Administrator concede acesso total à CLI, sem especificar o transporte. Em contrapartida, o guia do PuTTY para as mesmas versões exige o nome de utilizador admin para SSH pela rede e exclui outros nomes de utilizador; isto também se aplica ao início de sessão com palavra-passe. Daqui não se deduz que as contas de administrador nominativas tenham capacidade de acesso SSH, nem se retira uma conclusão geral sobre todas as formas de acesso à CLI. A função Console do WebAdmin abre uma consola no browser através do acesso WebAdmin e não comprova um início de sessão SSH pela rede. A possibilidade de uma determinada conta nominativa utilizar este acesso pelo browser tem de ser verificada separadamente, com base nas suas permissões e no firmware instalado. A gestão de chaves, permitida apenas ao administrador predefinido, também é uma permissão distinta e não determina quais as contas que podem iniciar sessão por SSH com palavra-passe.

Verificar a via de recuperação efetiva antes de alterar uma ACL: Para a via SSH pela rede documentada, utilizar a conta integrada admin com as suas credenciais atuais ou com uma chave configurada para esse efeito. Iniciar sessão através do acesso escolhido numa nova sessão, abrir a consola necessária e registar a conta, o transporte e a versão do firmware no registo da alteração; uma porta TCP acessível, por si só, não é suficiente. Um acesso funcional à Console pelo browser continua a depender da via WebAdmin e não constitui uma via de recuperação independente se esta for bloqueada. Se for necessária uma conta nominativa como via de recuperação por SSH, ou se o comportamento observado contrariar o guia, interromper a alteração, manter um acesso autorizado já testado e esclarecer com o Sophos Support o âmbito exato das contas e dos transportes abrangidos. Não alargar a ACL nem recorrer a tentativas repetidas de início de sessão como substituto desse esclarecimento.

Elimine uma exceção expirada em Administration > Device access > Local service ACL exception rule através de Delete na regra em questão e confirme com OK. Antes, teste a via administrativa que tem de ser mantida; depois, confirme que a antiga origem de suporte já não consegue ligar-se. Uma data de expiração registada aqui é uma obrigação de revisão, não uma prova de eliminação automática.

Troubleshooting

Se um início de sessão ficar subitamente inacessível, verifique também Administration > Admin and user settings > Login security > Block login. Este bloqueio por IP de origem depende de falhas de autenticação e pode afetar WebAdmin, CLI, VPN Portal e User Portal. Não é uma regra ACL. As tentativas CAPTCHA falhadas não contam como estas tentativas de início de sessão. Verifique a duração configurada do bloqueio e os eventos em vez de permitir HTTPS para uma zona inteira ou desativar indiscriminadamente a proteção.

Se um serviço local não estiver acessível ou bloqueado como esperado, verifique pela seguinte ordem:

1. Destino e porta: o IP da firewall está correto e o serviço utiliza a porta esperada?
2. Zona de origem: o cliente vem diretamente da zona esperada, através de VPN ou do Web Proxy?
3. Tabela de zonas: o serviço está permitido para esta zona em Administration > Device access?
4. Exceções ACL: IP version, Source zone, Source Network / Host, Destination host, Services, Action e posição estão corretos?
5. Port Sharing: o VPN Portal e a SSL VPN partilham a mesma porta e o mesmo protocolo?
6. API: a ativação da API, os Allowed IP hosts e o HTTPS Device Access estão todos corretos?
7. DNS: o DNS está permitido para clientes internos? Para publicação em WAN, também é necessário Publish on WAN.
8. Logs: o Log Viewer apresenta eventos adicionais do serviço ou de início de sessão?
9. Packet Capture: iniciar o Trace antes de repetir o teste. O acesso permitido tem de funcionar e apresenta normalmente Status: Consumed; a tentativa bloqueada apresenta normalmente Status: Violation e Reason: LOCAL_ACL. A Rule-ID não é a ID da exceção ACL. A utilização é explicada em Packet Capture na Sophos Firewall.

Se o WebAdmin ou um portal continuar acessível apesar de a zona de origem estar desativada, devem testar-se primeiro o Web Proxy e o Port Sharing. Uma regra de firewall adicional não resolve este problema.

Para rastreabilidade a longo prazo, podem utilizar-se o Central Firewall Reporting ou Enviar Syslog da Sophos Firewall para um SIEM.

Checklist operacional

• O WebAdmin não está amplamente acessível a partir de zonas WAN, Guest, IoT ou VoIP.
• HTTPS, SSH e SNMP estão limitados a origens específicas de gestão ou monitorização.
• O User Portal, o VPN Portal e a SSL VPN só estão ativos se o conceito operacional assim o exigir.
• O VPN Portal e a SSL VPN não partilham a mesma porta e o mesmo protocolo.
• O acesso através do Web Proxy a serviços HTTP/HTTPS locais foi testado separadamente.
• API access, Allowed IP hosts e HTTPS Device Access estão alinhados.
• As exceções ACL temporárias incluem a finalidade e a data de expiração e são eliminadas após a conclusão.
• As origens permitidas e bloqueadas foram testadas; os logs confirmam o resultado.
• As regras são verificadas regularmente quanto a origens obsoletas, serviços desnecessários e exceções Accept abrangentes.

Ressalvas sobre as fontes

O STAS fornece autenticação de utilizadores; não é uma VPN nem um canal administrativo cifrado. A permissão para o seu serviço de autenticação não substitui uma via de gestão protegida.

As instruções conservadas sobre chaves SSH de SFOS 22/23 são ambíguas: especificam RSA/DSA com pelo menos 2048 bits e enumeram ECDSA excluindo ED25519. Não deduza suporte para ED25519 nem considere DSA uma recomendação. Antes do registo, confirme o algoritmo suportado pelo firmware efetivamente utilizado; carregue apenas a chave pública e mantenha uma via de recuperação separada. Uma permissão de Device Access não valida um algoritmo de chave.

O Adaptive Learning também inclui URL de vírus detetados, nomes/URL/endereços IP de ameaças, endereços IP de origem e aplicações utilizadas. O envio HTTPS predefinido abrange dados do dispositivo, firmware e licenças (sem informação do proprietário), estado de funcionalidades/HA/gestão na nuvem, quantidades de objetos, erros e percentagens de utilização de CPU/memória/disco. Trata-se de uma decisão sobre divulgação de dados, não de um controlo ACL. O Sophos Assistant está ativado por predefinição; para o desativar, desmarque Turn on Sophos Assistant em Administration > Admin and user settings, clique em Apply e termine a sessão para voltar a iniciá-la. Isto não desativa a telemetria.

FAQ