PUERTO BAGDAD (2): SEGURIDAD EN CONTENEDORES, UNA VISTA DESDE EL PUERTO (LA PLATAFORMA) Y SU CONFIGURACIÓN, UNA GUÍA CASI PRÁCTICA

Tanto en la realidad como en la metáfora tecnológica el movimiento de carga en contenedores de los puertos depende muchos de las plataformas y la forma en cómo operan, su configuración… en esta nueva entrega de Puerto Bagdad abordamos precisamente las cualidades que la plataforma de contenedores independientemente de su arquitectura de despliegue o su tecnología debe presentar, y por esa misma vía los principales problemas de configuración del entorno de contenedores así como ciertas acciones y refuerzos que pueden utilizarse para procurar un entorno de contenedores seguro.

Empecemos, por los atributos que la plataforma de contenedores independientemente debe presentar de forma agnóstica esto es independientemente de su clase (dockers, kubernets…) arquitectura de despliegue o tecnología, si bien podría parecer una perogrullada la siguiente lista puede ahorrar muchos dolores de cabeza cuando los administradores de la plataforma se encuentran con limitaciones. La lista es general y deberá alinearse a los objetivos del negocio e incluso al gusto por los sabores de contenedores, la coexistencia de plataformas es posible: 

• Configurabilidad: debe ser configurable desde su implementación y hasta operación, debe ser capaz de soportar configuraciones que se adapten a los entornos de desarrollo, despliegue y seguridad.
• Políticas: tanto el despliegue como la gestión deben realizarse mediante políticas bien definidas y alienadas al gobierno de seguridad interno.
• Procesos: integración con prácticas de Desarrollo–Operaciones–Seguridad que garanticen la entrega rápida y segura de software. 
• Seguridad: la plataforma debe garantizar la seguridad del entorno (infraestructura y servicios) lo cual va desde la detección de vulnerabilidades antes del despliegue de aplicaciones hasta el monitoreo permanente de la infraestructura para detectar posibles desviaciones al cumplimiento o las políticas.
• Fiabilidad: el modelo de prestación de servicios debe basarse en acuerdos de nivel de servicio que garantice el máximo tiempo de disponibilidad de la infraestructura y de la misma plataforma, por ende de las cargas de trabajo de las aplicaciones desplegadas.
• Observabilidad: debe proporcionar información sobre la infraestructura, sus recursos y las (cargas de trabajo de las) aplicaciones mediante la captura e interpretación de métricas, eventos, registros (logs) y toda la telemetría que permita la comprensibilidad del entorno. 
• Multi-inquilinos (tenants): la plataforma de gestión de contenedores debería proveer aislamiento entre las instancias o los “inquilinos” que utilizan la plataforma.
• Consistencia: se requiere de una plataforma que ofrezca una experiencia consistente en la nube pública y en los entornos tanto para personal de desarrollo y operación.

Pero no todo se trata de tener plataformas poderosas, hay que saber configurarlas. El acceso y el control de infraestructura de nube comprometida, especialmente en lo que a contenedores se refiere, se ha convertido en uno de los intereses, retos y actividades más redituables y por ello más deseadas por los actores maliciosos alrededor del mundo, ya que logran no sólo robar información sino literalmente tener un trampolín para lanzar ataques cada vez más sofisticados.

Aún con las mejores prácticas e intenciones los profesionales de la nube y la seguridad se ven superados  constantemente por la complejidad de los entornos y la velocidad con las que el negocio despliega aplicaciones, servicios, información y contenido… aún con los enfoques DevOpsSec. Las guías de seguridad para alinear las instancias de nube y contenedores son usadas por los propios atacantes para su explotación, por ello vemos y seguiremos viendo cómo prácticamente todos los entornos “controlados” sufrirán violaciones en distintos niveles.

De manera general tenemos los siguientes casos de uso o desuso según se vea:

Caso #1: Configuración base incorrecta o la mala semilla

