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