Serie de Coders Conquer Security sobre infraestructura como código: protección insuficiente de la capa de transporte

Si eres un desarrollador que busca aprender más sobre los pasos que puedes seguir para comenzar a implementar infraestructura como código (IaC) segura en tu organización, has llegado al lugar indicado. Este es el siguiente capítulo de nuestra serie sobre IaC, diseñado para elevar tu nivel en las mejores prácticas de seguridad de IaC.

Antes de comenzar, ¿cómo te fue con el desafío de la entrega anterior? Si ya dominas la criptografía insegura, veamos cómo te va con la protección insuficiente de la capa de transporte antes de profundizar en los detalles:

¿Quieres aprender más y obtener una puntuación perfecta? Sigue leyendo:

En nuestro último artículo, hablamos sobre la importancia de contar con una criptografía segura para proteger cualquier dato importante o personal almacenado por aplicaciones y programas. Si tienes un cifrado sólido, este actúa como una última línea de defensa perfecta. Incluso si un atacante logra robar esos datos, si están fuertemente cifrados, la información bloqueada dentro de esos archivos seguirá estando protegida.

Sin embargo, proteger los datos en reposo es solo una parte de una defensa de datos completa. Siempre que los usuarios válidos necesiten acceder a datos protegidos, estos deben enviárseles. A veces, las aplicaciones también comparten datos con otros programas como parte de una carga de trabajo general. Si la capa de transporte no está protegida, queda vulnerable tanto al espionaje externo como a la visualización interna no autorizada. Por lo tanto, tener una protección insuficiente en la capa de transporte puede causar problemas graves.

Es un problema común. La organización de seguridad OWASP incluso mantiene una página completa sobre protección insuficiente de la capa de transporte.

¿Por qué es peligrosa la protección insuficiente de la capa de transporte?

Si no proteges suficientemente tus capas de transporte, es relativamente fácil para los hackers expertos interceptar la información que fluye entre tus usuarios y tus aplicaciones mediante técnicas como los ataques de intermediario (man-in-the-middle). Probablemente el aspecto más peligroso de este tipo de espionaje es que es casi completamente invisible para cualquier plataforma o escaneo de ciberseguridad interno, ya que ocurre fuera de tu red y de tu control.

Por ejemplo, en un entorno Docker que implementa un servicio Nginx:

services:
 nginx:
   image: localhost:5000/scw_nginx
   build: ./nginx
   secrets:
     - nginx_cert
     - nginx_key
   volumes:
     - type: bind
       source: ./nginx/nginx.conf
       target: /etc/nginx/nginx.conf
       read_only: yes
   ports:
     - 80:8443
   networks:
     - frontend
   deploy:
     restart_policy: *default-restart_policy
     resources: *default-resources_policy

La configuración del servicio Nginx no cifrará ni protegerá la conexión, lo que hace que toda la información intercambiada a través del enlace sea vulnerable a una variedad de ataques o espionaje.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

A menudo, la primera señal de que alguien podría estar espiando a través de tus capas de transporte es cuando se utiliza una gran cantidad de contraseñas de usuario robadas en ataques posteriores. Si otros datos, como información de clientes, registros financieros o secretos importantes de la empresa, son robados a través de una capa de transporte insegura, es posible que nunca te des cuenta de que has sido comprometido.

Y no es solo la capa de transporte entre los usuarios y las aplicaciones lo que requiere protección. En el backend, muchas aplicaciones se comunican entre sí y con servidores más alejados en la cadena de flujo de trabajo. Si bien estas comunicaciones internas generalmente no son vulnerables al espionaje externo, pueden exponer datos a usuarios que pueden tener acceso a la red, pero que no están autorizados a ver cierta información altamente protegida o sensible.

Asegurar correctamente las capas de transporte para una protección total de los datos

La mejor forma de proteger las capas de transporte es durante la creación de las aplicaciones. Este proceso comienza con una infraestructura de backend segura. Para los sitios web, todo debe hacerse mediante HTTPS. Nunca mezcles infraestructura HTTP y HTTPS. Incluso deberías configurar tus sitios para que redirijan automáticamente las solicitudes HTTP no seguras a la infraestructura HTTPS.

En el ejemplo anterior, un método adecuado para proteger la capa de transporte sería:

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

En ese ejemplo, todas las conexiones con el servicio Nginx están fuertemente cifradas. La sección del servidor en la configuración de Nginx solo incluye listen 8443 ssl para forzar el uso de SSL y proteger las conexiones.

Para proteger sus datos de amenazas internas, los desarrolladores deben emplear un protocolo de cifrado de capa de transporte robusto, como TLS 1.2. Una vez que haya implementado TLS 1.2 o su equivalente, los protocolos más débiles, como SSL v2, deben eliminarse por completo de su infraestructura y bloquearse permanentemente para evitar su uso.

Recuerde siempre que la seguridad de una aplicación no está completa hasta que tanto los datos en reposo como las capas de transporte estén suficientemente protegidos. De este modo, podrá garantizar una protección integral de extremo a extremo para los datos, tanto a nivel interno como cuando se transmiten a usuarios externos autorizados.
Consulte las páginas del blog de Secure Code Warrior para obtener más información sobre esta vulnerabilidad y cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede solicitar una demostración de la plataforma de formación de Secure Code Warrior para mantener sus habilidades de ciberseguridad perfeccionadas y actualizadas.