sftp

sFTP en AWS EC2 en 5 minutos

En algún momento te puedes encontrar con la necesidad de levantar un sFTP para que alguien te envíe ficheros. Yo lo he necesitado hace poco y lo he solucionado rápidamente con una instancia de AWS EC2. Te dejo paso a paso lo que tienes que hacer por si lo necesitas.

Leer más

micro_focus_summit17

SecurityInside Live: Micro Focus Summit 2017

El éxito de mañana está vinculado a la respuesta que hoy se dé a los desafíos de seguridad de nuestro negocio. Por eso, Micro Focus comparte en su Summit 2017 las experiencias de sus clientes y el conocimiento de su equipo.

Leer más

SecurityInside Live: Mundo Hacker Day 2017

Al igual que el año pasado, me voy al evento “Mundo Hacker Day 2017” para asistir en primera persona a las interesantes charlas que grandes expertos en seguridad van a ofrecer.

Leer más

Seguro que te interesa (GitHub behind the scenes – parte 1)

Esta entrada es un poco atípica, realmente no es más que una excusa para presentaros el nuevo repositorio en GitHub de esta web.

Poco a poco quiero ir ofreciendo los scripts que me hacen la vida más sencilla y que pueden ayudaros en ciertas tareas. Para estrenar el repo, he pensado en contar cómo hago la entrada de los Viernes en las que os listo las noticias que me han parecido más interesantes de la semana.

Tras unas cuantas entradas en las que iba recopilando enlaces a mano, decidí que así no podía continuar. Como dice un gran amigo, soy muy vago, pero vago de los buenos. Eso me hace pensar en cómo automatizar absolutamente todo lo que hago para que las tareas repetitivas las haga una CPU y yo pueda centrarme en ideas felices o a imaginar qué isla me compraré cuando me toque la lotería.

Gracias a lo de internet, tiro de Twitter para estar al tanto de las noticias de última hora y suelo hacer retweet de lo que me llama la atención. Noticias, herramientas, análisis, humor… pero todo relacionado con lo que me apasiona, la seguridad de la información.

Como últimamente le he cogido cariño a Python (al pitón como le llamo alegremente por la oficina de Dive), decidí tirar de un poco de crawling vía BeautifulSoup para buscar en twitter ciertos elementos.

Básicamente lo que hago es abrir la página de Twitter de SecurityInside y busco todos los retweets. De cada uno, me quedo con los elementos interesantes (título, autor, imágen y texto) y los pongo en forma de tabla para que se vea de forma decente como una entrada del blog. Básicamente esto:

El ejemplo es sólo parte del script completo. Si quieres utilizarlo o modificarlo, puedes descargarlo desde nuestro repositorio en GitHub.

 

Como podéis ver, sólo tengo que copiar la línea que me genera el script e insertarla en la entrada. La tarea se completa añadiendo el texto habitual y configurando las categorías, la imágen y los valores SEO.

Vale, me vais a decir que eso también se puede automatizar. La respuesta es que si, por eso os dejo pendiente la segunda parte del artículo en la que dedicaré otro rato a generar la entrada completa (insertando en base de datos y demás).

Pero poco a poco, que estoy un poco liado gestionando los backups anti malware de la junta directiva… pero eso es otra historia que os voy a contar en breve.

¿Os lo vais a perder?

Contenedores Linux y seguridad. Docker

Un poco de historia

Las técnicas de para circunscribir un proceso a un espacio aislado dentro de un sistema operativo no es algo nuevo. El primer antecedente, chroot, se remonta a 1979 y fue introducido como un concepto en desarrollo para sistemas Unix que permitía aislar dentro una ruta un proceso y sus hijos de modo que para ellos, esa ruta pareciese ser el directorio raíz. Más adelante,  en 1982, chroot se incorpora a sistemas operativos BSD. En 1991 es utilizado por William Cheswick, un programador e investigador en seguridad de red, para implementar una honeypot y monitorizar comportamientos maliciosos.

