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.