Proteger o VPN Portal da Sophos Firewall contra ataques de força bruta

Muitas falhas de login no Sophos Firewall VPN Portal mostram, antes de mais, que o portal está acessível a partir da Internet e é alvo de ataques automatizados. Ainda não provam uma intrusão bem-sucedida. A situação torna-se crítica quando são atingidos nomes de utilizador reais, quando contas no AD ou Microsoft Entra ID são bloqueadas ou quando aparece um login bem-sucedido desconhecido entre as tentativas falhadas.

Para conter o ataque, deve seguir-se esta ordem:

1. Preservar nos logs o intervalo de tempo, os utilizadores, os IP de origem e os métodos de autenticação.
2. Verificar os logins bem-sucedidos e os eventos de identidade no mesmo período.
3. Limitar o VPN Portal às origens ou aos países necessários através de uma Local Service ACL.
4. Ativar Block login e excluir a partilha de porta entre VPN Portal e SSL VPN.
5. Remover métodos de autenticação desnecessários e verificar MFA ou a proteção Entra.
6. Bloquear adicionalmente origens IPv4 maliciosas conhecidas através de Threat Feeds e monitorizar o efeito.

⚠️ Não desativar o VPN Portal sem preparação. Sophos Connect Provisioning e Microsoft Entra ID SSO utilizam a porta do VPN Portal. Antes de alterar Device Access ou portas, é necessário um segundo acesso administrativo testado e um plano para perfis de cliente, Redirect URIs e rollback.

Confirmar o ataque no Log Viewer

No Log Viewer, abrem-se os eventos de autenticação e aplicam-se os filtros:

• Log component: VPN Portal Authentication
• Status: Failed

Para cada resultado são relevantes a hora, Source IP, Source country, Username, Authentication mechanism e Reason. Num SIEM utilizam-se os campos Syslog log_component com o valor VPN Portal Authentication e status com o valor Failed; a sintaxe concreta da consulta depende do SIEM utilizado.

Em seguida, procura-se também Successful para os mesmos nomes de utilizador e o mesmo intervalo de tempo. Um login bem-sucedido desconhecido é mais importante do que o simples número de tentativas falhadas e deve ser tratado como um possível incidente de conta.

Uma única origem ou um ataque distribuído

A distribuição determina qual a proteção eficaz:

• Muitas tentativas a partir de um endereço IP: Block login pode bloquear temporariamente a origem depois de atingido o limite.
• Poucas tentativas a partir de muitos endereços IP: Uma botnet distribuída pode permanecer abaixo do limite em cada origem. Nesse caso, ACL, proteção de identidade e Threat Feeds tornam-se mais importantes.
• Muitos nomes de utilizador a partir da mesma origem: Este padrão corresponde a Password Spraying ou Credential Stuffing.
• Repetidamente o mesmo utilizador real: Verificar nos logs de AD, Entra ou RADIUS os bloqueios de conta e os logins bem-sucedidos.
• Nomes aleatórios que não existem: Trata-se frequentemente de scanning automatizado, mas continua a gerar carga e ruído nos logs.

Bloquear manualmente apenas o IP de origem raramente resolve de forma duradoura um ataque distribuído. Primeiro reduz-se a superfície acessível e depois acrescentam-se automaticamente as origens maliciosas conhecidas.

Verificar especificamente os logs em bruto

Se o Log Viewer não fornecer contexto suficiente, descarregam-se em Diagnostics > Tools > Troubleshooting logs os ficheiros afetados:

• vpnportal.log para o acesso ao portal;
• access_server.log para a autenticação e autorização de utilizadores;
• oauth_sso_vpn.log adicionalmente para Microsoft Entra ID SSO.

Por outro lado, sslvpn.log pertence ao serviço SSL VPN e só é relevante quando o erro ocorre durante o estabelecimento do túnel e não no login do portal. Os logs de autenticação podem conter nomes de utilizador, endereços IP públicos e outros dados sensíveis dos pedidos. Por isso, os excertos são limitados no tempo e no conteúdo, anonimizados antes da partilha e não são copiados sem verificação para tickets públicos. Serviços e logs da Sophos Firewall associa outros ficheiros de log; Guardar logs da Sophos Firewall descreve um arquivo de suporte estruturado.