Estas semillas iniciales supusieron los primeros pasos de lo que se acabaría consolidando como virtualización de sistemas con la aparición de hypervisores, software que permite la ejecución virtual de sistemas completos emulando tanto el hardware como el sistema operativo.

Dejando a un lado lo que a virtualización de hardware e hypervisores se refiere, en este artículo vamos a ofrecer una visión de los contenedores, una tecnología que,  partiendo de la idea base de chroot, extiende este concepto para conseguir ejecutar entornos aislados del sistema. Con el uso de contenedores, en realidad no se está virtualizando nada sino que se están manteniendo en un espacio aislado (namespace) los procesos y ficheros necesarios mientras se reutiliza el kernel del sistema anfitrión.

La primera aproximación sólida a los contenedores en sistemas *nix aparece  en FreeBSD en el año 2000 con la introducción del comando jail que orienta y amplia las funcionalidades de chroot. A partir de ahí, se empieza a extender a otras plataformas como Solaris, el sistema operativo de Sun Microsystems, que en  2005 incorpora Solaris Zones permitiendo crear subsistemas aislados denominados zonas. De igual forma otros fabricantes como IBM con AIX WPARs,  o HP con HP-UX Containers adoptan implementan soluciones similares.

Finalmente, en 2008, llega a Linux con LXC (Linux Containers) que da soporte al kernel para los namespaces. Los namespaces constituyen el elemento base de los contendores y es una funcionalidad del kernel que proporcionan facilidades para crear una abstracción del sistema de modo que, todo lo que sucede fuera del espacio del contenedor sea invisible al interior.

¿Virtualización? ¿Qué virtualización?

La evolución de los namespaces ha permitido pasar del “enjaulamiento” de rutas de chroot hasta los contenedores que proporcionan espacios aislados en todos los niveles: espacio de usuario, espacio de procesos, de red, puntos de montaje, etc. Esta situación se acerca a estado parecido a la virtualización que quizás podemos entender mejor como una virtualización de sistema operativo o mejor dicho, una “paralelización” puesto que se comparte una arquitectura y un kernel y no se virtualiza ningún elemento hardware o dispositivo lo que contribuye a un mejor rendimiento.

 

Screen Shot 2016-06-21 at 08.10.45

Contenedores vs virtualización

La popularidad y la utilización de los namespaces ha crecido enormemente desde su integración directa, en 2013 en el kernel 3.8 de Linux. Desde entonces se han consolidado y afianzado desarrollos basados en contenedores como por ejemplo  Docker o CoreOS Rkt entre otros.

Contenedores vs hipervisores

Los contenedores frente a la virtualización de hardware mejoran aspectos como:

Velocidad: Compartir el kernel significa cero latencia para levantar con contenedor.

Gestión de disco: El almacenamiento basado en sistemas de ficheros con características Copy on Write (CoW) permiten reutilizar y compartir segmentos de sólo lectura de datos (imágenes base)  entre distintos contenedores y trabajar con deltas (capas de escritura) que cada contenedor puede ir añadiendo y manteniendo de forma independiente. Sistemas de ficheros como Union Filesystems (aufs), OverlayFS o Brtfs permiten este modo de operación.

Portabilidad: Un contenedor puede trasladarse a cualquier otro sistema siempre que comparta la misma arquitectura de CPU, sin necesidad de adaptaciones. Esto permite trabajar de forma rápida y cómoda con repositorios que facilitan enormemente tareas de despliegue y desarrollo.
Por otro lado algunos inconvenientes son:
Seguridad: La implementación de los namespaces es relativamente reciente, y esto unido a que el kernel es compartido, incrementa los riesgos de comprometer el host y con ello todos los contenedores que estuviesen en el mismo. Punto único de fallo.
Entornos únicos: La imposibilidad de virtualizar otros sistemas operativos puede ser una desventaja en desarrollos multiplataforma.
Escalado y migración: Aunque existen soluciones de orquestación que permiten la ejecución multicontenedor distribuidos en distintas ubicaciones, la complejidad aumenta notablemente según lo hace el número de hosts. Esto unido a la imposibilidad de migración “en caliente” para mover contenedores supone una desventaja ante soluciones completas de virtualización.

