Si bien la necesidad de poder acceder puntualmente de forma remota a ciertos equipos para realizar tareas de gestión no es algo nuevo, la situación de confinamiento actual generada por la crisis del COVID-19 ha provocado el aumento del número de personas que usan herramientas de acceso remoto drásticamente. El protocolo de referencia para sistemas Windows es RDP, el conocido escritorio remoto.
A medida que se ha ido habilitando el acceso remoto a cada vez más y más máquinas Windows durante este periodo de aislamiento, en ocasiones de forma apresurada, han ido creciendo el número de ataques con este protocolo como objetivo, siendo este incremento muy notable durante la segunda quincena de Marzo y manteniéndose en niveles más altos de los habituales durante todo el periodo de confinamiento hasta el momento actual.
Ataques realizados por la familia Bruteforce.Generic.RDP en España. Fuente Kaspersky
Es significativo que en los paises que llevan cierto retraso en términos de afectación de la pandemia como EEUU o Rusia, se observa del mismo modo un cierto retraso en el aumento del número de ataques. Sin más datos que los aquí mostrados es dificil extraer conclusiones, pero no es descabellado pensar que exista algún tipo de correlación entre el número de ataques y el número de máquinas que exponen el puerto RDP. De este modo, a medida que aumentan las medidas de confinamiento y la necesidad de exponer nuevas máquinas, aumentaría el número de ataques.
Ataques realizados por la familia Bruteforce.Generic.RDP a nivel global. Fuente Kaspersky
En el contexto de máquinas virtuales (VM) con sistemas Windows desplegados en Azure, existen diferentes opciones de conexión que comentaremos a continuación. Si bien siempre es necesario minimizar el riesgo de este tipo de conexiones, los datos anteriores sugieren que en esta situación de confinamiento se hace necesario extremar las precauciones.
Recalcar que el contexto propuesto es el acceso puntual a servidores Windows remotos, normalmente para realizar tareas de gestión. Si de lo que se trata es de proporcionar servicios de escritorio virtual estaríamos en otro supuesto, existiendo arquitecturas y herramientas especializadas como RD Gateway.
Es la opción más común, más rápida y menos segura. Consiste en asociar una IP pública a nuestra máquina de modo que sea visible desde internet. Si la máquina tiene asociado un NSG, bien a nivel de NIC, de subred o de ambos, habrá que permitir el tráfico entrante hacia el puerto 3389 usado por el protocolo RDP.
NSG Configuración de las reglas de entrada
Si prestamos atención a la interfaz, Azure nos indica que la regla no es muy aconsejable.
Advertencia asociada a la regla RDP
Las recomendaciones para proteger el acceso RDP a nuestra VM son la mismas que para infraestructuras onpremise, entre otras, maximizar la fortaleza de las contraseñas, autenticación a nivel de red NLA, autenticación de doble factor DFA y sobre todo limitar el acceso a través de una VPN corporativa.
Ahora bien, estamos en la nube, el escenario es diferente, mi máquina no está incluida en la red corporativa ni tengo posibilidad de incluirla, ni siquiera algunos usuarios forman parte del dominio corporativo. ¿Qué podemos hacer? ¿Cuáles son las opciones? Veamos algunas alternativas.
Una de las alternativas más habituales consiste en restringir el acceso RDP de nuestras máquinas, permitiendo sólo el acceso a través de lo que comúnmente se denomina jumpbox o jumpserver.
El uso de jumpbox puede verse en varias arquitecturas de referencia como la topología de red Hub-spoke.
Topología de red Hub-Spoke en Azure
La idea es tener una configuración de red que permita aislar el acceso a las diferentes VMs, dejando únicamente expuesta la máquina jumpbox. En el escenario ideal, el acceso a la jumpbox será a través de VPN, pero es habitual el acceso público a la misma como en la arquitectura de referencia siguiente:
Extensión del dominio AD local a Azure
En realidad en este último escenario en el que el acceso a la jumpbox es público, la máquina estará igualmente expuesta, sin embargo hemos añadido un nivel más de protección: en caso de ataque la máquina comprometida será la ´jumpbox´, no las máquinas asociadas a nuestros workloads. El punto clave es detectar estas situaciones para desencadenar las acciones oportunas, actuando sobre la jumpbox antes de que el ataque prosiga hacia el resto de la infraestructura. En este sentido, Azure cuenta con herramientas como Azure Security Center, que ofrece protección de VM contra ataques de fuerza bruta y malware.
En caso de tener varias máquinas expuestas a través de IP Pública como en el primer escenario, el uso de jumpbox tiene otra serie de ventajas a tener en cuenta:
Una de las maneras de reducir la exposición a un ataque es limitar el tiempo que el puerto RDP está disponible. El puerto 3389 no necesita estar abierto de forma continua, únicamente cuando se necesite una conexión a la máquina.
Cuando habilitamos la opción Just In Time Access en una VM, Azure Security Center bloquea el tráfico entrante a la VM creando una regla en el NSG asociado. Cuando un usuario solicita acceso, Azure Security Center comprueba que dicho usuario tiene permisos RBAC para la VM en cuestión. Sólo en caso de que disponga de los permisos necesarios, Azure Security Center configura NSG y Azure Firewall para permitir el tráfico entrante a los puertos oportunos por un determinado espacio de tiempo. Una vez que el tiempo de acceso permitido expira, Azure Security Center vuelve al estado de partida, bloqueando el acceso a la VM.
Para beneficiarnos de esta opción, la VM deberá estar incluida en un plan de tarifa Estándar de Security Center.
Seguridad mejora en el nivel Standard de Azure Security Center
En este punto, recordar que cuando se eleva el nivel de servicio de Azure Security Center al nivel Estándar, automáticamente se inscriben y protegen todos los recursos, a menos que se indique lo contrario de forma explícita. Los recursos protegidos con Security Center se facturarán conforme al modelo de precios disponible en el portal de Azure.
| TIPO DE RECURSO | NIVEL GRATIS | NIVEL STANDARD |
| Máquina virtual | Gratis | ~€12,313/servidor/mes Datos incluidos - 500 MB/día |
| App Sevices | Gratis | ~€12,313/instancia de App Service/mes |
| SQL Database | No disponible | ~€12,650/servidor/mes |
Precios de Security Center 2020-05
Dependiendo del número de VMs, el coste puede ser importante, por lo que se hace interesante el uso de esta opción junto a la estrategia de jumpbox comentada en el punto anterior.
Una vez configurada la directiva JIT en la VM, será necesario solicitar el acceso desde el portal de Azure antes de conectarnos a la máquina vía escritorio remoto.
JIT Access. Solicitud de Acceso
Recientemente Azure ha incorporado un nuevo recurso llamado Bastion, que vendría a ser un servicio totalmente administrado equivalente a una jumpbox
La particularidad de este recurso es que la implementación se realiza por red virtual, no por suscripción o cuenta, ni por máquina virtual. Una vez que hayamos aprovisionado un servicio Azure Bastion en nuestra red virtual, la experiencia de RDP/SSH estará disponible para todas las máquinas virtuales de la misma red virtual.
Atendiendo a la documentación del recurso, "los servidores de bastión proporcionan conectividad RDP y SSH y están diseñados y configurados para resistir los ataques".
La principal diferencia respecto a las opciones anteriores es que no se requiere ninguna dirección IP pública en las VMs. Una vez configurado el Bastión en la VNET, podremos solicitar el acceso a las máquinas de esa VNET desde el portal de Azure.
Azure Bastion
Las ventajas son evidentes; el hecho de no tener IP pública resuelve el tema de los ataques asociados al protocolo RDP, además de las ventajas asociadas al jumpbox ya comentadas, como disponer de un único punto de monitorización. En este sentido Bastión ofrece la posibilidad de consultar y terminar las sesiones abiertas, así como información de todas las conexiones realizadas, incluyendo datos como IP origen, usuario, tiempo de conexión, etc.
Una peculiaridad del bastión es que no es necesario cliente de escritorio remoto, ya que el acceso se hace a través de cualquier navegador con capacidad HTML5. Esto puede ser una ventaja en algunos casos ya que nos libera de la necesidad de instalar ningún tipo de software cliente para la conexión, pero supone una desventaja en otros escenarios en los que precisamente se hace necesario el uso de dicho cliente por ejemplo para mover datos con unidades mapeadas o funcionalidad de cortar y pegar ficheros (actualmente la aplicación web sólo soporta el corta y pega de texto)
La principal limitación es que en la actualidad no soporta peering, por lo que sólo podremos acceder a las máquinas de la misma VNET, imposibilitando su uso centralizado en topologías tipo Hub & Spoke.
En lo relativo a costes, actualmente el precio ronda los 120€ al mes, a parte del tráfico igress del bastión también facturable.
Si bien podemos proporcionar acceso a nuestras VMs a través de RDP de manera prácticamente inmediata, se hace necesario más que nunca estudiar las diferentes opciones y ventajas e inconvenientes de cada una de ellas.
A medida que se aumentan las medidas de seguridad aumenta el coste asociado a los recursos. Es necesario concienciar a todos los actores con capacidad de decisión de la necesidad de establecer unos mecanismos que proporcionen un acceso seguro. Si bien aumentar las medidas de seguridad tiene un precio, la contrapartida es infinitamente mayor, evitando correr riesgos innecesarios, disgustos e incluso la continuidad del negocio en caso de que nuestra plataforma se vea expuesta.
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
