¿Es seguro que un servidor de producción tenga instalado make?


42

Durante la configuración de mis instancias de servidor virtual, requiero que se creen algunas aplicaciones utilizando make. ¿Existen riesgos de seguridad asociados con la makeinstalación? ¿O debería limpiarlo antes de que se implemente la instancia?

También tengo el gcccompilador en el servidor que utilizo para crear aplicaciones antes de la implementación.


44
Si te hace sentir mejor, cualquier pieza de software instalada en cualquier lugar crea una vulnerabilidad.
MDMoore313

1
Y otra con no root acceso a una consola a un servidor puede descargar una "distribución independiente" paquete de compilador (.tar.gz) que no tendrá que ser instalado de manera ...

1
¿Soy yo, o es la combinación de "¿es seguro?" y "acceso root" bastante incómodo ?
ADN

2
Si ya tiene instalado gcc, prácticamente no hay forma de que eso pueda empeorar cualquier problema de seguridad potencial.
Shadur

1
@Shadur ¿Qué diferencia hace tener GCC? Si el usuario ya tiene acceso a la máquina, puede cargar cualquier copia de gcc trivialmente. De todos modos, gcc puede ser útil para usuarios sin privilegios y no un riesgo de seguridad, siempre que no lo ejecuten los usuarios con privilegios.
Vality

Respuestas:


50

Algunas personas argumentarán que la presencia de herramientas de desarrollo en una máquina de producción facilitará la vida de un atacante. Sin embargo, esto es un obstáculo tan pequeño para un atacante, que cualquier otro argumento que pueda encontrar a favor o en contra de instalar las herramientas de desarrollo pesará más.

Si un atacante pudo penetrar en el sistema hasta el momento, que podría invocar cualquier herramienta que esté presente en el servidor, entonces ya tiene una violación grave de seguridad. Sin las herramientas de desarrollo, hay muchas otras formas de escribir datos binarios en un archivo y luego ejecutar un chmod en ese archivo. Un atacante que quiera usar un ejecutable de compilación personalizado en el sistema en este momento podría construirlo en su propia máquina y transferirlo al servidor.

Hay otras cosas mucho más relevantes a tener en cuenta. Si una pieza de software instalada contiene un error de seguridad, hay algunas formas en que podría exponerse a un atacante:

  • El paquete podría contener un ejecutable suid o sgid.
  • El paquete podría estar iniciando servicios en el sistema.
  • El paquete podría instalar scripts que se invocan automáticamente en ciertas circunstancias (esto incluye trabajos cron, pero otros eventos pueden invocar scripts, por ejemplo, cuando cambia el estado de una interfaz de red o cuando un usuario inicia sesión).
  • El paquete podría instalar dispositivos inodes.

No esperaría que las herramientas de desarrollo coincidan con una de las anteriores, y como tal no es un paquete de alto riesgo.

Si tiene flujos de trabajo en los que utilizaría las herramientas de desarrollo, primero debe decidir si son flujos de trabajo razonables y, si lo son, debe instalar las herramientas de desarrollo.

Si descubre que realmente no necesita esas herramientas en el servidor, debe abstenerse de instalarlas por varias razones:

  • Ahorra espacio en disco, tanto en el servidor como en las copias de seguridad.
  • Menos software instalado hace que sea más fácil rastrear cuáles son sus dependencias.
  • Si no necesita el paquete, no tiene sentido asumir el riesgo de seguridad adicional de tenerlo instalado, incluso si ese riesgo de seguridad es pequeño.

Si decide que por razones de seguridad, no permitirá que los usuarios no privilegiados pongan sus propias etiquetas de ejecución en el servidor, entonces lo que debe evitar no son las herramientas de desarrollo, sino más bien los directorios que se pueden escribir para aquellos usuarios en sistemas de archivos montados con permisos de ejecución. Puede que aún se utilicen herramientas de desarrollo incluso en esas circunstancias, pero no es muy probable.


66
Agregaría a esto que varios sistemas de producción dependen del código interpretado (por ejemplo, PHP, Perl, Python, ...). Prohibir las herramientas de desarrollo en este contexto no tendría sentido. Consideraría que los compiladores gccno presentan un riesgo mayor que estos. Como usted dice, un atacante que esté en condiciones de utilizar los compiladores instalados en un sistema generalmente podría hacer cosas peores de todos modos, como cargar su propio ejecutable (posiblemente vinculado estáticamente).
Bruno

3
Relevante: una versión pequeña de wget (51 bytes?) . Un ejemplo de la vida real de un atacante que mueve echoun archivo binario al servidor utilizando declaraciones posteriores en un archivo. Todo el proceso está automatizado con un script que se encuentra en el mismo enlace.
Adi

2
@Adnan, interesante. Por lo que puedo decir, el principal defecto de seguridad en este ejemplo de DVR es el hecho de que el atacante puede acceder a él como root con la contraseña 123456 en primer lugar. Tener o no tener wget u otras herramientas (antes del ataque) es apenas relevante.
Bruno

15

makees un shell que tiene una sintaxis diferente que bash.

