L'application de correctifs et la mise à jour des systèmes sont une étape clé dans la réduction des vecteurs d'attaque possibles contre votre infrastructure. Lorsqu'il existe des systèmes dans votre environnement qui ne sont pas à jour avec des correctifs, il peut y avoir des vecteurs d'attaque dont vous ne savez pas qu'ils pourraient affecter l'ensemble de votre organisation. Cependant, quelles étapes avez-vous en place lorsqu'un événement de mise à jour ne se déroule pas comme prévu ?
[ Les lecteurs ont également aimé : Sécuriser un système Linux hérité ]
Par exemple, les dépendances peuvent ne pas être satisfaites, il peut y avoir des versions incompatibles entre les RPM i686 et x86_64, les nouvelles versions de package peuvent ne pas fonctionner comme prévu ou quelque chose d'autre peut mal tourner. Lorsque quelque chose ne va pas, il est important d'avoir un plan sur la façon de procéder. Cela réduira le niveau de stress et garantira que tous ceux qui travaillent sur la tâche savent ce que font les autres.
Tester les patchs
Lors de l'application d'un correctif, il est important de tester d'abord les correctifs dans un environnement de test qui correspond à votre environnement de production . Si vous testez les correctifs sur un matériel différent, avec différentes versions de logiciels ou avec des charges de travail ou des processus différents de votre environnement de production, rien ne garantit que les résultats des tests de correctifs refléteront ce qui se passera en production. Une fois que vous disposez d'un environnement de test dans lequel vous pouvez vérifier qu'un ensemble de correctifs donné doit être installé, vous réduisez considérablement les risques de problèmes lors de l'installation des mises à jour.
Échec des correctifs
Si les mises à jour échouent à s'installer, la première chose à faire est de capturer toute sortie sur la console ou dans les journaux. Il peut s'agir simplement de copier un fichier journal dans un emplacement distinct ou de copier le texte affiché sur l'écran de la console. En fonction de la manière dont le correctif a été tenté, vous pouvez essayer de réexécuter les mises à jour, cette fois avec une sortie détaillée activée. Une fois que vous avez la sortie d'erreur, vous voudrez voir les différences entre votre environnement de test et ce que vous avez en production. Vous devez également vérifier que tous les correctifs ont été appliqués lors des tests et qu'aucun correctif ou erreur n'a été manqué par inadvertance. Un élément essentiel à vérifier est la liste des RPM installés sur votre serveur de test à comparer avec les versions de votre serveur de production.
Par exemple, sur le serveur de production :
# rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'| sort &> /tmp/rpm-qa.prod.output.txt
Vous pouvez ensuite comparer cela à la sortie collectée sur votre serveur de test dans son /tmp/rpm-qa.dev.output.txt .
Vous devez également vérifier que le yum disponible les référentiels sont les mêmes sur les deux systèmes. Vous pouvez le faire en trois étapes simples.
Tout d'abord, videz le cache :
# yum clean all
# rm /var/cache/yum/* -rf Ensuite, actualisez le gestionnaire d'abonnement :
# subscription-manager refresh
Troisièmement, répertoriez les référentiels dans yum avec le -v argument afin que vous puissiez voir des informations supplémentaires telles que le repodate et le nombre de packages dans les dépôts :
# yum repolist -v Dans l'exemple suivant, nous allons examiner le rhel-8-for-x86_64-appstream-rpms référentiel utilisé par un client sur mon serveur Red Hat Satellite :
Repo-id : rhel-8-for-x86_64-appstream-rpms
Repo-name : Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Repo-revision: 1605844838
Repo-updated : Thu 19 Nov 2020 11:02:03 PM EST
Repo-pkgs : 13,502
Repo-size : 31 G
Repo-baseurl : https://opendemo.usersys.redhat.com/pulp/repos/opendemoorg/Library/content/dist/rhel8/8/x86_64/appstream/os
Repo-expire : 1 second(s) (last: Wed 31 Dec 1969 07:00:00 PM EST)
Repo-filename: /etc/yum.repos.d/redhat.repo Les lignes clés ici sont repo-id , mise à jour du dépôt , repo-pkgs , et repo-baseurl . Si mes systèmes de test et de production affichent des informations différentes pour leurs référentiels en amont, il est possible que les dépendances ne soient pas satisfaites ou que quelque chose d'autre échoue. Si tel est le cas, vous devrez rechercher pourquoi les systèmes voient des informations différentes.
Autres paramètres
Supposons que les systèmes de test et de production disposent des RPM attendus et des mêmes référentiels, mais que les correctifs échouent toujours. Dans ce cas, d'autres causes possibles peuvent être un paramètre de sécurité mal appliqué, un espace disque insuffisant ou peut-être des autorisations utilisateur incorrectes. Pour enquêter sur ceux-ci, vérifiez les journaux tels que /var/log/messages , /var/log/secure , et /var/log/audit/audit.log peut être utile, ainsi que l'utilisation de la commande df -h pour vérifier l'espace disque. De plus, les clients Red Hat sont invités à ouvrir un ticket d'assistance pour obtenir de l'aide afin de résoudre le problème.
[ Cours en ligne gratuit :Présentation technique de Red Hat Enterprise Linux. ]
Récapitulez
Il existe de nombreuses causes possibles d'échec de l'installation correcte des correctifs, mais le fait de pouvoir comparer votre environnement de test à votre environnement de production facilitera grandement le dépannage. Les configurations, les dépendances, les charges de travail et les référentiels doivent tous être les mêmes dans les deux environnements.