Depuis quelques temps, je cherchais une solution de chat permettant de m’affranchir de Facebook et des autres plateformes comme WhatsApp ou Skype, afin de pouvoir satisfaire ma curiosité à ce sujet et essayer de convertir une partie de mes proches sur un outil de chat peut-être moins fringuant mais plus privé et personnel.
Après quelques recherches, je me suis donc orienté vers OpenFire qui est un serveur utilisant le protocole XMPP, qui fonctionne sous Windows, GNU/Linux et OS X. Dans mon cas précis, je vais réaliser l’installation de ce serveur sur un système d’exploitation Debian dans sa version Jessie (8.7).
1. Prérequis
Une fois l’OS de base installé, j’ajoute toujours par habitude fail2ban et proftpd, afin de pouvoir protéger le serveur par la suite et proftpd afin de faciliter le dépôt de fichiers sur la machine depuis mon filer. Ma machine étant hébergée sur un ESXi, j’installe les VMware tools.
apt-get install fail2ban
apt-get install proftpd
apt-get install open-vm-tools
A noter que par la suite, j’ajouterai certaines règles à fail2ban afin qu’il surveille les tentatives d’authentification sur le serveur OpenFire lui-même.
Dans un même souci de sécurité, je vais désactiver la connexion en root sur le serveur via SSH :
nano /etc/ssh/sshd_config
Je modifie de cette manière la ligne suivante (ancienne valeur en rouge, nouvelle valeur en vert) :
PermitRootLogin without-password
PermitRootLogin no
Puis, un redémarrage du serveur SSH pour prendre en compte la modification :
/etc/init.d/ssh restart
Plus tard, lors de la configuration, je vais choisir l’authentification par ActiveDirectory. J’ai donc créé dans mon AD un groupe « OpenFire Users » avec le compte utilisateur dont je vais me servir afin de pouvoir me connecter à l’application. Pour des raisons de sécurité, je ne vais pas utiliser le même compte que mon compte usuel sur ma plateforme Windows mais un utilisateur tout simple. Je vais également créer un compte de service qui permettra à l’application d’avoir un accès en lecture seule uniquement à l’AD, afin de ne pas avoir à renseigner le compte d’administrateur du domaine ou mon compte d’administration personnel. Pour ce faire, je vais passer par une délégation de contrôle.
 |
