El fichero /etc/security/user

En /etc/security/user se definen atributos extendidos de cada usuario; dichos atributos no son más que los no incluidos en el fichero /etc/passwd convencional de todo sistema Unix: mientras que en este último encontramos datos como el login o el UID de cada usuario, en el primero tenemos información como la fecha de caducidad de las contraseñas, las horas a las que puede conectar cada usuario, o los requisitos de seguridad mínimos para su clave. Cuando se añade un usuario al sistema mediante la orden mkuser se genera una nueva stanza en el fichero correspondiente al nuevo usuario, con unos atributos por defecto tomados del archivo /usr/lib/security/mkuser.default; existen numerosos atributos extendidos para los usuarios, y conocer algunos de ellos es vital para incrementar los niveles de seguridad ofrecidos por defecto por AIX. En este punto vamos a hablar de estos atributos.

Una directiva básica almacenada en /etc/security/user es account_locked, que evidentemente indica si una cuenta está bloqueada o no lo está; es una variable booleana, por lo que sus posibles valores son sencillamente true o false (o equivalentemente, yes y always o no y never). Aunque es muy similar a esta, la directiva login (también booleana) no es exactamente igual: si su valor es false o equivalente el usuario no puede acceder al sistema, pero su cuenta no está bloqueada, ya que es posible llegar a ella mediante su. Otra restricción de acceso para un usuario viene determinada por rlogin, que define si un usuario puede acceder al sistema de forma remota a través de telnet o rlogin (otros métodos de acceso, como SSH, no son controlados por esta directiva).

El que un usuario no tenga su cuenta bloqueada ni su acceso deshabilitado implica que puede utilizar su login para entrar - evidentemente si su autenticación es correcta - al sistema; algunas características de este acceso también se definen en /etc/security/user: por ejemplo, las horas y días que un determinado usuario puede acceder al equipo, mediante la directiva logintimes y las terminales desde las que puede hacerlo, mediante ttys. La sintaxis de la primera es equivalente a la utilizada en el fichero login.cfg, pero afectando ahora a usuarios concretos y no a puertos, mientras que la segunda se define mediante una lista de terminales separadas por comas; alternativamente se pueden usar los comodines `ALL' o `' para indicar que el usuario puede acceder a través de cualquier línea:

bruja:/# lsuser -a ttys toni
toni ttys=ALL
bruja:/#

Un grupo de directivas del archivo /etc/security/user también importantes para nuestra seguridad son las relativas a la contraseña de cada usuario; una de ellas es expires, que define la fecha de expiración de la clave en formato MMDDHHMMYY (un cero, valor por defecto, indica que el password nunca caduca):

bruja:/# lsuser -a expires toni
toni expires=0
bruja:/#

También relacionada con el envejecimiento de claves tenemos la directiva pwdwarntime, que define el número de días de antelación con los que se avisará a un usuario antes de obligarle a cambiar su contraseña. El periodo de validez de una clave viene indicado en semanas por la directiva maxage, cuyo valor puede oscilar entre 0 (valor por defecto, que indica que no existe caducidad) o 52 (un año de vida); por contra, el tiempo mínimo de vida de la contraseña se define en minage, que puede tomar los mismos valores que la directiva anterior. Cuando una clave caduca entra en juego la directiva maxexpired, que indica en semanas el tiempo durante el que se permite a un usuario (antes de bloquear su cuenta) acceder al sistema para cambiar su password, y cuyo valor oscila entre -1 (tiempo ilimitado) y 52 (un año).

Cuando un usuario cambia su contraseña, obligado o no por el sistema, entran en juego otra serie de parámetros también definidos en el fichero /etc/security/user: los relativos a las características que ha de poseer una clave del sistema. Sin duda uno de los más importantes para la seguridad, y que no aparece en otros Unices habituales, es dictionlist; esta directiva permite definir ficheros de diccionario (indicando las rutas absolutas de los mismos separadas por comas) contra los que se comprobará cada clave nueva elegida por un usuario. Los ficheros han de ser simples archivos de texto con palabras habituales - o modificaciones de las mismas - utilizadas en un lenguaje o área específica, similares a los utilizados como entrada de un programa rompedor de contraseñas tipo Crack o John the Ripper. Adicionalmente, AIX permite indicar métodos alternativos para comprobar la robustez de una clave mediante la directiva pwdchecks, que define métodos de comprobación cargados en tiempo de ejecución cuando un usuario ejecuta passwd para cambiar su contraseña.