Limitar o VPN Portal às origens necessárias

O VPN Portal é um serviço local da firewall. As regras normais de firewall ou DNAT não controlam este acesso; para isso utiliza-se Administration > Device access. Os fundamentos completos encontram-se em Device Access e Local Service ACL.

Antes da alteração, abre-se e testa-se efetivamente um acesso independente através da consola, da LAN de gestão, de uma VPN de administração ou do Sophos Central. Em seguida, cria-se primeiro a exceção restritiva:

1. Em Administration > Device access > Local service ACL exception rule, clicar em Add.
2. Name: por exemplo vpn-portal-from-approved-countries.
3. Rule position: Top.
4. IP version: IPv4; se estiver publicado IPv6, também é necessária uma regra IPv6 separada.
5. Source zone: WAN.
6. Source networks and hosts: redes fixas de parceiros, uma lista de IP mantida ou um Country Group com os países realmente necessários.
7. Destination host: a interface WAN ou o IP WAN configurado na Sophos Firewall onde o acesso chega. Atrás de um router NAT a montante, não se refere ao endereço público desse router.
8. Services: apenas VPN portal.
9. Action: Accept.
10. Guardar a regra.

No estado final, o VPN Portal não está genericamente ativado para WAN na matriz Device Access, ficando acessível apenas através das exceções ACL necessárias. As alterações de Device Access têm efeito imediato; por isso, a transição segura com teste positivo, teste negativo e rollback é descrita deliberadamente no guia detalhado de Device Access.

Depois, testa-se a exceção a partir de uma origem externa autorizada e de uma origem não autorizada. Enquanto continuar ativa uma autorização WAN ampla, um teste positivo bem-sucedido não prova, por si só, que a exceção limita o acesso conforme esperado.

Uma limitação por país é útil quando o grupo de utilizadores está geograficamente bem definido. Contudo, não é um controlo de identidade: viajantes, redes móveis, fornecedores VPN e geolocalizações IP incorretas podem bloquear utilizadores legítimos. O acesso mundial exige, por isso, uma proteção de identidade especialmente forte, MFA, logging e um processo de revisão.

Configurar corretamente Login Security e as portas

Em Administration > Admin and user settings > Login security, ativa-se Block login. O Sophos Firewall Health Check utiliza como ponto de partida cinco falhas de login em 60 segundos e uma duração de bloqueio de cinco minutos. O valor adequado para produção depende, ainda assim, do número de utilizadores, do processo de helpdesk e das origens NAT partilhadas.

O bloqueio funciona por IP de origem e, depois de atingido o limite, não afeta apenas o VPN Portal. WebAdmin, CLI, VPN Portal e User Portal também deixam de abrir a partir dessa origem. Um escritório, hotel ou NAT de fornecedor pode, assim, afetar simultaneamente vários utilizadores legítimos e um administrador. Por isso, nunca se realiza um teste negativo a partir do único acesso administrativo disponível.

Num ataque distribuído, Block login é apenas uma camada de proteção. Muitos bots podem permanecer individualmente abaixo do limite.

Excluir a partilha de portas

Comparam-se estes dois valores:

• Administration > Admin and user settings > VPN portal HTTPS port, por predefinição TCP 443
• Remote access VPN > SSL VPN > SSL VPN global settings > Port, por predefinição 8443 com TCP ou UDP

Se VPN Portal e SSL VPN utilizarem a mesma porta e o mesmo protocolo, as definições de Login Security não se aplicam. Além disso, o VPN Portal fica acessível a partir das zonas autorizadas para SSL VPN, mesmo que esteja desativado nessas zonas em Device Access.

A combinação tem, por isso, de ser inequívoca. Mudar apenas para uma porta aleatória não impede um ataque. Se a porta do VPN Portal for alterada, é necessário atualizar o URL do portal, o Entra Redirect URI e o valor vpn_portal_port para Sophos Connect Provisioning, e voltar a testar com um utilizador-piloto.

