I. Présentation

Que ce soit avec Office 365 et Exchange Online, ou une autre solution de messagerie, lorsque l'on parle d'e-mails, il y a deux termes qui reviennent encore et encore, constamment : sécurité et délivrabilité.

En tant qu’administrateur infrastructure, on souhaite éviter autant que possible de recevoir les mails de type spam, phishing, contenant des pièces jointes frauduleuses. Alors on met en place des filtres anti-phishing, antispam. On cherche aussi à sécuriser les e-mails au départ de notre serveur de messagerie, et faire en sorte qu’ils soient sains. Et puis on souhaite enfin s’assurer que nos mails passent les filtres de sécurité des serveurs de messagerie distants sans encombre, et arrivent directement dans la boîte mail du destinataire, sans passer par la case spam.

Avec Office 365, il y a plusieurs manières (complémentaires) d’arriver à nos fins. L’une d’entre elles est de passer par le trio gagnant des enregistrements DNS : « SPF », « DKIM » et « DMARC ».

II. Prérequis

• Avoir un serveur Exchange Online, et les licences Office365 associées
• Un nom de domaine enregistré
• Un nom de domaine configuré dans Office 365
• PowerShell en version 5.1 ou +

III. Pourquoi l’enregistrement SPF n’est pas suffisant ?

Bon, je vous vois venir, vous allez me dire que lorsque vous configurez un nouveau domaine dans Office 365, vous devez obligatoirement configurer un enregistrement SPF dans votre zone DNS, et que cet enregistrement sert déjà à améliorer la sécurité et la délivrabilité de vos mails. Alors, à quoi bon s’embêter avec DKIM et DMARC ?

On va la faire courte : SPF est bien entendu nécessaire, mais n’est absolument pas suffisant. C’est là que DKIM et DMARC entrent en jeu.

Je vous explique.

A. SPF – Comment ça marche ?

SPF (ou Sender Policy Framework) est une norme adoptée à l’international qui permet de réduire les spams au niveau de votre serveur.

Concrètement, l’enregistrement SPF sert à authentifier l’expéditeur d’un courrier électronique. Cela permet de vérifier que le serveur qui envoie un mail à partir d’une adresse mail en @mondomaine.com est bien un serveur légitime.

Le nom de domaine de l’émetteur est extrait de l’en-tête du mail reçu (« MAIL FROM : »), et une requête DNS est émise sur ce domaine pour connaître la liste des serveurs de messagerie légitimes qui peuvent émettre des mails pour ce domaine précis. On compare alors cette liste de serveurs à l’adresse IP du serveur qui a émis le message.

Par exemple dans mon cas, comme mes domaines sont configurés sur Office 365, seuls les serveurs Exchange Online du tenant Office 365 sont autorisés à envoyer des mails à mon nom.

Du coup, si jamais quelqu’un essaye de se faire passer pour moi en envoyant un mail en mon nom, son serveur ne sera pas reconnu comme légitime et le mail pourra donc être classifié comme mail frauduleux / spam.

SPF est donc devenu un indispensable pour :

• Augmenter la délivrabilité globale de ses mails
• Se défendre contre l’usurpation d’identité de domaine, ainsi que l’usurpation d’adresse électronique (mail)

Cependant, SPF ne sait pas gérer les transferts de mail, et c’est là que les enregistrements DKIM entrent en jeu.

B. SPF – Les bonnes pratiques

L’enregistrement SPF est un enregistrement dans votre zone DNS publique de type TXT qui contient la liste des serveurs de messagerie autorisés à envoyer un mail pour votre domaine.

Voici une bonne pratique à respecter en toute circonstance : incluez toujours vos serveurs sous la forme server.mondomaine.com, ne listez pas les adresses IP une par une.

A. Vérifier la configuration SPF

Vous pouvez vérifier la validité de votre enregistrement SPF en utilisant cet outil gratuit.

Renseignez dans le champ votre nom de domaine, puis cliquez sur le bouton « Valider DNS ».

Vous obtiendrez alors un résultat complet de l’analyse de votre enregistrement SPF.

Dans mon cas, ma configuration SPF est validée, et le serveur spf.protection.outlook.com (correspondant à Office 365) est bien celui qui est déclaré. Tout est parfait!

 

