¿Cómo puedo explicar al cliente que rfc2385 TCP MD5 Checksums no se puede activar para los servidores web de Linux?

Question

¿Cómo puedo explicar al cliente que rfc2385 TCP MD5 Checksums no se puede activar para los servidores web de Linux?

#1 de rook (2 votos)
#2 de StackzOfZtuff (1 votos)
#3 de mostlyinformed (1 votos)

11

He tenido una larga conversación con un cliente donde realizan un exploración de seguridad Rapid7 que luego advierte sobre la falta de suma de comprobación de TCP MD5 en el puerto 80. Esto es lo que creo que sé:

RFC 2385 fue diseñado para proteger BGP y, por extensión, protocolos de tipo BGP (es decir, conexiones TCP de larga ejecución).
BGP usa conexiones TCP de larga duración, HTTP no.
El cifrado / IPSec ha reemplazado a RFC 2385 para proteger BGP.
El ataque TCP RST es contra las conexiones TCP de larga ejecución porque el ataque depende de la probabilidad.
El impacto en el restablecimiento de una conexión HTTP mantenida en vivo es que la próxima solicitud se reiniciará.
La mayoría de las conexiones transfieren datos en milisegundos, la ventana de ataque es demasiado pequeña para que HTTP pueda dirigirse efectivamente. El ataque depende del tamaño de la ventana y el ancho de banda del atacante contra el servidor y parece tardar unos segundos incluso en buenas condiciones, según la página 25 de Deslizándose en la ventana: ataques de restablecimiento de TCP )
Una vista web suele estar formada por múltiples conexiones para cada cliente conectado, lo que hace que este tipo de denegación de servicio no sea atractivo en comparación con las alternativas.
Linux (específicamente RHEL o Debian) tiene soporte para rfc2385 pero no puede ser global habilitado.
Ni NGINX ni Apache tienen opciones de configuración para abrir sockets con tcp-md5-checksums habilitados.
Incluso si rfc2385 estaba activo para HTTP, no resolvería un problema, pero aumentaría la carga en el servidor. Lo cual es solo un punto secundario menor.

He intentado explicar que rfc2385 no es relevante para los servidores web, pero dicen que es un problema con TCP que, si bien es cierto, simplifica que es un ataque contra una naturaleza específica de la Conexión TCP.

He recurrido a explicar que ni Apache ni nginx pueden habilitar lo que piden. Me siguen enviando documentos de la base de conocimientos que mencionan Windows, Cisco, NetBSD, BGP, pero nunca nada relacionado con apache ni nginx.

Más allá de los documentos vinculados, los he enviado LWN explicándolos:

Sería difícil usar esta técnica para apagar un servidor web; Para empezar, las conexiones HTTP suelen ser de corta duración.

Hay un parche disponible en Windows que corrige la advertencia que están enviando como una sugerencia, pero claramente no logra nada para Linux.

¿Estoy hablando sin sentido? ¿Cuál sería su sugerencia de que el cliente que tiene el cumplimiento de seguridad se preocupe por estar en la misma página que yo?

apache security-theater nginx tcp

pregunta Kit Sunde 23.10.2014 - 09:33

fuente

3 respuestas

Lea otras preguntas en las etiquetas apache security-theater nginx tcp

¿Está utilizando TPM con contraseñas SRK / propietario bien conocidas? ¿Es seguro que Venmo solicite credenciales?

score 2 · Answer 1

El uso de MD5 para verificar la coherencia es una clara violación de CWE-327: Uso de un algoritmo criptográfico roto o arriesgado . Cualquier protección provista por RFC-2387 se anula por el uso de un algoritmo obsoleto e inseguro.

Rapid7 está haciendo que Internet sea menos seguro con esta recomendación. Esta "vulnerabilidad" de BS es un ruido más inútil que ahoga descubrimientos reales. La recomendación ciega de RFC-2385 de Rapid7 hace que la solicitud HTTP sea más difícil de procesar, lo que hace que el servidor web sea más propenso a los ataques DDoS.

Me quejaría a Rapid7 y los alentaría a que reconsideren seriamente esta recomendación de seguridad para el culto de la carga . Solo porque es fácil de probar, no significa que sea relevante. Pídale a Rapid7 que le diga a su cliente que esto no es una preocupación.

score 1 · Answer 2

1

Mi respuesta sería una versión atenuada de esto: "Están sugiriendo que usemos un esquema de autenticación de clave compartida sin cifrar diseñado para otro caso de uso. Su recomendación es extraña e inútil. No hay navegadores web que puedan generar el hash con clave requerido para cada segmento TCP ".

respondido por el StackzOfZtuff 30.12.2014 - 03:32

fuente

score 1 · Answer 3

Sin duda, su profunda experiencia con los exploradores de vulnerabilidades es mucho más que la mía, y su experiencia con las complejidades de TCP incluso mucho más. Pero tal vez pueda compartir mi método general de tratar con clientes que observan el resultado de un análisis de vulnerabilidad, ver un icono amarillo / naranja / rojo junto a un elemento y tener una reacción de gran preocupación sin darme cuenta de que no existe ningún problema real.

Explique que si bien los exploradores de vulnerabilidad a veces pueden ser notables en la detección de problemas sutiles pero vitales, también pueden ser absolutamente idiotas al ver problemas que no están respaldados por ningún riesgo sustancial en absoluto.
Explique por qué en este caso no existe ningún riesgo de seguridad adicional sustancial causado por este elemento. (Nota: todo esto obviamente supone que no hay, por supuesto). En otras palabras, explique por qué el escáner está equivocado y no le preste atención.
O bien (a) explica cómo, sin embargo, vas a corregir el problema sin problemas para que puedan sentirse bien al obtener una carta de salud limpia (aparente) o (b) si eso no es práctico, explique por qué el problema no puede ser prácticamente "arreglado" y cómo pueden documentar (por razones de cumplimiento, sus jefes, quien sea / lo que sea) que después de la investigación & contemplando, están seguros de que el problema es básicamente un tipo de falso positivo.

Parece que quizás tienes un "Pero ... pero ... ¡la herramienta costosa dice que hay una vulnerabilidad allí!" cliente. Tal vez intente una táctica para enfatizar que incluso si pudiera implementar este comportamiento de suma de comprobación de una manera que le gustaría al escáner, tomaría una buena parte de su tiempo (es decir, su dinero) y posiblemente incluso requeriría un tiempo de inactividad para el servidor. En mi experiencia, mencionar esas consideraciones es, de alguna manera, generalmente suficiente para que un cliente adquiera un nuevo sentido de aceptación acerca de vivir con una vulnerabilidad no vulnerable. Mis dos centavos, de todos modos.