Configurar Clientless SSL VPN na Sophos Firewall para RDP e SSH

Com Clientless SSL VPN, uma Sophos Firewall disponibiliza ligações internas individuais RDP, SSH, VNC ou a servidores de ficheiros diretamente no browser. O utilizador não instala um cliente VPN nem obtém acesso geral a uma rede interna. Em vez disso, inicia sessão no VPN Portal e vê apenas os bookmarks publicados pela respetiva Clientless Policy.

O nome semelhante pode conduzir facilmente à configuração errada: Clientless Users associa internamente um IP fixo a uma identidade. Não publica bookmarks nem faz parte deste procedimento de Remote Access.

O início de sessão no VPN Portal e a autenticação no destino são dois passos distintos. Clientless SSL VPN não suporta Credential Passthrough: a palavra-passe do VPN Portal não é automaticamente transmitida para o início de sessão no Windows ou SSH. Por conseguinte, dois inícios de sessão são normais, desde que não estejam guardadas credenciais do destino no bookmark.

O procedimento principal é curto:

Definir o sistema de destino fixo, a porta e o grupo de utilizadores autorizado.
Em Remote access VPN > Clientless SSL VPN policy > Bookmarks, criar um bookmark RDP ou SSH.
Em Policies, associar o grupo de utilizadores ao bookmark.
Proteger VPN Portal, certificado, autenticação, MFA e Device Access.
Testar o acesso a partir do exterior em VPN > Clientless access connections com um utilizador autorizado e outro não autorizado.

Quando Clientless SSL VPN é adequado — e quando não é

Clientless Access é especialmente adequado para poucos destinos fixos, acessos ocasionais ou técnicos externos quando não se pretende instalar um cliente VPN no dispositivo utilizado. Desta forma, RDP e SSH não precisam de ser publicados diretamente na Internet através de DNAT. Em vez disso, fica acessível publicamente o VPN Portal protegido.

No entanto, não substitui todos os cenários de Remote Access VPN:

Clientless SSL VPN é adequado para destinos RDP, SSH, VNC ou servidores de ficheiros individuais e estáticos que possam ser utilizados no browser.
Sophos Connect com IPsec ou SSL VPN é mais adequado quando um dispositivo gerido necessita de várias redes, aplicações nativas, DNS ou protocolos diferentes. O guia de decisão para Remote Access enquadra as variantes.
ZTNA destina-se a um acesso permanente orientado para aplicações, com identidade, estado do dispositivo e policies centrais. Os princípios básicos encontram-se em O que é Zero Trust Network Access?.
RD Gateway, Jump Host ou PAM devem ser considerados quando a administração privilegiada, contas pessoais no destino, gravação de sessões ou fluxos de aprovação são determinantes.

No caso do RDP, também é importante ter em conta que a área de transferência não é suportada em sessões Clientless desde o SFOS 19. Se copy-and-paste ou outras funções RDP nativas forem indispensáveis para o fluxo de trabalho, um caminho de acesso baseado num cliente ou especializado é uma escolha mais adequada.

Clientless SSL VPN não suporta endereços IP de destino dinâmicos. Embora seja permitido utilizar um nome de host como destino, a firewall tem de o resolver de forma estável para o sistema previsto. Um destino que muda frequentemente não deve ser planeado como um cenário Dynamic DNS atualizado de forma fiável.

Requisitos e valores de exemplo

Antes da configuração, devem estar definidos o destino, a identidade e o acesso ao portal:

O sistema de destino é alcançável a partir da firewall através de routing e DNS, e o serviço necessário está em execução.
Existe na firewall ou no servidor de autenticação associado um utilizador ou, de preferência, um grupo restrito.
O VPN Portal dispõe de um FQDN público ou acessível internamente e de um certificado fidedigno correspondente.
Em Authentication > Services, está selecionado um método adequado em VPN portal authentication methods.
Estão preparados MFA e um acesso de recuperação independente.
Foi decidido se as credenciais do destino podem ser guardadas no bookmark.

O exemplo RDP seguinte utiliza:

VPN Portal: https://vpn.example.com
servidor de destino: rdp-app01.intern.example
IP de destino: 10.20.30.25
porta RDP: 3389
bookmark: RDP-Fibu-Test
grupo: Clientless-RDP-Fibu
policy: Clientless-RDP-Fibu
segurança RDP para o primeiro teste: TLS
Automatic login: desativado
Share session: desativado

example.com é um domínio de exemplo reservado e 10.20.30.25 é um endereço privado de exemplo. O FQDN, o IP, o grupo e os nomes têm de ser substituídos pelos valores do próprio ambiente. A porta 3389 só continua correta se o servidor Windows utilizar efetivamente a porta RDP padrão.

