Proteger o acesso à Sophos Firewall: configurar Device Access

Em Administration > Device access define-se a partir de que zonas os serviços locais da Sophos Firewall ficam acessíveis. Isto inclui, por exemplo, HTTPS para a WebAdmin Console, SSH para CLI, Ping, DNS, User Portal, VPN Portal e outros serviços.

Esta área é crítica para a segurança. As regras de firewall normais controlam tráfego através da firewall. Device access controla tráfego para a própria firewall. Se WebAdmin ou SSH estiverem acessíveis a partir de uma zona não confiável, existe acesso direto de gestão ao equipamento de segurança.

⚠️ WebAdmin, SSH e portais só devem estar acessíveis a partir de redes confiáveis. Em ambientes de produção, é melhor restringir o acesso a uma rede de gestão, a um IP fixo de administração, a VPN ou ao Sophos Central Firewall Management.

Porque Device Access não é uma regra de firewall

Uma regra de firewall típica permite ou bloqueia ligações entre zonas, por exemplo LAN para WAN ou VPN para Server. Device Access é diferente: trata de serviços que correm diretamente na Sophos Firewall.

Exemplos:

• Um administrador abre https://172.16.16.16:4444.
• Um cliente usa a firewall como servidor DNS.
• Um sistema de monitorização faz ping à firewall.
• Um utilizador abre o User Portal ou VPN Portal.
• Um administrador liga-se à firewall por SSH.

Este tráfego não tem como destino um servidor atrás da firewall, mas sim a própria firewall. Por isso é controlado pela local service ACL.

É também por isso que Device Access faz parte do hardening básico de qualquer Sophos Firewall. Um conjunto limpo de regras LAN-to-WAN não protege automaticamente os serviços de gestão e de portal da própria firewall. Estes serviços têm de ser verificados separadamente e restringidos de forma consciente.

Compreender permissões por zona

Na parte superior de Administration > Device access existe uma tabela com zonas e serviços. Quando um serviço está ativado numa zona, o acesso a esse serviço local é, em princípio, permitido a partir dessa zona.

A tabela de zonas é prática, mas ampla. Funciona para zonas internas claras, por exemplo LAN, Management ou VPN. Assim que um serviço deve estar acessível apenas a IPs específicos de administradores, locais, países ou destinos de suporte, as Local service ACL exception rules são a melhor opção.

Exemplos típicos:

Em Custom Zones, a disponibilidade de serviços locais também pode ser influenciada pelas definições da zona. Ainda assim, Device Access deve ser sempre verificado conscientemente, porque é a visão central dos serviços locais da firewall.

Que serviços podem ser restringidos por ACL Rules?

Com Local Service ACL e ACL Exception Rules é possível controlar serviços locais da firewall de forma muito precisa. Estes serviços são especialmente relevantes:

Quanto mais destes serviços estiverem acessíveis a partir de WAN, redes de convidados, redes IoT ou zonas definidas de forma imprecisa, maior será a superfície de ataque. O objetivo não é desligar tudo, mas tornar cada serviço acessível apenas onde é realmente necessário.

Definir fontes da forma mais restrita possível

Uma ACL Rule não precisa de permitir simplesmente Any. A fonte pode ser definida com muito detalhe, por exemplo com:

• IPs individuais de administradores
• redes de gestão
• IP ranges
• IP lists
• FQDN hosts
• FQDN host groups
• DNS hosts ou DNS groups
• Country objects ou grupos de países
• redes dedicadas de VPN ou suporte

Assim, o acesso fica muito melhor delimitado. Exemplo: se um serviço externo de suporte vem apenas de um FQDN fixo ou de um intervalo IP definido, toda a zona WAN não deve receber acesso a HTTPS ou SSH. Se um sistema de monitorização precisa de SNMP, uma rede completa de servidores não deve poder consultar SNMP na firewall.

