Comment configurer les rapports MTA-STS et TLS pour votre domaine à l'aide d'Apache sur Ubuntu 18.04

De Get Docs
Aller à :navigation, rechercher

L'auteur a sélectionné Electronic Frontier Foundation Inc pour recevoir un don dans le cadre du programme Write for DOnations.

Introduction

Mail Transport Agent Strict Transport Security (MTA-STS) est une nouvelle norme Internet qui vous permet d'activer le protocole TLS strict pour les e-mails envoyés entre les fournisseurs de messagerie pris en charge. Il est similaire à HTTP Strict Transport Security (HSTS), où une politique force-TLS est définie puis mise en cache pendant une durée spécifiée, réduisant le risque d'attaques de type "man-in-the-middle" ou de rétrogradation. .

MTA-STS est complété par SMTP TLS Reporting (TLSRPT), qui vous donne un aperçu des e-mails qui sont livrés avec succès via TLS et de ceux qui ne le sont pas. TLSRPT est similaire au rapport DMARC, mais pour TLS.

La principale raison de la mise en œuvre de MTA-STS pour votre domaine est de garantir que les e-mails confidentiels qui vous sont envoyés sont transmis en toute sécurité via TLS. D'autres méthodes pour encourager TLS pour les communications par e-mail, telles que STARTTLS, sont toujours sensibles aux attaques de l'homme du milieu, car la connexion initiale n'est pas chiffrée. MTA-STS aide à garantir qu'une fois qu'au moins une connexion sécurisée a été établie, TLS sera utilisé par défaut à partir de là, ce qui réduit considérablement le risque de ces attaques.

Un exemple de cas d'utilisation pour MTA-STS et TLS Reporting est d'aider à créer un système de messagerie de service client sécurisé pour votre entreprise. Les clients peuvent envoyer des tickets d'assistance par e-mail contenant des informations personnelles confidentielles, qui nécessitent une connexion TLS sécurisée. MTA-STS aide à assurer la sécurité de la connexion, et TLSRPT fournira des rapports quotidiens identifiant tous les e-mails qui n'ont pas été envoyés en toute sécurité, donnant un aperçu crucial de toute attaque en cours ou antérieure contre votre système de messagerie.

Dans ce didacticiel, vous apprendrez à configurer MTA-STS et TLSRPT pour votre nom de domaine, puis à interpréter votre premier rapport TLS. Bien que ce didacticiel couvre les étapes d'utilisation d'Apache sur Ubuntu 18.04 avec un certificat Let's Encrypt, la configuration MTA-STS/TLSRPT fonctionnera également sur des alternatives, telles que Nginx sur Debian.

Conditions préalables

Avant de commencer ce guide, vous aurez besoin de :

  • Un nom de domaine déjà configuré pour recevoir des e-mails, utilisant soit votre propre serveur de messagerie, soit un service de messagerie hébergé, tel que G Suite ou Office 365. Ce didacticiel utilisera your-domain tout au long, mais cela devrait être remplacé par votre propre nom de domaine. Vous devrez configurer un sous-domaine dans le cadre du didacticiel, assurez-vous donc que vous pouvez accéder aux paramètres DNS de votre domaine.
  • Un serveur Ubuntu 18.04 configuré en suivant la configuration initiale du serveur avec Ubuntu 18.04, y compris un utilisateur sudo non root.
  • Un serveur Web Apache installé et configuré en suivant Comment installer le serveur Web Apache sur Ubuntu 18.04.
  • Un client Certbot configuré afin d'acquérir un certificat Let's Encrypt, en suivant Comment sécuriser Apache avec Let's Encrypt sur Ubuntu 18.04.

Une fois que vous les avez prêts, connectez-vous à votre serveur en tant qu'utilisateur non root pour commencer.

Remarque : Une fois que vous avez terminé les étapes de mise en œuvre pour MTA-STS et TLSRPT, vous devrez peut-être attendre jusqu'à 24 heures pour recevoir votre premier rapport TLS. En effet, la plupart des fournisseurs de messagerie envoient des rapports une fois par jour. Vous pouvez reprendre le didacticiel à partir de l'étape 5 une fois que vous avez reçu votre premier rapport.


