¿Deshabilitar Perl para algunos / la mayoría de los usuarios de Linux?

Estoy de acuerdo con Gilles en que deshabilitar Perl no es una seguridad efectiva; ya que hay muchas otras formas en que podría ser atacado (por ejemplo, un script de python; un script de bash; un script de php; un ejecutable) y que restringir /usr/bin/perl a ciertos grupos de usuarios puede tener efectos secundarios (por ejemplo, ese programa que llama a script perl como usuario ordinario).

Sin embargo, como punto de partida, de manera sencilla si tiene una aplicación en Linux que desea restringir a ciertos usuarios, primero cree un grupo y luego agregue usuarios a ese grupo. Los siguientes comandos logran esto en ubuntu (creando el grupo perl y agregando user1, user2, user3 a él:

sudo addgroup perl
sudo adduser user1 perl
sudo adduser user2 perl   
sudo adduser user3 perl

Ahora encuentre dónde está perl actualmente ( which perl , que en mi sistema era /usr/bin/perl ) encuentre lo que es la propiedad y los permisos de perl actualmente ( ls -l /usr/bin/perl en ubuntu está configurado de forma predeterminada como propiedad del usuario root y en la raíz del grupo) con todas las personas que tengan permisos de lectura / ejecución, que debe deshabilitar para otros usuarios a menos que estén en el grupo perl:

sudo chgrp perl /usr/bin/perl
sudo chmod o-rx /usr/bin/perl

Tenga en cuenta que un atacante en su sistema que no sea miembro del grupo perl, si puede llegar a un terminal podría cargar su propia versión del ejecutable de perl (o si no eliminó el acceso de lectura a otros usuarios). ; podrían haberlo copiado) a algún directorio local / tmp, establecer el bit ejecutable en él (si pueden ejecutar chmod ), y luego usar ese script perl de ejecución fuera de su propio ejecutable.

Deshabilitar Perl es inútil. El exploit que se puede escribir en Perl también se puede escribir en otro idioma. Digamos, PHP, que obviamente no vas a deshabilitar.

Si toma un sistema que ya es muy seguro (como en: las vulnerabilidades son raras y tienden a afectar solo a una pequeña parte del sistema sin una forma directa de habilitar la ejecución de código arbitrario), entonces puede valer la pena inhabilitar Todos los métodos de scripting. Esto puede limitar el grado en que algunas vulnerabilidades pueden ser explotadas. Por ejemplo, si solo puede inyectar un pequeño número de caracteres ASCII, escribir un ejecutable de la máquina puede ser un gran desafío, mientras que escribir un script sería trivial.

Contra el tipo de vulnerabilidad que encontró, deshabilitar intérpretes no ayudaría. El atacante podría subir PHP, o código de máquina. Estás disparando al mensajero.

El ataque que está experimentando se llama una técnica de Inclusión remota de archivos (RFI). Básicamente, es el resultado de una aplicación web vulnerable que se aprovecha para cargar códigos maliciosos para generar un shell remoto.

No es necesario que deshabilites específicamente Perl. Puede comenzar a identificar la aplicación vulnerable como, por ejemplo, phpBB que usa el atacante, luego aplicar un parche o eliminar esa aplicación por completo y reemplazarla con una versión actualizada.

Debido a que el cuadro está comprometido, en su mayoría no es seguro simplemente confiar en el método anterior, dado que es posible que ya hayan instalado una puerta trasera en su host. Si tiene un acceso físico al servidor, intente bajarlo a la red. Si tiene acceso remoto, simplemente trabaje con las reglas del cortafuegos y asegure el acceso solo a su ubicación de origen (dirección IP).

Una cosa que puedes hacer es NEGAR explícitamente todo el tráfico entrante de la capa de red y ESPECIFIQUE el tráfico solo para un puerto dado o usado: TCP / 22,80 para asegurarte de que puedan haber instalado una puerta trasera en un puerto diferente de los dos, no se unirá y generará un shell remoto.

La eliminación de Perl interrumpirá todas las aplicaciones dependientes de Perl que se ejecutan en tu host.