Le contaremos una historia interesante sobre cómo "terceros" intentaron interferir con el trabajo de nuestros clientes y cómo se resolvió este problema.
Como empezó todo
Todo comenzó la mañana del 31 de octubre, último día del mes, cuando muchos necesitan desesperadamente tiempo para resolver cuestiones urgentes e importantes.
Uno de los socios, que mantiene varias máquinas virtuales de los clientes a los que atiende en nuestra nube, informó que entre las 9:10 y las 9:20 varios servidores Windows que se ejecutan en nuestro sitio ucraniano no aceptaron conexiones al servicio de acceso remoto, los usuarios no pudieron iniciar sesión en sus escritorios, pero después de unos minutos el problema pareció resolverse por sí solo.
Elaboramos estadísticas sobre el funcionamiento de los canales de comunicación, pero no encontramos aumentos ni fallas en el tráfico. Analizamos las estadísticas sobre la carga de recursos informáticos y no encontramos anomalías. ¿Y qué fue eso?
Luego, otro socio, que aloja alrededor de cien servidores más en nuestra nube, informó los mismos problemas que notaron algunos de sus clientes, y resultó que, en general, los servidores eran accesibles (respondiendo adecuadamente a la prueba de ping y otras solicitudes), pero el servicio de acceso remoto a estos servidores acepta nuevas conexiones o las rechaza, y estábamos hablando de servidores en diferentes sitios, cuyo tráfico proviene de diferentes canales de transmisión de datos.
Miremos este tráfico. Llega al servidor un paquete con una solicitud de conexión:
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 se debe a ningún problema en el funcionamiento de la infraestructura, sino a otra cosa. ¿Quizás todos los usuarios tienen problemas con las licencias de escritorio remoto? Quizás algún tipo de malware logró penetrar en sus sistemas y hoy se activó, como hace un par de años. Xdatos и Petya?
Mientras lo solucionábamos, recibimos solicitudes similares de varios clientes y socios más.
¿Qué sucede realmente en estas máquinas?
Los registros de eventos están llenos de mensajes sobre intentos de adivinar la contraseña:
Normalmente, estos 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. Internet está lleno de robots que escanean constantemente todos los puntos de conexión disponibles e intentan adivinar la contraseña (por eso recomendamos encarecidamente utilizar contraseñas complejas en lugar de “123”). Sin embargo, la intensidad de estos intentos ese día fue demasiado alta.
¿Qué debería hacer?
¿Recomienda que los clientes dediquen mucho tiempo a cambiar la configuración para que una gran cantidad de usuarios finales cambien a un puerto diferente? No es una buena idea, los clientes no estarán contentos. ¿Recomienda permitir el acceso solo a través de VPN? Con prisa y pánico, conseguir conexiones IPSec para aquellos que no las tienen, tal vez esa felicidad tampoco les sonría a los clientes. Aunque debo decir que esto es algo santo en cualquier caso, 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 resolverlo por su cuenta, compartimos instrucciones. para configurar IPSec/L2TP en nuestra nube en modo sitio a sitio o en modo carretera -warrior, y si alguien quiere configurar un servicio VPN en su propio servidor Windows, siempre está listo para compartir consejos sobre cómo configurar un RAS estándar u OpenVPN. Pero, por muy geniales que fuéramos, este no era el mejor momento para realizar un trabajo educativo entre los clientes, ya que necesitábamos solucionar el problema lo más rápido posible con el mínimo estrés para los usuarios.
La solución que implementamos fue la siguiente. Hemos configurado un análisis del tráfico que pasa de tal manera que monitoreemos todos los intentos de establecer una conexión TCP al puerto 3389 y seleccionemos de él 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 dichas fuentes a la "lista blanca". Además, Si en una red de clase C durante estos 150 segundos se identifican más de 32 direcciones, tiene sentido bloquear toda la red. El bloqueo se establece por 3 días, y si durante este tiempo no se realizaron ataques desde una fuente determinada, esta fuente se elimina automáticamente de la “lista negra”. La lista de fuentes bloqueadas se actualiza cada 300 segundos.
Esta lista está disponible en esta dirección: , puede crear sus ACL basadas en él.
Estamos listos para compartir el código fuente de dicho sistema, no hay nada demasiado complejo en él (estos son varios scripts simples compilados literalmente en un par de horas en la rodilla) y, al mismo tiempo, se puede adaptar y usar no sólo para proteger contra tal ataque, pero también para detectar y bloquear cualquier intento de escanear la red:
Además, hemos realizado algunos cambios en la configuración del sistema de monitoreo, que ahora monitorea más de cerca la reacción de un grupo de control de servidores virtuales en nuestra nube ante un intento de establecer una conexión RDP: si la reacción no se produce dentro de un En segundo lugar, ésta es una razón para prestar atención.
La solución resultó bastante eficaz: ya no hay quejas ni de los clientes ni de los socios ni del sistema de seguimiento. Regularmente se agregan nuevas direcciones y redes enteras a la lista negra, lo que indica que el ataque continúa, pero ya no afecta el trabajo de nuestros clientes.
No guerrero en el campo
Hoy supimos que otros operadores se han encontrado con un problema similar. Alguien todavía cree que Microsoft realizó algunos cambios en el código del servicio de acceso remoto (si recuerdan, sospechábamos lo mismo el primer día, pero rápidamente rechazamos esta versión) y promete hacer todo lo posible para encontrar una solución rápidamente. . Algunas personas simplemente ignoran el problema y aconsejan a los clientes que se protejan por su cuenta (cambien el puerto de conexión, oculten el servidor en una red privada, etc.). Y desde el primer día, no sólo 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 se quedaron en silencio y no se sentaron en la orilla del río esperando que un día flotara el cadáver de un enemigo, sino que inmediatamente llamaron nuestra atención sobre el problema, lo que nos dio la oportunidad de eliminar. eso el mismo día.
Fuente: habr.com