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.