AIXDefinicin de ColoresNombre del Cliente:Control evaluado como inadecuadoPeriodo:Control evaluado como adecuado y no efectivoControl evaluado como adecuado y efectivo

Nombre del Servidor: reaNo. de ref.Referencia Work Program (AIX Work Program - BETA - July 2005)Objetivo de controlActividad de ControlResultados de la pruebaConclusin sobre efectividad (efectivo / no efectivo)Referencia a la matriz de debilidadesReferencia de papeles de trabajo o evidencia en legajo externoRiesgoDescripcin del plan de pruebaObtener informacin1. Parametrizacin de la plataforma que soporta la aplicacin y/o bases de datos de los servidores crticos para la operacin.1.11Se llevan a cabo controles sobre los usuarios y grupos que se administran en el sistema para prevenir el accesos no autorizado o accesos privilegiado.El acceso a la lnea de comandos va shell aumenta el riesgo de que usuarios no autorizados puedan acceder a los comandos, datos y archivos de configuracin.El acceso a la lnea de comandos puede ser restringido mediante el uso de shells restringidos o mediante el uso de scripts de login.

Los siguientes son Shells que comnmente permiten el acceso, en forma normal, a los usuarios:csh - "C shell"ksh - "Korn shell"sh - "Bourne shell2

Los siguientes son Shells restringidos que limitan el acceso desde la lnea de comandos: rsh - "restricted Bourne shell"rksh - "restricted Korn shell"

Verificar que los usuarios no tengan acceso a alguno de los shells que permita el acceso a lnea de comandos, mediante la inspeccin del archivo /etc./passwd. En caso de detectar usuarios con acceso a lnea de comandos a travs de un shell, revisar dichas cuentas con el administrador del sistema para verificar que estos usuarios requieren el acceso a lnea de comando. Adems, consultar con el administrador del sistema y determinar si hay otros mtodos utilizados para limitar los usuarios con respecto a la lnea de comandos. El acceso a la lnea de comandos puede ser restringido mediante el uso de shells restringidos o mediante el uso de scripts de inicio de sesin.

El shell "nologin" no permite el acceso a la lnea de comandos. Generalmente aparece como "/bin/nologin". En forma similar los shells "true" y "false" no permiten el acceso a la lnea de comandos. Estos ltimos generalmente aparecen como "/bin/true" y "bin/false"

Para analizar el acceso a la lnea de comandos va shell aumenta el riesgo de que los usuarios no autorizados puedan acceder a los comandos, datos y archivos de configuracin se debe realizar lo siguiente:

1) Abrir el archivo .2) Se debe analizar si cuentan con shells que permitan el acceso a los usuarios:

csh - "C shell"ksh - "Korn shell"sh - "Bourne shell"

3) Si se encuentran shell que permitan accesos se deber consultar al administrador por cada uno de ellos4) Analizar cuales comandos tienen "nologin" o alguno de los shell restringidos que limitan el acceso de la lnea de comandos.

rsh - "restricted Bourne shell"rksh - "restricted Korn shell"

Nota: Se debe revisar el tipo de usuarios en el sistema. Si el sistema slo cuenta con usuarios de TI los mismos generalmente tienen acceso justiciado a la lnea de comandos. En caso de existir usuarios finales, se debe confirmar que tengan shell restringido o "nologin" o se debe preguntar al administrador si por medio de algn script son enviados a la aplicacin. En este caso se debe confirmar que se use el comando "trap" para evitar que los usuarios puedan terminar el script y obtener acceso a la lnea de comandos.M

Puede ser que este control sea se riesgo alto (H), si la aplicacin es un desarrollo propio o un sistema Legacy1.23El acceso privilegiado a las cuentas se limita a un nmero adecuado de personas.Se han implementado mecanismos que restringen el acceso remoto a las cuentas de administracin del sistema. Los usuarios son forzados a registrarse a travs de cuentas no privilegiadas registrando los cambios a las cuentas de administracin. Revisar el archivo /etc./passwd para todos los perfiles de usuario. Comprobar cuales usuarios tienen autorizaciones especiales (es decir, root o ID 0 ) y determinar si el nmero de usuarios es el adecuado. Adems revisar las cuentas que tienen acceso como root en el archivo /var/adm/sulog, y determinar si esos usuarios son los adecuados.

