Nmero

Actividad de Control
User Management
1 Access to the root account should be restricted and
should provide an audit trail of activity

2 Every account defined on the system his clearly

identifiable with a user.

3 Controls are in place over user and groups that are

managed on the system to prevent unauthorized or
privileged access.

4 The system is securely configured to maximize security

and reduce the risk of system compromise

Password Management
5 All interactive logon accounts (shell accounts) on a
UNIX server should require a password and encrypted
passwords should be stored in shadow password files.

6 Password minimum length should be set according to

corporate standards and industry good practices,

7 Passwords lifetime and length should prevent

compromise

Auditing, Logging & Monitoring

8 A manageable audit trail is maintained, reviewed and
secured to detect unauthorized or malicious activity on
the system.

9 Failed login attempts should be monitored. Review

repeated failures for the same account in order to
prevent a brute force attack.

File System Access and Management

10 Changes on sensitive configuration files, such as those
used for user administration or scheduled jobs, should
be known and premeditated. Unwanted changes on
those files may result in a complete system loss of
control.

11 Sensitive files and directories are secured to prevent

unauthorized access.

11 Sensitive files and directories are secured to prevent

unauthorized access.

12 Only authorized users should have access to the

scheduling system

13 Permissions on key files and directories are restricted

as possible.

14 Access to program and data files should be

appropriately restricted

Network Controls
15 Exported file systems are not be exported with the 'root'
option.

16 Remote access to computer systems (via network

connections or dial-up) should be appropriately
restricted.

17 If there is no strong business need for rwall, then it

should be disabled.

17 If there is no strong business need for rwall, then it

should be disabled.

18 At least a strong business need exists, tftp service

should be disabled.

19 The system is securely configured to maximize security

and reduce the risk of system compromise

20 Remote access without users authentication should not

be permitted.

21 NFS exports are done in a secure way.

22 Network services do not pose a security risk on the

system.

System Configuration
23 The system has an adequate level of patches

Punto de Revisin

Procedimiento de validacin

Root is the most sensitive account on the Linux system Inspect the /etc/password file for all user profiles.
and should be properly secured.
Ascertain which users have the special authorities (i.e.,
root or equivalent a UID of 0) and determine
whether the number of users is appropriate. Inquire
with the system administrator to understand if any SU
groups have been setup to access privileged accounts.
If there have been groups setup, obtain the group files,
understand who is in the group and what access they
have to the IDs. Also, review the accounts listed in
the /var/adm/sulog file that are accessing the root
account, to ensure that these users are appropriate

Issue the command # cat /var/log/messages | grep su

to understand who has been accessing root.

All su (switch user) commands, which allow a user to

gain access to the root account, should be monitored
and reviewed in a timely manner, in accordance with
corporate standards
Accounts are defined on the system according to
security standards.

Obtain the /etc/passwd file in a text file. The following

command can be used: # cat /etc/passwd Ensure
users have individual accounts and are not sharing
accounts (look for the first colon separated field). If NIS
or NIS+ is being used, request the NIS map in a text
file.

The following command can be used to list the NIS or

NIS+ password database: #ypcat passwd (for NIS) #
niscat passwd.org_dir | more (for NIS+) Check the
listing for duplicate UID codes (the UID is the third colon
separated field).

Providing access on the server to users without a

business need significantly increase security risks.

Users with domain-wide access may have excessive

privileges (i.e. privilege beyond their job responsibilities)
They may perform unauthorized functions or access
sensitive files.

Access to the command line via a shell increases the

risk that users access unauthorized commands, data,
and configuration files.

Inspect the list of all local user accounts in the

/etc/passwd directory or NIS map. Review the list with
the system administrator to validate and verify the
business function for each account on the server.
Additionally, ensure each user in the /etc/passwd file
has a unique UID and that UID's are not shared. The
UIDs are the third attribute an /etc/passwd file and can
be seen below as '20'.

Joe:*:20:100:info:/home/joe:/usr/bin/csh
Review the local password file or NIS map to determine
accounts with shell (command line) access. Review
these accounts with the system administrator to verify
that these users require shell access. In addition,
inquire with the system administrator if user access is
restricted. Command line access can be restricted
through the use of restricted shells or through the use
of login scripts.

