Todo lo que querías saber sobre cómo abordar las vulnerabilidades de seguridad en contenedores basados en Linux

Piensa en la imagen de contenedor más importante que tienes ejecutándose en producción ahora mismo. ¿Cómo elegiste su imagen base? ¿Sabes cuántas vulnerabilidades tiene? ¿No te gustaría saberlo?

En Snyk, buscamos que elegir la imagen base más segura sea un proceso más inteligente, sencillo y, sobre todo, basado en datos.

Pero primero, veamos algunos conceptos sobre la seguridad de las distribuciones de Linux, ya que esta publicación se centra en imágenes basadas en Linux.

Las distribuciones de Linux en pocas palabras

Una distribución de Linux (distro) es un sistema operativo (SO) creado a partir de una colección de software que incluye un kernel de Linux (el núcleo del sistema operativo), un sistema de administración de paquetes y herramientas y bibliotecas de GNU, además de otros programas y documentación. Todo esto se agrupa y modifica por quienes mantienen la distribución para maximizar sus capacidades y adaptarla a las necesidades de diversas plataformas y dispositivos.

Por lo general, las distribuciones se ofrecen de dos maneras:

• como archivos binarios compilados (imágenes empaquetadas), disponibles para descargar desde repositorios de imágenes como Docker Hub. Por lo general, las imágenes se empaquetan a partir de las bibliotecas cuyo código fuente se mantiene.

• como código fuente, que permite modificar el software original. Esto ofrece gran flexibilidad, sobre todo porque la mayoría del software incluido en la distribución suele ser de código abierto.

Hoy en día, hay cientos de distribuciones de Linux disponibles, y la mayoría recibe mantenimiento activo. Su amplia disponibilidad y flexibilidad funcional permiten usarlas en distintas plataformas y dispositivos, incluidos los contenedores.

Al igual que cualquier otro software, los contenedores también son vulnerables a ataques debido a las vulnerabilidades que pueda haber en su código.

¿En qué se diferencia la seguridad entre las distintas distribuciones de Linux y sus versiones?

La forma de crear y mantener cada distribución varía. Estas diferencias pueden incluir cómo se agrupan y administran los componentes, entre otras cosas, y dan lugar a distintos tamaños de distribución, administradores de paquetes y niveles de exposición a vulnerabilidades de seguridad.

Una vulnerabilidad de seguridad en un componente puede tener distintos niveles de gravedad según la distribución. Un componente común a varias distribuciones podría considerarse seguro en una y recibir una puntuación CVE alta en otra; todo depende de cómo se empaqueta cada distribución.

Algunas distribuciones suelen ser más seguras que otras gracias a los mecanismos que sus responsables incorporan en el proceso de mantenimiento. Las distribuciones comerciales y consolidadas (Debian, Ubuntu, CentOS y Oracle) cuentan con equipos de seguridad dedicados. Estos equipos se encargan de revisar las puntuaciones CVE, priorizar e implementar correcciones de seguridad y mantener la seguridad general de la distribución.

Aun así, hay diferencias entre las opciones disponibles. En la tabla se detallan las diferencias en la forma de administrar estas importantes distribuciones, un factor que también afecta su nivel de seguridad:

*Alpine tiene un enfoque distinto para mantener las imágenes: actualiza sus paquetes con regularidad e incorpora correcciones de seguridad para un pequeño grupo de sus paquetes principales (curl, …).

¿En qué se diferencia una distribución de Linux de un ecosistema de lenguajes?

Los ecosistemas de lenguajes almacenan paquetes en registros, y los administradores de paquetes (como npm y pip) se encargan de mantenerlos actualizados. De manera similar, las distribuciones se almacenan en repositorios de paquetes para reutilizarlas como dependencias en distintos proyectos. Sin embargo, se empaquetan como imágenes y luego se almacenan por separado en repositorios de paquetes diseñados para imágenes, desde donde se pueden descargar y usar de inmediato en otros proyectos. Una vez empaquetadas para descargarse y usarse de inmediato, las imágenes se almacenan en sus propios registros de paquetes y sus administradores de paquetes las actualizan por separado de las bibliotecas de origen.

En ambos casos, el administrador de paquetes se encarga de descargar el paquete periódicamente, actualizarlo y volver a cargarlo en su almacenamiento.

Sin embargo, ahí terminan las similitudes.

Mantenimiento de paquetes en ecosistemas de lenguajes

En los ecosistemas de lenguajes, la vida es bastante sencilla: hay un registro de paquetes, al menos un administrador de paquetes y una relación exclusiva y directa entre ambos. El administrador descarga y carga los paquetes en el registro.

Esto se puede representar con el siguiente diagrama (a la izquierda, un ejemplo general que representa cualquier repositorio de paquetes; a la derecha, un ejemplo específico de npm):

