Webinar Codemotion 2020 - Piratas del Cloud

Francisco Javier Barrena Castillo - @DogDeveloper#DogSecCloud
Seguridad en contenedores
Francisco Javier Barrena Castillo @DogDeveloper

Who’s that guy
• Security Advocate & Software Architect en @ITI_TIC
• Actualmente en proyectos de investigación de ciberseguridad en
entornos cloud y detección basada en Machine Learning
• +10 años con proyectos comerciales
• Cybersecurity, Big Data, Machine Learning, Cloud Computing…
• ConsejeroTécnico en www.onlyeco.com
• Buscador de viajes eco-sostenibles
• Formador y ponente
• +60 cursos y charlas
https://www.linkedin.com/in/fjbarrena
https://twitter.com/DogDeveloper
https://github.com/fjbarrena
https://www.slideshare.net/fjbarrena

Depende del proveedor

Pero en general…

cloud?
data leaks?
cloud is ok?

You

• La tierra prometida del cloud nos ha hecho creer que:
• No tenemos que preocuparnos de las ‘cosas de sistemas’
• No tenemos que preocuparnos de las ‘cosas de redes’
• No tenemos que preocuparnos de las ‘cosas de seguridad’
• No es que sea falso lo que prometían
• Es que no era toda la verdad
• Es cierto que nos abstraemos de muchas cosas de las que antes no
podíamos librarnos
• Y es cierto que vale muchísimo la pena
• Pero hay aspectos que hemos desatendido porque ‘de eso se encargará otro’ …
Seguridad en el cloud

Hemos pasado de defender esto

A defender esto…

Poner star trek

• Pero eso no es lo peor
• Lo peor es que quien nos defendía antes ya no lo hace
• Lo peor es que las herramientas que nos ayudaban a defendernos
antes ya no valen, o su efectividad baja demasiado
• Esas herramientas hacían asunciones técnicas que ya no sirven
• Por ejemplo, consideremos un control de seguridad que tenga en cuenta
las direcciones IP
• Esto funciona bien paraVM o para Baremetal, donde las IP’s se mantienen durante meses o años
• Pero no para contenedores, donde las IP’s cambian constantemente
• Esto hace imposible proteger contenedores utilizando técnicas de seguridad que confían en IP’s
estáticas, como por ejemplo los conjuntos de reglas de un Firewall clásico

• El cloud, y los contenedores, necesita herramientas de monitorización y
seguridad específicas
• Los sistemas en seguridad clásica…
Network Sistemas de seguridad

• En entornos de contenedores hay muchas más
entidades, por lo que los procesos y herramientas de
seguridad en contenedores deben ser capaces de
escalar en consecuencia
• Y no solo respecto al número total de objetos que pueden
soportar
• También en cómo de efectivos y autónomos puedan ser
• Muchas empresas lo pasan mal para gestionar unos
pocos cientos deVMs
• En una arquitectura basada en contenedores vamos a tener
que gestionar miles o decenas de miles de contenedores

• Con contenedores hay un ratio de cambio mucho más elevado que
conVMs
• Mascotas vs Ganado
• Lo que conVMs era aceptable hacerlo manualmente, ya no lo es
• La automatización es la clave
• No solo por la importancia de manejar un número mayor de entidades
• Si no también por la frecuencia con la cual esas entidades cambian

• La seguridad debe ser portable, como los mismos contenedores
• Las organizaciones deben adoptar técnicas y herramientas que sean
abiertas y que funcionen entre plataformas (cross-platform) y entre
entornos (cross-environments)
• Los desarrolladores buildean la solución en un entorno (Docker local,
clúster local de Kubernetes…)
• La prueban en otro entorno (GitLabCI, Jenkins,TeamCity…)
• Y la despliegan en otro entorno diferente (Amazon, OpenShift, OpenStack,
Kubernetes OnPremise…)
• Por tanto, alcanzar consistencia en la evaluación (y refuerzo) de
seguridad entre entornos es clave

