Catégorie : Open Source

Authentification SMTP avec Postfix et Dovecot SASL

Un serveur SMTP a habituellement deux fonctions dans une infrastructure de messagerie :

  • Recevoir les messages de l’extérieur pour les stocker dans les boites internes
  • Envoyer les messages soumis depuis les boîtes internes vers le monde extérieur

Si pour l’action « Recevoir » il n’y a généralement pas d’authentification de l’expéditeur (tout inconnu peut envoyer un mail vers votre serveur SMTP), il n’en est pas de même pour l’action « Soumission des messages ». Imaginez si tout inconnu pouvait envoyer des mails depuis votre serveur SMTP ! Ce serait le paradis des spammeurs 🙂 Ces paradis existent encore, il s’agit des fameux « relais ouverts ». Heureusement, ces serveurs sont très vites mis sur des liste noires par la plupart de hébergeurs de boîtes mails. Cela signifie que si votre serveur SMTP est lui-même un relais ouvert, alors même vos messages légitimes seront mis à la poubelle par les filtres anti-spam des hébergeurs.

Par défaut, le serveur SMTP Postfix autorise la soumission des messages uniquement depuis des clients positionnés dans le même réseau que le serveur lui-même. Pas très pratique pour la mobilité ! Nous verrons donc dans cet article comment mettre en place un système d’authentification SMTP des clients avec Postfix et l’implémentation SASL Dovecot.

Article écrit avec les versions Dovecot 2.2.13 et Postfix 2.11.3.

Continuer la lecture de « Authentification SMTP avec Postfix et Dovecot SASL »

Utiliser LMTP avec Postfix et Dovecot

Habituellement, Postfix livre les messages reçus dans les boites mails des utilisateurs grâce à ses agents de livraison appelés local (pour les utilisateurs locaux) et virtual (pour les utilisateurs virtuels). Cependant, ces techniques de livraison nécessitent que les boites mails soient physiquement accessibles par Postfix. Dans le cas présent, nous allons vouloir livrer les messages reçus par Postfix dans les boites des utilisateurs à travers le réseau. Nous allons pour cela utiliser le protocole LMTP entre l’agent de transfert (ou MTA pour Mail Transfer Agent) Postfix et l’agent de livraison (ou MDA pour Mail Delivery Agent) Dovecot.

LMTP (Local Mail Transfer Protocol) est un protocole similaire à SMTP (Simple Mail Tranfer Protocol) défini par la RFC 2033. A la différence du protocole SMTP, LMTP est destiné aux échanges vers un serveur destinataire qui ne gère pas de file d’attente des messages, ce qui est le cas par exemple d’un serveur de livraison des mails comme Dovecot.

Article écrit avec les versions Dovecot 2.2.13 et Postfix 2.11.3.

Continuer la lecture de « Utiliser LMTP avec Postfix et Dovecot »

Graphite : nettoyer les données Whisper

Whisper est la base de données utilisée par Graphite (à travers le démon Carbon) pour stocker les métriques accessibles classiquement par Grafana. Whisper est une base de données à taille fixe, similaire au produit RRD. Chaque nouveau métrique entraine la création d’un fichier possédant l’extension .wsp. Voici un exemple de fichier créé sous RedHat pour un métrique de type « CPU Idle » envoyé par collectd :

/var/lib/carbon/whisper/<prefix>/<server>/<suffix>/cpu-0/cpu-idle.wsp

Il n’y a pas de nettoyage automatique des métriques. Dans le cas d’une infrastructure de type cloud par exemple, la liste des métriques peut s’allonger indéfiniment au rythme des créations de nouvelles instances, entrainant une consommation de stockage tout aussi importante qu’inutile. Le nettoyage va consister simplement à supprimer les fichiers Whisper. J’utilise pour ma part cette routine :

# find /var/lib/carbon/whisper/ -type f -mtime +7 -name \*.wsp -delete
# find /var/lib/carbon/whisper/ -depth -type d -empty -delete

La première commande supprime tous les fichiers Whisper non modifiés depuis plus de 7 jours. Mon intervalle de collecte étant de 1 minute, ça laisse de la marge pour d’éventuels problèmes ponctuels.
La deuxième commande supprime les dossiers rendus vides par le nettoyage des fichiers.

Je pose cette routine dans un fichier cron sous /etc/cron.d/whisper-cleaner pour un nettoyage quotidien :

