Definicin de Colores

Control evaluado como inadecuado

efectivo
efectivo

Nombre del Cliente:

Periodo:

rea

No. de ref.

Nombre del Servidor:

1. Parametrizacin 1.1
de la plataforma
que
soporta
la
aplicacin
y/o
bases de datos de
los
servidores
crticos para la
operacin.

Referencia Work
Program (AIX Objetivo
Work Program - control
BETA - July 2005)

de

Actividad de Control

Se llevan a cabo El acceso a la lnea de

controles sobre comandos va shell
los usuarios y
aumenta el riesgo de
grupos que se
que usuarios no
administran en el autorizados puedan
sistema para
acceder a los
prevenir el
comandos, datos y
accesos no
archivos de
autorizado o
configuracin.
accesos
privilegiado.

1.2

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

1.3

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

1.5

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

1.6

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

12

1.7

N/A

Todos 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

1.8

13

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

1.9

13

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

Servidor:

Descripcin del plan de prueba

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"

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 <servername>.<date>).
El contenido del archivo sulog se puede localizar dentro del archivo de resultados
del script <servername>.<date>.logs. Buscar [FILE]: /var/adm/sulog

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.

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:
MINLEN
MAXAGE
LOGINRETRIES
HISTSIZE
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 <servername>.<date>.osmodules
para obtener la salida del comando $lsuser ALL para cada una de las cuentas de
usuarios

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 <servername>.<date>
referente a la informacin de los crontab. La informacin de los crontab termina
en "CHECK_END: DO_CRON".
Referirse al archivo <servername>.<date>.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 <servername>.<date>.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 <servername>.<date>.keydirs file.

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

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./logan
Revisar 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.
.

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.

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: : <servername>.<date> file

Obtener informacin

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 <servername>.<date>
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 ellos
4) 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.

Para 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 <servername>.<date>.xls
2) 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 <servername>.<date>.logs
5) 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.

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 <servername>.<date>.osmodules
2) 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 <servername>.<date>.logs
4) 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.

Para 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 <servername>.<date>.osmodules
2) Verificar la configuracin de los parmetros de autenticacin y su valor por
defecto debe ser el siguiente:
- MINLEN:
- MAXAGE:
- LOGINRETRIES:
- HISTSIZE:
reutilizadas.

8 caracteres.
60 mximo de semanas de contraseas validas.
6 nmeros de intentos de accesos.
7 nmero de contraseas anteriores que no pueden ser

3) A travs de la opcin "MODULE_BEGIN: check_lsuser", se podr verificar

cuenta por cuenta cada configuracin de estos parmetros.

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 <servername>.<date>.xls
2) Analizar que el archivo "crontabs" no esta presente.
3) Abrir al archivo <servername>.<date>.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 <servername>.<date>.keydirs.xls
6) 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.

Realizar el control segn lo que se describe en "Descripcin de plan de prueba".

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 <servername>.<date>
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 <servername>.<date>.userfiles
4) 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).

Para comprobar que se han deshabilitado del sistema aquellos servicios que
proporcionan informacin sensitiva del equipo, se deber realizar el siguiente
procedimiento:
1)
2)
3)
4)
5)
6)

Abrir el archivo <servername>.<date>

Buscar el comando "[FILE]: HOSTS.EQUIV".
El archivo no debe de existir o debe encontrarse vacio.
Abrir el archivo <servername>.<date>.userfiles
Buscar el archivo .netrc.
Estos archivos no deben existir .

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

Resultados de la prueba

Conclusin Referenci
sobre
a a la
Referencia de papeles
efectividad matriz de de trabajo o evidencia
(efectivo / no debilidade
en legajo externo
efectivo)
s

Riesgo

M
Puede ser que este control
sea se riesgo alto (H), si la
aplicacin es un desarrollo
propio o un sistema
Legacy

L
El riesgo vara
dependiendo de los
usuarios que tienen acceso
a lnea de comandos y de
la aplicacin que aloja el
servidor.