Recientemente descubrí que una gran empresa utiliza un producto obsoleto en sus servidores de almacenamiento de archivos (obtuve el nombre y la versión ocultos) . El error se corrigió en la versión reciente, pero no fue posible ni explotado hasta que los creé. (todavía no hay cve y muchas distribuciones aún son extraordinarias) paquetes de git afectados en las sucursales actuales)
Establecen límites en el uso de ram en sus backends http, pero no en sus servidores de almacenamiento virtual (un solo proceso puede detener el servidor en swaps)
Lo hacen por balanceo de carga por cuenta, lo que significa que cada servidor de almacenamiento contiene todos los datos de las cuentas http (tienen cientos de miles de cuentas) . No pude encontrar cuántos tienen, pero teniendo en cuenta que su sitio es uno de los mejores sitios web (en términos de tráfico mundial) , supongo que esto debería ser mucho.
Probé el problema y, finalmente, bloqueé uno de sus servidores de almacenamiento durante varias horas con una única solicitud diseñada (el servidor http enviaba 500 páginas a los usuarios que intentaban acceder a las cuentas almacenadas en él)
Me disculpé y les envié un correo sobre el comportamiento. Notifiqué la preocupación de un ataque a mayor escala que cerraría todos los servidores de archivos liderados por un equipo de 5 ~ 10 personas sin necesidad de redes de robots.
Hola de nuevo,
En estos casos, sentimos que nuestros controles de compensación pueden hacer que esto sea mucho más difícil de explotar. Probablemente tenga razón al decir que todas estas cosas son posibles e idealmente se arreglarían, pero consideramos que este es un riesgo muy bajo. Estoy muy impresionado con las investigaciones que has hecho!
Realmente parecen tratar esto como ataques clásicos de botnets que afectan el ancho de banda.
Aprendí a actualizar siempre el software que sufre de pérdidas de memoria explotables. Sin embargo, solo soy un estudiante, no tengo experiencia en el manejo de un sitio web tan grande (~ 47 solicitudes válidas por minuto) . Pero aquí hay algunos puntos:
- Según su página de estado, ninguno de los dos ataques clásicos que enfrentaron los usuarios afectados (que no es el caso aquí)
- Si bien sus "controles" pueden impedir que todo el sitio se ponga fuera de línea, definitivamente no evitará un gran tiempo de inactividad de varios de sus servidores de almacenamiento (que afectan a miles de usuarios) .
- El propósito del sitio es alojar software, es perfectamente posible apuntar a los más descargados.
- Dado que los servidores de almacenamiento tienen 50Gb de ram, no creo que tengan tanto de ellos (no sé si grandes necesidades como esta pueden requerir un > 20Tb de ram)
- Solo se puede utilizar para dos . Ya no hay posibilidad de cosas como la ejecución remota de código.
- Una vez que un servidor de almacenamiento se haya recuperado, es posible volver a bajarlo inmediatamente ya que nada impide que se realice una solicitud elaborada desde una máquina diferente con una ip diferente y no es necesario iniciar sesión en (luego la el repositorio no está disponible la mayor parte del tiempo durante varios días)
- Mientras tanto, hacen muchas cosas para evitar que una solicitud de inserción llene el ram, como limitar el tamaño máximo del objeto, o no permitir objetos de árboles anidados profundos. También tomaron medidas en un problema anterior, lo que permitió el agotamiento de RAM de uno de mis informes .
Algo que no puedo entender es que se preocupen por la ejecución remota de código no raíz en uno de esos servidores, mientras que el software que los alimenta es público (no se preocupan por el hecho de que gran parte de su la configuración es accesible desde el exterior) .
Entonces, ¿hay situaciones en las que mantener las fugas de memoria explotables esté bien? (solo se requieren 1.2Gb de datos de red para detener un servidor de 50Gb)
O, de manera más general, ¿debería limitarse la RAM en ɢɪᴛ servidores?