Étape 1 - Création d'un fichier de stratégie MTA-STS

MTA-STS est activé et configuré à l'aide d'un fichier de configuration en texte brut que vous hébergez sur votre site Web. Les serveurs de messagerie pris en charge se connecteront alors automatiquement à votre site Web pour récupérer le fichier, ce qui entraînera l'activation de MTA-STS. Dans cette première étape, vous comprendrez les options disponibles pour ce fichier et choisirez la plus appropriée pour votre fichier.

Tout d'abord, ouvrez un nouveau fichier texte dans votre répertoire personnel afin d'avoir un endroit où noter la configuration souhaitée :

nano mta-sts.txt

Nous allons d'abord passer en revue un exemple, puis vous écrirez votre propre fichier de configuration.

Voici un exemple de fichier de configuration MTA-STS :

Exemple de fichier de configuration MTA-STS

version: STSv1
mode: enforce
mx: mail1.your-domain
mx: mail2.your-domain
max_age: 604800

Cet exemple de fichier de configuration spécifie que tous les e-mails livrés à mail1.your-domain et mail2.your-domain à partir de fournisseurs pris en charge doivent être livrés via une connexion TLS valide. Si une connexion TLS valide ne peut pas être établie avec votre serveur de messagerie (par exemple, si le certificat a expiré ou est auto-signé), l'e-mail ne sera pas livré.

Cela rendra beaucoup plus difficile pour un attaquant d'intercepter et d'espionner/modifier votre e-mail dans une situation comme une attaque de l'homme du milieu. En effet, l'activation correcte de MTA-STS permet uniquement la transmission d'e-mails via une connexion TLS valide, ce qui nécessite un certificat TLS valide. Il serait difficile pour un attaquant d'acquérir un tel certificat, car cela nécessite généralement un accès privilégié à votre nom de domaine et/ou site Web.

Comme indiqué dans l'exemple précédent dans cette étape, le fichier de configuration se compose d'un certain nombre de paires clé/valeur :

  • version :
    • Objectif : spécifier la version de la spécification MTA-STS à utiliser.
    • Valeurs acceptées : actuellement, la seule valeur acceptée est STSv1.
    • Exemple : version: STSv1
  • mode :
    • Objectif : spécifiez dans quel mode MTA-STS doit être activé.
    • Valeurs acceptées : appliquer : forcer tous les e-mails entrants des fournisseurs pris en charge à utiliser un TLS valide. test : mode de rapport uniquement. les e-mails ne seront pas bloqués, mais les rapports TLSRPT seront toujours envoyés. aucun : désactive MTA-STS.
    • Exemple : mode: enforce
  • mx :
    • Objectif : spécifier les serveurs de messagerie autorisés à gérer les e-mails pour votre domaine. Cela doit correspondre aux serveurs spécifiés dans vos enregistrements mx.
    • Valeurs acceptées : nom de domaine complet d'un serveur de messagerie ou d'un hôte générique. Plusieurs valeurs mx: doivent être utilisées pour spécifier plusieurs serveurs de messagerie.
    • Exemple : mx: mail1.your-domain, mx: mail2.your-domain, mx: *.example.org
  • max_age :
    • Objectif : spécifier la durée de vie maximale de la stratégie MTA-STS, en secondes.
    • Valeurs acceptées : tout entier positif jusqu'à 31557600.
    • Exemple : max_age: 604800 (1 semaine)

Vous pouvez également consulter la spécification officielle des paires clé/valeur dans Section 3.2 du MTA-STS RFC.

Avertissement : L'activation de MTA-STS en mode enforce peut entraîner la non-distribution inattendue de certains e-mails. Au lieu de cela, il est recommandé d'utiliser mode: testing et une faible valeur max_age: dans un premier temps, afin de s'assurer que tout fonctionne correctement avant d'activer complètement MTA-STS.


