ClickCease SACK Pánico y Lentitud: Ya están aquí los parches Live de KernelCare - TuxCare

Únase a nuestro popular boletín

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.

SACK Pánico y Lentitud: Ya están aquí los parches KernelCare Live

24 de junio de 2019 - Equipo de relaciones públicas de TuxCare

Kernel Care-03 (2)

Recientemente, el tipo equivocado de Netflix Original se reveló al público. El gigante del streaming anunció que había descubierto cuatro nuevas vulnerabilidades de denegación de servicio (DoS) y consumo de recursos que afectaban a servidores Linux y FreeBSD. Netflix ofreció todos los detalles en un aviso publicado en GitHub. Las vulnerabilidades amenazan a cualquier empresa que ejecute grandes flotas de ordenadores Linux de producción.

En el mejor de los casos: Ralentización

Todas las vulnerabilidades que amenazan a Linux aprovechan la función TCP Selective Acknowledgement del kernel (de ahí "TCP SACK"). Dos de las vulnerabilidades - CVE-2019-11478, y CVE-2019-11479 - hacen que la cola de retransmisión TCP se fragmente tanto que el kernel gasta excesivos recursos gestionando los elementos SACK de esa conexión TCP. Aunque esto no es desastroso, podría causar una ralentización significativa de la CPU. CVE-2019-11478 afecta a todos los kernels anteriores a 4.15; CVE-2019-11479 afecta a todas las versiones de Linux desde 2.6.29.

El peor escenario posible: Catástrofe

La tercera vulnerabilidad - CVE-2019-11477 - ha sido acertadamente apodada "SACK Panic". Afectando a todos los kernels 2.6.29 y posteriores, SACK Panic es una vulnerabilidad de desbordamiento de enteros que explota la función TCP Selective ACKnowledgement del kernel ajustando los valores del MSS (Maximum Segment Size). Una secuencia particular de paquetes puede inducir un kernel panic.

Al igual que las vulnerabilidades de lentitud, SACK Panic es especialmente preocupante porque puede desencadenarse de forma remota. Los actores maliciosos pueden desencadenar un pánico total, que puede bloquear completamente un sistema operativo, forzando el reinicio de un host y causando un cierre temporal de los servicios. Esto significa la caída de servidores, la interrupción de las comunicaciones y el riesgo de graves pérdidas de datos. Son muy malas noticias para los servicios que utilizan sistemas basados en Linux para prestar servicios en línea.

Por si fuera poco: SACK Panic afecta a todos los núcleos 2.6.29 y posteriores.

Obtenga una prueba GRATUITA de 7 días con soporte de KernelCare 

 

Proteja sus núcleos y sus dispositivos IoT, sin reiniciar

Los parches en vivo SACK Panic & Slowness de KernelCare, incluyendo el importantísimo PATCH_net_1_4.patchPATCH_net_1a.patch, están aquí para todas las distribuciones soportadas excepto UEK (que está en progreso ahora mismo). Y con una vulnerabilidad tan grave como SACK Panic, querrá parchearla lo antes posible. Sí, hay algunas soluciones para los archivos de configuración, pero están lejos de ser seguras.

Sin embargo, si vas a reiniciar para aplicar parches, esto supone un serio quebradero de cabeza. Reiniciar los servidores es un gran inconveniente; no puedes hacerlo sin planificarlo de antemano, y es muy tentador retrasarlo todo lo posible. (Esto es especialmente cierto en el caso de los dispositivos IoT, que pueden ser difíciles y llevar mucho tiempo parchear). Esto significa que cada vez que aparece una vulnerabilidad, te enfrentas a una disyuntiva: la molestia de reiniciar tu flota de servidores, o el riesgo de retrasar ese reinicio hasta la medianoche del sábado, cuando el tiempo de inactividad será el menos problemático.

Además, retrasar sus reinicios no sólo le hace inseguro: le hace incumplidor. Las pólizas de seguro de errores y omisiones (E&O) de la mayoría de las empresas, así como las cláusulas de sus contratos SLA, exigen el cumplimiento de las mejores prácticas de aplicación de parches. Normalmente, esto equivale a un intervalo entre la emisión del parche y su aplicación no superior a 30 días. Pero muchas empresas todavía tienden a planificar sus ciclos de reinicio en términos de meses o trimestres, lo que las sitúa en una violación perpetua de sus pólizas de seguros. Cuanto antes se parchee, antes se estará protegido y más se cumplirá la normativa.

Este fin de semana, los usuarios de KernelCare han recibido parches que se han aplicado automáticamente, sin necesidad de reiniciar el sistema. La próxima vez que aparezca una CVE peligrosa, no hay necesidad de enfrentarse a la molestia de reiniciar sus servidores. No hay necesidad de incumplir las normas de seguridad del sector. Live-patch con KernelCare, y usted estará totalmente protegido sin tener que mover un dedo.

Obtenga una prueba GRATUITA de 7 días con soporte de KernelCare 

 

Más información:

¿Desea automatizar la aplicación de parches de vulnerabilidad sin reiniciar el núcleo, dejar el sistema fuera de servicio o programar ventanas de mantenimiento?

Más información sobre Live Patching con TuxCare

Conviértete en escritor invitado de TuxCare

Empezar

Correo

Únete a

4,500

Profesionales de Linux y código abierto

Suscríbase a
nuestro boletín