Contenedores y seguridad. Namespaces, cgroups, capabilities y más.

El aislamiento en los contenedores Linux se sustenta principalmente en dos funcionalidades del kernel: los namespaces y cgroups, que haciendo una aproximación sencilla podemos identificar como los mecanismos que proporcionarán la base para el aislamiento a nivel cualitativo y cuantitativo respectivamente. Desde la versión de kernel 2.6, ambas tecnologías se han ido asentando paulatinamente hasta una completa integración en el kernel 3.8. Revisando la configuración del kernel (generalmente existe un fichero de config en /boot) podemos averiguar el grado de soporte en la compilación en uso, como muestran las siguientes imágenes para un kernel 4.0:

Desde el punto de vista de la seguridad, los namespaces permitirán espacios aislados para los procesos que contienen, lo que protege el sistema de acciones que suceden en el interior de la sandbox creada. Por otra  parte los control groups (cgroups), permiten gestionar los recursos que se atribuyen a ciertos procesos, siendo posible de este modo asignar límites cuantitativos de CPU, memoria, acceso a disco, etc. Esto es muy útil para asegurar que el sistema no pueda ver comprometidos sus recursos.

Por otra parte, el uso de las capabilities del kernel complementaría la seguridad de los namespaces y los cgroups, restringiendo y evitando acciones privilegiadas dentro del contenedor que podrían establecer una vía de escape de la sandbox.

Todo lo anterior unido a la integración de los contenedores con mecanismos de control de acceso como SELinux completa un entorno de seguridad suficientemente robusto que, como siempre, necesita de un ajuste y una configuración apropiada.

containers_security_layers

Aislamiento en contenedores

Una vez introducidos los mecanismos principales de seguridad de los contenedores: namespaces, cgroups, capabilities y SELinux, vamos a echar un vistazo a su funcionamiento.

Namespaces

Existen 6 tipos básicos de namespaces relacionados con distintos aspectos del sistema:

  • NETWORK namespace. Aislamiento de red. Así, cada namespace de red tendrá sus propios interfaces de red, direcciones de red, tablas de enrutamiento, puertos de red, etc.
  • PID namespace. Aísla el espacio de identificadores de proceso. Un contenedor tendrá su propia jerarquía de procesos y su proceso padre o init (PID 1).
  • UTS namespace. Aísla el dominio y hostname, permitiendo a un contenedor poseer su propio dominio de nombres.
  • MOUNT namespace. Aísla los puntos de montaje de los sistemas de ficheros que puede ver un grupo de procesos. Este namespace fue el punto de partida que nació con chroot.
  • USER namespace. Aísla identificadores de usuarios y grupos. Así dentro un contenedor es posible tener un usuario con ID 0 (root) que se corresponda con un ID de usuario cualquiera en el host.
  • IPC namespace. Aísla la intercomunicación entre procesos dentro del espacio.

Así, sobre un kernel con soporte para namespaces es posible aislar procesos utilizando las llamadas al kernel (clone) con los flags necesarios (CLONE_NEWNET, CLONE_NEWPID, CLONE_NEWUTS, CLONE_NEWNS, CLONE_NEWUSER, CLONE_NEWIPC) según lo deseado. Esta es la  base utilizada por frameworks como Docker para crear contenedores.

Utilizando Docker, verifiquemos en un ejemplo como los procesos dentro de un contenedor tienen namespaces distintos, lo que significa que se mueven en espacios independientes y aislados entre sí. En el escenario mostrado en la imagen siguiente,  podemos ver la ejecución de una shell (sh) dentro un contenedor utilizando Docker. Con el comando “docker ps” mostramos efectivamente, un contenedor con nombre loving_albatanni  que está ejecutando una shell. El pid del contenedor es 11344 desde el punto del host  que, correspondería al proceso 1 dentro del mismo y que identifica al  proceso “sh”,  el primer comando ejecutado en el contenedor.