À l'aide du fichier d'exemple précédent dans l'étape, ainsi que des exemples de paire clé/valeur précédents, écrivez le fichier de stratégie MTA-STS souhaité et enregistrez-le dans le fichier que vous avez créé au début de l'étape.

L'exemple de fichier suivant est idéal pour tester MTA-STS, car il ne bloquera aucun e-mail de manière inattendue et a un max_age de seulement 1 jour, ce qui signifie que si vous décidez de le désactiver, la configuration expirer rapidement. Notez que certains fournisseurs de messagerie n'enverront des rapports TLSRPT que si max_age est supérieur à 1 jour, c'est pourquoi 86401 secondes est un bon choix (1 jour et 1 seconde).

Exemple de fichier de configuration de test MTA-STS

version: STSv1
mode: testing
mx: mail1.your-domain
mx: mail2.your-domain
max_age: 86401

Dans cette étape, vous avez créé le fichier de configuration MTA-STS souhaité et l'avez enregistré dans votre zone d'accueil. Dans l'étape suivante, vous allez configurer un serveur Web Apache pour servir le fichier au format correct.

Étape 2 - Configuration d'Apache pour servir votre fichier de stratégie MTA-STS

Dans cette étape, vous allez configurer un hôte virtuel Apache pour servir votre fichier de configuration MTA-STS, puis ajouter un enregistrement DNS pour permettre l'accès au site à partir d'un sous-domaine.

Pour que votre fichier de configuration MTA-STS soit automatiquement découvert par les serveurs de messagerie, il doit être servi exactement au bon chemin : https://mta-sts.your-domain/.well-known/mta-sts.txt. Vous devez utiliser le sous-domaine mta-sts sur HTTPS et le chemin /.well-known/mta-sts.txt, sinon votre configuration ne fonctionnera pas.

Ceci peut être réalisé en créant un nouvel hôte virtuel Apache pour le sous-domaine mta-sts, qui servira le fichier de stratégie MTA-STS. Cette étape s'appuie sur la configuration de base que vous aurez configurée à l'étape préalable Comment installer le serveur Web Apache sur Ubuntu 18.04.

Tout d'abord, créez un répertoire pour votre hôte virtuel :

sudo mkdir /var/www/mta-sts

Si vous hébergez plusieurs domaines différents sur votre serveur Web, il est recommandé d'utiliser un hôte virtuel MTA-STS différent pour chacun, par exemple /var/www/mta-sts-site1 et /var/www/mta-sts-site2.

Ensuite, vous devez créer le répertoire .well-known, où sera stocké votre fichier de configuration MTA-STS. .well-known est un répertoire standardisé pour les fichiers « bien connus », tels que les fichiers de validation de certificat TLS, security.txt, etc.

sudo mkdir /var/www/mta-sts/.well-known

Vous pouvez maintenant déplacer le fichier de stratégie MTA-STS que vous avez créé à l'étape 1 dans le répertoire du serveur Web que vous venez de créer :

sudo mv ~/mta-sts.txt /var/www/mta-sts/.well-known/mta-sts.txt

Vous pouvez vérifier que le fichier a bien été copié si vous le souhaitez :

cat /var/www/mta-sts/.well-known/mta-sts.txt

Cela affichera le contenu du fichier que vous avez créé à l'étape 1.

Pour qu'Apache serve le fichier, vous devez configurer le nouvel hôte virtuel et l'activer. MTA-STS ne fonctionne que sur HTTPS, vous utiliserez donc exclusivement le port 443 (HTTPS), plutôt que d'utiliser également le port 80 (HTTP).

Tout d'abord, créez un nouveau fichier de configuration d'hôte virtuel :

sudo nano /etc/apache2/sites-available/mta-sts.conf

Comme avec le répertoire d'hôte virtuel, si vous hébergez plusieurs domaines différents sur le même serveur Web, il est recommandé d'utiliser un nom d'hôte virtuel différent pour chacun.

Ensuite, copiez l'exemple de configuration suivant dans le fichier et renseignez les variables si nécessaire :

~/etc/apache2/sites-available/mta-sts.conf

