Seguridad en Unix y redes - Usuarios y accesos al sistema (II)

El fichero /etc/security/login.cfg

En este archivo se definen ciertos parámetros de control para las conexiones remotas a un sistema AIX; como veremos en este punto, todos ellos tienen implicaciones directas, aunque de diferente grado, en la seguridad del entorno de trabajo. Se puede dividir en tres grandes áreas: la correspondiente a la definición de puertos, la relativa a métodos de autenticación de usuarios y la que define atributos también de los usuarios; todas ellas contienen una stanza por defecto, y adicionalmente definiciones particulares para elementos concretos.

---

La primera gran área del archivo, la relativa a los puertos, está formada por una serie de parámetros que definen características del acceso al sistema a través de ellos; la primera directiva de este grupo es herald, que permite definir el mensaje que se muestra en la pantalla del usuario que trata de establecer una conexión remota con el sistema (algo similar al archivo /etc/motd del resto de Unices, fichero que en AIX no existe - y si es creado no tiene efecto -). Cuando tratamos de acceder a una máquina AIX el mensaje que se muestra es similar al siguiente:
luisa:~$ telnet bruja Trying 192.168.0.10... Connected to bruja. Escape character is '^]'. telnet (bruja) AIX Version 4 (C) Copyrights by IBM and by others 1982, 1996. login:

Modificando la directiva herald de /etc/security/login.cfg podemos definir otros mensajes de presentación; si por ejemplo queremos simular que nuestra máquina ejecuta Solaris en lugar de AIX, podemos emular el mensaje del primero:

bruja:/# grep herald /etc/security/login.cfg herald = "SunOS 5.8\n\nlogin: " bruja:/#

Así, cuando un usuario trate de conectar al sistema, verá algo parecido a lo siguiente:

bruja:/# telnet 0 Trying... Connected to 0. Escape character is '^]'. SunOS 5.8 login:^D Connection closed. bruja:/#

Relacionada con el anterior parámetro tenemos la directiva herald2, formada por una cadena de texto y que define el mensaje de login impreso en la terminal tras un intento fallido de acceso al sistema; por defecto, esta cadena de texto es un nuevo prompt de login.

---

También relativa a los puertos, otra directiva interesante que podemos encontrar en el fichero login.cfg es logindelay, que permite especificar el retardo en segundos entre intentos consecutivos de entrada al sistema; si es diferente de 0 (si es 0 se deshabilita su efecto) el valor de este parámetro se multiplica por el número de intentos fallidos: si logindelay es 1 el retardo entre el primer y el segundo intento será de un segundo, entre el segundo y el tercero será de dos, etc. Junto a este parámetro podemos definir también la directiva logindisable, que marca el número de intentos de entrada al sistema fallidos que una conexión acepta antes de cerrarse - o bloquearse, si se trata de una línea serie -, logininterval, que define los segundos durante los que se tienen que producir los intentos fallidos de conexión para que se cierre o bloquee la misma, y loginreenable, que obviamente indica el intervalo - en minutos - que un puerto va a permanecer bloqueado (si su valor es 0 - y por defecto lo es - estará así hasta que el administrador lo desbloquee manualmente mediante chsec).

---

Otra entrada útil en el archivo login.cfg es logintimes, que como su nombre indica define las horas y días durante las que un puerto determinado puede ser utilizado para acceder al sistema, algo similar (en idea, no en sintaxis) al archivo /etc/porttime de Linux o al prot.pwd.DB de HP-UX 10.x. El formato utilizado para especificar los intervalos de horas o días en los que el acceso se permite (entradas llamadas ALLOW) o se deniega (entradas DENY) no es inmediato, por lo que es recomendable - como siempre en Unix - consultar la página del manual de login.cfg. Por defecto, se permite a todos los usuarios acceder a través de cualquier línea sin importar el día ni la hora.

---

Para finalizar con el área de puertos vamos a comentar un par de directivas que también se pueden definir en el archivo login.cfg: se trata de sak_enabled y synonym. La primera de ellas indica si el secure attention key (SAK) está habilitado en el puerto, lo que implica que los usuarios pueden obtener una ruta de comunicación fiable (trusted communication path, TCP) mediante la combinación de teclas Ctrl-X Ctrl-R; en la sección dedicada a la base fiable de cómputo de los sistemas Unix ya hablamos de este tipo de comunicaciones seguras, por lo que no vamos a entrar aquí en más detalles. La segunda de las directivas a las que hacíamos referencia, la denominada synonym, tiene como objetivo definir sinónimos para una terminal concreta; está bastante relacionada con la primera, ya que restringe el acceso al puerto, que sólo se utilizará para establecer una ruta de comunicación fiable con el sistema.

