I. Présentation

Aujourd'hui, c'est un grand jour, car je vais vous présenter mon projet vmSafeguard (open source) que je développe depuis plus d'un an. Cette application full-web est un système d'administration et d'automatisation de gestion de sauvegardes pour un ou plusieurs hôtes VMWare ESXi.

L'objectif étant de pouvoir automatiser entièrement les processus de sauvegarde de vos machines virtuelles, en évitant in fine au maximum l'intervention humaine. (si-vous avez déjà lu d'autres articles que j'ai écrits, vous commencez à saisir que j'adore tout automatiser je pense :-)).

J'utilise cette solution au quotidien dans le cadre de mon travail, au sein de plusieurs environnements de production. Tout au long de ce tutoriel, je vais utiliser la version conteneurisée de mon application, via Docker. Si vous souhaitez ne pas utiliser Docker pour son installation, je vous laisse le soin de consulter la documentation de mon projet (lien ci-dessous). Je préfère vous présenter vmSafeguard avec docker, comme ça si vous n'aimez pas l'application, vous aurez juste à supprimer l'image et son conteneur associé, et vous n'aurez pas perdu votre temps à provisionner un nouvel OS dédié.

Le serveur VMware ESXi qui va me servir de "test" pour cette démo est un ESXi 7.x.  L'outil vmSafeguard est aussi disponible pour les ESXi en version 6.x, mais avec moins de fonctionnalités. (cf la documentation)

Pour plus d'information, voici le Lien github du projet : https://github.com/archidote/vmSafeguard

A. Perspectives d'amélioration

Bien que pleinement fonctionnel, je souhaite continuer à améliorer cet outil, et certaines fonctionnalités et améliorations pourraient voir le jour à l'avenir, notamment :

• Sauvegarde "à chaud" des VMs, sans obligation de les éteindre pour réaliser l'action de sauvegarde comme c'est le cas actuellement (c'est géré automatiquement par l'outil vmSafeguard).
• Amélioration de l'API afin d'avoir plus de fonctionnalités et de granularité pour les alertes mail.
• Affichage des logs "en live" (sans avoir besoin de recharger la page manuellement)
• Identifier les VM avec leur nom plutôt que le VMID
• etc.

B. Prérequis

Voici les prérequis à respecter afin de pouvoir installer vmSafeguard :

• Disposer d'un ou plusieurs hyperviseurs VMware ESXi opérationnels pouvant communiquer avec la machine qui hébergera vmSafeguard
• Le service SSH et l'ESXi Shell doivent être activés (au démarrage), sur le(s) hôte(s) ESXi concerné(s)
• Privilèges d'administrateur sur le(s) hôte(s) ESXi ainsi que sur la machine hébergeant l'application.
• La version conteneurisée de vmSafeguard ne supporte pas HTTPS pour des raisons techniques (dialogue API, etc.). Si vous souhaitez absolument utiliser HTTPS, suivez l'installation standard sans Docker, qui n'est guère plus longue. 

C. À ne surtout pas faire !

• N'ajoutez pas d'espace dans les noms des machines virtuelles. Les VMs doivent avoir une nomenclature comme celle-ci :
  • Debian-11-64Bits ou Debian_11_64bits
  • mais pas comme ça : Debian 11 64bits, sinon vmSafeguard plantera
  • Ne renommez pas vos VMs
• Ne stockez pas votre machine virtuelle dans un sous-dossier d'une banque de données. Les VM doivent être stockées à la racine d'une banque de données spécifique comme celle-ci :
  • /vmfs/volume/datatsore1/MyDebian10Vm/ 
    Et surtout pas comme ça
    /vmfs/volume/datastore1/VMsdebian/MyDebian10Vm/

D. Environnement de mise en place

• vmSafeguard : exécuté dans un container docker via un hôte Linux (Kali linux) sur le port 8080 (192.168.130.128:8080)
• ESXi 7.x : adresse IP 192.168.130.131

Les deux machines, à savoir l'ESXi et l'hôte Docker doivent pouvoir communiquer entre elle.

II. Installation de vmSafeguard via Docker

Ce guide vous montrera comment configurer l'application vmSafeguard en tant que conteneur Docker rapidement.

Quelques ressources utiles sous la forme de tutoriels vidéos (installation et démonstration - non commenté) :

Installation et configuration de vmSafeguard (Docker)

Actions de sauvegarde avec vmSafeguard (Docker)

Installation de vmSafeguard pour un environnement de production et tests divers (Ubuntu)

A. Extraire (exécuter) l'image de vmSafeguard du hub docker (ESXi 7.x)

Via l'utilisateur root, exécutez les commandes suivantes :

docker run -d -p 8080:80 archidote/vmsafeguard

 J'attire votre attention sur le point suivant :

Vu que j'utilise un port d'écoute différent de 80 et 443 (8080) du côté de l'hôte docker, l'ESXi n'accepte pas par défaut d'envoyer des données sur d'autres ports que ces deux-là. Ce qui est primordial pour le fonctionnement de l'API locale. (Grrr...) Comme je vais utiliser le port 8080 côté hôte docker, je vais donc être amené à désactiver le pare-feu ESXi pour autoriser l'API locale à dialoguer sur un autre port que 80. Nous allons voir plus bas comment désactiver le pare-feu de l'ESXi le cas échéant. Néanmoins, si vous souhaitez vraiment utiliser le port 80 côté hôte docker (ce que je ne fais pas ici), vous pouvez vous abstenir de désactiver le pare-feu de l'ESXi.

Vérifiez que le conteneur est bien en cours d'exécution via la commande suivante :

docker ps

Si tel est le cas, connectez-vous au shell du conteneur par l'intermédiaire de la commande suivante :

docker exec -it <id of the container vmSafeguard> bash
#################
You are into the container with a bash shell
#################

# Démarrez le service cron par le biais de la commande suivante : 
# Par défaut, l'heure du conteneur se base sur l'heure "Française et sur la timezone Europe/Paris

service cron start

Dès lors, dirigez-vous vers le dossier suivant :

cd /root/.ssh/

B. Copiez votre clé publique SSH sur votre (vos) ESXi(s)

vmSafeguard utilise l'authentification par clé SSH publique/privée, pour pouvoir dialoguer avec les hôtes ESXi. Par défaut, le conteneur vmSafeguard dispose d'un couple de clés SSH, accessibles depuis le shell du container. Si vous souhaitez utiliser votre propre couple de clés ou en générer une nouvelle, pas de problème. Il suffira de remplacer cette paire de clés.

Transmettez la clé publique de vmSafeguard via la commande suivante à votre ESXi :

cat id_rsa.pub | ssh -p 22 root@adresse-ip-esxi \ 'cat >> /etc/ssh/keys-root/authorized_keys'
<mot de passe de l'utilisateur ESXi (root)>

Note 1 : Si vous souhaitez interagir avec plusieurs ESXi, répétez la commande précédente sur chaque hôte ESXi.

Afin de tester si vous pouvez vous connecter sans mot de passe via SSH, essayer de vous connecter avec la commande suivante :

ssh -p 22 root@ip-esxi

Désactivez le pare-feu de votre ESXi, si vous n'avez pas changé le port d'écoute côté "Hôte" sur 80.

esxcli network firewall set --enabled

esxcli network firewall get

Terminez la connexion SSH initiée avec la commande :

exit

C. Spécifier le nom de votre datastore

Dans cette nouvelle étape, nous allons spécifier dans la configuration de vmSafeguard le nom du datastore qui stockera les futures sauvegardes.

Depuis le terminal de votre conteneur, exécutez la commande suivante afin de modifier le nom du datastore en modifiant la valeur de la variable "DATASTORE".

nano /var/www/html/vmSafeguard/scripts/backup.sh

Enregistrez le fichier backup.sh et quittez le conteneur :

Cliquez sur "Submit" pour valider et accéder au tableau de bord de l'application.

Cliquez sur "Reload the dashboard", pour accéder à celui-ci.

Voici l'interface principale de vmSafeguard.

III. Tests

A. Afficher un résumé de chaque VM de l'ESXi

Depuis le tableau de bord, cliquez sur "Summary All", afin d'obtenir le VMID de chacune des VMs de votre ESXi. L'obtention de ce VMID est primordiale, car sans celui-ci, vous ne pourrez pas programmer de sauvegardes. En effet, au moment de créer un nouveau job de sauvegarde il faudra spécifier le VMID de la VM à sauvegarder.

Ici, nous pouvons constater que trois VMs sont présentes sur mon hôte ESXi (192.168.130.131).

Si vous souhaitez obtenir le VMID d'une seule VM en particulier, utilisez le menu suivant et entrez le nom de votre VM, depuis l'interface du dashboard :

B. Sauvegarder une ou plusieurs VM

En guise d'exemple, je vais sauvegarder deux VMs. Pour cela, je vais utiliser le sous-menu "Pool Backup", en entrant les deux "VMID" des VMs, séparés par un espace. Si vous souhaitez sauvegarder une seule VM, utilisez le sous-menu de gauche en entrant simplement son VMID.

Note 3 : Si la VM est éteinte, vmSafeguard la backupera directement, sinon il essaiera de l'éteindre de manière "conventionnelle" (si la VM à les vmware tools). Dans le cas contraire, vmSafeguard éteindra de force celle-ci pour procéder à sa sauvegarde. Lorsque la VM est allumée, le processus d'extinction avant sauvegarde est plus long (notamment si la VM doit faire des mises à jour par exemple)

Cliquez sur Start (pool) backup, pour lancer la sauvegarde directement.

Cliquez sur Latest logs pour obtenir les derniers logs concernant la sauvegarde en cours.

Sur la copie d'écran ci-dessus, j'attire votre attention sur les deux lignes qui sont pointées par une flèche rouge. Depuis la version 6.2, vmSafeguard, utilise deux API (locale/distante) qui permettent de vous envoyer un mail dans les situations suivantes :

• Backup(s) achevé(s)
• ESXi détecté comme étant hors ligne

C. Programmez vos sauvegardes

Tout l'intérêt de vmSafeguard est de pouvoir différer la programmation de vos sauvegardes. Grâce à ce menu, vous pouvez programmer vos sauvegardes afin de les automatiser : ce qui est très pratique, si vous souhaitez effectuer des sauvegardes de plusieurs machines virtuelles, la nuit par exemple.

Veillez à respecter la syntaxe cron, car par souci de sécurité, la tâche cron ne sera pas inscrite dans la crontab de l'utilisateur www-data le cas échéant.

Voici un site qui vous aidera, si vous souhaitez créer une tâche cron complexe : https://crontab.guru/examples.html

Vous avez le choix entre programmer une sauvegarde d'une seule VM (menu de gauche), et une sauvegarde de plusieurs VM. Dans tous les cas, il faudra insérer le(s) VMID(s) de(s) machine(s).

vmSafeguard contrôle l'existence ou non des VMID qui lui sont transmis avant de lancer la sauvegarde. Dans le cas où un mauvais VMID serait indiqué par erreur, pas de panique la sauvegarde sera simplement déprogrammée pour cette instance. Cela n'annule pas une sauvegarde de plusieurs machines virtuelles, si les autres VMID sont corrects.

Dans le cas du formulaire de droite, "Pool Backup", pensez bien à mettre un espace entre chaque VMID afin qu'ils soient tous pris en compte. Lorsque la sauvegarde s'effectue sans interaction humaine, toutes les informations sont journalisées. Menu > Logs

D. Changer d'ESXi pour un autre hôte ESXi

Depuis la version 5.0, vmSafeguard est capable de pouvoir changer d'ESXi, afin de sauvegarder les VMs d'un autre hôte. Cette approche vous permet de jongler d'ESXi en ESXi, en fonction des emplacements des VMs que vous souhaitez sauvegarder.

Depuis le tableau de bord, accédez au sous-onglet suivant, et renseignez l'IP et le port du service SSH de votre deuxième hôte ESXi.

Cliquez sur "Reload the dashboard".

Nous constatons que l'ESXi 192.168.130.132 n'a aucune VM existante, mais c'est normal. Rassurez-vous

E. Menu Paramètres

Enfin, pour finir, je vous présente le menu des paramètres de vmSafeguard. Il rassemble un ensemble d'éléments personnalisables comme :

• L'ajout d'un hôte ESXi, qui ne partage pas une banque de données communes avec d'autres ESXi
• Changement du mot de passe du compte admin, email, etc.
• Fixer le rafraichissement de la page d'accueil de manière automatique toutes les X secondes.
• Augmenter/Diminuer le temps, en seconde, d'écriture des logs (notamment pour la progression de la sauvegarde)
• Supprimer les anciennes sauvegardes > à X jours de manière automatique

IV. Conclusion

J'espère que ce tutoriel et la présentation de ce projet vous auront plu. N'hésitez pas à revenir vers moi via l'espace commentaire si vous avez une quelconque question, ou si vous souhaitez suggérer une ou plusieurs fonctionnalités que je pourrais intégrer à vmSafeguard.

Si le projet vous intéresse et que vous souhaitez l'intégrer dans un environnement de production pour "le long terme", installez vmSafeguard sans Docker. Ce n'est pas plus compliqué que ce vous venez de voir.

Dans le cas où vous rencontriez un bug ou un problème technique, je vous invite à ouvrir une issue directement sur la page GitHub du projet. Si vous trouvez la documentation un peu floue sur certains points, je vous encourage aussi à me le signaler.

The post Sauvegarde de VMs sur des hôtes VMware ESXi avec vmSafeguard first appeared on IT-Connect.

Derrière le nom CVE-2021-42321, se cache une faille critique qui touche les serveurs de messagerie Microsoft Exchange, et comme les failles ProxyShell et ProxyLogon, elle pourrait faire parler d'elle.

Si vous avez un serveur de messagerie sous Microsoft Exchange 2016 ou Exchange 2019, vous devriez lire cet article avec une attention particulière. Exchange est victime d'une nouvelle faille de sécurité qui permet à un attaquant authentifié d'exécuter du code à distance sur votre serveur, d'après les informations publiées par Microsoft sur le site TechCommunity. Cette vulnérabilité affecte les serveurs on-premise et les serveurs Exchange en mode hybride. et elle est déjà exploitée par les hackers dans le cadre de cyberattaques.

Se protéger contre les failles Exchange de novembre 2021

Pour protéger votre serveur de messagerie, Microsoft a précisé qu'il y a deux chemins de mises à jour possibles, selon la version actuelle de votre serveur Exchange. Vous devez avoir un serveur Exchange avec un CU spécifique afin de pouvoir installer la mise à jour de sécurité de novembre 2021.

Au sein du Patch Tuesday de novembre 2021, Microsoft a corrigé plusieurs failles pour Exchange, y compris pour Exchange 2013 d'où sa présence dans le schéma ci-dessus. La firme de Redmond vous recommande de mettre à jour votre serveur de messagerie au plus vite.

Mon serveur Exchange est-il ciblé ?

À l'instant t, il est possible de savoir s'il y a eu une tentative d'exploitation de ces nouvelles failles sur votre serveur Exchange. Pour cela, vous pouvez dégainer la console PowerShell et exécuter la commande suivante pour analyser les journaux de votre serveur :

Get-EventLog -LogName Application -Source "MSExchange Common" -EntryType Error | Where-Object { $_.Message -like "*BinaryFormatter.Deserialize*" }

Si la commande vous retourne un ou plusieurs résultats, ce n'est pas bon signe et vous devez approfondir les recherches sur votre serveur Exchange.

Par ailleurs, souvenez-vous que le mois dernier Microsoft a annoncé la mise en ligne d'un nouveau module pour Exchange baptisé "Microsoft Exchange Emergency Mitigation" (EM). Microsoft Exchange Emergency Mitigation permet d'appliquer sur votre serveur de messagerie les mesures d'atténuation, de protection, lorsqu'une nouvelle faille critique voit le jour, en attendant l'installation du correctif. Pour la faille CVE-2021-42321, Microsoft n'a pas précisé si ce nouveau module était en mesure de réagir pour protéger vos serveurs en attendant l'installation du patch, c'est dommage.

• Portail Microsoft - CVE-2021-42321

The post CVE-2021-42321 : la nouvelle faille critique qui touche Microsoft Exchange ! first appeared on IT-Connect.

Le Patch Tuesday de novembre 2021 est disponible ! Ce mois-ci, Microsoft a corrigé 55 vulnérabilités, dont 6 considérées comme critiques et 6 failles zero-day.

Si l'on tri les 55 failles de sécurité de ce mois-ci par type, on se rend compte qu'il y en a 20 qui correspondent à des failles de type "élévation de privilèges". À titre de comparaison, le mois dernier il y avait 21 failles de type élévation de privilèges, mais il y avait plus de 80 vulnérabilités corrigées. Par ailleurs, il y a 15 failles de type "exécution de code à distance" et 10 qui permettent la divulgation d'informations.

Parmi les produits Microsoft concernés par ce Patch Tuesday, nous avons : Azure RTOS, Azure Sphere, Microsoft Dynamics, Microsoft Edge, Exchange Server par trois fois, la suite Office (Excel, Word, Access), Hyper-V, l'Active Directory par 4 fois, Windows Hello, le NTFS, et le noyau Windows.

Six failles zero-day : Excel et Exchange dans le viseur

Ce mois-ci, il faut porter son attention sur les 6 failles zero-day et plus particulièrement deux d'entre-elles qui sont activement exploitées par les pirates. Il y a une faille qui touche Excel et la seconde Exchange, une fois de plus.

• CVE-2021-42292 - Microsoft Excel : bypass d'une fonctionnalité de sécurité
• CVE-2021-42321 - Microsoft Exchange : exécution de code à distance

La faille CVE-2021-42321 qui touche les serveurs de messagerie Microsoft Exchange est particulièrement inquiétante, car elle permet une exécution de code à distance post-authentification. Elle a été découverte lors de la compétition de hacking Tianfu Cup qui s'est déroulée le mois dernier. Pour en savoir plus sur cette faille, lisez cet article.

Quant à la faille dans Excel, c'est l'équipe de Microsoft Threat Intelligence Center qui en a fait la découverte et il s'avère qu'elle est déjà utilisée dans le cadre d'attaque. Dès à présent, Microsoft Office bénéficie d'un correctif pour vous protéger contre cette faille de sécurité, mais ce correctif n'est pas encore disponible pour Office sur macOS.

Concernant les autres failles zero-day qui ne sont pas encore utilisées dans le cadre d'attaques, voici la liste ci-dessous :

• CVE-2021-38631 - Protocole RDP : divulgation d'informations
• CVE-2021-41371 - Protocole RDP : divulgation d'informations
• CVE-2021-43208 : Visionneuse 3D : exécution de code à distance
• CVE-2021-43209 - Visionneuse 3D : exécution de code à distance

Il est à noter que les failles au sein du protocole RDP touchent toutes les versions de Windows, y compris les plus récentes : Windows 10, Windows 11, Windows Server 2022, etc... Y compris les installations en mode "Core".

Source

The post Patch Tuesday – Novembre 2021 : 55 vulnérabilités corrigées et 6 zero-day first appeared on IT-Connect.

Microsoft a publié les nouvelles mises à jour cumulatives pour Windows 10, à l'occasion de ce mardi 9 novembre 2021. Pour Windows 10 version 1909, c'est la KB5007189, tandis que pour les trois versions de Windows 10 les plus récentes, c'est la KB5007186.

Quel est le contenu de ces nouvelles mises à jour ? En complément des correctifs de sécurité, Microsoft a corrigé quelques bugs comme c'est précisé sur le site officiel. Rien de nouveau au sujet des problèmes d'impression évoqués ces dernières semaines. Avant tout, espérons que cette mise à jour ne génère pas de nouveaux problèmes. Je vais revenir sur la partie sécurité dans un article dédié au Patch Tuesday.

Il est à noter que c'est l'avant-dernière mise à jour pour Windows 10 v2004 puisque cette version sera en fin de support le mois prochain (voir cet article).

Voici un récapitulatif des KB en fonction des versions de Windows 10 :

- Windows 10 version 2004, 20H2 et 21H1 : KB5007186
- Windows 10 version 1909 : KB5007189
- Windows 10 version 1903 : Fin du support
- Windows 10 version 1809 : KB5007206
- Windows 10 version 1803 : Fin du support
- Windows 10 version 1709 : Fin du support
- Windows 10 version 1703 : Fin du support
- Windows 10 version 1607 : KB5007192
- Windows 10 version 1507 : KB5007207

Il ne vous reste plus qu'à faire un tour sur votre serveur WSUS ou dans Windows Update sur votre machine locale pour installer la mise à jour cumulative de novembre 2021. Dans le même temps, Microsoft a publié la mise à jour KB5007215 pour Windows 11.

Source

The post Windows 10 KB5007186 et KB5007189 : les màj cumulatives de novembre first appeared on IT-Connect.

On a tendance à l'oublier, mais une version sur deux de Windows 10 a un support relativement court : 18 mois. Cela signifie que Windows 10 version 2004, appelé également 20H1, ne sera plus supporté par Microsoft à partir du 14 décembre 2021.

Si vous utilisez Windows 10 en version 2004, ce qui correspond à la version sortie en mai 2020, il va être temps de penser à la suite : passer sur une version plus récente de Windows 10 ou directement sur Windows 11, si vos machines sont compatibles. Pour Windows 10, vous avez le choix entre la 21H1 déjà disponible ou la 21H2 qui doit voir le jour courant novembre.

Quoi qu'il en soit, cette mise à niveau est indispensable pour conserver un système à jour et protégé contre les dernières failles de sécurité connues. Néanmoins, Microsoft précise que Windows 10 version 2004 continuera de fonctionner normalement, c'est juste qu'il ne recevra plus de mises à jour.

Même si depuis le 4 novembre, Windows 11 est disponible via Windows Update pour un plus grand nombre d'utilisateurs, c'est surement encore un peu tôt pour le déployer en entreprise. Enfin, vous avez peut-être déjà pris les devants et effectués tous les tests nécessaires, je pense que cette décision dépend également de l'environnement dans lequel on se trouve et du nombre de postes.

Depuis le mois de juin dernier, les appareils sous Windows 10 version 2004 sont susceptibles de recevoir la mise à niveau vers Windows 10 21H1 par Windows Update, mais on sait qu'en entreprise on peut bloquer les mises à niveau pour garder une maîtrise de son parc informatique.

Si vous avez déjà entamé une migration de Windows 10 vers Windows 11 en entreprise, n'hésitez pas à partager votre retour d'expérience !

The post Fin du support de Windows 10 v2004 le 14 décembre 2021 first appeared on IT-Connect.