<IfModule mod_ssl.c>
<VirtualHost your-server-ipv4-address:443 [your-server-ipv6-address]:443>
    ServerName mta-sts.your-domain
    DocumentRoot /var/www/mta-sts

    ErrorDocument 403 "403 Forbidden - This site is used to specify the MTA-STS policy for this domain, please see '/.well-known/mta-sts.txt'. If you were not expecting to see this, please use <a href=\"https://your-domain\" rel=\"noopener\">https://your-domain</a> instead."

    RewriteEngine On
    RewriteOptions IgnoreInherit
    RewriteRule !^/.well-known/mta-sts.txt - [L,R=403]

    SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
    SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Cette configuration créera l'hôte virtuel mta-sts, qui sera servi sur mta-sts.your-domain. Il redirigera également toutes les demandes, à l'exception de celles vers le fichier mta-sts.txt lui-même, vers une page d'erreur 403 Forbidden personnalisée, avec une explication conviviale de l'objet du site de sous-domaine. Cela permet de s'assurer que tout visiteur qui tombe accidentellement sur votre site MTA-STS ne soit pas confus par inadvertance.

Actuellement, un certificat TLS auto-signé est utilisé. Ce n'est pas idéal, car un certificat entièrement valide/de confiance est requis pour que MTA-STS fonctionne correctement. À l'étape 3, vous allez acquérir un certificat TLS à l'aide de Let's Encrypt.

Ensuite, assurez-vous que les modules Apache requis sont activés :

sudo a2enmod rewrite ssl

Après cela, activez le nouvel hôte virtuel :

sudo a2ensite mta-sts

Ensuite, exécutez une vérification de la syntaxe des fichiers de configuration d'Apache pour vous assurer qu'il n'y a pas d'erreurs inattendues :

sudo apachectl configtest

Lorsque le test réussit sans erreur, vous pouvez redémarrer Apache pour activer complètement le nouvel hôte virtuel :

sudo service apache2 restart

Maintenant que l'hôte virtuel Apache a été installé et configuré, vous devez créer le ou les enregistrements DNS requis pour lui permettre d'y accéder à l'aide du nom de domaine complet mta-sts.your-domain.

La façon dont cela se fait dépend du fournisseur d'hébergement DNS que vous utilisez. Cependant, si vous utilisez DigitalOcean comme fournisseur DNS, accédez simplement à votre projet, puis cliquez sur votre domaine.

Enfin, ajoutez les enregistrements DNS requis pour le sous-domaine mta-sts. Si votre Droplet utilise uniquement IPv4, créez un enregistrement A pour mta-sts, pointant vers your-server-ipv4-address. Si vous utilisez également IPv6, créez un enregistrement AAAA pointant vers your-server-ipv6-address.

Au cours de cette étape, vous avez créé et configuré un nouvel hôte virtuel Apache pour votre sous-domaine MTA-STS, puis ajouté le ou les enregistrements DNS requis pour lui permettre d'y accéder facilement. À l'étape suivante, vous acquerrez un certificat Let's Encrypt de confiance pour votre sous-domaine MTA-STS.

Étape 3 - Acquisition d'un certificat Let's Encrypt pour votre sous-domaine MTA-STS

Au cours de cette étape, vous allez acquérir un certificat TLS auprès de Let's Encrypt, pour permettre à votre site mta-sts.your-domain d'être correctement servi via HTTPS.

Pour ce faire, vous utiliserez certbot, que vous avez configuré dans le cadre de l'étape préalable Comment sécuriser Apache avec Let's Encrypt sur Ubuntu 18.04.

Tout d'abord, exécutez certbot pour émettre un certificat pour votre sous-domaine mta-sts en utilisant la méthode de vérification du plugin Apache :

sudo certbot --apache -d mta-sts.your-domain

Cela émettra automatiquement un certificat de confiance et l'installera sur votre serveur Web Apache. Lorsque l'assistant Certbot vous demande de configurer une redirection HTTP -> HTTPS, sélectionnez "Non", car cela n'est pas requis pour MTA-STS.

