Sem Agente · Sem Instalação

Acesso remoto seguro: SSH, RDP, VPN e Zero Trust

Acesso Remoto Seguro: SSH, RDP, VPN e Zero Trust — O Guia para Amplificar sua Segurança Por que deixar a porta 3389 aberta na internet é o equivalente digital de deixar a chave de casa embaixo do tapete — e o que fazer no lugar disso.

Acesso Remoto Seguro: SSH, RDP, VPN e Zero Trust — O Guia para Amplificar sua Segurança

Por que deixar a porta 3389 aberta na internet é o equivalente digital de deixar a chave de casa embaixo do tapete — e o que fazer no lugar disso.

Introdução

Em algum momento dos últimos cinco anos, sua empresa precisou que alguém acessasse um servidor, um desktop ou uma rede interna de fora do escritório. A pandemia acelerou tudo isso de forma brutal: serviços que antes ficavam dentro de quatro paredes viraram, da noite pro dia, expostos à internet. Muitas vezes sem revisão de segurança, sem MFA, sem logs adequados.

O resultado? Acesso remoto é hoje um dos principais vetores de invasão e ransomware no mundo. Praticamente todo grande incidente de ransomware dos últimos anos começou com uma das três coisas: phishing, vulnerabilidade web, ou acesso remoto exposto e mal protegido. RDP exposto na porta 3389 é tão comum como vetor inicial que vários grupos de ransomware têm "scanners de RDP" como ferramenta padrão.

Este guia cobre:

  1. SSH, RDP, VNC, Telnet — o que cada um faz, os riscos de expor, e como proteger
  2. VPN tradicional — IPsec, OpenVPN, WireGuard — quando faz sentido, quando não faz mais
  3. Zero Trust e ZTNA — o que é, por que substitui VPN em muitos casos
  4. Cloudflare One, Tailscale, Twingate, Zscaler — comparativo prático
  5. Riscos específicos de cada exposição — com cenários reais
  6. Recomendações práticas — o que fazer pra dormir tranquilo

Parte 1: Os protocolos clássicos de acesso remoto

1.1 RDP (Remote Desktop Protocol) — porta 3389

O RDP é o protocolo proprietário da Microsoft para acesso gráfico a máquinas Windows. É extremamente popular porque vem instalado por padrão em todas as versões Server e Pro do Windows, e a experiência é quase nativa.

O que acontece quando você expõe a porta 3389 na internet:

Nas primeiras 24 horas após você abrir uma porta 3389 num IP público, ela vai receber milhares de tentativas de conexão. Existem botnets dedicadas exclusivamente a varrer a internet procurando RDP exposto.

Os ataques contra RDP exposto incluem:

  • Brute force de credenciais — bots tentam combinações de Administrator, admin, user, test com senhas comuns
  • Credential stuffing — usam listas de senhas vazadas em outros serviços
  • Exploração de CVEs — BlueKeep (CVE-2019-0708) permitia execução remota de código sem autenticação
  • Ataques NLA bypass — algumas configurações aceitam negociar protocolos antigos vulneráveis

Estatística que assusta: segundo relatórios de várias seguradoras de cyber e empresas de DFIR, RDP exposto é o vetor inicial em algo entre 40% e 60% dos casos de ransomware investigados.

Como proteger se você precisa de RDP:

A regra número um: nunca, em hipótese alguma, exponha RDP diretamente na internet.

Se você precisa de RDP, use:

  1. VPN corporativa — usuário conecta primeiro na VPN, depois acessa RDP pelo IP interno
  2. RD Gateway — solução nativa Microsoft que faz RDP trafegar dentro de HTTPS na porta 443
  3. Bastion host — máquina intermediária (Azure Bastion, AWS Session Manager)
  4. ZTNA — Zero Trust Network Access (veremos na Parte 3)

Sempre com:

  • MFA obrigatório
  • Network Level Authentication (NLA) habilitado
  • Account lockout após X tentativas falhas
  • Logs centralizados
  • Patches em dia

1.2 SSH (Secure Shell) — porta 22

O SSH é o protocolo padrão pra acesso remoto a servidores Linux/Unix. Foi criado em 1995 para substituir Telnet.

O que acontece quando você expõe a porta 22:

Igual ao RDP em volume. Bots tentam credenciais — root, admin, ubuntu, pi, oracle, git. A diferença é que SSH bem configurado é muito mais resistente que RDP, porque permite autenticação por chave criptográfica.

Como proteger SSH:

# /etc/ssh/sshd_config — configuração mínima recomendada

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes
PubkeyAuthentication yes
Protocol 2

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

AllowUsers seuusuario

X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

LogLevel VERBOSE
SyslogFacility AUTH

E fail2ban:

sudo apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 22
maxretry = 3
findtime = 600
bantime = 86400

