¿Un clúster constantemente dinámico de instancias de corta duración reduce la superficie de ataque?

0

La idea de las 4am

La idea general es que todas las instancias que se inician en mi clúster están precargadas con un 'script de suicidio' que luego de un preset Time To Live (por ejemplo, 27 minutos) lanza una instancia de reemplazo, y luego termina por sí solo.

El resultado es un clúster 'en constante movimiento' donde no existe una dirección IP por más tiempo que el TTL de cualquier instancia dada.

No tengo una comprensión de los vectores de ataque o la teoría de la superficie de ataque, como estoy seguro de que la mayoría de ustedes lo tienen, pero este tipo de enfoque parece ofrecer algunas ventajas interesantes.

Esto es lo que pienso que podría lograrse

  • Reducir los intentos generales de intrusión por instancia: La corta vida útil de cada IP reduciría el tiempo disponible para cualquier intento de intrusión. Una vez que se encuentra una IP de destino, el atacante tiene solo el TTL antes de que se cierre la ventana, lo que reduce el número total de intentos, lo que reduce la probabilidad general de un ataque exitoso.
  • Actualizaciones de seguridad frecuentes: las instancias controlarán sus actualizaciones de seguridad al iniciarse, lo que significa que nunca estarán más de 27 minutos desactualizados con los parches de seguridad.
  • Eliminar la capa de implementación: si maneja la implementación de la aplicación al iniciar, lo que hago, esto automatizaría aún más el proceso al eliminar la necesidad de Githooks o Dockerhubhooks, para bien o para mal.
  

Un experimento de pensamiento rápido también revelaría que si reduce el TTL a un punto en el que cualquier instancia dada solo tiene tiempo para manejar el inicio, el manejo de un puñado de solicitudes (el 'script de suicidio' también podría activarse después de que se haya manejado un cierto número de solicitudes, como por ejemplo, 27), y luego baja, me parece que aumentaría considerablemente la dificultad de un ataque. Si el ataque requiere más de 27 solicitudes, el atacante nunca podrá completar todos los pasos necesarios para tener éxito.

Así que creo que son cosas interesantes, buenas. Obviamente, hay muchos más factores a tener en cuenta, entre los cuales se encuentra el impacto que esto podría tener en la forma en que su enrutador maneja las solicitudes, y si su proveedor de nube lo permitiría incluso teniendo en cuenta la carga adicional de CPU que podría tener. su sistema

¿Reduciría esto la superficie de ataque para los siguientes vectores de ataque?

  • intentos de comprometer open-ssl
  • Escaneo de puertos
  • HTTP / HTTPS que escucha en 80 y 443 en cada instancia

Vale la pena señalar que las aplicaciones en cada instancia serían aplicaciones efímeras, el almacenamiento de la sesión es un clúster remoto de Mongo (que se ejecuta en la misma región de AWS), y Nginx se usaría en cada instancia para manejar el enrutamiento del tráfico al IP correcta: PUERTO de cada aplicación instalada en la instancia, por lo que 80 y 443 necesitan estar abiertos.

Gracias de antemano por cualquier información que desee compartir.

    
pregunta AJB 18.01.2015 - 02:50
fuente

1 respuesta

1
  

¿Se reduce un clúster constantemente dinámico de instancias de corta duración?   atacar la superficie?

¿Reducir la superficie de ataque?

No creo que lo haga significativamente. No necesariamente le permitiría ejecutar menos servicios o tener menos servicios expuestos a posibles atacantes. La superficie expuesta general de su sistema permanece igual.

¿Reducir la amenaza?

Tampoco lo creo, tampoco reduce necesariamente la cantidad de vulnerabilidades que pueden existir en su sistema o la cantidad de posibles atacantes que están motivados y son capaces de explotar su sistema. Puede reducir ligeramente la amenaza si esto pudiera hacer que el software vulnerable se actualice más rápidamente, pero eso también podría lograrse sin reemplazar la instancia.

¿Reducir el riesgo?

Sí, creo que lo haría, la pregunta es por cuánto. Le está haciendo más difícil a un atacante explotar su sistema, y por lo tanto reduce la posibilidad de que tenga éxito pero no está eliminando fundamentalmente ningún vector de ataque.

Consideraría esto como un sistema de prevención de intrusiones (IPS) que generalmente intenta bloquear solicitudes sospechosas. En ese caso, está reduciendo la posibilidad de que un atacante tenga éxito porque primero tienen que sortear el IPS, pero en realidad no está eliminando ninguna vulnerabilidad de su sistema.

Además, hay ciertos vectores de ataque que no se verían afectados por esto:

  • Inyecciones de SQL: podrían explotarse independientemente de la instancia que atendió la solicitud
  • DDoS contra una solicitud computacionalmente costosa entregada a través de su equilibrador de carga
  • Código malicioso almacenado en infraestructura compartida, por ejemplo, tu base de datos
  

el atacante nunca podría completar todos los pasos necesarios para   tener éxito

Esto sería válido si pudiera garantizar que una vulnerabilidad no se puede explotar en 27 minutos; de lo contrario, la efectividad variará enormemente entre los vectores de ataque. Algunos ataques podrían ser orquestados fácilmente en menos de un minuto.

Por ejemplo, en la vida real, los bloqueos de retardo de tiempo funcionan porque si usted sabe que la policía llegará en 20 minutos, pero la caja fuerte no se puede abrir durante 30 minutos. A menos que pueda recrear este escenario, no creo que se eliminen las vulnerabilidades.

  

Intenta comprometer open-ssl

Dudo que suponga que todas las instancias ejecutan una versión vulnerable. Tal vez si se tarda más de 27 minutos en explotar.

  

Escaneo de puertos

No, todas sus instancias probablemente tendrían los mismos puertos abiertos y servicios activos. Cuando una instancia se desconecta, solo pueden continuar el escaneo en otra instancia donde se detuvieron.

  

HTTP / HTTPS que escucha en 80 y 443 en cada instancia

Hay una gran variedad de exploits que podrían entregarse a través de HTTP, pero en general no creo que haga mucha diferencia. Normalmente, los sistemas con carga equilibrada están diseñados para brindar la misma respuesta en todas las instancias, por lo tanto, si se puede realizar una inyección de SQL en una instancia, es casi seguro que funcionará en otra.

    
respondido por el thexacre 18.01.2015 - 03:42
fuente

Lea otras preguntas en las etiquetas