Pour finir, testez votre nouvel hôte virtuel pour vous assurer qu'il fonctionne correctement. Utilisez un navigateur Web pour visiter https://mta-sts.your-domain/.well-known/mta-sts.txt, ou utilisez un outil de ligne de commande tel que curl :

curl https://mta-sts.your-domain/.well-known/mta-sts.txt

Cela produira le fichier de stratégie MTA-STS que vous avez créé à l'étape 1 :

Outputversion: STSv1
mode: testing
mx: mail1.your-domain
mx: mail2.your-domain
max_age: 86401

Si une erreur se produit, assurez-vous que la configuration de l'hôte virtuel de l'étape 2 est correcte et que vous avez ajouté un enregistrement DNS pour le sous-domaine mta-sts.

Au cours de cette étape, vous avez émis un certificat Let's Encrypt TLS pour votre sous-domaine mta-sts et testé qu'il fonctionne. Ensuite, vous allez définir des enregistrements DNS TXT pour activer pleinement MTA-STS et TLSRPT.

Étape 4 - Configuration des enregistrements DNS requis pour activer MTA-STS et TLSRPT

Dans cette étape, vous allez configurer deux enregistrements DNS TXT, qui activeront entièrement la stratégie MTA-STS que vous avez déjà créée, et activeront également la création de rapports TLS (TLSRPT).

Ces enregistrements DNS peuvent être configurés à l'aide de n'importe quel fournisseur d'hébergement DNS, mais dans cet exemple, DigitalOcean est utilisé comme fournisseur.

Tout d'abord, connectez-vous à votre panneau de contrôle DigitalOcean et accédez à votre projet, puis cliquez sur votre domaine.

Vous devez ensuite ajouter les deux enregistrements TXT suivants :

_mta-sts.your-domain IN TXT "v=STSv1; id=id-value"
_smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=reporting-address"

id-value est une chaîne utilisée pour identifier la version de votre politique MTA-STS en place. Si vous mettez à jour votre stratégie, vous devrez également mettre à jour la valeur id pour vous assurer que la nouvelle version est détectée par les fournisseurs de messagerie. Il est recommandé d'utiliser l'horodatage actuel comme id, par exemple 20190811231231 (23:12:31 le 11 août 2019).

reporting-address est l'adresse à laquelle vos rapports TLS seront envoyés. Il peut s'agir soit d'une adresse e-mail précédée de mailto:, soit d'un URI Web, par exemple pour une API qui collecte des rapports. L'adresse de rapport ne doit pas nécessairement être une adresse sur your-domain. Vous pouvez utiliser un domaine complètement différent si vous le souhaitez.

Par exemple, les deux exemples d'enregistrements suivants sont tous deux valides :

_mta-sts.your-domain IN TXT "v=STSv1; id=20190811231231"
_smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Ajustez les variables selon vos besoins et définissez ces enregistrements DNS TXT dans votre panneau de configuration DigitalOcean (ou quel que soit le fournisseur DNS que vous utilisez) :

Une fois ces enregistrements DNS définis et propagés, MTA-STS sera activé avec la stratégie que vous avez créée à l'étape 1 et commencera à recevoir des rapports TLSRPT à l'adresse que vous avez spécifiée.

Dans cette étape, vous avez configuré les enregistrements DNS requis pour que MTA-STS soit activé. Ensuite, vous recevrez puis interpréterez votre premier rapport TLSRPT.

Étape 5 - Interpréter votre premier rapport TLSRPT

Maintenant que vous avez activé MTA-STS et TLSRPT (TLS Reporting) pour votre domaine, vous commencerez à recevoir des rapports des fournisseurs de messagerie pris en charge. Ces rapports indiqueront le nombre d'e-mails qui ont été ou n'ont pas été livrés avec succès via TLS, et les raisons des erreurs.

Différents fournisseurs de messagerie envoient leurs rapports à des moments différents ; par exemple, Google Mail envoie ses rapports quotidiennement vers 10h00 UTC.

Selon la manière dont vous avez configuré l'enregistrement DNS TLSRPT à l'étape 5, vous recevrez vos rapports par e-mail ou via une API Web. Ce didacticiel se concentre sur la méthode de courrier électronique, car c'est la configuration la plus courante.

