Los contenidos pueden estar desactualizados con respecto al original
AIX
Siguiente: HP-UX Subir: Algunos sistemas Unix Anterior: Linux Índice General
Subsecciones
- Introducción
- Seguridad física en RS/6000
- Servicios de red
- Usuarios y accesos al sistema
- El fichero /etc/security/.ids
- El fichero /etc/security/passwd
- El fichero /etc/security/failedlogin
- El fichero /etc/security/lastlog
- El fichero /etc/security/limits
- El fichero /etc/security/login.cfg
- El fichero /etc/security/user
- El fichero /etc/security/group
- El sistema de log
- El sistema de parcheado
- Extensiones de la seguridad: filtros IP
- El subsistema de red
AIX
Introducción
AIX (Advanced Interactive eXecutive) es la versión de Unix desarrollada y mantenida desde hace más de diez años por IBM; sus orígenes provienen de IBM RT System, de finales de los ochenta, y se ejecuta en las plataformas RS/6000, basadas en chips RISC PowerPC similares al utilizados por algunos Macintosh más o menos modernos. Este operativo, mezcla de BSD y System V (se suele decir que no es ni uno ni otro) es el que más características propietarias incorpora, características que no se encuentran en ninguna otra versión de Unix, por lo que a cualquier administrador le costará más adaptarse a AIX que a otros Unices. No obstante, en favor de IBM hay que decir que dispone de un excelente asistente para realizar todo tipo de tareas denominado SMIT (System Management Interface Tool, también ejecutado como smitty en modo consola): aunque por supuesto cualquier tarea también se puede ejecutar desde la línea de comandos, esto generalmente no se hace con las órdenes habituales de Unix, por lo que SMIT es una herramienta indispensable para el administrador de la máquina. AIX, a pesar de que en un principio pueda parecer el Unix más arcaico - y nadie niega que lo sea - es un entorno de trabajo fiable y sobre todo extremadamente estable, e incluso incorpora características (tanto de seguridad como de otros aspectos) que ya quisieran para sí otros sistemas Unix.El hecho de que muchas tareas no se realicen en AIX de la misma forma en que se llevan a cabo en el resto de Unices es en parte debido al ODM (Object Data Manager); a diferencia de Solaris o Linux, en AIX debemos tener presente en todo momento que vi no es una herramienta para administrar el sistema, ya que los clásicos ficheros de configuración ASCII han sido sustituidos por archivos binarios, bases de datos que mantienen la configuración del sistema (aspectos como los dispositivos, los recursos del entorno, o el subsistema de comunicaciones de AIX) de forma más robusta, segura y portable que los simples ficheros de texto, al menos en opinión de los desarrolladores de IBM ([V$^+$00]).
IBM mantiene en Internet un excelente repositorio de documentación, principalmente los denominados RedBooks, completos manuales sobre casi cualquier tema relacionado con AIX - y otros productos de la compañía - que podamos imaginar. Están disponibles en la dirección http://www.redbooks.ibm.com/, y algunos de ellos son una herramienta imprescindible para cualquier administrador de sistemas. Por supuesto, también es muy recomendable instalar las páginas del manual on-line de AIX, algo que incomprensiblemente no se hace por defecto en una instalación estándar, y utilizar SMIT para ejecutar cualquier tarea que desde línea de órdenes dudemos de cómo hacer.
En este capítulo hablaremos de aspectos de la seguridad casi exclusivos de AIX; al ser este sistema probablemente el Unix más cerrado de todos, lo que veamos aquí difícilmente será extrapolable - en la mayoría de casos - a otros entornos como Solaris o HP-UX. En cualquier caso, es necesario para un administrador conocer los aspectos de AIX que le confieren su enorme robustez, tanto en lo referente a seguridad como en cualquier otra faceta genérica del sistema.
Seguridad física en RS/6000
El firmware de los sistemas RS/6000 provee de tres modos de protección física ([IBM00a]), en cierta forma similares a las que ofrecen las estaciones SPARC que comentamos al hablar de Solaris. El primero de ellos, denominado POP (Power-On Password) es el equivalente al modo `full-secure' de SPARC, y como éste impide el arranque del sistema si antes no se ha introducido la contraseña determinada como POP; por supuesto, esto evita tareas como la planificación de reinicios automáticos, por lo que en muchas ocasiones no compensa el nivel de seguridad con el de funcionalidad. Por eso existe un segundo modo de protección denominado Unattended start mode que permite arrancar al sistema de su dispositivo por defecto sin necesidad de que un operador teclee la contraseña POP para ello.En el modo `desatendido' el sistema arranca con normalidad desde el dispositivo especificado por defecto sin necesidad de ninguna clave POP (a pesar de que esta contraseña tenga que haber sido definida con anterioridad); el sistema arranca, pero la diferencia con el modo normal es que el controlador de teclado permanece bloqueado hasta el el password POP es introducido. De esta forma se consigue que la máquina proporcione todos sus servicios (el arranque es completo) pero que, si alguien quiere acceder a la misma desde consola, esté obligado a introducir la contraseña POP previamente definida.
Aparte del password POP, en las máquinas RS/6000 puede establecerse una segunda contraseña denominada PAP (Privileged Access Password) o Supervisory Password, que protege el arranque del SMS (System Management Services), un firmware que proporciona al administrador de la máquina ciertas utilidades de configuración de bajo nivel; el SMS es accesible en un determinado punto de la secuencia de arranque de la máquina, en concreto cuando el display marca `FF1' y se pulsa una cierta tecla (generalmente `1' en terminales de texto o `F1' en terminales gráficas), y desde sus menús se puede actualizar el propio firmware o cambiar el dispositivo de arranque, por poner sólo un par de ejemplos. Si la contraseña PAP está habilitada se restringe el acceso al SMS, evitando que un atacante con acceso físico al equipo puede modificar parámetros de la máquina vitales para nuestra seguridad.
Es importante establecer un password para proteger el SMS: si un pirata consigue acceso al mismo, ni tan siquiera importará si hemos definido o no una contraseña POP, ya que podrá deshabilitarla o incluso cambiarla desde el SMS; el problema surge si la clave de nuestro firmware se pierde, ya que en ese caso necesitaríamos abrir el equipo y quitarle su batería, perdiendo en este caso toda la configuración almacenada en la NVRAM.
Desde la línea de órdenes de un sistema AIX podemos ejecutar ciertos mandatos que nos van a permitir tanto visualizar el valor de parámetros del firmware como modificar dicho valor; lamentablemente no tenemos un interfaz tan uniforme como en Solaris, donde a través de la orden eeprom leemos y modificamos la información de la NVRAM, sino que en AIX tenemos que utilizar diferentes órdenes para interactuar con el firmware de la máquina. Por ejemplo, mediante un comando como bootlist podemos consultar y modificar la lista de dispositivos de arranque del sistema, y mediante lscfg obtener la versión del firmware instalado en la máquina:
bruja:/# bootlist -m normal -o hdisk0 fd0 cd0 ent2 bruja:/#
Servicios de red
Como en el resto de entornos Unix, en AIX es vital garantizar la seguridad de los servicios de red de la máquina para conseguir un entorno de trabajo fiable en su globalidad; no obstante, este operativo provee de una serie de herramientas que otros sistemas no proporcionan y que facilitan enormemente el trabajo del administrador: es importante acostumbrarse a su manejo (recordemos que en AIX vi no es una herramienta administrativa) a través de SMIT y, mucho mejor, desde línea de órdenes. Por poner un ejemplo, si a un administrador de un entorno Solaris, Linux o HP-UX le preguntamos cómo eliminaría el servicio chargen en una máquina, la respuesta sería siempre la misma: editando /etc/inetd.conf, comentando la línea correspondiente con una almohadilla (`#') y reiniciando el demonio inetd enviándole la señal SIGHUP; si le preguntamos lo mismo al root de una máquina AIX, lo más probable (aunque podría hacerlo de la forma anterior) es que utilice una orden como chsubserver, en un proceso similar al siguiente:bruja:/# grep chargen /etc/inetd.conf chargen stream tcp nowait root internal chargen dgram udp wait root internal bruja:/# chsubserver -d -v chargen -p udp bruja:/# chsubserver -d -v chargen -p tcp bruja:/# grep chargen /etc/inetd.conf #chargen stream tcp nowait root internal #chargen dgram udp wait root internal bruja:/# refresh -s inetd bruja:/#En AIX los subsistemas de red son gestionados por el Controlador de Recursos del Sistema (SRC, System Resource Controller), un software que proporciona comandos e interfaces uniformes para crear y controlar subsistemas ([IBM97c]), que no son más que programas o procesos (o combinaciones de los mismos) capaces de operar de forma independiente o a través de un controlador, algo que es más o menos equivalente a lo que todos conocemos como `demonio' en cualquier Unix; podemos ejecutar la orden `lssrc -a' para listar los subsistemas de nuestra máquina AIX:
bruja:/# lssrc -a Subsystem Group PID Status portmap portmap 5684 active inetd tcpip 7770 active xntpd tcpip 6352 active automountd autofs 6056 active hats hats 9876 active hags hags 8494 active hagsglsm hags 9370 active haem haem 6694 active haemaixos haem 10662 active pman pman 11372 active pmanrm pman 12130 active sysctld 11174 active snmpd tcpip 15520 active sendmail mail 16628 active dpid2 tcpip 16106 active fs 19612 active biod nfs 19874 active rpc.statd nfs 20644 active qdaemon spooler 15750 active writesrv spooler 19366 active clstrmgr cluster 32706 active clsmuxpd cluster 42048 active nfsd nfs 31168 active rpc.mountd nfs 42904 active rpc.lockd nfs 32004 active tftpd tcpip 7586 active syslogd ras 31852 active lpd spooler inoperative clvmd inoperative gated tcpip inoperative named tcpip inoperative routed tcpip inoperative rwhod tcpip inoperative iptrace tcpip inoperative timed tcpip inoperative dhcpcd tcpip inoperative dhcpsd tcpip inoperative dhcprd tcpip inoperative ndpd-host tcpip inoperative ndpd-router tcpip inoperative llbd iforncs inoperative glbd iforncs inoperative i4lmd iforls inoperative i4glbcd iforncs inoperative i4gdb iforls inoperative i4llmd iforls inoperative mrouted tcpip inoperative rsvpd qos inoperative policyd qos inoperative pxed tcpip inoperative binld tcpip inoperative dtsrc inoperative bruja:/#Los subsistemas con funciones relacionadas entre sí forman lo que se denomina grupos de subsistemas, y además cada subsistema se divide en subservidores (simples programas o procesos), formando una estructura jerárquica como la mostrada en la figura 11.1 (figura en la que además se muestra un ejemplo - entre paréntesis - de cada categoría); como podemos ver en ella, un grupo de subsistemas es tcpip, que como su nombre ya adelanta es el encargado de la gestión de protocolos TCP/IP, y que incluye a subsistemas tan importantes como inetd o snmpd. Mediante lssrc, con las opciones adecuadas, podemos obtener información detallada acerca de un subsistema o subservidor; por ejemplo, la siguiente orden nos muestra lo que hemos comentado anteriormente, que el subsistema inetd pertenece al grupo tcpip, y que en este caso concreto tiene cuatro servidores activos (tftp, klogin, kshell y ftp):
bruja:/# lssrc -ls inetd Subsystem Group PID Status inetd tcpip 7770 active Debug Not active Signal Purpose SIGALRM Establishes socket connections for failed services. SIGHUP Rereads the configuration database and reconfigures services. SIGCHLD Restarts the service in case the service ends abnormally. Service Command Description Status tftp /usr/sbin/tftpd tftpd -d /tftpboot active klogin /usr/sbin/krlogind krlogind active kshell /usr/sbin/krshd krshd active ftp /usr/sbin/ftpd ftpd active bruja:/#Como ya hemos dicho antes, el SRC proporciona comandos comunes para operar con todos sus subsistemas: disponemos de las órdenes startsrc y stopsrc para arrancar y detener - respectivamente - tanto subsistemas completos como subservidores de los mismos de forma independiente, y de traceson y tracesoff para activar o desactivar el trazado de los mismos; la orden refresh `refresca' un subsistema (algo similar a enviarle una señal SIGHUP), mientras que mediante lssrc podemos consultar el estado de un subsistema. Por ejemplo, para detener el subservidor telnetd en nuestro sistema no tenemos que recurrir - aunque podríamos hacerlo - a chsubserver (como vimos al inicio de este punto aplicando el ejemplo al subservidor chargen); una forma equivalente de hacerlo es simplemente ejecutando la siguiente orden:
bruja:/# startsrc -t telnet 0513-124 The telnet subserver has been started. bruja:/# grep -w telnet /etc/inetd.conf telnet stream tcp6 nowait root /usr/sbin/telnetd telnetd -a bruja:/# stopsrc -t telnet 0513-127 The telnet subserver was stopped successfully. bruja:/# grep -w telnet /etc/inetd.conf #telnet stream tcp6 nowait root /usr/sbin/telnetd telnetd -a bruja:/#
Usuarios y accesos al sistema
Como vamos a ver en esta sección, AIX ofrece un sistema de control de accesos y gestión de usuarios realmente interesante; al igual que en cualquier entorno Unix, nada más instalar el operativo ya existen una serie de usuarios `del sistema' (root, daemon, sys...). Todos ellos tienen en realidad las cuentas bloqueadas ya que el campo reservado a su contraseña en /etc/security/passwd es un asterisco, aunque una orden como `lsuser' nos diga lo contrario:bruja:/# lsuser -a account_locked ALL root account_locked=false daemon account_locked=false bin account_locked=false sys account_locked=false adm account_locked=false uucp account_locked=false guest account_locked=false nobody account_locked=false lpd account_locked=false imnadm account_locked=false nuucp account_locked=false bruja:/#Si necesitamos que la cuenta de un determinado usuario se bloquee temporalmente pero no queremos sustituir su clave del fichero de contraseñas por un asterisco, podemos ejecutar la orden `chuser'12.1:
bruja:/# lsuser -a account_locked toni toni account_locked=false bruja:/# chuser account_locked=true toni bruja:/# lsuser -a account_locked toni toni account_locked=true bruja:/#La gestión y el control de los accesos al sistema por parte de usuarios se puede llevar a cabo desde diferentes ficheros del directorio /etc/security/: por ejemplo, en el archivo user se definen los diferentes atributos de cada usuario del sistema, desde las propiedades de envejecimiento de su contraseña a las franjas horarias en que el usuario pueden acceder a la máquina; vamos a ver en los siguientes puntos algunos de estos archivos, interesantes para definir o refinar parámetros relacionados con la seguridad de nuestro sistema.
El fichero /etc/security/.ids
El nombre de este archivo quizás nos puede inducir a pensar que se trata de algo relacionado con la detección de intrusos en nuestra máquina; nada más lejos de la realidad: en el fichero .ids se almacena información necesaria para generar correctamente a nuevos usuarios. Su formato es similar al siguiente:bruja:/etc/security# cat .ids 8 210 11 205 bruja:/etc/security#Donde `8' y `11' indican los siguientes UID y GID (respectivamente) disponibles para usuarios con privilegios administrativos, mientras que `210' y `205' son equivalentes pero para usuarios sin dichos privilegios.
A no ser que conozcamos muy bien el sistema, no es recomendable modificar manualmente este archivo, ya que las herramientas de gestión de usuarios lo actualizan de forma automática; de cualquier forma, aquí lo citamos para evitar confusiones con su nombre, como hemos comentado al principio.
El fichero /etc/security/passwd
Al contrario de lo que sucede con el archivo .ids, el nombre del fichero passwd no da lugar a equivocaciones: se trata, evidentemente, de información sobre las claves de los usuarios del sistema. Esta información puede estar desajustada con respecto a la contenida en /etc/passwd, por lo que es recomendable ejecutar periódicamente - al menos una vez al mes - órdenes como pwdck, usrck o grpck, encargadas de verificar, comparar y sincronizar la información de los usuarios (definiciones, grupos y autenticación) en las diferentes tablas que AIX mantiene:bruja:/# pwdck -y ALL The user "daemon" has an invalid password field in /etc/passwd. The user "toni" has an invalid password field in /etc/passwd. bruja:/# usrck -n ALL User daemon is locked. User bin is locked. User sys is locked. User nobody is locked. User lpd is locked. User imnadm is locked. bruja:/#Tras sincronizar correctamente la información de los usuarios (parámetro `-y' de estas órdenes), en /etc/passwd nos encontraremos el carácter `!' en el campo reservado a la contraseña cifrada de cada entrada, mientras que las claves reales ya estarán en /etc/security/passwd. Este fichero ha de ser de sólo lectura para el administrador: es en cierta forma similar al /etc/shadow clásico de otros Unices; no obstante, difiere enormemente de él en el formato del archivo, ya que no utiliza una entrada por línea con los campos separados por el carácter `:'. Por contra, en AIX cada usuario tiene definidos una serie de campos, uno por línea, y con el identificador del campo y su contenido separados por un signo `='; por ejemplo, la entrada para el usuario `oracle' en /etc/security/passwd podría ser similar a la siguiente:
oracle:
password = be3a2NjB.dtbg
lastupdate = 995301219
flags =
El primer campo representa obviamente la contraseña cifrada del usuario;
el segundo representa el la fecha y hora de la última actualización del
conjunto de atributos (denominado `stanza') del usuario, y finalmente el
campo `flags', por defecto vacío, puede contener una serie de
parámetros característicos del usuario concreto: si se trata de un
usuario con cierto privilegio, si no necesita contraseña para conectar al
sistema...; para obtener más información sobre estos parámetros
podemos consultar la página del manual de `pwdck'.
El fichero /etc/security/failedlogin
Como su nombre indica, en este fichero se registran los intentos fallidos de acceso al sistema; su formato no es de texto plano, sino que es similar a los ficheros wtmp de AIX y otros sistemas Unix. Por tanto, para visualizar el contenido de este archivo necesitamos ejecutar órdenes como `last' o `who' con los parámetros adecuados:bruja:/# who -s /etc/security/failedlogin |tail -3 oracle pts/24 Sep 5 12:55 (luisa) UNKNOWN_ dtlogin/_0 Sep 12 11:01 toni pts/23 Sep 13 15:45 (anita) bruja:/#
El fichero /etc/security/lastlog
En el archivo /etc/security/lastlog de un sistema AIX, un fichero de texto plano que poco tiene que ver con el formato del `lastlog' de otros Unices, se encuentra almacenada información relativa a la última conexión - o intento de conexión - de cada usuario de la máquina; en concreto, aparecen referencias a la hora, terminal y host origen de la última entrada al sistema y del último intento de acceso.Cuando un usuario es creado mediante mkuser (o equivalentemente, vía SMIT) se crea una stanza vacía para el mismo en este archivo cuyos campos se irán rellenando a medida que el usuario acceda al sistema; esta stanza puede ser similar a la siguiente:
toni:
time_last_login = 1005297794
tty_last_login = ttyp0
host_last_login = anita
unsuccessful_login_count = 0
time_last_unsuccessful_login = 1004445794
tty_last_unsuccessful_login = /dev/pts/14
host_last_unsuccessful_login = luisa
Como podemos ver, el nombre de cada campo es autoexplicativo de su función; el
único que quizás puede plantear alguna duda es unsuccessful_login_count, que no es más que un contador que indica el
número de intentos de acceso fallidos desde la última entrada al sistema.
Para consultar los parámetros de cada usuario almacenados en este archivo no es necesario editar o visualizar el fichero: mediante la orden lsuser podemos obtener el valor de cada uno de ellos; si por ejemplo nos interesa el nombre de la máquina desde la que el usuario toni accedió por última vez al sistema, podemos conseguirlo de esta forma:
bruja:/# lsuser -a host_last_login toni toni host_last_login=anita bruja:/#
El fichero /etc/security/limits
En este archivo se definen límites a algunos de los recursos que ofrece un entorno de trabajo AIX; como muchos de los archivos del directorio, contiene una stanza que se aplica por defecto y luego entradas - vacías por lo general - para cada usuario, en las que se pueden personalizar parámetros que sólo se aplican a uno o varios usuarios y no a todos (generalmente se definen al crear al usuario). Las diferentes directivas del archivo son las siguientes:- fsize
Tamaño máximo de un archivo en bloques de 512 bytes. - core
Tamaño máximo de un fichero core (volcado de memoria) en bloques de 512 bytes. - cpu
Tiempo límite de CPU por proceso, especificado en segundos. Por defecto no está establecido para ningún usuario. - data
Límite de tamaño del segmento de datos de un proceso del usuario, en bloques de 512 bytes. - stack
Límite de tamaño de la pila de un proceso en bloques de 512 bytes. - rss
Límite del tamaño de memoria utilizada por proceso, en bloques de 512 bytes. - nofiles
Número máximo de descriptores de fichero abiertos.
Podemos ver los límites aplicables a uno o más usuarios mediante la orden `lsuser' (un valor de `-1' indica que se trata de un recurso no limitado al usuario en cuestión):
bruja:/# lsuser -f -a fsize core cpu data stack rss nofiles toni
toni:
fsize=2097151
core=2097151
cpu=-1
data=262144
stack=65536
rss=65536
nofiles=2000
bruja:/#
Por defecto, AIX ofrece unos límites bastante razonables a los recursos que
cada usuario puede consumir; no obstante, en función de para qué se utilice
cada sistema concreto, es recomendable que sea el administrador el que deba
especificar qué limites impone a los usuarios sobre los recursos de la
máquina para prevenir negaciones de servicio contra los mismos.
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.
El sistema de log
Al igual que sucede en cualquier sistema Unix, en AIX la información y los errores generados por eventos en el sistema son gestionados por el demonio syslogd, que en función de su configuración (en el archivo /etc/syslogd.conf) envía sus registros a consola, a un fichero, a un programa, a otro sistema...tal y como se explica en el capítulo dedicado a la auditoría de sistemas Unix. No obstante, además de syslogd, AIX proporciona otro mecanismo para la gestión de errores y mensajes del hardware, del sistema operativo y de las aplicaciones, ofreciendo una información muy valiosa para determinar cualquier tipo de problemas en el entorno ([Skl01]); mientras que por defecto syslogd no realiza ningún tipo de registro en AIX, este sistema no necesita ningún tipo de configuración adicional para comenzar a realiza su trabajo. Además, viene `de serie', ya que este mecanismo adicional forma parte de los paquetes bos.rte y bos.sysmgt.serv_aid, instalados por defecto con el operativo:
bruja:/etc# lslpp -l bos.rte bos.sysmgt.serv_aid
Fileset Level State Description
--------------------------------------------------------------------------
Path: /usr/lib/objrepos
bos.rte 4.3.3.10 COMMITTED Base Operating System Runtime
bos.sysmgt.serv_aid 4.3.3.50 COMMITTED Software Error Logging and
Dump Service Aids
Path: /etc/objrepos
bos.rte 4.3.3.0 COMMITTED Base Operating System Runtime
bos.sysmgt.serv_aid 4.3.3.50 COMMITTED Software Error Logging and
Dump Service Aids
bruja:/etc#
Al arrancar una máquina AIX desde /etc/inittab se invoca a /sbin/rc.boot, shellscript donde se inicializa el demonio errdemon,
encargado de monitorizar contínuamente el archivo /dev/error
y crear los registros de error en el fichero correspondiente; a diferencia de
syslogd, errdemon no escribe una entrada cada vez que se registra
un evento, sino que lo hace mediante buffers tal y como se le indica en
su base de datos de notificación de errores, /etc/objrepos/errnotify.
Además, el registro de errores por defecto se mantiene en /var/adm/ras/errlog, mientras que el último log generado se guarda en
memoria NVRAM de forma que en el arranque del sistema se añade al registro
cuando se inicializa el demonio.
Los registros guardados por errdemon están en modo binario (a diferencia de los logs habituales en Unix) por defecto, como hemos comentado, dentro del fichero /var/adm/ras/errlog; de esta forma, para visualizarlos necesitaremos ciertas herramientas que vienen con el sistema; podemos utilizar desde línea de comandos la orden errpt o bien - como siempre en AIX - invocarla desde SMIT. En cualquier caso, mediante esta herramienta se genera en tiempo real un informe de errores:
bruja:/# errpt |head -2 IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION AA8AB241 0506081102 T O OPERATOR OPERATOR NOTIFICATION bruja:/#Como podemos ver, cada línea mostrada por esta orden es uno de los registros procesados; la primera columna es un identificador de error único y la segunda indica la hora en que se generó el mismo en formato mmddhhmmyy (mes, día, hora, minuto y año). La tercera describe el tipo de error registrado: una `T' indica que es temporal, una `P' que es permanente y una `U' que es desconocido. La cuarta columna define la clase del error (`S' para errores software, `H' para hardware y `O' para entradas generadas mediante errlogger, como veremos después). Finalmente, la quinta columna indica el recurso afectado, y la última una descripción del error. Si pensamos que el formato es algo complicado de interpretar a simple vista (quizás tengamos razón), podemos utilizar la opción `-a' de la orden, que muestra los registros con un mayor nivel de detalle, hasta el punto de indicar las posibles causas del problema y su solución (aunque realmente esta información no es tan útil como pueda parecer en principio):
bruja:/# errpt -a|head -36
-------------------------------------------------------------------------
LABEL: SRC
IDENTIFIER: E18E984F
Date/Time: Mon May 6 07:02:05
Sequence Number: 30479
Machine Id: 000000375C00
Node Id: bruja
Class: S
Type: PERM
Resource Name: SRC
Description
SOFTWARE PROGRAM ERROR
Probable Causes
APPLICATION PROGRAM
Failure Causes
SOFTWARE PROGRAM
Recommended Actions
PERFORM PROBLEM RECOVERY PROCEDURES
Detail Data
SYMPTOM CODE
0
SOFTWARE ERROR CODE
-9017
ERROR CODE
9
DETECTING MODULE
'srchevn.c'@line:'288'
FAILING MODULE
qdaemon
-------------------------------------------------------------------------
bruja:/#
El archivo errlog es un registro circular, es decir, almacena tantas
entradas como se define al arrancar el demonio errdemon. Al llegar una
nueva entrada, se almacena primero en un buffer intermedio para minimizar
la probabilidad de pérdida del registro, y a continuación se pasa al
fichero errlog; en este punto, si se va a sobrepasar el tamaño máximo
del archivo, se elimina la primera entrada registrada. Podemos consultar los
parámetros de configuración actuales mediante errdemon, y quizás
nos interese también modificar alguno de ellos en el arranque del sistema;
por ejemplo, [Bha01] recomienda incrementar el tamaño por defecto de
los buffers y del archivo de log para obtener un mejor registro de
auditoría:bruja:/# /usr/lib/errdemon -l Error Log Attributes --------------------------------------------- Log File /var/adm/ras/errlog Log Size 1048576 bytes Memory Buffer Size 8192 bytes bruja:/# /usr/lib/errdemon -s4194304 -B32768 The error log memory buffer size you supplied will be rounded up to a multiple of 4096 bytes. bruja:/# /usr/lib/errdemon -l Error Log Attributes --------------------------------------------- Log File /var/adm/ras/errlog Log Size 4194304 bytes Memory Buffer Size 32768 bytes bruja:/#Otra herramienta interesante para trabajar con el sistema de registro de AIX es errlogger; la funcionalidad de la misma es similar a la de la orden logger en otros Unices: añadir entradas al fichero de log desde línea de comandos, por ejemplo a la hora de registrar eventos desde un shellscript:
bruja:/# errlogger Mensaje de prueba
bruja:/# errpt |head -2
IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
AA8AB241 0506081102 T O OPERATOR OPERATOR NOTIFICATION
bruja:/# errpt -a |head -25
-------------------------------------------------------------------------
LABEL: OPMSG
IDENTIFIER: AA8AB241
Date/Time: Mon May 6 08:11:54
Sequence Number: 30480
Machine Id: 000000375C00
Node Id: bruja
Class: O
Type: TEMP
Resource Name: OPERATOR
Description
OPERATOR NOTIFICATION
User Causes
ERRLOGGER COMMAND
Recommended Actions
REVIEW DETAILED DATA
Detail Data
MESSAGE FROM ERRLOGGER COMMAND
Mensaje de prueba
-------------------------------------------------------------------------
bruja:/#
AIX ofrece más herramientas para realizar diferente tareas sobre su sistema
nativo de log: eliminar entradas (errclear), instalar nuevas
entradas en el archivo de configuración (errinstall), detener el
demonio errdemon (errstop); para obtener información adicional
podemos consultar el capítulo 10 de [IBM97a]. El sistema de log en AIX es una de las características más potentes que
el operativo nos ofrece, proporcionando un nivel de detalle y granularidad en
la clasificación de eventos muy superior al de syslogd; no obstante, la
cantidad de información registrada, y el hecho de que no existan herramientas
`de serie' (realmente sí que las hay, en muchos casos simples scripts desarrolladas por terceros) que informen de algún modo especial ante
errores graves, hacen que no se consulte mucho el log y se pierdan
entradas que son importantes, no sólo en lo referente a la seguridad del
sistema sino también en lo que concierne a su estabilidad.
El sistema de parcheado
Antes de empezar a hablar sobre el parcheado y la actualización de un sistema AIX es conveniente aclarar un poco la nomenclatura que IBM sigue en su distribución de su software ([IBM00b]); el formato instalable más pequeño se denomina fileset, y hace referencia a una serie de archivos que realizan una cierta función en la máquina (por ejemplo, la implantación de mecanismos de seguridad al subsistema de red, como veremos después). Para actualizar los filesets existen actualizaciones de este formato, que se pueden diferenciar de la versión original porque su versión acaba en un número diferente de `0' (por ejemplo, un fileset puede estar marcado como 4.3.3.0 y una actualización como 4.3.3.4). Los filesets se agrupan en diferentes paquetes (packages) en función de su cometido (por ejemplo, el package que agrupa a todos los filesets relacionados con el sistema de red de AIX), y a su vez estos packages se agrupan en LPPs (Licensed Program Product), colecciones de software establecido en una gran área. La nomenclatura de la unidad software más pequeña define tanto el fileset como el package y el LPP al que pertenece: por ejemplo, bos.net.ipsec.rte es un fileset incluido en el paquete bos.net, que a su vez pertenece al LPP bos (Basic Operating System). Aparte de la anterior clasificación, los parches tal y como los conocemos en Unix se denominan PTFs (Program Temporary Fix), y cada uno de ellos viene referenciado por un número único llamado APAR (Authorized Program Analysis Report).La distribución de todo este software para AIX, tanto paquetes originales como actualizaciones, se realiza en un formato de fichero denominado bff (Backup File Format); este formato es el clásico de la orden backup de muchos Unices, por lo que puede ser instalado mediante restore, aunque su utilización no es en absoluto recomendable: para instalar un nuevo paquete o actualizar uno existente hemos de utilizar el comando installp o, más habitualmente, smit. Mediante `lslpp -L' podemos ver las versiones del software instalado en un sistema AIX, y con `lslpp -h' un histórico de sus versiones:
bruja:/# lslpp -L Java130.rte.lib
Fileset Level State Description
--------------------------------------------------------------------------
Java130.rte.lib 1.3.0.5 C Java Runtime Environment
Libraries
State codes:
A -- Applied.
B -- Broken.
C -- Committed.
O -- Obsolete. (partially migrated to newer version)
? -- Inconsistent State...Run lppchk -v.
bruja:/# lslpp -h X11.adt.lib
Fileset Level Action Status Date Time
--------------------------------------------------------------------------
Path: /usr/lib/objrepos
X11.adt.lib
4.3.3.0 COMMIT COMPLETE 09/29/99 09:55:30
4.3.3.10 COMMIT COMPLETE 06/12/01 11:25:48
bruja:/#
IBM ofrece sus parches para AIX tanto en CD-ROM como a través de Internet,
desde la dirección siguiente:http://techsupport.services.ibm.com/server/support/Cada parche se suele identificar de forma unívoca bien a través de su número PTF, bien a través de su APAR, o simplemente por su nombre y versión. Para instalarlo en un sistema AIX se suele utilizar smit install_update o, desde línea de comando, la orden instfix; no obstante, la instalación de parches y actualización de software en general suele resultar bastante engorrosa en AIX si se realiza únicamente de esta forma: en función de nuestro nivel de sistema operativo (determinado con la orden `oslevel') y la actualización que necesitemos llevar a cabo, es posible que la instalación de un único parche implique horas de trabajo, ya que ese parche puede necesitar como prerequisito un conjunto de parches que no están instalados, y que a su vez necesitan más parches; de esta forma, es muy posible que para una pequeña actualización necesitemos más de un gigabyte de ficheros descargados en el sistema.
Por fortuna, en un sistema AIX podemos utilizar fixdist, un cómodo entorno gráfico (en la figura 11.2 podemos ver su interfaz) que nos facilitará enormente esta tarea, ya que calcula todos los parches que conformarán nuestro árbol de prerequisitos y los descarga automáticamente; gracias a esta herramienta, descargar todos los prerrequisitos de un determinado parche se convierte en una tarea trivial.
Extensiones de la seguridad: filtros IP
En versiones más o menos recientes de AIX el operativo proporciona `de serie' unos interesantes mecanismos de seguridad IP basados en túneles y filtros de paquetes, algo similar - guardando las distancias - a ipchains o iptables en Linux; el uso de túneles requiere filtros, pero el de filtros no necesita para nada los túneles. Para poder utilizar ambos mecanismos necesitamos tener instalado el paquete (más concretamente, el fileset) bos.net.ipsec.rte:bruja:/# lslpp -l bos.net.ipsec.rte Fileset Level State Description ---------------------------------------------------------------------------- Path: /usr/lib/objrepos bos.net.ipsec.rte 4.3.3.0 COMMITTED IP Security Path: /etc/objrepos bos.net.ipsec.rte 4.3.3.0 COMMITTED IP Security bruja:/#Un túnel define una asociación entre dos máquinas en las que se han especificado parámetros de seguridad compartidos entre los dos extremos del túnel; el hecho de que se implique a otra máquina hace que, excepto en entornos muy homogénos - sistemas AIX - o en casos concretos, no se suela utilizar este mecanismo. En cambio, el filtrado de paquetes sí que se utiliza, ya que proporciona a un entorno aislado una protección frente a otras máquinas sin tener que modificar para nada el operativo o las aplicaciones de estas: proporciona un sistema de filtrado sencillo pero efectivo en máquinas en las que por cualquier motivo - dinero, utilización, rendimiento...- no se pueden implantar otras soluciones cortafuegos más completas, como CheckPoint Firewall-1 o IBM SecureWay Firewall. Por este motivo, en este punto vamos a comentar brevemente algunos aspectos del filtrado de paquetes en AIX, sin entrar en el apartado de túneles; si alguien está interesado en profundizar más en estos mecanismos de seguridad IP para AIX, puede consultar [IBM97b].
Para gestionar este sistema de filtrado podemos utilizar órdenes como rmfilt, mkfilt, genfilt o lsfilt; como siempre, es recomendable consultar las páginas de ayuda de cada una de ellas, aunque en este caso más que recomendable podríamos decir imprescindible, ya que el manejo de los filtros no es ni mucho menos inmediato, y la sintaxis para definir reglas es relativamente compleja. Para poner en marcha el sistema de filtrado necesitamos generar reglas y posteriormente activarlas; en el fichero /usr/samples/ipsec/filter.sample tenemos ejemplos de como definir una regla, un filtro de red, mediante genfilt.
El uso de genfilt puede llegar a ser bastante complicado, debido principalmente a su sintaxis (como acabamos de decir, es imprescindible consultar su página de manual). Para definir una regla nueva es obligatorio indicar al menos el protocolo sobre el que se aplicará (IPv4 o IPv6), así como el host o red origen y su máscara correspondiente; el resto de parámetros (destino, puertos de conexión, interfaz de red...) son opcionales, aunque como sucede en muchas otras ocasiones, es necesario estar atento a los valores que el sistema toma por defecto: por simple Ley de Murphy, serán restrictivos cuando nos interese que sean permisivos y viceversa. Para hacernos una idea de cómo se definen reglas mediante genfilt, si por ejemplo necesitáramos permitir todo el tráfico de una red local contra una máquina AIX situada en ella (192.168.0.10), la orden para lograrlo sería similar a:
bruja:/# genfilt -v 4 -a P -s 192.168.0.0 -m 255.255.0.0 -d 192.168.0.10 -M \ > 255.255.255.255 -i all bruja:/#Aunque no vamos a entrar aquí en detalles de la sintaxis de las reglas, veremos al final de este punto un shellscript como ejemplo de filtrado en una máquina AIX en el que se incluirán algunas definiciones de filtros; en cualquier caso, como ya hemos dicho, existe un fichero con ejemplos de reglas en /usr/samples/ipsec/filter.sample que podemos consultar para hacernos una idea de la sintaxis de genfilt.
Para activar el conjunto de reglas de filtrado que hayamos definido previamente mediante tenemos que utilizar la orden mkfilt; no obstante, antes de esto debemos haber generado los dispositivos especiales ipsec_v4 e ipsec_v6 (como su nombre indica, el segundo hace referencia a IPv6, mientras que el primero es relativo al protocolo clásico) en el sistema de ficheros utilizando mkdev, ya que de lo contrario la activación no será posible:
bruja:/# mkfilt -v 4 Device ipsec_v4 not found. Filter activation for IPv4 not performed. bruja:/# /usr/sbin/mkdev -c ipsec -t 4 ipsec_v4 Available bruja:/# /usr/sbin/mkdev -c ipsec -t 6 ipsec_v6 Available bruja:/#Una vez creados ambos ficheros especiales ya podemos activar el ruleset definido; por ejemplo, el siguiente shellscript - o modificaciones del mismo - puede utilizarse para definir un sencillo sistema de filtrado en nuestra máquina:
bruja:/# cat /etc/filtros #!/bin/sh # # Script para filtrar paquetes en una maquina AIX. # Antonio Villalon, Noviembre 2001 # ############# # Eliminamos y deshabilitamos reglas anteriores ############# /usr/sbin/rmfilt -v 4 -n all /usr/sbin/rmfilt -v 6 -n all /usr/sbin/mkfilt -v 4 -d /usr/sbin/mkfilt -v 6 -d ############# # Permitimos todo desde LAN ############# genfilt -v 4 -a P -s 192.168.0.0 -m 255.255.0.0 -d 192.168.0.10 -M \ 255.255.255.255 -i all ############# # Salida, todo abierto ############# genfilt -v 4 -a P -s 192.168.0.10 -m 255.255.255.255 -d 0 -M 0 ############# # Vuelta de DNS ############# genfilt -v 4 -a P -s 0 -m 0 -d 0 -M 0 -g N -c udp -o eq -p 53 -O gt -P 1023 ############# # Prohibimos todo lo no habilitado por defecto ############# genfilt -v 4 -a P -s 0 -m 0 -d 192.168.0.10 -M 255.255.255.255 -c tcp/ack genfilt -v 4 -a D -s 0 -m 0 -d 192.168.0.10 -M 255.255.255.255 ############# # Activamos las reglas para IP e IPv6 ############# /usr/sbin/mkfilt -v 4 -u /usr/sbin/mkfilt -v 6 -u bruja:/#Podemos ver que la activación del conjunto de reglas se realiza mediante la opción `-u' de mkfilt, tanto para IPv4 como para IPv6; esto significa que es a partir de la ejecución de esta orden cuando el sistema de filtrado comienza a funcionar.
Para consultar el conjunto de reglas definidas en nuestra máquina podemos utilizar el comando lsfilt (si lo ejecutamos sin ninguna opción nos proporcionará el listado de todas las reglas, tanto activas - las que se están aplicando - como inactivas - definidas pero sin ser aplicadas -). Como en otros sistemas de filtrado, a cada regla se le asigna un número de orden, y es ese número el que indica la precedencia de su aplicación: si un paquete hace match con una cierta regla, es esa la que se aplica, descartando las que son posteriores; es una aproximación similar a la seguida en Firewall-1 o ipchains, pero diferente de la de otros cortafuegos como IP Filter. Para consultar una regla concreta podemos utilizar las diferentes opciones de la orden lsfilt:
bruja:/# lsfilt -v 4 -n 3 Rule 3: Rule action : permit Source Address : 192.168.0.0 Source Mask : 255.255.0.0 Destination Address : 192.168.0.10 Destination Mask : 255.255.255.255 Source Routing : yes Protocol : all Source Port : any 0 Destination Port : any 0 Scope : both Direction : both Logging control : no Fragment control : all packets Tunnel ID number : 0 Interface : all Auto-Generated : no bruja:/#Para acabar este punto quizás es necesario saber cómo deshabilitar el sistema de filtrado; ya lo hemos visto antes, en el shellscript de ejemplo, pero hay que recordar que mediante la opción `-d' de la orden mkfilt podemos hacerlo. Esto es especialmente importante en situaciones en las que un filtro incorrecto deja inaccesible el sistema o alguna aplicación crítica, ya que la posibilidad de deshabilitar todo el filtrado mediante una orden sencilla, en línea de comandos, proporciona una solución rápida y efectiva este tipo de problemas.
El subsistema de red
Igual que en Solaris hemos visto, antes de comentar aspectos relativos a la seguridad del subsistema de red del operativo, la orden `ndd', en AIX es necesario introducir el comando `no' (Network Options), encargado de configurar (y visualizar) parámetros del subsistema de red de AIX. Y de la misma forma que hemos dicho que la gestión de seguridad de los usuarios (contraseñas, restricciones de acceso, límites...) es en AIX excelente, y que otros Unices deberían tomar nota, es justo decir ahora que la configuración de parámetros del núcleo relativos a la seguridad en AIX es más pobre que en Solaris, aunque no por ello deba considerarse débil o inadecuada.Como en cualquier Unix, una norma básica en la seguridad del subsistema de red para prevenir ataques de spoofing es no reenviar paquetes a no ser que nuestro equipo trabaje como un router o una pasarela; por tanto, es una buena idea desactivar el IP Forwarding tanto de tramas IP como de tramas IPv6:
bruja:/# no -o ipforwarding=0 bruja:/# no -o ip6forwarding=0 bruja:/#Para evitar ataques de SYN Flooding es interesante el parámetro clean_partial_conns, que define si se van a eliminar aleatoriamente conexiones incompletas (aquellas en las que no se ha completado el protocolo a tres bandas) de la cola del servidor para dejar hueco a nuevas entradas:
bruja:/# no -o clean_partial_conns=1 bruja:/#Respecto a algunos aspectos del protocolo ICMP, es recomendable no responder a los pings lanzados a direcciones de broadcast, ya que si lo hacemos podemos llegar a saturar una red, facilitando ataques de negación de servicio; esto se consigue asignando a la directiva bcastping un valor falso (`0'). De la misma forma, es también interesante no permitir broadcasts dirigidos a una pasarela para que sean emitidos en el otro extremo de la misma, para lo que debemos asignar a directed_broadcast un valor `0'. Además podemos hacer que nuestra máquina no responda a peticiones ICMP del tipo ICMP/SMALL>_MASK/SMALL>_REQUEST, asignando a la directiva icmpaddressmask el valor `0' (el que tiene por defecto):
bruja:/# no -o bcastping=0 bruja:/# no -o directed_broadcast=0 bruja:/# no -o icmpaddressmask=0 bruja:/#También relacionados con el protocolo ICMP, es necesario comentar aspectos relativos a las tramas ICMP/SMALL>_REDIRECT; podemos restringir la emisión de estos paquetes (recordemos que sólo un router debería poder enviarlos) mediante la directiva ipsendredirects, mientras que para deshabilitar la recepción de los mismos podemos utilizar ipignoreredirects:
bruja:/# no -o ipsendredirects=0 bruja:/# no -o ipignoreredirects=1 bruja:/#Como ya vimos, la gestión de paquetes source routed también puede presentar serias amenazas a nuestra seguridad; en AIX tenemos varios parámetros relativos al manejo de este tipo de tramas. En primer lugar es necesario desactivar tanto la generación como la recepción y el reenvío de las mismas, mediante los parámetros ipsrcroutesend, ipsrcrouterecv e ipsrcrouteforward respectivamente, asignandoles a todos valores de `0' (falso); el último de ellos tiene un equivalente especial para IPv6 denominado ip6srcrouteforward. Además, otro parámetro importante es nonlocsrcroute, que indica que sólo los paquetes source routed estrictos (strict source routed, paquetes en los que se especifica el camino concreto que ha de seguir la trama, a diferencia de los paquetes loose source routed, en los que sólo se marca un nodo por el que la trama ha de pasar y no el camino completo) pueden ser reenviados a través del host; su valor también ha de ser falso12.3:
bruja:/# no -o ipsrcroutesend=0 bruja:/# no -o ipsrcrouterecv=0 bruja:/# no -o ipsrcrouteforward=0 bruja:/# no -o ip6srcrouteforward=0 bruja:/# no -o nonlocsrcroute=0 bruja:/#Respecto al timeout de la caché ARP del que ya hemos hablado en Solaris y Linux, en AIX este parámetro viene definido por la variable arpt_killc; no obstante, su valor afecta tanto a entradas ARP no utilizadas como a entradas activas, por lo que nos debemos plantear con cuidado la conveniencia de modificarlo; en cualquier caso, podemos definir en minutos el timeout también mediante la orden no:
bruja:/# no -o arpt_killc=1 bruja:/#Además de la orden `no', otro comando que nos permite configurar parámetros interesantes para nuestra seguridad a nivel del subsistema de red - especialmente si administramos un servidor NFS - es `nfso', que configura y visualiza diferentes parámetros relacionados con este sistema de ficheros; su sintaxis es bastante similar a la de `no' (en cualquier caso, como sucede con todas las órdenes de un sistema Unix, es recomendable consultar la página de manual correspondiente), y entre los parámetros que permite configurar existen también algunos relacionados con la seguridad del sistema. Quizás el más importante es portcheck, que define el comportamiento del servidor ante peticiones provenientes de puertos no privilegiados: si su valor es 0 (por defecto es así) no se efectúa ningún tipo de comprobación, mientras que si es 1 se realiza el port checking y sólo se admiten peticiones desde puertos remotos privilegiados; por ejemplo, si queremos que esto sea así debemos ejecutar la siguiente orden (recordamos que, al igual que sucedía con `no', los cambios sólo tienen efecto sobre el kernel que se encuentra en ejecución, por lo que si se produce un reinicio de la máquina el comportamiento será el definido por defecto):
bruja:/# nfso -o portcheck portcheck= 0 bruja:/# nfso -o portcheck=1 bruja:/# nfso -o portcheck portcheck= 1 bruja:/#Existen otros parámetros configurables mediante nfso que nos pueden resultar interesantes para incrementar nuestra seguridad; por ejemplo, nfs_use_reserve_ports puesto a 0 (por defecto) especificará que se utilicen puertos no reservados para las comunicaciones entre cliente y servidor NFS, nfs_max_connections y nfs_max_threads definen respectivamente límites al número de conexiones simultáneas y de hilos servidores que se van a aceptar en un sistema AIX, etc. Como siempre, es imprescindible consultar la página de manual correspondiente en la versión de AIX que estemos ejecutando para conocer todos los parámetros sintonizables mediante `nfso' y sus repercusiones en nuestra seguridad.
Tal y como sucedía con `ndd', los cambios efectuados con `no' tienen efecto sobre el kernel que se está ejecutando en un cierto momento, por lo que si el sistema se reinicia deberemos volver a dar el valor que nos interese a ciertos parámetros ejecutando la orden en el arranque de la máquina. En AIX este arranque es más peculiar que en otros entornos, y si queremos añadir estas instrucciones en cada inicio del sistema debemos crear el script correspondiente y planificarlo para que se ejecute desde /etc/inittab ([Bha01]):
bruja:/# cat /etc/rc.securenet /usr/sbin/no -o ipforwarding=0 /usr/sbin/no -o ip6forwarding=0 /usr/sbin/no -o clean_partial_conns=1 /usr/sbin/no -o bcastping=0 /usr/sbin/no -o directed_broadcast=0 /usr/sbin/no -o icmpaddressmask=0 /usr/sbin/no -o ipsendredirects=0 /usr/sbin/no -o ipignoreredirects=1 /usr/sbin/no -o ipsrcroutesend=0 /usr/sbin/no -o ipsrcrouterecv=0 /usr/sbin/no -o ipsrcrouteforward=0 /usr/sbin/no -o ip6srcrouteforward=0 /usr/sbin/no -o arpt_killc=1 /usr/sbin/nfso -o portcheck=1 bruja:/# chmod 700 /etc/rc.securenet bruja:/# mkitab "rcsecurenet:2:once:/etc/rc.securenet 2>&1 >/dev/console" bruja:/#
Siguiente: HP-UX Subir: Algunos sistemas Unix Anterior: Linux Índice General 2002-07-15