IV. Comprendre et configurer DKIM

A. DKIM – Comment ça marche ?

DKIM est un acronyme pour Domain Keys Identified Mail. Cette technologie permet d’envoyer un message chiffré, et de s’assurer que celui-ci n’a subi aucune altération durant sa transition entre le serveur émetteur et le serveur récepteur.

Rassurez-vous, le contenu du mail n’est pas chiffré, et votre destinataire pourra continuer à lire le message sans vous demander de clé de déchiffrement.

Au moment où vous envoyez votre mail, le serveur émetteur le chiffre via sa clé DKIM privée. Le serveur récepteur va lui vérifier la clé DKIM publique (l’enregistrement DKIM de votre zone DNS), et comparer celle-ci avec ce qu’il a reçu. Si le test est concluant, alors le serveur émetteur est bien qui il prétend être, l’identité de l’émetteur est prouvée et le mail peut donc être délivré dans la boîte mail du destinataire.

DKIM permet donc de s’affranchir des attaques de type « man in the middle ».

Note : Cette signature DKIM se gère dans l’en-tête du mail envoyé. Cela est donc transparent pour l’utilisateur final. Comme cette signature reste dans l’en-tête, cela permet de continuer à certifier l’exactitude du mail initial si celui-ci est transféré à une tierce personne.

 

B. Pourquoi DKIM est aujourd’hui indispensable ?

Je vous conseille fortement de mettre en place DKIM en plus de vos enregistrements SPF. Pourquoi ?

Parce que DKIM prouve que le contenu du mail ainsi que les en-têtes n’ont subi aucune altération : le mail est donc authentique et légitime : personne ne l'a envoyé à votre place, et le serveur de messagerie distant est maintenant en capacité de le vérifier.

C. Configuration de DKIM pour votre domaine

Tout d’abord, ouvrez une console PowerShell et commencez par vous connecter à votre serveur Exchange Online :

Import-Module ExchangeOnlineManagement

Connect-ExchangeOnline

Avant de commencer, vérifions ensemble que mondomaine.com soit bien déclaré comme un nom de domaine utilisable par Exchange :

Get-AcceptedDomain

Vous devriez voir mondomaine.com dans la liste.

Nous allons ensuite initialiser la configuration DKIM de notre nom de domaine mondomaine.com :

New-DkimSigningConfig -DomainName mondomaine.com -Enabled $false

 

Note : Vous pouvez utiliser le paramètre -Keysize 2048 dans la commande précédente, pour forcer la taille de votre clé DKIM à 2048 bits. Pas de panique toutefois, si vous ne l'avez pas fait, vous pourrez toujours y apporter des modifications plus tard en production.

Bien. Maintenant, il nous reste à générer les enregistrements DNS « DKIM » que nous devrons ajouter dans notre zone DNS publique.

Pour cela, tapez la commande :

Get-DkimSigningConfig -Identity mondomaine.com | Format-List Selector1CNAME, Selector2CNAME

Dans mon cas, je vais donc devoir créer 2 enregistrements CNAME sur ma zone DNS :

Prenons 30 secondes pour analyser la structure des enregistrements selector1 et selector2 à créer. Ces deux enregistrements se composent comme suit :

selector<id>-<domaine>-<extension>._domainkey.<tenantOffice365>.onmicrosoft.com

Pour le domaine mondomaine.com, cela donnerait donc :

• selector1-mondomaine-com._domainkey.mondomaine.onmicrosoft.com
• selector2-mondomaine-com._domainkey.mondomaine.onmicrosoft.com

Il ne nous reste plus qu'à créer ces deux enregistrements CNAME dans notre zone DNS avec le paramétrage suivant :

• Nom : selector1._domainkey & selector2._domainkey
• TTL : 3 600 secondes

Note : Pensez bien à ajouter un point (.) à la fin du nom de domaine, pour indiquer que vous souhaitez pointer vers selector1-mondomaine-com._domainkey.mondomaine.onmicrosoft.com (domaine externe).

 

Attendez maintenant quelques secondes, le temps que votre zone DNS se réplique, puis lancez la commande suivante afin d’activer l’utilisation de DKIM pour mondomaine.com.