Common shells that typically allow a user to gain

access to the command line include the following:
csh - 'C shell'
ksh - 'Korn shell'
sh - 'Bourne shell'
Common shells that typically restrict command line
access:
rsh - 'restricted Bourne shell'
rksh - 'restricted Korn shell'

Allowing users to log into the system directly as root

from any host on the network, including PCs, increases
the risk that an unauthorized user will gain privileged
access to the system.

Review the /etc/securetty file to ensure that only the

console tty is listed.
Alternately, you may review the
/etc/security/access.conf file and ensure that, at least,
the root account is disabled for remote logins. The
following line should be present for that:
-:root:ALL EXCEPT LOCAL

Usually, the group 'wheel' includes all administrator

accounts. It is a good practice to deny access to this
group. The following line should be present for that:

-:whell: ALL EXCEPT LOCAL

If the entry has a # sign in front of it, that means that the
entry is commented out and is not enforced. If the entry
is commented out, inquire with the system administrator
as to the reason and any mitigating controls that have
been put into place to reduce the risk of remote root
logins.

The /etc/passwd file can be read by any user on the

system in order for programs to function properly. If
encrypted passwords are stored in this file, then any
user can copy encrypted passwords and try to crack
them.

Obtain the /etc/passwd and /etc/shadow files and

examine the 'password' field for each account to ensure
an encrypted password is located in the field. Review
the /etc/passwd file to verify that there are no encrypted
passwords stored in it. If the /etc/passwd file contains
an 'X' or '*' where the encrypted passwords would
reside, the server is shadowed and the encrypted
passwords are stored in the /etc/shadow file. Review
the /etc/shadow file to verify that it contains the
encrypted passwords.

An example of the encrypted password for the 'joe' user

ID is listed below in the 2nd attribute:
joe:9DgBXb2cnG3xA:11460::::::
If NIS is running, obtain the NIS map and examine the
entries to ensure an encrypted password is present for
all accounts allowed to access the server.

Accounts without passwords can also be found using

the following command: awk -F: '($2 == "") { print
$1 }' /etc/shadow

A minimum password length should be defined. This

can be defined to be mandatory for all users. Even so,
corporate standards should encourage users to build
their passwords using capital letters, special symbols
and numbers.

# ypcat passwd (for NIS) # niscat passwd.org_dir |

more (for NIS+)
"Verify the /etc/login.defs file and ensure that the
PASS_MIN_LEN variable is within corporate
guidelines..
Issue the following command: # cat /etc/login.defs |
grep PASS_MIN_LEN

corporate standards should encourage users to build

their passwords using capital letters, special symbols
and numbers.
If possible, run a password cracker program over user's
passwords to ensure non trivial passwords are being
used.
Password lifetime and length settings should minimize
the risk of password compromise

Review the /etc/login.defs file to ensure that the

parameters which set minimum password length
(PASS_MIN_LEN), minimum password lifetime
(PASS_MIN_DAYS) and maximum password lifetime
(PASS_MAX_DAYS) are appropriate

Insufficient logging will result in a lack of an audit trail in

the event of an unauthorized access. With good
logging and monitoring administrators are often given
early warnings for hardware and software errors or
problems.

Review the output of the /etc/syslog.conf file. This file

will show what events are logged and where the
information is sent. Inquire of the system administrator
to determine what is monitored and how the logs are
reviewed.

By default, system alerts are sent to the console and

root account. System emergencies are broadcast to all
users. Information alerts are sent to the syslog file.
These are the standard alerts and do not capture
security events.

Make sure entries within the syslog.conf file do not have

a '#' pound in front of them, commenting them out and
making them inactive.

The following activities should be logged and

configured:
- User login & logout times
- Track all su/root usage through separate sulog or
existing log facilities
- Separating logs from potentially compromised host
(especially true for Internet hosts or large environments)

If repeated failed login attempts are detected, this could Check the /var/log/messages and verify that login
mean that a password guessing or a brute force attack failures are monitored. Query the system administrator
has been attempted. Review if after too many login
about login failures.
attempts, the account didn't successfully login.

