Auditing Security of a Linux System

The purpose of this post is to detail what type reviews will be performed on a linux computer to determine if it meets the security requirements of the PCI DSS standard. To do this, whenever possible, I will detail the commands to use in each case.

However, although the main purpose is to audit compliance with PCI DSS, the proposed revisions can be used as a starting point for any security audit of a linux computer you want to perform.

All the commands in this post have been tested on Ubuntu 12.04 computer, so it is possible that some of them need to be modified to work properly on other Linux distributions. We can use the lsb_release-a command for the exact version of the system we are reviewing, or obtain it from the /etc/os-release.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

The command

Iptables -L -v

will show the firewall rules used in the system. In case of a laptop, you should review compliance with PCI DSS 1.4 that required to install and mantain a personal firewall. In any case, you should review the rules defined in the fw because in certain circumstances can serve as a compensating control in the absence of compliance with other requirements of the standard.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

To verify some aspects

To verify some aspects of compliance with this requirement, we can use the following commands:

Dpkg -l

This command allow us to list all installed packages in order to detect unnecessary packets that should have been uninstalled.

route -n

This command allows us to list all the routes defined in the system.

Additionally, analysing the following files we could determine if it has changed the name resolution of the system:

/etc/resolv.conf

/etc/hosts

/etc/nsswitch.conf

Also, you must check the next file to detect if exist unnecessary or predefined user accounts that should have been deleted or disabled:

/etc/passwd

Likewise, you should check out the company's hardening guide and identify any additional evidence that should be adquired to ensure it is being properly applied.

It is also important to identify which is the primary function of this server, and use the review to identify any package or service that does not make sense for that primary function. For example, if the primary server role is to act as a web server, it makes sense that we locate apache packages installed, but would not have it we found packages of Oracle or Nessus. The existence of these packages could make us suspect that the server is being used for more than one primary function and therefore the requirement 2.2.1 is not in place.

We can use the following command to list all running processes and services listening on the UDP and TCP ports to verify that there are no processes or unnecessary services running and all that are running are adequately documented and justified:

ps -edf

Lsof -i UDP -n -P

Lsof -i TCP -n -P

We should aldo review this folder to detect scheduled tasks:

/var/spool/cron/crontabs

Additionally, we review this list of processes and services to identify insecure protocols (such FTP, Telnet, etc.) and check that they have been documented and implemented additional security measures for these protocols.

Finally, to complete the review of this requirement, we will review the following file to check the existing SSH configuration on the server:

cat /etc/ssh/sshd_config

In this file we can verify which port SSH is running, what versions are allowed (should only be permitted v2 because v1 is vulnerable) and what encryption protocol is being used to ensure that is a sufficiently robust protocol. Additionally, you should check that the value of AllowTcpForwarding is "no", unless is justify the need to use this server as jumping server to manage other systems.

Requirement 6: Develop and maintain secure systems and applications

To check this requirement, we have to validate that there are no unsafe versions of software on the system. With this purpose in mind, we can use the following commands:

Uname -a

This command allow us to know witch kernel version is used and verify that there are not know vulnerabilities for that version, or in other words, that the kernel is correctly patched.

In the other hand, with the next command we can list all the packages installed in the system and their versions, so we can also check if there are any package vulnerable in the system. Remember that to meet this requeriment you must to install security patches for all the software included in the PCI DSS scope:

Dpkg -l

Last, but not least, we shoud review the next file to verify that there are not developers or testing user accounts. This kind of accounts must be deleted before the system or the apps are deployed in production environment:

/etc/passwd

Requirement 7: Restrict access to cardholder data by business need to know

In order to verify compliance with the PCI DSS requirement 7, you can perform the following checks:

/etc/sudoers

/etc/pam.d/sudo

/etc/pam.d/su

In these files we can check which users have permission to increase their privileges to root and under what conditions they can. All cases should be properly documented and justified.

We should also review the perms of the next file and any backup that it could have to be sure it can not be open or edited for any user:

/etc/shadow

On the other side, we should check that the setuide files can not be edited by don't authorized users to increase their system privileges. We could use next command for this purpose:

find / -perm -4000 -ls 2> /dev/null

