Contámosche unha historia interesante sobre como "terceiros" intentaron interferir no traballo dos nosos clientes e como se solucionou este problema.
Como comezou todo
Todo comezou na mañá do 31 de outubro, último día do mes, cando moitos necesitan desesperadamente ter tempo para resolver problemas urxentes e importantes.
Un dos socios, que garda varias máquinas virtuais dos clientes aos que serve na nosa nube, informou de que de 9:10 a 9:20 varios servidores de Windows que se executaban no noso sitio ucraíno non aceptaban conexións ao servizo de acceso remoto, os usuarios non podían para iniciar sesión nos seus escritorios, pero despois duns minutos o problema parecía resolverse por si só.
Subimos as estatísticas sobre o funcionamento das canles de comunicación, pero non atopamos ningún aumento ou avaría de tráfico. Observamos as estatísticas sobre a carga dos recursos informáticos, sen anomalías. E iso que foi?
Entón outro socio, que aloxa uns cen servidores máis na nosa nube, informou dos mesmos problemas que algúns dos seus clientes constataron, e resultou que, en xeral, os servidores eran accesibles (respondendo correctamente á proba de ping e outras solicitudes), pero o servizo de acceso remoto a estes servidores ou ben acepta novas conexións ou ben as rexeita, e estabamos a falar de servidores de diferentes sitios, cuxo tráfico procede de diferentes canles de transmisión de datos.
Vexamos este tráfico. Un paquete cunha solicitude de conexión chega ao 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
O servidor recibe este paquete, pero rexeita a 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
Isto significa que o problema claramente non é causado por ningún problema no funcionamento da infraestrutura, senón por outra cousa. Quizais todos os usuarios teñan problemas coa licenza de escritorio remoto? Quizais algún tipo de malware conseguise penetrar nos seus sistemas, e hoxe activouse, como ocorreu hai un par de anos XData и Petya?
Mentres o resolvíamos, recibimos solicitudes similares de varios clientes e socios máis.
Que ocorre realmente nestas máquinas?
Os rexistros de eventos están cheos de mensaxes sobre intentos de adiviñar o contrasinal:
Normalmente, estes intentos rexístranse en todos os servidores nos que se usa o porto estándar (3389) para o servizo de acceso remoto e o acceso está permitido desde todas as partes. Internet está chea de bots que exploran constantemente todos os puntos de conexión dispoñibles e tentan adiviñar o contrasinal (por iso recomendamos encarecidamente usar contrasinais complexos en lugar de "123"). Porén, a intensidade destes intentos ese día foi demasiado alta.
Como proceder?
Recomendas que os clientes pasen moito tempo cambiando a configuración para que un gran número de usuarios finais cambien a un porto diferente? Non é unha boa idea, os clientes non estarán contentos. Recomendas permitir o acceso só mediante VPN? Con présa e pánico, aumentar as conexións IPSec para aqueles que non as teñen, quizais tal felicidade tampouco sorrí aos clientes. Aínda que, debo dicir, isto é algo divino en calquera caso, sempre recomendamos ocultar o servidor nunha rede privada e estamos preparados para axudar coa configuración, e para aqueles que queiran descubrilo por conta propia, compartimos instrucións. para configurar IPSec/L2TP na nosa nube en modo sitio a sitio ou estrada -warrior, e se alguén quere configurar un servizo VPN no seu propio servidor Windows, sempre está preparado para compartir consellos sobre como configurar un RAS estándar ou OpenVPN. Pero, por moi xeniais que foses, este non era o mellor momento para realizar traballos educativos entre os clientes, xa que necesitabamos solucionar o problema o máis rápido posible cun mínimo estrés para os usuarios.
A solución que implementamos foi a seguinte. Establecemos unha análise do tráfico de paso de xeito que vixiemos todos os intentos de establecer unha conexión TCP ao porto 3389 e seleccionamos a partir del enderezos que, nun prazo de 150 segundos, intenten establecer conexións con máis de 16 servidores diferentes da nosa rede. - Estas son as fontes do ataque (Por suposto, se un dos clientes ou socios ten unha necesidade real de establecer conexións con tantos servidores da mesma fonte, sempre pode engadir tales fontes á "lista branca". Ademais, se nunha rede de clase C durante estes 150 segundos se identifican máis de 32 enderezos, ten sentido bloquear toda a rede. O bloqueo está establecido para 3 días, e se durante este tempo non se realizaron ataques desde unha determinada fonte, esta fonte elimínase automaticamente da "lista negra". A lista de fontes bloqueadas actualízase cada 300 segundos.
Esta lista está dispoñible neste enderezo: , podes construír as túas ACL en función del.
Estamos preparados para compartir o código fonte deste sistema; non hai nada excesivamente complexo nel (son varios scripts sinxelos compilados literalmente nun par de horas sobre o xeonllo) e, ao mesmo tempo, pódese adaptar e non usar. só para protexerse contra tal ataque, pero tamén para detectar e bloquear calquera intento de escanear a rede:
Ademais, fixemos algúns cambios na configuración do sistema de vixilancia, que agora supervisa máis de preto a reacción dun grupo de control de servidores virtuais na nosa nube ante o intento de establecer unha conexión RDP: se a reacción non se produce nun segundo, esta é unha razón para prestar atención.
A solución resultou bastante efectiva: non hai máis queixas tanto de clientes como de socios, e do sistema de seguimento. Novos enderezos e redes enteiras engádense regularmente á lista negra, o que indica que o ataque continúa, pero xa non afecta o traballo dos nosos clientes.
Hai seguridade nos números
Hoxe soubemos que outros operadores atoparon un problema similar. Alguén segue crendo que Microsoft fixo algúns cambios no código do servizo de acceso remoto (se lembras, sospeitamos o mesmo o primeiro día, pero rexeitamos moi rapidamente esta versión) e promete facer todo o posible para atopar unha solución rapidamente . Algunhas persoas simplemente ignoran o problema e aconsellan aos clientes que se protexan por si mesmos (cambiar o porto de conexión, ocultar o servidor nunha rede privada, etc.). E o primeiro día, non só resolvemos este problema, senón que tamén creamos algunhas bases para un sistema de detección de ameazas máis global, que pensamos desenvolver.
Un agradecemento especial aos clientes e socios que non quedaron en silencio e non se sentaron na beira do río agardando que algún día o cadáver dun inimigo flotase por el, pero que de inmediato nos chamaron a atención sobre o problema, o que nos deu a oportunidade de eliminar o mesmo día.
Fonte: www.habr.com