mercredi , 28 novembre 2018
Accueil » articles » Tout ce que vous devriez savoir sur VENOM et OpenStack

Tout ce que vous devriez savoir sur VENOM et OpenStack

Toute notre infrastructure est désormais protégée contre la nouvelle vulnérabilité VENOM, ce qui signifie que tous nos clients sont à l’abri de ce problème. Cependant, nous voulions publier un article de blog pour obtenir des détails sur certaines questions courantes concernant cette nouvelle vulnérabilité si vous utilisez OpenStack de quelque manière que ce soit.

Il est extrêmement important de savoir que 99 % des utilisateurs d’OpenStack sont concernés, car la plupart des clouds OpenStack exécutent KVM concerné par ce problème. Vous devriez donc faire très attention.

Utilisateurs OpenStack

Si votre opérateur déclare que vous êtes à l’abri, votre journal d’instance n’affichera aucun signe de redémarrage ou de suspension et de reprise, mais vous devrez quand même vérifier, car un redémarrage ou une suspension et une reprise est nécessaire pour appliquer la modification.

Vous pouvez vérifier cela en utilisant l’interface en ligne de commande OpenStack (ou tout autre moyen que vous souhaitez). Comme nous le voyons ci-après à partir d’un serveur sur notre infrastructure. Il a été suspendu et repris après le 13 mai 2015, le jour où le problème est devenu public.

$ nova instance-action-list sec-test +---------+------------------------------------------+---------+----------------------------+ | Action | Request_ID | Message | Start_Time | +---------+------------------------------------------+---------+----------------------------+ ... | suspend | req-d655ab4b-f88d-4ab1-a1cb-275eae468b05 | - | 2015-05-13T19:20:30.000000 | | resume | req-f9c42862-6485-4fc8-b9ea-de5432d7b7ae | - | 2015-05-13T19:20:34.000000 | +---------+------------------------------------------+---------+----------------------------+

Vous pouvez également consulter le panneau de configuration de votre fournisseur ou, dans notre cas, dans notre onglet « Historique » de CloudConsole pour le serveur. En tant qu’utilisateur, vous ne pouvez pas faire autre chose que de contacter votre fournisseur pour vous assurer qu’il s’en occupe pour vous.

Opérateurs OpenStack

Dans cette section, nous désignons les opérateurs comme toute personne impliquée dans la sécurisation et la stabilité d’un cloud OpenStack. Il est extrêmement important de le modifier car le problème est qu’en accédant à l’hyperviseur via une machine virtuelle, un utilisateur peut effectivement prendre en charge l’intégralité du cloud, car les calculs disposent généralement d’une authentification par clé publique SSH.

En outre, vous ouvrez l’accès à la file d’attente des messages de votre cloud, ce qui signifie qu’un utilisateur malveillant peut envoyer des messages dans la file d’attente et pouvant être exécutés par d’autres nœuds du cloud, sans parler de l’accès à votre réseau de gestion. Vous devriez vraiment patcher ceci dès que possible.

Mettre à jour le QEMU

La première étape consiste à vous assurer que vous avez exécuté le dernier qemu patché sur vos nœuds de calcul. Comme différentes distributions Linux qui utilisent des schémas de version différents, il est préférable de vérifier avec votre documentation la version corrigée. Nous avons fourni une liste de quelques bulletins de sécurité provenant de différentes distributions :

Pour référence, vous pouvez mettre à jour votre système Ubuntu en exécutant simplement « apt-get update », puis suivi de « apt-get update ». Une fois cela fait, vous devriez vérifier que vous êtes à jour en exécutant ce qui suit (exemple sur Ubuntu 14.04 LTS) :

$ dpkg -l | grep qemu-system-x86 ii qemu-system-x86 2.0.0+dfsg-2ubuntu1.11 amd64 QEMU full system emulation binaries (x86)

Redémarrer ou suspendre / reprendre toutes les instances

Une fois que vous l’avez actualisé, le processus qui exécute votre machine virtuelle reste identique à celui qui était vulnérable. Par conséquent, vous devez redémarrer le processus pour qu’il charge la nouvelle version corrigée.

Vous pouvez choisir de redémarrer les serveurs qui annuleront le processus « qemu-system-x86_64 » et redémarrer le nouveau patch.

Vous pouvez également choisir de suspendre et de reprendre, ce qu’enregistre le contenu de la mémoire des instances sur le disque et « qemu-system-x86_64 » processus « qemu-system-x86_64 » lors de la suspension, puis lance un nouveau processus et lit à nouveau le contenu enregistré de la mémoire.

L’avantage de la suspension et de la reprise est que vous ne perdez pas l’état de la machine virtuelle, de sorte qu’aucun redémarrage ne se produit, ce qui réduit les risques de redémarrage des serveurs. Vous pouvez faire les deux en utilisant les clients OpenStack API, Horizon ou CLI. À vous de décider comment vous souhaitez automatiser ce processus.

Vérifier les instances

La chose la plus importante est de s’assurer que tout notre travail a été fait correctement et que nous n’avons manqué aucune instance, nous vous recommandons d’exécuter ce qui suit pour vérifier que tous les processus qemu n’ont pas encore été redémarrés pour utiliser la nouvelle version.

$ pgrep qemu-system | xargs -n 1 lsof -p | grep txt | grep deleted

La commande ci-dessus ne doit rien renvoyer. S’il renvoie un résultat tel que celui-ci, cela signifie que l’instance qemu avec le PID 407 exécute une ancienne version. Il est important de noter que cette commande ne donne pas la bonne réponse que si vous avez déjà fait de remis à niveau  sur votre qemu.

$ pgrep qemu-system | xargs -n 1 lsof -p | grep txt qemu-syst 407 libvirt-qemu txt REG 9,1 6155432 64359274 /usr/bin/qemu-system-x86_64 (deleted)

J’espère que cet article a été utile pour vous donner toutes les informations dont vous avez besoin et comment y remédier.

Consulter aussi

Guide pratique pour devenir revendeurs d’hébergement web

En tant que web designer freelance, l’une des idées les plus courantes qui nous vient …

Watch Dragon ball super