Next commands allow us to list all files that can be open or edited by any user and are not located on /proc folder:

find / -type f -perm -006 2>/dev/null | grep -v /proc

find / -type f -perm -002 2>/dev/null | grep -v /proc

We should analyze these files to check if exists a justification for the privileges that are defined in each case.

In addition, we should review the next file to verify what shell have assigned each account:

/etc/passwd

Also, we should review next file to check if are defined any restriction to the users login:

Así mismo, se deberá revisar el fichero

/etc/security/access.conf

This file allow to limit the kind of access that some accounts can have. In example, you can configure it to prohibit the remote access to the root account or the console access to some user or app accounts.

Finally, you should review the next file to verify that the line “none *” exists and is not commented, as well as there are no users with extra capabilities without a justified reason for it:

/etc/security/capability.conf

Requirement 8: Identify and authenticate access to system components

To check the major part of PCI DSS requirement 8 we should review the next file:

/etc/pam.d/common-password

In this file we can find what algoritm is used to hash the passwords stored in /etc/shadow and verify if it is used pam_cracklib.so to configure a password policy that meets requirement 8.2.1 of PCI DSS.

Requirement 10: Track and monitor all access to network resources and cardholder data

To analyze compliance with this requirement of PCI DSS must be reviewed two aspects; time configuration and syslog settings.

Reviewing next file we know the UTC time zone being used by the system:

/etc/timezone

This other command allow us to verify the NTP Servers configuration for the time synchronization of the system:

Ntpdate

On the other side, next command allow us to know if syslog process is running:

ps -edf | grep syslog

Reviewing the next file we can know if syslog is configured to receive events from other systems or devices and what permits will have the generated log files:

/etc/rsyslog.conf

Finally, reviewing this file (or its equivalent defined in first lines of the file /etc/rsyslog.conf) we can know what events are generated and where they are saved or sent. On this way, we can verify if all the security events included on the PCI DSS scope are stored centralized as the standard requires:

/etc/rsyslog.d/50-default.conf

Requirement 11: Regularly test security systems and processes

Check what type of file integrity monitoring solution is installed. Depending on the type of solution being used, we must do appropriate revisions to ensure that the requirement 11.5 of PCI DSS. ie, at least weekly, the solution should check the changes made to files considered critical as system executables, application executables, parameter files, etc.

I hope you enjoy and find useful this post. If you have found any error or you wish propose any improvement, please, don't hesitate to propose it in a comment.

Twitter: @omarbenjumea

http://about.me/omarbenjumea

Auditar la seguridad de un sistema Linux

El propósito de este post es detallar qué tipo de revisiones se deben realizar en un equipo linux para determinar si cumple con los requisitos de seguridad del estándar PCI DSS. Para ello, siempre que sea posible, vamos a detallar los comandos a utilizar para obtener la información necesaria en cada caso.

No obstante, aunque el propósito principal sea auditar el cumplimiento de PCI DSS, las revisiones propuestas pueden utilizarse como punto de partida para cualquier revisión de seguridad de un equipo linux que se quiera realizar.

Todos los comandos indicados en este post han sido probados en un equipo Ubuntu 12.04, por lo que es posible que algunos de ellos deban ser modificados para que funcionen correctamente en otras distribuciones de linux. Podemos utilizar el comando lsb_release -a para conocer la versión exacta del sistema que estamos revisando, o bien obtenerla del archivo /etc/os-release.

 

Requisito 1: Install and maintain a firewall configuration to protect cardholder data

El comando

Iptables -L -v

mostrará las reglas de firewall utilizadas en el equipo. En caso de tratarse de un equipo portátil, se debería revisar el cumplimiento del req 1.4 de PCI DSS que exige que se instale y se mantenga un firewall personal en este tipo de equipos. En todo caso, es aconsejable revisar las reglas de fw definidas en el equipo ya que en determinadas circunstancias pueden servir como control compensatorio ante la ausencia de cumplimiento de otros requerimientos del estándar.

 

Requisito 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Para verificar algunos aspectos del cumplimiento de este requisito, podremos utilizar los siguientes comandos:

Dpkg -l

Nos permitirá listar todos los paquetes instalados con objeto de detectar paquetes innecesarios que debieran haber sido desinstalados.