1. La configuración inicial del clúster, incluyendo el o los pods, y de todos los elementos del entorno equivale a implantar buenos cimientos, por ello es crucial diseñar y configurar una arquitectura multitenant, capaz de crecer horizontal y verticalmente con el mínimo esfuerzo, planificar tantas iteraciones como se requiera para garantizar la seguridad de la plataforma, el entorno (desplegado) y los componentes individuales, antes de llevarlo a producción.
2. Hacer una verificación exhaustiva de que la configuración de seguridad inicial de la plataforma, garantizando los principios mínimos de seguridad como los principios del mínimo privilegio y de mínima exposición de los recursos, así como todos aquellos que reduzcan la superficie de ataque, especialmente en los entornos de nube donde los roles pueden tener exceso de privilegios, las identidades siguen siendo la primera línea de defensa.
3. Si contrata servicios serverless (cada vez más comunes) debe participar activamente en las definiciones iniciales del diseño, configuración y en cualquier actividad que instaure esos buenos cimientos, no hay que depositar toda la confianza en los administradores, pregunte todo y verifique lo más posible.

 Recomendación 1: Con los principales actores del Desarrollo, Operación y Seguridad diseñe una línea arquitectónica base que sea: multitenant aun cuando sea una sola organización, la segmentación incluso de ambientes (desarrollo, prueba, producción e intermedios) es crucial. La capacidad de crecimiento debe ser horizontal y vertical, es decir de la cantidad y capacidad de los recursos, en la medida de lo posible. Y con una buena configuración inicial el esfuerzo por cambios en configuración tiende a minimizarse. Por último, preste atención al diseño y las medidas de seguridad de la plataforma en sí, del entorno integrado (considerando las cargas) y de los componentes individuales (incluyendo la infraestructura subyacente), siempre será buena idea hacerlo en ambientes de pruebas antes de llevarlo a producción, siempre que se garantice una promoción consistente .

Recomendación 2: Realice una verificación exhaustiva en producción de la configuración base, la línea base debe garantizando los principios mínimos de seguridad como los principios del mínimo privilegio y de mínima exposición de los recursos junto con todo aquellos que reduzcan la superficie de ataque. En nube la segregación de roles, perfiles y el resguardo de las cuentas “maestras” es clave para no tener pérdidas o problemas mayores.

Recomendación 3: No confíe ciegamente en su proveedor de servicios de nube, ni en el Modelo de responsabilidad compartida ni en la oferta serverless, participe en el diseño inicial tanto como pueda y realice una auditoría continua de los entornos administrados e instaure un proceso de monitoreo y detección de brechas desde las primeras iteraciones, incluso antes.

 Caso #2: Mala configuración o 'los trabajos y los días'

Incluso si tuvo un despliegue cero óptimo y seguro el movimiento normal de los ciclos de desarrollo y liberación pueden provocar malas configuraciones, no es lo ideal pero es una realidad, debe cuidar al menos los siguientes casos problemáticos.

1. Lo primero que hará un atacante que busca instancias de Docker mal configuradas es escanear los puertos abiertos (2375 al 2377, 4243 al 4244 típicamente) desde Internet para su explotación, que podría terminar en comprometer y explotar la plataforma.
2. Asimismo, las instancias vulnerables también se pueden ser ubicadas por Shodan y plataformas similares (IoT) con el mismo fin.
3. Finalmente los atacantes pueden usar herramientas legítimas de monitoreo de Kubernetes como WeaveScope, Octan t, Konstellate o KOV para crear una puerta trasera en estas instancias de contenedores y comprometer los recursos.
4. Se deposita una cantidad de confianza considerable en los proveedores de la nube para configurar, parchear y administrar la seguridad de los contenedores, ejemplos sobran en los servicios en la nube más confiables pueden ser susceptibles a configuraciones que, sin saberlo, provocan la escalada de privilegios y facilitan la toma de control del clúster o la plataforma.

 Recomendación 1: es esencial implementar protección de borde lo que esto signifique… es decir, desde grupos de seguridad en los VPCs o VNETs de las nubes públicas, hasta las instancias de firewalls con IDS/IPS virtuales o físicos (en nube o en los centros de datos) pasando por Gateways que  hagan el reenvío de información. Todo entorno de nube debe tener una protección de su borde (perímetro) por más borroso que este sea.

