Le contaremos una historia genial sobre cómo "terceros" trataron de interferir con el trabajo de nuestros clientes y cómo se resolvió este problema.
Como empezó todo
Todo comenzó en la mañana del 31 de octubre, el último día del mes, cuando muchos necesitan desesperadamente lograr cerrar asuntos urgentes e importantes.
Uno de los socios que mantiene en nuestra nube varias máquinas virtuales de los clientes que atiende, informó que de 9:10 a 9:20 a la vez, varios servidores de Windows que se ejecutan en nuestro sitio ucraniano no aceptaron conexiones con el servicio de acceso remoto. , los usuarios no podían acceder a sus escritorios, pero después de unos minutos el problema pareció resolverse por sí solo.
Elevamos las estadísticas de los canales de comunicación, pero no encontramos ráfagas de tráfico o fallas. Observé las estadísticas sobre la carga de recursos informáticos, sin anomalías. Y que fue eso?
Luego, otro socio, que aloja otros cien servidores en nuestra nube, informó los mismos problemas que algunos de sus clientes notaron, y resultó que, en general, los servidores están disponibles (responden correctamente a la prueba de ping y otras solicitudes), pero el servicio El acceso remoto en estos servidores acepta nuevas conexiones, luego las rechaza, mientras que se trataba de servidores en diferentes sitios, cuyo tráfico proviene de diferentes canales de transmisión de datos.
Y veamos este tráfico. Un paquete con una solicitud para establecer una 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 la conexión rechaza:
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 está claramente causado no por fallas en la infraestructura, sino por algo más. ¿Quizás todos los usuarios tienen problemas con la licencia de escritorios remotos? Tal vez algún malware logró infiltrarse en sus sistemas, pero hoy se ha activado, como
ocurrió con
XData y
Petya hace un par de años.
Mientras lo resolvían, recibieron solicitudes similares de varios clientes y socios más.
¿Y qué pasa con estas máquinas?
Los registros de eventos están llenos de mensajes sobre el intento de encontrar una contraseña:
Por lo general, dichos intentos se registran en todos los servidores donde se usa el puerto estándar (3389) para el servicio de acceso remoto y se permite el acceso desde cualquier lugar. Internet está lleno de bots que escanean constantemente todos los puntos de conexión disponibles y tratan de encontrar una contraseña (por esta razón, recomendamos usar contraseñas complejas en lugar de "123"). Sin embargo, la intensidad de estos intentos ese día fue demasiado alta.
Que hacer
¿Recomienda a los clientes que dediquen 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. ¿Recomienda permitir el acceso solo a través de VPN? A toda prisa y pánico, para aumentar las conexiones IPSec, de quienes no son criados, tal vez, esa felicidad tampoco sonríe a los clientes. Aunque, debo decir, esto es en cualquier caso un asunto de caridad, siempre recomendamos ocultar el servidor en una red privada y estamos listos para ayudar con la configuración, y para aquellos a quienes les gusta resolver, compartiremos independientemente las instrucciones para configurar IPSec / L2TP en nuestra nube en modo de sitio a sitio o en carretera -Warrior, y si alguien quiere aumentar un servicio VPN en su propio servidor de Windows, siempre está listo para compartir consejos sobre cómo aumentar un RAS estándar o OpenVPN. Pero no importa cuán geniales fuéramos, este no era el mejor momento para realizar un trabajo educativo entre los clientes, ya que era necesario eliminar el problema con la mínima tensión para los usuarios lo más rápido posible.
La solución que implementamos fue la siguiente. Hemos establecido un análisis del tráfico que pasa de modo que se supervisen todos los intentos de establecer una conexión TCP al puerto 3389 y se seleccionen direcciones que, en 150 segundos, intenten establecer conexiones con más de 16 servidores diferentes en nuestra red: estas son las fuentes del ataque ( Por supuesto, si uno de los clientes o socios tiene una necesidad real de establecer conexiones con tantos servidores de la misma fuente, siempre puede agregar tales fuentes a la "lista blanca". Además, si está en una red de clase C para estos 150 segundos, se detectaron más de 32 direcciones, tiene sentido bloquear toda la red. El bloqueo se establece durante 3 días, y si no se realizaron ataques desde esta fuente durante este tiempo, esta fuente se elimina automáticamente de la lista negra. La lista de fuentes bloqueadas se actualiza cada 300 segundos.
Esta lista está disponible aquí en esta dirección:
https://secure.tucha.ua/global-filter/banned/rdp_ddos , puede crear sus propias ACL sobre la base de ella.
Estamos listos para compartir el código fuente de dicho sistema, no tiene nada súper complicado (estos son unos pocos guiones simples escritos literalmente en un par de horas "en la rodilla"), y al mismo tiempo se puede adaptar y usar no solo para proteger contra tal ataque, sino también para identificar y bloqueando cualquier intento de escaneo de red:
siga este enlace.Además, realizamos algunos cambios en la configuración del sistema de monitoreo, que ahora monitorea de cerca la reacción del grupo de control de servidores virtuales en nuestra nube ante un intento de establecer una conexión RDP: si la reacción no se produjo por un segundo, esta es una ocasión para prestar atención.
La solución resultó ser bastante efectiva: no hay más quejas de clientes y socios, así como del sistema de monitoreo. La "lista negra" incluye regularmente nuevas direcciones y redes enteras, lo que indica que el ataque continúa, pero ya no afecta el trabajo de nuestros clientes.
Solo en el campo no es un guerrero.
Hoy aprendimos que otros operadores se han enfrentado a un problema similar. Alguien todavía cree que Microsoft realizó algunos cambios en el código del servicio de acceso remoto (si recuerda, sospechamos lo mismo el primer día, pero rechazamos esta versión muy pronto) y promete hacer todo lo posible para encuentre una solución pronto. Alguien simplemente ignora el problema y aconseja a los clientes que se protejan (cambien el puerto de conexión, oculten el servidor en una red privada, etc.). Y el primer día, no solo resolvimos este problema, sino que también creamos algunas bases para un sistema de detección de amenazas más global, que planeamos desarrollar.
Un agradecimiento especial a los clientes y socios que no permanecieron en silencio y no se sentaron en la orilla del río anticipando que un día el cadáver del enemigo flotaría sobre él, e inmediatamente dirigieron nuestra atención al problema, lo que nos dio la oportunidad de eliminarlo el mismo día.