Archives de catégorie : Sécurisation

La catégorie Sécurisation contient différents principes permettant de sécuriser un objet informatique, de façon théorique (par rapport à un concept) ou pratique (en réponse à une actualité).

HIDS/HIPS

Un HIDS est un système de détection d’intrusion sur un serveur. Pour les puristes, il existe des IDS et des IPS (respectivement Intrusion Detection Systems et des Intrusion Prevention Systems). La différence ? L’un détecte uniquement et l’autre empêche (théoriquement) ces intrusions.

Pourquoi utiliser un HIDS ?

Parce que des zozos vont s’amuser sans relâche à tenter de trouver le mot de passe de vos utilisateurs ou de faire l’inventaire des dossiers et répertoires contenant vos sites web pour en connaître le contenu afin l’exploiter ou d’exploiter les failles du code PHP ou ASP (au autre) de vos pages web dynamiques.

Lequel utiliser ?

Côté systèmes Linux, l’IDS le plus courant est Snort. J’avoue l’avoir testé, et force est de reconnaître qu’il est un peu touffu et complexe, même s’il est très complet et que la communauté d’utilisateurs est réactive. En outre, je n’ai pas trouvé comment l’utiliser en IPS, mais je me repencherai sur la question un peu plus tard.

Je vous recommande fortement Ossec, qui est à la fois très léger et très simple à utiliser. Il suffit de connaître quelques infos de base pour l’installation (qui est automatique), et il n’est ensuite quasiment plus nécessaire d’y toucher, sauf pour le mettre à jour. Et en plus il dispose d’une fonctionnalité active response qui le rend quasiment IPS : il peut bloquer des IP trop entreprenantes ou ce genre de chose ; ceci peut d’ailleurs être paramétré par l’utilisateur, qui peut écrire ses propres scripts lancés en réponse à ce qui a été détecté comme une attaque.

Site officiel de téléchargement : http://ossec.net

Comment installer OSSEC ?

La procédure est décrite sur la page ossec.

Synology SRM Threat Prevention

Voir https://www.cachem.fr/synology-srm-1-2-threat-prevention/

Memcached

Memcached est un service de base de données en mémoire qui est principalement utilisé pour accélérer les applications web en mettant en cache le contenu statique et les résultats des requêtes des bases de données. Le mécanisme est très simple : c’est une base de données à clé-valeur en mémoire à stockage non persistant.

Memcached n’est toutefois pas protégé par authentification et, en cas de problème de configuration du serveurs, des hackers peuvent lire et écrire des données dans la base de données. C’est pour cela qu’il est important de sécuriser cette base de données. De par ses fonctionnalités, les serveurs ainsi vulnérables peuvent être utilisés pour des attaques de déni de service.

Source : l’excellent guide OVH.

Lien : https://docs.ovh.com/fr/dedicated/securiser-serveur-avec-service-memcache/

Ingénierie sociale

L‘ingénierie sociale  est une forme de délinquance astucieuse consistant à manipuler une personne, en lui faisant croire qu’elle a affaire à un interlocuteur légitime,  pour qu’elle réalise une action ou divulgue une information.

Le phénomène est ancien mais il est en plein expansion, notamment contre les entreprises françaises (indépendamment de leur banque). Les scenarii utilisés sont de plus en plus perfectionnés et font appel aux moyens techniques modernes.

Les fraudes financières

Le but est généralement de faire réaliser un virement à son profit, d’obtenir de l’information confidentielle (bancaire, financière, technique, etc) ou de détourner des services à son profit (vol de session, de compte de réseaux sociaux).

L’escroc essaiera de se faire passer pour une personne légitime (usurpation d’identité), à distance et en utilisant tous les moyens possibles (fax, mail, et même lignes téléphoniques détournées). Il usera de menace ou d’empathie pour convaincre son interlocuteur, en montrant également assez souvent une bonne connaissance de l’entreprise et de ses processus afin de rendre son discours crédible. 

Toute demande inhabituelle dans son contenu ou dans sa forme doit être considérée comme suspecte :

  • Urgence ou confidentialité extrême ;
  • Demande de virement bancaire sortant du cadre normal (montant important, opération avec un pays ou un tiers inhabituel) ;
  • Demande de prise de contrôle du poste ;
  • Non respect des procédures internes (appel direct du président, d’un service technique).

La fraude au président

