¿Instalar herramientas de desarrollo en el servidor de producción? ¿Riesgo de seguridad?

La regla general para los sistemas es: si no la necesita, no la instale. Tal vez deberíamos modificarlo para: si ya no lo necesita, desinstálelo.

¿Por qué? Para reducir la "superficie de ataque" disponible en el sistema, es decir, programas y utilidades que se pueden comprometer o usar como parte de un compromiso. Esa es la justificación general.

El riesgo específico para las herramientas de desarrollo es que si un atacante obtiene acceso a un usuario sin privilegios, es posible que pueda usar, por ejemplo, gcc para compilar código arbitrario en su casilla. Dicho esto, es probable que también esté ejecutando un intérprete como python, o tenga javac para aplicaciones web o similares, por lo que el impacto real del material podría no ser muy diferente.

Personalmente no veo nada de malo en instalar las herramientas de desarrollo (las jalaría manualmente con yum install <tool> para que luego puedan ser yum remove 'd) y luego eliminarlas una vez que se cumpla su propósito. Después de todo, toda esta charla de compilación de código abitrario en usuarios no privilegiados en realidad pierde el sentido: en esa etapa, alguien ya se ha posicionado en su sistema y eso es lo que quiere evitar.

En lo que respecta a las políticas, el hecho de no tener herramientas de desarrollo en un servidor web es una buena idea, ya que desalienta a los desarrolladores a "hacerlo en vivo". No es que lo haríamos, pero bueno ... probablemente lo haríamos :)

Además de la respuesta correcta de @ Karrax, en relación con el aumento de la superficie de ataque, las posibles explotaciones y el entorno de ataque más fácil para un pirata informático potencial, quería señalar un problema más que debería ser obvio, pero es a menudo dolorosamente no.

Estas son las herramientas de desarrollo . En un servidor de producción .
De ello deduzco que los desarrolladores no solo tienen acceso al servidor de producción, sino que aparentemente tienen la intención de desarrollarlo .
Esto, por sí mismo, tiene muchos riesgos asociados, a saber:

• Acceso no autorizado a datos de producción
• No hay privilegios mínimos posibles
• Sin segregación de tareas (SoD)
• Es muy probable que haya muchos archivos de código antiguos, de prueba y no utilizados
• Es muy probable que haya muchos archivos de configuración antiguos, de prueba y sin usar, por ejemplo, con un tipo de archivo .bak , que permite a cualquier usuario descargar y robar contraseñas, etc.
• No hay pruebas de seguridad antes de la implementación
• Es fácil de abrir en puertas traseras ocultas, debido a lo anterior
• Obviamente, no hay SDL (ciclo de vida de desarrollo de seguridad) implementado
• Y más.

Lo que quiero decir es que el problema no es solo instalar las herramientas de desarrollo, sino que el problema más grande es el proceso y el entorno a su alrededor que causaría dicho plan en primer lugar.

Sí , cualquier adición al software que instales en tu entorno aumentará la superficie de ataque que un atacante puede usar para comprometerte a ti y a tus sistemas.

Las herramientas en este paquete pueden contener exploits conocidos u otros exploits aún no descubiertos que pueden comprometer aún más su sistema.

En general, diría que es la mejor práctica mantener el desarrollo y la producción lo más separados posible, sin embargo, cada empresa puede tener su propio análisis de riesgo / consecuencia y costo, tal vez en su caso específico puede ser un riesgo aceptable.

¡Tenga en cuenta que en su caso está instalando 'herramientas de desarrollo'! Esto puede suponer un riesgo de seguridad adicional, ya que esencialmente está dejando un compilador perfectamente bueno (y otras herramientas) diseñado para este sistema específico, en su sistema. En muchos casos, esto hace que sea más trivial que el atacante compile y ejecute más código de explotación una vez que se haya visto comprometido, sin embargo, en algunos casos especiales (en los que quizás necesite un compilador especial), será demasiado fácil para el atacante. has sido comprometido

EDITAR: Como Gilles comenta, el último ejemplo es muy poco probable en su caso específico. Me gustaría citar a Gilles porque es exactamente lo que quise incluir en mi ejemplo:

  

en un sistema donde el atacante tiene un ancho de banda limitado o solo puede inyectar caracteres imprimibles, o en un sistema exótico para el cual obtener un compilador o construir uno es caro. Pero aquí estamos hablando de un sistema con una conexión de red rápida y que el atacante puede reproducir por unos pocos dólares