En uno de los artículos hablé sobre cómo el guión infantil interfiere en la vida de nuestros clientes. En este artículo, me gustaría hablar sobre soluciones: cómo intentaremos lidiar con eso.
Hasta ahora, sin los códigos fuente completos, estarán en los próximos artículos. Mientras tanto, más bien, sobre la estrategia y tácticas de defensa.
"Soluciones" estándar
Enviar quejas
Un enfoque muy común. Si se detecta una intrusión en su IS, ingrese al atacante en el firewall (o no) y envíe una queja automática por correo, que se encontró en whois.
Recibimos quejas sobre nuestros clientes desde el sistema de detección de intrusos de varios bancos, oficinas, sitios web. Incluso, al parecer, las grandes organizaciones simplemente lanzan fail2ban y eso es todo.
Todo funcionará cada dos veces, ¿qué pasa si el atacante no está prohibido? Sí, y está mal dar la oportunidad de llamar a tu puerta, ¿qué pasa si alguien establece la contraseña de nivel solarwinds123 y es pirateado en el primer intento?
Obligar a los usuarios a hacer lo correcto.
Puede crear su propio servicio, casi malware, como lo hizo Godaddy, agregar otro usuario bajo el inicio de sesión de nydys y olvidarse de deshabilitar el administrador de inicio en la nube, como lo hizo Godaddy, instalar 8 certificados adicionales en el sistema, como lo hizo Godaddy.
También puede bloquear AD y otros "puertos inseguros", como lo hizo algún otro alojamiento, y eso es todo.
Puede ejecutar sus rastreadores y escanear sus propias redes. Escanee puertos, encuentre servicios vulnerables o incluso intente ingresar a sus propios clientes con las contraseñas descifradas con mayor frecuencia.
Esto realmente ayudará en algo, pero el usuario debe decidir qué y cómo se debe organizar en los servidores del usuario. Además, si haces todo esto, como dicen, en una escala, entonces tropezaremos con una extensión en el conocimiento técnico de los usuarios y un malentendido, "Bueno, ¿qué he hecho?" y “¡No soy programador!”, pero todos deberían estar a salvo.
Lidiar con la seguridad
Todo lo anterior es muy bueno y puede ser útil. Pero los usuarios deben estar protegidos. Especialmente novatos. Los servidores virtuales se utilizan a menudo como un campo de experimentación, una plataforma para familiarizarse con los sistemas de servidores y, a veces, los usuarios se equivocan.
Hablamos con los propietarios de las máquinas comprometidas, les pedimos que dijeran honestamente qué contraseña se estableció y, desafortunadamente, los inicios de sesión y las contraseñas de la prueba: prueba o nivel 111: 111, esta sigue siendo una práctica común.
Los usuarios de Linux están empeorando, no están tan dispuestos a contactar como los usuarios de Windows, aunque, a juzgar por la cantidad de quejas sobre los servidores Linux, los ciberdelincuentes los piratean o utilizan con mayor frecuencia.
Está claro que no todo el mundo pierde sus políticas y establece contraseñas del nivel "12345678" en la raíz, pero esto sucede con regularidad, así que debería intentarlo.
Arquitectura
Simple como un durmiente. Aquí hay una imagen:
- El servidor de capturas recopila estadísticas durante 1 hora y envía los datos recopilados a la base de datos.
- El servidor de jueces recopila datos de la base de datos y toma decisiones sobre prohibiciones. Las prohibiciones también se registran para el historial médico de cada dirección IP específica.
- El servidor BGP analiza la lista de prohibidos generada y transmite esta lista como una fuente de BGP a los enrutadores.
Desde los servidores de trampa, los datos se envían en el mismo formato por el mismo "Get-Bruteforce" que ofrecimos anteriormente, a saber:
- Intentos de piratería
- Inicios de sesión utilizados
- dirección IP
- Registro PTR
Cómo se pesan las decisiones
Estamos hablando de una solución potencialmente de combate, por lo tanto, es imposible prohibir a todos seguidos. Es necesario introducir criterios discretos y comprensibles para que quede claro cómo, qué y por qué.
Por el momento, se tienen en cuenta 6 factores:
- ¿Cuántas veces intentó el atacante entrar
- ¿Cuántos cebos diferentes golpeó?
- ¿La dirección IP es estática?
- ¿La dirección IP pertenece al proveedor de alojamiento o de origen?
- ¿El atacante utilizó inicios de sesión "incorrectos"?
- Que dicen otros buenos
Expresiones cuantitativas
Aquí todo está claro. Cuanto más intensiva sea la búsqueda y mayor sea su área, y cuanto mayor sea el diccionario, mayor será la amenaza que representa el atacante. No tiene sentido ampliar este artículo.
PTR y todo lo relacionado con él
Cuando publicamos el análisis inicial de fuerza bruta, se hizo evidente que el registro PTR dice mucho.
La cantidad de empresas de alojamiento chinas que atacaron nuestros servidores fue simplemente abrumadora, pero esta no es una excepción, los clientes de Azure y AWS también participaron con mucha alegría y no ocuparon los últimos lugares.
La mayor cantidad de ataques provino de las direcciones IP estáticas de los proveedores de alojamiento, por lo que si los servidores representan la mayor amenaza para la seguridad, ¿por qué prohibir a los usuarios habituales?
Inicios de sesión incorrectos
Hay algunos. Por ejemplo, "k8h3d", que se encuentra fácilmente en Google, es el primer candidato para una prohibición. Este es un inicio de sesión de un gusano criptominero muy estúpido que dejó una puerta trasera en RDP con este nombre de usuario. Lo mismo se aplica a los inicios de sesión escritos en hindi, chino y otros diseños que no son típicos de nuestros clientes.
Puede imaginar una situación en la que una persona comete un error en un dígito de la dirección IP, no ingresa y comienza a ordenar todas las contraseñas que había en su vida. Pero es difícil imaginar esperar de nuestro cliente que comenzará a escribir algo diferente al Administrador estándar. Proporcionamos SO solo con inicios de sesión en inglés, por lo tanto, prohibir la distribución del teclado es quizás lo más efectivo y seguro.
Otros buenos chicos
Spamhaus como ejemplo de los buenos, gracias a ellos por las listas de bloqueo abiertas. Digamos que un atacante golpeó solo un honeypot, pero su dirección ha estado en el SBL durante mucho tiempo, entonces ¿por qué tirar?
Es lo mismo con las listas de fail2ban abiertas, la opinión de otros buenos te permite tomar decisiones con más confianza.
Pruebas
Como en medicina. Estudio aleatorizado, doble ciego. Los servidores supervisados (excepto las trampas) se dividen en dos grupos.
- Grupo de control
- Los pacientes
Durante las primeras dos semanas, aplicamos reglas de filtrado solo para pacientes. El grupo de control recibe todo el tráfico sin filtrar. Después de eso, se intercambian exactamente la mitad de los servidores de ambos grupos.
Se ubicarán grupos de control adicionales en otros CD para tener en cuenta la “estacionalidad” y excluir la influencia de otros factores, por ejemplo, el cierre de controladores, etc.
Por lo tanto, será posible establecer de manera más confiable cuán efectivo es el honeypotting como método para proteger cualquier cosa que no sean los propios honeypots.
¿Que sigue?
Después de recopilar los datos primarios, las pruebas de combate cercano se llevarán a cabo en solo un par de centros de datos, y si esto reduce significativamente el número de ataques, publicaremos:
- Abrir hoja de bloqueo con comentarios expandidos en formato txt, xml y json
- Script para RouterOS y hoja de bloqueo separada para RouterOS
- Alimentación abierta para enrutadores con soporte BGP.
- Códigos fuente.
Bueno, si no hay menos ataques o más problemas, publicaremos solo el código fuente y un informe sobre por qué se quemó.
Espero que el tema sea tan interesante para usted como espera sus pensamientos sobre el sistema propuesto, cualquier pensamiento será útil.
