La raison pour laquelle j'ai décidé si rapidement de continuer la série d'articles "Administration système 101" est que j'ai réalisé que certains administrateurs système Linux ne sont pas différents des administrateurs système Windows en matière de gestion des correctifs. Pour être honnête, c'est encore pire dans certains domaines (il se targue surtout de sa durée de fonctionnement). Par conséquent, cet article couvrira les concepts de base de la gestion des correctifs sous Linux, y compris à quoi ressemble une bonne gestion des correctifs, certains outils associés que vous pouvez utiliser et comment l'ensemble du processus d'installation des correctifs est effectué.
Par gestion des correctifs, j'entends les systèmes que vous déployez pour mettre à niveau le logiciel sur vos serveurs, et pas seulement pour mettre à jour le logiciel vers la version la plus récente et la plus avancée. Même les distributions conservatrices comme Debian, qui maintiennent une version spécifique du logiciel dans un souci de « stabilité », publieront de temps en temps des correctifs de mise à niveau pour corriger les bugs et les failles de sécurité.
Bien sûr, si votre organisation décide de maintenir sa propre version d'un logiciel spécifique, soit parce que les développeurs ont besoin de la version la plus récente et la plus performante et doivent dériver le code source du logiciel et y apporter des modifications, soit parce que vous aimez vous donner du travail supplémentaire, cela Ensuite, vous rencontrerez des problèmes. Idéalement, vous devriez avoir configuré votre système pour créer et empaqueter automatiquement des versions personnalisées de votre logiciel en utilisant le même système d'intégration continue que celui utilisé par d'autres logiciels. Cependant, de nombreux administrateurs système utilisent encore des méthodes obsolètes pour empaqueter des logiciels sur leurs hôtes locaux, selon la documentation (espérons-le à jour) sur le wiki. Quelle que soit la méthode que vous utilisez, vous devez savoir si la version que vous utilisez présente des failles de sécurité et, si tel est le cas, vous assurer que le nouveau correctif est installé sur votre version personnalisée du logiciel.
La première chose à faire dans la gestion des correctifs est de vérifier les mises à niveau logicielles. Tout d'abord, pour les logiciels de base, vous devez vous inscrire à la liste de diffusion de sécurité de la distribution Linux correspondante, afin de pouvoir être informé dès que possible de la mise à niveau de sécurité du logiciel. Si vous utilisez des logiciels qui ne proviennent pas du référentiel de la distribution, vous devez également essayer de suivre les mises à jour de sécurité de ceux-ci. Une fois que vous recevez une nouvelle notification de sécurité, vous devez examiner les détails de la notification pour déterminer la gravité de la vulnérabilité de sécurité, déterminer si votre système est affecté et l'urgence du correctif de sécurité.
Certaines organisations utilisent encore des méthodes manuelles pour gérer les correctifs. De cette façon, lorsqu'un correctif de sécurité apparaît, l'administrateur système doit s'appuyer sur la mémoire et se connecter à chaque serveur pour le vérifier. Après avoir déterminé quels serveurs doivent être mis à niveau, utilisez l'outil de gestion de packages intégré au serveur pour mettre à niveau ces logiciels à partir du référentiel de versions. Enfin, mettez à niveau tous les serveurs restants de la même manière.
Il existe de nombreux problèmes avec la manière manuelle de gérer les correctifs. Premièrement, cela rendra l'application de correctifs une corvée. Plus vous installez de correctifs, plus cela nécessitera de coûts de main-d'œuvre et plus les administrateurs système seront susceptibles de retarder ou même de l'ignorer complètement. Deuxièmement, la gestion manuelle s'appuie sur la mémoire de l'administrateur système pour suivre les mises à niveau des serveurs dont il est responsable. Cela peut facilement faire en sorte que certains serveurs soient manqués et ne soient pas mis à niveau à temps.
Plus la gestion des correctifs est rapide et facile, plus vous avez de chances de bien la faire. Vous devez créer un système capable d'interroger rapidement quels serveurs exécutent des logiciels spécifiques et les numéros de version de ces logiciels, et il devrait idéalement être capable de diffuser divers correctifs de mise à niveau. Personnellement, j'ai tendance à utiliser un outil d'orchestration comme MCollective pour effectuer cette tâche, mais Satellite fourni par Red Hat et Landscape fourni par Canonical vous permettent également d'afficher les informations sur la version du logiciel du serveur et d'installer des correctifs sur une interface de gestion unifiée.
L'installation des correctifs doit également être tolérante aux pannes. Vous devriez avoir la possibilité de mettre à jour votre service sans le mettre hors ligne. Il en va de même pour les correctifs du noyau qui nécessitent un redémarrage du système. La méthode que j'ai adoptée consiste à diviser mon serveur en différents groupes haute disponibilité, avec lb1, app1, lapinmq1 et db1 dans un groupe, et lb2, app2, lapinmq2 et db2 dans un autre groupe. De cette façon, je peux mettre à niveau un groupe à la fois sans mettre le service hors ligne.
Alors, quelle est la vitesse ? Pour les quelques logiciels qui ne sont pas fournis avec un service, votre système devrait pouvoir installer un correctif en quelques minutes à une heure au mieux (comme la vulnérabilité ShellShock de bash). Pour les logiciels comme OpenSSL qui nécessitent un redémarrage du service, le processus d'installation des correctifs et de redémarrage du service avec tolérance aux pannes peut prendre un peu plus de temps, mais c'est là que les outils d'orchestration s'avèrent utiles. Dans mes récents articles sur MCollective (voir tickets de décembre 2016 et janvier 2017), j'ai donné quelques exemples d'utilisation de MCollective pour la gestion des correctifs. Il est préférable de déployer un système qui simplifie l'installation des correctifs et le redémarrage des services de manière automatisée et tolérante aux pannes.
Si le correctif nécessite un redémarrage du système, comme un correctif du noyau, cela prendra plus de temps. Encore une fois, les outils d’automatisation et d’orchestration peuvent rendre ce processus plus rapide que vous ne le pensez. J'ai pu mettre à niveau et redémarrer les serveurs en production avec tolérance aux pannes en une heure ou deux, et le processus était encore plus rapide si je n'avais pas à attendre les sauvegardes de synchronisation du cluster entre les redémarrages.
Malheureusement, de nombreux administrateurs système s'accrochent encore à la vision dépassée de la disponibilité comme un signe de fierté - étant donné que les correctifs d'urgence du noyau se produisent environ une fois par an. Pour moi, cela signifie simplement que vous ne prenez pas la sécurité de votre système au sérieux !
De nombreuses organisations utilisent encore des serveurs qui constituent des points de défaillance uniques qui ne peuvent pas être temporairement mis hors ligne et, pour cette raison, ne peuvent pas être mis à niveau ou redémarrés. Si vous souhaitez rendre votre système plus sécurisé, vous devez supprimer les bagages obsolètes et créer un système qui peut au moins être redémarré pendant les fenêtres de maintenance de fin de soirée.
Fondamentalement, une gestion rapide et pratique des correctifs est également le signe d’une équipe de gestion système mature et professionnelle. La mise à niveau du logiciel est l'une des tâches nécessaires pour tous les administrateurs système. Prendre le temps de rendre ce processus simple et rapide apportera des avantages bien au-delà de la sécurité du système. Par exemple, cela peut nous aider à identifier les points de défaillance uniques dans la conception architecturale. De plus, cela aide à identifier les systèmes obsolètes dans l’environnement et incite à remplacer ces pièces. En fin de compte, lorsque la gestion des correctifs est suffisamment bien effectuée, elle libère du temps pour les administrateurs système, leur permettant de se concentrer sur les domaines où une expertise est réellement nécessaire.
Kyle Rankin est un architecte senior de sécurité et d'infrastructure dont les livres incluent : Linux Hardening in Hostile Networks, DevOps Troubleshooting et The Official Ubuntu Server Book. Il est également chroniqueur pour Linux Journal.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