Outras dicas:

  1. Mude a porta padrão. Não é segurança real, mas reduz ruído nos logs drasticamente.
  2. Use chaves ED25519: ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519
  3. Considere FIDO2: ssh-keygen -t ed25519-sk -f ~/.ssh/ided25519sk
  4. SSH bastion em ambientes maiores
  5. NUNCA exponha SSH com senha pra internet

1.3 VNC — porta 5900

O VNC tem um histórico de segurança catastrófico:

  • Algumas versões antigas aceitavam conexão sem autenticação
  • Senhas fracas por design (limite de 8 caracteres no clássico)
  • Sem criptografia por padrão em muitas implementações
  • CVEs frequentes de RCE

Resumindo: não use VNC exposto na internet.

Alternativas:

  1. SSH com X11 forwarding (ssh -X)
  2. VNC dentro de túnel SSH (ssh -L 5900:localhost:5900 user@servidor)
  3. NoMachine ou xrdp
  4. VPN ou ZTNA na frente

1.4 Telnet — porta 23

Texto puro. Sem criptografia. Sem autenticação forte. Tudo em claro.

Botnets como Mirai se especializaram em encontrar Telnet exposto em câmeras IP, roteadores e DVRs com credenciais padrão. O Mirai derrubou Twitter, GitHub, Reddit e Spotify em 2016 usando essa botnet.

Desabilite hoje:

sudo systemctl status telnet.socket
sudo systemctl disable telnet.socket
sudo systemctl stop telnet.socket
sudo apt remove telnetd

1.5 Outros protocolos perigosos quando expostos

  • FTP (21) — texto puro. Use SFTP ou FTPS
  • SMB/CIFS (445) — vetor do WannaCry. Nunca exponha
  • SNMP v1/v2c (161) — community strings em texto puro
  • MySQL/PostgreSQL/MongoDB/Redis — bancos nunca devem estar expostos
  • VNC sobre HTTP (5800) — mesmos problemas do VNC
  • Webmin (10000), cPanel (2083), Plesk (8443) — restrinja por IP ou ZTNA

Parte 2: VPN tradicional

2.1 Os principais protocolos

IPsec — veterano, padrão da indústria, configuração complexa, problemas com NAT.

OpenVPN — open-source maduro, flexível, performance limitada (single-threaded).

WireGuard — nova geração, ~4.000 linhas de código, criptografia moderna fixa, performance excepcional.

PPTP — quebrado criptograficamente desde 2012. Não use jamais.

L2TP/IPsec, SSTP — legados, casos muito específicos.

2.2 O que pode dar errado com VPN

O concentrador VPN é o alvo. Vulnerabilidades graves nos últimos anos:

  • Pulse Secure (CVE-2019-11510)
  • Fortinet FortiGate (CVE-2018-13379)
  • Citrix ADC (CVE-2019-19781)

Acesso é binário. Conectou? Acesso à rede inteira. Movimento lateral fica fácil.

Performance ruim em escala global. Backhaul ao concentrador.

MFA frequentemente opcional ou mal implementado.

Visibilidade limitada sobre o que o usuário acessou dentro da rede.

2.3 Quando VPN ainda faz sentido

  • Site-to-site (conectar duas redes inteiras) — IPsec ainda é rei
  • Equipamento legado sem autenticação moderna
  • Compliance que exige VPN tradicional
  • Ambientes pequenos, baixa criticidade
  • Budget zero (WireGuard self-hosted é grátis)

Parte 3: Zero Trust e ZTNA

3.1 O conceito

A frase: "never trust, always verify" — nunca confie, sempre verifique.

O modelo tradicional era "castelo": muros, portões, dentro todo mundo é confiável. Zero Trust inverte:

  1. Não confie em ninguém por padrão (interna ou externa)
  2. Verifique sempre — toda requisição autenticada e autorizada
  3. Privilégio mínimo — só o que precisa
  4. Assuma que houve breach
  5. Visibilidade total — todo acesso logado e analisado

3.2 ZTNA — Zero Trust Network Access

Enquanto VPN te conecta à rede inteira, ZTNA te conecta a aplicações específicas, depois de validar quem você é, em qual dispositivo, em qual contexto.

Como funciona:

  1. Usuário tenta acessar uma aplicação
  2. ZTNA intercepta a requisição
  3. Verifica: usuário autenticado? Dispositivo OK? Horário OK? IP OK? Permissão pra essa app?
  4. Se tudo bate, libera acesso só pra essa aplicação
  5. Se algo está errado, bloqueia ou pede MFA

O usuário nunca tem acesso à rede, só à aplicação. A aplicação não fica exposta na internet. O conector ZTNA roda dentro da rede e faz conexão saída pro provedor.

3.3 Os principais players

Cloudflare One (Cloudflare Access + Tunnel)

  • Plano gratuito robusto
  • Integra com Google, Microsoft, Okta, GitHub
  • Performance excelente — PoPs em centenas de cidades
  • Funciona pra HTTP, SSH, RDP, VNC