Set-DkimSigningConfig -Identity mondomaine.com -Enabled $true

Note : Si vous obtenez une erreur, soit une faute s’est glissée dans votre enregistrement DNS de type CNAME (pensez à bien vérifier le point final), soit vous n’avez pas attendu assez longtemps pour que la réplication de votre zone DNS soit effectuée.

D. Vérifier la configuration DKIM

Pour vérifier la bonne configuration de DKIM sur votre domaine, je vous conseille d’utiliser ce lien.

Renseignez l’un des 2 sélecteurs configurés, ainsi que votre nom de domaine, puis cliquez sur le bouton « Valider DNS ».

Note : Ne saisissez que selector1, l'outil va compléter automatiquement le reste de l'enregistrement DNS. Si vous saisissez selector1._domainkey, le test échouera.

Vous pouvez donc voir que dans mon cas l’enregistrement DKIM du sélecteur 1 est valide.

Note : Pensez bien à refaire cette étape pour chacun des sélecteurs DKIM configurés pour votre domaine.

Vous pouvez également, lorsque vous êtes connectés à votre serveur Exchange en PowerShell, exécuter la commande suivante :

Get-DkimSigningConfig -Identity mondomaine.com

Je n'obtiens pas d'erreur, mon domaine est donc correctement configuré avec DKIM.

V. Comprendre & configurer DMARC

A. DMARC – Comment ça marche ?

DMARC est un acronyme pour Domain-based Message Authentication, Reporting, and Conformance. DMARC utilise SPF et DKIM pour authentifier les expéditeurs d’emails, et fournit une protection supplémentaire.

En effet, SPF et DKIM permettent d’authentifier un expéditeur (ou non). Mais ils ne donnent aucune indication sur la conduite à tenir dans le cas d’une usurpation d’identité avérée.

C’est là que DMARC entre en jeu : lorsqu’on configure cet enregistrement DNS, on lui indique une politique à tenir. Cela permet au serveur de messagerie de savoir quoi faire de ces mails : faut-il les rejeter ? les mettre en quarantaine ? Ne rien faire mais l’historiser ?

A vous de le décider, et ça se passe dans DMARC.

B. Configuration de DMARC pour votre domaine

Afin de configurer DMARC pour votre domaine, il n’est pas nécessaire de faire des manipulations PowerShell : tout se passe dans votre zone DNS.

Il vous faut créer l’enregistrement TXT suivant dans votre zone DNS :

• Type : TXT
• Nom : _dmarc
• TTL : 3 600 secondes
• Valeur : « v=DMARC1 ; p=<policy>; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s »

Quelques explications :

Pct=100 indique que cette règle s’applique à 100% des emails.

adkim=s indique que la règle d'alignement avec DKIM est stricte. Seuls les mails partant du domaine mondomaine.com sont valides. Les mails en provenance d'un sous-domaine de mondomaine.com ne sont pas considérés comme valides.

aspf=s indique que la règle d'alignement avec SPF est stricte. L'en-tête "De" du mail doit correspondre exactement au nom de domaine de la commande SMTP "MAIL FROM".

Le paramètre rua est optionnel. Si vous l'indiquez comme ici, cela permettra d'envoyer des rapports sur l'activité DMARC à l'adresse mail [email protected].

Vous pouvez remplacer <policy> par 3 valeurs. Il s’agit ici de configurer la stratégie à appliquer sur le serveur de messagerie si un mail est rejeté par DMARC :

• None : vous êtes en mode surveillance uniquement.
• Quarantine : les mails qui ne passent pas DMARC sont mis en quarantaine.
• Reject : les mails qui ne passent pas DMARC sont rejetés

Note : Je vous conseille de commencer par la stratégie none. Cela vous permet d’analyser l’impact de DMARC sur les mails reçus lorsque vous le passerez en mode quarantaine. On ne sait pas exactement la quantité de messages que l’on risque de perdre (non délivrés dans la boîte de réception du destinataire) via une stratégie DMARC restrictive, commencez donc par la stratégie de surveillance « none ».

C. Vérifier la configuration DMARC

Afin de vérifier que votre enregistrement DMARC est bien configuré sur votre zone, je vous invite à utiliser ce lien.

