Liens :
OpenSMTPd et Dovecot.
Ou comment mettre en place ton petit serveur de mail perso rien que pour ta pomme, ou presque, même si tu n'y comprends pas grand chose, ou presque.
Sommaire :
- Ce que ce tutoriel est, ce qu'il n'est pas.
- Pourquoi un serveur de mail chez soi ?
- Le mail, comment ça marche ?
- Mail auto-hébergé ? Je ne veux pas, je ne peux pas parce que…
- Installation de l'OS de base
- Peaufiner l'installation
- Générer clés et certificats SSL.
- OpenSMTPd.
- Dovecot.
- Configuration du client.
- Un Webmail : Roundcube.
- Aller plus loin (1) : Chiffrer et signer ses mails avec GPG.
- Aller plus loin (2) : SPF.
- Aller plus loin (3) : Faire signer son certificat par une autorité de certification.
- Aller plus loin (4) : Servir de MX secondaire et en utiliser un.
1 - Ce que ce tutoriel est, ce qu'il n'est pas.
Ce tutoriel est destiné à toute personne, physique ou morale, souhaitant pour 1000 raisons, bonnes ou mauvaises, idéologiques ou techniques, rationelles ou pas, (apprendre à) installer et gérer un serveur de mails, que ce soit pour elle ou pour une organisation de petite taille : famille, association, PME.
Ce tutoriel est plutôt destiné à ceux et celles ayant déjà un UNIX, sur sa ou ses machine(s) principale. (Oui, MacOS X est un UNIX, un UNIX sâle, mais un UNIX quand même).
Ce tutoriel n'est pas un cours complet, exhaustif et devant faire autorité sur ce qu'est l'administration d'un serveur mail.
Ce qui y est présentée est une des façons les plus simple de monter un serveur mail. Parce que pour conserver de la simplicité la gestion des utilisateurs présentée est très basique, c'est probablement une mauvaise idée de suivre ce guide pour un service devant gérer (estimation à la louche) plus de 30 personnes.
Si on vous demande un jour de déployer un serveur mail gérant d'office plus de 30 comptes, alors :
- ce tutoriel n'est peut-être pas fait pour vous parce que :
- vous avez déjà probablement de l'expérience dans le domaine et donc :
- ce tutoriel n'est peut-être pas fait pour vous.
J'ai arbitrairement fait plusieurs choix pour ce tutoriel et bon nombre d'impasses ; Si un des choix que j'ai fait vous gêne, c'est probablement que vous le maîtrisez le sujet suffisamment bien pour vous permettre des libertés par rapport au cheminement tout tracé de ce guide.
Pour information : d'autres ressources sympathiques pour apprendre à maîtriser votre mail :
Hébergez vos mails sur Ubuntu server et libérez-vous, utilisant Postfix, Dovecot et Ubuntu.
Reprendre en main ses emails, avec Ubuntu ou FreeBSD, OpenSMTPD et Dovecot. Assez similaire à ce que vous êtes en train de lire ; moins détaillé et plus direct.
Auto-héberger ses mails avec OpenSMTPD dans son environnement naturel : OpenBSD ; par Vigdis.
En vidéo :
une formation « DNS et mails» par Benjamin Bayart (plus axé DNS que mail cependant) ;
ainsi que le mail, vaste sujet et Chiffrement SSL/TLS, tous deux par Benjamin Sonntag.
2 − Un serveur de mail chez soi ?
Considérations sur les notions de client et de serveur sur Internet.
Lorsqu'on pense à "serveur", on imagine parfois un gros machin avec quinze ventilateurs, qui fait à peu près le bruit d'un aspirateur bouché, qui crame à peu près autant de courant électrique qu'une ville moyenne, qui est moche, qui se soulève péniblement en faisant fait mal au dos et qui se rack en baie dans un datacenter.
Depuis quelques temps, dans les esprits les plus éclairés « serveur » rime parfois avec Raspberry Pi. Ça consomme à peu près rien (~5 Watts), ça fait tourner Linux, ça a des performances amplement suffisantes pour ce qu'on lui demande, ça dispose de ports USB pour y mettre un disque dur externe ou une clé USB et d'un port ethernet pour être relié au réseau. Et on leur trouve maintenant des boitiers classieux, d'autres très… colorés, ou même des patrons pour en réaliser en papier, pour presque pas un rond.
Un bon compromis serait peut-être d'utiliser un ordinateur portable remisé. C'est d'une puissance bien assez suffisante pour une consommation globalement raisonnable, et avec un peu de chance il reste à la batterie quelques minutes d'autonomie qui vous laisseront le temps de réarmer le disjoncteur sans que la machine ne s'éteigne.
La réalité, c'est qu'une machine de bureau, un ordinateur portable, un RPI ou un gros machin à racker dans une baie, c'est la même architecture de base « processeur + mémoire + interface réseau » . La différence c'est uniquement ce qu'on met autour, comme par exemple une batterie dans le cas d'un ordinateur portable ou un écran, un clavier et une souris dans le cas d'une machine dite de bureau.
Ce qui détermine si un ordinateur est client ou serveur, c'est juste le type de logiciel que vous installez dessus.
Installez une suite bureautique et votre ordinateur sera une machine à écrire.
Installez Firefox et votre ordinateur sera un client web, installez Apache et votre ordinateur sera un serveur web.
Installez Firefox et Apache, et votre ordinateur sera client et serveur web.
Installez donc LibreOffice et Apache, et vous pourrez mettre instantanément à disposition le document que vous rédigez en ligne, juste en en faisant "Enregistrer sous..." et en indiquant le répertoire qui est servi par le serveur web. Faites une correction dans votre texte et sauvegardez la correction et instantanément la nouvelle version de votre fichier est disponible, partout, par tout le monde, si peut que vous communiquiez l'URL de votre document.
Si vous êtes habitué à devoir « uploader sur Internet » un fichier pour qu'il soit mis à disposition, ça doit vous paraître étrange qu'exactement le même fichier, pas une copie, puisse être sur votre ordinateur ET sur Internet en même temps. Ça veut aussi -et surtout- dire que votre ordinateur est dans un cas bien une partie du réseau Internet, et dans l'autre cas, non.
Donc si vous n'avez pas de machines à faire tourner à part, et que votre machine habituelle est globalement sédentaire (bin oui, si elle change d'IP ou qu'elle est déconnectée du réseau ça marchera moins bien), et reste allumée (parce que téléchargements, parce que vous minez du bitcoin, ou que vous participez au projet SETI ou que sais-je...) alors non, c'est pas plus déconnant que cela d'y installer de quoi la transformer en serveur de mail.
Cette précision apportée, dans la suite du guide partira néanmoins du principe que vous possédez une machine qui sera dédiée à la fonction « serveur », vous pourrez l'adapter facilement, au besoin, si vous partez sur la base de « ma machine du bureau fera aussi serveur mail ».
Considérations sur la centralisation d'Internet, et ses dangers.
Les motivations pour avoir son propre serveur de mail sont multiples :
- Le fun d'apprendre à le faire ;
- L'amour du DIY ;
- L'envie purement cosmétique de personnaliser aussi ce qui se trouve à droite du @.
- Rien d'intéressant à la télé
ce soir; - Besoin d'avoir la main sur mes moyens de communication, de pouvoir réparer soi même si c'est cassé ; (car Gmail aussi tombe en panne)
- Volonté de ne pas laisser à, on ne sait plus trop qui finalement, l'accès à sa correspondance électronique.
spoiler : les quelques lignes qui suivent sont très militantes, si mes états d'âmes ne vous intéressent pas, passez directement à l'installation d'Ubuntu
Ce dernier argument, la volonté de ne laisser sa correspondance aux mains d'entreprises (capitalistes, tentaculaires et étrangères) est présent depuis très longtemps parmi les adeptes d'une vision a-centrée du réseau.
Internet a été pensé, conçu et déployé sans centre, que ce soit en terme d'infrastructure matérielle, de services ou des prises de décisions.
On peut pas dire que son évolution récente soit tout à fait conforme à l'idée de départ.
Vous retirer une idée fausse de la tête
Schématisons à outrance le fonctionnement du mail en quelques dessins :- Alain, en jaune ;
- Béatrice, en vert ;
- Les machines de Google ;
- Les machines de Yahoo.
Dans l'esprit de bien des gens, qui ne se sont pas posé la question, le mail c'est « j'envoie un message de mon ordinateur, avec mon compte Google, vers l'ordinateur de mon correspondant, avec son compte Yahoo ».
Et donc dans leur tête, ça donne ceci :
Il y a donc deux intermédiaires, ici Google et Yahoo, qui se trouvent inutilement au centre du cheminement, qui possèdent les mails (bin ouais, il est stocké sur des serveurs, sur LEURS serveurs, pas sur celui de Alain ou de Béatrice) et sur lesquels ni l'un ni l'autre des protagonistes n'ont de moyen de savoir ce qui est fait avec leur messagerie.
Est elle analysée ? Est elle lue par les adminsys de Yahoo et Google ? Est elle fournie (même pas forcément légalement) à des entitées tierces ? Bref : y a-t-il violation de la correspondance privée entre deux individus ? Aucun moyen de le savoir.
Alors on fait quoi pour remédier à cela ?
Bin on fait de l'Internet, et on envoie soi-même le mail, avec une machine qu'on possède.
Et entre Alain et Béatrice, il n'y a du coup plus rien d'autre que les routeurs composants le chemin normal d'Internet, sans passer par un service tiers qui vont gérer le mail à leur place :
Comment en est on arrivé à une situation ou nos mails ne nous appartiennent plus ?
Avec l'arrivée des connexion permanentes, l'égalité des machines sur le réseau passe de la belle théorie à la réalité. Il devenait envisagable d'héberger soi-même son mail sur une machine posée quelquepart dans notre maison. Certains FAI d'époque comme Nerim ou Teaser (ou encore FDN, mais on les a redécouverts entre temps, ceux là) proposaient même en standard, la possibilité d'utiliser leurs serveurs comme MX secondaires, plutôt pratique quand on auto-héberge son mail.
Le chemin pris était encourageant.
C'est ce qui a été nommé « effet Minitel 2.0 ». Reproduire sur Internet, réseau a-centré, les comportements centralisateurs inhérents à des réseaux d'ancienne génération, comme la télévision ou le minitel.
Cette transition dans le mauvais sens est décrite par Benjamin Bayart dans cette vidéo qui date de 2007 sur Youtube ou sur le site de FDN.
Aujourd'hui la question est donc à prendre dans l'autre sens, il faut se demander
« Pourquoi un serveur mail ailleurs que chez soi ? ».
Et franchement, à part si vous avez un "chez moi" assez peu fixe ou qu'Internet n'arrive pas chez vous, j'ai pas de réponses à cette question.
3 − Le mail, comment ça marche ?
4 − Mail auto-hébergé ? Je ne veux pas, je ne peux pas parce que…
2.1 − Si je me fais cambrioler, si on me vole mon serveur, le voleur aura tout mes mails, et moi plus rien
Non, du tout.
2.1.1 − Le chiffrement
Effectivement, tant que votre machine est allumée : tout va bien, le système tourne et s'assure de ne servir les données qu'à conditions (modulo les failles de sécurités et les vols d'identifiants, bien sur) que l'on ai montré patte blanche.Mais il est vrai que si demain votre machine se retrouve entre de mauvaises mains, pour une raison ou une autre (perquisition ou vol, peu importe), celui ou celle qui aura accès à votre machine aura tout le loisir de faire ce qu'il en souhaite.
Il pourra par exemple en retirer le disque dur pour en faire une ou plusieurs copies et les lire avec SA machine. Ou de faire booter un live CD sur votre machine. Et, oui, se faisant aura accès à l'intégralité de vos données.
À gauche : le disque dur d'un serveur, extrait, et branché via USB à un autre ordinateur.
À droite : le résultat, tout le système de fichiers, y compris le répertoire ou sont stockés les mails, est accessible en libre accès.
Bien sur qu'on peut éviter cela.
Pour se faire, hormis la partition /boot qui fait démarrer le minimum du minimum tout le contenu du disque dur doit être chiffré. Aucune donnée en clair ne viendra toucher la surface du disque. Ce qui signifie que même lu par un système externe, les données contenues sur le disque dur resteront illisibles sans la phrase de passe.
Cela amène deux inconvénients : 1 − Pour que l'OS puisse démarrer il faut saisir la dite phrase de passe au boot ;
2 − si vous oubliez cette clé, il n'y a pas de fonctions « réinitialiser le mot de passe et me le renvoyer » ; phrase oubliée = données perdues.
Il conviendra de la choisir longue, très longue, plus longue que le mot de passe que vous avez l'habitude d'utiliser, car si votre machine est saisie l'attaquant aura tout loisir d'user du bruteforce. La seule protection qui vous restera ce jour là sera le fait que plus une clé est longue plus le temps pour la trouver sera long.
Si vous la choisissez suffisement longue (partons sur au moins 20 caractères) les moyens à mettre en œuvre et le temps à y passer seront probablement disproportionnés par rapport à la valeur que votre attaquant accorde à vos données.
Bouée de sauvetage : Si vous avez oublié votre phrase de passe exacte mais que vous avez une vague idée de ce qu'elle pourrait être, ce que Benjamin Sonntag raconte sur « Luks Bruteforce : tester tous vos mots de passes... » vous sera d'une aide précieuse.
Évidemment, tout OS digne de ce nom propose désormais en standard à l'installation la possibilité de chiffrer l'intégralité du disque dur. Ubuntu ne faisant pas exception, on aurais tort de se priver.
2.1.2 − Le backup
Rêgle d'or : des données qui ne se trouvent qu'à un seul endroit sont des données en danger.Vous voulez sauvegardez vos mails en cas de vol, de défaillance ou de destruction de votre serveur ? Facile, ils sont dans le répertoire
/home/user/Maildir.Rapatriez régulièrement ce dossier via
SCP sur, par exemple, une clé USB que vous gardez toujours sur vous, et même si votre maison brûle, vous n'aurez pas perdu vos mails (simplement ceux que vous n'aviez pas encore sauvegardés).Je cause d'une telle clé dans un autre article : Bracelet/clé USB chiffrée.
2.2 − Ça crame de l'électricité pour rien.
2.3 − Si ma pauvre petite ligne ADSL fournie sans garantie lâche, je ne reçoit plus mes mails.
et le MX secondaire, pour les chiens ?5 − Installation de l'OS
L'installation du système de base : c'est parti !
La première étape consiste à se procurer une image d'installation de Ubuntu, pour cela direction la page de téléchargement de Ubuntu Server.
32 ou 64 bits, ça c'est fonction de votre machine ; Long Term Support ou pas, à vous de voir.
Si vous ne savez pas, dans le doute prenez une version dite LTS.
Seconde étape, coller ce .iso sur un CD (utilisez simplement votre logiciel de gravure favori en choisissant bien l'option "graver une image") ou une clé USB (sous linux, facile : sudo dd if=/chemin/de/votre.iso of=/dev/Sdx).
On passe à l'installation proprement dite, on se pince le nez, on se jette à l'eau, plouf, dans 20 minutes vous avez un serveur sous Linux !
1ère question : choix de la langue.
Facile !
2ème question : On installe ou bien ?
Petite astuce : Si, comme pas mal de monde, vous recyclez un vieux laptop, il y a une probabilité non-nulle pour que vous ayez à faire à un Pentium M.
Dans ce cas une installation en l'état ne échoueras ; Il vous faut activer le PAE en appuyant sur F6 et en ajoutant "forcepae" à la fin des options passées au kernel, comme indiqué sur la capture d'écran.
3ème question : Choix du pays.
Facile, encore !
4ème question : Choix du nom de la machine.
Pour une machine qui va distribuer du courrier, moi je pense que le nom d'un célèbre facteur, c'est bien.
5ème question : Choix du login.
J'ai pour habitude depuis facile 15 ans d'avoir « Thy » comme login, donc, facile ! À vous de voir lequel vous souhaitez. À noter que ce login sera, par défaut, la partie gauche de votre adresse mail, bien que ce soit facilement modifiable.
6ème question : Choix du mot de passe.
Vous le taperez deux fois, histoire d'être sur que vous ne vous êtes pas trompé.
Je vous encourage à le choisir long, facile à retenir mais difficile à deviner, comme je l'explique dans Avoir des bonS motS de passe".
7ème question : Faut-il chiffrer le répertoire personnel ?
Non : à l'étape suivante on va choisir de chiffrer tout le disque dur.
8ème question : Choix du type de partitionnement.
Allons au plus simple : « assisté, avec chiffrement », puis choix du disque à partitionner.
Si vous installez depuis un CD, il n'y aura qu'un choix possible a priori, si vous installez depuis une clé USB, prenez simplement garde à sélectionner votre disque dur (facile, c'est le plus gros) et non la clé.
9ème question : Saisie de la phrase de passe.
Si Ubuntu vous demande bien une phrase et non mot de passe, c'est pour une raison bien précise. Faites la longue, comme un jour sans pain.
Car si quelqu'un met la main sur votre disque dur et qu'il finit par trouver cette phrase, toute vos données sont à poil. Qu'il possède votre pass utilisateur ou pas.
10ème question : Portion du disque dur à utiliser.
On va pas se compliquer la vie, utilisons tout le disque dur : "max".
11ème question : Ha ! Non, c'est pas une question, c'est juste la copie des fichiers en cours !
12ème question : Choix du proxy.
"Aucun", à moins que vous ne soyez sur un réseau d'entreprise, alors demandez à votre adminsys.
13ème question : Mise à jour de sécurité des programmes.
Vous êtes débutant ? Allons au plus simple : "automatique". Le système vérifiera périodiquement si des updates de sécurité sont disponibles et les appliquera tout seul, pendant que vous ronflez.
14ème question : Choix des logiciels à installer.
On ne va installer que le serveur SSH à ce stade.
15ème question : Installer GRUB ?
Oui.
Et voilà : Fini !
Il est temps de rebooter.
Au premier boot : On vous demande de saisir votre phrase de passe.
Votre Linux de démarrera pas tant qu'elle ne sera pas saisie. Si votre disque dur est retiré puis monté dans une machine tierce, les données resteront illisibles tant que cette phrase de passe ne sera pas saisie.
Il est temps de s'installer confortablement dans votre Linux fraîchement installé :-)
Peaufinage de l'installation
Bien, votre serveur tourne, mais il ne fait pas grand chose pour le moment.
Il y a fort à parier que vous allez maintenant le mettre dans un endroit ou il ne dérangera pas et ou il sera à l'abri des pieds qui se prennent dans les câbles.
Il y a également fort à parier que vous allez souhaiter y accéder à distance, plutôt que d'y brancher un clavier et un écran à chaque fois que vous aurez quelque chose à y faire. Dans ce cas ci, un outil de choix : OpenSSH.
Histoire de rendre cette prise en main à distance plus aisée, on va employer l'utilitaire Tmux.
Accéder à distance à sa machine, c'est bien. S'assurer que personne ne se permet de faire illégitimement de même en testant méthodiquement toutes les combinaisons possibles c'est mieux.
Et pour cela il y a Fail2ban. Ce petit programme se charge de repérer les échecs de connexions dus à une mauvaise authentification puis il va bannir les IP d'ou proviennent ces tentatives de votre système, pendant une période paramétrable.
Mais pour éditer les fichiers de configuration, on va avoir besoin d'un éditeur de texte, comme le simplissime Vim.
On va même commencer par là.
Installation de Vim, et initiation rapide
Vim, contrairement aux éditeurs de texte plus connus, comme Gedit, Notepad (ou, plus ancien, MS Edit) est un éditeur "modal".
Vous naviguerez donc entre les modes "commandes" et "édition" au gré des besoin.
Si c'est assez surprenant quand on est pas habitué, on prends le pli assez vite et "Échap, :wq" se transforme rapidement en réflexe.
Pour éditer un fichier, utilisez la commande
| vim /chemin/nom_du_fichier |
Vous arrivez devant votre fichier, en mode commande. Dans ce mode vous pouvez, bien sur, déplacer le curseur, mais pas taper votre texte. Vous pouvez couper la ligne courante, tapant "dd", la copier dans le buffer avec "yy" et enfin coller le contenu du buffer avec "yy".
Pour sauvegarder le fichier courant, utilisez la commande ":w".
Pour quitter Vim, usez de ":q".
Ces commandes sont cumulables, et vous pouvez sauvegarder et quitter dans la foulée avec ":wq".
Si vous avez modifié un fichier et que vous souhaitez quitter sans l'avoir sauvegardé, Vim va vous rappeler à l'ordre. Si vous souhaitez réellement quitter SANS sauvegarder, alors vous pouvez forcer une commande en la faisant suivre de "!", donc employer ":q!".
Maintenant que vous possédez les rudiments du mode commande, passons au mode édition.
Pressez I, et vous voilà en insertion de texte, de façon très banale.
Astuce : si vous accédez à Vim par le biais d'un émulateur de terminal et que vous avez besoin de copier de large portions de texte (comme, plus loin, la configuration d'OpenSMTPD), sachez qu'une fois en mode édition, vous pouvez insérer le contenu du presse-papier.
En général Ctrl+shift+V vous permettra de coller (en tout cas c'est ainsi que fonctionne Gnome terminal).
Pour revenir au mode commandes et pouvoir ainsi sauvegarder et quitter, une pression sur "Échap" est suffisante.
Récapitulons :
| I | Passer dans le mode insertion |
| yy | Copier la ligne courante |
| dd | Couper la ligne courante |
| p | Coller la ligne après le curseur |
| :q | Quitter |
| :q! | Quitter sans enregistrer |
| :w | Sauvegarder |
| :wq | Sauvegarder et quitter |
| Échap | Passer dans le mode commandes |
Pour aller un peu plus dans le détail : Initiation à Vim sur Openclassrooms et Vim sur le wiki ubuntu-fr.org.
Configuration d'OpenSSH
Maintenant que Vim est installé et, à peu près, maîtrisé (ou bien que vous avez utilisé un autre éditeur de texte auquel vous êtes plus habitué hein !), on va pouvoir éditer quelques fichiers. Comme le fichier de configuration du serveur OpenSSH, par exemple.
OpenSSH (fork de SSH, "Secure SHell", initié par une équipe du projet OpenBSD) est LE programme qui vous vous permettre de vous connecter à votre serveur, à son shell, plus précisément, depuis votre PC de bureau ou votre laptop, et interagir avec lui comme si vous étiez physiquement devant votre serveur.
Pas besoin d'y brancher un écran et un clavier quand vous devez faire une quelconque manipulation, pas même besoin d'être au même endroit.
Cerise sur le gâteau : les échanges sont parfaitement sécurisés, contrairement à ses prédécesseurs telnet ou rsh.
SSH peut fonctionner avec le classique système login/mot de passe.
Vous pouvez déjà vous connecter à votre serveur depuis votre PC client, avec la commande
| ssh mon_serveur.tld -l Mon_login |
SSH vous demande si vous êtes surs de l'identité du serveur, puis votre mot de passe, et paf (ça fait des chocapic), vous êtes devant le prompt de votre serveur, sans être physiquement devant.
Mieux encore, vous pouvez vous connecter avec le principe de clé privée/clé publique.
Le concept est simple : sur tout serveur que vous devez administrer, vous pouvez déposer votre clé publique (qui peut être réellement publique, sa divulgation n'entraîne aucun risque de compromissions des échanges), et cette clé publique par le truchement d'algorythmes cryptographiques (que je ne détaillerais pas ici) permet de s'assurer de votre identité en se comparant à des données qui seront chiffrés avec votre clé privée (qui elle doit rester sous votre contrôle en permanence, du coup, et donc ne jamais traîner sur une clé USB égarée).
Sur votre PC client (et non sur le serveur, du coup), on donc se créer une clé avec la commande
| ssh-keygen -t rsa |
À laquelle il est plus que fortement conseillé d'attribuer une phrase de passe, pour éviter qu'un vol de la clé privée n'ait des conséquences immédiatement catastrophiques (considérez néanmoins la clé comme compromise si par exemple votre PC portable est volé, et recréez vous dès que possible une nouvelle paire de clés si ça arrivais).
Votre clé privée se trouve dans le fichier /home/utilisateur/.ssh/id_rsa
Votre clé publique se trouve dans le fichier /home/utilisateur/.ssh/id_rsa.pub
Maintenant, copions la clé publique sur le serveur :
| ssh-copy-id -i ~/.ssh/id_rsa.pub thy@suis.at |
Et tentons de nous connecter de nouveau :
Votre gestionnaire de trousseau vous demandera la passphrase de votre clé privée la première fois, et ensuite bingo, vous vous connecterez à chaque fois sans avoir à saisir quelque pass que ce soit. La simplicité au quotidien gagne un niveau :-)
Maintenant on va gagner un cran en sécurité en retouchant un peu la configuration d'OpenSSH :
| sudo vim /etc/ssh/sshd_config |
On va passer les options "PermitRootLogin" et "PasswordAuthentication" à NO.
Puis on redémarre SSH :
| sudo service ssh restart |
Installation et configuration de Fail2ban
Installation de Tmux, et initiation rapide
7 − SSL
cd /rootopenssl genrsa -out server.key 4096
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt
mv server.crt /etc/ssl/certs/server.crt
mv server.key /etc/ssl/private/server.key
chown root /etc/ssl/private/server.key
chown root /etc/ssl/certs/server.crt
*chgrp ssl-cert /etc/ssl/private/server.key
*chgrp ssl-cert /etc/ssl/certs/server.crt
chmod 600 /etc/ssl/private/server.key
apt-get install opensmtpd
8 − OpenSMTPD.
OpenSMTPD est un serveur (d'ou le "D", pour Daemon) SMTP issu du projet OpenBSD.
Une vieille tradition d'OpenBSD est de refaire de zéro ("from scratch" comme il faut dire pour paraître hype) ce qui n'est pas considéré satisfaisant.
En plus d'OpenSMTPD, on peut citer :
- OpenSSH (présenté plus haut) ;
- OpenBGPD (protocole de routage inter-opérateurs) ;
- OpenNTPD (synchronisation d'horloge) ;
- ou plus récemment LibReSSL (reprise de OpenSSL).
Pour autant issu d'OpenBSD, OpenSMTPD est disponible sur d'autres OS, dont Ubuntu. Ça tombe bien.
Parmi les objectifs d'OpenSMTPD il y a la sécurité, et la simplicité de configuration, avec un fichier de configuration (je cite) « presque humainement lisible ».
Parmi les objectifs que ne vise pas OpenSMTPD il y a la performance et la vitesse, encore que dans les faits OpenSMTPD arrive à soutenir la comparaison avec ses concurrents.
Quoiqu'il en soit, dans le cas présent on vise un serveur qui ne va traiter qu'un nombre très réduit d'utilisateurs, la question n'est donc pas à se poser.
Pour les curieux⋅ses, une présentation (en anglais) d'OpenSMTPD lors de l'AsiaBSDCon 2013 par un de ses développeurs, Éric Faurot (lien vers Youtube).
Installons OpenSMTPD
| sudo apt-get install opensmtpd |
| sudo vim /etc/smtpd.conf |
Il n'y a plus qu'à recopier et adapter la configuration ci après :
fichier disponible ici
|
pki mail.suis.at certificate "/etc/ssl/certs/server.crt" pki mail.suis.at key "/etc/ssl/private/server.key" table aliases file:/etc/aliases table mesdomaines { suis.at } listen on lo listen on eth0 port 25 hostname besancenot.suis.at tls pki mail.suis.at listen on eth0 port 587 hostname besancenot.suis.at tls-require pki mail.suis.at auth accept from any for local alias <aliases> deliver to maildir accept from any for domain <mesdomaines> alias <aliases> deliver to maildir accept from local for any relay |
| wget -r chezmanu.eu/smtpd.conf -O /etc/smtpd.conf |
ou bien exécuter la commande
La table des aliases vous permet une redirection sommaire des mails. mon /etc/aliases montre que les adresses abuse@, noc@, security@, postmaster@, hostmaster@, webmaster@, www@ et ftp@ sont redirigées vers root@ ; et que root@ lui même est redirigé vers thy@, en tout début de fichier.
Pratique si vous avez besoin d'une adresse temporaire que vous voudrez désactiver ensuite : créez une ligne spam : thy, utilisez l'adresse pour vous inscrire au service qui ne va pas manquer de spammer cette adresse, voire la revendre.
Tout ce qu'ils obtiendront, c'est un message d'erreur indiquant que cette adresse n'existe plus. Temps nécessaire : deux secondes pour l'activation, deux secondes pour la désactivation.
On remarque également une table "mesdomaines", qui ne contient que "suis.at".
Si vous possédez plusieurs noms de domaines, incluez les tous entre les accolades, séparés par une virgule et OpenSMTPD les traitera indifféremment, vous recevrez dans la même boite le courrier à destination de user@domaine1.com et user@domaine2.com.
Les lignes suivantes indiquent quels sont les ports écoutés par OpenSMTPD (ici le 25 et le 587), selon quelles modalités (une connexion au 587 requiert obligatoirement une authentification et du chiffrement par TLS) et le hostname sous lequel se présentera OpenSMTPD. Je vous encourage vivement à le mettre de la forme NomDeLaMachine.VotreDomaine.tld, certains serveurs étants tatillons en réception sur ce genre de détails, par mesure de protection contre le spam.
Les lignes suivantes se lisent presque naturellement et indiquent grosso modoque pour tout mail reçu pour un des domaines listées dans la table "mes domaines", on expédie ça dans le ~/Maildir/ du destinataire, et qu'un utilisateur local (comprendre : authentifié sur le serveur) peut envoyer là ou il souhaite, OpenSMTPD relaiera.
9 - Dovecot.
dovecotapt-get install dovecot-core dovecot-imapd
vim /etc/dovecot/conf.d/10-ssl.conf
ssl =yes/ required
ssl_cert = ssl_key =
vim /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:~/Maildir
service dovecot restart
10 − Configuration du client.
11 − Un Webmail : Roundcube.
root@raspberrypi:~# apt-get install mysql-server l'installeur demandera un mot de passe pour l'utilisateur root. Il s'agit du root de la base de données MySQL, ce n'est pas la même chose donc que l'utilisateur root du système Linux. root@raspberrypi:~# apt-get install roundcube-core roundcube-mysql roundcube-plugins-extra configure roundcube-core db-common → yes → mysql Sélectionnez "MySQL" Puis l'installateur vous demandera le mot de passe de l'user Root de MySQL. Puis vous choisirez un mot de passe pour l'utilisateur roundcube. Roundcube est maintenant dans le répertoire "/var/lib/roundcube" Apache2 a été installé dans la foulée, par le jeu des dépendances. Configurons donc tout cela… selon le système (ubuntu et debian diffèrent un peu sur ce point, cela change même de versions en versions), vous trouverez le contenu servi par apache dans /var/www/ ou var/www/html. Mettons un peu d'ordre dans ton cela, et éditons /etc/apache2/sites-available/000-default.conf12 − Chiffrer et signer ses mails avec GPG.
gpg --gen-key 1 rsa et rsa 4096 0 nexpire jamais let's go entropy ! pub 4096R/86A5F5AC 2015-04-24 Empreinte de la clé = DC17 C467 D4BD D1E0 6DE4 2527 2AA8 EC78 86A5 F5AC uid Thy Lolsco (test)gpg --edit-key Emmanuel Bourguin
>trust
>sign
---------------------------------- Un certificat de révocation: gpg --gen-revoke 86A5F5AC Sélectionnez une des 4 catégories de raisons de révocation (non spécifiée, compromise, remplacée ou plus utilisée) puis un éventuel commentaire. Un certificat est alors généré Vous pouvez, je le conseille même, créer plusieurs certificats de révocation puis les incorporer dans la foulée dans des fichiers au noms explicites gpg --gen-revoke 86A5F5AC > ~/.gnupg/revok-0.cle gpg --gen-revoke 86A5F5AC > ~/.gnupg/revok-1.cle gpg --import ~/.gnupg/revok-0.cle gpg --send-key 86A5F5AC