Dans cet article, vous apprendrez ce qu'est le correctif en direct du noyau Linux, comment il garantit la disponibilité, quels 5 outils sont disponibles pour vous aider à faire fonctionner des serveurs pendant des années - sans redémarrage et quels sont les avantages et les inconvénients de chaque outil.
Au sein des organisations informatiques, il existe des processus et des pratiques si routiniers qu'ils sont invisibles. Peu importe si ces processus et pratiques sont défectueux ou s'il existe une meilleure solution :si quelque chose a fonctionné pendant quelques années, les gens arrêtent de chercher des alternatives. Cela décrit parfaitement les approches actuelles de correction du noyau .
À l'heure actuelle, la plupart des entreprises corrigent les serveurs en planifiant des cycles de redémarrage. Parce que le redémarrage de la flotte de serveurs est un casse-tête qui provoque des temps d'arrêt, les gens le repoussent aussi longtemps qu'ils le peuvent. Ce qui signifie que les correctifs ne sont pas appliqués le plus tôt possible. Cet écart entre le problème du correctif et son application est synonyme de risque, de faute professionnelle et peut entraîner une non-conformité.
Cette approche standard des correctifs du noyau expose les serveurs aux intentions malveillantes des acteurs de la menace sur plusieurs vecteurs d'attaque, exposant les organisations informatiques à des problèmes de sécurité majeurs. Toute personne chargée de protéger son organisation contre les cyberattaques devrait rechercher un meilleur moyen d'exécuter des serveurs Linux sans redémarrage (idéalement, pendant des années).
Pourquoi le patch en direct existe-t-il ?
En 2009, un étudiant du MIT administrant un serveur Web a retardé l'application d'un correctif au noyau Linux du serveur, car l'application du correctif aurait impliqué un redémarrage gênant ses utilisateurs. Pendant le retard, le serveur a été piraté. Cela a inspiré l'étudiant, Jeff Arnold , pour essayer de développer un moyen de patcher un noyau Linux sans redémarrer le serveur.
Il a fait équipe avec trois autres étudiants pour développer Ksplice , le premier outil logiciel « sans redémarrage » pour corriger les noyaux Linux. Ils ont formé une société pour promouvoir leur nouveau produit, qui a été acquis par Oracle. Lorsqu'Oracle a intégré Ksplice à sa propre distribution, Oracle Linux, d'autres fournisseurs Linux ont commencé à travailler sur leurs propres systèmes de correctifs en direct.
En effet, l'application de correctifs en direct (application de correctifs de sécurité à un serveur en cours d'exécution, sans redémarrage nécessaire) offre des fonctionnalités précieuses aux organisations qui gèrent plusieurs serveurs :
- Fonctionnement continu des serveurs, sans redémarrage. Cela signifie peu ou pas de temps d'arrêt.
- Automatisation des tâches liées aux correctifs. Cela permet au personnel d'assistance de se consacrer à d'autres tâches.
- Application immédiate des nouveaux correctifs. Cela réduit considérablement les vulnérabilités du serveur.
Fonctionnement des correctifs Linux Kernel Live
Il existe deux méthodes de base pour patcher en direct un noyau Linux :temporaire et persistant . La méthode temporaire applique un correctif sans redémarrage, mais nécessite en fait un redémarrage ultérieur du serveur. Les correctifs en direct persistants ne nécessitent aucun redémarrage.
La méthode temporaire
La méthode temporaire de correctifs en direct nécessite l'installation d'un logiciel de gestion de packages (tel que le plug-in YUM) sur le serveur. Lorsque les correctifs sont livrés aux référentiels, ils sont appliqués conformément aux workflows de mise à jour spécifiés par l'utilisateur.
Cette méthode est incluse avec certaines distributions de système d'exploitation Linux et avec les contrats de support de certains fournisseurs. Cependant, cela ne doit pas être considéré comme gratuit ou peu coûteux, car cela implique des coûts en temps et des problèmes qui ne sont pas apparents à l'avance.
La méthode temporaire, également appelée patch "stack", implique des redémarrages et des temps d'arrêt du serveur. En effet, les correctifs temporaires s'accumulent les uns sur les autres au fil du temps, dégradant les performances et la stabilité. La seule solution à ce problème est de redémarrer le serveur pour charger un nouveau noyau en mémoire.
La méthode persistante
Avec la méthode persistante de correctifs en direct, un serveur de correctifs dédié stocke les derniers correctifs. Ces correctifs sont « monolithiques », et non temporaires, car ils intègrent des correctifs antérieurs. Sur les serveurs Web à corriger, un programme agent s'exécute en arrière-plan, vérifiant périodiquement la présence de correctifs sur le serveur de correctifs. À la demande de l'agent, un module du noyau exécute le correctif.
Cette méthode implique des frais de licence fournisseur, mais ces frais peuvent être étonnamment bas. De plus, en remplaçant le travail manuel par des processus automatisés, la méthode persistante réduit le temps et les efforts nécessaires pour administrer les serveurs. Plus important encore, comme il n'implique aucun redémarrage, il permet aux serveurs de rester opérationnels, parfois pendant des années.
L'application permanente de correctifs en direct offre également d'autres avantages importants. Même avec des vulnérabilités matérielles qui nécessitent généralement des redémarrages pour être résolues, telles que Spectre , effondrement , et Zombieload , les serveurs utilisant la méthode persistante restent opérationnels. En outre, il fonctionne avec des scanners de vulnérabilité, ce qui est important pour la conformité aux normes de sécurité telles que SOC2.
Suggestion de lecture :
- Comment vérifier les vulnérabilités Meltdown et Spectre et les corriger sous Linux
5 systèmes de correctifs en direct du noyau Linux qui aideront à exécuter des serveurs Linux sans redémarrage
Il existe plusieurs systèmes de correctifs dynamiques du noyau disponibles auprès de différents fournisseurs, dont la plupart sont destinés à être utilisés avec une distribution Linux spécifique :
Oracle Ksplice
Ksplice est le système original de correctifs du noyau Linux "sans redémarrage", créé en 2009 et acquis par Oracle en 2011. Il fonctionne désormais uniquement avec Oracle Linux et RHEL avec une licence Oracle. Il manque une fonction de planification, mais effectue des mises à jour automatiques des correctifs sans redémarrage requis.
RedHat Kpatch
Kpatch a été créé par Red Hat pour fonctionner sur sa propre distribution Linux, bien qu'il puisse être porté sur Fedora, CentOS et les systèmes basés sur Debian tels que Ubuntu et Gentoo. Ce n'est pas automatisé :avec Kpatch, un administrateur doit vérifier et appliquer les correctifs manuellement.
SUSE Kgraft
Kgraft est le système de correctifs en direct de SUSE et fonctionne uniquement avec Linux Enterprise Server de SUSE. Contrairement à d'autres systèmes, Kgraft n'arrête pas les fonctions du noyau pendant l'application des correctifs. Au lieu de cela, il surveille les fonctions afin de pouvoir appliquer tous les correctifs au sein d'un seul appel système.
Live Patch d'Ubuntu
Livepatch a été créé par Canonical, la société qui développe Ubuntu. Il est unique parmi les systèmes de correctifs en direct en ce sens qu'il permet aux administrateurs de créer leurs propres correctifs de noyau personnalisés. Cela fonctionne sur Ubuntu, bien sûr, mais aussi sur Red Hat Enterprise Linux.
KernelCare
KernelCare, développé par CloudLinux, fonctionne avec les distributions les plus populaires, telles que CentOS, RHEL, Oracle Linux, Amazon Linux, Debian et Ubuntu. Il est automatisé, facile à installer, gère les correctifs complexes et fournit des correctifs personnalisés et à date fixe pour répondre à des besoins spécifiques.
Comparaison des fonctionnalités et des prix
Capacités de correction
| KernelCare | Oracle Ksplice | Red Hat Kpatch | SUSE Kgraft | Ubuntu Livepatch | |
| Distribution des ensembles de correctifs | Un seul jeu de patchs pour tous les patchs | Chacun est un module séparé | Chacun est un module séparé | Chacun est un module séparé | Patchset unique pour tous les patchs |
| Moment de lancement | Avant ou peu après la distribution de base | Après le correctif dans la distribution de base | Aucun fourni | Correspond aux cycles de publication de SUSE | Correspond aux cycles de publication d'UBUNTU |
| correction Glibc | Oui | Oui | Non | Non | Non |
| correction OpenSSL | Oui | Oui | Non | Non | Non |
| Correctifs personnalisés | Oui | Non | Oui | Oui | Non |
Compatibilité et mise en œuvre
| KernelCare | Oracle Ksplice | Red Hat Kpatch | SUSE Kgraft | Ubuntu Livepatch | |
| Prend en charge les anciens noyaux ? | Oui | Oui | Non | Non | Non |
| Prise en charge 32 bits ? | Personnalisé | Oui | Non | Non | Non |
| API disponible ? | Oui | Oui | Non | Oui | Oui |
| Fonctionnalité de restauration ? | Oui | Oui | Non | Non | Non |
| Fonctionne derrière un pare-feu ? | Oui | Oui | Oui | Oui | Oui |
Distributions prises en charge
| Oracle Ksplice | Oracle Linux, Fedora 25-27, Ubuntu Desktop 14.04-17.10 |
| Red Hat Kpatch | Red Hat Enterprise Linux, Ubuntu, Debian, Gentoo |
| SUSE Kgraft | SUSE |
| Ubuntu Livepatch | Ubuntu |
| KernelCare | SE CloudLinux, Amazon Linux 1 &2, CentOS, Debian, OpenVZ, Oracle Enterprise Linux, Oracle UEK, Proxmox VE, Red Hat Enterprise Linux, Ubuntu, Ubuntu Core, Virtuozzo , Xen4 CentOS, Yokto |
Prix par serveur
| Oracle Ksplice | 2 299 $ (1 399 $) par serveur et par an :le coût d'un abonnement au support Oracle Linux Premier ou (limité) |
| Red Hat Kpatch | 1 299 USD par serveur et par an :le coût d'un abonnement au support RHEL Premium |
| SUSE Kgraft | 2 198 $ par serveur et par an :le coût combiné du service de correction en direct (699 $) et de l'abonnement au serveur prioritaire (1 499 $) |
| Ubuntu Livepatch | 225 $ par serveur et par an, 75 $/an pour les machines virtuelles :le coût d'un abonnement au support Ubuntu Advantage |
| KernelCare | 27 $ par serveur et par an, pour une licence de plus de 500 serveurs. |
Lire connexe
- Détecter les bibliothèques partagées obsolètes en mémoire avec Uchecker
Quel système de correctifs en direct du noyau Linux vous convient le mieux ?
Pour une entreprise exécutant des serveurs Web en interne, avec une grande équipe d'administrateurs système, des systèmes standardisés et des contrats de support existants avec Oracle, Red Hat ou SUSE, les avantages de l'utilisation des systèmes de correctifs inclus peuvent l'emporter sur les frais. Interagir régulièrement avec les opérations d'assistance de ces fournisseurs peut aider à rationaliser les siennes.
Pour une organisation exécutant des serveurs Web standardisés sur Ubuntu, son système Livepatch inclus dans son abonnement au support est un bon choix. Le système est solide et le coût est faible par rapport aux contrats de support susmentionnés.
Pour une entreprise disposant d'un grand parc de serveurs, comprenant différentes distributions Linux, le système KernelCare est la seule option viable. C'est également un bon choix pour les entreprises pour lesquelles le coût et l'efficacité sont des préoccupations, en fournissant des correctifs automatisés et flexibles à faible coût.
Pour une entreprise qui exploite des appareils compatibles avec Internet dans le cadre de "l'Internet des objets", KernelCare est la seule option. La majorité de ces appareils utilisent des conteneurs Linux, et lorsqu'ils sont piratés, cela peut avoir des conséquences mortelles, il est donc crucial de garder leurs noyaux corrigés. Le calendrier de publication rapide des correctifs dans le système KernelCare le rend bien adapté aux applications IoT.
Lire connexe :
- Différentes façons de mettre à jour le noyau Linux pour Ubuntu
Utilisez-vous actuellement l'un des systèmes de correctifs en direct susmentionnés ? Veuillez partager vos réflexions dans la section des commentaires ci-dessous.