¿Qué tan peligroso podría ser (y qué ganancias de rendimiento se pueden obtener) al desactivar las mitigaciones de vulnerabilidad en servidores que no tienen acceso a Internet?

Question

Cuando un servidor host Linux de máquina virtual no tiene acceso a Internet y se usa exclusivamente en una LAN y utiliza una distribución relativamente bien probada como Proxmox, ¿qué tan peligroso sería desactivar todas las mitigaciones de vulnerabilidad a través del kernel arg mitigations=off?

Además, ¿alguien ha probado qué tipos de mejoras de rendimiento podrían observarse al desactivar todas esas mitigaciones?

Recientemente, esto se convirtió en una pregunta para mí cuando vi este gran impacto que retbleedcrean las mitigaciones:https://www.phoronix.com/review/retbleed-benchmark

Esta línea de pensamiento se extendió a la curiosidad de cuáles podrían ser las ramificaciones (tanto negativas como positivas) de eliminar todas o algunas mitigaciones, ya sea a través del argumento central anterior o desactivando individualmente las mitigaciones de alto impacto.

Answer 1

El indicador del kernel de Linux mitigations=[on|off]es una opción única para habilitar/deshabilitar fácilmente todas las mitigaciones del kernel disponibles para las vulnerabilidades de hardware que se enumeran aquí.https://docs.kernel.org/admin-guide/hw-vuln/index.html

El impacto de esto depende, por supuesto, completamente de su CPU:

• Cuando su CPU no es vulnerable a ninguna de las vulnerabilidades conocidas, ninguna de las mitigaciones es aplicable y el impacto debería ser efectivamente cero.

• Cuando su CPU es vulnerable a algunos (¿hay incluso CPU vulnerables a algunos?)todo¿Cuáles de ellas?) el impacto depende de qué vulnerabilidades específicas y su carga de trabajo.

En cuanto al análisis de riesgos, también depende de su carga de trabajo y base de usuarios.

En un host de virtualización operado por un proveedor VPS público, se confía menos en los invitados y es mucho más probable que sean maliciosos (o estén comprometidos) de lo que esperaría en un host de virtualización interno utilizado exclusivamente por mis colegas.

Por ejemplo, en nuestros hosts de virtualización utilizados para canalizaciones de CI/CD y clústeres de computación, todos los invitados duran poco, se implementan a partir de imágenes confiables, se ejecutan por hasta un par de horas y luego se destruyen nuevamente. Allí necesitamos todo el rendimiento que podamos obtener y desactivar las mitigaciones.

En un clúster compartido diferente hospedamos cargas de trabajo de consolidación de servidores más clásicas; los invitados que se despliegan allí pueden (y es más probable que lo hagan) funcionar "para siempre" en lugar de durante horas. Tiene una combinación de cargas de trabajo de producción y no producción y los invitados son administrados por equipos de DevOps que no son tan diligentes a la hora de parchear y actualizar sus sistemas y aplicaciones.
Allí, el riesgo de un invitado malintencionado o comprometido es mucho mayor, la posible reducción del rendimiento para cargas de trabajo específicas es una compensación aceptable y, por lo tanto, las mitigaciones se habilitan allí y limitamos qué indicadores de CPU quedan expuestos a los invitados.

Answer 2

¿Es realmente imposible conectarse al servidor, incluso indirectamente desde fuera de su red?

Esa es la primera pregunta que debes hacerte. Si se puede acceder a la LAN desde una máquina que tiene 2 conexiones de red, una a esa LAN y otra a otra red que esté conectada a Internet (con suerte a través de varias capas de firewalls), simplemente conectó ese servidor a Internet.

Y recuerde que una máquina no necesita estar conectada a Internet para ser vulnerable a ataques. Una máquina podría estar infectada con malware que simplemente intenta dañarla a través de una memoria USB, un disquete o incluso escribiendo comandos en una terminal.

Al final, toda seguridad, como todas las mejoras de rendimiento, es un compromiso. ¿Cuál es un nivel de riesgo aceptable para las recompensas obtenidas?

Para conocer sus posibles ganancias de rendimiento, ejecute pruebas en la máquina mientras no tenga ninguna conexión de red y compruébelo usted mismo. Lo más probable es que no sea mucho, pero podría ser suficiente para exprimir esos pocos ciclos de CPU adicionales que ayudan a que el hardware antiguo sobreviva un poco más para que usted tenga tiempo de convencer a la alta dirección de que realmente, realmente, debería hacerlo. Obtenga el presupuesto para un nuevo servidor.

Answer 3

"... se usa exclusivamente en una LAN y utiliza una distribución relativamente bien probada como Proxmox, ¿qué tan peligroso sería desactivar todas las mitigaciones de vulnerabilidad a través del kernel arg mitigations=off?"
...
"Esta línea de pensamiento se extendió a la curiosidad de cuáles pueden ser las ramificaciones, tanto negativas como positivas, de eliminar todas o algunas mitigaciones, ya sea a través del argumento central anterior o desactivando individualmente las mitigaciones de alto impacto".

Es posible que aún desee considerar la responsabilidad y el mayor tiempo para reparar incluso una pequeña cantidad de problemas.

Dicho esto, la mayoría de las mitigaciones ya están implementadas en las CPU más nuevas; por lo tanto, desactivarlos produce una pérdida pequeña o pequeña de rendimiento en los sistemas más nuevos; sí, generalmente es más lento con las mitigaciones desactivadas; pero como cualquier punto de referencia hay excepciones.

"... ¿qué tipo de mejoras en el rendimiento podrían observarse al desactivar todas esas mitigaciones?"

Michael Larabel de Phoronix dice:

En su artículo del 7 de diciembre de 2022:"Comparación del rendimiento del impacto de la mitigación de Intel Raptor Lake":

"... en su mayor parte, las mitigaciones involucradas en el software que aún son relevantes para Raptor Lake se pueden dejar activas sin ninguna diferencia significativa en el rendimiento".

En su artículo del 30 de septiembre de 2022:"Con AMD Zen 4, sorprendentemente no vale la pena deshabilitar las mitigaciones de seguridad de la CPU":

"... para el amplio espectro de 190 pruebas comparativas diferentes realizadas, mantener las mitigaciones predeterminadas fue aproximadamente un 3% más rápido en general que ejecutar con las mitigaciones = desactivadas. Básicamente, lo opuesto a lo que normalmente vemos con otros procesadores más antiguos".

Con sistemas más antiguos, aún debe considerar que los empleados descontentos puedan elevar sus privilegios o dañar su LAN antes de su salida. Parte de su insatisfacción puede deberse a que tienen equipos anticuados, que utilizan en su contra. Además, un teléfono celular conectado rompería la presunción de "no estar conectado a Internet", cargar el teléfono y ejecutar una aplicación no deseada o abrir un correo electrónico cuidadosamente elaborado sólo puede explotar las vulnerabilidades que existen.