Mantenimiento de paquetes en repositorios de distribuciones

En cambio, las distribuciones en repositorios de imágenes son un poco más complicadas. Una distribución puede usar varios repositorios, administradores de paquetes y herramientas para cargar paquetes. La elección del repositorio, el administrador y la herramienta depende del número de versión de la distribución, su alcance (main, contributions, non-free, community), entre otros factores.

Esto se puede representar con el siguiente ejemplo (a la izquierda, un repositorio de paquetes genérico para cualquier distribución y versión; a la derecha, un ejemplo de varias versiones de Debian):

Cada versión de Debian usa el repositorio que corresponde a la versión indicada.

No siempre hay paquetes y sus versiones disponibles en todos los repositorios. Algunas distribuciones permiten adaptar paquetes a versiones anteriores (es decir, instalar en otra versión tipos de paquetes disponibles solo para una versión específica), y algunos paquetes se pueden agregar directamente a una versión de la distribución desde un repositorio externo, como un archivo de paquetes personales (PPA) de Ubuntu, en lugar de usar el administrador de paquetes nativo. Esta compleja relación entre paquetes y distribuciones contrasta con la relación sencilla entre registros de paquetes y administradores de paquetes, que es mucho menos sensible a los problemas de versiones descritos.

Las complejidades de abordar los problemas de seguridad de los contenedores

La mayoría de los equipos de seguridad de las distribuciones mantienen correcciones de seguridad solo para algunos de sus componentes. Por ejemplo, Debian solo ofrece oficialmente correcciones de seguridad para sus componentes principales, tal como se indica en su documentación. Esto se debe al complejo proceso de evaluar las distintas imágenes a lo largo del tiempo.

Como mencionamos, las imágenes se empaquetan a partir de su código fuente, que suele almacenarse por separado en bibliotecas de código abierto. Una vez empaquetada, almacenada y mantenida en su propio repositorio, la imagen sigue avanzando con sus propias versiones, independientemente de la biblioteca de código fuente, que también evoluciona con sus propias versiones y a su propio ritmo. Esto significa que una vulnerabilidad presente en la biblioteca podría no estar en la imagen. Es posible que haya aparecido en una versión posterior de la biblioteca y, en ese caso, nunca afectaría a la imagen ya empaquetada. También puede ocurrir lo contrario.

Cuando se descubre una vulnerabilidad de seguridad en una biblioteca a partir de la cual se creó una imagen, los equipos de seguridad deben evaluar la imagen y verificar si la vulnerabilidad realmente existe y si se considera una vulnerabilidad según la composición de la propia imagen.

Las versiones de la mayoría de las distribuciones más antiguas y consolidadas no suelen actualizarse de forma drástica; por lo general, reciben actualizaciones menores y correcciones de seguridad para nuevas vulnerabilidades. 

La mayoría de las distribuciones suelen considerar que no reciben mantenimiento las versiones muy antiguas que llegaron al fin de su vida útil (EOL), así como las versiones nuevas (versiones edge que quizá aún no estén bajo la responsabilidad del equipo de seguridad). Por ejemplo, Debian 7 llegó al fin de su vida útil. Si una vulnerabilidad afecta a la versión X de un paquete disponible solo en versiones EOL o recién lanzadas, es posible que no aparezca en los avisos de seguridad de la distribución. Por eso, el nivel de soporte de seguridad de la distribución para versiones EOL y de vanguardia no siempre refleja su estado de seguridad real. En estos casos, la información disponible no es suficiente para que Snyk detecte todas las vulnerabilidades, e incluso podrían pasar inadvertidas algunas vulnerabilidades críticas.

¿Por qué no se admite mi distribución de Linux?

Analizamos cada imagen basada en una distribución compatible según la distribución y su versión, y la comparamos con nuestra base de datos de vulnerabilidades. Después del análisis, enumeramos las vulnerabilidades e incluimos detalles sobre ellas y su origen, si tienen una corrección, qué distribuciones y versiones están afectadas y a partir de qué versión se corrigen.

Al recopilar vulnerabilidades, hacemos todo lo posible para estar al día con cada nueva versión y preparar nuestra hoja de ruta. También hacemos un seguimiento cercano de la actividad y las necesidades de nuestros usuarios para enriquecer nuestra base de datos; además, siempre estamos disponibles para conversar con ellos en support@snyk.io y a través de nuestra cuenta de Twitter. También nos esforzamos especialmente por admitir las versiones LTS de los proveedores que analizamos en esta publicación. Dicho esto, no admitimos todas las distribuciones existentes. Por ejemplo, si tu imagen se basa en una distribución muy antigua o muy nueva, es probable que Snyk no la admita.

