si un servidor usa / dev / random para generar la clave de sesión aleatoria con un cliente. ¿Cómo puede iniciar un ataque de denegación de servicio (DOS) en un servidor de este tipo?
si un servidor usa / dev / random para generar la clave de sesión aleatoria con un cliente. ¿Cómo puede iniciar un ataque de denegación de servicio (DOS) en un servidor de este tipo?
Aparte de todos los métodos de ataque DoS normales que pueden funcionar contra el sistema, bajo ciertas condiciones puede hacer el DoS del sistema solicitando un número increíblemente grande de ID de sesión nuevos.
Tenga en cuenta que digo 'puede en ciertas circunstancias' aquí por dos razones:
/dev/random . Esto no funcionará en algunos sistemas UNIX, como OpenBSD, que felizmente suministrará números aleatorios seguros desde /dev/random hasta la muerte térmica del universo sin bloqueo. Esto se debe a que en OpenBSD /dev/random es un enlace simbólico a /dev/arandom , que es un CSPRNG de ejecución libre que periódicamente se inyecta más entropía. /dev/random para inicializar su RNG interno, y luego lo usan para generar cosas como claves de sesión, lo que significa que no tienen problemas más allá del inicio o la reinicialización con un grupo de entropía vacío. Incluso los más inteligentes usan /dev/urandom para sembrar, por lo que literalmente no tienen problemas con un grupo de entropía vacío. Incluso suponiendo que el resto del sistema no se vea afectado por la falta de entropía, es posible que no pueda tener un gran impacto directo en el servicio en sí. Dependiendo de la forma en que está diseñado, puede tener un impacto exactamente cero más allá de su propia conexión al servicio.
Puede referirse al problema de que la lectura de /dev/random se bloqueará en algunos sistemas si no hay suficiente entropía disponible. La extracción rápida de la entropía del sistema mediante la creación de una gran cantidad de identificadores de sesión puede hacer que la aplicación se bloquee al crear otro identificador de sesión, lo que hace que al menos esta parte específica de la aplicación no responda por algún tiempo: un ataque de denegación de servicio.
La forma exacta en que se puede hacer que la aplicación cree nuevos identificadores de sesión depende de la aplicación, pero para implementaciones típicas podría ser suficiente enviar una única solicitud HTTP que aún no tiene una cookie de sesión y el envío de muchas de estas solicitudes se puede automatizar fácilmente. .
Lea otras preguntas en las etiquetas cryptography random