Em cenários globais de Remote Access, a delimitação é mais difícil. Algumas empresas não podem simplesmente permitir SSL VPN ou VPN Portal apenas a partir da Suíça, Alemanha ou de um único país, porque os colaboradores trabalham em todo o mundo. Nestes casos, deve-se usar adicionalmente MFA, logging, definições restritivas de portal e Threat Feeds.

Local Service ACL Exception Rule

Quando um serviço não deve ser disponibilizado para uma zona inteira, usa-se uma Local service ACL exception rule. Assim é possível definir com precisão quem pode aceder a que serviço local.

Caminho:

1. Abrir Administration.
2. Selecionar Device access.
3. Deslocar até Local service ACL exception rule.
4. Clicar em Add.

Uma ACL Exception Rule consiste essencialmente nestes campos:

Para acesso WebAdmin a partir da internet, nunca se deve usar Any como fonte. A Sophos impede deliberadamente o acesso WebAdmin a partir da zona WAN para todas as fontes, porque isso seria um risco elevado. Se o acesso WAN for realmente necessário, deve ser permitido apenas através de IPs de origem específicos, redes definidas, objetos FQDN ou outras fontes restritas.

A ordem também é importante. ACL Exception Rules são avaliadas de cima para baixo. Uma regra Drop mais acima pode tornar uma regra Accept posterior ineficaz. Inversamente, uma regra Accept demasiado ampla pode anular restrições planeadas. Por isso, a ordem das regras deve ser analisada com o mesmo cuidado que as regras de firewall.

Configuração base recomendada

Para muitos ambientes de produção, esta lógica é sensata:

• Permitir HTTPS/WebAdmin apenas a partir de Management, admin-VPN ou IP fixo de administração.
• Desativar SSH por predefinição e permitir apenas quando necessário através de ACL específica.
• Ativar DNS apenas em zonas onde os clientes usam realmente a firewall como servidor DNS.
• Permitir Ping para sistemas internos de monitorização, mas não de forma geral a partir de WAN.
• Ativar User Portal, VPN Portal e SSL VPN apenas quando forem necessários.
• Permitir RED apenas para locais ou intervalos de origem onde existam efetivamente RED Appliances.
• Permitir SNMP apenas para o sistema de monitorização.
• Permitir SMTP Relay apenas para sistemas internos definidos.
• Ativar Dynamic Routing apenas em segmentos onde protocolos de routing dinâmico são realmente usados.
• Verificar MFA para WebAdmin, VPN Portal e Remote Access.
• Usar Sophos Central Firewall Management quando for necessário acesso externo de gestão seguro.

Tratar SSH com especial cuidado

SSH é muito útil para troubleshooting e suporte, mas não deve ficar amplamente aberto de forma permanente. Para SSH:

• Apenas o utilizador admin pode iniciar sessão por SSH.
• A autenticação por public key é o método preferido.
• O acesso a partir de WAN deve ser permitido apenas através de IPs de origem fixos ou VPN.
• Após uma análise, deve-se verificar se SSH continua a ser necessário.

Mais detalhes estão no guia Ligar à Sophos Firewall por SSH.

Bots, brute force e Threat Feeds

Na prática, vê-se muito frequentemente que serviços demasiado abertos são encontrados imediatamente por bots. WebAdmin, User Portal, VPN Portal e SSL VPN são particularmente afetados. Mesmo que um serviço esteja protegido por palavra-passe e MFA, logins públicos geram tentativas de ataque, tráfego brute-force, ruído nos logs e carga desnecessária na firewall.

Isto não significa automaticamente que um ataque teve sucesso. Mas mostra que o serviço faz parte da superfície pública de ataque. Quanto menos fontes chegarem sequer ao login, melhor.

