¿Cómo puedo fortalecer los compiladores (como lo sugiere Lynis)?

1

Este artículo sugiere restringir los compiladores a la raíz, pero no dice cómo, y no pude encontrar nada. Útil buscando en la web.

ii  g++                                4:5.3.1-1ubuntu1                    i386         GNU C++ compiler
ii  g++-5                              5.4.0-6ubuntu1~16.04.1              i386         GNU C++ compiler
ii  gcc                                4:5.3.1-1ubuntu1                    i386         GNU C compiler
ii  gcc-4.7                            4.7.4-3ubuntu12                     i386         GNU C compiler
ii  gcc-4.7-base:i386                  4.7.4-3ubuntu12                     i386         GCC, the GNU Compiler Collection (base package)
ii  gcc-4.8                            4.8.5-4ubuntu2                      i386         GNU C compiler
ii  gcc-4.8-base:i386                  4.8.5-4ubuntu2                      i386         GCC, the GNU Compiler Collection (base package)
ii  gcc-5                              5.4.0-6ubuntu1~16.04.1              i386         GNU C compiler
ii  gcc-5-base:i386                    5.4.0-6ubuntu1~16.04.1              i386         GCC, the GNU Compiler Collection (base package)
ii  gcc-6-base:i386                    6.0.1-0ubuntu1                      i386         GCC, the GNU Compiler Collection (base package)
  1. ¿Cuál de estos compiladores puedo eliminar (en un servidor web de Ubuntu)?
  2. ¿Debo eliminar intérpretes como Python y Ruby también?
  3. ¿Qué comandos de Bash puedo usar para fortalecer los compiladores necesarios?
pregunta forthrin 03.08.2016 - 13:12
fuente

4 respuestas

3

La seguridad siempre es un equilibrio entre la facilidad de uso y la protección. El sistema más seguro que puedo imaginar es una computadora apagada que se encuentra en una caja fuerte del banco. Desafortunadamente, también es difícil de usar ... Eliminar los compiladores o, peor aún, restringirlos a la raíz en una prueba o en un sistema dev sería una tontería: o ya no puede usarlo o siempre iniciará sesión como root. Las cosas son diferentes en un servidor de producción único donde normalmente se pueden eliminar.

Pero casi no puedo imaginar cómo eliminar un compilador podría asegurar un servidor Ubuntu. En cuanto a cualquier sistema similar a Debian, los paquetes generalmente se instalan en forma binaria, lo que significa que si un atacante tiene acceso de escritura a una carpeta, puede depositar un programa construido en su propia máquina y usarlo allí. Y si no tiene acceso de escritura, tampoco podrá crear un archivo ejecutable.

Este consejo, como muchos otros sobre seguridad por ofuscación , se parece a aceite de serpiente . Eso no debería causar muchos daños, pero tampoco protegerá realmente nada ... Pero es algo que es fácil de implementar en una herramienta de auditoría automática y se puede vender

Si realmente desea asegurar un servidor de producción, no se centre en los compiladores, sino que elimine con cuidado todas las herramientas de red (y genéricas) que no se usan allí, y configure los cortafuegos para bloquear la cantidad de y salientes entrantes conexiones posibles: si un servidor se vio comprometido, será realmente más difícil para el atacante rebotar en otro. Pero esto no puede hacerse con una herramienta automática, ya que debe adaptarse al entorno real y al caso de uso preciso del servidor. Una vez hecho esto, es posible que los compiladores ya se hayan ido pero honestamente no me importaría. Si desea ir un paso más allá, también compile un kernel personalizado que contenga solo los controladores utilizados en su entorno. De acuerdo, no puede compilar un kernel si ha eliminado compiladores, pero debería estar construido y probado en El sistema de desarrollo o pre-prod. De esa forma, los chavales que intentan utilizar las direcciones del kernel habituales no podrán encontrarlas.

