Mise en place d'OpenFire sur Debian Jessie

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.

Installation de TrueCrypt 7.1 sur OS X 10.10 et suivants

J'utilise TrueCrypt comme solution de cryptage de données depuis quelques années. Outil gratuit et indépendant de tout OS (fonctionne sur Windows, OS X et GNU/Linux), je le trouve léger, fonctionnel et fiable, malgré les rumeurs qui ont conduit les développeurs à abandonner le projet. VeraCrypt semble être le fork reprenant TrueCrypt cependant par habitude j'utilise toujours TrueCrypt.

Cependant, comme TrueCrypt est assez vieux et qu'il n'a pas été mis à jour depuis 2014, son installation sur un système OS X récent est problématique. En effet, le package refusera de s'installer car il considère que la version d'OS X est trop vieille. En cause, dans le code d'initialisation du paquet, un contrôle caduc de la version d'OS X, en se basant sur la chaîne elle-même de la version de l'OS et non la valeur décimale. Ce qui signifie qu'en s'exécutant sur un OS X 10.10, 10.11 ou 10.12, l'application jugera que votre version est plus vieille que 10.4, car par ordre alphabétique, 10.10 est avant 10.4.

Afin de pouvoir installer l'application, il va donc falloir modifier ce bout de code afin de supprimer le contrôle.

Tout d'abord, il faut monter l'image disque, puis copier le fichier d'installation .mpkg. Dans cet exemple, je le copierai sur le bureau.

 

En "affichant le contenu du paquet", on va dérouler le répertoire Contents et modifier le fichier distribution.dist grâce à TextEdit ou n'importe quel autre éditeur de texte. Au début de fichier, la fonction pm_install_check est celle qui pose problème.

 

En supprimant la partie du code écrite en rouge, l'installateur ne fera plus de vérification de la version d'OS X. Il suffit d'enregistrer le fichier (si vous avez bien copié le fichier .mpkg dans un répertoire pour lequel vous avez les autorisations d'écrire, cela ne devrait pas poser de problèmes, c'est pourquoi il faut le sortir du fichier .dmg monté) et de relancer le fichier .mpkg afin que l'installation s'exécute sans anicroche.

function pm_install_check() {
  if(!(system.version.ProductVersion >= '10.4.0')) {
    my.result.title = 'Error';
    my.result.message = 'TrueCrypt requires Mac OS X 10.4 or later.';
    my.result.type = 'Fatal';
    return false;
  }
  return true;
}