route -n

Nos permitirá listar todas las rutas definidas en el sistema. Adicionalmente, el análisis de los siguientes ficheros nos permitirá determinar si se ha modificado la resolución de nombres del sistema o si se ha personalizado el encaminamiento:

/etc/resolv.conf

/etc/hosts

/etc/nsswitch.conf

Adicionalmente, se debería revisar el archivo

/etc/passwd

para detectar la existencia de cuentas de usuario innecesarias o por defecto que deberían haber sido ser borradas o deshabilitadas.

Así mismo, se debería revisar la guía de hardening documentada por la organización para este tipo de sistemas e identificar cualquier comprobación adicional que deba ser realizada para garantizar que está siendo correctamente aplicada.

También es importante identificar cual es la función primaria de este servidor, y aprovechar la revisión para identificar cualquier paquete o servicio que no tenga sentido para dicha función primaria. Así, por ejemplo, si la función primaria del servidor es la de actuar como servidor web, tendrá sentido que localicemos paquetes de apache instalados, pero no lo tendría que encontráramos paquetes de Oracle o Nessus. La existencia de dichos paquetes nos podría hacer sospechar que el servidor se está utilizando para más de una función primaria y por lo tanto se está incumpliendo el requisito 2.2.1.

Podemos utilizar los siguientes comandos para listar todos los procesos en ejecución, así como los servicios escuchando en los puertos UDP y TCP con objeto de verificar que no hay procesos o servicios innecesarios ejecutándose y que todos los que se están ejecutando están adecuadamente documentados y justificados:

ps -edf

Lsof -i UDP -n -P

Lsof -i TCP -n -P

También se debería revisar el contenido de la carpeta

/var/spool/cron/crontabs

para detectar la existencia de tareas programadas.

Adicionalmente, deberemos revisar este listado de procesos y servicios para identificar protocolos inseguros (FTP, Telnet, etc..) y verificar que se hayan documentado e implementado medidas de seguridad adicionales para estos protocolos.

Finalmente, para terminar con la revisión de este requisito, revisaremos el siguiente fichero para revisar la configuración de SSH existente en el servidor:

cat /etc/ssh/sshd_config

En este archivo podemos verificar en qué puerto se ejecuta SSH, qué versiones se permiten (únicamente debería estar permitida la v2, ya que la v1 es vulnerable) y qué protocolo de cifrado se está utilizando para garantizar que se utiliza un protocolo suficientemente robusto. Adicionalmente, se debería revisar que el valor de AllowTcpForwarding sea “no”, al no ser que se justifique la necesidad de utilizar este servidor como salto para administrar otros equipos.

 

Requisito 6: Develop and maintain secure systems and applications

Para revisar este requisito, tenemos que validar que no existen versiones inseguras de software en el sistema. Con este propósito en mente, podemos utilizar los siguientes comandos:

Uname -a

Este comando nos permitirá conocer la versión del kernel y verificar que no existan vulnerabilidades conocidas para esta versión, es decir, que el kernel esté correctamente parchedo.

Por otro lado, con:

Dpkg -l

listaremos todos los paquetes instalados en el sistema y sus respectivas versiones, por lo que podremos realizar la misma operación buscando versiones para las que existan vulnerabilidades conocidas y que por lo tanto debieran estar parcheadas o actualizadas para cumplir este requisito de PCI DSS.

Finalmente, se deberá analizar el fichero

/etc/passwd

para verificar que no existen cuentas de usuario correspondientes a personal de desarrollo ni cuentas de pruebas o testing que no hayan sido borradas en la puesta en producción del sistema.

 

Requisito 7: Restrict access to cardholder data by business need to know

Con el propósito de verificar el cumplimiento del requisito 7 de PCI DSS, se pueden realizar las siguientes revisiones:

/etc/sudoers

/etc/pam.d/sudo

/etc/pam.d/su

En estos ficheros podremos revisar qué usuarios tienen permiso para aumentar sus privilegios a root y en qué condiciones pueden hacerlo. Se deberá comprobar que todos los casos estén debidamente documentados y justificados.

Se deberá revisar que ni el fichero

/etc/shadow

