Blog de Omar Benjumea

lunes, 19 de mayo de 2014

Auditar la seguridad de un sistema Linux

El propsito 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 estndar PCI DSS. Para ello,
siempre que sea posible, vamos a detallar los comandos a utilizar para obtener la informacin
necesaria en cada caso.
No obstante, aunque el propsito principal sea auditar el cumplimiento de PCI DSS, las revisiones
propuestas pueden utilizarse como punto de partida para cualquier revisin 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 versin
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 porttil, se
debera 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 estndar.

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 anlisis de los
siguientes ficheros nos permitir determinar si se ha modificado la resolucin de nombres del
sistema o si se ha personalizado el encaminamiento:
/etc/resolv.conf
/etc/hosts
/etc/nsswitch.conf

Adicionalmente, se debera revisar el archivo

/etc/passwd
para detectar la existencia de cuentas de usuario innecesarias o por defecto que deberan haber
sido ser borradas o deshabilitadas.
As mismo, se debera revisar la gua de hardening documentada por la organizacin para este tipo
de sistemas e identificar cualquier comprobacin adicional que deba ser realizada para garantizar
que est siendo correctamente aplicada.
Tambin es importante identificar cual es la funcin primaria de este servidor, y aprovechar la
revisin para identificar cualquier paquete o servicio que no tenga sentido para dicha funcin
primaria. As, por ejemplo, si la funcin primaria del servidor es la de actuar como servidor web,
tendr sentido que localicemos paquetes de apache instalados, pero no lo tendra que
encontrramos paquetes de Oracle o Nessus. La existencia de dichos paquetes nos podra hacer
sospechar que el servidor se est utilizando para ms de una funcin primaria y por lo tanto se est
incumpliendo el requisito 2.2.1.
Podemos utilizar los siguientes comandos para listar todos los procesos en ejecucin, as como los
servicios escuchando en los puertos UDP y TCP con objeto de verificar que no hay procesos o
servicios innecesarios ejecutndose y que todos los que se estn ejecutando estn
adecuadamente documentados y justificados:
ps -edf
Lsof -i UDP -n -P
Lsof -i TCP -n -P
Tambin se debera 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 revisin de este requisito, revisaremos el siguiente fichero para
revisar la configuracin 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 debera 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 debera 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 propsito en mente, podemos utilizar los siguientes comandos:

Uname -a
Este comando nos permitir conocer la versin del kernel y verificar que no existan
vulnerabilidades conocidas para esta versin, 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 operacin 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 produccin del sistema.

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

