Next: El sistema de parcheado Up: Solaris Previous: Servicios de red Índice General
anita:/# passwd -s -a|grep LK daemon LK bin LK sys LK adm LK lp LK uucp LK nuucp LK listen LK nobody LK noaccess LK nobody4 LK anita:/#Podemos bloquear una cuenta de acceso a la máquina mediante `passwd -l', de la forma siguiente:
anita:/# passwd -s toni toni PS 06/15/01 7 7 anita:/# passwd -l toni anita:/# passwd -s toni toni LK 06/27/01 7 7 anita:/#A pesar de su estado, las cuentas bloqueadas son accesibles si ejecutamos la orden `su' como administradores, por lo que si estamos bastante preocupados por nuestra seguridad podemos asignarles un shell que no permita la ejecución de órdenes, como /bin/false10.6:
anita:/# su - adm $ id uid=4(adm) gid=4(adm) $ ^d anita:/# passwd -e adm Old shell: /bin/sh New shell: /bin/false anita:/# su - adm anita:/# id uid=0(root) gid=1(other) anita:/#Si realmente somos paranoicos, de la lista de usuarios que hemos visto antes incluso nos podemos permitir el lujo de eliminar a nobody4, ya que se trata de una entrada que existe para proporcionar cierta compatibilidad entre Solaris y SunOS que actualmente apenas se usa. No obstante, muchísimo más importante que esto es eliminar o bloquear a cualquier usuario sin contraseña en el sistema; es recomendable comprobar de forma periódica que estos usuarios no existen, para lo cual también podemos utilizar `passwd -s -a' y vigilar las claves cuyo estado sea `NP' (No Password):
anita:/# passwd -s -a|grep NP prueba NP anita:/# passwd -l prueba anita:/#Tras estas medidas de seguridad iniciales, lo más probable es que en nuestro sistema comencemos a dar de alta usuarios reales; sin duda, lo primero que estos usuarios tratarán de hacer es conectar remotamente vía telnet:
rosita:~$ telnet anita Trying 192.168.0.3... Connected to anita. Escape character is '^]'. SunOS 5.8 login: toni Password: Last login: Fri Jun 22 10:45:14 from luisa anita:~$A estas alturas ya debemos saber que es una locura utilizar telnet para nuestras conexiones remotas por el peligro que implica el tráfico de contraseñas en texto claro, por lo que debemos obligatoriamente utilizar SSH o similar. Si de cualquier forma no tenemos más remedio que permitir telnet (no encuentro ningún motivo para ello, y personalmente dudo que los haya...), quizás nos interese modificar el banner de bienvenida al sistema, donde se muestra claramente que la máquina tiene instalada una versión concreta de Solaris: esto es algo que puede ayudar a un pirata que busque información de nuestro sistema. Para cambiar el mensaje podemos crear el archivo /etc/default/telnetd, en el que la entrada `BANNER' especifica dicho mensaje:
anita:/# cat /etc/default/telnetd BANNER="\nHP-UX anita A.09.05 E 9000/735 (ttyv4)\n\n" anita:/# telnet 0 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HP-UX anita A.09.05 E 9000/735 (ttyv4) login:Algo similar se puede hacer con el fichero /etc/default/ftpd para el servicio de FTP, aunque de nuevo dudo que haya algún motivo para mantenerlo abierto; estos mensajes evidentemente no van a evitar que alguien pueda obtener datos sobre el sistema operativo que se ejecuta en una máquina (veremos al hablar del sistema de red en Solaris como conseguir esto), pero al menos no le dejarán esa información en bandeja.
luisa:~$ telnet anita Trying 192.168.0.3... Connected to anita. Escape character is '^]'. login: root Password: Not on system console Connection closed by foreign host. luisa:~$Esto es debido a que el parámetro `CONSOLE' tiene como valor dicha consola (/dev/console) en el fichero /etc/default/login; para trabajar como superusuario de forma remota es necesario acceder al sistema como un usuario sin privilegios y después ejecutar el comando su. Esta forma de trabajo suele ser la más recomendable, ya que ofrece un equilibrio aceptable entre seguridad y funcionalidad; no obstante, si nos interesara que root pudiera conectar directamente de forma remota (no suele ser recomendable), podríamos comentar la entrada `CONSOLE' en el fichero anterior, mediante una almohadilla (`#'). Si por el contrario queremos que el administrador no pueda conectar al sistema ni desde la propia consola, y sólo se puedan alcanzar privilegios de superusuario mediante la ejecución de su, podemos dejar la entrada correspondiente a `CONSOLE' en blanco:
anita:/# grep -i console /etc/default/login # If CONSOLE is set, root can only login on that device. CONSOLE= anita:/#En el fichero anterior (/etc/default/login) existen otros parámetros interesantes de cara a incrementar nuestra seguridad. Por ejemplo, el parámetro `TIMEOUT' indica el número de segundos (entre 0 y 900) que han de pasar desde que la máquina solicita el login al conectar remotamente hasta que se cierra la conexión si el usuario no lo teclea; esto nos puede ayudar a evitar ciertos ataques de negación de servicio, pero puede ser un problema si tenemos usuarios que conecten a través de líneas de comunicación lentas o muy saturadas, ya que con un timeout excesivamente bajo es posible que antes de que el usuario vea en su terminal el banner que le solicita su login la conexión llegue a cerrarse.
anita:~$ telnet 0 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. login: prueba Choose a new password. New password:Si realmente queremos asegurarnos de que no tenemos usuarios sin clave podemos ejecutar periódicamente la orden `logins -p', que nos mostrará los información acerca de los usuarios sin contraseña en la máquina; si su salida es no vacía, tenemos un grave problema de seguridad:
anita:/# logins -p prueba 107 staff 10 Usuari en proves anita:/# passwd prueba New password: Re-enter new password: passwd (SYSTEM): passwd successfully changed for prueba anita:/# logins -p anita:/#Para finalizar con /etc/default/login, vamos a hablar de un par de entradas en el fichero relacionadas con la auditoría de los accesos al sistema: el parámetro `SYSLOG' con un valor `YES' determina si se han de registrar mediante syslog los accesos al sistema como root, así como los intentos de login fallidos, y el parámetro `SYSLOG/SMALL>_FAILED/SMALL>_LOGINS' indica el número de intentos de entrada fallidos que se han de producir antes de emitir un mensaje de error; es recomendable que esta segunda variable tenga un valor `0', que implica que syslog registrará todos los intentos fallidos de login:
anita:/# grep -i ^syslog /etc/default/login SYSLOG=YES SYSLOG_FAILED_LOGINS=0 anita:/#Otro archivo interesante de cara a incrementar aspectos de la seguridad relacionados con los usuarios de nuestro sistema es /etc/default/passwd, donde se pueden definir parámetros para reforzar nuestra política de contraseñas; por ejemplo, podemos definir una longitud mínima para los passwords de los usuarios dándole un valor a la variable `PASSLENGTH':
anita:/# grep -i passlength /etc/default/passwd PASSLENGTH=8 anita:/#Por defecto, la longitud mínima de una clave es de seis caracteres; si le asignamos a `PASSLENGTH' un valor menor (algo poco recomendable de cualquier forma), el sistema simplemente lo ignorará y obligará a los usuarios a utilizar passwords de seis o más caracteres. Además, sea cual sea la longitud de las claves que definamos, debemos tener siempre en cuenta que Solaris sólo interpetará los ocho primeros caracteres de cada contraseña; el resto son ignorados, por lo que dos passwords cuyos ocho primeros caracteres sean iguales serán equivalentes por completo para el modelo de autenticación.
rosita:~$ telnet anita Trying 192.168.0.3... Connected to anita. Escape character is '^]'. login: toni Password: Your password will expire in 5 days. Last login: Sun Jun 24 03:10:49 from rosita anita:~$Como no todo va a ser hablar bien de Unix a cualquier precio (aunque Solaris tiene muchos aspectos para hablar bien del operativo), podemos hacer un par de críticas a mecanismos relacionados con las contraseñas en Solaris. En primer lugar, quizás deja algo que desear la granularidad que nos ofrece para el envejecimiento de claves: especificar los valores máximo y mínimo en semanas a veces no es apropiado, y seguramente si Solaris nos permitiera indicar dichos valores en días podríamos definir políticas más precisas; aunque en la mayoría de ocasiones la especificación en semanas es más que suficiente, en casos concretos se echa de menos el poder indicar los días de vigencia de una contraseña. Otro aspecto que se podría mejorar en Solaris es la robustez de las claves: limitarse a rotaciones del nombre de usuario es en la actualidad algo pobre; un esquema como el ofrecido en AIX, donde se pueden especificar incluso diccionarios externos al operativo contra los que comparar las claves que un usuario elige, sería mucho más potente.