Ciberseguridad en el Cloud - ¿Y es que eso no puede hacerlo otro?

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

Who’s that guy
• Actualmente Security Advocate & Software
Architect en @ITI_TIC
• +10 años con proyectos comerciales
• Big Data, Machine Learning, Cloud Computing, etc…
• Formador y ponente
• +40 cursos impartidos
• +50 charlas
fjbarrena
@DogDeveloper

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

Como odio a los developers

Hemos pasado de defender esto

Poner escena de Zombies rápidos a tope
¿Quizá Resident Evil?

A defender esto…

• 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 para VM 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 de VMs
• 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 con VMs
• Mascotas vs Ganado
• Lo que con VMs 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

Explicar Riesgos / Contramedidas / Ejemplos

• 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

• 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.

• 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

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

• 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
Oye 192.168.3.21, dame la imagen jboss/wildfly:latest
Toma churro de bytes con extra de mining de cryptomonedas

• 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 NO VA 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

• 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 de Wordpress 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

• 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
• Zero Trust Architecture
• Pero esto no es tan fácil como soltar 4 palabros de moda…
conclusiones

Gracias!

Ciberseguridad en el Cloud - ¿Y es que eso no puede hacerlo otro?

Recomendados

Recomendados

Más contenido relacionado

Similar a Ciberseguridad en el Cloud - ¿Y es que eso no puede hacerlo otro?

Similar a Ciberseguridad en el Cloud - ¿Y es que eso no puede hacerlo otro? (20)

Último

Último (16)

Ciberseguridad en el Cloud - ¿Y es que eso no puede hacerlo otro?