Un compilador como gcces un potente awkconfigurado con un conjunto de sustituciones que el estándar awkno admite. No es compatible con POSIX sorto catinyecta basura en la salida. Es un editor de texto interactivo (think vi) que está configurado para realizar algunas modificaciones al inicio y luego salir antes de mostrar la interfaz de usuario.

No hay nada inherentemente inseguro en ellos, no hacen que su máquina sea más insegura que una en la que tiene catredirección de shell bash + +.


2
Una respuesta tan zen que no sé cómo calificarla.
Kasperd

44
@kasperd Esta respuesta pretende ser seria. Pensé que traer el punto de vista de un programador podría ser útil. Una función que traduce una entrada en una salida no introduce una vulnerabilidad solo porque su salida está en un formato comprensible para la CPU.
ignis

1
Estoy de acuerdo con el punto que está haciendo. Creo que su respuesta es una gran lectura para cualquiera que ya esté de acuerdo con ella. Solo me preocupa que tu respuesta pueda parecer una broma para alguien que no está de acuerdo con ella.
Kasperd

Me gusta esta respuesta mucho más que la aceptada :)
Ruslan

15

makeen sí está bien makees simplemente un marco de automatización y seguimiento de dependencias. Sin embargo, generalmente se usa junto con compiladores, y aquellos que preferiblemente no deberían estar disponibles en un sistema de producción, ya que son completamente innecesarios. Lo mismo es válido para todos los paquetes innecesarios, ya sean bibliotecas compartidas, intérpretes, etc. El software instalado en los sistemas de producción debe controlarse estrictamente, y solo deben estar presentes los paquetes que requiere la aplicación.

Debería crear su aplicación en un servidor de compilación, empaquetarla y luego implementar el paquete binario en sus sistemas de producción.

Nota: las herramientas de embalaje nativas apestan . Ni siquiera te molestes en tratar de asimilarlos. En cambio, echa un vistazo a Jordan Sissel's fpm. Hace que el empaque sea una alegría absoluta.


8
Estoy preguntando por curiosidad e ignorancia aquí: ¿Por qué dice que la presencia de compiladores es un "problema de seguridad importante"? ¿Cuál es el problema de seguridad con tener un compilador instalado? ¿Es solo una cuestión de que no debería construir su código en un servidor de producción en primer lugar y, por lo tanto, el compilador es superfluo, o hay realmente un problema de seguridad significativo con la presencia del compilador?
reirab

11
Si bien es una buena idea construir sus aplicaciones en un servidor separado, decir que la presencia de compiladores en un sistema de producción es un problema de seguridad significativo no tiene sentido. ¿Qué pasa con los lenguajes de scripting y los sistemas compilados JIT (Perl, Python, Java, ...)?
Bruno

3
La presencia de compiladores en un entorno de producción no es un "riesgo de seguridad significativo". Yo mismo he movido archivos binarios a cajas comprometidas usando echoy base64. De hecho, incluso puede hacerlo con una serie de echodeclaraciones y ninguna otra herramienta .
Adi

1
Buenos puntos, todos. He editado mi respuesta para aclarar.
EEAA

9

Por el contrario, el problema potencial no es tener makeel servidor de producción, el problema potencial es construir las aplicaciones en el servidor de producción en lugar de implementar imágenes precompiladas probadas. Puede haber razones válidas para esta metodología, pero es una de las que argumentaría enérgicamente si me pidieran que la adopte.


4

Usted pregunta si makedebería instalarse en un servidor de producción, pero mi pregunta real sería: ¿Quién tiene acceso a ese servidor de producción y qué garantías tiene para hacer frente a una incursión? Si makeno se instaló pero alguien tiene rootacceso, ¿adivina qué? Se pueden instalar manualmente makey lo que quieran.

La dura realidad sobre la seguridad de la computadora es tanto como quieras evitar el acceso no deseado, estar obsesionado con bloquear el acceso no es tan importante como:

  1. ¿Quién tiene acceso al servidor?
  2. ¿Qué puede hacer para revertir después de una interrupción?

Todo esto depende de qué tipo de trabajo realice. Trabajo principalmente en el mundo de los servidores web y mi actitud es básicamente que cualquier persona que obtenga acceso al servidor de producción de mí debe demostrar habilidades, conocimiento y madurez. Eso es. A veces lleva unos días. A veces lleva meses. Pero básicamente, su mejor línea de seguridad en los servidores de producción es controlar el acceso además de otras cosas que hacemos para fortalecer los servidores.


1

makeen sí es inofensivo Todo lo que hace es ejecutar aplicaciones en un orden establecido, dependiendo de las dependencias que especifique y qué archivos ya existen en el sistema. Incluso puede ser útil como parte del proceso de instalación: puede usarlo para colocar archivos preconstruidos donde necesitan ir, o ejecutar pruebas unitarias u otras cosas.

Sin embargo, debe considerar para qué exactamente lo quiere usar. A menudo se utiliza en conjunción con los compiladores y otras herramientas para la creación de aplicaciones, y los que se podría utilizar para anular algunas de sus líneas de defensa. Pero makeno puede hacer estas cosas si las herramientas no están disponibles.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.