Recomendación 2: considere la incorporación de protección de las cargas a nivel host, es una manera rápida y fácil de suplir ciertas malas configuraciones y de atacar el problema de los puertos (de red) abiertos o expuestos, y otros problemas que ataca el “parcheo virtual”.

Recomendación 3: considere incluir herramientas de monitoreo para los contenedores (en ejecución), a nivel salud (utilización de CPU, RAM, actividad de red) que además tengan elementos de inteligencia de amenazas e incluso supervisión de umbrales de riesgo.

Recomendación 4: siga sin confiar ciegamente en su proveedor de servicios de nube tanto en un Modelo de responsabilidad compartida como en la oferta serverless, ejecute las herramientas de alienación, conformidad y de buenas prácticas que tienen las nubes públicas y algunos entornos de contenedores, le arrojarán incumplimientos de los entornos que deberán ser atendidos. O de cualquier forma, practique auditorías contante con base en algún marco de seguridad.

 Caso #3: Malware o el código (malicioso) que sí funciona

1. La mala configuración de Docker está siendo explotadas por malwares criptográficos como Cetus y Graboide.
2. Existen campañas orquestadas de gran alcance que explotan las herramientas de Integración continua/Despliegue continuo (CI/CD).
3. Las instancias vulnerables de Docker también son susceptibles de malware DDoS como XORDDoS y Kaiji , que utilizan esos recursos para aumentar su capacidad de ataque por denegación de servicios distribuida.

Recomendación 1: es esencial implementar protección de borde lo que esto signifique desde grupos de seguridad en los VPCs o VNETs de las nubes públicas, instancias de firewalls con IDS/IPS virtuales o físicos (en nube o en los centros de datos)

Recomendación 2: considere la incorporación de protección de las cargas a nivel host, es una manera rápida y fácil de suplir ciertas malas configuraciones y de atacar el problema de puertos.

Recomendación 3: considere incluir herramientas de monitoreo para los contenedores (en ejecución), a nivel salud (utilización de CPU, RAM, actividad de red) que además tengan elementos de inteligencia de amenazas e incluso supervisión de umbrales de riesgo.

 Caso #4: Imágenes "malignas" o el enemigo en casa

1. Los repositorios de imágenes públicas son una herramienta rentable y sencilla para distribuir imágenes maliciosas disfrazadas de configuraciones personalizadas, se cauto en lo que descarga aún más si piensa utilizar la imagen incluso en desarrollo o prueba si los ambientes no están completamente segmentados.
2. Pero incluso repositorios internos centrales o incluso de los desarrolladores pueden tener imágenes maliciosas que pueden expandirse al promoverla si no se tienen buenas prácticas. El control administrativo de los desarrolladores es crucial tanto como la libertad creativa dentro de un framework consistente.

Recomendación 1: Verifique sus fuentes de imágenes base, independientemente de si está creando las suyas propias o si usa imágenes de un repositorio público deben ser  sometidas a una verificación constante, mantener una imagen limpia mediante GithubR siempre será una buena práctica. Si es un usuario avanzado incorpore herramientas de análisis como Dive (o incluso nativas del propio Docker) para ayudarlo a verificar el historial de imágenes.

Recomendación 2: Incorpore herramientas de escaneo de imágenes o de protección de contenedores en general, el mercado posee algunas opciones funcionales y configurables que se adaptan a su ciclo de desarrollo, integración y liberación.

Recomendación 3: Equilibre la libertad creativa de los desarrolladores, ingenieros y arquitectos de software, programadores, testers, integradores, implementadores y operativos, y ene general de toda la gente que participa en el desarrollo y liberación con medidas estrictas para el control de imágenes, versiones, artefactos e incluso documentación. La gente de seguridad podrá ayudarlo en este sentido, equilibrando ambas fuerzas esenciales en cualquier organización.

Hasta aquí esta entrega de Puerto Bagdad, en la próxima entrega quizá volvamos a las tendencias de contenedores que irrumpirán hacia finales del año.

Enrique López T.