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