Podemos verificar los cambios de namespaces con el comando pstree con el flag –S, que nos mostrará la jerarquía de procesos, indicándonos entre paréntesis los cambios de contexto en los namespaces. De forma más directa, inspeccionando /proc identificamos claramente identificadores distintos en los namespaces de proceso 1 del host y el proceso 11344 del contenedor (pid 1 dentro).

Namespace de procesos

Namespace de procesos



NOTA: Nótese que no hay cambio en el namespace de usuario ya que este es opcional y debe fijarse al arrancar docker. Al no haber cambio en el namespace de usuario, el usuario dentro del contenedor es el mismo usuario fuera de él. Esto quiere decir que root dentro del contenedor es root fuera, lo que entraña un riesgo de seguridad que conviene evitar configurando oportunamente la ejecución.

Cgroups

Los grupos de control o cgroups son una excelente herramienta para controlar la asignación de recursos hardware. Para ello se definen jerarquías en árbol en las que se agrupan los procesos del sistema apoyándose en una ruta del sistema de ficheros, generalmente ubicado en /sys/fs/cgroup (debian) o /cgroup (redhat). Simplificando, podemos imaginar como el tradicional ulimit pero mucho más extenso y granular. No es objeto de este artículo profundizar en la descripción funcional de los grupos de control, pero si es interesante ver como gracias a ello es posible recortar recursos a un contenedor y por tanto contribuir a aislar su impacto en el sistema.

De nuevo utilizando docker arrancamos dos contenedores uno sin especificar límite de memoria y un segundo aplicando un límite de 64mb utilizando el flag –m 64mb. Para demostrar la restricción de memoria corremos el programa stress para consumir 100Mb de memoria ( stress –vm 1 –vm-bytes 100M )

 

Con el comando systemd-cgtop podemos ver el consumo de recursos por distintos grupos de control y verificamos efectivamente que, uno de los contenedores no es capaz de consumir más de 64Mb:

 

cgroups

Las propiedades del contenedor y sus límites podemos comprobarlas con docker inspect:

cgroups_limit

Capabilities

Las capabilities proporcionan un buen mecanismo para restringir privilegios. En el caso de los contenedores es especialmente útil y por ejemplo en Docker, por defecto cualquier contenedor sufre un recorte de capabilities que impiden numerosas operaciones privilegiadas tales como el montaje de sistemas de ficheros o administración de interfaces de red entre otras.

Verifiquemos con un ejemplo real como se produce este recorte de capabilities comparando una shell en el host y una shell en el contenedor.

Una shell de root en el host tiene todas las capabilities:

Sin embargo, por defecto en un contenedor se restringen capabilities y como se puede ver en la siguiente imagen de un contenedor docker se eliminan todas menos unas pocas:

Esto se traduce en restricciones dentro del contenedor. Para ilustrar con un ejemplo: obsérvese que se han quitado las capabilities cap_net_admin y cap_sys_time, de modo quelo el kernel denegaría operaciones de cambio de fecha del sistema o manipulación de interfaces de red dentro del contenedor (aun siendo root):

Las capabilities necesarias pueden otorgarse o denegarse al arrancar el contenedor según se necesite.
Así por ejemplo podemos comprobar el efecto de quitar la capability NET_RAW necesaria para ejecutar ping:

Comprobamos que en las capabilities del contenedor ya no tenemos CAP_NET_RAW:

Contenedores y aseguramiento del contenido

Los contenedores de Linux y las tecnologías subyacentes tienen un desarrollo suficientemente sólido que han propiciado que su utilización se vaya asentando y teniendo en cuenta cada vez más. No obstante, ha de tenerse en cuenta que la falta de rodaje que conlleva esta relativa inmadurez se hace extensiva a la seguridad se echa en falta aún una base de metodologías para configurar, fortalecer y verificar aspectos que sin la debida atención pueden poner en entredicho la seguridad de sistemas “containerizados”.