---

La segunda gran área del fichero /etc/security/login.cfg hace referencia, como dijimos al principio, a los métodos de autenticación de usuarios disponibles en la máquina. Más tarde, cuando hablemos del fichero /etc/security/user, veremos que se pueden definir mecanismos secundarios de autenticación en el sistema que funcionan de forma independiente o junto al esquema clásico de nombre de usuario y contraseña. Los programas que implanten estos mecanismos adicionales han de definirse dentro de una stanza, bajo la directiva `program', que le de un nombre al modelo de autenticación que posteriormente se definirá para uno o más usuarios en /etc/security/user; insistimos en la palabra `adicionales', ya que los esquemas de autenticación clásicos no requieren definición (SYSTEM, para acceder con nombre de usuario y contraseña, y NONE, para acceder sin autenticación). Por ejemplo, imaginemos que si queremos definir un nuevo método basado en claves de un solo uso al que vamos a denominar authone y que está implementado en el programa /usr/local/auth/onetime; su stanza sería similar a la siguiente:
authone: program = /usr/local/auth/onetime

La última área del archivo proporciona la definición de algunos atributos globales de los usuarios bajo una stanza única: usw. El primero de estos atributos es logintimeout, que define el tiempo en segundos (60, por defecto) que un usuario tiene para teclear su contraseña cuando el sistema se lo solicita. Un segundo parámetro, maxlogins, define el número máximo de conexiones simultáneas que un usuario puede abrir en el sistema: el valor por defecto, 100, es a todas luces excesivo en la mayor parte de entornos, por lo que deberíamos especificar un valor adecuado a nuestro sistema - es imposible dar un valor `óptimo' para esta directiva -; si el valor de maxlogins es 0, el número máximo de conexiones simultáneas de un usuario está ilimitado. Finalmente, el último parámetro, shells, define los intérpretes de comandos válidos en la máquina, algo similar al archivo /etc/shells de otros Unices. Una entrada típica de esta stanza puede ser similar a la siguiente:

usw: shells = /bin/sh,/bin/bsh,/bin/csh,/bin/ksh,/bin/tsh,/usr/bin/sh maxlogins = 5 logintimeout = 30

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 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.

El fichero /etc/security/group

En el archivo /etc/security/group se pueden definir atributos para cada uno de los grupos del sistema (especificados, como en el resto de Unices, en el fichero /etc/group); de cara a la seguridad, son principalmente dos los atributos que más nos interesan en un entorno convencional: admin y adms. El primero de ellos, la directiva admin, es booleano (es decir, su valor puede ser `true' o `false'), y define el estado administrativo del grupo al que afecta. El que un grupo sea administrativo implica que sólo el administrador puede cambiar atributos del mismo, mientras que si no lo es aparte del root pueden hacerlo los usuarios pertenecientes al grupo security; en este último caso entra en juego la directiva adms, que define los administradores de grupos no administrativos. Estos administradores de un grupo tienen capacidad para ejecutar ciertas tareas sobre él, como añadir o eliminar usuarios o administradores del mismo.

---

La stanza de un grupo determinado suele ser similar a la siguiente:
pruebas: adms = root,toni admin = false

Igual que existen órdenes propias de AIX para consultar atributos de los usuarios o modificarlos (lsuser, chuser, rmuser...), en el caso de los grupos existen comandos equivalentes: lsgroup, chgroup...Su uso es muy similar al de los primeros:

bruja:/# lsgroup pruebas pruebas id=201 admin=false users= adms=root,toni bruja:/#

Los atributos de grupo que aparecen en el archivo /etc/security/group se denominan, como en el caso de los usuarios y el fichero /etc/security/user, extendidos; los básicos se encuentran en el mismo lugar que en cualquier otro Unix: en /etc/group, donde se definen los grupos, su clave, su GID y los usuarios que pertenecen a cada uno de ellos de forma secundaria. En AIX, la pertenencia al grupo especial `system' permite a un usuario realizar ciertas tareas administrativas sin necesidad de privilegios de administrador. Algo similar sucede con el grupo `security', que permite a sus usuarios gestionar parcialmente algunos aspectos de la seguridad en el sistema (les proporciona acceso al directorio /etc/security/ y su contenido, para, por ejemplo, modificar atributos de los usuarios no administrativos); por defecto, en AIX el grupo `staff' es el que engloba a los usuarios normales.