ni sus posibles backups puedan ser leídos por los usuarios.

Por otro lado, se deberá comprobar que los ficheros setuid no puedan ser editados por usuarios no autorizados para aumentar de esta manera sus privilegios en el sistema. Podemos utilizar el siguiente comando para dicha revisión:

find / -perm -4000 -ls 2> /dev/null

Los siguientes comandos nos permitirá listar los ficheros que pueden ser leídos por cualquier usuario y que no están ubicados en /proc:

find / -type f -perm -006 2>/dev/null | grep -v /proc

find / -type f -perm -002 2>/dev/null | grep -v /proc

Se deberán analizar los ficheros obtenidos para ver si existe una justificación para los permisos que tienen establecidos.

Por otro lado, se deberá revisar el fichero

/etc/passwd

para verificar qué shell tiene asignada cada usuario y qué usuarios no tiene asignada ninguna shell.

Así mismo, se deberá revisar el fichero

/etc/security/access.conf

para comprobar si existen restricciones en el login de usuarios. Este fichero permite configurar limitaciones al tipo de acceso que puedan tener determinadas cuentas, por ejemplo, impidiendo el acceso remoto a la cuenta root, o el acceso mediante consola a determinadas cuentas de usuario o aplicación.

Finalmente, se deberá revisar el fichero

/etc/security/capability.conf

para confirmar que existe la linea “none *” no comentada (sin #), y que no se han asignado capacidades extras a usuarios sin que exista un motivo justificado para ello.

 

Requisito 8: Identify and authenticate access to system components

Para verificar la mayoría de los aspectos incluidos en el requisito 8 de PCI DSS será necesario revisar el archivo

/etc/pam.d/common-password

En este archivo podremos revisar qué algoritmo se está usando para el hash con el que se guardan los passwords en /etc/shadow y verificar si se está usando pam_cracklib.so para configurar una política de contraseñas suficiente para dar cumplimiento al requisito 8.2.1 de PCI DSS:

 

Requisito 10: Track and monitor all access to network resources and cardholder data

Para analizar el cumplimiento de este requisito de PCI DSS debemos revisar dos aspectos; la configuración de tiempo y la configuración de syslog.

Revisando el siguiente archivo podremos conocer la zona de tiempo UTC que está siendo utilizada por el sistema:

/etc/timezone

Mediante el siguiente comando, podremos verificar la configuración de servidores NTP que está siendo utilizada para la sincronización horaria del sistema:

Ntpdate

Por otro lado, el siguiente comando nos permitirá saber si el proceso de syslog está habilitado:

ps -edf | grep syslog

Revisando el fichero

/etc/rsyslog.conf

se puede verificar si está habilitado el servicio syslog para recibir eventos de otros sistemas o dispositivos y qué permisos van a tener los ficheros de logs generados.

Finalmente, mediante la revisión del fichero

/etc/rsyslog.d/50-default.conf (o su equivalente indicado al principio del fichero /etc/rsyslog.conf)

podremos identificar qué eventos se están generando y en qué rutas se están guardando estos ficheros de logs (o a qué servidores se están enviando). De esta manera, podremos verificar si se está cumpliendo el requisito de centralizar todos los eventos de seguridad generados por los sistemas incluidos en el alcance de PCI DSS.

 

Requisito 11: Regularly test security systems and processes

Revisar qué tipo de software de monitorización de integridad de ficheros tiene instalado el sistema. En función del tipo de mecanismo que se esté utilizando, se deberán realizar las revisiones pertinentes para garantizar que se cumple el requisito 11.5 de PCI DSS, es decir, que al menos semanalmente se comprueban la modificaciones realizadas en ficheros considerados críticos como ejecutables del sistema, ejecutables de aplicaciones, ficheros de parámetros y configuraciones, histórico de logs u otros archivos que no deban cambiar frecuentemente y se consideren críticos para la seguridad del sistema o de los datos.

Espero que la entrada os guste y os sea de utilidad y, por supuesto, si alguien detecta algún error o tiene alguna sugerencia de mejora de cara a realizar este tipo de auditorías, se agradecerá cualquier aportación al respecto.

¿Aún no me sigues en twitter?: @omarbenjumea
http://about.me/omarbenjumea