Siguiendo con los parámetros relativos a las claves de usuario tenemos una serie de directivas que son básicas para garantizar la robustez de las contraseñas; una de ellas es minlen, que marca la longitud mínima de una clave y que por defecto está a cero (un valor más adecuado sería seis). Además, mediante minalpha y minother podemos definir el número mínimo de caracteres alfabéticos y no alfabéticos (respectivamente) exigibles en una clave; como en el anterior caso, el valor por defecto de ambos es cero, por lo que es recomendable aumentarlo como mínimo hasta dos, para garantizar que todo password tiene por lo menos un par de letras y un par de caracteres numéricos o de símbolos. Otra directiva interesante es maxrepeats, que permite especificar el número máximo de veces que un determinado carácter puede aparecer en una clave; su valor por defecto es ocho (ilimitado), y como siempre es importante modificar esta variable para darle un valor diferente y acorde a nuestra política de seguridad: por ejemplo dos, de forma que una misma letra, número o signo no aparezca más de un par de veces en la clave de un usuario; además, AIX también permite obligar a los usuarios a utilizar un cierto número de caracteres nuevos en una clave (caracteres no usados en el anterior password) mediante la directiva mindiff, cuyo valor puede oscilar entre 0 (por defecto) y 8, que obligaría al usuario a utilizar sólo caracteres nuevos en su clave.

Otras directivas relacionadas con las características de una clave son las relativas a los históricos de contraseñas: en primer lugar, histexpire marca el periodo (en semanas) que un usuario no puede reutilizar su clave antigua. Su valor por defecto es cero, lo cual evidentemente no beneficia mucho nuestra seguridad, por lo que es recomendable asignarle a esta directiva un valor entre 12 (unos tres meses) y 52 (un año); por su parte, mediante histsize podemos indicar el número de contraseñas antiguas que no pueden ser reutilizadas (hasta cincuenta), lo que combinado con el valor máximo aceptado por histexpire (260 semanas, o, lo que es lo mismo, cinco años) nos da una idea de la potencia de AIX en la gestión de sus claves: más que suficiente en la mayor parte de entornos.

Una entrada de /etc/security/user que hay que tratar con mucho cuidado, ya que incluso puede ser peligrosa para la seguridad de nuestros usuarios, es loginretries; indica el número de intentos fallidos de acceso al sistema que puede efectuar un usuario antes de que su cuenta se bloquee. Evidentemente, esto nos puede ayudar a detener a un atacante que intente acceder al sistema adivinando la contraseña de alguno de nuestros usuarios, pero es también un arma de doble filo: si un pirata quiere causar una negación de servicio a uno o varios usuarios, no tiene más que introducir el login de los mismos y contraseñas aleatorias cuando el sistema se lo solicita, lo que hará que AIX inhabilite el acceso legítimo de esos usuarios causando un perfecto ataque de negación de servicio contra los mismos. Quizás en la mayor parte de los sistemas sea una buena idea no habilitar esta directiva (asignándole un valor de 0, el que tiene por defecto), y prevenir el hecho de que un pirata pueda `adivinar' una contraseña implantando unas políticas de claves adecuadas.

Otras directivas interesantes de /etc/security/user son las relativas a los esquemas de autenticación de usuarios seguidos en el sistema; auth1 define el método de autenticación primario de un usuario y acepta tres valores que se pueden combinar entre sí: NONE (no existe autenticación), SYSTEM (el método clásico basado en login y password), y finalmente token;argument. Sin duda este último es el más interesante, ya que permite a un administrador utilizar métodos alternativos - por sí sólos o, más habitual, combinados con el clásico basado en login y password - para autenticar a uno o varios usuarios. Estos métodos (`token') han de estar definidos mediante una stanza válida, como ya vimos, en el archivo /etc/security/login.cfg, y el programa que los implemente será ejecutado recibiendo como primer parámetro el argumento `argument' definido en la entrada.

