En 1991, tuvieron lugar dos eventos no relacionados, cada uno de los cuales presagiaba dos libertades muy diferentes: el fin de la Guerra Fría y el nacimiento de Linux.
La posibilidad de parchear el kernel en tiempo real llegó en 2008, cuando Linux todavía era un adolescente. Ahora que el kernel de Linux está a punto de llegar a los 30, el parcheo en tiempo real también está maduro, y está listo para menospreciar su reputación como un complemento opcional que es simplemente "bueno tener en la caja".
Hay dos razones para esto. Primero está el dominio de Linux como la plataforma elegida para el alojamiento web económico y versátil: más de la mitadde todos los sitios web famosos se ejecutan actualmente en Linux. En segundo lugar, el reconocimiento de que la aplicación de parches en tiempo real es más que una conveniencia; También es una forma eficaz y económica de mejorar la seguridad de su sistema Linux.
Ksplice, la primera solución de parcheo del kernel de Linux en tiempo real, ganó sin esfuerzo un estatus lucrativo después del lanzamiento, solo fortaleciendo su liderazgo cuando el gigante tecnológico Oracle lo compró en 2011. En la actualidad, es la más famosa de las cinco organizaciones que ofrecen servicios de parches de seguridad automatizados para Linux. En orden alfabético, estos son:
- Servicio Canonical Livepatch para Ubuntu.
- KernelCare para Ubuntu, Red Hat Enterprise Linux, Oracle Linux, Amazon Linux y más.
- Kpatch para Red Hat Enterprise Linux.
- Ksplice para Oracle Linux.
- SUSE Linux Enterprise Live Patching para SUSE Linux Enterprise.
Cada empresa promociona sus servicios utilizando las mismas palabras clave estándar, las mismas frases estándar, repetidas sin cesar. Te daré los más populares y cómo debes entenderlos.
- Sin reiniciar : actualiza el kernel de Linux sin reiniciar.
- Automatizado: verifica e instala las actualizaciones de seguridad del kernel sin un observador.
- Fácil instalación: la instalación y configuración son muy simples o innecesarias.
- Totalmente compatible: no es necesario que escriba parches usted mismo. (Consulte el manual para escribir parches en Kpatch, para comprender por qué esto es importante)
Ignore estos puntos de venta deslumbrantemente obvios y encontrará otras características a considerar, otros factores que puede utilizar para comparar un servicio con otro. Este artículo explora algunos de ellos, ligeramente sazonados con afirmación y edificación. Pero primero, recordemos qué es el parche en vivo.
¿Qué es el parcheo del kernel de Linux en tiempo real?
El kernel de Linux contiene más de 20 millones de líneas de código escritas en su mayoría (presumiblemente) por programadores humanos. Como todo software, tiene errores. En esta era de mayor enfoque en la ciberseguridad, los errores implican vulnerabilidades . Para resolver este problema, los proveedores de Linux intentan lanzar actualizaciones para sus núcleos lo antes posible. Los administradores de sistemas de Linux también están tratando de reaccionar rápidamente instalando estas actualizaciones, lo que dificulta la programación. Esto se debe a que no existe un patrón para detectar vulnerabilidades. Aquí hay algunas razones de por qué:
- Hay muchas versiones diferentes del kernel de Linux en uso en un momento dado. Algunos necesitarán arreglos; algunos no lo hacen.
- , .
- Linux , .
- Linux . , , — .
Hay una cosa más que rara vez se menciona: es el disgusto instintivo del administrador del sistema por detener la máquina, lo que causa incomodidad física al tener que decir: "El servidor está fuera de servicio por mantenimiento".
¿Por qué detener el servidor? Porque la actualización del kernel no surtirá efecto hasta el reinicio. Si no reinicia, si lo deja en un segundo plano o lo olvida, se encontrará en un dilema porque un servidor sin los últimos parches es inseguro . Hablaremos de este mantra con más detalle más adelante, pero su esencia es esta:
cuando las vulnerabilidades se hacen públicas, lo mismo sucede con sus exploits.
O, en otras palabras, tiene una vulnerabilidad que no conocía antes, pero ahora la tiene. Y todos los demás también.
El salvador en este escenario es el parche en vivo . Esta es una forma de actualizar no todo el kernel de Linux, sino solo su parte problemática. Y esto se hace sin detener procesos ni interrumpir el trabajo de los usuarios.
Sin embargo, existen limitaciones. El parcheo del kernel en tiempo real no puede corregir todo tipo de errores. La abrumadora complejidad del código del kernel y los desafíos técnicos de cambiar el código sobre la marcha significan que esta técnica solo se utiliza para solucionar problemas críticos, generalmente relacionados con la seguridad.
A pesar de esto, un sistema con funciones de parcheo en tiempo real es más seguro que un sistema sin él. A continuación, se incluyen algunas preguntas que debe hacer al buscar una solución de parcheo en tiempo real:
1. ¿Qué hay dentro del parche (y quién está detrás de él)?
Cuando se suscribe a un servicio de parcheo en vivo, paga más que solo el software en sí. Esto se vuelve claro cuando comienza a buscar en la fuente del kernel de Linux y se da cuenta de cómo un parche mal escrito puede dañar todo un sistema Linux.
Mencioné anteriormente que el kernel es un enorme cuerpo de trabajo que parece expandirse tanto en actividad como en volumen. Tenga en cuenta el aumento en el número de líneas de código en la rama maestra del repositorio del kernel de Linux. (Cuenta a partir del 1 de enero de cada año. Solo se cuentan los archivos y encabezados C / C ++, los archivos Python y Perl).
Con tanto código, escribir parches para el kernel de Linux no es una tarea fácil. Se requiere un conocimiento profundo de la arquitectura del kernel y las estructuras de datos. Experiencia con las convenciones de codificación de la comunidad de Linux y los estándares de calidad. Y se necesita un talento especial para inventar soluciones que no afecten la funcionalidad, el rendimiento y la estabilidad.
Hay dos métodos opuestos que utilizan los proveedores de parches para desarrollar y entregar parches del kernel. Los llamo incrementales y monolíticos .
Los parches incrementales, como una bola de chicle, se apilan uno encima del otro, modificando cada uno el comportamiento del anterior. Como cliente, debe realizar un seguimiento de los parches que instala y los que no, y el orden en que se instalan. No prestar atención a estos problemas puede provocar cambios impredecibles en el comportamiento de su sistema. Este método de parcheo permite a los proveedores lanzar rápidamente pequeños parches específicos. Pero con el tiempo, el sistema puede volverse inestable hasta el punto de que solo una actualización completa del kernel puede restaurarlo.
Un parche monolítico es un parche que incluye todos los parches anteriores. Básicamente, solo hay un parche maestro que reemplaza al activo en lugar de agregarse a él. Este enfoque hace que la plataforma sea más estable, aumentando significativamente el tiempo de actividad del servidor, que a menudo se mide en miles de días.
2. ¿Cuánto tiempo esperar hasta el próximo parche?
Es inevitable que se produzca un retraso entre la notificación de una vulnerabilidad y su reparación. Se necesita tiempo para analizar los errores del kernel y tiempo para evaluar su impacto. Se necesita ingenio y habilidad para encontrar una solución, y toneladas de pruebas para asegurarse de que funcione. Luego está sujeto a revisión y aprobación obligatorias como parte del proceso de desarrollo de Linux.
Se producen retrasos evitables cuando el proveedor de Linux reemplaza la clasificación de gravedad de la comunidad por la suya propia. Esto significa que un proveedor puede solucionar múltiples vulnerabilidades con menos parches, pero debido a esto, el cliente espera en promedio más tiempo para solucionar ciertos problemas.
Los administradores de Linux que comprenden las razones de la naturaleza errática de los lanzamientos de parches no se benefician mucho más que aquellos que no lo hacen. Ninguno de ellos encuentra consuelo en el conocimiento de que mientras esperan los parches, sus sistemas son aún más vulnerables a un exploit de lo que eran antes de que fuera descubierto.
Este es el motivo: a los miembros de la comunidad de investigación en ciberseguridad les encanta anunciar vulnerabilidades junto con un caso de uso visual. Por lo general, toman la forma de una prueba de concepto, una descripción técnica detallada de cómo reproducir un error o utilizar un exploit. Estas descripciones son de buena fe para ayudar a los desarrolladores del kernel a encontrar y reparar el agujero. Pero también les ahorran a los piratas informáticos mucho tiempo y esfuerzo al darles un atajo a una receta literal para el desastre en su carrera por explotar la vulnerabilidad como arma.
3. ¿Qué tan grave debería ser el error?
A casi todas las vulnerabilidades recién descubiertas se les asigna un identificador CVE. Más tarde, tras una inspección más detallada por parte de los investigadores de seguridad, una vulnerabilidad se clasifica como gravedad, es decir, una medida de su impacto.
Un esquema de calificación importante es una Evaluación de Vulnerabilidad del sistema general (CVSS - Common Vulnerability Scoring System) . Representa una vulnerabilidad como un conjunto de números, cada uno de los cuales es una puntuación para una característica, por ejemplo:
- ¿Qué tan fácil es reproducir (usar)?
- Qué difícil es arreglarlo.
- La escala del impacto en la disponibilidad de servidores y servicios.
- Importancia o confidencialidad de los datos abiertos.
El conjunto completo incluye muchas más evaluaciones similares. El algoritmo los combina en una puntuación de referencia , un número ordenado que representa la gravedad de la vulnerabilidad, que va de 0 (bajo) a 10 (alto). CVSS de la segunda versión divide los rangos de estos números en las palabras clave LOW, MEDIUM y HIGH. La nueva versión de CVSS 3 agrega dos más: NINGUNO y CRÍTICO.
Por lo tanto, el número de vulnerabilidades varía no solo por meses y años, sino también por gravedad.
Los esquemas de clasificación de vulnerabilidades como CVSS permiten a los proveedores de Linux evaluar cómo responder a una vulnerabilidad específica del kernel. Por ejemplo, es posible que quieran escribir parches para vulnerabilidades con una puntuación acumulada de 7 o más. Esto significa ALTO en CVSS v2, ALTO o CRÍTICO en CVSS v3. Un proveedor que afirma apuntar a vulnerabilidades críticas solo puede referirse a vulnerabilidades con calificaciones de gravedad 9 y 10 cuando usa CVSS v3.
4. ¿Puedo revertir un parche?
Instalar parches automáticamente sin supervisión es una idea terrible para muchos administradores de sistemas. Saben que incluso las correcciones probadas minuciosamente pueden cambiar el comportamiento de un sistema, afectando su rendimiento o funcionalidad de una manera sutil y no del todo obvia. Cuando esto sucede, cuando el servidor se comporta de manera extraña después de instalar el parche, la forma más rápida de solucionarlo es eliminar el parche.
Algunos servicios de parcheo en tiempo real pueden eliminar los parches. Esto hace que sea más fácil determinar si una actualización reciente está provocando un cambio en el comportamiento del sistema.
5. ¿Puedo alojar mi propio servidor de parches?
El agente de software de parcheo comprueba en tiempo real los parches disponibles en los servidores remotos de parches. Lo hace a intervalos regulares configurables, generalmente con la capacidad de realizar comprobaciones personalizadas. Si hay un parche disponible, el software del agente lo descargará e instalará. Pero si el agente de parcheo no puede comunicarse con el servidor de parches donde el servicio de parcheo del proveedor almacena los parches, el parche en vivo no sucederá.
Para resolver este problema, debe crear su propio servidor de parches. Este servidor local transmite parches a todas las computadoras de su empresa bajo su firewall. Copy Safe descarga el parche y luego lo distribuye a través del firewall después de verificar la integridad de los archivos del parche. Puede administrar y auditar este proceso a su conveniencia haciendo que el directorio de su empresa sea un poco más relajado.
Hay otros beneficios tambien:
- Tiene un mejor control sobre qué parches reciben sus servidores y cuándo.
- Puede bloquear una gran cantidad de servidores para niveles de parche conocidos.
- Es más fácil separar los clústeres de servidores para el desarrollo, las pruebas, la puesta en escena y la producción.
El parche dinámico requiere un agente local y un servidor de parche remoto. Controlar ambos es fundamental para las implementaciones empresariales.
Conclusión
Antes de despertar, aquí hay tres preguntas adicionales para hacerle a un posible proveedor de soluciones de parcheo:
- ¿Puedo cancelar la renovación automática? Hay ocasiones en las que no desea actualizar los núcleos automáticamente.
- ¿En qué plataformas funciona? Si bien su entorno de servidor puede excluir cualquier flexibilidad para elegir una solución de parcheo en tiempo real, es mejor si la suscripción al servicio no limita qué variante de Linux necesita usar.
- ? , Linux. . , .
El hecho de que sean menos prominentes en la aplicación de parches a las descripciones de los productos de los proveedores no hace que las características descritas en este artículo sean menos importantes. Cualquiera de estos puede influir en su decisión de ponerse en contacto con un proveedor específico. Cada uno de estos puede afectar directamente la efectividad y relevancia de la solución para su entorno. Dado que las tarifas de suscripción al servidor varían desde unas pocas decenas por mes hasta miles de dólares estadounidenses por año, es útil tener cuidado al elegir una solución de parcheo del kernel de Linux.
Lee mas:
Instale y configure AlienVault SIEM (OSSIM)
10 mejores prácticas para proteger las imágenes de Docker. Parte 1
10 mejores prácticas para proteger las imágenes de Docker. Parte 2