Cuando se procede con la implementación de controles de PCI DSS en un entorno informático suele ser muy común encontrar servicios de red que, por alguna razon (obsolescencia, limitaciones técnicas del fabricante, limitaciones de hardware, problemas de compatibilidad, etc.), no ofrecen los niveles de seguridad exigidos por el estándar pero que son necesarios en términos operativos. En este tipo de situaciones se requiere buscar alternativas de implementación que permitan la gestión segura de dichos servicios sin afectar la operación (controles compensatorios).

Todos los artículos de la serie "Casos de estudio de PCI DSS":

En este nuevo caso de estudio se analizará el proceso de aseguramiento de protocolos y servicios inseguros (SMTP, POP3, IMAP, HTTP, MYSQL, VNC, CIFS, etc.) empleando tunelización y redirección de tráfico vía TLS, lo cual permitirá el cumplimiento de siguientes requerimientos de PCI DSS:

  • 1.1.6 Documentación y justificación de negocio para el uso de todos los servicios, protocolos y puertos permitidos, incluida la documentación de las funciones de seguridad implementadas en aquellos protocolos que se consideran inseguros.
  • 2.2.3 Implementar funciones de seguridad adicionales para los servicios, protocolos o daemons requeridos que no se consideren seguros.
  • 2.3 Cifre todo el acceso administrativo que no sea de consola utilizando un cifrado sólido.
  • 4.1 Utilizar criptografía sólida y protocolos de seguridad para proteger los datos del titular de la tarjeta confidenciales durante la transmisión por redes públicas abiertas.

Tunelización y redirección de tráfico empleando stunnel

El concepto de tunelización (o encapsulación) permite la inserción de un paquete de datos de un protocolo específico dentro de la carga útil («payload») de otro. Esta técnica es ampliamente utilizada para la creación de túneles de VPN (IPSEC, PPTP, L2TP), enrutamiento (GRE, PPP, P2P) e incluso para evitar controles de filtrado de paquetes en firewalls.

En este caso, se empleará como ejemplo la herramienta stunnel, que permite la encapsulación de protocolos arbitrarios dentro del protocolo TLS.

NOTA: En este ejemplo se usará stunnel debido a su facilidad de configuración e integración, pero también se pueden emplear otras herramientas alternativas que ofrecen la misma funcionalidad, como tlstunnel, hitch TLS proxy, HAProxy o incluso SSH.

Supongamos que tenemos un servicio HTTP que permite una conexión administrativa a un servicio dentro del entorno PCI DSS. No obstante, el proveedor de este software no ofrece una versión segura para la conexión (como HTTPS) por lo que se estaría incumpliento el requerimiento 2.3 de PCI DSS. Esto es muy común en consolas OOB o en servicios de administración simple.

En este caso, se empleará stunnel para crear un túnel que encapsule el trafico HTTP nativo de la aplicación insegura dentro del protocolo TLS, garantizando que todo el tráfico estará encriptado punto a punto entre el cliente y el servidor. Todas las conexiones remotas serán gestionadas por stunnel a través del puerto 443, que redireccionará el tráfico a la aplicación local al puerto 80. La aplicación insegura seguirá activa sin ninguna modificación operativa, pero solamente recibirá conexiones desde localhost provenientes del daemon de stunnel.

En primer lugar, se requiere la generación de un certificado digital que será usado en la conexión. En este ejemplo se usará un certificado autofirmado, pero también se puede optar por emplear certificados generados por una CA confiable (como es el caso de Let’s Encrypt) si el servicio estará expuesto a redes públicas abiertas para cumplir con el requerimiento 4.1.

Posteriormente, se procede con la instalación de stunnel (disponible para Android, GNU/Linux y Windows, incluyendo una GUI). En este caso particular se empleará una instalación en GNU/Linux (Debian):

Luego, editar el fichero /etc/default/stunnel y cambiar la variable “ENABLED” a 1.

Para poder gestionar el servicio empleando systemctl, es necesario crear un archivo de parámetros llamado “stunnel.service” en /lib/systemd/system:

Y luego lo habilitamos para funcionar vía systemctl:

Luego, editamos el archivo /etc/stunnel/stunnel.conf con los siguientes parámetros:

Con esto, se ha implementado un túnel TLS 1.2 que soporta un conjunto de cifrado con algoritmos robustos, escuchando en el puerto 443 y redireccionando el tráfico al puerto 80 de localhost en donde se encuentra instalada la aplicación insegura.

Finalmente, bloqueamos a nivel de red el tráfico entrante al puerto 80 (HTTP) para evitar conexiones inseguras:

Varios temas adicionales:

  • stunnel soporta TLS v1.3 (sslVersion = TLSv1.3). Si se activa esta opción, se requiere definir el conjunto de cifrado con el parámetro «ciphersuites = CIPHERSUITES_LIST».
  • Si se descarga el código fuente de stunnel y se compila, es muy importante que se tenga la última versión de OpenSSL. En este caso, cualquier versión de SSL estará desactivada por defecto.
  • La página del manual de stunnel enumera todos los parámetros que son configurables. El ejemplo anterior es bastante sencillo, pero stunnel se puede configurar para soportar autenticación, balanceo de carga, proxy transparente, envío de sus logs a un syslog remoto, etc.
  • La misma técnica se puede emplear para encriptar tráfico de transacciones de MySQL, VNC, etc.