y para contenedores…
• La seguridad debe ser portable como los mismos
contenedores
• Las organizaciones deben adoptar técnicas y
herramientas que sean abiertas y que funcionen entre
plataformas (cross-platform) y entre entornos (cross-
environments)
• Los desarrolladores buildean la solución en un entorno
(Docker local, clúster local de Kubernetes…)
• La prueban en otro entorno (GitLabCI, Jenkins,TeamCity…)
• Y la despliegan en otro entorno diferente (Amazon,
OpenShift, OpenStack, Kubernetes OnPremise…)
• Por tanto, alcanzar consistencia en la evaluación (y
refuerzo) de seguridad entre entornos es clave

• Históricamente, las herramientas, reportes y configuración de seguridad,
tanto base como de políticas, nos han hecho sentir así…

• La complejidad creciente de los sistemas requieren de herramientas que nos
sean:
• Sencillas de instrumentar
• Con información suficiente, pero no excesiva
• Con alertas suficientes, pero no excesivas
• Pero sobretodo
• Usable
• El volumen de información, la complejidad de los sistemas y el aumento de la
variedad y cantidad de ataques necesitan que la aplicación de técnicas de
seguridad sea usable

• La complejidad creciente de los sistemas requieren de
herramientas que nos sean:
• Sencillas de instrumentar
• Con información suficiente, pero no excesiva
• Con alertas suficientes, pero no excesivas
• Pero sobretodo
• Usable
• El volumen de información, la complejidad de los
sistemas y el aumento de la variedad y cantidad de
ataques necesitan que la aplicación de técnicas de
seguridad sea usable

Por qué debería creerte?

Contenedor vs máquina virtual (vm)

Ciclo de desarrollo con contenedores

Riesgos y contramedidas

vulnerabilidades con imágenes

• Las imágenes son instantáneas estáticas de un sistema operativo (y las
dependencias necesarias para ejecutar la aplicación) en un instante de tiempo
• La ’estaticidad’ de las imágenes las hace proclives a falta de actualizaciones de
seguridad
• Una imagen creada hoy, con todo actualizado, puede estar libre de
vulnerabilidades conocidas por días o semanas después de su creación
• Pero inevitablemente se descubrirán vulnerabilidades en la imagen o en alguno de sus
componentes
• En un entorno no contenerizado, simplemente se actualizan las máquinas
• Pero las imágenes son inmutables, por lo que se requiere hacer una nueva versión y subirla al
repositorio de imágenes para que los sistemas que las usan se actualicen
• Y cambiar la configuración del orquestador para que apunte a las nuevas imágenes
actualizadas…
Riesgo 1 – vulnerabilidades con imágenes

• Se requiere de herramientas y procesos específicos para la gestión de
vulnerabilidades en imágenes
• Las herramientas tradicionales cuentan con ciertas asunciones, como la
durabilidad del host y los mecanismos de actualización de aplicaciones, que
no aplican a las tecnologías de contenedores
• Estas herramientas a menudo son incapaces de detectar vulnerabilidades
dentro de los contenedores, dándonos una falsa sensación de seguridad
contramedida 1 – vulnerabilidades con imágenes

• Algunos aspectos clave a tener en cuenta
• Policy-driven. Las organizaciones deben ser capaces de crear quality
gates en todo el ciclo de vida de la imagen que garanticen que solo las
imágenes que cumplen el estándar de seguridad puedan ser
utilizadas
• Integración con el ciclo de vida completo de las imágenes
• Visibilidad de vulnerabilidades en todas las capas de la imagen, no
solo de la imagen base, también de frameworks, software de teceros y
software propio

image missconfiguration

• Un clásico
• Ejemplos
• Imagen que corre todo con privilegios de administrador
• Imagen que tiene instalado un SSH daemon
• Imagen con credenciales por defecto
• …
• Lo de siempre en sistemas, pero ahora en imágenes. Not new.
Riesgo 2 – image missconfiguration

• Contramedidas recomendadas
• Se deben configurar las imágenes para que corran con usuarios sin privilegios (o
con los mínimos necesarios)
• Añadir al proceso de build la validación de la configuración de las imágenes,
incluyendo las recomendaciones del vendor
• Informes continuos, constantemente actualizados, centralizados y
monitorización constante de imágenes para identificar, lo más prematuramente
posible, debilidades y riesgos
• Policy-driven. Procesos y automatismos que permitan prohibir la ejecución de
máquinas que no cumplan con el quality-gate
• Uso de imágenes base solo de fuentes de confianza (oficiales)
contramedida 2 – image missconfiguration