Renseignez alors le nom du domaine à vérifier, et cliquez sur le bouton « Valider DNS ».

Si vous avez suivi mes recommandations sur l’implémentation de DMARC, vous devriez donc avoir un enregistrement présent avec une stratégie de type « none ».

VI. Et si on regardait les en-têtes de nos mails ?

Avant de nous quitter, vérifions maintenant ce qui se passe dans l’en-tête des mails en sortie de notre serveur de messagerie.

Je me suis donc envoyé un mail de mon adresse [email protected] à mon adresse Gmail personnelle, puis j’ai affiché l’intégralité du message pour pouvoir consulter l’en-tête.

On peut voir que le mail a bien été envoyé à partir d’un serveur Exchange Office365, nommé FRA01-PR2-obe.outbound.protection.outlook.com, et qu’il a été réceptionné par le serveur mx.google.com.

On peut également voir 4 mentions importantes dans la section Authentication-Results :

• Dkim=pass
• Arc=pass
• Spf=pass
• Dmarc=pass

Ces mentions indiquent que la configuration SPF, DKIM et DMARC mise en place ensemble est fonctionnelle, et que ce mail est légitime. Autrement dit :

• Le serveur ayant envoyé le mail est bien un serveur autorisé et légitime pour envoyer des mails du domaine mondomaine.com
• Le mail a bien été envoyé par [email protected], il n’y a donc pas d’usurpation d’identité.

 

Note : On peut également voir deux points supplémentaires :

• L’échange du mail entre les deux serveurs de messagerie s’est bien effectué de façon sécurisée : le protocole TLS 1.2 a été utilisé pour cela.
• La politique DMARC actuellement mise en place pour ce domaine est sur « none », comme je vous le conseille dans un premier temps. Pour l’anecdote, elle va changer dans les prochains jours pour passer en « quarantine ».

VII. Conclusion

Vous n’avez maintenant plus aucune excuse pour ne pas correctement configurer vos enregistrements SPF, DKIM et DMARC.

Et si vous êtes amenés à expliquer à vos collègues ou à votre DSI l’intérêt de configurer ces enregistrements, retenez simplement que cela :

• Renforce la protection antispam & anti-phishing
• Augmente la sécurité de votre serveur de messagerie
• Permets de contrer les attaques « man in the middle » ainsi que l’usurpation de domaine et l’usurpation d’identité
• Favorise la délivrabilité de vos mails

Sachez engin que Google, Microsoft et Yahoo travaille sur un nouveau standard pour toujours plus renforcer la sécurité et la délivrabilité des mails, j’ai nommé BIMI.

The post Office 365 : comment améliorer la délivrabilité et la sécurité de vos e-mails ? first appeared on IT-Connect.

I. Présentation

Ça y est, vous êtes fin prêts à abandonner votre serveur Exchange On Premise (hébergé chez vous), pour migrer vers un serveur Exchange Online.

C’est d’ailleurs dans votre intérêt si vous n’avez pas les compétences en interne pour maintenir ce serveur au quotidien, au vu des dernières failles de sécurité identifiées sur Exchange. L’avantage avec Exchange Online, c’est que c’est Microsoft qui s’occupe de tout.

Enfin presque tout. Car le paramétrage du serveur reste à votre charge. Normal, me direz-vous.

Dans cet article, je vais m’attarder sur la bonne manière de configurer les enregistrements DNS d’Exchange Online. Mais on ne traitera pas de toute la configuration du serveur, car ça pourrait faire un cours complet. ?

II. Prérequis

Pour suivre ce tutoriel, il vous faudra respecter plusieurs prérequis :

• Déjà, avoir un serveur Exchange Online prêt à l’emploi, c'est-à-dire un abonnement Office 365 avec la messagerie.
• Posséder les licences Office365 nécessaires pour l’utilisation de la messagerie. Si votre entreprise a opté pour un pack de licences (E3, E5), c’est déjà dedans.
• Un nom de domaine enregistré au nom de votre entreprise ou à votre propre nom, et sur lequel vous avez la main pour modifier la zone DNS.
• PowerShell en version 5.1 ou +

Si vous partez de zéro, consultez directement ce tutoriel : comment créer un tenant Office 365 / Microsoft 365 ?

