Proxecto Openwall liberación do módulo do núcleo (Linux Kernel Runtime Guard, deseñado para detectar e bloquear ataques e violacións da integridade da estrutura do kernel. Por exemplo, o módulo pode protexer contra modificacións non autorizadas no kernel en execución e intentos de cambiar os privilexios dos procesos do usuario (detección de vulnerabilidades). O módulo é axeitado tanto para protexer contra vulnerabilidades coñecidas do kernel Linux (por exemplo, en situacións nas que a actualización do kernel do sistema é problemática), así como para contrarrestar exploits de vulnerabilidades aínda descoñecidas. Código do proxecto licenciado baixo GPLv2.
Entre os cambios na nova versión:
- Cambiouse o posicionamento do proxecto LKRG, que xa non está dividido en subsistemas separados para comprobar a integridade e determinar o uso de exploits, senón que se presenta como un produto completo para identificar ataques e varias violacións de integridade;
- A compatibilidade cos núcleos está garantida Linux de 5.3 a 5.7, así como núcleos compilados con optimizacións GCC agresivas, sen as opcións CONFIG_USB e CONFIG_STACKTRACE ou coa opción CONFIG_UNWINDER_ORC, así como núcleos que carecen de funcións interceptadas por LKRG se se poden evitar;
- Ao construír, compróbanse algunhas configuracións obrigatorias do núcleo CONFIG_* para xerar mensaxes de erro significativas en lugar de fallas escuras;
- Engadido soporte para os modos de espera (ACPI S3, suspender a RAM) e de suspensión (S4, suspender a disco);
- Engadido soporte DKMS a Makefile;
- Implementouse soporte experimental para plataformas ARM de 32 bits (probado en Raspberry Pi 3 Modelo B). O soporte AArch64 (ARM64) dispoñible anteriormente ampliouse para ofrecer compatibilidade coa placa Raspberry Pi 4;
- Engadíronse novos ganchos, incluíndo un manejador de chamadas capable() para identificar mellor os exploits que manipulan "", non os ID de proceso ();
- Propúxose unha nova lóxica para detectar intentos de escapar das restricións do espazo de nomes (por exemplo, desde os contedores Docker);
- Nos sistemas x86-64, compróbase e aplícase o bit SMAP (Prevención de acceso ao modo de supervisor), deseñado para bloquear o acceso aos datos do espazo do usuario desde o código privilexiado que se executa no nivel do núcleo. A protección SMEP (Supervisor Mode Execution Prevention) implementouse anteriormente;
- Durante o funcionamento, os axustes de LKRG colócanse nunha páxina de memoria que adoita ser de só lectura;
- A información de rexistro que pode ser máis útil para ataques (por exemplo, información sobre enderezos no núcleo) está limitada ao modo de depuración (log_level=4 e superior), que está desactivado por defecto.
- Aumentouse a escalabilidade da base de datos de seguimento de procesos: en lugar dunha árbore RB protexida por un spinlock, utilízase unha táboa hash de 512 árbores RB protexidas por 512 bloqueos de lectura-escritura;
- Implementouse e habilitouse un modo por defecto, no que a integridade dos identificadores do proceso adoita comprobarse só para a tarefa actual, e tamén opcionalmente para as tarefas activadas (despertar). Para outras tarefas que están en estado de suspensión ou funcionan sen acceder á API do núcleo controlada por LKRG, a comprobación realízase con menos frecuencia.
- Engadíronse novos parámetros sysctl e módulo para axustar LKRG, así como dous sysctl para simplificar a configuración seleccionando entre conxuntos de configuracións de axuste fino (perfís) preparados polos desenvolvedores;
- Modificouse a configuración predeterminada para conseguir un equilibrio máis equilibrado entre a velocidade de detección de infraccións e a eficacia da resposta, por unha banda, e o impacto no rendemento e o risco de falsos positivos, por outra;
- O ficheiro da unidade systemd foi redeseñado para cargar o módulo LKRG no inicio do arranque (pódese usar unha opción de liña de comandos do núcleo para desactivar o módulo);
Tendo en conta as optimizacións propostas na nova versión, a redución de rendemento ao usar LKRG 0.8 estímase nun 2.5% no modo predeterminado ("pesado") e nun 2% no modo lixeiro ("lixeiro").
Nunha celebrada recentemente eficacia dos paquetes para detectar rootkits LKRG Os mellores resultados, sen falsos positivos, identificaron 8 de 9 rootkits probados que operaban a nivel de kernel (detectáronse rootkits: Dimorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Detectáronse rootkit e Sutekh, pero Keysniffer, que é un módulo do núcleo cun rexistrador de teclas e non un rootkit no sentido estrito do termo, non se detectou. En comparación, os paquetes AIDE, OSSEC e Rootkit Hunter detectaron dous de nove rootkits, mentres que Chkrootkit non detectou ningún. Non obstante, LKRG non admite a detección de rootkits no espazo de usuario, polo que a combinación de AIDE e LKRG foi a máis eficaz, detectando 14 de 15 rootkits de todo tipo.
Ademais, pódese notar que o desenvolvedor da distribución comezou paquetes preconfeccionados con DKMS para Debian, Whonix, Qubes e Kicksecure, e un paquete para xa actualizado á versión 0.8. Os paquetes con LKRG tamén están dispoñibles en ruso и .
A verificación de integridade en LKRG realízase comparando o código e os datos reais do núcleo e dos módulos, algunhas estruturas de datos importantes e a configuración da CPU con hash almacenados ou copias das áreas de memoria, estruturas de datos ou rexistros correspondentes. As comprobacións actívanse periódicamente polo temporizador e cando se producen varios eventos.
A determinación do posible uso de exploits e o bloqueo de ataques realízase na fase anterior ao que o núcleo ofreza acceso aos recursos (por exemplo, antes de abrir un ficheiro), pero despois de que o proceso recibiu permisos non autorizados (por exemplo, cambiando o UID). Cando se detecta un comportamento non autorizado, os procesos vense obrigados a finalizar por defecto, o que é suficiente para bloquear moitos exploits.
Fonte: opennet.ru
