ClickCease Redémarrer ou ne pas redémarrer ? C'est la question que se posent de nombreux administrateurs système - TuxCare

Rejoignez notre populaire bulletin d'information

Rejoignez 4 500+ professionnels de Linux et de l'Open Source !

2 fois par mois. Pas de spam.

Redémarrer ou ne pas redémarrer ? C'est la question que se posent de nombreux administrateurs système.

12 novembre 2020 - L'équipe de relations publiques de TuxCare

Redémarrer ou ne pas redémarrer ? Telle est la question que se posent de nombreux administrateurs système.Un cycle de redémarrage de serveur est un nom générique donné au processus de redémarrage d'une flotte de serveurs dans une organisation. Cela peut être dû à plusieurs facteurs, mais c'est souvent parce que les correctifs et les mises à jour nécessitent un redémarrage - ils ciblent soit un composant critique du système d'exploitation, soit une bibliothèque partagée utilisée par plusieurs composants ou programmes. Le nombre de serveurs qui doivent être redémarrés a un impact direct sur la durée de l'opération et le risque associé. Plus le nombre de serveurs à mettre à jour est élevé, plus le processus de planification et d'exécution est difficile.

Pour offrir aux entreprises un moyen de gérer ces mises à jour de sécurité sans redémarrage, le "live patching" a été créé. Le principal avantage de cette méthode est qu'elle ne nécessite pas de redémarrage, ce qui réduit de 60 % les tâches typiques du cycle de correction. Pourtant, de nombreuses entreprises utilisent des cycles de redémarrage plutôt que la méthode du "live patching". Y a-t-il une raison à cela ? Nous allons examiner ce problème.

Contenu :

  1. Risque de mise à jour. Risque lié à l'absence de mise à jour :
    Equifax : Un récit édifiant
    Le Live Patching ralentit-il les systèmes ?
  2. Rebooter ou ne pas rebooter ?
  3. Le vainqueur : Cheminer sans rebooter
  4. Conclusion

 

Risques liés à la mise à jour. Risques liés à l'absence de mise à jour.

Risques liés à la mise à jour. Risques liés à l'absence de mise à jour.

Quand vous mettez à jour votre noyau, il y a toujours nouveaux risques potentiels C'est l'une des raisons pour lesquelles certains n'ont pas encore adopté les mises à jour de correctifs en direct. Si leurs serveurs sont déjà stables, ont une vitesse décente et n'ont pas besoin de nouvelles fonctionnalités, ils ne veulent peut-être pas risquer le temps d'arrêt du serveur nécessaire pour appliquer les correctifs. Bien que ces raisons puissent sembler parfaitement raisonnables pour ne pas appliquer un correctif, il existe une raison pour laquelle vous devez absolument le faire, même si vous avez une ou plusieurs de ces raisons : la sécurité.

Dès qu'un nouveau correctif pour le noyau est annoncé, les pirates commencent à chercher des moyens d'exploiter la vulnérabilité qui est corrigée. Si vous ne mettez jamais à jour ce correctif, vous laisserez toujours une porte dérobée ouverte aux pirates pour s'introduire dans vos systèmes. C'est précisément pourquoi nous trouvons encore des pirates qui exploitent la vulnérabilité HeartBleed même si le correctif a été publié en 2014. Il s'agit de l'une des vulnérabilités les plus dévastatrices, mais certains systèmes n'ont toujours pas appliqué le correctif permettant de retirer cette porte dérobée aux pirates.

 

Equifax : Un récit édifiant

Equifax : Un récit édifiant

Selon une enquête de Ponemon, 60 % des personnes interrogées déclarent qu'une ou plusieurs des violations subies par leur organisation l'année dernière étaient dues à une vulnérabilité connue pour laquelle il existe un correctif, mais qu'elles ne l'ont jamais appliqué. Environ 88 % des personnes interrogées ont déclaré qu'avant de pouvoir appliquer un correctif, elles devaient se coordonner avec d'autres services de leur organisation, ce qui peut retarder le correctif de 12 jours. Plus le délai est long, plus les pirates ont le temps de trouver une porte dérobée dans votre système.

La brèche d'Equifax 2017 est un excellent exemple d'une vulnérabilité pour laquelle un correctif n'a pas été appliqué. Equifax était au courant de la vulnérabilité Apache Struts (CVE-2017-5638), mais n'a pas appliqué de correctif au système. Le PDG d'Equifax de l'époque a déclaré qu' ils n'avaient pas trouvé la vulnérabilité dans leurs analyses du système, et que le correctif n'avait donc pas été appliqué comme il était censé l'être. Comme le correctif n'a pas été appliqué, 145,5 millions d'Américains se sont fait voler leurs informations. Si la société avait utilisé un système de correctifs en temps réel, cette violation de données aurait pu être évitée.

 

