Proyecto de pared abierta lanzamiento del módulo del kernel (Linux Kernel Runtime Guard), diseñado para detectar y bloquear ataques y violaciones de la integridad de las estructuras del kernel. Por ejemplo, el módulo puede proteger contra cambios no autorizados en el kernel en ejecución e intentos de cambiar los permisos de los procesos del usuario (detectando el uso de exploits). El módulo es adecuado tanto para organizar la protección contra exploits ya conocidos del kernel de Linux (por ejemplo, en situaciones en las que es difícil actualizar el kernel en el sistema) como para contrarrestar exploits para vulnerabilidades aún desconocidas. Código de proyecto licenciado bajo GPLv2.
Entre los cambios de la nueva versión:
- Se ha cambiado el posicionamiento del proyecto LKRG, que ya no se divide en subsistemas separados para verificar la integridad y determinar el uso de exploits, sino que se presenta como un producto completo para identificar ataques y diversas violaciones de integridad;
- Se proporciona compatibilidad con kernels de Linux desde 5.3 a 5.7, así como con kernels compilados con optimizaciones GCC agresivas, sin las opciones CONFIG_USB y CONFIG_STACKTRACE o con la opción CONFIG_UNWINDER_ORC, así como con kernels que no tienen funciones enganchadas LKRG, si pueden. ser prescindido;
- Al compilar, se verifican algunas configuraciones obligatorias del kernel CONFIG_* para generar mensajes de error significativos en lugar de fallas oscuras;
- Se agregó soporte para los modos de espera (ACPI S3, suspensión en RAM) y suspensión (S4, suspensión en disco);
- Se agregó soporte DKMS a Makefile;
- Se implementó soporte experimental para plataformas ARM de 32 bits (probado en Raspberry Pi 3 Modelo B). La compatibilidad con AArch64 (ARM64) disponible anteriormente se ha ampliado para brindar compatibilidad con la placa Raspberry Pi 4;
- Se han agregado nuevos enlaces, incluido un controlador de llamadas capaz() para identificar mejor los exploits que manipulan "", no ID de proceso ();
- Se ha propuesto una nueva lógica para detectar intentos de escapar de las restricciones del espacio de nombres (por ejemplo, desde contenedores Docker);
- En los sistemas x86-64, se verifica y aplica el bit SMAP (Prevención de acceso en modo supervisor), diseñado para bloquear el acceso a los datos del espacio del usuario desde el código privilegiado que se ejecuta en el nivel del kernel. La protección SMEP (Prevención de ejecución del modo supervisor) se implementó anteriormente;
- Durante la operación, las configuraciones de LKRG se colocan en una página de memoria que generalmente es de solo lectura;
- La información de registro que puede ser más útil para ataques (por ejemplo, información sobre direcciones en el kernel) se limita al modo de depuración (log_level=4 y superior), que está deshabilitado de forma predeterminada.
- Se ha aumentado la escalabilidad de la base de datos de seguimiento de procesos: en lugar de un árbol RB protegido por un spinlock, se utiliza una tabla hash de 512 árboles RB protegidos por 512 bloqueos de lectura y escritura;
- Se ha implementado y habilitado un modo de forma predeterminada, en el que la integridad de los identificadores de proceso a menudo se verifica solo para la tarea actual y, opcionalmente, también para las tareas activadas (de activación). Para otras tareas que están en estado de suspensión o que funcionan sin acceder a la API del kernel controlada por LKRG, la verificación se realiza con menos frecuencia.
- Se agregaron nuevos parámetros sysctl y módulo para ajustar LKRG, así como dos sysctl para una configuración simplificada seleccionando entre conjuntos de configuraciones de ajuste fino (perfiles) preparados por los desarrolladores;
- Se han cambiado los ajustes predeterminados para lograr un equilibrio más equilibrado entre la velocidad de detección de infracciones y la eficacia de la respuesta, por un lado, y el impacto en el rendimiento y el riesgo de falsos positivos, por el otro;
- El archivo de unidad systemd ha sido rediseñado para cargar el módulo LKRG en las primeras etapas del arranque (se puede usar una opción de línea de comando del kernel para deshabilitar el módulo);
Teniendo en cuenta las optimizaciones propuestas en la nueva versión, la reducción de rendimiento al utilizar LKRG 0.8 se estima en un 2.5% en modo predeterminado ("pesado") y un 2% en modo ligero ("ligero").
En una reciente celebración efectividad de los paquetes para detectar rootkits LKRG mejores resultados, identificando 8 de 9 rootkits probados que funcionan a nivel de kernel sin falsos positivos (se identificaron los rootkits Dimorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit y Sutekh, pero Keysniffer, que es un kernel módulo, se perdió con un keylogger, no con un rootkit en el sentido literal). A modo de comparación, los paquetes AIDE, OSSEC y Rootkit Hunter detectaron 2 de 9 rootkits, mientras que Chkrootkit no detectó ninguno. Al mismo tiempo, LKRG no admite la detección de rootkits ubicados en el espacio del usuario, por lo que la mayor eficiencia se logra cuando se utiliza una combinación de AIDE y LKRG, que permitió identificar 14 de 15 rootkits de todo tipo.
Además, se puede observar que el desarrollador de la distribución comenzar paquetes listos para usar con DKMS para Debian, Whonix, Qubes y Kicksecure, y un paquete para ya actualizado a la versión 0.8. Los paquetes con LKRG también están disponibles en ruso и .
La verificación de integridad en LKRG se realiza comparando el código y los datos reales del kernel y los módulos, algunas estructuras de datos importantes y configuraciones de la CPU con hashes almacenados o copias de las áreas de memoria, estructuras de datos o registros correspondientes. Los controles se activan tanto periódicamente mediante un temporizador como cuando ocurren varios eventos.
La determinación del posible uso de exploits y el bloqueo de ataques se lleva a cabo en la etapa anterior a que el kernel proporcione acceso a los recursos (por ejemplo, antes de abrir un archivo), pero después de que el proceso haya recibido permisos no autorizados (por ejemplo, cambiando el UID). Cuando se detecta un comportamiento no autorizado, los procesos se ven obligados a finalizar de forma predeterminada, lo que es suficiente para bloquear muchos exploits.
Fuente: opennet.ru