Les contaremos una interesante historia sobre cómo los 'terceros' intentaron obstaculizar el trabajo de nuestros clientes y cómo se resolvió este problema.
Cómo comenzó todo
Todo comenzó la mañana del 31 de octubre, el último día del mes, cuando muchos necesitaban urgentemente resolver temas importantes.
Uno de los socios, que gestiona varias máquinas virtuales de clientes en nuestra nube, informó que entre las 9:10 y las 9:20, varios servidores Windows que operan en nuestra plataforma de Ucrania no aceptaban conexiones al servicio de acceso remoto, los usuarios no podían ingresar a sus escritorios, pero después de unos minutos, el problema pareció resolverse por sí solo.
Revisamos las estadísticas de funcionamiento de los canales de comunicación y no encontramos ni picos de tráfico ni caídas. Pero al mirar las estadísticas de carga de recursos computacionales, no había anomalías. ¿Qué fue eso?
Luego, otro socio, que aloja casi un centenar de servidores en nuestra nube, informó que algunos de sus clientes enfrentaron problemas similares, aunque se descubrió que, en general, los servidores estaban disponibles (respondían correctamente a pruebas de ping y otras solicitudes), pero el servicio de acceso remoto en esos servidores aceptaba y rechazaba nuevas conexiones de manera intermitente, considerando que se trataba de servidores en diferentes plataformas, cuyo tráfico provenía de diferentes canales de transmisión de datos.
Veamos ese tráfico. Un paquete con una solicitud para establecer conexión llega al servidor:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
El servidor recibe este paquete, pero rechaza la conexión:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
Esto significa que el problema claramente no es causado por fallos en la infraestructura, sino por algo más. ¿Quizás todos los usuarios tuvieron problemas con la licencia de escritorios remotos? ¿O quizás algún malware se infiltró en sus sistemas y hoy se activó, como pasó hace un par de años con XData y Petya?
Mientras investigábamos, recibimos consultas similares de varios otros clientes y socios.
¿Qué está sucediendo en estas máquinas?
En los registros de eventos hay muchos mensajes sobre intentos de adivinar contraseñas:
Normalmente, tales intentos se registran en todos los servidores donde se utiliza el puerto estándar (3389) para el servicio de acceso remoto y se permite el acceso desde cualquier lugar. En Internet hay una gran cantidad de bots que están constantemente escaneando todos los puntos de conexión disponibles y tratando de adivinar contraseñas (es por esta razón que recomendamos encarecidamente utilizar contraseñas complejas en lugar de «123»). Sin embargo, la intensidad de estos intentos ese día fue demasiado alta.
¿Qué hacer?
¿Recomendar a los clientes dedicar mucho tiempo a cambiar la configuración de un gran número de usuarios finales para cambiar a otro puerto? No es una buena idea, los clientes no estarán contentos. ¿Recomendar permitir el acceso solo a través de VPN? Configurar conexiones IPSec en medio de la prisa y el pánico para quienes no las tengan activadas tampoco sería un regalo para los clientes. Aunque, debo decir que, de todos modos, es una obra meritoria, siempre recomendamos ocultar el servidor en una red privada y estamos listos para ayudar con la configuración. Para los aficionados que desean hacerlo por su cuenta, compartimos instrucciones para configurar IPSec/L2TP en nuestra nube en modo site-to-site o road-warrior, y si alguien desea levantar un servicio VPN en su propio servidor Windows, siempre estamos listos para compartir consejos sobre cómo establecer RAS o OpenVPN. Pero, por muy geniales que seamos, no era el mejor momento para realizar labores educativas entre los clientes, ya que necesitábamos resolver el problema lo más rápido posible con el mínimo esfuerzo para los usuarios.
La solución que implementamos consistió en lo siguiente. Organizamos el análisis del tráfico entrante de tal manera que pudiéramos rastrear todos los intentos de establecer una conexión TCP al puerto 3389 y seleccionar las direcciones que, en 150 segundos, intentaran establecer conexiones con más de 16 servidores diferentes en nuestra red; estos son los orígenes del ataque (por supuesto, si alguno de nuestros clientes o socios realmente necesita establecer conexiones con tal cantidad de servidores desde una misma fuente, siempre se pueden añadir tales fuentes a la 'lista blanca'. Sin embargo, si en una red de clase C se identifican más de 32 direcciones en esos 150 segundos, tiene sentido bloquear toda la red. El bloqueo se establece por 3 días, y si durante ese tiempo no se realizan ataques desde dicha fuente, esta se elimina automáticamente de la 'lista negra'. La lista de fuentes bloqueadas se actualiza cada 300 segundos.
Esta lista está disponible en la siguiente dirección: , pueden construir sus propias ACL basándose en ella.
Estamos dispuestos a compartir el código fuente de tal sistema; no hay nada demasiado complicado (son unos pocos scripts sencillos, elaborados literalmente en un par de horas 'sobre la marcha'), y además, se puede adaptar y utilizar no solo para protegerse contra tales ataques, sino también para detectar y bloquear cualquier intento de escaneo de la red:
Además, hemos realizado algunos cambios en la configuración del sistema de monitoreo, que ahora presta más atención a la reacción del grupo de control de servidores virtuales en nuestra nube ante un intento de establecer una conexión RDP: si no hay respuesta dentro de un segundo, esto es motivo para estar alerta.
La solución resultó ser bastante efectiva: ya no hay quejas ni por parte de los clientes y socios ni del sistema de monitoreo. Nuevas direcciones y redes enteras caen regularmente en la 'lista negra', lo que indica que el ataque continúa, pero ya no afecta el funcionamiento de nuestros clientes.
Uno en el campo no es un guerrero
Hoy hemos aprendido que otros operadores han enfrentado un problema similar. Algunos aún creen que fue Microsoft quien hizo cambios en el código del servicio de acceso remoto (si recuerdas, sospechamos lo mismo el primer día, pero rápidamente descartamos esa versión) y prometen hacer todo lo posible para encontrar una solución lo antes posible. Algunos simplemente ignoran el problema y aconsejan a los clientes que se protejan por su cuenta (cambiando el puerto de conexión, ocultando el servidor en una red privada, etc.). Nosotros, desde el primer día, no solo resolvimos este problema, sino que también creamos una base para un sistema más global de detección de amenazas que planeamos desarrollar.
Un agradecimiento especial a los clientes y socios que no se quedaron callados y no se sentaron a la orilla del río esperando que un día flote el cadáver del enemigo, sino que de inmediato llamaron nuestra atención sobre el problema, lo que nos permitió resolverlo ese mismo día.
Fuente: habr.com
