Seguridad en Unix y redes - Parametros del núcleo

En el archivo /etc/system el administrador de un equipo Solaris puede definir variables para el núcleo del sistema operativo, como el número máximo de ficheros abiertos por un proceso o el uso de memoria compartida, semáforos y mensajes para intercomunicación entre procesos. En este apartado vamos a comentar algunos de estos parámetros que pueden afectar a la seguridad; hablaremos especialmente de aquellos que pueden y deben ser limitados para evitar diversos tipos de negaciones de servicio, ataques que recordemos afectan a la disponibilidad de nuestros recursos.

---

Si deseamos ver el valor de alguno de los parámetros en el kernel que se está ejecutando en este momento, lo podemos hacer con la orden adb (nótese que no ofrece ningún prompt, hemos de escribir directamente el parámetro a visualizar, con un `/D' al final para que nos muestre el valor en decimal):
anita:~# adb -k /dev/ksyms /dev/mem physmem 38da maxusers/D maxusers: maxusers: 56 maxuprc/D maxuprc: maxuprc: 901 ^d anita:~#

Una negación de servicio muy típica en Unix es el consumo excesivo de recursos por parte de usuarios que lanzan - voluntaria o involuntariamente - demasiados procesos; esto es especialmente común en sistemas de I+D, donde muchos usuarios se dedican a programar, y un pequeño error en el código (a veces denominado `runaway fork') puede hacer que el sistema se vea parado por un exceso de procesos activos en la tabla. La gravedad del problema aumenta si pensamos que también es muy habitual que los usuarios lancen simulaciones que tardan en ejecutarse varios días (o varias semanas), de forma que una parada inesperada puede causar la pérdida de muchas horas de trabajo. Por tanto, parece obvio que es recomendable limitar el número de procesos simultáneos por usuario; en Solaris este número está ilimitado por defecto, por lo que si deseamos asignar un valor máximo hemos de editar el fichero /etc/system e incluir una línea como la siguiente:

set maxuprc=60

De esta forma limitamos el número de procesos por usuario a 60 (un número aceptable en la mayoría de sistemas10.7), consiguiendo así que un error en un programa no sea capaz de detener la máquina.

---

Un parámetro del sistema operativo especialmente importante, y que quizás nos interese modificar (sobre todo en máquinas con pocos recursos) es maxusers. Al contrario de lo que mucha gente cree, maxusers no hace referencia al número máximo de usuarios que pueden conectar simultáneamente al sistema, sino que es un valor que escala a otros parámetros del núcleo (como max_nproc, número máximo de procesos en la tabla) o maxuprc. Para modificarlo, podemos incluir en /etc/system una línea con el valor deseado, generalmente el tamaño en MB de la memoria física de nuestra máquina ([Dik99]):
set maxusers=128

También puede ser conveniente limitar parámetros del sistema operativo relativos al sistema de ficheros, ya que también se pueden producir negaciones de servicio relacionadas con ellos. Por ejemplo, es interesante poder limitar el número máximo de ficheros abiertos mediante los parámetros rlim_fd_max (límite hard) y rlim_fd_cur (límite soft) o evitar que los usuarios puedan utilizar chown() en sus ficheros, especificando un valor 1 para la variable rstchown (este es el comportamiento por defecto; si no lo seguimos, aparte de comprometer la seguridad los usuarios sin privilegios podrían ignorar el sistema de quotas).

---

Dejando ya de lado los límites que se pueden imponer a los recursos consumidos por los usuarios del sistema, existe otra serie de parámetros del núcleo interesantes para aumentar la seguridad de un sistema Solaris. Por ejemplo, en algunas arquitecturas SPARC (concretamente en sun4u, sun4d y sun4m) es posible, desde Solaris 2.6, establecer una protección hardware para prevenir ataques de buffer overflow. Esta protección consiste en impedir que los programas puedan ejecutar código en su pila, recibiendo la señal SIGSEGV si tratan de hacerlo: para ello, en /etc/system hemos de incluir una línea como
set noexec_user_stack=1

Y si además queremos monitorizar los intentos de ataque de este tipo (como mensajes del núcleo de Solaris, con priority `kern' y nivel `notice', por defecto en /var/adm/messages), podemos incluir en el archivo la línea

set noexec_user_stack_log=1

Si administramos un servidor NFS y deseamos que ignore las peticiones de clientes que no provengan de puertos privilegiados (es decir, que no hayan sido solicitadas por un usuario privilegiado de la máquina cliente) podemos definir la variable NFS/SMALL>_PORTMON en /etc/system; si usamos versiones de Solaris anteriores a la 2.5, debemos incluir una línea como

set nfs:nfs_portmon = 1

mientras que en Solaris 2.5 y posteriores utilizaremos

set nfssrv:nfs_portmon = 1

Por último, como ya comentamos en el punto dedicado a la seguridad EEPROM, podemos deshabilitar el acceso que se consigue a la misma al pulsar la combinación de teclas `Stop-A' en un teclado Sun; para ello es necesario añadir en el fichero /etc/system una entrada como

set abort_enable=0

Antes de finalizar este punto, es necesario tener en cuenta que los cambios que se realicen en /etc/system no tendrán efecto hasta que la máquina se reinicie, y que un pequeño error en los contenidos de este archivo puede provocar que un sistema no arranque, por lo que es siempre recomendable guardar una copia antes de realizar cualquier modificación del fichero.