Forme élaborée d’ingénierie sociale, elle est précédée très souvent par une longue phase de reconnaissance de la part de l’attaquant (ou de l’équipe d’attaquants). Tous les moyens sont bons : registre de commerce, Kbis, sites web des entreprises, réseaux sociaux, appels téléphoniques, etc. Le coût reste très raisonnable pour une équipe motivée et organisée, et la dissimulation reste facile (cartes bancaires prépayées, standards téléphoniques IP, essais gratuits de produits comme des fax par internet ou des outils de prise de contrôle à distance d’ordinateurs, etc.).

Une fois les informations engrangées, un ou plusieurs scénarios d’attaques sont élaborés. L’attaque en elle-même consiste en un ou plusieurs coup de téléphone à une personne ciblée, afin de la pousser à réaliser un virement au profit des attaquants. Au total, le coût de l’attaque reste très faible par rapport au gain potentiel.

L’élément le plus délicat dans ce schéma de fraude est le circuit de transfert puis de blanchiment de l’argent : il doit partir au plus vite du compte bancaire de la société victime et doit être difficile à rapatrier en cas de contestation.

Les bons réflexes

En cas de sollicitation de ce type, la personne doit :

  • Ne pas céder à la pression et garder son sens critique ;
  • Continuer à respecter les processus internes ;
  • Vérifier la légitimité de la demande ;
  • Vérifier l’identité du demandeur (contre-appel sur un numéro d’appel validé, ou toute méthode validée à l’avance) ;
  • Ne pas se laisser isoler : faire appel à un collègue ou son responsable.

Tendance

Grace aux progrès de l’informatique, il ne faut désormais plus que 20 minutes d’écoute1 pour reproduire correctement la voix de quelqu’un.

Cela va grandement faciliter le travail de ces pauvres fraudeurs au président, qui avaient bien du mal avant à trouver une voix ressemblante.

Autres fraudes

La liste est infinie : escroquerie à la fausse facture, à la facture falsifiée, changement de RIB, intervention sur un système informatique de paiement ou de gestion de trésorerie pour voler une session utilisateur, etc.

Un schéma possible est que le fraudeur tente de contrôler la session utilisateur d’une victime (une personne ayant l’autorisation de faire des paiements), en prétextant être un service technique devant faire des manipulations sur l’ordinateur de la victime, à distance. Si la victime est abusée et qu’elle laisse l’accès au pirate (comme il le ferait à un helpdesk informatique, par exemple), ce dernier cherchera généralement à détourner l’attention de sa cible (en lui faisant envoyer un fax, ou poser une question à un autre collaborateur, etc) afin d’installer à demeure un moyen d’accès à l’ordinateur ciblé sans être vu.

Voir aussi

NFS

NFS est un protocole couramment utilisé pour partager des fichiers entre deux machines distantes, avec pour avantage principal d’apparaitre, une fois que le système de fichier est monté via NFS, comme n’importe quel autre répertoire local sur la machine cliente.

Ainsi, une machine cliente peut écrire sur un répertoire situé physiquement sur une machine serveur, de façon assez transparente.

Création d’un montage NFS

Première chose à savoir : NFS ne fonctionne qu’avec rpcbind (ou équivalent ; dans le temps on utilisait portmap) qui sert à faire le lien sur la machine serveur entre les outils de NFS et les ports logiciels (tcp ou udp) nécessaires pour communiquer via TCP/IP.

Installation des outils

A minima, il faut installer les outils suivants (pour une distribution style Debian) :

sudo apt-get install nfs-common nfs-kernel-server rpcbind

Paramétrage NFS

Il faut en premier indiquer dans le fichier /etc/exports quel répertoire doit etre partagé :

# /etc/exports : the access control list for filesystems which may be exported to NFS clients.
# 
# Example (NFS4)
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) 
# 
/jean            192.168.0.0/255.255.0.0(rw,no_root_squash,subtree_check)

Le premier paramètre est l’emplacement du répertoire à partager. Jusque là, ça va. Ensuite, on indique vers quelles machines le partage est autorisé (pour NFS, indépendamment de tout autre mécanisme de sécurité tel qu’un pare-feu).
Les options possibles sont assez nombreuses, et parfois complexes.

???

Il faut également paramétrer ou mettre à jour la liste des ordinateurs (hotes) autorisés à accéder au serveur NFS. Donc deux fichiers à modifier : /etc/hosts.deny et /etc/hosts.allow.

# /etc/hosts.deny : list of hosts that are _not_ allowed to access the system.
# 
portmap:ALL 
lockd:ALL 
mountd:ALL 
rquotad:ALL 
statd:ALL