• Contramedidas recomendadas
• Actualización frecuente de las imágenes base para reducir la superficie de ataque
• Usa siempre como imagen base tecnologías específicas para contenedores
• No uses Ubuntu, Debian ni sistemas operativos de propósito general
• En su lugar, utiliza Alpine Linux,Windows Nano Server, etc.
• Es más engorroso, porque tienes que instalar dependencias básicas, pero reducen muchísimo la superficie de
ataque
• Nunca, amigo, nunca habilites SSH en un contenedor
• Los contenedores deben correr de forma inmutable
• Habilitar acceso por SSH abre la puerta a cambios, que violan este principio
• Y además exponen al contenedor a un enorme riesgo de red
• Si tienes que acceder a un contenedor, utiliza el API del runtime…

Pero no añadas paquetes software, ni actualices, ni hagas
nada más que consultar, recuerda la inmutabilidad de los
contenedores.

Embedded shit

• Ojo con el malware dentro de las imágenes
• Es una manera COXONUDA de expandir malware
• Especialmente si estamos en entornos de alta carga y elásticos (como Kubernetes,
por ejemplo)
riesgo 3 – embedded shit

Explicar Riesgos / Contramedidas / Ejemplos

Riesgo 3 – embedded shit

R3 – embedded shit

• Ojo con empaquetar imágenes con secretos, claves, API Keys o
whatever… en claro https://github.com/christianmetz/wildfly-mysql/blob/master/Dockerfile
Riesgo 3 – embedded shit

Conexiones inseguras a registros

• Como hemos visto, las imágenes son sensibles, por que son la base de
todo
• Si las conexiones a los repositorios de imágenes se hacen a través de
conexiones inseguras, los contenidos de las imágenes viajan en claro
• Si se trata además de un repositorio privado, es más probable que me haya
relajado con el tema de los secretos, claves, etc.
• Además, se incrementa el riesgo de un ataque por man-in-the-middle
• Docker, por defecto, no permite la inclusión de registros inseguros…
pero se pueden activar…
Riesgo 4 – conexiones inseguras a registros de imágenes

192.168.3.21:8081
192.168.3.21  artifactory.my-org.es
DNS Server
Dame IP de artifactory.my-org.es
Toma: 192.168.3.21
Oye 192.168.3.21, dame la imagen jboss/wildfly:latest
Toma churro de bytes
Expulsa de la red
Suplanta a JFrog,
tomando su IP
192.168.3.21:8081
192.168.3.22:8081
Cuando el legítimo JFrog reaparece, ya no tiene la misma IP, ergo ya no sirve a Kubernetes

Tráfico de red entre contenedores

• El tráfico entre contenedores se suele routear sobre una red virtual
• Esta red está típicamente manejada por el orquestador y es,
habitualmente, opaca
• Además, las herramientas de monitorización, administración y seguridad de
redes convencionales no sirven
• Porque ese tráfico NOVA POR LA INTERFAZ DE RED ‘física’
• Va por otra parte, y somos ciegos a ella
• Pero lo potencialmente crítico es mezclar tráfico ‘virtual’ (opaco) de
diferentes aplicaciones sobre la misma red virtual
• Especialmente si la ‘sensibilidad’ de las aplicaciones es diferente
• No es lo mismo mezclar tráfico de Spotify y Facebook…
• Que mezclar tráfico entre el ERP y el blog en Wordpress de mi empresa…
Riesgo 5 – tráfico de red entre contenedores

• Si aplicaciones de diferente nivel de sensibilidad usan la misma red virtual,
el riesgo a un ataque de red exitoso aumenta
• Si el WordPress se compromete, los atacantes tendrán visibilidad al tráfico de red
del ERP
Riesgo 5 – tráfico de red entre contenedores

• Los orquestadores deben configurar las aplicaciones en redes en base a su
nivel de sensibilidad (segmentación de red por sensibilidad)
• Aunque también es posible dar una red a cada aplicación (segmentación de
red por aplicación), para la mayoría de las organizaciones definir redes por
sensibilidad es suficiente
• Un pelín más de riesgo, pero muchísimo más mantenible
contramedida 5 – tráfico de red entre contenedores

Mezcla de nodos