Imaginemos una situación en la que la autenticación múltiple nos puede resultar útil: queremos que ciertos usuarios del sistema, aparte de autenticarse con su login y password, tengan que proporcionar una clave adicional para acceder a la máquina, por ejemplo la de un usuario especial sin acceso real (sin shell ni acceso ftp). Si uno de esos usuarios es toni y el usuario especial es sistemas, deberíamos definir la entrada auth1 de toni para que se efectue en primer lugar la autenticación clásica y posteriormente se pida la clave de sistemas - modelo SYSTEM pero en este caso con el parámetro `sistemas' -; esto lo conseguimos ejecutando la orden chuser (o equivalentemente modificando el fichero /etc/security/user con un simple editor, aunque es recomendable la primera aproximación):

bruja:/# chuser "auth1=SYSTEM,SYSTEM;sistemas" toni
bruja:/# lsuser -a auth1 toni
toni auth1=SYSTEM,SYSTEM;sistemas
bruja:/#

Cuando toni trate de acceder al sistema se le solicitará su clave y, si esta es correcta, la clave de sistemas; si esta última también es válida el acceso se permitirá, denegándose en caso contrario^12.2.

Otra directiva relacionada con la autenticación de usuarios es auth2, que define los métodos secundarios de autenticación en el sistema; aunque la idea y sintaxis de los métodos secundarios es similar a los definidos en auth1, la principal diferencia con estos es que los secundarios no son de obligado cumplimiento: para acceder al sistema, un usuario ha de autenticarse correctamente en todos los métodos primarios, y si lo hace, aunque falle en los secundarios, el acceso es permitido. Esto puede parecer paradójico pero no lo es en absoluto: los métodos definidos en auth2 no sustituyen a los definidos en auth1, sino que se utilizan de forma adicional para otorgar otros privilegios a un usuario determinado; el caso típico puede ser el de Kerberos: cuando un usuario se autentica correctamente en una máquina, con su login y contraseña, el método secundario puede solicitarle una clave adicional para otorgarle credenciales de Kerberos; si esta clave no es correcta el usuario accede al sistema como máquina aislada, pero sin las credenciales que le autentiquen en el dominio. Además, los métodos definidos en auth2 permiten especificar programas no relacionados con la autenticación, pero que nos interesa que se ejecuten cuando un usuario accede al sistema.

La última directiva de /etc/security/user relacionada con la autenticación de usuarios es SYSTEM, que en AIX 4.x puede ser utilizada para describir diferentes métodos de autenticación: NONE (sin autenticación), `files', si sólo se efectua una autenticación local basada en las claves almacenadas en /etc/security/passwd, `compat', si a lo anterior le añadimos un entorno NIS, y DCE, si estamos trabajando con autenticación en un entorno distribuido. Como medida de seguridad básica, la propia IBM recomienda que el root de un sistema AIX sólo se autentique a través de ficheros de contraseñas locales (la entrada SYSTEM de la stanza del superusuario ha de tener como valor `files').

Una vez que un usuario se ha autenticado correctamente y ha accedido al sistema entran en juego otra serie de directivas que nos pueden resultar interesantes de cara a nuestra seguridad. La menos importante es umask, que como su nombre indica define, mediante tres dígitos octales, la máscara por defecto de cada usuario; decimos que es la menos importante porque, como sucede en cualquier Unix, el usuario puede modificar ese valor por defecto siempre que lo desee, simplemente ejecutando la orden umask desde línea de comandos.

Dos entradas que también afectan a la seguridad de usuarios ya dentro del sistema son su y sugroups; la primera, cuyo valor puede ser true o false (o sus equivalentes), indica si los usuarios de la máquina pueden ejecutar la orden su para cambiar su identidad a la del usuario en cuya stanza se ha definido la directiva: ojo, no se trata de limitar la ejecución de su a un usuario concreto, sino de limitar al resto la posibiliad de convertirse en ese usuario a través de este comando. Asignar a la directiva su el valor de true puede ayudarnos a proteger ciertas cuentas especiales de la máquina que no nos interesa que sean alcanzadas de ninguna forma por el resto de usuarios. Por su parte, la segunda entrada a la que hacíamos referencia, sugroups, define los grupos cuyos miembros pueden (o que no pueden, si precedemos su nombre por el símbolo `!') acceder mediante la orden su a una cuenta determinada, evidentemente si el valor de la directiva su de esa cuenta es verdadero.

Para finalizar este punto vamos a comentar brevemente un último grupo de directivas dentro del archivo /etc/security/user que definen características de los usuarios del sistema. En primer lugar, admin define el estado administrativo de un usuario: si es administrador o si no lo es; en caso afirmativo sólo el root puede modificar las características de ese usuario. Independientemente del estado administrativo de un usuario, cada uno puede ser administrador de grupos concretos (grupos que no sean administrativos, ya que en este caso, como sucede con la definición de usuarios, sólo el root puede modificar sus parámetros); entra entonces en juego el valor de admgroups, que indica los grupos (separados por comas) de los que el usuario es administrador.

Otra característica de cada usuario es la posibilidad del mismo de ejecutar tareas relacionadas con el SRC; es controlada por la directiva daemon, que puede tomar el valor de verdadero o falso. La entrada registry define la forma de gestionar la autenticación de un usuario concreto: en local (files) o en entornos distribuidos (NIS o DCE). Por último, tpath marca las características del Trusted Path: nosak, si el Secure Attention Key (recordemos, Ctrl-X Ctrl-R en AIX) no tiene efecto, on, si al pulsar el SAK se accede al Trusted Path, always, si siempre que un usuario accee al sistema lo hace al Trusted Path, y finalmente notsh, que desconecta al usuario al pulsar Ctrl-X Ctrl-R, lo que implica que nunca puede estar en el Trusted Path.