The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

PCI-DSS y virtualización

INTRODUCCIÓN

No es ningún secreto que, principalmente por ahorro de costes, más y más servicios se están virtualizando.

Tipicamente, donde antes había montones de servidores dedicados ahora tenemos un único servidor que tiene configuradas varias máquinas virtuales; una con el servidor web, otra con la base de datos SQL …

Por otro lado, normativas como la de PCI-DSS, que es de obligado cumplimiento para todas aquellas entidades que manejen datos de tarjetas de crédito (bancos, etc),  cada vez son más exigentes y amplían el número de elementos auditados. Donde antes se decía que los servidores por los que circulen datos de tarjetas deben tener antivirus instalados, ahora se extiende a todos los servidores que formen parte de la misma intranet.

Así pues, en este caos de redes, servidores, servicios, datos confidenciales, cifrados, etc … ¿dónde queda el papel de la virtualización con respecto al cumplimiento de PCI-DSS?

PUNTOS CONFLICTIVOS

Sin ánimo de ir al detalle, veamos unos cuantos puntos que, como poco, habría que mirar como “difíciles de cumplir” o “poco realistas”.

1. Actualizaciones de Software

Practicamente cualquier normativa concerniente a la seguridad, obliga a instalar y documentar todos los parches de seguridad críticos. Vamos a creernos que esto se hace dentro de las máquinas virtuales … Pero, ¿qué pasa con el servidor de VMware – quien dice VMware dice cualquier otro – que corre por debajo? ¿Es que alguien lo parchea?

Es muy complicado que un servidor de VMware sea parcheado si en el corren unos cuantos servidores críticos. Por lo tanto, la respuesta a nuestra pregunta es casi seguro NO.

2. Separación de entornos y servicios

La segmentación de la red, la separación de entornos (desarrollo, test, producción) y, en particular, no tener varios servicios corriendo en el mismo servidor – por ejemplo, la base de datos y el servidor web deberían estar en servidores separados – son críticos para un entorno bien securizado.

Ahora bien, en pos del ahorro de costes, muchas veces se meten dentro del mismo servidor de vmware máquinas virtuales de entornos distintos o bien, como poníamos de ejemplo antes, una máquina virtual con la base de datos y otra con la aplicación web … Esto, que puede a priori parecer inocuo, plantea un serio problema, ya que, en realidad, todas las máquinas virtuales reciben el tráfico de red al completo, lo cual compromete la seguridad del servidor VMware “entero”.

Unido a esto, está el hecho de que ya han sido presentados trabajos que muestran como escapar de la máquina virtual al host (del host a la máquina virtual es bastante fácil; puedes hacer lo que te venga en gana).

Así pues, aunque estrictamente dos máquinas virtuales corriendo respectivamente el servidor de base de datos y el servidor web en el mismo host no incumplan directamente PCI-DSS, desde luego afecta a la seguridad.

3. Consolas de administración.

Muchas veces durante las auditorías se pone énfasis en localizar consolas de administración abiertas a toda la intranet, en intentar forzarlas por fuerza bruta … Normalmente, esto se refiere a aplicaciones web, pero no debemos olvidar que todos los servidores de virtualización tienen su respectiva consola de administración, aunque esta escuche en un puerto raro (https://servidor-vmware:8333/). Estas consolas también pueden tener passwords por defecto y también pueden ser atacadas por fuerza bruta.

4. Logs centralizados.

Otro requisito fundamental de PCI-DSS es que los logs se manden cifrados a un servidor donde se almacenen de forma segura y puedan/sean examinados periodicamente. Y sí, esto siempre se cumple dentro de las máquinas virtuales pero … ¿qué pasa con los logs del propio VMware?

Un usuario que acceda al host tiene control absoluto de todas las máquinas virtuales. Puede copiarlas y llevárselas a su casa, donde podrá hacer lo que le venga en gana. ¿Son estos logs enviados a un servidor centralizado? Mejor no preguntar …

5. Antivirus, IDS, …

Siguiendo en nuestra línea, deberíamos plantearnos cómo queda la seguridad del host. Estamos seguros de que se ha hecho el correspondiente hardening de la máquina virtual que contiene la aplicación web …

Pero no nos engañemos, instalar un antivirus en el host puede llegar a ralentizar bastante el servidor, aparte de posibles problemas potenciales de este tipo de software. De nuevo es difícil que se cumpla este punto (y sí, los *nix también tienen que tener antivirus instalado; no sirve eso como excusa)

Un sin fin de preguntas sin responder

Podemos pensar que estaremos bien tranquilos si las máquinas virtuales están bien securizadas, pero a día de hoy cada vez tenemos menos ataques desde el exterior con un sql-injection y cada vez tenemos más desde el interior con una mezcla de ingeniería social y hacking, particularmente en entornos altamente securizados.

Así pues, no estaría de más preocuparnos de la seguridad de nuestros servidores de VMware, por los que, no lo olvidemos, pasa todo el tráfico de red que envían/reciben sus máquinas virtuales y en los que, además, desde el host podría instalarse un troyano que haga inútil cualquier intento de detección del ataque.

¿Tiene el host un IDS? ¿Tiene sofware antivirus? ¿Tiene puestos los últimos parches de seguridad? ¿Se cambian sus passwords cada mes? ¿Qué usuarios y con qué permisos pueden entrar? ¿Dónde están los backups de las máquinas virtuales? ¿Y la lista de actualizaciones que han metido en el host? ¿Entran como root a la consola de administración del vmware? …

Muchas veces, mirando allí donde nadie mira, podremos encontrar la respuesta a cómo reventar un sistema.

Comments are closed.