Dans ce tutoriel, nous allons apprendre à installer Windows Server 2025, le nouveau système d'exploitation de Microsoft à destination des serveurs. Bien qu'il soit encore en version "Preview", nous pouvons avoir une idée précise du processus d'installation, de son interface, et commencer à évaluer certaines nouveautés.
Pour le moment, Microsoft n'a pas dévoilé officiellement les prérequis de Windows Server 2025, donc je ne m'avancerai pas sur ce point.
Voici des articles que vous pouvez lire pour en savoir plus sur les nouveautés prévues et connues actuellement :
Afin de pouvoir suivre ce tutoriel, vous de télécharger une image ISO de Windows Server 2025 Preview après avoir rejoint le programme Windows Insiders pour Windows Server.
2 - Quand c'est fait, vous devez accéder à cette page pour télécharger l'image ISO de Windows Server Preview
Quand le système d'exploitation sera disponible, d'autres liens seront publiés par Microsoft.
III. Installation de Windows Server 2025
Vous pouvez installer Windows Server 2025 sur une machine physique, mais également dans une machine virtuelle. Si vous avez besoin d'aide pour lancer l'installation, voici quelques liens utiles :
Intéressons-nous maintenant à l'installation en elle-même, étape par étape.
La première étape consiste à sélectionner le langage et le format de l'heure.
La seconde étape consiste à sélectionner la disposition du clavier.
Vient ensuite l'étape "Sélectionner l'option d'installation", où nous devons choisir "Installer Windows Server" pour procéder à l'installation du système. Ceci va permettre de poursuivre avec la nouvelle expérience d'installation. En complément, il faut cocher l'option "J'accepte que tout soit supprimé...".
Saisissez la clé de produit que vous souhaitez utiliser pour activer Windows Server 2025. Si vous n'en avez pas, vous pouvez passer cette étape.
Pour la version "Preview", Microsoft fournit les clés de licence suivantes :
Windows Server 2025 Standard : MFY9F-XBN2F-TYFMP-CCV49-RMYVH
Windows Server 2025 Datacenter : 2KNJJ-33Y9H-2GXGX-KMQWH-G6H67
En fonction de la clé de licence saisie, et après vérification de celle-ci, l'étape suivante est accessible. Si l'on indique une clé de licence pour Windows Server 2025 Standard, nous avons le choix entre :
Windows Server 2025 Standard, ce qui correspond au mode "Core" sans interface graphique (minimaliste)
Windows Server 2025 Standard (expérience utilisateur), ce qui permet d'avoir une installation avec l'interface graphique habituelle, à la sauce Windows 11 dans le cas présent.
Ensuite, acceptez les conditions du contrat de licence Microsoft.
Sélectionnez le disque sur lequel vous souhaitez installer le système d'exploitation. Ici, c'est sur une machine virtuelle avec un seul disque.
Démarrez l'installation... Et patientez pendant ce temps-là.
Une fois que la grosse partie de l'installation est effectuée, le serveur va redémarrer. Quand ce sera fait, vous serez invité à saisir un mot de passe pour le compte Administrateur local du serveur. Quand c'est fait, cliquez sur "Terminé".
Pour finir, une étape peu habituelle s'affiche : "Envoyer des données de diagnostic à Microsoft", comme sur Windows 11. Choisissez si vous souhaitez partager plus ou moins de données de télémétrie avec Microsoft.
Voilà, l'installation de Windows Server 2025 est terminée !
IV. Aperçu de l'interface de Windows Server 2025
Windows Server 2025 intègre le "Gestionnaire de serveur" comme les précédentes générations de Windows Server. Comme le montre l'image ci-dessous, Microsoft nous incite à utiliser Windows Admin Center, en local ou via Azure, pour l'administration de nos serveurs Windows Server. L'entreprise américaine met en avant également sa solution Azure Arc.
L'interface de Windows Server 2025 est similaire à celle de Windows 11, ce qui est assez perturbant au premier abord. Mais, n'oublions pas qu'il s'agit d'une première version "Preview" donc tout cela est susceptible d'évoluer dans les prochains mois... même si en principe ce nouveau Windows Server devrait conserver cette interface, au même titre que Windows Server 2022 est similaire à Windows 10.
V. Conclusion
En suivant ce tutoriel, vous êtes en mesure de pouvoir installer Windows Server 2025 Preview sur un serveur physique ou virtuel afin d'essayer cette nouvelle version de Windows Server. En fonction des évolutions futures, cet article sera actualisé.
Pour ceux qui ont pris le temps d'essayer cette version Preview, qu'en pensez-vous ?
Il y a quelques jours, Microsoft a mis en ligne la première version "Preview" officielle de Windows Server 2025. L'occasion de réaliser une première installation de la future version majeure de Windows Server, et de se rendre compte que Microsoft a introduit une nouvelle expérience d'installation.
Dès à présent, les administrateurs système peuvent tester Windows Server 2025, que l'on appelait auparavant Windows Server vNext. Au-delà des différentes nouveautés dévoilées par Microsoft, et qui ont déjà fait l'objet de plusieurs articles sur IT-Connect, c'est le processus d'installation qui a évolué légèrement.
Il est à noter que ce nouvel assistant d'installation devrait également profiter à Windows 11 (dans les futures versions stables) car avec les dernières build disponibles via le programme Windows Insiders, Microsoft a également introduit cette nouvelle expérience.
Aperçu du nouvel assistant d'installation
Découvrons ensemble ce nouveau processus d'installation... Qui commence par le choix du langage, le format de l'heure, et la disposition du clavier. Au-delà de l'aspect visuel qui est différent, la prochaine étape l'est également.
L'étape "Sélectionner l'option d'installation" est nouvelle, et elle propose trois choix à l'utilisateur :
Installer Windows Server
Réparer mon ordinateur personnel
Lancer l'expérience héritée
La première option, à savoir "Installer Windows Server" sert à poursuivre l'installation de Windows Server 2025 grâce à ce nouvel assistant, mais il n'y a pas de réel changement par la suite. À l'étape suivante, l'assistant vous demande de saisir la clé de produit. La clé de produit sera vérifiée et en fonction des droits qu'elle procure, vous aurez le choix entre une ou plusieurs éditions de Windows Server. Cette étape peut également être ignorée.
Si l'on sélectionne "Réparer mon ordinateur personnel", nous arrivons sur un environnement où l'on peut ouvrir l'Invite de commandes, accéder aux paramètres de l'UEFI ou encore restaurer la machine à l'aide d'une image système. Ce bouton était déjà présent sauf qu'il s'appelait "Réparer l'ordinateur" et il était "caché" en bas à gauche de la première étape du précédent assistant d'installation.
Enfin, l'option "Lancer l'expérience héritée" permet de retrouver l'assistant d'installation "classique" que l'on connait depuis plusieurs années.
Ensuite, si l'on poursuit avec le nouvel assistant, il faut se laisser guider jusqu'à la fin de l'installation... Mais, il est à noter que l'installation se termine par une étape où l'on doit choisir ce que l'on souhaite envoyer à Microsoft en termes de données de diagnostic (télémétrie).
Si vous souhaitez découvrir le processus d'installation de Windows Server 2025 dans son intégralité, vous pouvez suivre ce tutoriel :
On se retrouve dans cet article pour une nouvelle solution de l'un des challenges d'investigation numérique/forensic nommés Sherlocks et mis à disposition par la plateforme Hack The Box. Je vous propose ici ma démarche permettant de solutionner le Sherlocks Meerkat, de difficulté "Facile".
Cet article sera notamment l'occasion de comprendre comment peut se dérouler concrètement une cyberattaque, et quels sont les modes opératoires des attaquants et analystes en cybersécurité
Cette solution est publiée en accord avec les règles d'Hack The Box et ne sera diffusée que lorsque le Sherlocks en question sera indiqué comme "Retired".
Technologies abordées
Linux, bash, web, JSON, HTTP
Outils utilisés
Wireshark, sublime text, jsbeautifier
Retrouvez tous nos articles Hack The Box via ce lien :
Je ne sais pas vraiment de quel outil viennent ces données, mais il s'agit vraisemblablement d'une solution de sécurité réseau ou d'un IDS (Intrusion Detection System). On y voit différentes données relatives à des alertes de sécurité portant sur des flux réseau (IP destination, source, ports, etc.).
III. Investigation numérique : le cas Meerkat
A. Tâche n°1: l'application web
Énoncé - Task 1 : We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running?
La première tâche consiste à retrouver le nom de l'application compromise. J'ai commencé par isoler les signatures dans les alertes depuis le fichier JSON afin d'avoir une vue synthétique de celles-ci :
On voit ici que plusieurs alertes référencent l'application Bonitasoft. La solution de sécurité semble avoir reconnu l'exploit ou l'attaque et l'avoir assigné à une CVE. Si l'on s'intéresse à la capture réseau avec l'outil d'analyse réseau Wireshark et que l'on applique un filtre sur le protocole HTTP, on peut voir que l'application bonita apparaît rapidement :
Astuce au passage : pour appliquer rapidement un filtre Wireshark sur un élément très spécifique d'un paquet, on peut effectuer un clic droit sur l'élément en question puis Apply as Filter :
B. Tâche n°2 : identifiants utilisés
Énoncé - Task 2 : We believe the attacker may have used a subset of the brute forcing attack category - what is the name of the attack carried out?
Il s'agit de retrouver le nom de l'attaque opérée sur l'application, en sachant qu'elle a un lien avec le brute force et les mots de passe. Commençons par nous renseigner sur les attaques existantes et leurs noms exacts auprès de la référence en la matière, le framework MITRE ATT&CK :
On se doute donc que l'attaque va être l'une de celles-ci. Nous pouvons essayer d'analyser les paquets HTTP du fichier PCAP pour en savoir plus (Filtre wireshark :HTTP). S’il s'agit d'une attaque concernant l'authentification, les requêtes qui nous intéressent sont les requêtes POST (à moins que l'application soit vraiment très ancienne, à l'époque où les identifiants transitaient en paramètre GET...). Améliorons notre filtre Wireshark :
Nous pouvons voir que plusieurs requêtes POST ont été faites, chacune avec des identifiants bien précis, soit l'identifiant qui semble être celui par défaut (install:install), soit une adresse mail avec un mot de passe. On observe notamment qu'il n'y a jamais deux fois le même username de testé, il ne s'agit pas d'une attaque par brute force. L'attaquant semble savoir à l'avance quel mot de passe va avec quelle adresse mail.
L'attaquant a donc forcément récupéré ces informations avant de procéder à son attaque. Il s'agit donc d'une attaque par Credential Stuffing où l'attaquant utilise des identifiants valides qu'il a récupéré précédemment (achat sur le darknet, campagne de phishing, etc.).
C. Tâche n°3 : utilisation d'une CVE
Énoncé - Task 3 : Does the vulnerability exploited have a CVE assigned - and if so, which one?
Ici, il faut revenir sur les alertes de sécurité récupérées dans le format JSON, la CVE en question est déjà identifiée :
Énoncé - Task 4 : Which string was appended to the API URL path to bypass the authorization filter by the attacker's exploit?
D'après la question, l'attaquant aurait modifié l'URL durant son attaque sur l'API afin de contourner un filtrage en place. Voyons cela dans la capture réseau.
Nous pouvons voir qu'après plusieurs tentatives d'authentification infructueuses, l'attaquant parvient à trouver une combinaison valide puisqu'il atterrit sur l'API. On peut notamment observer que toutes les URL comportent un ;i18ntranslation. J'ai du mal à voir l'intérêt d'ajouter cette chaîne de caractère, mais cela semble être en relation avec la CVE exploitée.
E. Tâche n°5 : attaque par brute force
Énoncé - Task 5 : How many combinations of usernames and passwords were used in the credential stuffing attack?
Ici, Il s'agit de compter le nombre de tentatives d'authentification différentes effectuées par l'attaquant dans le cadre de son attaque par Credential stuffing. Pour ce faire, j'ai appliqué le filtre suivant sur Wireshark :
http.request.uri == "/bonita/loginservice"
Il me permet de n'afficher que les paquets qui contiennent une requête vers /bonita/loginservice, correspondant à la page de login. J'ai ensuite effectué un tri par taille (Length) afin de pouvoir ignorer rapidement toutes les tentatives d'authentification avec install:install (qui font donc tous la même taille : 105 octets). Ceux-ci n'entrent pas dans le cadre d'une attaque par Credential Stuffing, puisqu'il s'agit d'un mot de passe par défaut, et non volé.
En sélectionnant les paquets restants, Wireshark m'indique que j'en ai 59 :
J'en enlève 3 car l'attaquant a fait 4 tentatives d'authentification avec les mêmes identifiants, qui ne comptent donc que pour 1, cela fait donc 56 identifiants.
F. Tâche n°6 : identifiant valide
Énoncé - Task 6 : Which username and password combination was successful?
Nous avons un aperçu de la réponse via nos analyses précédentes. En affichant uniquement les requêtes POST dans Wireshark, on remarque qu'après plusieurs tentatives d'authentification, l'attaquant commence à requêter d'autres points d'entrée, signe que son attaque par brute force a abouti :
Ici, il ne faut pas oublier de trier nos paquets par ordre d'interception, et non plus par taille. En sélectionnant l'authentification juste avant la requête sur l'URL /bonita/API/pageUpload, on obtient les identifiants avec lesquels l'attaquant est parvenu à s'authentifier :
seb.broom@forela.co.uk:g0vernm3nt
G. Tâche n°7 : utilisation d'un site tiers
Énoncé - Task 7 : If any, which text sharing site did the attacker utilise?
Il semble ici que l'attaquant ait utilisé un site de partage de fichiers pour échanger des données avec la cible compromise. Qui dit requête web, dit souvent requête DNS, utilisons un filtre Wireshark sur les requêtes DNS de type 1 (A, c'est-à-dire les requêtes name to IPv4):
Le site utilisé par l'attaquant est pastes.io !
H. Tâche n°8 : script de persistance
Énoncé - Task 8 : Please provide the file hash of the script used by the attacker to gain persistent access to our host.
Ici, il s'agit de retrouver un script déposé par l'attaquant afin d'établir une persistance sur le système compromis. Nous pouvons nous intéresser aux échanges réseau effectués par l'attaquant, qui sont en clair :
On retrouve assez rapidement une commande wget qui a permis à l'attaquant de télécharger un script depuis le site pastes.io. Ce qui nous permet de nous-même le télécharger pour récupérer son hash md5.
Attention : en condition réelle, le téléchargement et surtout l'analyse des outils de l'attaquant doivent être réalisés sur des plateformes faites pour, déconnectées d'internet et du réseau interne de l'entreprise.
I. Tâche n°9 : clé publique SSH
Énoncé - Task 9 : Please provide the file hash of the public key used by the attacker to gain persistence on our host.
En analysant le contenu du script, on remarque qu'il a cherché à ajouter sa clé publique dans le fichier authorized_keys de l'utilisateur ubuntu :
Là aussi, sa clé est téléchargée depuis le site pastes.io, ce qui nous permet de la récupérer :
J. Tâche n°10 : modification d'un compte utilisateur
Énoncé - Task 10 : Can you confirmed the file modified by the attacker to gain persistence?
Nous avons déjà la réponse grâce à la lecture du script de l'attaquant :
/home/ubuntu/.ssh/authorized_keys
Passons à la tâche suivante !
K. Tâche n°11 : MITRE ATT&CK
Énoncé - Task 11 : Can you confirm the MITRE technique ID of this type of persistence mechanism?
De retour sur le framework MITRE ATT&CK, connaissant déjà ce framework à force de l'utiliser, je retrouve facilement l'attaque en question :
Et voilà ! Nous sommes arrivés au bout de l'exercice d'investigation :
IV. Résumé de l'attaque
Au cours de cette investigation, nous avons découvert que l'attaquant a opéré au préalable de l'attaque une récupération d'identifiants et de mots de passe valides par un moyen inconnu. Il a ensuite effectué une attaque par brute force avec ces identifiants sur l'application BonitaSoft en exploitant notamment la CVE-2022-25237 pour contourner les protections de la page d'authentification. Une fois authentifié, l'attaquant a déposé une backdoor par l'intermédiaire du site pastes.io, puis il est parvenu à ajouter sa clé SSH publique dans le répertoire personnel de l'utilisateur ubuntu. Enfin, il est parvenu à accéder en SSH au serveur compromis.
Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :
Nous allons à présent mettre en avant les principales notions et apprentissages de cet exercice, aussi bien pour l'attaquant que pour les défenseurs ou l'analyste. Il ne s'agit pas d'un point de vue complet, n'hésitez pas à améliorer ce contenu en donnant votre avis dans les commentaires :).
A. Côté analyste
Maîtrisez Wireshark : cet outil regorge de fonctionnalités avancées que nous n'avons fait qu'effleurer ici, mais les connaître donne un avantage certain et permet d'aller beaucoup plus vite lors d'une analyse.
L'analyse du fichier JSON a été réalisée à coup de grep, mais sur un fichier plus conséquent l'utilisation de jq ou d'autres parseurs JSON en ligne de commande pourrait devenir intéressante.
B. Côté défense
L'attaquant a opéré une attaque par credential stuffing, ce qui signifie soit :
que les utilisateurs ont été piégés par un phishing préalable à l'attaque, auquel cas il faut améliorer la sensibilisation des utilisateurs
soit que les identifiants ont été récupérés sur une autre application compromise, auquel cas les utilisateurs réutilisent leurs identifiants entre les applications, ce qui n'est pas une bonne pratique. L'implémentation d'un 2FA peut également être recommandée.
La compromission initiale ayant été réalisée en exploitant la CVE-2022-25237 (authentication/authorization bypass vulnerability), il peut également être recommandé de mettre en place et d'appliquer une politique de mise à jour (directive n°34 du guide d'hygiène de l'ANSSI : Définir une politique de mise à jour des composants du système d’information).
Le fait qu'un serveur ait un accès direct et non restreint à internet est un danger certain. On voit ici que l'attaquant a pu importer des outils, des scripts et sa clé publique très rapidement et sans contraintes particulières. C'est pourquoi il est recommandé de limiter au strict nécessaire l'accès à internet des serveurs.
L'exposition directe du serveur à internet et notamment de son service d'administration (SSH) apporte une porte d'entrée supplémentaire à l'attaquant. Après avoir compromis l'application web et ajouté sa clé publique dans les authorized_keys d'un utilisateur, celui-ci a pu se connecter en SSH et se servir du serveur compromis comme d'un rebond vers le réseau interne.
L'ANSSI recommande dans la directive n°23 de son guide d'hygiène de "Cloisonner les services visibles depuis internet du reste du système d’information" pour limiter les possibilités de rebond. Il est également recommandé de ne pas exposer de ports d'administration directement sur Internet, mais d'y accéder en interne, si nécessaire après l'établissement d'une connexion VPN.
On peut également noter que l'utilisateur qui fait tourner le service web ne devrait pas avoir les droits d'écriture dans le home d'un utilisateur. Dans ce cas, il peut être recommandé de vérifier les permissions d'exécution de l'application web sur le serveur Linux compromis, par exemple utiliser le compte www-data et s'assurer qu'il n'a pas de droits d'accès trop permissifs en dehors de ses répertoires web.
Je vous recommande vraiment de vous intéresser au framework MITRE ATT&CK, il permet de rapidement catégoriser une attaque, la définir, mais aussi d'obtenir des informations supplémentaires sur les outils pouvant être utilisés, des recommandations, des informations pour améliorer la détection ou identifier des groupes d'attaquants (APT) en relation avec une attaque.
C. Côté attaquant
Pour être plus discret, l'attaquant aurait pu étaler son attaque par brute force sur plusieurs heures ou jours, potentiellement avec des IP différentes. Il est en effet plus difficile de corréler des évènements sur une telle durée (à moins qu'un filtre sur l'IP du serveur ciblé soit appliqué, mais la taille des fichiers à analyser doit être conséquente). N'étant pas moi-même analyste SOC/Forensic, je suis preneur de vos retours sur cette méthode :).
L'attaquant aurait également pu procéder à des opérations ne nécessitant pas le dépôt de fichier sur le système avec des commandes en one-line, pourquoi pas obfusquées. Le fait de laisser ses fichiers/scripts indéfiniment sur une plateforme publique facilite également la compréhension de l'attaque et pourquoi pas l'identification de l'attaquant. Cela apparaît toutefois comme réaliste dans le cadre d'attaques en masse ou automatisées, toutes les machines compromises retrouveront alors les scripts et backdoors sur un seul et même point.
VI. Conclusion
J'espère que cet article vous a plu ! Au-delà de la résolution du challenge, il est toujours intéressant de savoir tirer parti de ces exercices pour s'améliorer et en extraire le maximum d'apprentissage. N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis !
Enfin si vous voulez accéder à des cours et modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy
Un correctif non officiel, proposé par la plateforme 0Patch, a été publié pour corriger une faille de sécurité zero-day nommée "EventLogCrasher" ! En exploitant cette vulnérabilité, un attaquant peut faire planter à distance le service Event Log de Windows. Voici ce qu'il faut savoir.
Le 23 janvier 2024, un chercheur en sécurité surnommé Florian a publié sur Twitter des détails au sujet d'une vulnérabilité qui permet de faire planter le service Event Log de Windows (Journal d'événements de Windows), à distance ou en local, à partir de n'importe quel compte utilisateur.
Dans un premier temps, il a contacté l'équipe MSRC de Microsoft pour faire remonter ce problème de sécurité, mais il n'a pas obtenu une réponse positive. Microsoft estime que cette vulnérabilité n'est pas éligible : "ils ont prétendu qu'il s'agissait d'un double d'un autre bug datant de 2022 (coïncidence ?) qui ne répondait pas aux exigences de servicing", précise-t-il.
De ce fait, il a publié un code PoC pour montrer l'exploitation de cette vulnérabilité, en pratique. Nous pouvons voir que c'est très simple. D'un point de vue d'un attaquant, il suffit d'avoir une connectivité réseau avec la machine cible et avoir des identifiants valides (un compte avec de faibles privilèges est suffisant) pour exploiter la vulnérabilité. Même si le pare-feu Windows est actif, l'exploitation est possible (avec la configuration par défaut).
Le risque : ne pas avoir de trace de certains événements
Cette faille de sécurité pourrait être exploitée dans le cadre d'une cyberattaque puisque si l'attaquant fait planter le service Event Log d'un contrôleur de domaine pendant son attaque, les événements associés à ses actions ne seront pas journalisés ! Nous pouvons même dire que cela pourrait empêcher certains événements de remonter dans le SIEM de l'entreprise. Ainsi, l'attaquant peut agir sans se faire remarquer...
À ce sujet, voici ce que précise 0patch dans son article de blog : "La bonne nouvelle à ce stade est que le service Windows Event Log est configuré pour redémarrer automatiquement en cas d'arrêt inattendu. La mauvaise nouvelle est qu'il n'est redémarré que deux fois, puis plus du tout. Par conséquent, si le service d'enregistrement des événements se bloque trois fois, il s'arrête de manière persistante."
Toutefois, il faut savoir que les événements relatifs à la sécurité et au système sont mis en mémoire si le service Event Log n'est pas disponible. Lorsqu'il est de nouveau actif, ils sont inscrits. Malgré tout, cette file d'attente à des limites en termes de taille et elle est éphémère : les événements sont perdus en cas de redémarrage de la machine, ou de plantage.
Comment se protéger ?
Comme je l'évoquais en introduction, la plateforme de micropatching 0patch a publié des correctifs non officiels pour combler cette faille de sécurité. D'ailleurs, cette vulnérabilité affecte toutes les versions de Windows et Windows Server à partir de Windows 7 et Windows Server 2008 R2.
En attendant un éventuel correctif officiel de la part de Microsoft, 0patch met à disposition gratuitement les correctifs suivants :
Windows 11 v22H2, v23H2 - mise à jour complète
Windows 11 v21H2 - mise à jour complète
Windows 10 v22H2 - mise à jour complète
Windows 10 v21H2 - mise à jour complète
Windows 10 v21H1 - mise à jour complète
Windows 10 v20H2 - mise à jour complète
Windows 10 v2004 - mise à jour complète
Windows 10 v1909 - mise à jour complète
Windows 10 v1809 - mise à jour complète
Windows 10 v1803 - mise à jour complète
Windows 7 - pas d'ESU, ESU1, ESU2, ESU3
Windows Server 2022 - mise à jour complète
Windows Server 2019 - mise à jour complète
Windows Server 2016 - mise à jour complète
Windows Server 2012 - pas d'ESU, ESU1
Windows Server 2012 R2 - pas d'ESU, ESU1
Windows Server 2008 R2 - pas d'ESU, ESU1, ESU2, ESU3, ESU4
Il faut savoir que 0patch existe depuis plusieurs années et que des correctifs sont régulièrement mis à disposition des utilisateurs. Ils ne sont pas toujours gratuits, car il y a un service payant associé à cette plateforme.
Merci à l'équipe 0patch de m'avoir transmis cette information.
A partir d'aujourd'hui, mercredi 1er février 2024, Google et Yahoo! vont appliquer de nouvelles exigences pour durcir leur politique de réception des e-mails. Ceci signifie qu'il est urgent de bien configurer SPF, DKIM et DMARC pour votre domaine de messagerie, surtout si vous envoyez beaucoup d'e-mails... Voici ce qu'il faut savoir.
Si Google et Yahoo! durcissent le ton et qu'ils ont pris cette décision, c'est dans le but de lutter contre les e-mails indésirables et les e-mails malveillants. En effet, certains domaines de messagerie sont régulièrement usurpés dans le cadre de campagnes de phishing dans le but d'essayer de tromper l'utilisateur.
Désormais, lorsque vous envoyez un e-mail à quelqu'un qui utilisent les services de Google ou Yahoo!, les serveurs de messagerie vont systématiquement chercher à authentifier l'e-mail et le serveur émetteur afin de déterminer si le courrier électronique est légitime ou non. Cette décision s'applique aux utilisateurs Yahoo! Mail mais aussi, et surtout, aux utilisateurs de Gmail (Google Mail) ou Google Workspace pour les services Google.
Des règles différentes selon la quantité d'e-mail envoyés par jour
Il faut savoir que les règles ne seront pas les mêmes selon si vous envoyez moins de 5 000 e-mails par jour ou plus de 5 000 e-mails par jour. Nous parlons bien de 5 000 e-mails envoyés à partir du même nom de domaine principal, et éventuellement à partir des sous-domaines.
Autrement dit, vous devriez faire attention si vous envoyez une newsletter à plusieurs milliers de personnes, ou si vous envoyez beaucoup d'e-mails à vos clients (via un site de e-commerce, par exemple).
Moins de 5 000 e-mails envoyés par période de 24 heures
Vous devez authentifier vos e-mails avec SPF et/ou DKIM, tout en utilisant une connexion sécurisée pour émettre vos e-mails (TLS). Tous les domaines et adresses IP utilisées pour émettre des e-mails doivent avoir un enregistrement DNS de type "PTR" (reverse) correctement configuré.
Vous devez également maintenir votre taux de plaintes pour spam inférieur à 0,10%, tout en évitant absolument qu'il dépasse 0,30%. Google vous invite à utiliser son outil Google Postmaster Tools pour assurer ce suivi.
Google précise également que les e-mails doivent être dans un "format correct", c'est-à-dire qu'il faut respecter la RFC5322. Ce qui implique que vous ne devez pas manipuler l'en-tête "from:" de vos e-mails : n'envoyez pas un e-mail à partir d'un domaine en utilisant un serveur légitime pour un autre domaine.
Plus de 5 000 e-mails envoyés par période de 24 heures
Vous devez respecter toutes les règles listées ci-dessus, et en tant que "gros expéditeur", vous devez respecter des exigences supplémentaires ! Vous devez absolument configurer SPF et DKIM pour l'authentification des e-mails, et vous devez configurer DMARC à minima en mode surveillance, c'est-à-dire sans réel impact et avec une politique définie sur "p=none" (dans un premier temps).
En complément, vous devez faire en sorte d'envoyer uniquement des e-mails qui ont réellement de l'intérêt, et pour tous les e-mails de type "newsletter" ou associé à "un abonnement", vous devez faire intégrer un bouton qui permet de se désinscrire en une clic. "Vous ne devriez pas avoir à faire des pieds et des mains pour ne plus recevoir de messages indésirables d'un expéditeur particulier. Il devrait suffire d'un clic.", peut-on lire sur le site de Google.
Pour en savoir plus, je vous recommande de lire cette documentation de Google :
C'est bien gentil tout ça... Mais comment ça fonctionne ? Comment effectuer la configuration ? Au niveau de la configuration, cela dépend de votre situation et de vos besoins : utilisez-vous Google Workspace, Microsoft 365, AWS, ou encore un serveur de messagerie on-premise ? Peut-être même que vous utilisez en complément un service d'e-mailing ? Sachez que la méthode de configuration ne sera pas la même d'un service à l'autre.
Par contre, ce qui est important au-delà de l'implémentation, c'est de bien comprendre l'intérêt de SPF, DKIM et DMARC. Pour cela, nous avons mis en ligne un article et une vidéo à ce sujet (avec la présentation d'outils gratuits pour vous aider), en plus d'un tutoriel déjà en ligne depuis quelque temps et qui s'adresse aux administrateurs de Microsoft 365.