Configurar o bookmark RDP

Bookmark com TLS e autenticação pessoal no destino

Em Remote access VPN > Clientless SSL VPN policy > Bookmarks, cria-se um novo bookmark com Add:

Em Name, introduzir RDP-Fibu-Test.
Em Type, selecionar RDP.
Em URL, introduzir rdp-app01.intern.example ou o IP fixo 10.20.30.25.
Utilizar a porta de serviço 3389. Só se introduz uma porta diferente se tiver sido configurada deliberadamente de outra forma no sistema de destino.
Manter Automatic login desativado para o primeiro teste.
Se necessário, introduzir o domínio de rede Windows, por exemplo, CORP ou corp.example.com.
Em Protocol security, selecionar TLS.
Manter Share session desativado.
Guardar com Save.

Sem Automatic login, o utilizador introduz as respetivas credenciais na janela RDP aberta. Desta forma, pode iniciar sessão com uma conta Windows pessoal, desde que o modelo de segurança do servidor de destino permita este modo TLS.

O certificado do VPN Portal e Protocol security: TLS cumprem funções diferentes. O certificado do portal protege o percurso do browser até à firewall. A definição RDP protege a ligação seguinte entre a firewall e o sistema Windows. Por conseguinte, um certificado de portal válido não substitui uma segurança RDP adequada.

Quando o servidor Windows exige NLA

Muitos sistemas Windows exigem Network Level Authentication (NLA). Neste caso, seleciona-se NLA no bookmark. O SFOS ativa assim Automatic login, e o nome de utilizador e a palavra-passe do sistema de destino têm de ser guardados no bookmark.

Não se trata apenas de uma opção de conveniência. Todos os utilizadores autorizados deste bookmark trabalham no sistema de destino com a mesma identidade Windows guardada. Para tal, deve ser utilizada apenas uma conta dedicada, com privilégios mínimos e passível de rotação. Contas Domain Admin, contas pessoais de administração e contas de serviço com privilégios amplos não devem ser guardadas num Clientless Bookmark.

O NLA não deve ser desativado no servidor Windows apenas para permitir o funcionamento do exemplo com TLS. Se não forem aceitáveis credenciais guardadas ou uma identidade de destino comum, Clientless RDP não é adequado para este servidor. Um VPN normal, RD Gateway, PAM ou um Jump Host controlado preservam melhor a rastreabilidade pessoal.

Share session também permanece desativado. A opção destina-se a um caso de colaboração planeado deliberadamente. Numa sessão partilhada, Stop session termina a ligação para todos os participantes, enquanto Suspend session pausa apenas o utilizador atual. Uma sessão de administração privilegiada não deve ser partilhada.

Configurar a Clientless Policy e o VPN Portal

Associar utilizadores e bookmark numa policy

Um bookmark existente, por si só, ainda não torna o destino visível para nenhum utilizador. Só a policy associa a identidade ao recurso:

Abrir Remote access VPN > Clientless SSL VPN policy.
Em Policies, clicar em Add.
Em Name, introduzir Clientless-RDP-Fibu.
Em Policy members, selecionar apenas o grupo Clientless-RDP-Fibu.
Em Published bookmarks, selecionar RDP-Fibu-Test.
Guardar com Apply.

Um Bookmark Group só compensa quando os mesmos utilizadores precisam de vários destinos. Para um único destino RDP, apenas cria um nível adicional de gestão.

Proteger o VPN Portal

O utilizador abre as ligações Clientless através do VPN Portal. A porta padrão é 443; a porta e o certificado encontram-se em Administration > Admin and user settings > Admin console and end-user interaction. No exemplo, o certificado tem de conter vpn.example.com como SAN e ser aceite pelo browser sem aviso. Importar e atribuir certificados na Sophos Firewall explica a atribuição geral de certificados.

Em Administration > Device access, VPN portal tem de ser permitido para o acesso efetivamente necessário. Se o portal tiver de estar acessível a partir de todas as origens WAN, ativa-se WAN na matriz. Com redes de origem conhecidas, é preferível a variante mais restrita: manter WAN desativado na matriz e criar em Local service ACL exception rule uma regra Accept com Source zone: WAN, o Source Network / Host concreto, o endereço necessário da firewall como Destination host e Services: VPN portal. Uma exceção Accept adicional não restringe uma autorização WAN já ativada de forma geral na matriz. Isto não ativa automaticamente WebAdmin, User Portal, SSH ou SSL VPN. O planeamento seguro encontra-se em Device Access e Local Service ACL.