know
Con el propsito 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 estn
debidamente documentados y justificados.
Se deber revisar que ni el fichero
/etc/shadow
ni sus posibles backups puedan ser ledos 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 revisin:
find / -perm -4000 -ls 2> /dev/null
Los siguientes comandos nos permitir listar los ficheros que pueden ser ledos por cualquier
usuario y que no estn 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 debern analizar los ficheros obtenidos para ver si existe una justificacin 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
aplicacin.
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 mayora 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 poltica de contraseas 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
configuracin de tiempo y la configuracin 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 configuracin de servidores NTP que est
siendo utilizada para la sincronizacin 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 revisin del fichero
/etc/rsyslog.d/50-default.conf (o su equivalente indicado al principio del fichero /etc/rsyslog.conf)
podremos identificar qu eventos se estn generando y en qu rutas se estn guardando estos
ficheros de logs (o a qu servidores se estn 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 monitorizacin de integridad de ficheros tiene instalado el sistema.
En funcin del tipo de mecanismo que se est utilizando, se debern 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 crticos como
ejecutables del sistema, ejecutables de aplicaciones, ficheros de parmetros y configuraciones,
histrico de logs u otros archivos que no deban cambiar frecuentemente y se consideren crticos
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 algn error o
tiene alguna sugerencia de mejora de cara a realizar este tipo de auditoras, se agradecer
cualquier aportacin al respecto.
An no me sigues en twitter?: @omarbenjumea
http://about.me/omarbenjumea
Publicado por Omar Benjumea en 16:31
Etiquetas: auditora, Compliance, linux, PCI DSS, Security, Seguridad, Tarjetas de crdito, ubuntu

3 comentarios:

soymicmic dijo...
Un articulo muy interesante.
Para el Requisito 3 tal vez se podra incluir algn script de bsquedas de nmeros de tarjeta con
expresiones regulares o algo similar
21 de mayo de 2014, 10:14

Omar Benjumea dijo...

Muchas gracias por la aportacin soymicmic.

Tienes razn, se puede realizar una bsqueda mediante expresiones regulares para encontrar
PANes. De cara a evitar falsos positivos, es muy recomendable comprobar que los nmeros
hallados cumplen el algoritmo de Luhn, es decir, se trata de nmeros de tarjeta vlidos.
22 de mayo de 2014, 0:46

soymicmic dijo...
Correcto. He encontrado alguna implementacin para consola:
http://rosettacode.org/wiki/Luhn_test_of_credit_card_numbers#Bash
A su vez, habra que combinarlo con el BIN para determinar longitudes.
22 de mayo de 2014, 14:56
Publicar un comentario en la entrada
Entrada ms reciente Entrada antigua Pgina principal
Suscribirse a: Enviar comentarios (Atom)

Etiquetas
Seguridad (25) PCI DSS (18) Compliance (9) Security (9) Tarjetas de crdito (7)
ISO27000 (6) Information Security (6) Anlisis de Riesgos (5) Infraestructuras
Crticas (5) ISO27001 (4) Consultora (3) Risk Analysis (3) SGSI (3) SIEM (3)
CISO (2) Concienciacin (2) ENS (2) Ingeniera Social (2) Kudelski Security (2)
Risk Assessment (2) Risk evaluation (2) SCADA (2) SPAM (2) Scrum (2)
Switzerland (2) Vulnerabilidad (2) linux (2) seguridad de la informacin (2) ubuntu
(2) vulnerabilidades (2) Agile (1) Caixa d'Enginyers (1) DevOPS (1) DevOPSSEC
(1) ISMS (1) Impact (1) Industrial Systems (1) Linkedin (1) Pass the hash (1)
Quickwins (1) Segundo Factor (1) Sistemas Industriales (1) Spain (1) Timo
nigeriano (1) Windows (1) agility (1) amenazas (1) audit (1) auditora (1) bastionar
(1) critical infrastructures (1) fraud (1) hardening (1) relocating (1) scam (1)

Archivo del Entradas populares

blog

Auditar la seguridad de un sistema Linux

octubre 2016 (2)

abril 2016 (2)

septiembre
2015 (1)

agosto 2015 (1)

marzo 2015 (1)

enero 2015 (3)

diciembre 2014

El propsito de este post es detallar qu tipo de revisiones se deben

realizar en un equipo linux para determinar si cumple con los r...

Requisitos documentales de PCI DSS

Es muy frecuente que, cuando una organizacin se enfrenta al reto d

implantar el cumplimiento con el estndar PCI DSS, se centre en los

Quiero ser Consultor de Seguridad

He pasado la mayor parte de mi carrera profesional dedicndome a la

consultora de seguridad de la informacin. La verdad es que llegu a


(1)

noviembre 2014
(3)

septiembre
2014 (1)

agosto 2014 (1)

julio 2014 (1)

mayo 2014 (2)

Actores en PCI DSS

El objetivo de esta entrada del blog es dar una (somera) visin sobre
diferentes actores y estndares que representan algn papel en l...

PCI DSS 11.3: Pentest Methodology

As commented in the previous post , one of the new requirements of t

PCI DSS v3 is to have a procedure that describes the metho...

Metodologa de Test de Intrusin (Requisito 11.3 de PCI DSS)

T al y como comentaba en la anterior entrada , uno de los nuevos

requisitos de la PCI DSS v3 consiste en disponer de un procedimiento

Implementando el Requerimiento 1 de PCI DSS (I)

marzo 2014 (1)

febrero 2014 (1)

diciembre 2013
(1)

noviembre 2013
(6)

agosto 2013 (1)

junio 2013 (2)

abril 2013 (2)

Proceso de gestin de vulnerabilidades

marzo 2013 (2)

La gestin de vulnerabilidades debe ser un punto prioritario en el prog

de seguridad de cualquier organizacin. Aunque tener todos los s...

febrero 2013 (8)

El primer requerimiento del estndar (Instalar y mantener una configu

de firewall para proteger los datos de tarjeta) se cent...

Plan de Respuesta ante Incidentes de Seguridad & PCI DSS

No hay organizacin que est a salvo de sufrir un incidente de seguri

Se puede tardar ms o menos en padecerlo y en resolverlo, ser ms.

Ejemplo de Anlisis de Riesgos

mayo 2010 (3)

Introduccin Este post tiene como objetivo el explicar en detalle una
metodologa propia de anlisis de riesgos. En el pasa...

Suscribirse a ....
Atom
Entradas
Atom
Comentarios

Plantilla Simple. Con la tecnologa de Blogger.

This site uses cookies from Google to deliver its services, to personalize ads and
to analyze traffic. Information about your use of this site is shared with Google. By
using this site, you agree to its use of cookies.Learn MoreGot it