El pasado martes de parches, Microsoft lanzó la actualización de seguridad MS12-020 para cerrar dos fallos recientemente descubiertos en la implementación de RDP (Remote Desktop Protocol) de Microsoft. Uno de ellos, Microsoft lo califica de «crítico» porque podría permitir a los hackers obtener el control de LocalSystem en un equipo Windows con RDP activado.
Como probablemente ya habrá oído, se trata de una situación de alto riesgo, que podría dar lugar a una epidemia tan grave como la causada por Code Red, Melissa o SQL Slammer. Parche o remedio ahora!
Microsoft le ayudará a hacer ambas cosas. Puede instalar el parche o ejecutar un script Fix It en línea para mitigar el problema hasta que se aplique el parche. El script habilita la autenticación a nivel de red, que requiere autenticación antes de que un sistema remoto pueda conectarse.
Pero tengo otro consejo. Como vengo recomendando desde hace más de una década, los administradores deberían considerar la posibilidad de ejecutar servicios conectables a Internet en puertos no predeterminados si es posible. En este caso particular, RDP debería ejecutarse en algún otro puerto que no sea el 3389.
Este consejo se extiende a otras áreas. Los sitios web de administración no deben ejecutarse en el puerto 80 o incluso 443. SSH no debería estar escuchando en el puerto 22. Los hosts de Telnet no deberían estar escuchando en el puerto 23. El único servicio común generalizado que no he podido conseguir que funcione de forma fiable en un puerto no predeterminado es FTP: utiliza los puertos 21 y 22 (en modo pasivo), e incluso su modo activo (donde se pueden indicar otros puertos) no funciona bien a través de los cortafuegos.
En el caso de RDP, puede cambiar el puerto predeterminado siguiendo esta guía. Sin embargo, cuando se cambia el puerto por defecto, hay que indicar el puerto no predeterminado en la cadena de conexión (por ejemplo, mstsc.exe 192.168.1.12:50045).
Mi recomendación de cambiar el puerto de escucha por defecto en un servicio empresarial suele recibir críticas. Mi argumento central es el siguiente: En la mayoría de los casos, una empresa puede cambiar el puerto de escucha por defecto, lo que no causa ningún problema más allá de la educación de los administradores y la reconfiguración de una sola vez de algunos scripts y herramientas, y disminuye significativamente el riesgo de un ataque armado.
Aunque los hackers y el malware pueden utilizar un escáner de puertos como Nmap para encontrar el nuevo puerto, ningún exploit armado ha hecho nunca un escaneo de puertos, aunque fácilmente podrían. Este hecho por sí solo le da mucha protección.
Algunas personas llaman a este tipo de recomendación «seguridad por oscuridad», como si fuera algo malo. En mi opinión, la seguridad por oscuridad es una de las mejores defensas. De lo contrario, cada nación publicaría dónde están sus misiles y submarinos nucleares en lugar de mantener la información en secreto.
Para mí, el gusano SQL Slammer es uno de los mejores argumentos para poner servicios comunes en puertos no predeterminados. Lanzado en 2003, explotó casi todos los servidores SQL posibles sin parches y sin protección conectados a Internet en 10 minutos. Se activó un domingo por la mañana temprano, y para cuando la mayoría de los administradores se despertaron, los daños ya se habían producido durante casi un día completo de trabajo.
Básicamente, para cuando nos habíamos limpiado la costra de sal de los ojos, ya se había acabado – y luego pasamos las siguientes 48 horas (o más) tratando de limpiar el desastre. Fue una llamada de atención.
Nadie que hubiera habilitado SQL en un puerto no predeterminado (es decir, un puerto aparte del 1433 y el 1434) tuvo que hacer nada — aparte de observar tranquilamente a todos los demás lidiar con sus desastres. Los que cambiaron de puerto no tuvieron que limpiar un gran lío. No tuvieron que apresurarse a sacar parches. No tenían servidores explotados. Un cambio con un impacto operativo mínimo y pudieron evitar toneladas de riesgo.
Ciertamente otras mitigaciones funcionan igual de bien, como requerir una conexión VPN válida antes de conectarse al servicio, requerir una combinación de contactos de puerto previos antes de habilitar el servicio, o requerir una autenticación exitosa antes de que el servicio responda (esta es la solución Fix It de Microsoft), y cualquier otra cosa que pueda protegerte contra ataques armados.
Pero no se me ocurre ninguna otra solución de seguridad sencilla que disminuya el riesgo de forma tan eficaz como cambiar el puerto por defecto, cuando sea posible. Si sigues este consejo, mueve el puerto a un número bastante alto, por encima de 10.000 o 12.000, para evitar posibles conflictos de puertos con otros servicios existentes. Pruebe todo el equipo de producción y actualice los cortafuegos o proxies necesarios. Los lectores que siguieron este consejo en el pasado no tienen mucha prisa esta semana.