Les correctifs en direct ralentissent-ils les systèmes ?

Les correctifs en direct ralentissent-ils les systèmes ?

Certains peuvent choisir de ne pas passer au live patching parce qu'ils pensent que les mises à jour en direct vont ralentir leurs systèmesOr, même un petit ralentissement peut entraîner des problèmes pour une organisation. Un certain nombre de facteurs peuvent ralentir un système, notamment les vulnérabilités elles-mêmes et l'utilisation de correctifs temporaires au lieu de correctifs permanents.

Avec les correctifs temporaires, vos mises à jour sont appliquées au serveur, mais vous devez le redémarrer pour qu'il applique complètement les correctifs. En outre, les correctifs s'empilent les uns sur les autres et peuvent commencer à ralentir le système par eux-mêmes. Avec les correctifs persistants en direct, tout est fait sans nécessiter de redémarrage ni ralentir le système.

 

Rebooter ou ne pas rebooter ?

Rebooter ou ne pas rebooter ?

Pour comparer l'application de correctifs en direct et l'application de correctifs réguliers avec redémarrage, il faut tenir compte de plusieurs aspects, car la comparaison change en fonction du type de système considéré.

Serveurs physiques: Pour les serveurs physiques, une opération de redémarrage prend toujours au moins quelques minutes en raison de l'opération POST (power-on self-test) qui est effectuée pour vérifier les composants matériels. Dans ce cas, il est toujours plus rapide et plus efficace d'effectuer un correctif en direct car cela prend moins de temps et la disponibilité du service est plus élevée. C'est le cas typique où le live patching avec KernelCare Enterprise est toujours meilleur à tous points de vue.

Serveurs virtualisés épais: Pour les serveurs virtualisés épais, le temps de redémarrage est un facteur moins important, mais il implique également des temps d'arrêt lors de l'application régulière de correctifs et du redémarrage. Cela a un effet d'entraînement sur d'autres systèmes, affecte la redondance des services fournis, nécessite une fenêtre de maintenance et a plus d'impact que l'application de correctifs en temps réel.

Serveurs virtualisés minces: Sur les systèmes virtualisés légers, c'est là que les choses pourraient être plus équilibrées, car redémarrer un conteneur revient à le détruire et à le recréer, et c'est le cas d'utilisation optimal pour les conteneurs. Cependant, un conteneur partage le noyau avec l'hôte sur lequel il s'exécute, de sorte que la mise à jour du noyau de l'hôte avec KernelCare Enterprise signifie qu'il met automatiquement à jour les conteneurs également. C'est mieux ainsi, car il n'est plus nécessaire de démonter le conteneur et de le recréer, aussi rapide ou lent que cela puisse être.

Table de comparaison des serveurs

Lorsque l'on effectue cette opération sur plusieurs serveurs, il faut le faire de manière à maintenir la disponibilité du service, ce qui est plus facile à faire si l'on dispose de nombreux serveurs. Cela signifie que les grandes organisations peuvent le faire plus efficacement que les petites, car elles disposent de plus de serveurs redondants. Néanmoins, même dans le meilleur des cas, c'est-à-dire lorsque les services sont entièrement conteneurisés, l'application de correctifs en direct sur les serveurs hôtes a moins d'impact que la recréation de conteneurs avec des versions mises à jour.

 

Le gagnant : Mise à jour sans redémarrage

Le gagnant : Mise à jour sans redémarrage

Comme nous l'avons vu avec la brèche d'Equifax et l'exploitation continue de la vulnérabilité HeartBleed six ans plus tard, la seule façon d'éviter les brèches est d'appliquer rapidement les correctifs. Cependant, le temps d'arrêt nécessaire pour redémarrer un système peut potentiellement le rendre vulnérable. La seule solution est un système de patchs en direct qui ne nécessite pas de redémarrage.

 

Conclusion

Lorsqu'un système compte 1 000 serveurs ou plus, il peut être difficile de les maintenir à jour tout seul, surtout si vous devez coordonner les temps d'arrêt entre les services. KernelCare Enterprise offre des correctifs en direct sans redémarrage, ce qui vous permet de ne jamais avoir de temps d'arrêt et de ne pas laisser votre système exposé à des vulnérabilités non corrigées. Avec KernelCare Enterprise, les serveurs d'entreprise sont toujours à jour et protégés contre les violations de données.

Obtenez un essai GRATUIT de 7 jours avec assistance de KernelCare 

 

 

Vous cherchez à automatiser la correction des vulnérabilités sans redémarrage du noyau, temps d'arrêt du système ou fenêtres de maintenance programmées ?

Découvrez le Live Patching avec TuxCare

Devenez rédacteur invité de TuxCare

Commencer

Courrier

Rejoindre

4,500

Professionnels de Linux et de l'Open Source
!

S'abonner à
notre lettre d'information