Si vous voulez télécharger TrueCrypt dans sa dernière révision avant la version modifiée par les développeurs afin qu'elle ne gère plus l'écriture, je vous renvoie vers ce lien. Si vous ne souhaitez pas réaliser la modification du code vous-même, je mets à disposition sur mon miroir à la fois le fichier .dist modifié (il ne reste plus qu'à le copier-coller dans le .mpkg) ou alors le fichier .mpkg qu'il ne vous restera plus qu'à exécuter pour installer l'application.

Restriction de l'accès SSH sur ESXi 6.5

Pour des raisons de sécurité, je désactivais toujours l'accès SSH à mon serveur ESXi, laissant donc l'administration via la console web (que je n'aime pas trop par ailleurs) et le vClient.

Seulement, il n'y a pas si longtemps, les services de management ont crashé, rendant impossible la connexion via l'interface web ou le vClient, que ce soit via une machine virtuelle situé sur l'ESX ou bien en distant. Le serveur ne répondait pas non plus aux requêtes PowerCLI. J'ai donc dû demander un KVM sur le serveur afin de pouvoir prendre le shell en direct et relancer les services.

Depuis, je me suis dit qu'avoir quand même la main sur le shell pouvait être une option intéressante si besoin. Par contre, je voulais tout de même garder une certaine sécurité en ne le laissant pas ouvert depuis l'extérieur.

Via le vClient, il est possible de filtrer les connexions au serveur SSH par adresse IP ou blocs d'IP, ce qui dans mon cas m'intéresse puisque je vais lui demander d'autoriser seulement les connexions provenant de l'adresse IP LAN de mes machines virtuelles.

Dans le vClient, onglet Configuration > Profil de Sécurité > Modifier les propriétés du pare-feu puis Serveur SSH

Ensuite, la tentative de connexion depuis mon ordinateur personnel chez moi ne renvoie rien :

Depuis le réseau interne, cela fonctionne bien :

Par contre, par défaut, l'accès est possible en root uniquement. Etant donné que je possède un utilisateur standard afin d'accéder aux consoles et faire de la gestion rapide avec des privilèges limités, je voulais interdire la connexion en SSH avec l'utilisateur root et autoriser mon compte standard en connexion pour ensuite procéder à une élévation des droits avec su - mais cela ne semble plus être possible dans les dernières versions d'ESXi (testé sur 6.0 et 6.5).

Sauvegarde wbadmin impossible sur contrôleur de domaine virtuel 2012 R2

Comme premier article, je vais aborder le problème auquel j'ai été confronté récemment après avoir mis en place ma petite infrastructure que je présenterai éventuellement dans un prochain billet.

Je possède un contrôleur de domaine fonctionnant sous Windows Server 2012 R2, le seul de la forêt. Je possède un autre serveur 2012 R2, qui va recevoir sur un disque virtuel dédié les fichiers de sauvegarde des autres serveurs Windows ainsi que les fichiers des quelques scripts de sauvegardes de mes machines Linux.

Je veux donc concentrer sur ce serveur les sauvegardes Windows Server afin de pouvoir les sauvegarder en ligne plus facilement par la suite.

Sur mon contrôleur de domaine, j'installe donc la fonctionnalité Windows Server, et tente d'exécuter une première sauvegarde. Pour des raisons de performances disques (disques mécaniques en SATA3) et vu le peu de criticité, je ne souhaite pas effectuer de sauvegarde planifiée mais des sauvegardes uniques que je réaliserai de temps en temps. Je choisis donc de sauvegarder le serveur complet.

Je précise l'emplacement réseau du lecteur de sauvegarde, et je lance l'opération. Quelques minutes plus tard, la sauvegarde rentre en erreur au moment de sauvegarder le disque C:.

Dans les logs, rien de bien transcendant : c:\windows\logs\WindowsImageBackup

J'essaye donc de sauvegarder un autre serveur exactement de la même manière et avec le même compte de sauvegarde (un compte de service qui est le seul à avoir les droits complets sur le dossier du partage réseau, et qui est membre du groupe Opérateurs de Sauvegarde). Cela fonctionne, cela signifie que ce n'est pas le partage réseau qui pose problème.

Autre piste suggérée : la taille des secteurs n'est pas la même. En regardant sur les deux machines grâce à msinfo32.exe, je vois qu'ils font bien la même taille de 512 K.

Je tente un sfc /scannow sur le contrôleur de domaine afin de vérifier l'état des fichiers système, même si le serveur a été installé il y a moins de 48 heures. Pas d'erreur décelée. Je monte un second disque virtuel afin d'effectuer une sauvegarde en local, toujours impossible, le problème semble donc venir de l'accès au C:.

Finalement, je décide alors de boycotter l'interface graphique de wbadmin ainsi que l'utilisation en ligne de commande qui ne donne pas plus de résultats, même avec un lancement en tant qu'administrateur du domaine. Je recherche rapidement sur le web comment utiliser PowerShell pour se substituer au cmd et tombe sur un script fourni sur une plateforme Microsoft.
Etant donné que je n'ai pas besoin de toute la partie envoi de mail ni suivi du nombre de sauvegarde, je l'ai quelque peu simplifié.

Add-PsSnapin Windows.ServerBackup
$Server = "\\serveur"
$Folder = ($Server+"\dossier")
$WBPolicy = New-WBPolicy
Add-WBBareMetalRecovery -Policy $WBPolicy | Out-Null
$BackupLocation = New-WBBackupTarget -network ($Folder)
Add-WBBackupTarget -Policy $WBPolicy -Target $BackupLocation -force | Out-Null
$WBPolicy | Out-Null
Start-WBBackup -Policy $WBPolicy

On spécifie donc un serveur de sauvegarde, un répertoire accessible, on spécifie les paramètres souhaités dans la policy, et on exécute.
Via PowerShell, la sauvegarde s'est bien déroulée, il ne me restera plus qu'à appeler ce script lorsque je souhaiterai réaliser une sauvegarde. A noter que le script d'origine permet de sauvegarder également les autres volumes du systèmes qui sont non critiques (non swap, non système), mais n'ayant qu'un volume sur ce DC, l'option ne me concerne pas. Vous pouvez trouver le script d'origine en suivant ce lien. Apparemment la fonctionnalité WBBackup de PowerShell est conseillée par rapport au wbadmin. Question d'habitudes, j'utilisais toujours wbadmin avant.

Il ne me reste plus qu'à uploader sur mon ftp la sauvegarde pour être tranquille, et la faire redescendre sur ma station de travail au cas où.

Vous pouvez récupérer le script présent dans ce billet en le téléchargeant sur mon miroir de fichiers.