Un listado de los usuarios con privilegios de administrador ( UID = 0 ) aparece en el script dentro de los resultados del script buscando DO_UIDZERO (dentro del archivo .).

El contenido del archivo sulog se puede localizar dentro del archivo de resultados del script ..logs. Buscar [FILE]: /var/adm/sulogPara poder analizar si se han implementado mecanismos que restringen el acceso remoto a las cuentas de administracin, se debe realizar el siguiente procedimiento:

1) Abrir el archivo ..xls2) Deber buscar "DO_UIDZERO" 3) Verificar cuales usuarios tienen autorizaciones especiales (es decir, ROOT o ID 0) y determinar si el numero de usuarios es el adecuado. 4) Abrir el archivo ..logs5) Ver el contenido del archivo sulog y localizar las cuentas que tienen acceso como root y determinar si son los adecuados. 6) Si se encuentran cuentas que tengan accesos como root se deber consultar al administrador por el uso de ellas.H1.38El registro de auditoria es mantenido, revisado para detectar actividad no autorizada o maliciosa en el sistema.Se ha configurado el sistema operativo para registrar los errores y advertencias del sistema con el objetivo de generar un histrico de eventos.Consultar con el administrador del sistema y determinar qu niveles de auditora estn activados, en donde se registra la informacin de auditora y hasta qu punto la informacin es revisada de manera proactiva.

En AIX, la auditora est habilitada a nivel de evento. Un evento auditable es cualquier evento de seguridad relevante ocurrido en el sistema. Un evento de seguridad relevante es cualquier cambio en el estado de seguridad del sistema, o cualquier intento de violacin al sistema de control de acceso o las polticas de seguridad, o ambas cosas. La informacin registrada en los logs incluye el nombre del evento auditable, el xito o el fracaso del evento, y cualquier otra informacin que sea relevante. El archivo /etc./security/audit/config contiene los eventos y los usuarios que son procesados por el subsistema de auditora.

Los eventos que deben ser considerados para la auditora, son los siguientes: Autenticacin de usuarios Usuarios que utilizan el comando su o la cuenta root Acceso al sistema Cambiar la configuracin del sistema Intentos de evadir el sistema de auditora Inicializar el sistema Modificacin de cuentas

Los registros de auditora se pueden registrar utilizando los mtodos de recoleccin BIN, STREAM, o ambos. El modo BIN escribe en archivos que se van alternando, lo cual provee seguridad y posibilidad de almacenamiento a largo plazo. El modo STREAM escribe los registros a un buffer circular. El modo STREAM ofrece respuesta inmediata.

Archivos adicionales donde se puede almacenar informacin la auditora incluyen log logs de /var/adm/sulog y en el directorio /var/adm/loginlog. El archivo de log denominado sulog captura los intentos exitosos y fallidos del uso del comando su realizados por un usuario. El archivo de log denominado loginlog captura cualquier intento fallido de acceso que supere el lmite definido por el sistema.

Para an alizar si se ha configurado el sistema operativo para registrar los errores y advertencias del sistema, de deber realizar el siguiente procedimiento:

1) Abrir el archivo ..osmodules2) Ver la configuracin "[FILE]: CONFIG" y analizar el contenido del archivo "/etc./security/audit/config" el cual podremos ver la configuracin del sistema y su auditoria.3) Abrir ..logs4) Ver la configuracin de [FILE]: /var/adm/sulog y analizar la configuracin del archivo "/var/adm/sulog", este es un fichero de texto donde se registran las ejecuciones de la orden su, indicando fecha, hora, usuario que lanza el programa y usuario cuya identidad adopta, terminal asociada y xito (`+') o fracaso (`-') de la operacin.

M1.57Los controles de autenticacin estn configurados para evitar que las cuentas en el sistema se vean comprometidas.La polticas de configuracin de las contraseas en el sistema han sido configuradas para garantizar la generacin de contraseas robustas como longitud mnima y mxima, tiempo de vida, intentos de acceso fallidos permitidos, etc.Revisar la salida del comando $lsuser ALL o revisar el archivo de usuarios /etc/security/user para verificar que las siguientes variables se definen de acuerdo con la poltica de seguridad de la empresa o de acuerdo a las mejores prcticas:

MINLENMAXAGELOGINRETRIESHISTSIZE

A continuacin se sealan las guas de la industria: LOGINRETRIES (nmero de intentos de acceso no vlidos antes de cierre): MAXAGE (nmero mximo de semanas en que una contrasea es vlida): MINLEN (mnima longitud contrasea):

Referirse a "[FILE]: USER" para validar los parmetros globales (default) y "MODULE_BEGIN: check_lsuser"en el archivo ..osmodules para obtener la salida del comando $lsuser ALL para cada una de las cuentas de usuariosPara poder analizar los controles de autenticacin estn configurados para evitar que las cuentas en el sistema se vean comprometidas, se deber realizar el siguiente procedimiento:

1) Abrir el archivo ..osmodules2) Verificar la configuracin de los parmetros de autenticacin y su valor por defecto debe ser el siguiente:

