Acceso Remoto Seguro: SSH, RDP y VPN

Acceso Remoto Seguro: SSH, RDP, VPN y Zero Trust — La Guía para Amplificar tu Seguridad

Por qué dejar el puerto 3389 abierto en internet es el equivalente digital de dejar la llave de casa debajo del felpudo — y qué hacer en su lugar.

Introducción

En algún momento de los últimos cinco años, tu empresa necesitó que alguien accediera a un servidor, a un escritorio o a una red interna desde fuera de la oficina. La pandemia aceleró todo esto de forma brutal: servicios que antes quedaban dentro de cuatro paredes se vieron expuestos a internet de la noche a la mañana. Muchas veces sin revisión de seguridad, sin MFA, sin logs adecuados.

¿El resultado? El acceso remoto es hoy uno de los principales vectores de invasión y ransomware en el mundo. Prácticamente todo gran incidente de ransomware de los últimos años comenzó con una de tres cosas: phishing, vulnerabilidad web, o acceso remoto expuesto y mal protegido. RDP expuesto en el puerto 3389 es tan común como vector inicial que varios grupos de ransomware tienen "scanners de RDP" como herramienta estándar.

Esta guía cubre:

1. SSH, RDP, VNC, Telnet — qué hace cada uno, los riesgos de exponer, y cómo proteger
2. VPN tradicional — IPsec, OpenVPN, WireGuard — cuándo tiene sentido, cuándo ya no
3. Zero Trust y ZTNA — qué es, por qué reemplaza a VPN en muchos casos
4. Cloudflare One, Tailscale, Twingate, Zscaler — comparativo práctico
5. Riesgos específicos de cada exposición — con escenarios reales
6. Recomendaciones prácticas — qué hacer para dormir tranquilo

Parte 1: Los protocolos clásicos de acceso remoto

1.1 RDP (Remote Desktop Protocol) — puerto 3389

RDP es el protocolo propietario de Microsoft para acceso gráfico a máquinas Windows. Es extremadamente popular porque viene instalado por defecto en todas las versiones Server y Pro de Windows, y la experiencia es casi nativa.

Qué pasa cuando expones el puerto 3389 en internet:

En las primeras 24 horas después de abrir un puerto 3389 en una IP pública, recibirá miles de intentos de conexión. Existen botnets dedicadas exclusivamente a barrer internet buscando RDP expuesto.

Los ataques contra RDP expuesto incluyen:

• Fuerza bruta de credenciales — bots intentan combinaciones de Administrator, admin, user, test con contraseñas comunes
• Credential stuffing — usan listas de contraseñas filtradas en otros servicios
• Explotación de CVEs — BlueKeep (CVE-2019-0708) permitía ejecución remota de código sin autenticación
• Ataques NLA bypass — algunas configuraciones aceptan negociar protocolos antiguos vulnerables

Estadística que asusta: según reportes de varias aseguradoras cibernéticas y empresas de DFIR, RDP expuesto es el vector inicial en algo entre 40% y 60% de los casos de ransomware investigados.

Cómo proteger si necesitas RDP:

La regla número uno: nunca, bajo ninguna circunstancia, expongas RDP directamente en internet.

Si necesitas RDP, usa:

1. VPN corporativa — el usuario se conecta primero a la VPN, luego accede a RDP por la IP interna
2. RD Gateway — solución nativa de Microsoft que hace que RDP viaje dentro de HTTPS en el puerto 443
3. Bastion host — máquina intermediaria (Azure Bastion, AWS Session Manager)
4. ZTNA — Zero Trust Network Access (veremos en la Parte 3)

Siempre con:

• MFA obligatorio
• Network Level Authentication (NLA) habilitado
• Account lockout después de X intentos fallidos
• Logs centralizados
• Parches al día

1.2 SSH (Secure Shell) — puerto 22

SSH es el protocolo estándar para acceso remoto a servidores Linux/Unix. Fue creado en 1995 para reemplazar Telnet.

Qué pasa cuando expones el puerto 22:

Igual que RDP en volumen. Bots intentan credenciales — root, admin, ubuntu, pi, oracle, git. La diferencia es que SSH bien configurado es mucho más resistente que RDP, porque permite autenticación por clave criptográfica.

Cómo proteger SSH:

# /etc/ssh/sshd_config — configuración 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

Y fail2ban:

sudo apt install fail2ban

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

Otros consejos:

1. Cambia el puerto por defecto. No es seguridad real, pero reduce ruido en los logs drásticamente.
2. Usa claves ED25519: ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519
3. Considera FIDO2: ssh-keygen -t ed25519-sk -f ~/.ssh/ided25519sk
4. SSH bastion en ambientes más grandes
5. NUNCA expongas SSH con contraseña a internet