TL / DR: mi consejo es que no sabes qué compilador se puede eliminar de forma segura o cómo puedes restringirlo a la raíz, ni siquiera intentes hacerlo . Simplemente siga las mejores prácticas comunes:

  • nunca use la cuenta de root para nada que no lo requiera
  • solo sudo comandos individuales o por un corto tiempo
  • nunca permita que un servidor se ejecute como root (a excepción de su tiempo de inicialización ...) y asegúrese de que deja todos los privilegios innecesarios antes de aceptar solicitudes
  • asegure su firewall lo mejor que pueda y prohíba todos los accesos innecesarios
  • no instale software innecesario o no controlado

Y no confíe en las herramientas de auditoría automática para más de lo que pueden hacer. Una auditoría de seguridad seria realmente cuesta tiempo y dinero ...

    
respondido por el Serge Ballesta 03.08.2016 - 14:03
fuente
1

Desde la perspectiva de un hacker / pentester, puedo decir que tener un compilador en una máquina objetivo y / o python / ruby puede ser muy útil. Así que estoy de acuerdo con una de las respuestas anteriores de que eliminarlo de un servidor de producción aumenta la seguridad. Sin embargo, esas herramientas solo son útiles para los atacantes que ya tienen un shell limitado en su sistema. En ese caso, puede hacer que su vida sea más difícil al no darles herramientas útiles adicionales que necesitan para la escalada de privilegios. Pero esto no es una gran ganancia en seguridad. Querría evitar que obtengan un shell en primer lugar y eso no tiene nada que ver con un compilador o una herramienta de interpretación. Por otro lado, eliminar gcc y python / ruby en un servidor de producción probablemente tampoco sea un gran problema, así que ¿por qué no hacerlo? Como se dijo anteriormente, no veo por qué un servidor de producción necesita un compilador. Si necesita python / ruby, depende del software que se ejecute en esa caja. Si ningún software depende de python / ruby, puede desinstalarlo sin preocuparse. Permitir gcc solo para root también ayudaría a evitar que alguien lo use para la escalada de privilegios. Pero me preguntaría cuál es el beneficio en comparación con eliminarlo, o en otras palabras: ¿qué usuario root lo necesita?

    
respondido por el kaidentity 03.08.2016 - 16:04
fuente
0

Debería poder eliminar de forma segura los compiladores de C y C ++. Hacerlo es relativamente simple y normalmente indoloro. Es probable que sea una ganancia relativamente pequeña en seguridad, pero para un entorno de servidor de producción es poco probable que necesite un compilador de C o C ++. Probablemente me pregunte por qué alguien necesita crear un código de producción en un servidor de producción. Es probable que las ganancias de seguridad no sean terriblemente altas, pero los costos también son generalmente muy bajos.

Eliminar intérpretes como Python o Ruby es potencialmente un poco más costoso, ya que las herramientas de administración a menudo están escritas en estos idiomas, lo que puede costarle cierta utilidad y flexibilidad. Su caso de uso particular debe tenerse en cuenta.

Solo tenga en cuenta que la eliminación de diferentes compiladores e intérpretes presenta un espectro de utilidad frente a seguridad. Eliminar el intérprete de bash, por ejemplo, haría que el sistema sea difícil o imposible de administrar, ya que los scripts de bash se utilizan en todas partes para iniciar / detener servicios y mantener el software.

    
respondido por el Steve Sether 03.08.2016 - 15:38
fuente
0

La seguridad es el arte de hacer las cosas bien, incluso si en sí mismas no siempre parecen tener un gran impacto. La principal razón para eliminar o restringir el uso de compiladores en sistemas de producción ya está en kaidentity. El artículo sobre escalada de privilegios (en el enlace referido), da alguna idea de cómo funciona y cómo puede defenderse eliminando el compilador o restringiendo su uso.

    
respondido por el Michael Boelen 04.08.2016 - 07:53
fuente

Lea otras preguntas en las etiquetas