- MINLEN: 8 caracteres.- MAXAGE: 60 mximo de semanas de contraseas validas.- LOGINRETRIES: 6 nmeros de intentos de accesos.- HISTSIZE: 7 nmero de contraseas anteriores que no pueden ser reutilizadas.

3) A travs de la opcin "MODULE_BEGIN: check_lsuser", se podr verificar cuenta por cuenta cada configuracin de estos parmetros.M1.69Archivos y directorios sensibles estn asegurados para prevenir el acceso no autorizado.El acceso no autorizado es mayor si los permisos y la propiedades estn inadecuadamente asignados en conjunto los directorios estndar de UNIX y los directorios que contienen programas o datos financieros importantes. La ejecucin de archivo crontabs estn restringidos solo a usuarios autorizados.Revisar los permisos en los archivos /var/sol/cron/crontabs/* para comprobar que son de propiedad del usuario para el que se nombran o de root y que son de lectura y escritura slo para este dueo o para root. Revisar el contenido de los archivos crontab y obtener una lista de programas que se ejecutan dentro de estos archivos. Compruebe que todos los programas en esta lista tienen la propiedad de lectura y escritura slo por este dueo o por root.

Buscar en "CHECK_BEGIN: DO_CRON" en el archivo . referente a la informacin de los crontab. La informacin de los crontab termina en "CHECK_END: DO_CRON".

Referirse al archivo ..ww para enlistar los archivos y directorios con permisos de escritura universal. Verificar que ninguno de los archivos crontab, programas ejecutados por crontabs, o directorios que contiene los programas ejecutables por crontabs tienen permisos de escritura universal.

Referirse al archivo ..keydirs. Verificar todos los archivos crontab, programas ejecutados por crontab, o directorios que contienen los programas ejecutados por crontab puedan ser ejecutados y modificados por root o por el dueo de los crontab. Nota: No todos los archivos referenciados crontab se encuentra listados en el archivo ..keydirs file.Para poder analizar los archivos y directorios relevantes deben contar con una adecuada configuracin para evitar accesos no autorizados, se deber realizar lo siguiente:

1) Abrir el archivo ..xls2) Analizar que el archivo "crontabs" no esta presente.3) Abrir al archivo ..ww.xls 4) Analizar y comprobar que todos los programas en esta lista tienen la propiedad de escritura y slo por este dueo o por root. Revisar los permisos heredados de todos los directorios de los programas en esta lista para comprobar que pertenecen al dueo o root y slo ellos tienen permisos de escritura.5) Abrir el archivo ..keydirs.xls6) Analizar y comprobar que todos los archivos crontab, programas ejecutados por crontab, o directorios que contienen los programas ejecutados por crontab puedan ser ejecutados y modificados por root o por el dueo de los crontab. H12Consultar con el administrador del sistema cuales son los archivos de las aplicaciones o programas financieros. Para cada directorio y archivo, obtener los permisos del directorio, usando el comando "ls -lR". Los archivos y directorios de todas las aplicaciones financieras deben ser asignados los dueos y los grupos apropiados. El campo de permisos "otros" no debe tener permiso de escritura. Los permisos de escritura para el campo de permisos "otros" slo debe permitirse si existe documentacin que respalde el uso por necesidades operativas que no pueda cubrirse con una configuracin ms segura.Realizar el control segn lo que se describe en "Descripcin de plan de prueba".H1.7N/ATodos los usuarios deben tener el valor "umask", que define los permisos para los archivos de nueva creacin, de 027.La variable "umask" se utiliza por defecto en el archivo de creacin de permisos."umask" permite la configuracin a los usuarios que no sea el propietario leer o escribir un archivo Revisar el valor por default de la variable "umask" as como el valor configurado para cada usuario.Revisar el valor por default de umask en el archivo /etc./profile o en /etc./loganRevisar el valor de umask configurado para cada usuario dentro de los archivos .profile y/o .cshrc de cada usuario.Verificar que el valor de umask en estos archivos estn configurados con 027 o ms restringidos.

.Para analizar si la variable "umask" se utiliza por defecto en el archivo de creacin de permisos, se deber realizar el siguiente procedimiento:

1) Abrir el archivo .2) Verificar el parmetro "CHECK_BEGIN: DO_UMASK" 4) Comprobar la informacin de la configuracin y lo relacionado con el valor de UMASK.3) Abrir el archivo ..userfiles4) Analizar "MODULE_BEGIN: check_startup_files"5) Verificar el valor de UMASK dentro de los archivos de configuracin de cada usuario (.profile, .login, and .cshrc files).L

El riesgo vara dependiendo de los usuarios que tienen acceso a lnea de comandos y de la aplicacin que aloja el servidor.1.813El sistema est bien configurado para maximizar la seguridad y reducir el riesgo de comprometer el sistema. Se han deshabilitado del sistema aquellos servicios que proporcionan informacin sensitiva del equipo. Revisar los archivos relacionados con la funcionalidad denominada "relaciones de confianza" o "trusted hosts": - los archivos.rhosts en los directorios home de usuarios no deben permitirse.- el archivo /etc./hosts.equiv debe ser eliminado; - los archivos .netrc no deben permitirse.

Nota: El script de PwC obtiene la informacin necesaria para realizar esta prueba sin embargo, en caso de realizarse una revisin directa el administrador del sistema tiene que ejecutar un comando que buscar en cualquier entorno UNIX los archivos .rhosts, hosts.equiv y .netrc.. El comando es el siguiente: $cut -d: -f6 /etc/passwd | sort -u | xargs -I {} -t ls -ld {}/.netrc

Si alguno de estos tres tipos de archivos existen, pregunte con el administrador del sistema la razn de los mismos En algunos casos, las aplicaciones de negocio requieren de estos archivos con fines de comunicacin.

Para comprobar que se han deshabilitado del sistema aquellos servicios que proporcionan informacin sensitiva del equipo, se deber realizar el siguiente procedimiento:

1) Abrir el archivo .2) Buscar el comando "[FILE]: HOSTS.EQUIV".3) El archivo no debe de existir o debe encontrarse vacio. 4) Abrir el archivo ..userfiles5) Buscar el archivo .netrc.6) Estos archivos no deben existir .L1.913Servicios innecesarios, protocolos y componentes del sistema estn deshabilitadas o eliminadas para limitar las vulnerabilidades y debilidades en el servidor potenciales. Se han deshabilitado del sistema aquellos servicios que proporcionan informacin sensitiva del equipo. Revise el archivo / etc. / inetd.conf para comprobar que la lnea correspondiente a telnet se ha comentado o no existe.

A menos que exista una necesidad operativa o de negocio documentados para el uso de telnet, debe ser desactivada por tener la entrada telnet en el archivo / inetd.conf / etc. comentada. El proceso inetd luego se debe reiniciar.

Si hay un documentado operativo o negocio necesita para la funcionalidad de telnet, luego de Secure Shell (SSH), que cifra las sesiones de usuario, se debe utilizar como un sustituto para telnet.

Secng script output file: : . filePara poder verificar que los servicios de red estn establecidos de acuerdo a las normas de seguridad, se debe solicitar lo siguiente:

1) Solicitar al administrador el resultado del siguiente comando, "/ etc. / inetd.conf"2) Verificar que el servicio "Telnet" se encuentre desactivado, a menos que exista una necesidad operativa o de negocio documentados para el uso de telnet, esta debe ser desactivada.M