Projeto Parede Aberta lançamento do módulo do kernel (Linux Kernel Runtime Guard), projetado para detectar e bloquear ataques e violações da integridade das estruturas do kernel. Por exemplo, o módulo pode proteger contra alterações não autorizadas no kernel em execução e tentativas de alterar as permissões dos processos do usuário (detectando o uso de explorações). O módulo é adequado tanto para organizar a proteção contra explorações já conhecidas do kernel Linux (por exemplo, em situações em que é difícil atualizar o kernel no sistema) quanto para combater explorações de vulnerabilidades ainda desconhecidas. Código do projeto licenciado sob GPLv2.
Entre as mudanças na nova versão:
- Foi alterado o posicionamento do projeto LKRG, que não está mais dividido em subsistemas separados para verificação de integridade e determinação do uso de exploits, mas se apresenta como um produto completo para identificação de ataques e diversas violações de integridade;
- A compatibilidade é fornecida com kernels Linux de 5.3 a 5.7, bem como com kernels compilados com otimizações agressivas do GCC, sem as opções CONFIG_USB e CONFIG_STACKTRACE ou com a opção CONFIG_UNWINDER_ORC, bem como com kernels que não possuem funções de gancho LKRG, se puderem ser dispensado;
- Ao compilar, algumas configurações obrigatórias do kernel CONFIG_* são verificadas para gerar mensagens de erro significativas em vez de travamentos obscuros;
- Adicionado suporte para modos de espera (ACPI S3, suspensão para RAM) e suspensão (S4, suspensão para disco);
- Adicionado suporte DKMS ao Makefile;
- Foi implementado suporte experimental para plataformas ARM de 32 bits (testado no Raspberry Pi 3 Modelo B). O suporte AArch64 (ARM64) anteriormente disponível foi expandido para fornecer compatibilidade com a placa Raspberry Pi 4;
- Novos ganchos foram adicionados, incluindo um manipulador de chamadas capaz() para melhor identificar explorações que manipulam "", não processa IDs ();
- Uma nova lógica foi proposta para detectar tentativas de escapar das restrições de namespace (por exemplo, de contêineres Docker);
- Em sistemas x86-64, o bit SMAP (Supervisor Mode Access Prevention) é verificado e aplicado, projetado para bloquear o acesso aos dados do espaço do usuário de código privilegiado em execução no nível do kernel. A proteção SMEP (Supervisor Mode Execution Prevention) foi implementada anteriormente;
- Durante a operação, as configurações do LKRG são colocadas em uma página de memória que geralmente é somente leitura;
- As informações de registro que podem ser mais úteis para ataques (por exemplo, informações sobre endereços no kernel) são limitadas ao modo de depuração (log_level=4 e superior), que está desabilitado por padrão.
- A escalabilidade do banco de dados de rastreamento de processos foi aumentada - em vez de uma árvore RB protegida por um spinlock, é usada uma tabela hash de 512 árvores RB protegidas por 512 bloqueios de leitura e gravação;
- Um modo foi implementado e habilitado por padrão, no qual a integridade dos identificadores de processo é frequentemente verificada apenas para a tarefa atual e também opcionalmente para tarefas ativadas (despertar). Para outras tarefas que estão em estado de suspensão ou funcionando sem acessar a API do kernel controlada pelo LKRG, a verificação é realizada com menos frequência.
- Adicionados novos parâmetros sysctl e módulo para ajuste fino do LKRG, bem como dois sysctl para configuração simplificada selecionando entre conjuntos de configurações de ajuste fino (perfis) preparados pelos desenvolvedores;
- As configurações padrão foram alteradas para alcançar um equilíbrio mais equilibrado entre a velocidade de detecção de violações e a eficácia da resposta, por um lado, e o impacto no desempenho e o risco de falsos positivos, por outro;
- O arquivo da unidade systemd foi redesenhado para carregar o módulo LKRG no início da inicialização (uma opção de linha de comando do kernel pode ser usada para desabilitar o módulo);
Levando em consideração as otimizações propostas na nova versão, a redução de desempenho ao utilizar o LKRG 0.8 é estimada em 2.5% no modo padrão (“pesado”) e 2% no modo light (“light”).
Em um evento realizado recentemente eficácia dos pacotes para detecção de rootkits LKRG melhores resultados, identificando 8 de 9 rootkits testados trabalhando no nível do kernel sem falsos positivos (rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit e Sutekh foram identificados, mas Keysniffer, que é um kernel módulo, foi perdido com um keylogger, não com um rootkit no sentido literal). Para efeito de comparação, os pacotes AIDE, OSSEC e Rootkit Hunter detectaram 2 de 9 rootkits, enquanto o Chkrootkit não detectou nenhum. Ao mesmo tempo, o LKRG não suporta a detecção de rootkits localizados no espaço do usuário, portanto a maior eficiência é alcançada ao utilizar uma combinação de AIDE e LKRG, que permitiu identificar 14 dos 15 rootkits de todos os tipos.
Além disso, pode-se notar que o desenvolvedor da distribuição começado pacotes prontos com DKMS para Debian, Whonix, Qubes e Kicksecure, e um pacote para já atualizado para a versão 0.8. Pacotes com LKRG também estão disponíveis em russo и .
A verificação de integridade no LKRG é realizada comparando o código e os dados reais do kernel e dos módulos, algumas estruturas de dados importantes e configurações da CPU com hashes armazenados ou cópias das áreas de memória, estruturas de dados ou registros correspondentes. As verificações são ativadas periodicamente por temporizador e na ocorrência de diversos eventos.
A determinação do possível uso de explorações e ataques de bloqueio é realizada antes do kernel fornecer acesso aos recursos (por exemplo, antes de abrir um arquivo), mas após o processo ter recebido permissões não autorizadas (por exemplo, alterar o UID). Quando um comportamento não autorizado é detectado, os processos são forçados a encerrar por padrão, o que é suficiente para bloquear muitas explorações.
Fonte: opennet.ru