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, 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.

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, se possível, com Public Key. Os administradores com o perfil Administrator podem obter acesso à CLI; apenas o Default Admin gere as definições e chaves de Public Key.
• 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.

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.

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. 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 Central.

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.
• A SSL VPN utiliza por predefinição TCP ou UDP 8443.
• 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

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. Description: documentar a finalidade, o ticket e a data de expiração prevista.
3. Rule position: selecionar Top para uma exceção WAN específica e verificar as restantes regras quanto a sobreposições.
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

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.

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.

Implementar alterações sem bloqueio de acesso

As alterações ao Device Access têm efeito imediato. 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 Central.
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 a origem permitida não funcionar após a remoção da permissão abrangente ou uma origem bloqueada continuar a alcançar o serviço, a permissão abrangente deve ser imediatamente reposta através da via de administração independente. Depois, corrige-se a regra ACL nova ou contraditória e repete-se o procedimento.

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.

Troubleshooting

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.

FAQ