Le fichier /etc/hosts.allow doit lui etre également en cohérence avec ce qu’on a indiqué plus haut. Pour simplifier, la syntaxe n’est pas identique (ça n’est plus du CIDR).

# /etc/hosts.allow : list of hosts that are allowed to access the system. 
# 
portmap:ALL 
lockd:192.168. 
mountd:192.168. 
rquotad:192.168. 
statd:192.168.

Lancement des services nécessaires

service rpcbind start 
service nfs-common start 
service nfs-kernel-server reload 
service nfs-kernel-server start

Utilisation d’un pare-feu

Choix des ports logiciels

Par défaut, les ports utilisés peuvent etre assez aléatoires.

Règles de pare-feu

Il suffit d’ouvrir les ports assignés à rpcbind (111) et NFS (2049).

Montage coté client

​mount -t cifs //MACHINEDISTANTE/Multimedia /media/MédiasPartagés -o  guest,rw,nosetuids,sec=ntlmv2 
mount.cifs //MACHINEDISTANTE/Multimedia /media/MédiasPartagés -o  user=xxx

Vérification

rpcbind -e 
exportfs

Coté serveur :

showmount -e

Coté client :

showmount -a adresse_serveur

Et ?

Sécurisation d’un partage NFS

  • http://www.tldp.org/HOWTO/NFS-HOWTO/security.html
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-nfs-security.html
  • http://www.linuxsecurity.com/content/view/117705/49/
  • http://www.sans.org/reading-room/whitepapers/linux/nfs-security-trusted-untrusted-environments-1956

Liens

  • http://www.sunhelp.org/faq/nfs.html
  • http://www.iana.org/assignments/service-names-port-numbers

EBS

Elastic Bloc Store, ou EBS, est un service d’espace de stockage destiné à être utilisé par les machines virtuelles d’AWS (EC2).

Chiffrement

Un des principaux (seuls) moyens de protéger les informations stockées sur des volumes de données est de les chiffrer. Mais que peut-on chiffrer sur un volume EBS ? La règle fournie par Amazon est simple :

  1. Les volumes créés à partir d’images chiffrées sont chiffrées.
  2. Les volumes créés à partir d’images non chiffrées ne le sont pas.
  3. Les volumes crées vides peuvent être chiffrés.

Conséquence : le volume EBS sur lequel vous installez un système d’exploitation issu d’une image machine (« ami ») non chiffrées ne le sera pas. Or c’est le cas de toutes les images machines fournies par AWS, ce qui s’explique car sinon, pour créer une instance EC2, il faudrait fournir la clé à chacun des clients, ce qui serait totalement contreproductif, vu que d’une part un chiffrement n’est utile que si la clé de chiffrement est secrète, et que d’autre part les clients d’AWS ne pourraient créer aucun instance sans disposer de cette clé, ce qui rend le processus très lourd.

Comment chiffrer les volumes de données

Il n’y a aucune astuce ni piège : il suffit de cocher la case « Chiffrement » puis de choisir la clé de chiffrement désirée en dessous. Cette clé peut être n’importe quelle clé à laquelle l’utilisateur a accès.

center

Comment chiffrer un volume EBS système ?

Il faut d’abord créer une ami non chiffrée à partir de la machine « modèle », puis faire une copie de l’ami ainsi produite et la chiffrer (je n’ai pas trouvé d’autre méthode).

center

Sources

  • https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf

Nginx

Nginx est un serveur web relativement léger qui est désormais assez répandu.

Passer en https

Un excellent article sur le sujet (en anglais) est disponible chez DigitalOcean. Un résumé se trouve ci-dessous.

Installer Certbot

Certbot est un utilitaire permettant d’avoir rapidement un certificat SSL reconnu par la plupart des navigateurs. Un petit tour sur le site officiel https://certbot.eff.org/ et c’est joué.

Sans détailler toutes les possibilités, un simple certbot certonly suffit la plupart du temps à créer les certificats. Pour cela, il faut qu’un serveur web correspondant au nom de domaine voulu soit installé et accessible pour l’utilitaire. Les éléments du certificat seront créés et il sera alors possible de les utiliser pour tous les services associés à ce domaine, même sur d’autres ports que les classiques 80 et 443 du web.

Basculer nginx en https

Sur certaines distributions, cela se fait presque tout seul. Si ça n’est pas le cas, voici les étapes pour les distributions debian-like.

Il faut commencer par modifier le fichier .conf correspondant votre site (/etc/nginx/sites-available/default pour le site par défaut). Cela doit ressembler à ceci :

