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.
© 2002 Antonio Villalón Huerta