Sensitive system files should not change without the

administrators consent. Sensitive configuration files
hold data that can be used to compromise the system.

Review the system sensitive files, such as

/etc/passwd, /etc/shadow, /etc/group, etc/inetd.conf, the
"r" files, cron files, startup files (placed on the /etc/rc*
directories) and specific system configuration files in
order to ensure they don't have write permissions for
non administrator users. Check with the system's
administrator if a control is performed to ensure those
files do not suffer unwanted changes.

Regularly scheduled commands can be specified

according to instructions found in "crontab" files.

Review the permissions on the

/var/spool/cron/crontabs/* files to verify that they are
owned by the user for which they are named or root and
are readable and writeable only by this owner or root.
Review the contents of the crontab files and compile a

If crontab is used to schedule financially significant

jobs, then access to these jobs should be properly
restricted
All directories and files accessed by the standard job
scheduling programs (i.e. cron and at) should be
restricted from all users not requiring this access.

Review the contents of the crontab files and compile a

list of programs that are executed from within these
files. Verify that all programs in this list are owned and
writeable only by this owner or root. Review the
Check restrictive permissions on the following files
(follow the vendor recommendations):

/etc/at.allow

/etc/at.deny
/etc/cron.allow

/etc/cron.deny
Issue the command: ls -l <file>
Review the contents and existence of the files. The files
specify who can and cannot use the commands at, cron
and batch.
# cat <file>
Review permits on directories directly under /, /usr,
/etc, /sbin, /usr/bin, /usr/lib, /usr/libexec, /var/spool, /dev,
/var/spool/cron, /etc/*.d, /var/log and /usr/sbin and
ensure the owner and the permissions set on them are
as restrictive as possible.

Root access or access to sensitive files and resources

might be obtained by a user with command-line access
if permissions and ownership are weak on these
directories.

Issue the command # ls -la and verify the directories

permits and owner. Ensure they are as restrictive as
possible. Inspect the owner and groups and verify that
they are only writeable by root, bin, or sys (i.e.,
privileged IDs).

All programs that run with high levels of privilege should To find for SUID and SGID files, issue the following
be appropriately secured, documented and checked
command:
periodically for changes

$ find / -type f \( -perm -2000 -o -perm -4000 \) -print

If a more detailed view is needed, the following

commands will show detailed information about SUID
and SGID files respectively:

$ find / -type f -perm -4000 -exec ls -l {} \;

$ find / -type f -perm -2000 -exec ls -l {} \;
Determine why these permissions are set for the listed
files.
The 'root' option allows a user to access a NFS
exported file system with root privileges.

Review the /etc/exports file in order to determine

whether any NFS exports are configured with the 'root'
or no_root_squash option .

Individual .rhosts and .netrc files should not exist or

should be empty

Review the environment for any trusted hosts: .rhosts

files in user's HOME directories should not be
allowed; /etc/hosts.equiv file should be eliminated;
.netrc files should not be permitted. Have the system
administrator run a command that will search the Linux
environment for any .rhosts, hosts.equiv and .netrc files.
If any of these three types of files exist, inquire with the
system administrator as to why they exist. In some
instances, applications require some of these files for
communication purposes.

The rwall service has no proper authentication therefore Review the super server (inetd or xinetd) configuration
it represents a risk and must be deactivated.
and ensure rwall service is deactivated.
Run:

The rwall service has no proper authentication therefore

it represents a risk and must be deactivated.

# ps axu | grep wall]

to ensure that the rwall service is not running as a stand
alone daemon.
The tftp service offers no authentication at all but yet
Review the super server (inetd or xinetd) configuration
the possibility of accessing data; therefore it represents and ensure tftp service is deactivated.
a risk and should be deactivated.
Run:
# ps axu | grep tftp
to ensure that the tftp service is not running as a stand
alone daemon.
Without the existence of the /etc/ftpusers file, any user If the FTP service is in use, review the contents of
listed in the /etc/passwd file can transfer files across the the /etc/ftpusers file. The /etc/ftpusers file should be
network. This increases the risk that unauthorized files created if it does not already exist. The /etc/ftpusers file
are transferred across the network.
restricts the User IDs contained within from logging into
the FTP service. At a minimum, the following accounts
should be included:

- root
- bin
- sys
- uucp
- sync
- any guest accounts
- accounts with restricted shell
- any other account that should not be copying files
across the network
Note: As with many UNIX server daemons, configuring
an ftp server is inherently complicated. For companies
or sites with Internet facing ftp servers, please seek
expert review advice.
"Remote access should require authentication and
should be done by using secure tools, such as SSH.

Review all .rhosts files (located at user's home

directories). To list existing .rhosts files: # find / -name
.rhosts -print

Remote access without authentication may allow

spoofing."

Review /etc/hosts.equiv file.

Ensure non authenticated users can remotely access
the system.

File systems exported trough NFS follow the defined

security standards.

Issue the following commands:

# showmount -e
# cat /etc/exports
Ensure the 'ro' option has been used for all shared
filesystems listed in the /etc/exports.

Ensure that filesystems are being exported to a list or

range of host (or IP addressses), as opposed to being
exported to everyone.
Network services should be set according to security
standards.

Review the following with the system administrator to

verify that only those services that serve a strong
business need are available:

each service in the /etc/inetd.conf

file (in the case that inetd is being
used) or the /etc/xinetd.d/* files (in
the case that xinetd is being used)
each service configured to start
at boot time in the startup scripts: #
ls -lL /etc/rc*

each service using insecure RPC

authentication: # rpcinfo -p
the output of the following
command, which identifies
processes currently running on the
server:
# ps aux

The system should be protected with security patches

according to the documented patching procedure.

" Check the version of the installed kernel by executing

the command:
# uname -r
Check the version of the installed software. Depending
on the packages the distribution works with, run one of
the following commands:
For deb packages (Debian, SuSE, Xandros, etc.):
#dpkg -l *
For rpm packages (RedHat, Fedora, Mandrake,
etc.):#rpm -qa
Compare the installed versions with each vendor's
latest.

Remember that manually compiled software will not

appear on these commands output. Only those installed
as packages will."

Resultado

Archivos Base

Solo root tiene UID de 0 en etc/passwd.

Archivos de consultas al FTP:
Pero adicionalmente, se ha inspeccionado el archivo de
etc/groups para determinar los accesos a comandos
"su" del grupo root, y solamente el usuario root forma
parte de este grupo.
Por otro lado, se verific /var/log/messages grep su
FTP.rar
para revisar las cuentas que acceden a root, en lo que
se determin que no accedieron mediante su a root.
Para actualizaciones de paquetes:

Si bien no existen usuarios compartiendo cuentas,

existen cuentas nombradas de forma genrica que no
permiten la identificacin y autenticacin del usuario, de
forma adecuada. No bostante, estos archivos son
utilizados solamente por usuarios de PMI Desarrollo y
Tecnologa de PMB y otros pases, ya que requieren
acceder principalmente para temas relacionados a las
actualizaciones de FINMAS.

Por ejemplo para los paises solo existe una cuenta de

acceso creada, pero puede ser que la utilicen ms de
un usuario. No obstante la responsabilidad de estas
cuentas est a cargo de PMI.

No existen usuarios duplicados.

NIS or NIS+ no se utilizan.

Asimismo, se han identificado usuarios con ms de un

ientificador asignado en el FTP que son las cuentas
administradas por PMI y las cuentas utilizadas por GTI,
usuarios sin formularios de autorizacin. El detalle a
continuacin:

No todas las cuentas de usuario requieren de shell

access, estn limitadas a /sbin/nologin y /usr/bin/rssh
(secure shell).
Solamente la cuenta root tiene acceso a bin/bash.

Console, vc y tty estn listados.

Ninguna restriccin est listada en -:root:ALL EXCEPT
LOCAL; ni en -:whell: ALL EXCEPT LOCAL.

Root puede loguearse remotamente, ya que est

activado: #-:whell: ALL EXCEPT LOCAL

Los passwords de las cuentas en passwd se

encuentran encriptadas, se hace uso de shadow para
resguardarlo.

El servicio de NIS no se est ejecutando.

No existen contraseas sin password, el mecanismo de
autenticacin que se utiliza es MD5.

Las contraseas de acceso de las cuentas no se

consideran dbiles se ha podido determinar a travs de
un programa de crakeo john de ripper, a travs de
ataques de diccionario.

PASS_MIN_LEN es 5, pero debera acomodarse a lo

estndar de dominio o servidores que es 8.

Se tiene estos descargos de la gestin pasada:

Respuestas a Auditora de Sistemas ON PMB - Parte Servidor FTP.msg

Respuestas a Auditora de Sistemas ON PMB - Parte Servidor FTP.msg

PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_MIN_LEN 5
PASS_WARN_AGE 7
Son polticas estndar que deben ser cambiadas a por
ejemplo: 62, 2, 8, respectivamente para estar de
acuerdo a las polticas de dominio.
El ltimo es correcto.

*.info;mail.none;authpriv.none;cron.none
Ver correo adjunto anteriormente.
/var/log/messages
Los mensajes informativos de todas las aplicaciones se
loguean
No loguea mensajes del sistema de mail (ok ya que no
aplica)
No loguea programas de autorizacin privados
No loguea cron y at
La carpeta de logueos es messages.
NOTA: DEBERIAN LOGUEARSE LOS MENSAJES DE
AUTENTICACION AUTH
# The authpriv file has restricted access.
authpriv.*
/var/log/secure
# Log cron stuff
cron.*
/var/log/cron
# Everybody gets emergency messages
*.emerg
*
# Save news errors of level crit and higher in a special
file.
uucp,news.crit
/var/log/spooler
# Save boot messages also to boot.log
local7.*
/var/log/boot.log
*.* @10.2.0.30

No se registran los mensajes de intentos fallidos de

accesos y otros en /var/log/messages.
Solo se registran en el syslog los accesos exitosos
(comando LAST), tampoco se monitorean lo logs que
se registran, se espera adquirir una herramienta para
su anlisis y monitoreo a cargo del Encargado de
Seguridad Informtica.

Slo existen permisos de escritura para usuario root:

-rw-r--r-- 1 root root 4316 Apr 9 10:04 /etc/passwd
Slo existen permisos de lectura para usuario root en
shadow: -r-------- 1 root root 2960 Apr 9 12:49
/etc/shadow
Slo existen permisos de escritura para usuario root:
-rw-r--r-- 1 root root 1325 Apr 9 10:03 /etc/group
Si bien los usuarios comunes no tienen permisos de
lectura y escritura pueden navegar en la carpetas y
obtener informacin. Hay que restringir estos accesos.

Existen permisos de escritura y ejecucin slo para

usuario root y su grupo root, en los scripts de inicio del
sistema para directorios y sus links:
lrwxrwxrwx 1 root root 7 Apr 23 2011 /etc/rc -> rc.d/rc
lrwxrwxrwx 1 root root 10 Apr 23 2011 /etc/rc0.d ->
rc.d/rc0.d
lrwxrwxrwx 1 root root 10 Apr 23 2011 /etc/rc1.d ->
rc.d/rc1.d
lrwxrwxrwx 1 root root 10 Apr 23 2011 /etc/rc2.d ->
rc.d/rc2.d
lrwxrwxrwx 1 root root 10 Apr 23 2011 /etc/rc3.d ->
rc.d/rc3.d
lrwxrwxrwx 1 root root 10 Apr 23 2011 /etc/rc4.d ->
rc.d/rc4.d
lrwxrwxrwx 1 root root 10 Apr 23 2011 /etc/rc5.d ->
rc.d/rc5.d
lrwxrwxrwx 1 root root 10 Apr 23 2011 /etc/rc6.d ->
rc.d/rc6.d
lrwxrwxrwx 1 root root 13 Apr 23 2011 /etc/rc.local ->
rc.d/rc.local
No existe el archivo crontabs.

Ver correo adjunto anteriormente.

ls -l /etc/at.allow - No existe archivo

ls -l /etc/at.deny
-rw------- 1 root root 1 Jan 26 2010 /etc/at.deny
Los usuarios detallados en l no pueden ejecutar at (ni
atrm, ni atq)

ls -l /etc/cron.deny
-rw-r--r-- 1 root root 0 Dec 6 2010 /etc/cron.deny
Los usuarios detallados en l no pueden ejecutar
crontab.

Slo la cuenta de superusuario est permitida para

acceder a todos los directorios y archivos mediante
tareas de trabajos programados.

/, slo accede root

/usr, slo accede root

/etc, adems de root, el grupo disk tiene permisos de

escritura en el archivo dumpdates _: -rw-rw-r-- 1 root
disk
0 Mar 6 2011 dumpdates. En este archivo se
registra informacin de las copias de cada sistema de
archivos, su nivel, y la fecha de realizacin
/sbin, adems de root, el grupo ecryptfs de tiene
permisos de ejecutar el archivo de ayuda de montar el
disco: -rwsr-x--- 1 root ecryptfs 15136 Sep 3 2009
mount.ecryptfs_private
/usr/bin, adems de root, los grupos slocate, mail,
screen, nobody, tty tienen acceso a los comandos de
usuario en bin: locate, lockfile, procmail, screen, sshagent, wall, write.
/usr/lib, solo accede root a las bibliotecas de usuarios
/usr/libexec, slo root accede

/var/spool, adems de root tienen acceso el usuario

daemon y snmp, asimismo, los grupos lp y mail.
/dev, adems de root tienen acceso grupos disk, lp,
floppy, kmen, tty, uucp , y el uuario vcsa
/var/spool/cron, solo root accede
/etc/*.d, adems de root el grupo daemon
/var/log , adems de root el grupo utmp y sys con el
usuario lp
/usr/sbin, adems de root el grupo smmsp y apache

Existen accesos a archivos que del sistema mediante

las cuentas de ftppublico y ftpreportes. Se debe
restringir de alguna forma el uso de estas aplicaciones.
Asimismo a carpetas de PMI desarrollo donde se
guardan ejecutables. Ver pestaa (a).

Ningn permiso es otorgado para SUID o SGID. Solo

root tiene acceso a estos privilegios.

sudoers - 10-2-0-7.dat

No existe el archivo /etc/exports

/etc/hosts.equiv ha sido elliminado

no existen .rhosts files
no existen .netrc files

rwall solo permitido para root.

root
8245 0.0 0.2 61188 744 pts/0
0:00 grep wall

R+ 15:17

tftp solo permitido para root.

root
8247 0.0 0.2 61188 740 pts/0
0:00 grep tftp

R+ 15:17

No existe el archivo /etc/ftpusers cualquier cuenta de

/etc/passwd puede transferir a ftp, incluidas las cuentas
que pueden ser sensibles como root, bin o sys, uucp,
sync, guest accounts, cuentas con restricted shells y
otras que no deberan.

No existen archivos rhosts.

/etc/hosts.equiv no existe
No se permiten accesos remotos que no requieran de
mecanismos de autenticacacin. No se confa en hosts
remotos confiables.
no existen showmount -e, por lo tanto no existen NFS
exports activos. Ni existen informacin en
cat/etc/exports.

Los servicios habilitados en xinetd.d/* deberan

deshabilitarse. Averiguar para los que no son por
defecto: /rmcp, /etc/xinetd.d/*

Los servicios habilitados para

levantaser en el boot time son
propios: init.d, rc*.d, rc.sysinit,
rc.local
Para RPC existen los siguientes
servicios ejecutndose:
program vers proto port
100000 2 tcp 111
portmapper
100000 2 udp 111
portmapper
100024 1 udp 916 status
100024 1 tcp 919 status
Los cuales no deberan estar
ejecutndose.

La versin del kernell instalada es:

2.6.18-238.9.1.el5
Los paquetes de actualizacin instalados son los
ltimos correspondientes a la versin de Centos,
obtenida de la pgina oficial www.centos.org Release
5.5.
Ver archivo adjunto.