⚠️ Um VPN Portal acessível a partir da WAN é uma superfície pública de início de sessão. Não deve ser operado sem MFA, um certificado fidedigno, uma associação restrita à policy e monitorização dos inícios de sessão. Se VPN Portal e SSL VPN partilharem a mesma porta e o mesmo protocolo, as zonas alcançáveis podem influenciar-se mutuamente; este efeito de Port Sharing tem de ser verificado separadamente.

Para o Sophos OTP local, começa-se por utilizar Specific users and groups em Authentication > Multi-factor authentication. Para o autorregisto através de uma aplicação de autenticação, ativa-se Generate OTP token with next sign-in, seleciona-se VPN portal em Require MFA for e guarda-se com Apply. A implementação piloto e o acesso de recuperação encontram-se em Ativar MFA na Sophos Firewall. O VPN Portal não suporta MFA RADIUS baseado em challenge; por isso, um método RADIUS existente tem de ser testado especificamente para este início de sessão no portal. Se o portal utilizar Microsoft Entra ID SSO e Conditional Access, Entra ID SSO para Sophos Connect e VPN Portal descreve toda a cadeia de identidade.

Testar o acesso a partir do exterior

O teste deve ser realizado a partir de uma rede externa real, por exemplo, através de um hotspot móvel. Um teste a partir da LAN não demonstra que DNS, certificado, Device Access e um router a montante funcionam corretamente a partir da Internet.

Abrir https://vpn.example.com numa janela privada do browser.
Verificar o nome do certificado, a cadeia de certificados e o estado do browser.
Iniciar sessão como membro de Clientless-RDP-Fibu e concluir o MFA.
Em VPN > Clientless access connections, verificar se aparece RDP-Fibu-Test.
Clicar em Connect. A sessão tem de abrir numa nova janela do browser.
Com Automatic login desativado, introduzir as credenciais pessoais do Windows e verificar o início da sessão RDP.
Terminar corretamente a sessão no sistema Windows e, em seguida, sair do VPN Portal.
Testar com um utilizador que não pertença ao grupo. O bookmark não pode aparecer para esse utilizador.
Remover temporariamente o utilizador de teste do grupo da policy e verificar se o acesso desaparece depois de um novo início de sessão.

O sucesso não significa apenas que aparece um ambiente de trabalho. O utilizador positivo vê exatamente os bookmarks previstos, o utilizador negativo não vê nenhum, o MFA é aplicado, o certificado é fidedigno, a autenticação no destino funciona e a sessão termina de forma rastreável no portal e no sistema de destino.

Opções para SSH, VNC e servidores de ficheiros

Bookmark SSH com Host Key verificado

Para SSH, seleciona-se SSH como Type em Bookmarks > Add. Um exemplo utiliza srv-linux01.intern.example, a porta 22 e o utilizador clientless-test.

O Public host key tem de pertencer ao servidor esperado. Num destino Linux, é possível apresentar a Host Key pública diretamente na consola fidedigna do servidor e documentar o respetivo fingerprint:

sudo cat /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Estes comandos são executados no servidor Linux de destino, não na Sophos Firewall. Se o servidor utilizar outro tipo de Host Key, o nome do ficheiro tem de ser adaptado em conformidade. Uma chave proveniente de um aviso não verificado no browser ou de um scan de rede arbitrário não deve ser aceite sem verificação.

O primeiro comando apresenta a Host Key ED25519 pública que é inserida no bookmark em Public host key. O segundo comando apresenta apenas o fingerprint para a comparação documentada; o fingerprint não é copiado para o campo em vez da chave.

Em seguida, cria-se o bookmark SSH completo:

Em Name, introduzir, por exemplo, SSH-Linux-Test.
Em Type, selecionar SSH.
Em URL, introduzir srv-linux01.intern.example e utilizar a porta 22.
Em Username, definir clientless-test ou o utilizador de destino previsto.
Manter Automatic login desativado se o utilizador tiver de introduzir a palavra-passe do destino.
Inserir em Public host key a Host Key pública verificada diretamente no sistema de destino.
Manter Share session desativado e guardar com Save.
Adicionar o bookmark à Clientless Policy em Published bookmarks e guardar com Apply.
No VPN Portal, clicar em Connect em VPN > Clientless access connections, introduzir a palavra-passe do destino e verificar se aparece o Terminal Prompt esperado. Em seguida, terminar corretamente a sessão SSH.

