Aujourd’hui l’email (le mél, quoi) est devenu un outil essentiel de nos vies. C’est le moyen privilégié de communication, privée mais aussi commerciale et publique. Il contient des éléments très confidentiels, et d’un point de vue sécurité c’est souvent un pivot critique, si quelqu’un possède l’accès à vos emails il peut réinitialiser des mots de passe par exemple.
Pourtant la plupart d’entre nous laisse cet outil dans les mains de tiers, que ce soient des « gratuits dont vous êtes le produit » ou les adresses fournies par leur FAI. Cela a deux conséquences fâcheuses :
- perte complète de la confidentialité
- risque de perte du contrôle à tout moment.
Il y a deux solutions pour limiter les déconvenues potentielles :
- utiliser un fournisseur payant indépendant et offrant des garanties sérieuses de confidentialité
- héberger son propre email.
On parlera ici de la deuxième solution.
Principes
C’est quoi un email
La technique derrière les email est presque aussi vieille qu’Internet. Elle repose aujourd’hui sur deux protocoles éprouvés :
- SMTP (Simple Mail Transfer Protocol) permet la transmission de messages, depuis un client vers un serveur ou entre serveurs jusqu’à la destination
- IMAP (Internet Message Access Protocol) permet de consulter une boîte email, gérer les messages et les dossiers.
Notez que si vous utilisez uniquement Gmail en interface Web tout ceci vous est masqué, mais a bien lieu.
Les emails eux-même sont simplement des blocs de « texte », avec des éléments techniques (les entêtes) et le contenu organisé en sections s’il y a différents formats ou des pièces jointes.
Comment ça marche
Pour envoyer un email le client utilisé doit formater le message correctement puis le donner à un relais (MTA) généralement configuré comme serveur sortant / SMTP.
Ce relais va regarder l’adresse du ou des destinataires et trouver le ou les serveurs à contacter en utilisant les enregistrements DNS MX des domaines. Par exemple si j’envoie un email à titi@toto.com, le relais va demander au DNS gérant le domaine toto.com l’enregistrement MX, qui contient l’adresse du serveur de mail à contacter. Il va alors s’y connecter en utilisant SMTP et lui transmettre l’email pour livraison.
Le serveur de destination va alors livrer l’email dans la boîte du destinataire.
Notez qu’il peut y avoir des relais intermédiaires et que la livraison peut être plus ou moins complexe.
Héberger son propre email
Prérequis
Pour héberger son email il faut d’abord un domaine (la partie après l’arobase comme sansimportance.com). Cela coûte environ 10 € par an, j’utilise Netim.
Il faut ensuite un serveur qui tournera sous une forme d’OS Linux. Comme décrit dans mon article sur l’auto hébergement j’ai un petit boîtier à la maison qui m’a coûté 150 €. Vous pouvez aussi louer un VPS chez OVH par exemple, cela vous coûtera entre 5 et 10 € par mois. Dans les deux cas il vous faudra aussi une adresse IP fixe, à vérifier auprès de votre FAI si vous visez un hébergement à la maison.
Domaine, MX et SPF
Comme vu plus haut, pour recevoir des email vous devrez au minimum configurer une entrée DNS MX (Mail eXchange) pour que les serveurs qui veulent envoyer des messages à votre domaine sachent comment contacter votre serveur. Cette configuration sera généralement faite chez votre enregistreur de nom, ajoutez simplement une entrée MX pointant sur l’IP de votre serveur.
ll est aussi recommandé d’ajouter une entrée de type TXT appelée SPF (Sender Policy Framework) qui indique qui a le droit d’envoyer des messages provenant de votre domaine. Normalement ce devrait être uniquement vous, donc ajoutez une entrée TXT avec le contenu :
v=spf1 mx -all
En gros ça dit : seul mon serveur (mx) peut envoyer des email venant de mon domaine, bloquez tout le reste (-all).
Si jamais vous devez utiliser un relais sortant ce peut être plus compliqué, en particulier chez Free (pour l’instant) :
v=spf1 ip4:212.27.42.0/24 ip6:2a01:e0c:1:1599::10/124 ~all
Dans ce cas j’ai même laissé ~all pour éviter un blocage dur si les IP de Free changent.
Boîtes mail
Pour accueillir des boîtes mail sur le serveur il faut créer autant d’utilisateurs que nécessaire (car oui vous pouvez dès à présent créer autant de comptes que vous le voulez, pour la famille, les amis), par exemple avec useradd. Il faudra aussi leur choisir un mot de passe pour qu’ils puissent y accéder.
Ces boîtes seront au format Maildir, c’est à dire que dans chaque répertoire utilisateur (du genre /home/titi si titi est un nom d’utilisateur) il y aura un dossier Maildir contenant tous les emails. C’est du coup assez facile à sauvegarder.
Vous pouvez aussi créer des alias pour faire pointer monsieur.titi vers l’utilisateur titi, éditez simplement le fichier /etc/alias avant de lancer la commande postalias.
SMTP avec Postfix, Dovecot et Postgrey
Installez Postfix, Dovecot et Postgrey.
Pour Postfix réalisez les configurations suivantes dans /etc/postfix/main.conf, ne vous inquiétez pas je vais expliquer, je suppose ici que notre domaine est toto.com :
smtpd_relay_restrictions = permit_sasl_authenticated reject_unauth_destination myhostname = toto.com mydestination = $myhostname, localhost relayhost = [smtp.free.fr]:465 smtp_tls_security_level = encrypt smtp_tls_wrappermode = yes home_mailbox = Maildir/ smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous
smtpd_relay_restrictions permet de contrôler qui peut envoyer des messages, avec la configuration ci-dessus on dit :
- les utilisateurs authentifiés peuvent envoyer n’importe où (vers l’extérieur quoi)
- les autres ne peuvent envoyer que vers notre domaine, cela évite de pouvoir abuser de notre serveur comme relais ouvert.
myhostname est le nom qu’utilisera le serveur, il doit correspondre à ce qui a été défini en MX dans le DNS.
mydestination est la liste des destinations pour lesquelles on accepte les messages, localhost peut être utilisé pour envoyer des alertes localement au serveur (au compte root généralement).
relayhost et les lignes suivantes permet de désigner un relais pour les messages sortant si votre FAI bloque l’envoi direct (comme Free). En VPS pas besoin de ces lignes.
home_mailbox identifie comment seront livrés les messages pour nos utilisateurs, ici en format Maildir (dossier Maildir dans les dossiers racine des utilisateurs).
Enfin tout le bloc smtpd_sasl permet de spécifier comment on authentifiera les utilisateur avant de leur permettre d’envoyer des messages où ils veulent. On utilisera Dovecot, voir plus bas.
Voilà, ça peut paraître intimidant mais finalement pas tant de choses à configurer que ça.
En bonus j’utilise les directives suivantes pour combattre le spam qui est vraiment une plaie :
smtpd_client_restrictions =
permit_sasl_authenticated
reject_unknown_client_hostname
reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]
reject_rhsbl_reverse_client dbl.spamhaus.org=127.0.1.[2..99]
warn_if_reject reject_rbl_client zen.spamhaus.org=127.255.255.[1..255]
smtpd_helo_required = yes
smtpd_helo_restrictions =
reject_unknown_helo_hostname
reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99]
smtpd_sender_restrictions =
reject_unknown_sender_domain
reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99]
smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10023
Ces contrôles sont effectués lorsque des serveurs se connectent et tentent de nous refiler un message :
- ils doivent avoir un nom DNS correspondant à leur IP et on vérifie que cette IP n’est pas en liste noire auprès de Spamhaus
- ils doivent nous dire HELO avec leur petit nom, et on vérifie que ce petit nom est valide et pas en liste noire
- on vérifie que l’adresse de l’émetteur du message (le FROM) est bien valide, et que le domaine n’est pas en liste noire
- enfin on passe l’info à Postgrey (qui écoute sagement sur le port 10023) pour vérifier si on connaît déjà ce serveur, sinon on va lui demander de ré-essayer plus tard.
IMAP avec Dovecot
On a vu un peu plus haut que Dovecot permettait de réaliser l’authentification SASL pour le SMTP (l’envoi des messages), mais il se charge aussi du IMAP (leur consultation). La configuration est super simple, même si répartie dans plusieurs fichiers.
Dans conf.d/10-mail.conf s’assurer que le format est bien Maildir :
mail_location = maildir:~/Maildir
Dans conf.d/10-master.conf s’assurer d’avoir l’intégration Postfix :
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0666
}
}
Il est aussi possible de désactiver les protocoles non utilisés, voir ci-dessous.
Sécurité
Protocoles sécurisés et Letsencrypt
Il est critique pour la sécurité d’utiliser les protocoles chiffrés SMTPS et IMAPS pour ne pas transmettre des mots de passe (et des données) en clair. Ces protocoles reposent sur TLS et donc des certificats.
Grâce à Letsencrypt il est relativement facile d’obtenir et de maintenir à jour gratuitement un certificat. Suivez les instructions sur le site, ce sera plus simple si vous avez un serveur Apache HTTP installé. C’est hors du cadre de cet article (mais en constituera un autre).
Une fois le certificat obtenu c’est un jeu d’enfant pour l’utiliser.
Pour Postfix dans main.conf :
smtpd_tls_cert_file = /etc/letsencrypt/live/toto.com/cert.pem smtpd_tls_key_file = /etc/letsencrypt/live/toto.com/privkey.pem smtpd_use_tls=yes
Pour Dovecot dans conf.d/10-ssl.conf (attention les < ne sont pas une erreur) :
ssl = yes ssl_cert = </etc/letsencrypt/live/toto.com/cert.pem ssl_key = </etc/letsencrypt/live/toto.com/privkey.pem
Pour s’assurer de ne pas faire de bêtise on pourra désactiver IMAP pour ne garder que IMAPS. Pour ce faire allez dans conf.d/10-master.conf modifier :
inet_listener imap {
#port = 143
port = 0
}
Par contre pour SMTP il faut garder 25 pour les autres serveurs mais s’assurer de n’utiliser que SMTPS pour l’authentification dans les clients que vous utilisez.
Bloquer les importuns avec fail2ban
A partir de là, si vous regardez vos logs vous constaterez que la majorité des tentatives d’authentification SMTP ne sont pas légitime. Et oui Internet est une jungle. On a limité le taux de réussite des spammeurs, mais comment bloquer les tentatives d’énumération de mot de passe ?
On utilise fail2ban. Ce programme surveille les logs de différents logiciels (par défaut sshd) et s’il repère trop de tentatives d’accès loupées depuis une IP il bloque celle-ci (avec le firewall système iptables) pendant un certain temps.
Après installation, pour ajouter le support Postfix SASL il suffit d’ajouter dans le ficher /etc/fail2ban/jail.d/defaults-debian.conf :
[postfix-sasl] enabled = true
Pour vérifier que Postfix SASL est bien pris en compte tapez sudo fail2ban-client status :
Status |- Number of jail: 2 `- Jail list: postfix-sasl, sshd
Et voilà les prisons pour les escrocs sont prêtes. Pour voir ce qui se trouve dedans tapez sudo fail2ban-client status postfix-sasl. Bien sûr si un de vos utilisateurs se trompe de mot de passe 3 fois de suite il sera banni temporairement, c’est la vie (vous pouvez le débloquer au besoin).
Clients
Point d’interface Web ici, bien que l’on puisse en installer une (comme Roundcube ou Rainloop). Sur PC n’importe quel client email devrait faire l’affaire, j’utilise Thunderbird.
Sur téléphone Androïde BlueMail est très bien.
Dans les deux cas il faudra correctement configurer comme suit. Pour le serveur sortant :
- nom du serveur = toto.com
- port = 465 (SMTPS)
- sécurité = TLS/SSL
- authentification = mot de passe
- nom d’utilisateur = titi
Pour le serveur de courrier :
- nom du serveur = toto.com
- port = 993 (IMAPS)
- sécurité = TLS/SSL
- authentification = mot de passe
- nom d’utilisateur = titi
Vous pourrez aussi choisir le nom qui sera utilisé pour l’affichage et même l’adresse email si vous créez un alias.