# cat /etc/cron.d/whisper-cleaner
0 9 * * * root (find /var/lib/carbon/whisper/ -type f -mtime +7 -name \*.wsp -delete; find /var/lib/carbon/whisper/ -depth -type d -empty -delete)

Grafana : remettre le mot de passe admin à sa valeur par défaut

Si vous arrivez sur cette page, c’est que comme moi vous avez probablement oublié le mot de passe que vous aviez défini un jour pour l’utilisateur admin dans Grafana 🙂 Dans ce cas, une solution est de redéfinir le mot de passe à sa valeur par défaut (admin) en modifiant directement la base de données.

Je vous propose ici une méthode pour les différents moteurs de base de données supportés par Grafana : MySQL, SQLite et PostgreSQL.

Continuer la lecture de « Grafana : remettre le mot de passe admin à sa valeur par défaut »

Authentifier avec Apache

Le but de cette petite note est l'authentification simple avec Apache permettant un contrôle d'accès sur un site.

L'environnement est un serveur Ubuntu en version 12.04 LTS muni d'un noyau Linux en version 3.2.13 et d'un serveur Apache en version 2.2.22.

1 – Créer un fichier utilisateur

La première chose à faire est de créer un fichier contenant les utilisateurs et mots de passe qui pourront se connecter au site.

Pour cela, il faut utiliser l'utilitaire htpasswd fourni par Apache.

La commande prendra trois arguments :

  • -c : pour créer le fichier, à ne plus utiliser lors de l'ajout d'autres utilisateurs
  • le nom du fichier contenant les utilisateurs/mots de passe
  • l'utilisateur à ajouter

Nous allons donc créer le fichier par l'ajout d'un premier utilisateur, la commande nous demandera ensuite de taper deux fois le mot de passe associé :

# htpasswd -c /etc/apache2/passwords toto
New password:
Re-type new password:
Adding password for user toto

Le nom et l'emplacement du fichier sont libres, attention à ne pas le mettre dans un répertoire accessible depuis l'Internet !

2 – Configurer Apache

La configuration de l'authentification peut se faire dans un fichier .htaccess situé dans le répertoire à protéger, ou dans une directive <Directory> de la configuration du site.

C'est cette deuxième méthode qui sera utilisée ici. Dans la section <Directory> correspondant au répertoire à protéger, nous allons ajouter ces directives :

AuthType Basic

Indique le type d'authentification, ici Basic. Attention, cela signifie que les mots de passe passeront en clair sur le réseau, ce type d'authentification est à coupler avec l'utilisation d'une couche SSL.

AuthName "Restricted Area"

Le nom de la zone à protéger. Elle sert à la fois d'information au visiteur mais permet aussi de regrouper plusieurs emplacements, évitant ainsi à l'utilisateur de devoir se ré-authentifier à chaque changement d'emplacement.

AuthBasicProvider file

Le fournisseur de l'authentification, ici un fichier. Ce pourrait être une base de données ou un LDAP par exemple.

AuthUserFile /etc/apache2/passwords

Comme on a précisé avant que l'on utilisé un fichier, cette directive indique son emplacement.

Require valid-user

Ce qui est requis pour accéder au répertoire. Ce pourrait être un nom d'utilisateur, ici on indique plutôt que tout utilisateur présent dans le fichier peut accéder au répertoire si son authentification a réussie.

3 – Redémarrer et tester

Il n'y a plus qu'à redémarrer Apache pour la prise en compte des modifications de configuration :

# service apache2 reload
 * Reloading web server config apache2                                                                    [ OK ]

Et à tester en se rendant sur la page : devrait alors apparaitre une boite de dialogue permettant de s'authentifier avec l'utilisateur et mot de passe configurés précédemment !

Créer une base de données MySQL

La création d'une base de données MySQL est très souvent un pré-requis à l'installation d'application Web sur u serveur.

La procédure est toujours la même, et très simple.

La création d'une base de données avec MySQL implique deux étapes :

  • la création de la base de données proprement dite
  • la création d'un utilisateur et l'attribution des droits sur cette base

La première chose à faire est de se connecter au serveur MySQL avec l'utilisateur root :

# mysql -u root -p

Une fois connecté, nous pouvons créer notre base, toto par exemple :

mysql> CREATE DATABASE toto;
Query OK, 1 row affected (0.00 sec)

Puis nous créons notre utilisateur toto qui aura comme mot de passe secret :

mysql> CREATE USER 'toto'@'localhost' IDENTIFIED BY 'secret';
Query OK, 0 rows affected (0.00 sec)

Enfin, on attribue à la base de données toto tous les droits pour l'utilisateur toto :