||
| Clic droit sur le domaine « domaine.local » puis Délégation de contrôle |
En choisissant le compte de service en question sur le domaine, je vais créer une tâche personnalisée à déléguer, sur ce dossier et les objets qui s’y trouvent. Enfin, je vais accorder les autorisations en lecture, en cochant Lire et Lire toutes les propriétés. Si tout s’est bien passé, le compte de service pourra lire le contenu du domaine.
2. Installation
Le paquet pour Debian fourni par l’éditeur d’OpenFire ne contient pas l’environnement Java nécessaire. Il faut donc l’installer préalablement. Etant donné que mon système est tout juste installé, je n’ai pas pris la peine de réaliser un apt-get update avant de lancer la commande suivante :
apt-get install default-jre
apt va installer la JRE présente dans les dépôts de Debian. La version requise par l’application est la version 1.7. Un simple java -version permet de renvoyer la version installée :
Une fois dans le répertoire dans lequel j’ai calé le paquet, un petit dpkg -i et l’installation se déroule. J’obtiens une notification comme quoi le répertoire créé pour l’utilisateur ne lui appartient pas : j’affecte un password à l’utilisateur et le rend propriétaire de son répertoire.
3. Configuration
L’installation étant terminée, j’ouvre donc un navigateur afin d’accéder à l’installateur web, qui va s’occuper de la création de la configuration de base ainsi que de la base de données. J’ai laissé les paramètres par défaut (encryption Blowfish, et les ports de la console d’administration, qui de toutes façons ne seront pas routés vers l’extérieur).
Concernant la base de données, si je voulais utiliser mon serveur MySQL, vu le peu de criticité et de besoin pour l’instant, je me suis retourné vers une base de données embarquée. Si selon l’éditeur les performances sont en retrait, cela m’importe peu dans le cadre de mon utilisation personnelle. Je verrai éventuellement pour déporter la partie base vers mon serveur MySQL si l’envie m’en prend.
Vient ensuite la partie authentification. Je vais me baser sur mon domaine ActiveDirectory. La connexion se passe sans accrocs grâce aux autorisations que nous avons accordées durant les prérequis. Les DN (distinguishedName) se déduisent facilement ou peuvent être trouvées grâce à ADSI Edit.
Je laisse par défaut les configurations de mapping utilisateur et groupes, puis je spécifie temporairement mon compte comme administrateur de l’application. Je créerai un compte d’administration de l’application plus tard.
4. Administration
En me connectant avec le login déclaré comme administrateur de l’application, je peux parcourir les différents réglages de l’application. Les délégations permettent à l’application de bien parcourir le domaine, cependant l’application ne gère pas l’écriture dans un annuaire LDAP, par conséquent, la création d’utilisateurs, la modification de mot de passe ou autres opérations ne sont pas possibles ; il faudra se connecter sur une console ActiveDirectory pour procéder à une quelconque manipulations sur les comptes.
La première chose que je vais réaliser est un blocage des comptes d’utilisateurs qui ne sont pas dans le groupe « OpenFire Users » que j’ai créé au départ. Ainsi, des utilisateurs peuvent se connecter à l’application sans avoir forcément de comptes sur mes machines, ou un accès à une machine ne donne pas forcément d’accès à l’application.
L’option est des plus explicites. Dans la liste des utilisateurs visibles, on y retrouve un icône en plus d’avoir son nom barré pour signifier que cet utilisateur n’aura pas d’accès à l’application.
Ensuite, étant donné que je suis situé derrière un pare-feu et que j’utilise le NAT pour n’utiliser qu’une seule IP pour toutes mes machines virtuelles, je vais devoir faire quelques opérations de routage sur mon appliance pfSense (que j’aurai l’occasion d’aborder dans un futur billet). Dans l’interface d’administration, chaque port est plutôt bien détaillé.
Je vais changer les ports qui ont été inscrits par défaut, et en profiter pour forcer des connexions sécurisées afin que les données ne transitent pas en clair sur le réseau. En fonction de mes besoins au départ, il y a des connexions que je ne vais pas autoriser. Quelques paramètres de sécurité méritent également le détour (qui peut se connecter, plages IP autorisées, inscriptions en ligne…).
5. Tests de connectivité cliente
Maintenant que tout est configuré côté serveur – même si il y a sans doute de quoi peaufiner – il ne reste plus qu’à faire un essai en local, et un essai depuis le web.
Je réaliserai l’essai en local depuis une machine virtuelle Debian. Le client qui se connecte à OpenFire s’appelle Spark et il est édité par la même communauté. Tout comme le serveur, le client est disponible sur Windows, OS X et GNU/Linux. Et tout comme le serveur, le paquet pour Debian est livré sans Java, il faudra donc l’installer à part. Java étant déjà installé sur ma machine, je suis donc parti pour un dpkg -i du paquet spark, cependant, je me suis heurté à un mur :
J’ajoute dans ma liste de dépôts les dépôts jessie-backports sans oublier de les rafraîchir juste après :
deb http://ftp.fr.debian.net/debian jessie-backports main
Puis, je lance un aptitude install -s afin de simuler une installation du paquet et de voir exactement ce qui merde. En cause, des dépendances non satisfaites à cause de la différence de version entre les paquets dans la branche usuelle et la branche backports de Jessie.
 |
| aptitude install -s permet de simuler une installation des paquets pour diagnostiquer ce qui ne fonctionne pas correctement. |
 |
| Je finis par accepter l’installation de ce paquet dans la version la plus récente, disponible dans le dépôt ajouté précédemment. |
 |
|||
| Le paquet s’installe bien. |
Enfin, je peux conclure en installant le paquet Java final.
Je peux enfin réaliser mon dpkg -i spark_2_8_3.deb et exécuter l’application.
Vu que je ne possède pas de certificats, je vais cocher les deux options pour accepter tous les certificats et pour ne pas vérifier le nom du serveur afin de pouvoir me connecter. Je saisis ensuite mes identifiants… Et ça marche !
Il ne me reste plus qu’à réaliser un test de connexion depuis l’extérieur, ajouter les quelques règles fail2ban si nécessaires… et demander à mes proches d’installer cette petite appli pour discuter en tout temps. Le serveur étant plus orienté utilisation professionnelle que personnelle, il n’y a pas d’application tout du moins sur iOS.