• Imaginemos un orquestador cualquiera, por ejemplo Kubernetes
• Nuestro Kubernetes tiene 4 nodos físicos, en los que corren los
contenedores
• Qué contenedores corren en qué nodos es irrelevante para Kubernetes
• Sin configuración adicional, un contenedor puede caer en cualquier nodo
físico
• Eso significa, que mi contenedor deWordpress puede caer en el mismo
nodo físico que mi contenedor del ERP
riesgo 6 – mezcla de nodos

• Aunque tenga configuradas redes virtuales diferentes para esos nodos, que físicamente
estén en el mismo equipo implica ciertos riesgos
• Por ejemplo, en Kubernetes se puede montar un volumen directamente en el sistema
de ficheros del nodo que hostea al contenedor
Load Balancer
Nodo físico A Nodo físico B
POD
WP
DockerRuntime
DockerRuntime
HostFS
HostFS
POD
WP
POD
ERP
POD
ERP
riesgo 6 – mezcla de nodos

• Configurar tu orquestador para aislar despliegues en nodos por sensibilidad
• Misma estrategia que para la red, pero para los nodos
• Cómo implementarlo dependerá del orquestador, si tomamos el ejemplo de Kubernetes
• Podemos configurar reglas de afinidad (affinity) que aseguren que la planificación de los pods/contenedores se
hace por sensibilidad
• Podemos tener varios clústers de Kubernetes por sensibilidad…
• Aunque el orquestador que usemos haga un buen trabajo aislando
contenedores de nodos físicos, asilar despliegues por sensibilidad nos da un
nivel adicional de defensa muy interesante
• Esta aproximación también asegura que si queda algún dato residual (cachés,
volúmenes locales, etc.), este solo podrá ser comprometido por contenedores
infectados de su mismo nivel de sensibilidad, dificultando así el robo de datos
contramedida 6 – mezcla de nodos

orchestrator trust

• La confianza entre el orquestador y sus nodos físicos requiere de un
especial cuidado
• El orquestador es el nodo más importante del sistema
• Una configuración débil del orquestador puede exponer a todo el sistema a
múltiples riesgos
• Algunos ejemplos:
• Inclusión de nodos físicos no autorizados al clúster
• Si un nodo se ha comprometido se compromete todo el clúster
• Ya que comparten claves de seguridad
• Comunicaciones entre DevOps y el orquestador, administradores y otros hosts sin
encriptar y sin autenticar
riesgo 7 – orchestator node trust

• Los orquestadores deben asegurar que los nodos físicos de los que se
compone el clúster tienen una identidad persistente y deben estar
siempre autenticados
• También deben proveer de un inventario actualizado de nodos, que
incluya su estado de conectividad
• Deben ser capaces de aislar un nodo comprometido y eliminarlo del
clúster sin degradar el conjunto de operaciones del clúster
• Las comunicaciones entre nodos deben hacerse por HTTPs (encriptadas)
contramedida 7 – orchestator node trust

• Hay muchísimas más recomendaciones de seguridad específicas para
contenedores, que tienen que ver con
• Imágenes
• Container registries
• Orquestadores
• Contenedores
• Sistemas operativos Host
• Riesgos externos
• Por no hablar de la seguridad de las propias aplicaciones, que es otro
mundo…
• Pero hay 4 elementos que son fundamentales en lo que a seguridad en
contenedores se refiere
conclusiones

Explicar Riesgos / Contramedidas / EjemplosExplicar Riesgos / Contramedidas / Ejemplos

• Para conseguir esto tenemos que apoyarnos en nuevas tecnologías y
nuevos paradigmas
• Big Data
• Machine Learning
• Blockchain
• OSINT
• Counterintelligence
• Deception
• Seguir con el desacoplamiento de elementos críticos
• ZeroTrust Architecture
• Pero esto no es tan fácil como soltar 4 palabros de moda…
conclusiones

Proyecto opossum
IMDEEA/2020/64
AppSec
DevSecOpsInfraSec
OPOSSUM

Proyecto opossum
IMDEEA/2020/64

Gracias!

Webinar Codemotion 2020 - Piratas del Cloud

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Webinar Codemotion 2020 - Piratas del Cloud

Semelhante a Webinar Codemotion 2020 - Piratas del Cloud (20)

Último

Último (20)

Webinar Codemotion 2020 - Piratas del Cloud

Notas do Editor