Si vous venez de terminer le reste de ce didacticiel, attendez de recevoir votre premier rapport, puis vous pourrez reprendre.

Votre rapport TLSRPT quotidien par e-mail aura généralement une ligne d'objet semblable à celle-ci :

Report Domain: your-domain Submitter: google.com Report-ID: <[email protected]>

Cet e-mail contiendra une pièce jointe au format .gz, qui est une archive compressée Gzip, avec un nom de fichier similaire au suivant :

google.com!your-domain!1565222400!1565308799!001.json.gz

Pour le reste de ce didacticiel, ce fichier sera appelé report.json.gz.

Enregistrez ce fichier sur votre ordinateur local et extrayez-le à l'aide de l'outil de votre choix.

Si vous utilisez un système Linux basé sur Debian, vous pourrez exécuter la commande gzip -d pour décompresser l'archive :

gzip -d report.json.gz

Cela se traduira par un fichier JSON appelé report.json.

Ensuite, vous pouvez afficher le rapport soit directement en tant que chaîne JSON brute, soit utiliser votre embellisseur JSON préféré pour le mettre dans un format plus lisible. Dans cet exemple, jq sera utilisé, mais vous pouvez également utiliser json.tool de Python si vous le souhaitez.

Remarque : Si vous n'avez pas installé jq, vous pouvez l'installer à l'aide de apt install jq. Ou, pour d'autres systèmes d'exploitation, utilisez les instructions d'installation nécessaires de jq.


jq . report.json

Cela affichera quelque chose de similaire à ce qui suit :

Prettified report.json{
    "organization-name": "Google Inc.",
    "date-range": {
        "start-datetime": "2019-08-10T00:00:00Z",
        "end-datetime": "2019-08-10T23:59:59Z"
    },
    "contact-info": "[email protected]",
    "report-id": "2019-08-10T00:00:00Z_your-domain",
    "policies": [
        {
            "policy": {
                "policy-type": "sts",
                "policy-string": [
                    "version: STSv1",
                    "mode: testing",
                    "mx: mail1.your-domain",
                    "mx: mail2.your-domain",
                    "max_age: 86401"
                ],
                "policy-domain": "your-domain"
            },
            "summary": {
                "total-successful-session-count": 230,
                "total-failure-session-count": 0
            }
        }
    ]
}

Le rapport indique le fournisseur qui a généré le rapport et la période de rapport, ainsi que la stratégie MTA-STS qui a été appliquée. Cependant, la section principale qui vous intéressera est summary, en particulier le nombre de sessions réussies et échouées.

Cet exemple de rapport montre que 230 e-mails ont été livrés avec succès via TLS par le fournisseur de messagerie qui a généré le rapport, et 0 envois d'e-mails n'ont pas réussi à établir une connexion TLS appropriée.

En cas d'échec, par exemple si un certificat TLS expire ou s'il y a un attaquant sur le réseau, le mode d'échec sera documenté dans le rapport. Voici quelques exemples de modes de défaillance :

  • starttls-not-supported : si le serveur de messagerie de réception ne prend pas en charge STARTTLS.
  • certificate-expired : si un certificat a expiré.
  • certificate-not-trusted : si un certificat auto-signé ou un autre certificat non approuvé est utilisé.

Dans cette dernière étape, vous avez reçu puis interprété votre premier rapport TLSRPT.

Conclusion

Dans cet article, vous avez configuré et configuré les rapports MTA-STS et TLS pour votre domaine, et interprété votre premier rapport TLSRPT.

Une fois que MTA-STS a été activé et fonctionne de manière stable pendant un certain temps, il est recommandé d'ajuster la politique, d'augmenter la valeur max_age, et éventuellement de la basculer en mode enforce une fois que vous êtes sûr que tous les e-mails des fournisseurs pris en charge sont livrés avec succès via TLS.

Enfin, si vous souhaitez en savoir plus sur les spécifications MTA-STS et TLSRPT, vous pouvez consulter les RFC pour les deux :