1.3 VNC — puerto 5900

VNC tiene un histórico de seguridad catastrófico:

• Algunas versiones antiguas aceptaban conexión sin autenticación
• Contraseñas débiles por diseño (límite de 8 caracteres en el clásico)
• Sin criptografía por defecto en muchas implementaciones
• CVEs frecuentes de RCE

Resumiendo: no uses VNC expuesto en internet.

Alternativas:

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

1.4 Telnet — puerto 23

Texto plano. Sin criptografía. Sin autenticación fuerte. Todo en claro.

Botnets como Mirai se especializaron en encontrar Telnet expuesto en cámaras IP, routers y DVRs con credenciales por defecto. Mirai derribó Twitter, GitHub, Reddit y Spotify en 2016 usando esta botnet.

Desactiva hoy:

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

1.5 Otros protocolos peligrosos cuando están expuestos

• FTP (21) — texto plano. Usa SFTP o FTPS
• SMB/CIFS (445) — vector de WannaCry. Nunca expongas
• SNMP v1/v2c (161) — community strings en texto plano
• MySQL/PostgreSQL/MongoDB/Redis — bases de datos nunca deben estar expuestas
• VNC sobre HTTP (5800) — mismos problemas que VNC
• Webmin (10000), cPanel (2083), Plesk (8443) — restringe por IP o ZTNA

Parte 2: VPN tradicional

2.1 Los principales protocolos

IPsec — veterano, estándar de la industria, configuración compleja, problemas con NAT.

OpenVPN — open-source maduro, flexible, performance limitado (single-threaded).

WireGuard — nueva generación, ~4.000 líneas de código, criptografía moderna fija, performance excepcional.

PPTP — roto criptográficamente desde 2012. Nunca lo uses.

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

2.2 Qué puede salir mal con VPN

El concentrador VPN es el objetivo. Vulnerabilidades graves en los últimos años:

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

El acceso es binario. ¿Conectado? Acceso a la red entera. Movimiento lateral fácil.

Performance pobre en escala global. Backhaul al concentrador.

MFA frecuentemente opcional o mal implementado.

Visibilidad limitada sobre qué accedió el usuario dentro de la red.

2.3 Cuándo VPN aún tiene sentido

• Site-to-site (conectar dos redes completas) — IPsec aún es rey
• Equipamiento legado sin autenticación moderna
• Compliance que requiere VPN tradicional
• Ambientes pequeños, baja criticidad
• Presupuesto cero (WireGuard self-hosted es gratis)

Parte 3: Zero Trust y ZTNA

3.1 El concepto

La frase: "nunca confíes, verifica siempre" — never trust, always verify.

El modelo tradicional era "castillo": muros, puertas, dentro todo mundo es confiable. Zero Trust invierte:

1. No confíes en nadie por defecto (interno o externo)
2. Verifica siempre — toda requisición autenticada y autorizada
3. Privilegio mínimo — solo lo que necesitas
4. Asume que hubo breach
5. Visibilidad total — todo acceso registrado y analizado

3.2 ZTNA — Zero Trust Network Access

Mientras VPN te conecta a la red entera, ZTNA te conecta a aplicaciones específicas, después de validar quién eres, en qué dispositivo, en qué contexto.

Cómo funciona:

1. Usuario intenta acceder a una aplicación
2. ZTNA intercepta la requisición
3. Verifica: ¿usuario autenticado? ¿Dispositivo OK? ¿Horario OK? ¿IP OK? ¿Permiso para esa app?
4. Si todo encaja, libera acceso solo para esa aplicación
5. Si algo está mal, bloquea o pide MFA

El usuario nunca tiene acceso a la red, solo a la aplicación. La aplicación no está expuesta en internet. El conector ZTNA corre dentro de la red y hace conexión saliente al proveedor.

3.3 Los principales jugadores

Cloudflare One (Cloudflare Access + Tunnel)

• Plan gratuito robusto
• Se integra con Google, Microsoft, Okta, GitHub
• Performance excelente — PoPs en centenas de ciudades
• Funciona para HTTP, SSH, RDP, VNC

Tailscale

• Construido sobre WireGuard
• Setup absurdamente fácil
• Plan gratuito generoso
• Performance P2P excelente
• Open-source en su mayoría

Twingate

• ZTNA "puro" desde el diseño
• Buena integración con AD/Okta
• Granularidad fina
• Plan gratuito para uso pequeño

Zscaler Private Access (ZPA)