# Default server configuration 
# 
server { 
        listen 80 default_server; 
        listen [::]:80 default_server; 
        server_name  www.; 
        return 301 https://$request_uri; 
} 
server { 
        # SSL configuration 
        listen 443 ssl default_server; 
        listen [::]:443 ssl default_server; 
        server_name  www.; 
        ssl_certificate         /etc/letsencrypt/live//fullchain.pem; 
        ssl_certificate_key     /etc/letsencrypt/live//privkey.pem; 
...

Pensez bien à séparer les deux serveurs, sous peine d’avoir des redirections infinies sur le site en https !

Renouvellement

Comme les certificats Let’s Encrypt n’ont qu’une durée de vie assez courte (3 mois), il faut les renouveler régulièrement. C’est extrêmement difficile et complexe, car il faut lancer la commande :

$ certbot renew

Cela ne renouvelle vos certificats que s’il y en a vraiment besoin. Donc vous pouvez même lancer la commande tous les jours, vos certificats ne seront renouvelés qu’à l’approche de l’échéance de ceux-ci. Un petit crontab et hop, le tour est joué.

Après, il reste à recopier vos éléments de certificats là où vous les utilisez, si par exemple vous vous en servez pour des services hors http/https.

Sauvegarde

Réaliser une sauvegarde de ses fichiers importants est la mesure de sécurité la plus importante qui soit. L’actualité de 2015-2016 en est la preuve, avec la prolifération de ransomwares.

Parmi les critères de choix d’un service de sauvegarde en ligne, il y en a un qui est essentiel : dans les conditions d’utilisation, vérifiez bien qu’il est écrit que si vous perdez votre mot de passe (ou votre clé de chiffrement), il sera impossible de récupérer vos données. En effet, la plupart des fournisseurs de service de sauvegarde s’engagent à ne jamais consulter ou diffuser vos données. Sous-entendu : ils peuvent le faire mais ne le feront pas.

Liste de quelques services en ligne permettant l’utilisation de clés de chiffrement personnelles, et donc ne pouvant pas lire vos fichiers.

  • Crashplan (il n’y a plus directement de plan pour les particuliers)
  • Backblaze
  • Carbonite
  • SOS
  • Mozy

Cela ne préjuge en rien de la qualité du service proposé. Pour avoir des informations complémentaires, voici un comparatif récent, en anglais :

Autres offres de stockage

  • degoo.com
    • Via une application. Pas d’autre accès possible.
  • zoolz.com
  • pCloud
    • Pas FTP/SFTP
  • sync.com
  • hiDrive (ionos)
    • Beaucoup de protocoles mais uniquement sur la formule Pro ; sinon il faudra se contenter de WebDav.
    • Client (PC) assez ancien, même s’il paraît robuste.

Critères d’évaluation

  • Présence d’un client de synchronisation
  • Gestion des droits utilisateurs
  • Gestion des versions
  • Taille max des fichiers
  • Mode de protection (chiffrement)
  • Protocoles supportés (https, ftps/sftp, ssh/scp, etc.)

Logiciels de chiffrement pour stockage en ligne

  • Boxcryptor

OpenVZ (Sauvegarde)

La sauvegarde d’une machine virtuelle OpenVZ se fait très simplement, en étant administrateur (root) de la machine.

Préparation de la partition

Pour minimiser le downtime (le temps où le serveur est indisponible), il faut utiliser un paramètre spécial de sauvegarde (cf script ci-dessous) lequel nécessite un partionnement particulier.

En effet, il faut que les machines virtuelles soient créées sur une partition de type LVM mais également il est nécessaire qu’une partie de cette partition reste disponible pour le processus de sauvegarde. Si le partionnement est généralement réalisé à l’installation, il faudra quelques commandes pour libérer de la place sur la partition LVM (par défaut, elle est montée sur /var/lib/vz.

Paramétrage du partitionnement pour une distribution de type PROXMOX

root@host:~# /etc/init.d/vz stop (arrêt du service de virtualisation) 
root@host:~# df -h (pour voir l'allocation de la partition LVM) 
Sys. de  fich.         Tail. Occ. Disp. %Occ. Monté sur 
/dev/sda1               12G  886M   11G   8% / 
tmpfs                1000M     0 1000M   0%  /lib/init/rw 
udev                   10M  2,6M  7,5M  26% /dev 
tmpfs                1000M     0 1000M   0% /dev/shm 
/dev/mapper/pve-lv1    74G  952M   69G    2% /var/lib/vz (on voit que la partition fait 74 Go). 

root@host:~# umount /var/lib/vz (on démonte la partition) 
root@host:~# e2fsck -f /dev/mapper/pve-lv1 (on vérifie son état, pour ne rien abimer) 

root@host:~# resize2fs /dev/mapper/pve-lv1 73G (on diminue la taille de 1 ou 2 Go, ce qui est généralement suffisant) 
root@host:~# lvresize --size -2G /dev/mapper/pve-lv1 (on libère 2 Go qui pourra être utilisé par le processus snapshop) 

root@host:~# e2fsck -f /dev/mapper/pve-lv1 (on re-vérifie la partition, après ces manipulations) 
root@host:~# resize2fs /dev/mapper/pve-lv1 (on met en conformité la partition et le système de fichiers) 
root@host:~# mount /dev/mapper/pve-lv1 /var/lib/vz (on remonte la partition) 
root@host:~# /etc/init.d/vz start (on redémarre le service de virtualisation)

Script de sauvegarde

Le seul paramètre important est le numéro de machine virtuelle. La première porte souvent l’identifiant 101, c’est ce que j’ai utilisé dans mon exemple.

L’option --snapshot permet de minimiser le temps d’indisponibilité de la machine virtuelle.

#!/bin/sh# 
# 
# Svg machine virtuelle 
nohup vzdump --snapshot --compress--dumpdir /svg --tmpdir /tmp 101 
# 
NOM_FICH1=vzdump-101.$(date +%Y%m%d)-$1.tgz 
cp /svg/vzdump-101.tgz /répertoire_sauvegarde/$NOM_FICH1

Script ou commande de restauration

vzrestore <fichier_de_sauvegarde> 101

Synthèse (Serveur Web)

Sécuriser un serveur web, et de manière générale gérer un serveur web, demande pas mal de connaissances et de disponibilité. Il n’existe pas de recette universelle pour sécuriser un serveur, sachant qu’en outre ils tournent souvent avec un système d’exploitation Linux dont les différentes versions comportent des particularités. Je me bornerai ici à donner quelques bases, dans le cadre d’un serveur web de type personnel, sans ambition de haute disponibilité ou autre exigence de niveau professionnel.

Considérations générales sur la sécurité des serveurs web

La sécurité d’un serveur web répond grosso modo aux mêmes impératifs que ceux d’un ordinateur personnel, mais habituellement les services utilisés (et donc exposés) ne sont pas les mêmes, et surtout par essence ils sont destinés à être accédés depuis n’importe où et par n’importe qui.

Différents points sont à étudier et à mettre en oeuvre, ils peuvent la plupart du temps être mis en oeuvre indépendamment les uns des autres ; je décrirai ici en détail les opérations pour un serveur utilisant une distribution CentOS qui est proposée chez beaucoup d’hébergeurs. Il est néamoins assez facile de les adapter à d’autres .

Il faut également distinguer l’installation du serveur (c’est-à-dire tout ce qui ne pourra pas être changé ou modifié par la suite, donc l’OS et le partitionnement) et l’installation des services.

Principes généraux de base

  1. Toujours utiliser un mot de passe fort pour chacun des utilisateurs
  2. Avoir un firewall (pare-feu)
  3. Avoir un anti-virus
  4. Employer régulièrement des anti-rootkits
  5. Connaître et utiliser des HIPS ou HIDS
  6. Conduire des audits de sécurité et avoir des outils de test
  7. Maintenir son système à jour
  8. Et bien sûr : faire très régulièrement des sauvegardes

Articles intéressants

  • https://www.thefanclub.co.za/how-to/how-secure-ubuntu-1204-lts-server-part-1-basics

TrueCrypt

Que penser de TrueCrypt ? C’est l’un des plus étonnants mystères de ces dernières années dans le petit monde de l’informatique.

TrueCrypt est un utilitaire permettant de chiffrer ses documents, voire des volumes entiers sur vos disques plus ou moins durs. Très utilisé, et même recommandé par des personnes de confiance, l’utilitaire a disparu du jour au lendemain (littéralement), sans donner d’explication convaincante1. D’autant plus étonnant que des initiatives avaient abouti à la réalisation d’un audit du code (qui est à peu près en open source), sans que l’on trouve en première approche de grosse faille ou de faiblesse particulière, à peine un mois plus tôt. Par ailleurs, en 2013, l’ANSSI avait fait réaliser une certification de premier niveau (CSPN), c’est-à-dire que fonctionnellement il répond bien à la cible de sécurité choisie.

Une communication discrète…

L’équipe de développement s’est toujours montrée discrète, ce qui est la fois un gage de sécurité (au sens où il est alors difficile de faire pression sur les auteurs) mais aussi une source d’inquiétude car il est alors impossible de connaître la notoriété ou la réputation des personnes impliquées.

…jusqu’à la fermeture !

Car ce jour là, le site fut modifié brutalement pour indiquer que le logiciel ne devait plus être considéré comme sûr, et qu’il fallait se tourner vers BitLocker, le produit de chiffrement de Microsoft dont la sécurité est difficilement évaluable puisqu’il s’agit d’un produit commercial, dont les sources sont inconnues (le retro engineering étant interdit sur les produits Microsoft), et surtout en provenance d’un éditeur soumis comme tous les autres à la législation américaine et aux agences fédérales.

Pourquoi ?

On nage alors dans le paradoxe : les développeurs de l’outil permettant d’échapper au big brother promeuvent d’un seul coup un outil sur lequel plane la suspicion ! Certains penchent pour un gag order, qui consiste en une obligation de silence, pratique relativement usuelle en droit anglo-saxon, en lien avec par exemple une interdiction de continuer à développer le logiciel (j’imagine) ou l’obligation d’y inclure une porte dérobée, ce qu’auraient refusé évidemment les développeurs.

D’autres pensent à de gros problèmes de structure et de conception, n’induisant pas de faille majeure au moment de l’examen du code, mais que les avancées technologiques rendent nécessaires de revoir, avec un coût de réécriture trop important pour les développeurs.

On peut aussi penser que c’est par lassitude, ou suite à la découverte de leur propre chef d’une faille trop importante, mais cela me semble peu probable au vu de leur communication quasi-provocatrice.

Par ailleurs, la dernière version publiée (7.2) de l’outil a été expurgée de toutes les parties de code concernant le chiffrement, ne laissant à l’utilisateur que la possibilité de déchiffrer ses données, pour ne pas les perdre, mais sans plus pouvoir les protéger. Pourquoi s’en donner la peine ? Sauf dans le cas d’une faille béante dans le mécanisme de chiffrement qui le rendrait impropre à une protection correcte des données, mais aucun des audits postérieurs à cet arrêt n’a révélé de tels problèmes.

Peut-on encore l’utiliser ?

Certains le font. En tout cas la version 7.1a2, la dernière contenant toutes les fonctionnalités et qui a été auditée, sans qu’on n’y trouve de faille sévère.

Il existe un site web assez curieux, truecrypt71a.com, qui se prétend extérieur au projet mais dont l’auteur connaît parfaitement tous les détails de TrueCrypt, et où certains passages sont rédigés à la 1ère personne (« nous », en parlant du développement de TrueCrypt). C’est une mine de renseignements, et on peut y trouver les sources et les binaires (avec des éléments d’identifications comme des signatures GPG).

Comment monter un conteneur sous Linux ?

J’ai dû me poser la question (pour le boulot), et on peut très bien le faire sans installer TrueCrypt. Il faut toutefois installer cryptsetup, un utilitaire permettant une configuration un peu plus simple (car il y a en réalité tout un tas d’autres outils mis en oeuvre).

Sur un Raspberry, sous Raspbian 10, il faut installer les packages suivants :

  • cryptsetup_1.7.3-4_armhf.deb
  • cryptsetup-bin_1.7.3-4_armhf.deb
  • libcryptsetup4_1.7.3-4_armhf.deb

On les trouve sur le site officiel de Raspbian, à l’adresse https://archive.raspbian.org/raspbian/pool/main/. Les numéros de versions changeront au fur et à mesure des mises-à-jour.

Ensuite il y a une petite manip, en trois étapes (trouvée ici) :

  • Attacher le fichier conteneur à un périphérique virtuel (loopback device) ;
  • Ouvrir le conteneur avec cryptsetup ;
  • Enfin monter le conteneur dans le filesystem.

En pratique :

$ sudo losetup /dev/loop0 nom_fichier_conteneur
$ sudo cryptsetup --type trcrypt open /dev/loop0 nom_conteneur
$ sudo mount /dev/mapper/conteneur point_de_montage

On peut donner n’importe quel nom au conteneur, qui sera ensuite accessible via /dev/mapper/nom_conteneur. On peut vérifier la 1ère étape comme suit :

$ losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE     DIO LOG-SEC
/dev/loop0         0      0         0  0 /jean/test.tc   0     512

Sources