martes, 26 de mayo de 2009

Bitácora de PSI.: Una de cuotas

En el capítulo anterior hemos hablado, entre otras cosas, de los sistemas de ficheros. Hoy trataremos de poner algunas barreras al campo en la forma de cuotas.

Es necesario definir cuotas en nuestros sistemas de ficheros, tanto locales como en red, especialmente en entornos multiusuario. Bueno, si tu máquina únicamente te tiene a ti por usuario, no será tan crítica esta tarea, aunque ...

Nuestro espacio de almacenamiento no suele ser infinito, por lo que será necesario limitar su uso. No es bueno dejar llenar nuestros discos duros. Como mínimo poner cuotas al número de bloques e inodes por usuario y, o, grupo. De forma resumida para vuestras máquinas de laboratorio podéis utilizar este mini-howto "Debian Disk Quota Management". Para asignar cuotas podrás utilizar el quotatool o el edquota. Normalmente se definen varias cuotas tipo a usuarios que se utilizan para asignar a otros usuarios:

$ sudo edquota -p ...

# for i in `cat /etc/passwd [pipe] cut -f1 -d:`; do edquota -p $i; done

Este último comando asignará cuota a todo usuario del /etc/passwd, incluido root, admin, etc. Si quieres asignárselo a un grupo determinado, según el caso, puedes utilizar algún pequeño "script" o comando para seleccionar los usuarios afectados.

En este punto, utilizamos unas viejas conocidas en el mundo de los procesos, las llamadas "fork bombs", que sirve para ilustrar la necesidad de configurar otro tipo de cuotas, como las de procesos. Es bastante habitual encontrarnos en la actualidad máquinas multiusuario con cuotas de disco, pero no de procesos. Tal vez la más conocida, publicada y comentada de las "fork bombs" sea :(){ :[pipe]:& };:

De forma resumida, abre un terminal como usuario y ejecuta dicha cadena. En el caso de que el sistema no tenga cuotas de proceso, se comerá el procesador de la máquina y la dejará tirada. Esta cadena es una función llamada : que se auto-llama de forma recursiva dos veces y que se vuelven a llamar, como diría el inminente Buzz Light Year, "hasta el infinito y más allá". Esta función se puede reescribir de la siguiente forma para una mejor comprensión:

mifuncion(){ mifuncion[pipe]mifuncion& };mifuncion

Para microsoft en un cmd si se ejecutas un fichero por lotes mifuncion.bat cuyo contenido sea %0[pipe]%0 el efecto será el mismo. Existen otras muchas fork bombs, pero que no tienen ningún interés más que el de ilustrar la necesidad de definir cuotas en los distintos subsistemas gestionados por nuestros sistemas operativos. Aunque aquí veremos cuotas para el sistema de ficheros y procesos, recuerda que también tenemos otros recursos que pueden requerir de cuotas, como por ejemplo nuestros interfaces de red (por IP, servicios, etc.), para evitar posibles abusos (traffic shapping y QoS).

En el caso de cuotas de proceso, en los equipos del laboratorio (debian) tienes el fichero de configuración de linux-pam /etc/security/limits.conf. En el que podrás definir cuotas para distintos elementos, por ejemplo.:

@colegas hard nproc 100
@enemigos hard nproc 10

La primera línea definiría un límite "hard" de número de procesos a los usuarios del grupo colegas de 60 y, en la segunda, de 10 para los enemigos.

* hard nproc 60

Esta línea establecerá un límite de procesos de 60 para todo bicho que pulule en el equipo, a excepción del root. No olvides que un proceso puede generar un gran número de procesos. Analizar el perfil de los procesos de tus usuarios y sus necesidades te permitirá definir la política de asignación de cuotas. Bajo ningún concepto debemos considerar la típica coña de "usuario bueno, usuario muerto". Nosotros trabajamos para ellos y, sin ellos, nuestro trabajo no tendría sentido.

Y, es suficiente con las cuotas que hemos visto?. En el caso del fichero /etc/security/limits.conf podrás definir, al igual que se hace con nproc, límites para otros parámetros (fuente fichero de configuración de las debian de laboratorio).:

