Projet à mur ouvert version du module du noyau (Linux Kernel Runtime Guard), conçu pour détecter et bloquer les attaques et les violations de l'intégrité des structures du noyau. Par exemple, le module peut protéger contre les modifications non autorisées du noyau en cours d'exécution et les tentatives de modification des autorisations des processus utilisateur (détection de l'utilisation d'exploits). Le module convient à la fois pour organiser la protection contre les exploits déjà connus du noyau Linux (par exemple, dans les situations où il est difficile de mettre à jour le noyau dans le système) et pour contrer les exploits pour des vulnérabilités encore inconnues. Code de projet sous licence GPLv2.
Parmi les changements de la nouvelle version :
- Le positionnement du projet LKRG a été modifié, qui n'est plus divisé en sous-systèmes distincts pour vérifier l'intégrité et déterminer l'utilisation des exploits, mais se présente comme un produit complet pour identifier les attaques et diverses violations d'intégrité ;
- La compatibilité est assurée avec les noyaux Linux de 5.3 à 5.7, ainsi qu'avec les noyaux compilés avec des optimisations GCC agressives, sans les options CONFIG_USB et CONFIG_STACKTRACE ou avec l'option CONFIG_UNWINDER_ORC, ainsi qu'avec les noyaux ne disposant pas de fonctions accrochées LKRG, s'ils le peuvent. être supprimé ;
- Lors de la construction, certains paramètres obligatoires du noyau CONFIG_* sont vérifiés pour générer des messages d'erreur significatifs au lieu d'obscurs crashs ;
- Ajout de la prise en charge des modes veille (ACPI S3, suspension sur RAM) et veille (S4, suspension sur disque) ;
- Ajout du support DKMS à Makefile ;
- La prise en charge expérimentale des plates-formes ARM 32 bits a été implémentée (testée sur Raspberry Pi 3 modèle B). La prise en charge d'AArch64 (ARM64), précédemment disponible, a été étendue pour assurer la compatibilité avec la carte Raspberry Pi 4 ;
- De nouveaux hooks ont été ajoutés, notamment un gestionnaire d'appel capable() pour mieux identifier les exploits qui manipulent "", pas les identifiants de processus ();
- Une nouvelle logique a été proposée pour détecter les tentatives d'évasion des restrictions d'espace de noms (par exemple, à partir de conteneurs Docker) ;
- Sur les systèmes x86-64, le bit SMAP (Supervisor Mode Access Prevention) est vérifié et appliqué, conçu pour bloquer l'accès aux données de l'espace utilisateur à partir du code privilégié exécuté au niveau du noyau. La protection SMEP (Supervisor Mode Execution Prevention) a été mise en œuvre précédemment ;
- Pendant le fonctionnement, les paramètres LKRG sont placés dans une page mémoire généralement en lecture seule ;
- Les informations de journalisation qui peuvent être les plus utiles pour les attaques (par exemple, les informations sur les adresses dans le noyau) sont limitées au mode de débogage (log_level=4 et supérieur), qui est désactivé par défaut.
- L'évolutivité de la base de données de suivi des processus a été augmentée : au lieu d'une arborescence RB protégée par un verrou tournant, une table de hachage de 512 arborescences RB protégées par 512 verrous en lecture-écriture est utilisée ;
- Un mode a été implémenté et activé par défaut, dans lequel l'intégrité des identifiants de processus est souvent vérifiée uniquement pour la tâche en cours, et aussi éventuellement pour les tâches activées (réveil). Pour les autres tâches qui sont en état de veille ou qui fonctionnent sans accéder à l'API du noyau contrôlée par LKRG, la vérification est effectuée moins fréquemment.
- Ajout de nouveaux paramètres sysctl et module pour affiner LKRG, ainsi que deux sysctl pour une configuration simplifiée en sélectionnant parmi des ensembles de paramètres de réglage fin (profils) préparés par les développeurs ;
- Les paramètres par défaut ont été modifiés pour atteindre un équilibre plus équilibré entre la rapidité de détection des violations et l'efficacité de la réponse, d'une part, et l'impact sur les performances et le risque de faux positifs, d'autre part ;
- Le fichier d'unité systemd a été repensé pour charger le module LKRG au début du démarrage (une option de ligne de commande du noyau peut être utilisée pour désactiver le module) ;
Compte tenu des optimisations proposées dans la nouvelle version, la réduction des performances lors de l'utilisation de LKRG 0.8 est estimée à 2.5% en mode par défaut («lourd») et 2% en mode léger («léger»).
Lors d'une réunion récemment organisée efficacité des packages de détection des rootkits LKRG meilleurs résultats, identifiant 8 des 9 rootkits testés fonctionnant au niveau du noyau sans faux positifs (les rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit et Sutekh ont été identifiés, mais Keysniffer, qui est un noyau module, a été manqué avec un keylogger, pas un rootkit au sens littéral). À titre de comparaison, les packages AIDE, OSSEC et Rootkit Hunter ont détecté 2 rootkits sur 9, tandis que Chkrootkit n'en a détecté aucun. Dans le même temps, LKRG ne prend pas en charge la détection des rootkits situés dans l'espace utilisateur, donc la plus grande efficacité est obtenue en utilisant une combinaison d'AIDE et de LKRG, qui a permis d'identifier 14 rootkits sur 15 de tous types.
De plus, on peut noter que le développeur de la distribution commencé des packages prêts à l'emploi avec DKMS pour Debian, Whonix, Qubes et Kicksecure, et un package pour déjà mis à jour vers la version 0.8. Les forfaits avec LKRG sont également disponibles en russe и .
La vérification de l'intégrité dans LKRG est effectuée en comparant le code et les données réels du noyau et des modules, certaines structures de données importantes et paramètres du processeur avec des hachages stockés ou des copies des zones de mémoire, des structures de données ou des registres correspondants. Les contrôles sont activés à la fois périodiquement par minuterie et lors de l'apparition de divers événements.
La détermination de l'utilisation possible d'exploits et du blocage des attaques est effectuée avant que le noyau ne donne accès aux ressources (par exemple, avant d'ouvrir un fichier), mais après que le processus a reçu des autorisations non autorisées (par exemple, en modifiant l'UID). Lorsqu’un comportement non autorisé est détecté, les processus sont forcés de s’arrêter par défaut, ce qui suffit à bloquer de nombreux exploits.
Source: opennet.ru