• Enterprise robusto
• Compliance y certificaciones
• Caro y complejo
• Excesivo para empresas pequeñas

Microsoft Entra Private Access

• Integración nativa con todo Microsoft
• Licenciado dentro de M365
• Conditional Access poderoso

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

3.4 Comparativo VPN vs ZTNA

| Aspecto | VPN tradicional | ZTNA moderno | |---|---|---| | Acceso | Red entera | Aplicaciones específicas | | Exposición en internet | Concentrador expuesto | Ningún puerto abierto | | Movimiento lateral | Fácil | Drásticamente difícil | | Granularidad | Por usuario/grupo | Por usuario + dispositivo + contexto + app | | Visibilidad | Conexión de VPN | Cada acceso a cada app | | Performance global | Backhaul | PoP más cercano | | Setup | Complejo | Generalmente simple | | Costo entrada | Puede ser cero (self-hosted) | Puede comenzar gratis |

Parte 4: Riesgos consolidados

| Servicio | Puerto | Riesgo si está expuesto | Qué hacer | |---|---|---|---| | RDP | 3389 | Crítico. Vector #1 ransomware | Nunca exponer. VPN/RD Gateway/bastion/ZTNA | | SSH con contraseña | 22 | Alto. Fuerza bruta | Desactiva contraseña. Usa claves ED25519 | | SSH con clave | 22 | Bajo si está actualizado | Hardening + fail2ban + monitoreo | | VNC | 5900 | Crítico. Histórico catastrófico | Nunca exponer. Usa túnel SSH/ZTNA | | Telnet | 23 | Crítico. Texto plano | Desactiva. Usa SSH | | FTP | 21 | Alto. Texto plano | SFTP o FTPS | | SMB | 445 | Crítico. Vector WannaCry | Nunca exponer | | SNMP v1/v2c | 161 | Alto. Community en texto plano | SNMPv3, nunca exponer | | Bases de datos | varios | Crítico. Extorsión y robo | Nunca exponer. Firewall + auth fuerte | | Paneles admin | varios | Alto. CVEs RCE | IP whitelist o ZTNA | | Concentrador VPN | varía | Alto. Objetivo prioritario | Parches + MFA + monitoreo |

Parte 5: Recomendaciones prácticas

1. Haz un inventario de qué está expuesto. No puedes proteger lo que no sabes que existe.

2. Mapea qué debería estar haciendo cada puerto. Para cada servicio: ¿necesita estar expuesto? ¿Por qué? ¿Quién lo usa? ¿Cuándo fue la última revisión?

3. Cierra todo lo que no necesita estar abierto. Inmediatamente.

4. Para todo lo que necesita acceso remoto, nunca expongas el servicio directamente. En orden:

• ZTNA (primera opción)
• VPN moderna (WireGuard)
• VPN tradicional (IPsec/OpenVPN)
• Bastion host con SSH

5. Activa MFA en todo. Sin excepciones.

6. Mantén todo actualizado. Parches críticos en hasta 48 horas.

7. Monitorea continuamente. Las exposiciones reaparecen.

8. Logs centralizados. Intentos fallidos, IPs extrañas, horarios atípicos.

9. Revisiones periódicas trimestrales como mínimo.

10. Entrena a los usuarios. La ingeniería social bypasea MFA.

Consideraciones finales

La diferencia entre una empresa con hardening adecuado de acceso remoto y una sin él es, frecuentemente, la diferencia entre estar en los periódicos por algo bueno (lanzamiento de producto) o por algo malo (ataque de ransomware con parálisis de una semana).

La buena noticia: herramientas modernas — especialmente ZTNA — han hecho que hacer lo correcto sea más fácil y barato que continuar haciendo lo incorrecto. Cloudflare One, Tailscale y Twingate tienen planes gratuitos. WireGuard es gratis. SSH con claves ED25519 es gratis. No hacer nada sale más caro.

El peor escenario no es el ataque sofisticado. Es el ataque molesto: bot haciendo fuerza bruta en RDP expuesto, encontrando contraseña débil, instalando ransomware, cifrando todo. No es atacante de película. Es script automatizado corriendo hace meses, esperando que alguien deje la puerta entreabierta.

SentinelHub barre exactamente ese tipo de exposición: monitorea tus IPs públicas, identifica puertos y servicios expuestos, alerta cuando algo nuevo aparece, cruza con bases de CVE para ver si la versión tiene vulnerabilidad conocida, y traduce todo al español para que no necesites andar adivinando.

¿Te pareció útil? Comparte con el equipo de TI de tu empresa. Si aún tienen RDP expuesto en internet, especialmente comparte.