Proteger a autenticação e as contas afetadas

Em Authentication > Services > VPN portal authentication methods, só permanecem ativos os servidores de que o conceito atual de Remote Access realmente necessita. Um caminho local, AD, LDAP ou RADIUS que já não seja utilizado não oferece qualquer vantagem, mas pode expor credenciais adicionais a testes contra o portal público.

MFA não impede todas as tentativas falhadas, mas reduz o risco de uma palavra-passe conhecida ou adivinhada ser suficiente. MFA para VPN Portal e Remote Access descreve a configuração para utilizadores locais e de diretório. Com Microsoft Entra ID SSO, verificam-se adicionalmente Entra MFA, Conditional Access, Sign-in Logs e Risk Events.

Um utilizador real com tentativas falhadas suspeitas não é analisado apenas na firewall:

1. Verificar bloqueios de conta e logins bem-sucedidos no Identity Provider responsável.
2. Terminar sessões bem-sucedidas desconhecidas de acordo com o processo de incidentes.
3. Repor a palavra-passe e os métodos MFA registados se houver suspeita de comprometimento.
4. Verificar a associação a grupos e a autorização de Remote Access.
5. Só depois confirmar, com um login-piloto documentado, que o acesso legítimo voltou a funcionar.

O VPN Portal só pode ser completamente removido de WAN se nenhum processo necessário depender dele. Entra SSO e o provisioning através de .pro utilizam a porta do portal. Com ficheiros .ovpn distribuídos manualmente, pode ser possível um processo de publicação mais restritivo, mas as alterações aos perfis têm então de ser distribuídas e testadas de forma controlada.

Adicionar Threat Feeds contra origens conhecidas

A Sophos Firewall também pode comparar endereços IP de origem maliciosos conhecidos no tráfego dirigido ao sistema para serviços como VPN Portal, WebAdmin e VPN. Feeds IPv4 mantidos são adequados como camada de proteção adicional.

Configurar Threat Feeds na Sophos Firewall explica a configuração completa, os requisitos de licença, o piloto Monitor, o funcionamento em Block, os False Positives e os feeds Cybora testados pela Avanet. Para um novo feed, continua a ser necessário verificar a obtenção e o conteúdo IoC, observar primeiro o efeito e só depois bloquear de forma controlada.

Para que as correspondências de Active Threat Response apareçam no Log Viewer, deve ativar-se Local reporting para Active threat response em System services > Log settings.

Os Threat Feeds não substituem uma ACL nem uma proteção de identidade forte. Detetam apenas os indicadores incluídos, os Third-Party Feeds suportam atualmente IPv4 para IoC de IP de origem e um IP de bot novo ou não listado continua acessível. Inversamente, um False Positive pode bloquear um utilizador legítimo; por isso, é necessário um processo documentado de exceção e revisão.

Verificar o efeito e continuar a monitorizar

Depois de cada alteração, repete-se o mesmo teste definido:

1. Uma origem externa autorizada alcança o VPN Portal e um utilizador-piloto consegue iniciar sessão.
2. Uma origem não autorizada deixa de alcançar o portal.
3. VPN Portal e SSL VPN utilizam uma combinação inequívoca de porta e protocolo.
4. Uma tentativa falhada controlada aparece no Log Viewer com o IP de origem e o método de autenticação esperados.
5. Sophos Connect Provisioning, Entra SSO e o próprio túnel VPN continuam a funcionar.
6. As correspondências de Threat Feed aparecem no log de Active Threat Response, caso esta camada de proteção seja utilizada.
7. Não ocorrem bloqueios de contas AD ou Entra nem logins bem-sucedidos desconhecidos.

Para a deteção a longo prazo, enviam-se os logs de autenticação para um SIEM. Os alertas úteis consideram não só o número de erros, mas também muitas origens diferentes contra o mesmo utilizador, muitos nomes de utilizador a partir de uma origem e logins bem-sucedidos depois de uma série de tentativas falhadas.

Perguntas frequentes