¿Cómo sabe Snyk qué alternativas de imágenes base seguras recomendar?

También recopilamos periódicamente datos de una amplia variedad de repositorios y obtenemos varias veces al día todas las etiquetas de cada repositorio de Docker Hub para mantener la información actualizada. Con estos datos, también podemos recomendarte cómo corregir la imagen base (o principal), siempre que hayas vinculado tus proyectos de Snyk al Dockerfile correspondiente.

Si conoces el análisis de aplicaciones de Snyk, quizá estés acostumbrado a encontrar desde un par hasta unas cuantas decenas de vulnerabilidades por repositorio que supervisas o analizas. Sin embargo, en el ecosistema de Linux las cifras son distintas: encontrar unos cientos de vulnerabilidades es bastante común.

Esto puede ser abrumador. Por eso, intentamos ofrecerte recomendaciones más prácticas e información útil sobre la imagen y sus vulnerabilidades. Para ayudarnos, te pedimos que proporciones el Dockerfile, que suele formar parte de un proyecto de contenedor.

Al usar Snyk para analizar tus imágenes, puedes agregar un enlace al código fuente donde guardaste el Dockerfile. Una vez que analicemos el repositorio, podremos ofrecerte recomendaciones de corrección basadas en los resultados. Lee más sobre cómo vincular tu Dockerfile en nuestra documentación.

Una vez que tenemos el Dockerfile, detectamos la imagen base y determinamos cuántas vulnerabilidades se originaron en ella y cuántas provienen de otras capas agregadas mediante el Dockerfile. Esto es útil para decidir si debes modificar las otras capas agregadas en el Dockerfile y para determinar si conviene reemplazar la imagen base por otra más segura.

Para sugerir actualizaciones pertinentes, descargamos y analizamos continuamente decenas de repositorios y cientos de etiquetas. Luego, consultamos nuestra base de datos de imágenes junto con nuestra base de datos de vulnerabilidades de seguridad para encontrar la imagen más segura disponible con resultados actualizados. Después, sugerimos etiquetas del repositorio para tu imagen base, incluidas opciones para:

• una actualización menor: como su nombre indica, una etiqueta con una actualización menor respecto de tu etiqueta actual. A veces, con solo una actualización menor puedes eliminar decenas e incluso cientos de vulnerabilidades. ¿Por qué no probarla?

• una actualización mayor: pasar a la siguiente versión principal

• una alternativa: recomendamos otras imágenes no relacionadas que podrían ser adecuadas para tu contenedor

Consideramos que una etiqueta alternativa es una posible actualización si cumple las siguientes condiciones:

• Tiene menos vulnerabilidades de gravedad alta, o la misma cantidad de vulnerabilidades de gravedad alta y menos vulnerabilidades de gravedad media, y la misma cantidad o menos vulnerabilidades de gravedad baja.

• La distribución de SO de la etiqueta de la imagen candidata no es demasiado antigua, de vanguardia, sin soporte a largo plazo ni inestable.

• Como los avisos de seguridad de las distribuciones Alpine solo están disponibles para un pequeño subconjunto de paquetes con parches, consideramos que las imágenes basadas en Alpine ofrecen poca visibilidad de seguridad. Por eso no recomendamos etiquetas basadas en Alpine.

Las actualizaciones alternativas pueden usar etiquetas de distintas distribuciones y, por lo tanto, suelen implicar un cambio mucho más riesgoso. Sin embargo, queremos ofrecerte información sobre la mayor cantidad posible de opciones para proteger tu imagen.

Conclusiones

Los contenedores son distintos de las bibliotecas, lo que hace que la seguridad y la clasificación de problemas sean, sin duda, más desafiantes. Al mismo tiempo, los contenedores están por todas partes gracias a sus evidentes e importantes beneficios. Sin embargo, eso no significa que tengas que lanzar contenedores peligrosos. Con un poco de planificación y la implementación de buenas herramientas de seguridad, como Snyk, puedes simplificar considerablemente el proceso de proteger tus contenedores.

En cualquier caso, es importante que clasifiques tus contenedores con regularidad para asegurarte de que sigan siendo lo más seguros posible. Cuando detectes una vulnerabilidad y necesites corregirla reemplazando la imagen base, ten en cuenta estos puntos para mantener tu contenedor seguro sin que deje de funcionar:

• Comprueba si dependes de algún paquete del SO y, de ser así, asegúrate de que la actualización no lo afecte.

• Ten en cuenta el tamaño de la imagen.

• Si consideras una actualización alternativa, también debes revisar los comandos o las funciones específicas de la distribución que estés usando y actualizarlos según corresponda.

Prueba hoy mismo a analizar tus imágenes con Snyk.