Sem Automatic login, o utilizador introduz a palavra-passe do destino ao estabelecer a ligação; o nome de utilizador continua a fazer parte do bookmark. Por conseguinte, nomes de utilizador SSH pessoais diferentes exigem bookmarks separados ou outro caminho de acesso. Com Automatic login, o SFOS pode utilizar uma palavra-passe ou Private Key. Private Keys privilegiadas ou amplamente utilizadas não devem ser guardadas num bookmark publicado de forma partilhada.

Outros tipos de bookmark

O SFOS 22 também documenta:

VNC para acesso gráfico a sistemas Linux ou UNIX configurados para esse fim.
FTP, FTPS, SFTP e SMB para acesso a servidores de ficheiros no browser. Não é criada uma unidade de rede normal. Para dados confidenciais, SFTP ou FTPS são preferíveis ao FTP sem encriptação.
Telnet como tipo de terminal. Como o Telnet não encripta o transporte, não deve ser utilizado para novos acessos.

Os bookmarks HTTP e HTTPS não fazem parte dos tipos Clientless atualmente documentados para o SFOS 22. Para aplicações Web internas, a Web Application Firewall ou ZTNA são a arquitetura mais adequada, consoante os requisitos de proteção.

Diagnosticar erros típicos

VPN Portal não está acessível: Verificar o registo DNS público, a porta, o NAT a montante, Administration > Device access e um possível efeito de Port Sharing.
O início de sessão no portal falha: Em Authentication > Services, verificar a autenticação do VPN Portal, bem como o estado do utilizador, MFA e access_server.log.
Clientless access connections não aparece: O utilizador não está atribuído a uma Clientless Policy ou a policy não publica nenhum bookmark.
O bookmark aparece para o utilizador errado: Verificar Policy members, associações a grupos e Published bookmarks. Quando existem vários grupos correspondentes, Clientless SSL VPN pode combinar as permissões das respetivas policies. Os bookmarks que um utilizador real vê desta forma têm de fazer parte do teste positivo e negativo.
O bookmark abre, mas o destino continua inacessível: Verificar a resolução DNS do ponto de vista da firewall, o endereço estático do destino, routing, a porta de destino, o estado do serviço e a firewall do host.
O início de sessão no VPN Portal funciona, mas o do Windows não: A autenticação no portal e no destino são independentes. Verificar o domínio, a conta de destino, a palavra-passe e TLS ou NLA.
NLA ativa Automatic login: Este é o comportamento documentado. Não desativar NLA sem planeamento; reavaliar o modelo de conta e de acesso.
SSH apresenta uma Host Key diferente: Parar a ligação e verificar a alteração diretamente no sistema de destino ou junto do operador responsável. Uma chave inesperada pode indicar uma reinstalação, um destino incorreto ou um ataque.

Em Diagnostics > Tools > Troubleshooting logs, diferentes ficheiros ajudam em fases distintas:

vpnportal.log para o VPN Portal;
access_server.log para autenticação e autorização;
clientless_access.log para ligações Clientless e o estabelecimento da ligação ao destino;
oauth_sso_vpn.log para inícios de sessão no VPN Portal com SSO.

Devem ser documentados em conjunto a hora do teste, o utilizador, o bookmark e o destino. Assim, é possível distinguir nos logs os problemas do portal, de identidade e do destino. A atribuição geral dos logs e o acesso através da Advanced Shell encontram-se em Logs de serviços da Sophos Firewall.

Operação e limitações RDP conhecidas

As Clientless Policies devem ser verificadas regularmente, tal como outras autorizações de Remote Access. Devem ser removidos utilizadores, bookmarks e contas de destino que já não sejam necessários. As palavras-passe ou Private Keys guardadas devem ter um owner, uma data de validade e um processo de rotação. Automatic login e Share session devem fazer parte de todas as revisões de permissões.

No RDP existem duas limitações atuais que não devem ser tratadas como erros de configuração:

A área de transferência não é suportada em bookmarks Clientless RDP desde o SFOS 19. Por conseguinte, copy-and-paste entre o dispositivo local e a sessão RDP não é um método de trabalho fiável.
O ponteiro do rato pode aparecer na sessão RDP HTML5 como uma cruz ou X em vez da seta normal. Atualmente, a Sophos não indica uma solução alternativa.

Se forem indispensáveis a área de transferência, funções RDP nativas, um acesso de rede mais amplo ou contas pessoais num servidor que exige NLA sem credenciais guardadas, Clientless SSL VPN não é o atalho adequado. Nesse caso, o acesso deve ser transferido deliberadamente para Sophos Connect, RD Gateway, PAM, um Jump Host ou ZTNA.