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.

Antes de cada alteração, registam-se as definições atuais ou guarda-se uma cópia da configuração. Incluem-se a seleção WAN de VPN portal, todos os campos e a ordem das exceções Local Service ACL, o estado e os três valores de Block login, portas e protocolos de VPN Portal e SSL VPN e a seleção e ordem dos servidores de autenticação. Para Provisioning ou Entra SSO, registam-se também vpn_portal_port, o URL do portal e o Redirect URI. Para Threat Feeds alterados guardam-se URL, tipo de indicador, action, estado e opções personalizadas. O rollback restaura estes valores, não valores predefinidos presumidos.

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. Nem todos surgem como colunas padrão em cada vista; Detailed view e colunas adicionais mostram os detalhes disponíveis. Se faltar contexto, verificam-se os logs em bruto e do Identity Provider. Num SIEM filtra-se log_component por VPN Portal Authentication e status por Failed; a sintaxe depende do SIEM.

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 Fusion (anteriormente 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. Rule 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.

Depois de guardar, testa-se primeiro a exceção a partir de uma origem externa autorizada. Pelo segundo acesso administrativo verificado, remove-se a seleção geral WAN de VPN portal em Device Access e guarda-se. As alterações têm efeito imediato. A origem autorizada deve continuar a chegar ao portal e uma não autorizada deve deixar de o alcançar. Se o teste positivo falhar, repõe-se a seleção WAN anterior pelo segundo acesso. O guia de Device Access descreve outras variantes.

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.

O web proxy configurado na firewall é uma exceção importante. O SFOS trata os pedidos HTTP e HTTPS do proxy como internos, não como tráfego de uma zona. Utilizadores com acesso ao proxy podem assim alcançar VPN Portal e outros serviços HTTP da firewall, mesmo que Device Access os desative para a sua zona. Se o proxy for usado, realiza-se o teste negativo uma vez diretamente e outra comprovadamente pelo proxy explícito ou transparente. Device Access não bloqueia este caminho interno por zona; se necessário, limita-se o próprio acesso ao proxy.

Configurar corretamente Login Security e as portas

Em Administration > Admin and user settings > Login security, ativa-se Block login e preenchem-se os três campos para número de tentativas, intervalo e duração do bloqueio. Cinco falhas em 60 segundos e cinco minutos de bloqueio são apenas um exemplo, não um valor Sophos universal nem um valor de produção a adotar sem piloto. Os valores dependem de utilizadores, helpdesk e NAT partilhado. O teste é feito a partir de um IP controlado, mantendo aberto o segundo acesso administrativo.

O bloqueio funciona por IP de origem e aplica-se a todos os serviços após o limite, incluindo WebAdmin, CLI, VPN Portal e User Portal. Atrás de NAT de escritório, hotel ou fornecedor pode afetar vários utilizadores e um administrador ao mesmo tempo. Nunca se realiza o teste negativo pelo ú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. Falhas de CAPTCHA não contam como logins falhados nem acionam o bloqueio.

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ó ficam ativos os servidores necessários. Um caminho local, AD, LDAP ou RADIUS sem uso permite tentativas desnecessárias contra outro diretório. Pelo menos um servidor deve permanecer selecionado. VPN Portal não suporta RADIUS com challenge-based MFA; não deve ser planeado como MFA do portal.

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 removido de WAN se nenhum processo necessário depender dele. O provisioning .pro liga-se através de vpn_portal_port. Com Entra SSO, o URL usado para VPN Portal e Remote Access e o Redirect URI registado devem corresponder ao gateway e porta publicados. Ficheiros .ovpn distribuídos manualmente podem permitir publicação mais restrita, mas alterações de perfil exigem distribuição e testes controlados.

Adicionar Threat Feeds contra origens conhecidas

A Sophos Firewall também compara IP de origem maliciosos conhecidos em tráfego para os próprios serviços, incluindo VPN Portal, WebAdmin e VPN. Segundo a ajuda SFOS 22, aplica-se a MDR, NDR Essentials e Third-Party Threat Feeds, mas não a Sophos X-Ops Threat Feeds. Um Third-Party Feed IPv4 mantido serve assim como camada adicional para origens conhecidas.

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 mostrar correspondências localmente no Log Viewer, ativa-se Local reporting para Active threat response em System services > Log settings. XGS 87/87w e 107/107w não suportam reporting local; usa-se Sophos Fusion ou um servidor Syslog.

Os Threat Feeds não substituem uma ACL nem autenticação forte. Comparam apenas endereços listados. Third-Party Feeds aceitam IPv4 individuais, não IPv6, intervalos IP ou endereços de rede; novos IP de bot continuam acessíveis. Um False Positive pode bloquear utilizadores legítimos. Um feed começa em Monitor; verificam-se erros e resultados inesperados antes de mudar para Block. Uma Threat Exclusion afeta todos os módulos Active Threat Response, devendo ser limitada, justificada e temporária. As correspondências e exceções são revistas regularmente.

No rollback, um feed alterado regressa à action anterior; um feed novo é desativado, mas não é eliminado sem revisão. Depois verifica-se se uma origem afetada por False Positive volta a alcançar o portal e se as restantes proteções funcionam.

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 destino de logs configurado, caso a proteção seja usada.
7. No período de observação definido não surgem novos bloqueios AD ou Entra nem logins desconhecidos bem-sucedidos.

Se um teste falhar, repõe-se primeiro apenas a última alteração no valor anterior documentado. Pode ser a action do feed, um servidor, Block login, porta e Redirect URI ou Device Access. Para Device Access, repõe-se primeiro a antiga seleção WAN pelo segundo acesso e só depois se remove a nova exceção ACL. Para a porta, repõem-se em conjunto porta e protocolo, .pro, URL do portal e Redirect URI, repetindo depois os testes permitido e negado.

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