Tailscale

  • Construído sobre WireGuard
  • Setup absurdamente fácil
  • Plano gratuito generoso
  • Performance P2P excelente
  • Open-source na maior parte

Twingate

  • ZTNA "puro" desde o desenho
  • Boa integração com AD/Okta
  • Granularidade fina
  • Plano gratuito pra uso pequeno

Zscaler Private Access (ZPA)

  • Enterprise robusto
  • Compliance e certificações
  • Caro e complexo
  • Overkill pra empresas pequenas

Microsoft Entra Private Access

  • Integração nativa com tudo Microsoft
  • Licenciado dentro de M365
  • Conditional Access poderoso

Outras: Perimeter 81/Check Point Harmony, NetSkope, Palo Alto Prisma, Cato Networks.

3.4 Comparativo VPN vs ZTNA

| Aspecto | VPN tradicional | ZTNA moderno | |---|---|---| | Acesso | Rede inteira | Aplicações específicas | | Exposição na internet | Concentrador exposto | Nenhuma porta aberta | | Movimento lateral | Fácil | Drasticamente difícil | | Granularidade | Por usuário/grupo | Por usuário + dispositivo + contexto + app | | Visibilidade | Conexão da VPN | Cada acesso a cada app | | Performance global | Backhaul | PoP mais próximo | | Setup | Complexo | Geralmente simples | | Custo entrada | Pode ser zero (self-hosted) | Pode começar grátis |

Parte 4: Riscos consolidados

| Serviço | Porta | Risco se exposto | O que fazer | |---|---|---|---| | RDP | 3389 | Crítico. Vetor #1 ransomware | Nunca expor. VPN/RD Gateway/bastion/ZTNA | | SSH com senha | 22 | Alto. Brute force | Desabilite senha. Use chaves ED25519 | | SSH com chave | 22 | Baixo se atualizado | Hardening + fail2ban + monitoramento | | VNC | 5900 | Crítico. Histórico catastrófico | Nunca expor. Use SSH tunnel/ZTNA | | Telnet | 23 | Crítico. Texto puro | Desabilite. Use SSH | | FTP | 21 | Alto. Texto puro | SFTP ou FTPS | | SMB | 445 | Crítico. WannaCry vector | Nunca expor | | SNMP v1/v2c | 161 | Alto. Community em texto puro | SNMPv3, nunca expor | | Bancos de dados | vários | Crítico. Extorsão e roubo | Nunca expor. Firewall + auth forte | | Painéis admin | vários | Alto. CVEs RCE | IP whitelist ou ZTNA | | VPN concentrador | varia | Alto. Alvo prioritário | Patches + MFA + monitoramento |

Parte 5: Recomendações práticas

1. Faça um inventário do que está exposto. Você não pode proteger o que não sabe que existe.

2. Mapeie o que cada porta deveria estar fazendo. Pra cada serviço: precisa estar exposto? Por quê? Quem usa? Quando foi a última revisão?

3. Feche tudo o que não precisa estar aberto. Imediatamente.

4. Pra tudo que precisa de acesso remoto, nunca exponha o serviço diretamente. Em ordem:

  • ZTNA (primeira escolha)
  • VPN moderna (WireGuard)
  • VPN tradicional (IPsec/OpenVPN)
  • Bastion host com SSH

5. Habilite MFA em tudo. Sem exceções.

6. Mantenha tudo atualizado. Patches críticos em até 48 horas.

7. Monitore continuamente. Exposições reaparecem.

8. Logs centralizados. Tentativas falhas, IPs estranhos, horários atípicos.

9. Revisões periódicas trimestrais no mínimo.

10. Treine os usuários. Engenharia social bypassa MFA.

Considerações finais

A diferença entre uma empresa com hardening adequado de acesso remoto e uma sem é, frequentemente, a diferença entre estar nos jornais por algo bom (lançamento de produto) ou por algo ruim (ataque de ransomware com paralisação de uma semana).

A boa notícia: ferramentas modernas — especialmente ZTNA — tornaram fazer a coisa certa mais fácil e barato que continuar fazendo a coisa errada. Cloudflare One, Tailscale e Twingate têm planos gratuitos. WireGuard é gratuito. SSH com chaves ED25519 é gratuito. Não fazer nada sai mais caro.

O pior cenário não é o ataque sofisticado. É o ataque chato: bot brute-forçando RDP exposto, encontrando senha fraca, instalando ransomware, criptografando tudo. Não é atacante de filme. É script automatizado rodando há meses, esperando alguém deixar a porta entreaberta.

O SentinelHub varre exatamente esse tipo de exposição: monitora seus IPs públicos, identifica portas e serviços expostos, alerta quando algo novo aparece, cruza com bases de CVE pra ver se a versão tem vulnerabilidade conhecida, e traduz tudo pra português pra você não precisar ficar adivinhando.

Achou útil? Compartilha com o time de TI da sua empresa. Se eles ainda têm RDP exposto na internet, especialmente compartilha.