mysql> GRANT ALL ON toto.* TO 'toto'@'localhost';
Query OK, 0 rows affected (0.00 sec)

Voilà, la base toto est désormais configurée avec un utilisateur toto. Ces paramètres pourront ensuite être renseignés dans l'application qui ira créer ses propres tables.

Apache : ajouter un nouveau serveur virtuel par nom

La création de serveurs virtuels par nom dans Apache permet de faire cohabiter plusieurs sites sur une même adresse IP, chaque site étant accédé par son propre nom.

On aura ainsi, par exemple, deux sites Web http://monsite1.com et http://monsite2.fr qui pourront être hébergés dans le même serveur Apache tout en ne possédant qu'une seule adresse IP.

C'est la méthode la plus couramment utilisée pour créer des serveurs virtuels. L'autre méthode, la création de serveurs virtuels par IP, n'est à utiliser que dans des cas particuliers.

Logiciel utilisé : Apache 2.2.17

Distribution Linux : Ubuntu Server 11.04, Linux 2.6.38

Note : l'emplacement des fichiers de configuration est donné par rapport à l'installation du serveur Apache via Ubuntu Server. Pour une installation à partir des sources, toutes les directives seront à mettre dans le fichier httpd.conf. et la création du lien symbolique pour l'activation du site n'est pas nécessaire.

Continuer la lecture de « Apache : ajouter un nouveau serveur virtuel par nom »

Ubuntu Server : installer un serveur LAMP (Linux Apache MySQL PHP)

Un serveur LAMP est un serveur utilisant 4 composants particuliers, destiné dans la plupart des cas à la publication de sites Web :

  • Linux : le système d'exploitation
  • Apache : le serveur Web
  • MySQL : le serveur de base de données
  • PHP : le langage de script

Le but ici est d'installer ces différents composants à partir des paquetages de la distribution Ubuntu Server 13.10 qui utilise actuellement les versions suivantes des composants :

  • Linux v3.10.23
  • Apache v2.4.6
  • MySQL v5.5.37
  • PHP v5.5.3

L'installation de l'ensemble est aisé grâce aux paquetages fournis par la distribution Ubuntu Server, le tout étant de les installer dans le bon ordre 🙂

Les étapes seront les suivantes :

  1. Installer le serveur Apache
  2. Installer le module PHP pour Apache
  3. Installer le serveur MySQL
  4. Installer le module MySQL pour PHP

Article mis à jour pour Ubuntu Server 13.10

Continuer la lecture de « Ubuntu Server : installer un serveur LAMP (Linux Apache MySQL PHP) »

Dovecot : utilisation de SSL pour l’IMAP

Le but de cette note est de sécuriser une connexion IMAP à un serveur Dovecot via l’utilisation du protocole SSL/TLS.

Pour l’installation de Dovecot, on se reportera à cette note : installer un serveur de mail sous Linux avec Dovecot

Article écrit avec les versions Dovecot 2.2.13 et OpenSSL 1.0.1t.

Article mis à jour le 11/10/2016

Continuer la lecture de « Dovecot : utilisation de SSL pour l’IMAP »

Dovecot : authentification IMAP

Suite à l'installation du serveur IMAP Dovecot (cf : http://blog.moncoindunet.fr/linux/installer-un-serveur-de-mail-sous-linux-23-dovecot/), je vais ici m'intéresser aux principes d'authentification IMAP offerts par ce serveur.

Cette note sera découpée en deux parties :

  • première partie théorique, où je passerai en revue les notions et méthodes disponibles dans Dovecot
  • deuxième partie pratique, avec la mise en place d'authentifications régulièrement utilisées

Dans cette note sera évoquée la mise en place d'une authentification Dovecot sans utilisation d'une application externe. La mise en place d'une authentification couplée avec SSL ou LDAP par exemple sera traitée dans des notes ultérieures, de même que l'interaction avec Postfix.

Au niveau de la configuration, avant Dovecot 2 toutes les directives de configuration se situées dans le fichier dovecot.conf. A partir de la version 2, ce fichier a été éclaté en plusieurs fichiers situés dans conf.d, par exemple 10-auth.conf. Je parlerai donc de ces nouveaux fichiers, si vous avez une version de Dovecot inférieure à la 2, la directive se trouvera donc dans le fichier dovecot.conf (moyennant parfois quelques modifications de syntaxe).

Logiciel utilisé : Dovecot 2.0.8

Continuer la lecture de « Dovecot : authentification IMAP »