|
Mise en place d'un système de messagerie sécurisée pour une PME/PMI( Télécharger le fichier original )par Papa Cheikh Cisse - Mactar Ndiaga Seck Université Gaston Berger, Saint-Louis, Sénégal - Maitrise Informatique 2010 |
Partie 3: Sécuriser le système demessagerie La sécurité du serveur de mails se situe à plusieurs niveaux. Elle réside sur la sécurisation des communications, l'authentification des utilisateurs et l'intégrité des données. Les communications sont généralement sécurisées en utilisant un chiffrage avec OpenSSL, l'authentification est assurée a l'aide de SASL et les données sont analysées par un antivirus et un anti-spam. Ainsi, pour apporter de la sécurité en matière de courrier électronique, on peut agir sur deux éléments : les MTA et les MUA ou autrement dit coté serveur et coté client. Il est d'abord primordial de ne plus transmettre de mots de passe en clair ensuite on pourra se concentrer sur la validité des données. 3.1 Authentification SMTP avec SASL 3.1.1 Principes et objectifs de SASL SASL pour Simple Authentication and Security Layer est une méthode qui offre un support d'authentification a des protocoles orientés connexion. SASL inclut des commandes pour identifier et authentifier un utilisateur sur un serveur et pour éventuellement négocier la protection des interactions du protocole. Si son utilisation aboutit, une couche de sécurité est insérée entre le protocole et la connexion. Si l'on utilise Dovecot comme serveur IMAP, il est maintenant possible d'utiliser son démon d'authentification pour réaliser l'authentification SMTP via SASL. Nous allons passer a la configuration des serveurs SMTP et IMAP/POP3 dans la section qui suit. 3.1.2 Configurer Postfix et Dovecot pour SASL La première étape dans la configuration de SASL est l'édition des fichiers /etc/postfix/ main.cf et de /etc/postfix/ master.cf. A travers ces fichiers nous indiquerons a Postfix qu'il faut utiliser l'authentification SMTP pour tous les utilisateurs qui désirent envoyer un mail, sauf s'ils font partie de mynetworks. Avec la configuration suivante, on interdit également les connexions anonymes :
Nous allons maintenant modifier le fichier /etc/postfix/ master.cf en éditant l'option smtpd_sasl_auth_enable pour activer l'authentification avec SASL pour Postfix : smtps inet n - - - - smtpd -o smtpd_tls_wrappermode =yes -o smtpd_sasl_auth_enable =yes Après cela, il nous reste a configurer Dovecot pour qu'il réponde aux requêtes d'authentification de Postfix. Ceci se fait dans le ficher /etc/dovecot/dovecot.conf, il suffit de rajouter les lignes suivantes dans la section socket listen :
Bien entendu, pour que les modifications soient prises en compte, il faut redémarrer les services avec les commandes suivantes : # /etc/init.d/dovecot restart Il est maintenant possible de tester l'authentification en faisant une connexion SMTP en telnet. Il faut préalablement préparer la chaîne d'authentification encodé en base64. Pour cela nous utiliserons mimencode qui est une part des programmes metamail. Nous aurons les commandes suivantes:
La syntaxe est printf
"\0<nom_utilisateur>\0<mot_de_passe>" et c'est
cette couple login/password au serveur. On peut maintenant commencer la session telnet comme indiquée ci-dessous:
(C) correspond à une requête du client et (S) à une réponse du serveur. La session ci-dessus présente une authentification réussie sur le serveur mail.minfo.sn avec le couple login/mot_de_passe <user/minfo> pour l'authentification. On remarque dans cette session que le mot de passe est encodé en base64, il n'est donc pas lisible directement, il est par contre déchiffrable (avec mimencode -u). Cette méthode n'offre donc aucune sécurité et il est ainsi de voir le mot de passe d'une personne en analysant les trames réseaux. La solution la plus répandue pour contourner ce problème est de chiffrer toutes les communications avec SSL, c'est l'objet du paragraphe suivant. 3.2 Sécurisation des communications 3.2.1 Protection contre l'Open-Relay et le spam On parle d'Open-Relay lorsqu'on est en face d'un serveur SMTP qui autorise tous les messages électroniques entrants a transiter par lui pour atteindre d'autres domaines. Il s'agit d'un mécanisme qui consiste a accepter de transmettre un message à un destinataire quelconque. C'est le comportement par défaut de plusieurs serveurs SMTP. Cependant plusieurs spammeurs ont par la suite commencé à abuser de cette fonctionnalité pour causer des dégâts ; ce qui a poussé les administrateurs réseaux et systèmes à contrôler les flux entrants et à empêcher le relais pour leurs serveurs afin de ne pas se retrouver « blacklisté ». Ainsi pour augmenter la sécurité de notre serveur de mail, il est important de contrôler les échanges avec les serveurs SMTP ouverts (Open Relay). Ces serveurs sont utilisés pour envoyer des messages électroniques non sollicités, connus sous le nom de spam. Pour cela, il existe des listes d'adresses IP correspondant aux machines qui fonctionnent comme des serveurs SMTP ouverts. On peut donc demander à Postfix de consulter ces listes avant d'accepter un message entrant. Ceci est réalisé grâce a la directive smtpd_client_restrictions dans le fichier /etc/postfix/ main.cf. Enfin pour éviter que notre serveur devienne lui-même ouvert, il faut limiter les accès de façon très stricte. Par exemple, on peut rejeter le mail si les en-têtes sont incomplètes, si le message est mal formé, etc. Par contre, mes messages provenant des réseaux connus (my_networks) ou des personnes authentifiées (sasl_authenticated) seront toujours acceptés. Nous devons modifier notre fichier /etc/ main.cf de façon à avoir les lignes suivantes :
Notons que ce type de règles permet de diminuer sensiblement la charge de la machine dans le sens ou le mail est rejeté avant d'être analysé par les outils de filtrage de contenu (Amavis, ...) qui sont souvent très consommateurs de ressources. On pourra également observer un léger gain de bande passante puisque seuls les en-têtes des messages indésirables seront échangés sur le réseau, en aucun cas les corps de message ou les pièces jointes. La configuration ci-dessus autorise toujours le relais pour les personnes authentifiées grâce à la directive permit_sasl_authenticated. 3.2.2 Les certificats SSL Comme nous l'avons vu plus haut, les services de messagerie (SMTP et IMAP) demandent une authentification de la part des utilisateurs. Dans ce cas, ce dernier va fournir un couple login/mot de passe qui devra transiter sur le réseau entre le client et le serveur. Pour que ces identifiants ne circulent pas en clair, la plupart des services offrent la possibilité de chiffrer les échanges a l'aide d'OpenSSL. Pour cela, chaque service doit disposer d'un certificat SSL qui permettra de s'assurer de son authenticité et de chiffrer/déchiffrer les communications. Le fichier de configuration ci-dessous permettra de générer le certificat du serveur SMTPS. On peut par exemple l'enregistrer dans /etc/ssl/smtpd.cnf.
Nous allons ensuite générer le certificat et restreindre les privilèges sur la clé privée. Il nous suffira de lancer les commandes suivantes :
Lors de la configuration du certificat, le champ "commonName" est très important. Il doit toujours correspondre au FQDN (Fully Qualified Domain Name ; mail.minfo.sn dans notre cas) qui sera utilisé pour accéder au service. Dans le cas contraire, la plupart des clients vont générer une alerte à chaque négociation TLS avec le serveur. Nous avons terminé la génération du
certificat du serveur SMTP, nous devons faire la même smtp" par "imap" et de le renommer par /etc/ssl/imapd.cnf. On appliquera ces mêmes modifications sur la commande de génération vue précédemment. 3.2.3 Chiffrement des communications IMAP et SMTP avec OpenSSL Dovecot offre la possibilité de sécuriser les communications IMAP et SMTP avec OpenSSL : IMAPS et SMTPS. Il est souvent préférable de n'utiliser que cette déclinaison du protocole afin qu'aucun mot de passe ne passe en clair sur le réseau. Pour activer le support de l'IMAPS dans Dovecot, il faut dans un premier temps disposer d'un certificat pour ce service, ce qui a été fait dans le paragraphe précédent. Il suffit ensuite d'éditer le fichier /etc/dovecot/dovecot.conf pour modifier les paramètres suivants :
Notons que le paramètre protocols ne devra contenir que la valeur imaps, les autres protocoles de relève de courrier étant bannis. Avec cette configuration, les clients peuvent maintenant se connecter au serveur IMAP uniquement sur le port 993 et toutes les communications seront chiffrées. Il reste simplement à redémarrer le serveur avant de faire un premier test en ligne de commande: # /etc/init.d/dovecot restart # openssl s_client -connect mail.minfo.sn:993 --- * OK Dovecot ready. . login user minfo . OK Logged in. . logout * BYE Logging out . Logout completed. Pour le cas de SMTPS, la configuration d'OpenSSL se fera dans ses principaux fichiers de configuration. Il nous suffira d'abord de modifier les lignes suivantes dans /etc/postfix/ main.cf:
puis enlever le commentaire affecté à ces trois lignes dans le fichier /etc/postfix/ master.cf
Nous pourrons redémarrer avec un :
# etc/init.d/postfix restart avant de vérifier le fonctionnement de SMTPS comme le montre le test ci-contre : # openssl s_client -connect mail.minfo.sn:465 [...] --- 220 mail.minfo.sn ESMTP Postfix (Ubuntu) EHLO minfo.sn 250 mail.minfo.sn MAIL FROM: < user@minfo.sn> 250 2.1.0 Ok RCPT TO: < autre_user@minfo.sn> 250 2.1.5 Ok DATA 354 End data with <CR ><LF >.<CR ><LF >
Hello !! . 250 2.0.0 Ok: queued as 8EF8730102C3 quit 221 2.0.0 Bye 3.2.4 Configuration d'un firewall Le but d'un firewall est d'empêcher que des programmes puissent communiquer sur le réseau sans votre accord. Les iptables représentent le plus célèbre firewall utilisé sous Linux. Il permet d'établir un certain nombre de règles pour dire par quels ports on peut se connecter à votre ordinateur, mais aussi à quels ports vous avez le droit de vous connecter. On peut aussi filtrer par IP mais nous ne détaillerons pas cela ici. Par exemple, si nous voulons empêcher toute connexion FTP, nous pouvons souhaiter bloquer le port 21 (utilisé par FTP). Nous utiliserons les iptables pour mettre en place notre firewall. En général, la technique d'un pare feu ne consiste pas a bloquer certains ports, mais plutôt a bloquer par défaut tous les ports et à en autoriser seulement quelques-uns. Pour bloquer tous les ports :
Ainsi notre serveur refusera tout trafic entrant (INPUT DROP), sortant (OUTPUT DROP) ou qui doit juste passer par lui (FORWARD DROP). Nous allons ensuite autoriser le trafic sur l'interface de loopback locale. Ceci car le serveur a quelquefois besoin de communiquer avec lui-même. Dans la configuration retenue ici, il faut ouvrir uniquement les ports suivant en entrée : + 25 (SMTP) : pour que le serveur puissent recevoir les mails provenant des autres serveurs de mails. + 465 (SMTPS) : pour que les utilisateurs authentifiés puissent envoyer des mails en mode crypté (SSL). + 993 (IMAPS) : pour que les utilisateurs authentifiés puissent recevoir des mails en mode crypté (SSL) en utilisant IMAP. + 2000 (MANAGESIEVE) : pour que les utilisateurs authentifiés puissent éditer les règles de filtrage. Pour réaliser cela, nous exécuterons les commandes suivantes:
Cela fait, nous allons autoriser les requêtes de type ICMP, ne serait-ce que pour pouvoir s'assurer que notre serveur est toujours en vie, grâce a cette commande :
# iptables -A INPUT -p icmp -j ACCEPT Ainsi, nous venons de configurer notre pare feu avant d'éviter toute intrusion indésirable dans notre système. Ceci grâce aux iptables. Il existe en guise d'information, depuis la version 8.04 LTS d'Ubuntu, un autre outil, aux commandes assez simples, très puissant et qui permet de configurer un pare feu, constituant ainsi une alternative aux iptables : il s'agit de UFW (Uncomplicated FireWall). Cependant, avoir un firewall ne prémunit pas contre les dangers. En revanche, cela rend la tâche particulièrement difficile aux pirates qui voudraient accéder à notre serveur.
# postfix -add -filter amavis 10025 3.3 Gérer l'intégrité des données Ce volet de la sécurité des serveurs mails concerne le contenu des messages. En effet maintenant que les communications sont chiffrées et que les utilisateurs sont authentifiés avant toute opération, il reste a s'assurer que le contenu des messages n'est pas malveillant. 3.3.1 Filtrage de contenu avec Amavis Afin de centraliser toutes les opérations de filtrage de contenu, il faut mettre en place un démon SMTP qui sera capable de recevoir un mail, d'en extraire le contenu pour analyse puis de le renvoyer sous certaines conditions : c'est le rôle d'Amavis. Ce n'est pas un antivirus mais un outil qui fonctionne conjointement avec Postfix pour fournir le contenu du mail à des scanners tels que ClamAV. L'installation d'Amavis se fait a partir de la commande suivante : # aptitude install amavisd-new Postfix prévoit une directive spécifique pour le filtrage de contenu: content_filter. Pour analyser le contenu avant de délivrer le message, il faut donc simplement indiquer à Postfix le transport à utiliser pour faire cette analyse dans le fichier /etc/postfix/ main.cf:
content_filter = amavis:[127.0.0.1]:10024 Ainsi, Postfix transmet le message a l'outil de transport d'Amavis sur le port 10024 de la machine locale. Il faut maintenant configurer ce transport dans le fichier /etc/postfix/ master.cf. Cette modification peut-être simplement réalisée a l'aide de la commande suivante : Cette commande a permis de modifier le fichier master.cf afin d'indiquer le routage des messages. Le message sera maintenant analysé par Amavis puis, si le contenu n'est pas indésirable, il sera retransmis à Postfix sur le port 10025. Amavis est maintenant en place il suffit de redémarrer les services pour que les modifications soient prises en compte.
3.3.2 Intégration d'un antivirus : ClamAV Il existe de nombreux antivirus mais beaucoup sont distribués sous des licences propriétaires. Dans le monde de l'Open, il existe ClamAV qui fait très bien son boulot. Pour qu'Amavis puisse faire du filtrage antivirus, il faut donc installer ClamAV ainsi que quelques librairies de compression (pour analyser les archives). L'installation peut se faire a partir de la commande suivante:
# aptitude install clamav clamav-daemon gzip bzip2 unzip unrar zoo arj ClamAV est l'antivirus qui va lire le contenu des mails puis le valider et le transmettre a Postfix ou le rejeter. Pour que tout se passe correctement, il faut maintenant s'assurer que l'utilisateur "clamav" fasse partie du groupe "amavis".
# adduser clamav amavis Activation du support antivirus pour Amavis dans le fichier /etc/amavis/conf.d/15- content_filter_mode : @bypass_virus_checks_maps=(\%bypass_virus_checks,\@bypass_virus_checks_acl, \$bypass_virus_checks_re); Configuration d'Amavis dans /etc/amavis/conf.d/20-debian_defaults
$final_virus_destiny = D_BOUNCE; Redémarrage des services
Pour vérifier le bon fonctionnement de l'antivirus, on peut utiliser des sites prévus a cet effet comme GFI Email Security Test. Ces sites permettent d'envoyer des mails infectés avec un virus de test (non dangereux) vers votre serveur. En fonction des paramètres de notification qui ont été choisi, la réception de ce mail devrait, ou non, déclencher une alerte à l'administrateur du serveur. 3.3.3 Intégration d'un Anti Spam: Spamassassin Le but de Spamassassin est de filtrer le trafic des courriels pour éradiquer les courriels reconnus comme pourriels ou courriels non sollicités. Face à l'augmentation importante du spam, ce logiciel connaît un engouement important et est adaptable sur de nombreux serveurs de courriels dont Sendmail, Postfix, Exim, Qmail ; il peut être installé sur la plupart des systèmes basés sur Linux, Windows et Mac OS X. Spamassassin est un programme écrit en Perl qui fait passer un certain nombre de tests au message. En fonction du résultat de ces tests, il attribue un score au courriel. Si le score dépasse un certain seuil, le courriel est alors considéré comme du Spam. Spamassassin modifie alors le titre du message (il l'encadre par ***** SPAM *****). De plus, Spamassassin positionne deux nouveaux en-têtes au message : X-Spam-Status et X-SpamLevel. Ces deux en-têtes permettent alors de créer des filtres dans votre client de messagerie pour orienter le message (par exemple le mettre dans la corbeille). Tous les messages doivent donc passer par Spamassassin pour être traités, avant d'arriver dans leur dossier définitif. Pour installer Spamassassin et des outils anti-spam :
# aptitude install spamassassin libnet -dns -perl razor pyzor Activation de la cron Spamassassin dans /etc/default/spamassassin. Ceci permet de mettre à jour les règles chaque nuit.
CRON =1 Mise à jour des règles Spamassassin :
# sa -update La configuration de Spamassassin se fait dans le fichier /etc/spamassassin/ local.cf. Ce fichier doit être édité comme ceci :
greylist tflags URIBL_GREY net score URIBL_GREY 0.25 urirhssub URIBL_JP_SURBL multi.surbl.org. A 64 body URIBL_JP_SURBL eval: check_uridnsbl ('URIBL_JP_SURBL ') describe URIBL_JP_SURBL Has URI in JP at http://
body URIBL_BLACK eval: check_uridnsbl ('URIBL_BLACK ') describe URIBL_BLACK Contains an URL listed in the URIBL blacklist tflags URIBL_BLACK net score URIBL BLACK _ urirhssub URIBL_GREY multi.uribl.com. A 4 body URIBL_GREY eval: check_uridnsbl ('URIBL_GREY ') describe URIBL_GREY Contains an URL listed in the URIBL 3.0 tflags URIBL_JP_SURBL net
Configuration de razor en utilisant l'utilisateur amavis
Configuration de pyzor en utilisant l'utilisateur amavis # su - amavis $ pyzor disposer Il faut ensuite activer le support anti-spam pour Amavis dans le fichier /etc/amavis/conf.d/15-content_filter_mode. Il faut seulement enlever les commentaires des deux lignes suivants:
@bypass_spam_checks_maps = (\% bypass_spam_checks,\ @bypass_spam_checks_acl ,\ $bypass_spam_checks_re ); Il faut maintenant définir le comportement d'Amavis lorsque Spamassassin a terminé d'analyser le message. Comme indiqué précédemment, Spamassassin affecte un score au message. Amavis va maintenant comparer ce score au seuil défini par la variable FIXME. Si le score est supérieur à cette valeur, Amavis va appliquer les règles destinées aux messages indésirables. Le score affecté par Spamassassin n'étant jamais fiable a cent pour cent, il faire prendre beaucoup de précautions lors de la définition des règles d'Amavis. Par exemple : > il ne vaut mieux pas modifier le sujet du message en ajoutant "***SPAM***" : si le message est marqué par erreur, l'utilisateur final aura un message désirable dont le sujet commencera par ***SPAM*** ; > il est fortement recommandé de ne pas supprimer directement les messages marqués comme spam; > la méthode la plus sûr, est sans doute d'inscrire le score dans les en-têtes et de ne pas toucher au reste du message. Il suffit ensuite d'utiliser les différentes méthodes de filtrage pour que les spams soient délivrés dans un dossier spécifique. Toute cette configuration se fait dans le fichier /etc/amavis/conf.d/20- debian_defaults :
Notons qu'avec la configuration ci-dessus, les en-têtes de spam seront ajoutées sur tous les messages, quel que soit le score obtenu. Par ailleurs, tous les messages atteignant un score supérieur à 6.0 seront considérés comme Spam. Comme toujours, les modifications ne seront prises en compte qu'après un redémarrage d'Amavis :
# /etc/init.d/amavis restart 3.3.4 Tri des messages avec SIEVE Dovecot est conçu en favorisant toujours les aspects de sécurité. Il est activement développé et implémente de nombreuses fonctionnalités. L'un des atouts intéressant de Dovecot est la gestion des filtres SIEVE. SIEVE est un langage permettant de traiter les messages à leur arrivée sur le serveur : il est par exemple possible de rediriger un message vers un dossier particulier ou de mettre en place un répondeur automatique de vacance. SIEVE agit donc de manière comparable à Procmail mais apporte une fonctionnalité très intéressante: MANAGESIEVE. MANAGESIEVE est un protocole permettant de gérer les scripts de filtrage depuis l'application de messagerie cliente : plus besoin de se connecter en SSH pour éditer son script de filtrage ! Bien entendu, le support SIEVE est disponible uniquement si la livraison des messages est réalisée par le LDA de Dovecot. Configuration du plugin Pour activer le plugin SIEVE il faut éditer le fichier /etc/dovecot/dovecot.conf comme suit : protocol lda { [...] # sieve_global_path = mail_plugins = [...] cmusieve [...] } Pour activer la gestion des filtres SIEVE, il ne reste plus qu'à redémarrer le service :
# /etc/init.d/dovecot restart Édition d'un script de base dans /home/<user_name>/.dovecot.sieve:
Exemple de script pour mettre en place un répondeur automatique de vacance :
Filtres globaux Dovecot supporte les filtres globaux pour permettre à tous les utilisateurs de partager un script de filtrage. Attention cependant, le script global défini par la variable sieve_global_path ne sera exécuté uniquement s'il n'y a aucun filtre personnel pour l'utilisateur. Dans /etc/dovecot/dovecot.conf :
Création du répertoire :
# mkdir /etc/dovecot/global_script Exemple de script pour trier les mails marqués par Spamassassin :
Modification des droits:
Pour appliquer la configuration, il ne reste plus qu'à redémarrer le service :
# /etc/init.d/dovecot restart Edition des scripts : MANAGESIEVE Comme indiqué précédemment, Dovecot gère maintenant le protocole MANAGESIEVE. Ce support n'est pas encore officiel mais est disponible sous forme de patch. Coté Debian, le patch est inclus dans les paquets depuis la version 1.0.12. Pour activer le démon managesieve, il suffit simplement de l'ajouter dans la directive protocols du fichier /etc/dovecot/dovecot.conf :
Malheureusement, les clients capables de gérer correctement le protocole MANAGESIEVE sont très rares : > Il existe un plugin pour RoundCube mais qui ne fonctionne pas sur la version stable actuelle. > Le plugin Thunderbird fonctionne maintenant correctement depuis sa version 0.1.5. Ce plugin permet de gérer le protocole MANAGESIEVE mais malheureusement l'édition des scripts doit encore se faire manuellement. Ainsi, notre système de messagerie est fin prêt, opérationnel avec une sécurité, nous ne dirons pas inviolable, mais que le pirate ou hacker aura beaucoup de mal à mettre hors de portée. |
| ||||||||||||||||||||||||||||||||||||||