core limits the core file size (KB)
data max data size (KB)
fsize maximum filesize (KB)
memlock max locked-in-memory address space (KB)
nofile max number of open files
rss max resident set size (KB)
stack max stack size (KB)
cpu max CPU time (MIN)
as address space limit
maxlogins max number of logins for this user
maxsyslogins max number of logins on the system
priority the priority to run user process with
locks max number of file locks the user can hold
sigpending max number of pending signals
msgqueue max memory used by POSIX message queues (bytes)
nice max nice priority allowed to raise to
rtprio max realtime priority

Otros muchos parámetros configurables del sistema los encontrarás en /etc/login.defs y /etc/pam.d/common-password

password required pam_unix.so nullok obscure min=4 max=8 md5

¿Qué opinas de la línea anteriore que puedes localizar en los ficheros common-password de las máquinas de laboratorio?. ¿Qué opinas del uso de password md5 de longitud mínimo 4?. ¿Debemos enviar al md5 a hacerle compañía al crypt?. De momento no, pero requiere unos ciertos cuidados, que recuerdan a los últimos días del crypt.

Para que puedas dedicar un poco de tiempo a probar alguna herramienta, señalar dos dedicadas a la reproducción de ataques por fuerza bruta sobre una gran cantidad de servicios, Medusa y THC Hydra. Sin entrar en IDSs de propósito general, existen herramientas para su detección y filtrado, como fail2ban, denyhosts, blocksshd o sshdfilter. Su funcionamiento se centra en la identificación en los ficheros de "log" de ataques por fuerza bruta desde determinadas IPs para su filtrado normalmente mediante iptables. Será necesario incluir excepciones, para no filtrar lo que no se debe, y tener en cuenta la posibilidad de paquetes IP spoofing que nos puedan producir el filtrado de equipos confiables.

Y la pregunta que está en el aire, ¿no vas a dar más niveles RAID?. Hemos llegado hasta aquí hablando de sistemas de ficheros y RAIDs, y no hemos terminado nuestra aventura. Es hora de cerrarla, y descubrir al asesino.

Se analiza el funcionamiento de los RAID3 y 4, de los que no incluyo en esta entrada nada, al no ser de gran interés para nosotros. El RAID5, uno de nuestros clásicos, ilustra la utilización de información de paridad distribuida entre un grupo de discos para garantizar la recuperación ante el "casque" de un disco duro. El RAID5 incrementa el rendimiento respecto al 3 y 4, evitando el cuello de botella de tener toda la paridad en un único disco duro.

Desde un punto de vista operativo, la mayoría de los RAID que montamos son 0, 1 y 5. Existen otros muchos RAID, pero no son de este mundo -:). Recuerda que los discos duros se pueden llenar (el próximo día de clase hablaremos de LVM), se pueden estropear, te los pueden robar. RAID puede proporcionar un cierto nivel de seguridad, pero no funciona ante un borrado accidental de ficheros, no sustituye al backup, no protege de incendios, inundaciones, etc. También puedes plantear hacer RAID sobre discos remotos, por ejemplo con Fibre Channel.

En algunas ocasiones los RAID se van de fiesta y se montan RAID10 (grupos de "mirrors" "stripeados") o RAID01 (grupos de "stripeados" "mirroreados") [estos últimos términos son el resultado de un proceso de fusión, mis disculpas a la RAE].

Aunque los RAID pueden incrementar el rendimiento también puedes plantear el uso de distintos planificadores de entrada salida a disco o ajustar algunos de sus parámetros. Sin duda alguna, el "tunning" es un deporte maravillo que, por desgracia, se practica poco.

Recuerda que la partición de swap puede darle mucho trabajo a tu disco. No te olvides dimensionar al swap adecuadamente, y meterlo en un disco rápido. También puedes crear varias particiones de swap y distribuirlas entre varios discos, asignándoles prioridades. De esta forma, tu swap podrá irse de vacaciones a varios discos, y utilizar eso que se llama acceso concurrente.

Otra instalación que puede sernos de interés es hacer "mirroring" del sistema operativo. Y finalmente, para que puedas crear, monitorizar y hacer todo tipo de pruebas con los RAID en los equipos del laboratorio, el mdadm.