Durante la instalación de Solaris se crean en /etc/passwd una serie de entradas correspondientes a usuarios considerados `del sistema' (adm, bin, nobody...); ninguno de estos usuarios tiene por qué acceder a la máquina, de forma que una buena política es bloquear sus cuentas. Podemos comprobar qué usuarios tienen el acceso bloqueado consultando el estado de su contraseña: si es `LK' (locked), la cuenta está bloqueada:
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.
Siguiendo con las conexiones remotas a un sistema, uno de los aspectos que nos puede llamar la atención si estamos comenzando a trabajar con Solaris es que el usuario root sólo puede conectar desde la propia consola de la máquina; si lo intenta de forma remota, se le negará el acceso:
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.
Relacionada en cierta forma con el parámetro anterior, y también dentro del archivo
/etc/default/login, la entrada `SLEEPTIME' permite indicar el número de segundos - entre 0 y 5 - que han de transcurrir desde que se teclea una contraseña errónea y el mensaje login incorrect aparece en pantalla. Con `RETRIES' podemos especificar el número de intentos de entrada al sistema que se pueden producir hasta que un proceso de login finalice y la conexión remota asociada se cierre: en otras palabras, indicamos el número de veces que un usuario puede equivocarse al teclear su clave antes de que el sistema cierre su conexión.
Otra directiva interesante de /etc/default/login es `PASSREQ': si su valor es `YES', ningún usuario podrá conectar al sistema sin contraseña, y si es `NO', sí que se permiten este tipo de entradas. Evidentemente, el valor recomendable es el primero, aunque el incremento que conseguimos en nuestra seguridad no es excesivo y sólo se puede encontrar útil en circunstancias muy concretas, ya que a los usuarios que no tengan contraseña simplemente se les obligará a elegir un password al intentar entrar al sistema:
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.
Una contraseña en Solaris debe poseer al menos dos letras (mayúsculas o minúsculas) y al menos un número o carácter especial. Tampoco debe coincidir con el nombre de usuario, ni con rotaciones del mismo (por ejemplo el usuario `antonio' no podrá utilizar como clave `antonio', `ntonioa', `oinotna', etc.), y debe diferir del password anterior en al menos tres caracteres; para cualquiera de estos efectos comparativos, las letras mayúsculas y las minúsculas son equivalentes. Sólo el root puede adjudicar contraseñas que no cumplan las normas establecidas, pero a efectos de seguridad es recomendable que las claves que asigne tengan tantas restricciones como las que pueden escojer los usuarios (o más).
Volviendo de nuevo a /etc/default/passwd, dentro de este archivo tenemos un par de entradas útiles para establecer una política de envejecimiento de claves en nuestro sistema; se trata de `MAXWEEKS' y `MINWEEKS', que como sus nombres indican definen los tiempos de vida máximo y mínimo (en semanas) de una contraseña. Un tercer parámetro, `WARNWEEKS', define el periodo de tiempo (de nuevo, en semanas) a partir del cual se avisará a un usuario de que su password está a punto de caducar; dicho aviso se produce cuando el usuario inicia una sesió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.
Contra el primero de estos comentarios quizás se podría decir, en defensa de Solaris, que realmente en /etc/shadow podemos especificar días en lugar de semanas, pero eso implicaría modificar el archivo a mano para cada usuario, algo que no suele ser recomendable en ningún sistema Unix, o bien ejecutar /usr/bin/passwd con las opciones apropiadas, de nuevo para todos los usuarios en cuestión. Contra el segundo también se podría argumentar que existen utilidades de terceros para reforzar las contraseñas que eligen los usuarios, o bien que no es difícil escribir un módulo de PAM para evitar que esos usuarios elijan claves triviales, pero el hecho es que Sun Microsystems por defecto no incorpora ninguno de estos mecanismos en Solaris.
