Depuis le 1er février 2024, les clients d'Amazon Web Services (AWS) doivent payer pour utiliser des adresses IPv4 publiques. Pour Amazon, c'est l'occasion d'empocher plusieurs centaines de millions de dollars...
Amazon a trouvé un nouveau moyen de gagner beaucoup plus d'argent sans que ce soit réellement significatif pour les clients d'AWS : facturer l'utilisation des adresses IPv4 publiques, utiles et indispensables pour de nombreux services. En effet, l'été dernier, Amazon avait annoncé qu'à partir du 1er février 2024, les adresses IPv4 publiques allaient être facturées ! Ceci s'applique à toutes les régions AWS et aux différents types de ressources, notamment les instances EC2 et les noeuds EKS.
Concrètement, une adresse IPv4 publique est facturée 0,005 dollar HT par heure, soit un demi-centime de dollar par heure. Sur une année complète, cela représente 43,80 dollars HT. Du côté de Microsoft Azure, c'est déjà facturé aux clients, et le tarif peut varier de 0,0036 dollar HT de l'heure à 0,005 dollar HT de l'heure.
D'après Andree Tonk, ingénieur en infrastructure chez Cisco, le fait de facturer l'utilisation des adresses IPv4 publiques va rapporter très gros à Amazon. Il estime qu'AWS va engranger entre 400 millions de dollars et 1 milliard de dollars supplémentaire par an, uniquement via ce service. Pour effectuer cette estimation, il s'est appuyé sur trois informations :
Le nombre d'adresses IPv4 publiques détenues par AWS, environ 132 millions
Le nombre d'adresses IPv4 publiques utilisées par les clients AWS, à partir d'un fichier avec 79 millions d'adresses IPv4 publiques
Le tarif annuel de 43,80 dollars HT
Il a fait une estimation relativement prudente en partant du principe que seulement 10% des adresses IPv4 publiques étaient utilisées, soit 7,9 millions, ceci représente tout de même 346 millions de dollars par an.
L'objectif d'Amazon est d'inciter ses clients à être plus économe dans la consommation des adresses IPv4, puisque c'est en quelque sorte une ressource rare (nous le savons depuis longtemps). La "solution" consiste à passer sur des adresses IPv6.
Fin janvier, AnyDesk a été victime d'une cyberattaque lors de laquelle les pirates sont parvenus à compromettre l'infrastructure de production de l'éditeur. Voici les dernières informations publiées par AnyDesk !
Pour rappel, AnyDesk est une solution de prise en main à distance populaire, et il s'agit d'une alternative à une autre solution encore plus populaire : TeamViewer. Aux alentours du 29 janvier 2024, des pirates sont parvenus à s'introduire sur les serveurs de production d'AnyDesk et ils ont pu voler des informations sensibles, notamment du code source et des certificats de signature de code.
La recommandation : utiliser une nouvelle version d'AnyDesk
À la suite de cet incident, AnyDesk a recommandé à ses clients d'utiliser par précaution la dernière version du logiciel, à savoir la version 8.0.8 (pour Windows) puisqu'elle a été signée avec un nouveau certificat de signature de code qui n'est pas en possession des pirates.
Il y a quelques heures, et grâce à l'enquête réalisée en collaboration avec les experts de CrowdStrike, AnyDesk a mis en ligne des informations supplémentaires. L'éditeur allemand recommande toujours l'utilisation des versions 7.0.15 et 8.0.8, qui sont les dernières à ce jour, tout en rappelant que "toutes les versions d'AnyDesk obtenues à partir de nos sources officielles peuvent être utilisées en toute sécurité."
Réinitialisation des mots de passe du portail AnyDesk
AnyDesk a également forcé la réinitialisation de tous les mots de passe associés au portail client "my.anydesk.com", même s'il s'agit avant tout d'une décision prise "par prudence" d'après l'éditeur. Désormais, vous devez définir un nouveau mot de passe pour accéder à votre compte AnyDesk.
Dans le cas où vous utiliseriez ce même mot de passe pour d'autres services, il est recommandé de le changer également sur les services en question.
Un impact sur les serveurs relais d'Espagne et du Portugal
Dans une FAQ publiée sur le site officiel et associée à cet incident de sécurité, AnyDesk affirme qu'il ne s'agit pas d'une attaque de ransomware. Pour autant, le nom du groupe de cybercriminels reste inconnu à ce jour (mais AnyDesk détient peut être l'information en interne).
De plus, l'éditeur précise que des serveurs relais européens sont directement affectés par cette attaque. "Seuls deux de ces serveurs relais en Europe ont été touchés par l'incident.", peut-on lire.
Ces serveurs relais permettent d'assurer la connexion avec les clients AnyDesk déployés sur les appareils, mais toutes les informations de sécurité (jetons, clés privées, etc.) sont stockées uniquement sur les appareils.
Nous apprenons ensuite que les deux serveurs en question sont sollicités par les utilisateurs situés en Espagne et au Portugal. "Les clients des pays qui se connectent via des serveurs relais en dehors de l'Europe (par exemple, les États-Unis, l'Asie, l'Afrique, l'Australie, l'Amérique du Sud) et en dehors de la zone de localisation affectée de ces deux serveurs (c'est-à-dire l'Espagne et le Portugal) ne sont pas non plus concernés.", précise AnyDesk.
Enfin, AnyDesk précise que le code source de l'application est sain et qu'il n'a pas été altéré par les pirates pour distribuer un logiciel malveillant. "Nous avons examiné notre code et n'avons constaté aucune modification malveillante.", ce qui est plutôt rassurant.
L'enquête d'AnyDesk se poursuit donc il y aura peut être d'autres informations disponibles dans les prochains jours.
Dans ce tutoriel nous allons voir comment personnaliser la configuration de VMware ESXi 8.0 à partir de l’interface DCUI (Direct Control User Interface). À titre de rappel, ESXi est un hyperviseur de type 1 ou bare-metal, c'est-à-dire qu'il s'installe directement sur le matériel. Depuis sa mise en marché par VMware en 2001, ESXi reste encore aujourd'hui l'hyperviseur le plus utilisé en entreprise pour les charges de travail on-prem (sur site). Son installation constitue la première étape pour mettre en place une infrastructure de virtualisation vSphere. VMware offre une version d'évaluation qui vous permet d'en faire l'essai pour une période de 60 jours.
En entreprise, ESXi s’installe sur un serveur physique et vient rarement seul : un cluster d'au moins deux hôtes est nécessaire pour disposer des fonctionnalités de haute disponibilité. Pour les besoins d'un lab VMware, nous avons vu dans un autre article que vous pouvez déployer ESXi en tant que machine virtuelle sous VMware Workstation 17 en mettant à profit la technique de virtualisation imbriquée. Si vous souhaitez aller de l'avant avec cette approche, consultez l'article suivant :
Les étapes présentées ici supposent que votre hôte ESXi est déjà installé et que vous pouvez y accéder en mode console, que ce soit à partir de Workstation, de vSphere ou en SSH.
Remarque : si besoin, vous pouvez accéder au site de VMware pour télécharger une image d'ISO d'évaluation de VMware ESXi.
II. Configurer l’adressage IP
L’interface DCUI (Direct Control User Interface) se reconnaît aisément par sa page d’accueil classique où des options figurent sur un arrière-plan gris et jaune. Lors de la première installation de ESXi, c’est à partir de la DCUI que vous pourrez personnaliser vos configurations réseau, DNS ou assigner un nom d’hôte à votre serveur. Cette console vous permet aussi de changer le mot de passe de root et de consulter les journaux du système.
Pour accéder aux options de configuration, connectez vous à votre hôte ESXi en mode console (sur Workstation ou vSphere) et appuyez sur F2 (« Customize System/View Logs »).
Vous devrez ensuite vous authentifier avec le compte root. Lorsque vos informations d’accès ont été saisies, appuyez sur « OK ».
Lors du déploiement de ESXi, une adresse IP est assignée automatiquement via DHCP, mais dans un environnement de production, il est préférable de configurer une adresse fixe. Pour faire cette modification, déplacez-vous sur « Configure Management Network » et appuyez sur la touche Entrée.
Notons au passage que le réseau de gestion (Management Network) est l’interface principale pour administrer ESXi. Elle peut être utilisée pour d’autres fonctionnalités comme le vMotion (déplacement de machines virtuelles à chaud entre deux hôtes dans vSphere), mais il est préférable de disposer d’une deuxième carte réseau dédiée pour faire ce type de configuration.
Dans les options de configuration de la carte de gestion, déplacez-vous sur « IPv4 Configuration » (ou IPv6, si vous l’utilisez…) et appuyez sur la touche Entrée.
Dans le menu « IPv4 Configuration », déplacez-vous sur « Set static IPv4 address and network configuration » et sélectionnez l’option en appuyant sur la barre d’espacement. Vous pouvez ensuite éditer les champs « IPv4 Address », « Subnet Mask » et « Default Gateway » selon l’adressage IP que vous avez choisi. Appuyez sur la touche d’entrée (« OK ») lorsque vous avez terminé. Dans l'exemple ci-dessous, l'adresse IPv4 "192.168.2.80/24" est attribuée à l'hyperviseur.
Vous disposez maintenant d'une adresse IP statique, voyons comment modifier les noms des serveurs DNS que vous aller utiliser ainsi que le nom d'hôte de votre serveur ESXi.
III. Faire les configurations DNS
De retour au menu « Configure Management Network », déplacez vous sur « DNS Configuration » et appuyez sur la touche Entrée.
Dans le menu « DNS Configuration », sélectionnez « Use the following DNS server addresses and hostname » et appuyez sur la barre d’espacement pour confirmer votre choix. Indiquez les adresses des serveurs DNS dans les champs appropriés et vous pouvez également donner un nom d’hôte à votre serveur sous « Hostname ». Lorsque vous aurez terminé, appuyez sur la touche d’entrée.
Si vous souhaitez accéder à votre machine à partir de son nom d’hôte, vous voudrez lui assigner un nom de domaine. Dans le menu « Configure Management Network », déplacez vous à l’option « Custom DNS Suffixes » et appuyez sur la touche d’entrée.
Vous verrez que localdomain est déjà présent comme suffixe par défaut. Vous pouvez le retirer et saisir le suffixe DNS de votre dans le champ « Suffixes » et appuyez sur la touche d’entrée. Dans cet exemple, le suffixe DNS "itconnect.fr" est utilisé, ce qui donnera le nom complet (FQDN) suivant pour l'hôte : ESXI8-01.itconnect.fr.
Si ce n'est pas déjà fait, créez un enregistrement A pour votre hôte ESXi sur un serveur DNS. N'hésitez pas à consulter les articles suivantes pour en savoir davantage sur le DNS sous Linux ou mieux comprendre ce service :
Lorsque vos personnalisations réseau et DNS sont terminées, appuyez sur la touche échap. afin de valider les configurations du réseau de gestion.
Appuyez sur « Y » pour confirmer que vous souhaitez redémarrer le service du réseau de gestion.
Vous reviendrez ensuite au menu principal (« System Customization »). Si vous voulez tester la configuration réseau et la résolution DNS, déplacez vous sur « Test Managment Network » et appuyez sur la touche d’entrée. Bien entendu, pour le DNS, votre enregistrement A devra avoir été créé préalablement.
Des commandes ping seront envoyées si vous appuyez sur la touche d’entrée pour tester l’adresse IP indiquée (d'abord sur l’interface principale et, ensuite, sur les autres si vous avez plusieurs cartes réseau) et une résolution de nom sera effectuée sur le nom d’hôte.
Au besoin, vous pouvez interrompre le test en appuyant sur la touche échap.
Il existe d’autres options que vous pourrez explorer au besoin comme la possibilité de préciser un numéro de VLAN sous « Configure Management Network » ou d’activer SSH sous « Troubleshooting Options ».
Lorsque vous aurez terminé vos configurations, vous pouvez sortir de l’interface DCUI avec la touche échap. Sur la page d'accueil, vous trouverez les adresses web (nom d'hôte ou adresse IP fixe) pour accéder à la console web ESXi Host Client.
IV. Se connecter à ESXi Host Client avec les nouvelles configurations
Notez l'adresse web indiquée dans la section jaune de la DCUI (https://<adresse IP ou nom d'hôte>) et inscrivez-la dans la barre de recherche de votre navigateur préféré pour accéder à l'interface ESXi Host Client. Vous pouvez maintenant vous connecter en tant que root.
Si vous ne parvenez pas à accéder à l’interface web de ESXi, revenez dans la DCUI et vérifiez votre configuration réseau. Dans le menu « System Customization », vous pouvez aussi redémarrer la « stack » TCP/IP en choisissant l’option « Restart Management Network ».
V. Conclusion
Dans ce tutoriel, nous avons vu comment personnaliser la configuration de l'adressage IP et des informations DNS d'un hôte ESXi en passant par la console DCUI (Direct Control User Interface). Par défaut, ESXi s'attribue une adresse IP via DHCP et un suffixe DNS qu'il convient de modifier, notamment lorsque nous installons des hôtes en production.
Une fois notre hôte ESXi configuré, nous sommes prêts à passer à la création et l'administration de machines virtuelles dans un environnement VMware. Ce sera le sujet de tutoriels à venir prochainement ! En attendant, n'hésitez pas à explorer ESXi et à expérimenter pour mieux comprendre le fonctionnement et la richesse des fonctionnalités de cet hyperviseur.
Une alerte de sécurité s'affiche sur l'écran de votre PC lorsque vous essayez d'ouvrir une invitation de calendrier (.ICS) avec Outlook ? Sachez que Microsoft est au courant de ce problème et que des investigations sont en cours. Voici ce que l'on sait !
Suite à l'installation des mises à jour de sécurité Microsoft Office publiées à l'occasion du Patch Tuesday de Décembre 2023, les utilisateurs doivent faire face à un nouveau problème lié au client de messagerie Outlook. C'est le cas également après l'installation du correctif qui vise à combler la vulnérabilité CVE-2023-35636 présente dans Outlook et qui peut être utilisée pour voler des hash NTLM.
Le bug se produit lorsqu'un utilisateur essaie d'ouvrir un fichier .ICS, correspondant à un événement de calendrier. Une alerte de sécurité s'affiche à l'écran, avec un premier message "Microsoft Office a identifié un problème de sécurité potentiel" accompagné d'un second message "Cet emplacement peut être dangereux". Ce qui n'est pas normal, c'est que l'alerte s'affiche même lorsqu'il s'agit d'un fichier local.
Source : Microsoft
Microsoft cherche actuellement une solution, et l'entreprise américaine est formelle sur le fait qu'il s'agit bien d'un bug. En effet, voici ce que nous pouvons lire dans un document de support : "Ce comportement n'est pas attendu lors de l'ouverture de fichiers .ICS. Il s'agit d'un bug qui sera corrigé dans une prochaine mise à jour".
Une solution temporaire
En attendant ce correctif, sachez que Microsoft propose une solution temporaire qui consiste à effectuer des modifications dans le Registre Windows de votre machine. L'inconvénient de cette solution temporaire, c'est qu'elle désactive tous les types de messages, et pas uniquement ceux-ci...
Si vous souhaitez déployer cette solution, sachez que vous devez ajouter une nouvelle clé DWORD nommée "DisableHyperlinkWarning", avec une valeur "1" dans le Registre Windows. Voici où créer cette valeur dans le Registre :
Depuis plusieurs semaines, la situation est très compliquée pour l'éditeur Ivanti et ses clients : une nouvelle faille de sécurité zero-day a été découverte dans les solutions Ivanti Connect Secure et Ivanti Policy Secure. Les pirates l'exploitent massivement dans le cadre de cyberattaques. Faisons le point sur la situation.
Le 31 janvier 2024, Ivanti a tiré la sonnette d'alarme pour avertir ses clients de la présence d'une nouvelle faille zero-day dans ses solutions, notamment au sein du composant SAML, en publiant un nouveau bulletin de sécurité. Désormais, cette faille de sécurité, de type SSRF (Server-Side Request Forgery) est associée à la référence CVE-2024-21893. Plusieurs agences, dont l'ANSSI au niveau français, ainsi que l'agence américaine CISA, ont publiées des alertes de sécurité pour cette nouvelle CVE.
Depuis le 2 février, la vulnérabilité est massivement exploitée par les cybercriminels ! Il faut dire qu'il y a plusieurs exploits PoC disponibles sur Internet, comme sur cette page. D'après le service de monitoring TheShadowServer, 170 adresses IP différentes sont à l'origine d'attaques ayant pour objectif de compromettre des instances Ivanti. Il faut dire que cette faille est intéressante pour les pirates puisqu'elle s'exploite à distance, et lorsque, l'attaque réussie, elle permet d'outrepasser l'authentification et d'accéder à certaines ressources.
Toujours d'après TheShadowServer, actuellement, près de 22 500 instances Ivanti Connect Secure sont exposés sur Internet. Attention, il s'agit du nombre total d'instances, et nous ignorons combien d'entre elles sont vulnérables à cette faille zero-day.
Comment se protéger ?
Si vous utilisez Ivanti Connect Secure, Ivanti Policy Secure, mais aussi Ivanti ZTA, vous devez installer le dernier correctif de sécurité pour vous protéger de cette nouvelle faille zero-day, ainsi que de celles dévoilées dernièrement : CVE-2023-46805, CVE-2024-21887, CVE-2024-21888 et CVE-2024-21893.
Le 1er février 2024, Ivanti a indiqué ceci sur son bulletin de sécurité : "Un correctif corrigeant toutes les vulnérabilités connues est maintenant disponible pour Ivanti Connect Secure version 22.5R2.2 et Ivanti Policy Secure 22.5R1.1."
C'est réellement à effectuer en priorité si vous utilisez ces solutions.
