Malware humano – Protegiendo un servidor de los usuarios

En el proceso de bastionado de un servidor, lo usual es protegerlo contra ataques procedentes de fuera de la máquina. Añadimos mil y una medidas, como las que comenté en un post anterior. Sin embargo, es muy habitual obviar la seguridad interna, porque se confía en exceso en los trabajadores y no se valora adecuadamente el impacto que puede producir un ataque accidental o intencionado. Ex-empleados cabreados que conservan credenciales de acceso, ingeniería social a personal interno, o manazas, son algunos ejemplos de estas muestras de “malware” tan particular, porque sinceramente, ¿quién no ha tenido ganas de hacer alguna vez un rm -rf /? ;)

Vamos a describir unas cuantas indicaciones para asegurar el servidor de estos posibles ataques internos.

1. Política de contraseñas

Este es un clásico imprescindible en cualquier tipo de autenticación a un servicio. Por ejemplo, una política que imponga una longitud mínima de contraseña, el uso de mayúsculas y números, y que no sea una palabra de diccionario. Por desgracia, no se usa tanto como se debería y permite que herramientas de bruteforcing como thc-hydra o John the Ripper sigan siendo muy útiles hoy día.

Pongamos como ejemplo, el acceso a la consola de una máquina Linux, aunque estas restricciones también pueden y deben ser aplicables a otros sistemas de autenticación, como correo, LDAP, Active Directory etc, etc.

En primer lugar vamos a añadir caducidad a las contraseñas, para que solo sean válidas para un tiempo determinado. Editamos los siguientes valores en el fichero /etc/login.defs

PASS_MAX_DAYS	180
PASS_MIN_DAYS 	1
PASS_WARN_AGE	30

Con esto conseguimos que en las nuevas cuentas que se creen a partir de ahora, sus contraseñas tengan una vida máxima de 180 días y un plazo de 30 días para que avise al usuario de que debe cambiarla. También se limita el poder cambiarse la contraseña una única vez al día, después veremos porqué.

Sin embargo, estas restricciones se aplican únicamente a los usuarios creados a partir de ese momento. Es necesario aplicar estas restricciones a los usuarios que ya han sido creados anteriormente. Para eso usaremos el comando chage:

# chage -m 1 -M 180 -W 30 usuario

Una forma de automatizar el proceso con los usuarios del sistema sería con el siguiente script (es una idea, posiblemente no sea correcto en algunos sistemas, y habrán formas más decentes de hacerlo, así que por favor no me tiréis piedras ;))

for directorio in /home/*; do
	chage -m 1 -M 180 -W 30 ${directorio:6}
done

Vamos a configurar ahora restricciones a la hora de elegir la contraseña. Para eso hay que editar el fichero /etc/pam.d/common-password. Veámoslo con el siguiente ejemplo:

password requisite pam_cracklib.so retry=2 minlen=8 difok=2 dcredit=-1 
     ucredit=-1 lcredit=-1 ocredit=-1 
password [success=1 default=ignore] pam_unix.so obscure use_authtok 
     try_first_pass sha512 remember=12 
password requisite pam_deny.so 
password required pam_permit.so

En este caso hemos impuesto que la contraseña deba tener un mínimo de 8 caracteres, con la restricción de tener obligatoriamente al menos una mayúscula, un dígito y un carácter especial. Además no se podrá usar una contraseña que se parezca en dos caracteres. El sistema también recordará las últimas 12 contraseñas utilizadas para que no se pueda repetir (por eso la restricción de cambiarse la clave una única vez al día). Finalmente, el modificador “obscure” hace unas comprobaciones extra, que la clave utilizada no se encuentre en el diccionario, no sea palíndromo de la anterior, etc. Para utilizar el módulo pam_cracklib.so del ejemplo, es necesario instalar el paquete libpam-cracklib.

2. Límite de procesos

Estas restricciones también son muy importantes ya que un simple “forkbomb” utilizado con permisos de usuario puede dejar completamente frito un servidor en cuestión de segundos. Para eso debemos editar el fichero /etc/security/limits.conf y añadir la siguiente linea:

*      hard   nproc      2048

Con esto limitamos a un máximo de 2048 procesos por usuario. Este fichero permite además definir restricciones al uso de CPU, de memoria, entre otros. Podéis encontrar más información en el manual de Debian. Podéis hacer la prueba de los cambios realizados probando a utilizar el famoso forkbomb:

$ :(){ :|:& };:

¡Mucho ojito donde se prueba este comando! Como ya he comentado antes, usar esto en un entorno no preparado contra estos ataques puede tumbar un equipo en pocos segundos.

3. Límite de espacio en disco

Otra restricción habitual es limitar el espacio de almacenamiento máximo en una partición, para evitar que colapse todo el espacio libre de forma accidental o intencionada. Para eso lo adecuado es implantar políticas de cuota de disco, y así controlar el máximo de espacio usado a cada usuario. Lo primero es instalar el paquete quota en el sistema. Después es necesario añadir los siguientes parámetros en la configuración de la partición en /etc/fstab:

/dev/sda2 /home ext4 defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 1 2

A continuación se “remonta” la partición para que se apliquen los cambios, se crean ficheros necesarios con sus permisos correspondientes, y se activan las cuotas de disco recién configuradas:

mount -o remount /
touch /quota.user /quota.group
chmod 600 /quota.*
quotacheck -avugm
quotaon /

Ahora podemos aplicar los valores de las cuotas a cada usuario:

# edquota user

Donde se puede configurar el número de bloques e i-nodos a ocupar definiendo unas cuotas de gracia (soft) o absolutos (hard). Y con esto, acaba este breve repaso a algunas medidas necesarias para hacer de nuestros servidores un sistema un poquito más seguro y libre de esos auténticos “virus” de carne y hueso.