En 1991, deux événements indépendants ont eu lieu, chacun d'entre eux annonçant deux libertés très différentes: la fin de la guerre froide et la naissance de Linux.
La possibilité de patcher le noyau en temps réel est apparue en 2008, alors que Linux était encore adolescent. Maintenant que le noyau Linux est sur le point d'atteindre 30, les correctifs en temps réel sont également mûrs et sur le point de minimiser sa réputation en tant que module complémentaire facultatif qui est simplement «agréable à avoir dans la boîte».
Il y a deux raisons à cela. Le premier est la domination de Linux en tant que plate-forme de choix pour l'hébergement Web économique et polyvalent: plus de la moitiétous les sites Web connus fonctionnent actuellement sous Linux. Deuxièmement, la reconnaissance du fait que la correction en temps réel est plus qu'une simple commodité; c'est également un moyen efficace et peu coûteux d'améliorer la sécurité de votre système Linux.
Ksplice, la première solution de correctifs de noyau Linux en temps réel, a acquis sans effort un statut lucratif après son lancement, ne faisant que renforcer son leadership lorsque le géant de la technologie Oracle l'a achetée en 2011. Aujourd'hui, c'est la plus célèbre des cinq organisations proposant des services de correctifs de sécurité automatisés pour Linux. Par ordre alphabétique, ce sont:
- Service Canonical Livepatch pour Ubuntu.
- KernelCare pour Ubuntu, Red Hat Enterprise Linux, Oracle Linux, Amazon Linux et plus.
- Kpatch pour Red Hat Enterprise Linux.
- Ksplice pour Oracle Linux.
- SUSE Linux Enterprise Live Patching pour SUSE Linux Enterprise.
Chaque entreprise fait la promotion de ses services en utilisant les mêmes mots-clés standard, les mêmes phrases standard, répétées à l'infini. Je vais vous donner les plus populaires et comment vous devez les comprendre.
- Rebootless : actualise le noyau Linux sans redémarrer.
- Automatisé: vérifie et installe les mises à jour de sécurité du noyau sans observateur.
- Installation facile: l'installation et la configuration sont très simples ou inutiles.
- Entièrement pris en charge: vous n'avez pas besoin d'écrire vous-même des correctifs. (Jetez un oeil à de Kpatch Patch Guide de rédaction pour voir pourquoi cela est important)
Ignorez ces arguments de vente aveuglément évidents et vous trouverez d'autres fonctionnalités à prendre en compte, d'autres facteurs que vous pouvez utiliser pour comparer un service à un autre. Cet article en explore quelques-uns, légèrement assaisonnés d'affirmation et d'édification. Mais d'abord, rappelons ce qu'est le patching en direct.
Qu'est-ce que le correctif du noyau Linux en temps réel?
Le noyau Linux contient plus de 20 millions de lignes de code écrites principalement (vraisemblablement) par des programmeurs humains. Comme avec tous les logiciels, il a des bogues. En cette ère de concentration accrue sur la cybersécurité, les bugs impliquent des vulnérabilités . Pour résoudre ce problème, les fournisseurs Linux essaient de publier des mises à jour de leurs noyaux dès que possible. Les administrateurs système Linux essaient également de réagir rapidement en installant ces mises à jour, ce qui rend la planification plus difficile. En effet, il n'existe aucun modèle de détection des vulnérabilités. Voici quelques raisons:
- Il existe de nombreuses versions différentes du noyau Linux en cours d'utilisation à tout moment. Certains auront besoin d'être réparés; certains non.
- , .
- Linux , .
- Linux . , , — .
Il y a encore une chose qui est rarement mentionnée: c'est le dégoût instinctif de l'administrateur système pour arrêter la machine, ce qui cause une gêne physique d'avoir à dire: «Le serveur est en panne pour maintenance».
Pourquoi arrêter le serveur? Parce que la mise à jour du noyau ne prendra effet qu'au redémarrage. Si vous ne redémarrez pas - si vous le mettez en veille ou si vous l'oubliez - vous vous retrouverez dans un dilemme, car un serveur sans les derniers correctifs n'est pas sûr . Nous parlerons de ce mantra plus en détail plus tard, mais son essence est la suivante:
lorsque les vulnérabilités deviennent publiques, la même chose se produit avec leurs exploits.
Ou, en d'autres termes, vous avez une vulnérabilité que vous ne connaissiez pas auparavant, mais que vous avez maintenant. Et tout le monde aussi.
Le sauveur dans ce scénario est le patch en direct . C'est une façon de mettre à jour non pas tout le noyau Linux, mais seulement sa partie problématique. Et cela se fait sans arrêter les processus ni interrompre le travail des utilisateurs.
Cependant, il existe des limites. Les correctifs du noyau en temps réel ne peuvent pas corriger toutes sortes de bogues. La complexité écrasante du code du noyau et les défis techniques liés à la modification du code à la volée signifient que cette technique n'est utilisée que pour résoudre les problèmes critiques, généralement liés à la sécurité.
Malgré cela, un système avec des fonctionnalités de correction en temps réel est plus sûr qu'un système sans cela. Voici quelques questions à poser lors de la recherche d'une solution de correctif en temps réel:
1. Qu'y a-t-il à l'intérieur du patch (et qui est derrière)?
Lorsque vous vous inscrivez à un service de correctifs en direct, vous payez plus que le logiciel lui-même. Cela devient clair lorsque vous commencez à fouiller dans la source du noyau Linux et que vous réalisez à quel point un correctif mal écrit peut endommager tout un système Linux.
J'ai mentionné plus tôt que le noyau est un énorme corpus de travail qui semble se développer à la fois en activité et en volume. Notez l'augmentation du nombre de lignes de code dans la branche master du référentiel du noyau Linux. (Compte à partir du 1er janvier de chaque année. Seuls les fichiers et en-têtes C / C ++, les fichiers Python et Perl sont comptés.)
Avec autant de code, écrire des correctifs pour le noyau Linux n'est pas une tâche facile. Une compréhension approfondie de l'architecture du noyau et des structures de données est nécessaire. Expérience des conventions de codage et des normes de qualité de la communauté Linux. Et il faut un talent particulier pour inventer des solutions qui n'affectent pas la fonctionnalité, les performances et la stabilité.
Il existe deux méthodes opposées que les fournisseurs de correctifs utilisent pour développer et fournir des correctifs de noyau. Je les appelle incrémentales et monolithiques .
Des patchs incrémentiels, comme une boule de chewing-gum, sont empilés les uns sur les autres, chacun modifiant le comportement du précédent. En tant que client, vous devez suivre les correctifs que vous installez et ceux que vous n’avez pas, ainsi que l’ordre dans lequel ils sont installés. Le fait de ne pas prêter attention à ces problèmes peut entraîner des changements imprévisibles dans le comportement de votre système. Cette méthode de correction permet aux fournisseurs de publier rapidement de petits correctifs ciblés. Mais avec le temps, le système peut devenir instable au point que seule une mise à jour complète du noyau peut le restaurer.
Un patch monolithique est un patch qui inclut tous les patchs précédents. Fondamentalement, il n'y a qu'un seul patch maître qui remplace le patch actif plutôt que d'y être ajouté. Cette approche rend la plate-forme plus stable, augmentant considérablement la disponibilité du serveur, souvent mesurée en milliers de jours.
2. Combien de temps attendre le prochain patch?
Il y a inévitablement un délai entre le signalement d'une vulnérabilité et sa correction. Il faut du temps pour analyser les erreurs du noyau et du temps pour évaluer leur impact. Il faut de l'ingéniosité et des compétences pour trouver une solution, et des tonnes de tests pour s'assurer que cela fonctionne. Il est ensuite soumis à un examen et à une approbation obligatoires dans le cadre du processus de développement Linux.
Des retards évitables se produisent lorsque le fournisseur Linux remplace le niveau de gravité de la communauté par le sien. Cela signifie qu'un fournisseur peut corriger plusieurs vulnérabilités avec moins de correctifs, mais cela fait qu'un client attend en moyenne plus longtemps que certains problèmes soient résolus.
Les administrateurs Linux qui comprennent les raisons de la nature erratique des versions de correctifs n'en bénéficient pas beaucoup plus que ceux qui ne le font pas. Aucun d'entre eux ne trouve de réconfort en sachant qu'en attendant les correctifs, leurs systèmes sont encore plus vulnérables à un exploit qu'avant sa découverte.
Voici pourquoi: les membres de la communauté de recherche sur la cybersécurité adorent annoncer des vulnérabilités avec un cas d'utilisation visuel. Ils prennent généralement la forme d'une preuve de concept, une description technique détaillée de la manière de reproduire un bug ou d'utiliser un exploit. Ces descriptions sont de bonne foi pour aider les développeurs du noyau à trouver et corriger le trou. Mais ils font également gagner beaucoup de temps et d'efforts aux pirates en leur donnant un raccourci vers une recette littérale de désastre dans leur course pour exploiter la vulnérabilité comme une arme.
3. Quelle devrait être la gravité de l'erreur?
Presque toutes les vulnérabilités nouvellement découvertes reçoivent un identifiant CVE. Plus tard, après une inspection plus approfondie par les chercheurs en sécurité, une vulnérabilité est classée comme gravité, c'est-à-dire une mesure de son impact.
Un système de notation important est une évaluation générale de la vulnérabilité du système (CVSS - Common Vulnerability Scoring System) . Il représente une vulnérabilité sous la forme d'un ensemble de nombres, dont chacun est un score pour une caractéristique, par exemple:
- Est-il facile de reproduire (utiliser).
- Comme il est difficile de le réparer.
- L'ampleur de l'impact sur la disponibilité des serveurs et des services.
- Importance ou confidentialité des données ouvertes.
L'ensemble complet comprend de nombreuses autres évaluations similaires. L'algorithme les combine en un score de base , un nombre net représentant la gravité de la vulnérabilité, allant de 0 (faible) à 10 (élevé). CVSS de la deuxième version divise les plages de ces nombres en mots-clés LOW, MEDIUM et HIGH. La nouvelle version de CVSS 3 en ajoute deux autres: NONE et CRITICAL.
Ainsi, le nombre de vulnérabilités varie non seulement selon les mois et les années, mais aussi selon la gravité.
Les systèmes d'évaluation des vulnérabilités tels que CVSS permettent aux fournisseurs Linux d'évaluer comment réagir à une vulnérabilité spécifique du noyau. Par exemple, ils peuvent vouloir écrire des correctifs pour les vulnérabilités avec un score cumulatif de 7 ou plus. Cela signifie HIGH dans CVSS v2, HIGH ou CRITICAL dans CVSS v3. Un fournisseur prétendant cibler des vulnérabilités critiques ne peut faire référence qu'à des vulnérabilités avec des niveaux de gravité 9 et 10 lors de l'utilisation de CVSS v3.
4. Puis-je annuler un patch?
L'installation automatique des correctifs sans aucune supervision est une idée terrible pour de nombreux administrateurs système. Ils savent que même des correctifs testés de manière approfondie peuvent modifier le comportement d'un système, affectant ses performances ou ses fonctionnalités d'une manière subtile et pas tout à fait évidente. Lorsque cela se produit, lorsque le serveur se comporte étrangement après l'installation du correctif, le moyen le plus rapide de le gérer est de supprimer le correctif.
Certains services de correctifs en temps réel peuvent supprimer des correctifs. Cela permet de déterminer plus facilement si une mise à jour récente entraîne une modification du comportement du système.
5. Puis-je héberger mon propre serveur de correctifs?
L'agent logiciel de correction vérifie en temps réel les correctifs disponibles sur les serveurs ptach distants. Il le fait à intervalles réguliers et configurables, généralement avec la possibilité d'effectuer des vérifications personnalisées. Si un correctif est disponible, le logiciel de l'agent le téléchargera et l'installera. Mais si l'agent de correction est incapable de communiquer avec le serveur de correctifs sur lequel le service de correction du fournisseur stocke les correctifs, l'application de correctifs en direct ne se produira pas.
Pour résoudre ce problème, vous devez créer votre propre serveur de correctifs. Un tel serveur local diffuse des correctifs sur tous les ordinateurs de votre entreprise sous votre pare-feu. Copy Safe télécharge le correctif, puis le distribue via le pare-feu après avoir vérifié l'intégrité des fichiers de correctif. Vous pouvez gérer et auditer ce processus à votre convenance en rendant le conseil d'administration de votre entreprise un peu plus détendu.
Il y a aussi d'autres avantages:
- Vous avez un meilleur contrôle sur les correctifs que vos serveurs reçoivent et quand.
- Vous pouvez bloquer un grand nombre de serveurs pour des niveaux de correctifs connus.
- Il est plus facile de séparer les clusters de serveurs pour le développement, les tests, la préparation et la production.
Le correctif dynamique nécessite un agent local et un serveur de correctifs distant. Le contrôle des deux est essentiel pour les déploiements en entreprise.
Conclusion
Avant de vous réveiller, voici trois questions supplémentaires à poser à un fournisseur potentiel de solutions de correctifs:
- Puis-je annuler le renouvellement automatique? Il y a des moments où vous ne voulez pas mettre à jour automatiquement les noyaux.
- Sur quelles plateformes fonctionne-t-il? Bien que votre environnement de serveur puisse empêcher toute flexibilité dans le choix d'une solution de correction en temps réel, il est préférable que votre abonnement au service ne limite pas l'option Linux que vous devez utiliser.
- ? , Linux. . , .
Le fait qu'ils soient moins présents dans les descriptions de produits des fournisseurs de correctifs ne rend pas les fonctionnalités décrites dans cet article moins importantes. Chacun de ces éléments peut influencer votre décision de contacter un fournisseur spécifique. Chacun de ces éléments peut affecter directement l'efficacité et la pertinence de la solution pour votre environnement. Étant donné que les frais d'abonnement au serveur vont de quelques dizaines par mois à des milliers de dollars américains par an, il est utile d'être prudent lors du choix d'une solution de correction du noyau Linux.
Lire la suite:
Installer et configurer les
10 meilleures pratiques AlienVault SIEM (OSSIM) pour sécuriser les images Docker. Partie 1
10 bonnes pratiques pour sécuriser les images Docker. Partie 2