Se um portal tiver de estar acessível em todo o mundo, filtros por país ou IPs de origem individuais muitas vezes não chegam. Nestes ambientes recomendamos também Third-Party Threat Feeds. Threat Feeds fornecem continuamente à firewall Indicators of Compromise atuais, por exemplo IPs, domínios ou URLs maliciosos. Scanners conhecidos, botnets e atacantes podem assim ser bloqueados antes de chegarem ao WebAdmin, VPN Portal, SSL VPN ou outros serviços publicados.

Mais detalhes: Sophos Firewall Threat Feeds

Erros comuns

Verificar uma regra de firewall em vez de Device Access

Se WebAdmin, SSH, DNS ou Ping para a firewall não estiverem acessíveis, uma regra de firewall normal não ajuda. O tráfego não passa através da firewall; termina na própria firewall. Por isso é necessário verificar Administration > Device access.

WebAdmin permitido a partir de demasiadas zonas

WebAdmin não deve estar acessível a partir de todas as zonas internas. Uma rede de convidados, IoT ou VoIP normalmente não precisa de acesso à gestão da firewall. Também internamente deve-se assumir que podem existir clientes comprometidos. Uma rede de gestão separada ou admin-VPN reduz claramente este risco.

DNS não ativado para a zona de clientes

Se os clientes devem usar a firewall como servidor DNS, DNS tem de estar permitido para a zona correta. Caso contrário, os clientes chegam ao IP da firewall, mas não recebem resposta DNS. Inversamente, DNS não deve ser permitido a partir de zonas onde a firewall não deve ser usada como DNS resolver.

Confundir User Portal e VPN Portal

User Portal e VPN Portal são serviços diferentes. Dependendo do conceito de Remote Access, é preciso verificar que portal é realmente necessário. Muitas vezes um portal é ativado porque um utilizador precisou de descarregar uma configuração uma vez, e depois fica aberto durante anos. Estes legados devem ser removidos regularmente.

Ignorar o caso especial do Web Proxy

Quando Web Proxy é usado, pedidos HTTP e HTTPS podem parecer internos do ponto de vista do proxy. Isto pode afetar a forma como o acesso a WebAdmin, Captive Portal, VPN Portal ou User Portal é controlado. Em ambientes com proxy, deve-se testar com especial cuidado que acessos são realmente possíveis.

Regra ACL demasiado ampla

Uma ACL Exception Rule com Source zone: Any, Source Network / Host: Any e Services: HTTPS, SSH quase nunca é uma boa ideia. Estas regras anulam o ganho de segurança da exceção ACL. É melhor uma regra pequena e clara, com uma fonte inequívoca e exatamente os serviços necessários.

Regra Drop na posição errada

Se uma regra Drop estiver acima de uma regra Accept, o acesso pretendido pode mesmo assim ser bloqueado. Em ACL Exception Rules, a ordem é portanto tão importante como nas regras de firewall.

SSL VPN e VPN Portal deixados demasiado abertos

Remote Access muitas vezes precisa de estar acessível a partir do exterior. Mesmo assim, deve-se verificar se todos os países, redes e grupos de utilizadores precisam realmente de acesso. Se uma limitação apertada por fonte não for possível, MFA, logging e Threat Feeds devem ser usados com ainda mais consistência.

Troubleshooting

Se um serviço local não estiver acessível, esta sequência ajuda:

1. O IP de destino da firewall está correto?
2. O cliente vem da zona esperada?
3. O serviço está permitido para esta zona em Administration > Device access?
4. Existe uma Local service ACL exception rule correspondente?
5. Existe uma regra ACL superior com Drop que corresponde?
6. O serviço está configurado noutra porta?
7. O acesso é visto de forma diferente por VPN, proxy ou NAT?
8. O Log Viewer mostra alguma indicação?
9. O Packet Capture vê a tentativa de ligação no interface?

Para acesso de suporte, pode fazer sentido criar uma ACL Exception Rule específica e removê-la ou desativá-la após a conclusão.

Mais informações

• Sophos Firewall - Device access
• Sophos Firewall - Device access best practices
• Ligar à Sophos Firewall por SSH
• Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Remote Access