III. Configurer un nouveau domaine (via le centre d'administration)

Pour pouvoir envoyer des mails via un domaine personnalisé, il faut commencer par le déclarer dans Exchange Online.

Connectez-vous sur le centre d’administration de votre tenant Microsoft 365 : admin.microsoft.com, puis allez dans le menu Paramètres, puis Domaines.

Cliquez sur le bouton Ajouter un domaine, et renseignez le nom de domaine à ajouter. Par exemple : mondomaine.com.

On vous demande alors de valider que vous êtes bien le propriétaire de ce nom de domaine. Comment faire ? Plusieurs méthodes s’offrent à vous. Je vous recommande personnellement la première : l’ajout d’un enregistrement TXT à votre zone DNS. Simple et efficace.

L’utilitaire de configuration va essayer de détecter le fournisseur d’hébergement DNS, autrement dit le fournisseur chez qui vous avez acheté votre nom de domaine et chez qui vous vous connectez pour modifier votre zone DNS. Dans notre cas, il s’agit d’Azure, mais vous pouvez très bien le modifier manuellement si la détection n’a pas fait correctement son job.

On vous donne alors les informations à ajouter dans votre nouvel enregistrement TXT sur votre zone DNS :

• Nom TXT
  • @ (ou ignorer s'il n'est pas pris en charge par le fournisseur)
• Valeur TXT
  • MS=ms57389148
• Durée de vie
  • 3600 secondes (ou la valeur par défaut de votre fournisseur)

La procédure exacte pour ajouter cet enregistrement chez votre registrar DNS peut changer en fonction de chez qui vous êtes. Pour l’exemple, je vais vous montrer comment faire sur l’interface de Gandi. Bien sûr, les menus peuvent être différents en fonction de votre fournisseur.

Une fois sur la zone DNS de votre nom de domaine, cliquez sur le bouton Ajouter, puis choisissez TXT comme type d’enregistrement DNS :

Configurer la valeur TTL (Time To Live, ou Durée De Vie) à la valeur préconisée par Microsoft, soit : 3600 secondes.

Mettre @ ou laisser vide le nom de votre enregistrement DNS. Ce point peut différer en fonction de votre interface de gestion DNS.

Enfin dans la zone de texte, renseignez la valeur donnée par Microsoft, soit : MS=ms67153608

Une fois l’enregistrement créé, retournez sur l’interface de Microsoft, et cliquez sur le bouton Vérifier.

Si la propriété du nom de domaine est vérifiée, vous passez à l’étape suivante de configuration. Sinon, vous obtiendrez une erreur. En règle générale, l’erreur vient d’un mauvais enregistrement TXT : vous avez pu oublier le @ ou faire un mauvais copier / coller.

Cliquez sur Continuer.

Pour que les mails en provenance et à destination de votre nom de domaine puissent être correctement routés par Microsoft 365, vous avez encore quelques étapes à respecter : Configurer dans votre zone DNS les enregistrements MX, CNAME, TXT.

L’enregistrement MX indique quel est le serveur de messagerie, et indique également la priorité associée à chaque serveur s’il y en a plusieurs. Cela permet de dire via votre zone DNS quel est votre serveur de messagerie préféré, et également de configurer un serveur de messagerie secondaire.

Comme tout à l’heure, créez un nouvel enregistrement dans votre zone DNS, mais cette fois de type MX.

Créez ensuite les enregistrements CNAME et TXT demandés :

L’enregistrement CNAME « autodiscover » permet de faciliter la configuration de votre client de messagerie Outlook : il suffit d’entrer le nom de l’utilisateur et son mot de passe et la configuration serveur s’effectue automatiquement.

ATTENTION : La valeur à renseigner est bien autodiscover.outlook.com. avec un point à la fin. Cela indique à votre zone DNS que vous pointez vers une autre zone DNS, soit dans notre cas l’enregistrement autodiscover.outlook.com. Si vous oubliez le point à la fin, vous pointerez alors sur autodiscover.outlook.com.votrezonedns.extension. Ce qui ne fonctionnera pas.

L’enregistrement TXT est ce qu’on appelle un enregistrement SPF.

Vérifiez les enregistrements une fois que vous êtes prêts. Microsoft va alors interroger vos serveurs DNS pour vérifier la conformité des enregistrements, et vous remonte les erreurs s’il y en a. Par exemple, dans mon cas :

Là c’est plutôt explicite : un enregistrement SPF existait déjà sur ma zone DNS, automatiquement ajouté par Gandi. Il me reste à le supprimer et on sera bon.

NOTE : Vous pouvez aussi être amenés à supprimer des enregistrements de type MX, automatiquement ajoutés sur votre zone DNS.

Tous vos enregistrements DNS devraient maintenant être valides.

IV. Configurer un nouveau domaine (via PowerShell)

Pour effectuer la même manipulation sous PowerShell, une fois connecté à votre tenant Microsoft 365 via PowerShell, tapez la commande suivante :

New-MsolDomain -Name "mondomaine.com"

On demande ensuite les enregistrements DNS pour procéder à la vérification de la propriété du domaine :

Get-MsolDomainVerificationDns -DomainName "mondomaine.com" -Mode DnsTxtRecord

Comme dans la procédure manuelle, on se connecte sur notre espace de gestion Noms de domaine / Zones DNS, pour ajouter l’enregistrement TXT validant la propriété du nom de domaine.

On vérifie ensuite la propriété :

Confirm-MsolDomain -DomainName "mondomaine.com"

À ce stade, ce n’est plus si évident de récupérer les enregistrements MX, CNAME, et SPF pour les configurer ensuite dans votre zone DNS. Il est préférable de finir cette partie-là à la main.

Mais si vous êtes comme moi, et que vous aimez bien tout automatiser alors la suite est pour vous.

Vous aurez besoin du module AzureAD sur votre PC.

Install-Module AzureAD

Import-Module AzureAD

Connectez-vous ensuite à votre AzureAD :

Connect-AzureAD

Tapez la commande suivante pour récupérer les informations permettant de créer les enregistrements MX, CNAME et TXT :

Get-AzureADDomainServiceConfigurationRecord -Name coosol.net | Select Label, RecordType, Ttl, MailExchange, Preference, Text, CanonicalName

Si le label correspond à votre nom de domaine, lorsque vous ajouterez cet enregistrement DNS, cela correspond au @.

ATTENTION : Sur l’enregistrement CNAME, il vous faudra ajouter un point à autodiscover.outlook.com, sinon vous vous retrouverez avec un enregistrement du type autodiscover.outlook.com.mondomaine.com ce qui n’est pas du tout ce que vous souhaitez.

 

V. Script PowerShell - Récupérer les enregistrements DNS à créer

Pour aller encore plus loin, voici un script qui vous retourne en sortie un tableau propre des enregistrements DNS à ajouter dans votre zone DNS.

On réutilise les mêmes commandes que précédemment, mais cette fois on reformate les données pour que ce soit plus lisible en sortie.

#Install-Module AzureAD -Force
Import-Module AzureAD
Connect-AzureAD -Credential (Get-Credential)
$domain = "coosol.net"
$result = @()
$DNSRecords = (Get-AzureADDomainServiceConfigurationRecord -Name $domain | Select Label, RecordType, Ttl, MailExchange, Preference, Text, CanonicalName)
Foreach ($DNSRecord in $DNSRecords) {
    if ($DNSRecord.Label -eq $domain) {
        $Label = "@"
    }
    else {
        $Label = $DNSRecord.Label
    }
    $ttl = $DNSRecord.ttl + " secondes"
    switch ( $DNSRecord.RecordType )
    {
        Mx
        {
            #Enregistrement DNS de type MX
            $result += [PSCustomObject]@{
                Type = "MX"
                TTL = $ttl
                Nom = $Label
                Priorite = $DNSRecord.Preference
                Valeur = $DNSRecord.MailExchange
            }
        }
        Txt
        {
            #Enregistrement DNS de type TXT (SPF)
            $result += [PSCustomObject]@{
                Type = "TXT"
                TTL = $ttl
                Nom = $Label
                Valeur = $DNSRecord.Text
            }
        }
        Cname
        {
            #Enregistrement DNS de type CNAME
            $Valeur = $DNSRecord.CanonicalName + "."
            $result += [PSCustomObject]@{
                Type = "CNAME"
                TTL = $ttl
                Nom = "autodiscover"
                Valeur = $Valeur
            }
        }
    }
}
Clear-Host
Write-Output "Enregistrements DNS à créer :`n"
Write-Output $result

 

VI. Comment vérifier l'intégrité d'un nom de domaine sur Office 365 ?

À partir du centre d’administration admin.microsoft.com, allez dans Paramètres, puis dans Domaines.

Sélectionnez un domaine, cliquez sur le bouton Options (les 3 petits points), puis cliquez sur Vérifier l’état d’intégrité. Tous vos enregistrements devraient être au vert :

VII. À quoi sert un enregistrement SPF ?

Le sigle SPF veut dire Sender Policy Framework. Concrètement, et sans rentrer dans les détails, cet enregistrement SPF est couramment utilisé pour sécuriser nos serveurs de messagerie, plus particulièrement pour vérifier les adresses des expéditeurs.

Cela permet de vérifier qu’un email [email protected] provient bien du serveur de messagerie configuré pour relayer les mails du domaine mondomaine.com.

Cette vérification est effectuée en arrière-plan par le serveur de messagerie et n’est en aucun cas visible de l’utilisateur final.

VIII. Conclusion

Félicitations ! Vous avez configuré votre premier domaine sur Office365. Vous pouvez maintenant créer de nouvelles boîtes de messagerie et commencer à envoyer des mails.

Mais si vous souhaitez sécuriser un peu plus votre envoi / réception de mails, je vous invite à configurer également vos enregistrements DNS DKIM / DMARC.

The post Comment ajouter un nouveau domaine dans Office 365 ? first appeared on IT-Connect.

Au sein de son Patch Tuesday d'Avril 2021, Microsoft avait corrigé quatre vulnérabilités Exchange découvertes par la NSA. Il s'avère que l'une d'entre elle dispose désormais de sa propre documentation technique et d'un PoC pour l'exploiter.

Un exploit est disponible sur GitHub pour montrer que la faille référencée sous le nom CVE-2021-28482 est réelle et exploitable. Il s'agit de la faille la moins grave parmi les 4 vulnérabilités découvertes par la NSA car elle nécessite une authentification, mais il ne faut pas la négliger pour autant.

Le chercheur en sécurité Nguyen Jang a publié un PoC écrit en Python sur son GitHub, dans le but de montrer qu'il est possible d'exploiter la faille CVE-2021-28482. Un code validé par Will Dormann, un analyste en vulnérabilité pour le CERT/CC aux États-Unis. Concrètement, un attaquant peut exploiter cette faille en étant authentifié sur un serveur Exchange où les mises à jour d'avril ne sont pas installées.

En soi, la faille CVE-2021-28482 n'est pas aussi critique que les vulnérabilités ProxyLogon car elle ne permet pas d'effectuer une attaque massive puisqu'il faut s'authentifier sur le serveur de messagerie. Néanmoins, elle peut tout à fait être exploitée dans le cas d'une attaque ciblée : il suffit à l'attaquant de récupérer le compte d'un utilisateur standard pour passer cette barrière liée à l'authentification.

Rappelons également que Nguyen Jang est déjà à l'origine d'un PoC permettant d'exploiter les failles ProxyLogon.

Cette fois encore, il est indispensable de mettre à jour rapidement vos serveurs Exchange. Les correctifs contre la faille ProxyLogon d'une part, mais aussi les correctifs du Patch Tuesday d'Avril 2021 pour corriger les quatre failles Exchange révélées par la NSA. Il est vrai que depuis quelques mois, il est devenu fréquent que des failles critiques soient révélées au sein de Microsoft Exchange et cela pousse les entreprises à adopter un rythme élevé pour les mises à jour.

Source

The post Microsoft Exchange : attention, la faille CVE-2021-28482 dispose d’un exploit first appeared on IT-Connect.

Bulletin d’actualité du 19/04/2021 Nous voici de nouveau ensemble dans notre rendez-vous du vendredi pour revenir sur les différents bulletins de sécurité publiés par le CERT-FR ! Durant la période du 12 avril au 18 avril 2021, le CERT-FR (Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques en France) a publié un …