Mise à jour de la base de données, veuillez patienter...

Je suis l’heureux propriétaire de plusieurs routeurs EdgeRouter ER-X de la marque Ubiquiti, robustes et peu chers (environ 60 euros). Je me sers de ce routeur pour isoler mon réseau personnel de la box fournie par mon fournisseur d’accès à internet.

D’autre part, il se trouve que j’habite à 450 km de mon lieu de travail, et donc que je loue un studio près de mon entreprise où je suis en présentiel 3 jours par semaine. J’ai donc un deuxième abonnement internet fibre dans ce studio où j’héberge une partie de mon matériel informatique (mon “PC dans le Cloud“, mon serveur de sauvegardes externalisées et un serveur FreshRSS).

Jusqu’à présent, pour accéder à l’un ou l’autre des deux réseaux privés, j’utilisais des serveurs OpenVPN que j’ai mis en place dans chacun des réseaux. Mais pour simplifier mes usages, j’ai voulu mettre en place un VPN site à site reliant mes deux réseaux domestiques. J’ai fait pas mal de tests, que je ne détaillerai pas ici, à base de serveurs dédiés, jusqu’à optimiser la chose (de mon point de vue) en utilisant WireGuard positionné directement sur les routeurs ER-X.

Attention : relier deux sites par un VPN permanent site à site présente un risque important de sécurité. Si l’un des réseaux est compromis, l’autre l’est aussi. A faire à vos risques et périls.

Disclaimer : Je ne suis pas admin réseau, donc réfléchissez bien à deux fois avant de reproduire cette configuration. Si vous êtes spécialiste réseau, n’hésitez pas à améliorer cette configuration ER-X en commentaire, c’est aussi pour cela que je la partage.

Mon objectif est de mettre en place le schéma suivant :

ATTENTION 1 : J’utilise un FAI qui me propose (encore) une adresse IPv4 fixe pour chaque box. Il est possible de mettre en place cette configuration avec des adresses IPv4 dynamiques, mais il faut disposer d’un DNS dynamique associé à ces adresses IPv4.

ATTENTION 2 : Chaque box envoie tout son trafic entrant vers son routeur ER-X (configuré en IPv4 DMZ, config possible sur une box en mode routeur). Je bloque le trafic IPv6 car je ne maîtrise pas son fonctionnement.

La configuration se fait en 3 étapes:
– 1) Sauvegarde des configurations des routeurs ER-X
– 2) Installation de WireGuard sur chaque routeur
– 3) Configuration de chaque routeur

Première étape : sauvegarde des configurations des routeurs ER-X

Vous pouvez pour cela utiliser l’interface web d’administration du routeur (voir image ci-dessous), à la fois pour sauvegarder la configuration et pour la restaurer.

Je vous recommande également de vous entraîner sur un routeur de test avant de vous lancer sur un routeur de production le vendredi soir…

Deuxième étape : installation de WireGuard sur chaque routeur ER-X

Conformément aux instructions du site https://github.com/WireGuard/wireguard-vyatta-ubnt/wiki/EdgeOS-and-Unifi-Gateway, il faut choisir la dernière version du logiciel correspondant à votre routeur ER-X (et à sa version d’EdgeOS).

Pour les routeurs ER-X, il s’agit de la version e50, et à la date d’écriture de ce billet, du fichier e50-v1-v1.0.20211208-v1.0.20210914.deb

Pour le routeur ER-X A :

ssh adminERXA@192.168.A.254
adminERXA# curl -OL https://github.com/WireGuard/wireguard-vyatta-ubnt/releases/download/1.0.20211208-1/e50-v1-v1.0.20211208-v1.0.20210914.deb
adminERXA# sudo dpkg -i e50-v1-v1.0.20211208-v1.0.20210914.deb

Il faut ensuite générer les clefs avec la commande suivante :

adminERXA# wg genkey | tee /config/auth/wg.key | wg pubkey >  wg.public

Vous obtiendrez des clefs qui ressembleront à cela :

adminERXA# more /config/auth/wg.key #clé privée ER-X A
ADndfjehry126857hhdfyendjfk0983274nsud+jdhf=
adminERXA# more wg.public #clé publique ER-X A
AHsdkfhehdhkqjhgdiuhzdhkjhsciukjc23374485+z=

Profitez-en pour les sauvegarder dans votre KeyPass ou équivalent.

Procédez de même sur le deuxième routeur ER-X B :

ssh adminERXB@192.168.B.254
adminERXB# curl -OL https://github.com/WireGuard/wireguard-vyatta-ubnt/releases/download/1.0.20211208-1/e50-v1-v1.0.20211208-v1.0.20210914.deb
adminERXB# sudo dpkg -i e50-v1-v1.0.20211208-v1.0.20210914.deb
adminERXB# wg genkey | tee /config/auth/wg.key | wg pubkey >  wg.public
adminERXB# more /config/auth/wg.key #clé privée ER-X B
ERDncbfjhgdlkjoijdelzkj145858kjhdfkhkzh+zdd=
adminERXB# more wg.public #clé publique ER-X B
BJFURHFgshkhzihh148576091+jhzgaduygdjfjhkdz=

Troisième étape : configuration de chaque routeur ER-X

Sur le premier routeur ER-X A, créez une interface wg0 avec comme adresse IPv4 10.C.0.1/30 écoutant sur le port UDP 51820 :

ssh adminERXA@192.168.A.254
configure
set interfaces wireguard wg0 address 10.C.0.1/30
set interfaces wireguard wg0 listen-port 51820
set interfaces wireguard wg0 route-allowed-ips true
set interfaces wireguard wg0 private-key /config/auth/wg.key
commit

Puis il faut autoriser le routeur distant B et ses réseaux (avec la clef publique de ER-X B) :

set interfaces wireguard wg0 peer BJ...dz= endpoint IPv4_FAI_B:51820
set interfaces wireguard wg0 peer BJ...dz= persistent-keepalive 15
set interfaces wireguard wg0 peer BJ...dz= allowed-ips 192.168.B.0/24
set interfaces wireguard wg0 peer BJ...dz= allowed-ips 10.C.0.0/30
commit

Il faut également modifier le pare-feu avec les commandes :

set firewall name WAN_LOCAL rule 15 action accept
set firewall name WAN_LOCAL rule 15 protocol udp
set firewall name WAN_LOCAL rule 15 description 'Wireguard'
set firewall name WAN_LOCAL rule 15 destination port 51820
commit

Vérifiez que tout est configuré comme vous le souhaitez :

run show ip route

Si oui, vous pouvez enregistrer la configuration dans le routeur pour qu’elle soit lue à son prochain démarrage.

save
exit

Même opération sur le deuxième routeur ER-X B (avec l’adresse IPv4 10.C.0.2/30 pour l’autre extrémité du tunnel, et la clef publique du routeur ER-X A) :

ssh adminERXB@192.168.B.254
configure
set interfaces wireguard wg0 address 10.C.0.2/30
set interfaces wireguard wg0 listen-port 51820
set interfaces wireguard wg0 route-allowed-ips true
set interfaces wireguard wg0 private-key /config/auth/wg.key
commit
set interfaces wireguard wg0 peer AH...z= endpoint IPv4_FAI_A:51820
set interfaces wireguard wg0 peer AH...z= persistent-keepalive 15
set interfaces wireguard wg0 peer AH...z= allowed-ips 192.168.A.0/24
set interfaces wireguard wg0 peer AH...z= allowed-ips 10.C.0.0/30
commit
set firewall name WAN_LOCAL rule 15 action accept
set firewall name WAN_LOCAL rule 15 protocol udp
set firewall name WAN_LOCAL rule 15 description 'Wireguard'
set firewall name WAN_LOCAL rule 15 destination port 51820
commit
run show ip route
save
exit

A ce stade, le tunnel VPN devrait fonctionner et vous devriez pouvoir voir les machines situées sur l’autre réseau… Sinon, bon courage.

Les images réseaux de ce billet ont été construites avec ce site https://app.diagrams.net/

Pour accéder à mon réseau domestique depuis l’extérieur, j’ai mis en place un serveur VPN privé. C’est pratique, cela me permet d’accéder depuis l’extérieur à mes ressources autohébergées (serveur de flux RSS, serveurs de sauvegarde, partages familiaux, etc.) mais aussi de me protéger quand j’utilise un réseau Wifi, lorsque je me déplace avec mon matériel personnel (téléphone, tablette ou ordinateur portable).

Cela m’a permis de fermer tous les ports d’accès que j’avais ouverts sur ma box, sauf bien sûr le port d’accès au serveur VPN.

Mais ce serveur VPN est devenu pour moi un point de défaillance unique (SPOF). Et là, suite à une intervention malheureuse à distance, lors d’une maintenance admin sur ce serveur, j’ai coupé le tunnel VPN. Et pour le relancer, il me fallait… me connecter au serveur via le tunnel VPN. Bref, j’avais scié la branche sur laquelle j’étais assis. Classique.

Cette situation désagréable aurait pu être rapidement résolue si j’avais pu avoir accès à distance à un ordinateur de la maison. Hélas, Mme Zythom était au tribunal en train de défendre un innocent. J’ai donc attendu qu’elle revienne, pour pouvoir prendre le contrôle de son ordinateur (avec AnyDesk) et intervenir par rebond pour accéder à mon serveur VPN et le relancer. N’oubliez pas que je suis trois jours par semaine en télémaison ; je n’aurais pas pu tenir si longtemps sans l’accès à mes flux RSS…

En bon informaticien, je n’aime pas les SPOF mais j’aime hacker mes réseaux, par curiosité bien sûr. J’ai donc eu l’idée de mettre en place une porte dérobée, façon Elliot dans Mr Robot.

A ce stade de mon récit, et comme j’ai déjà eu à faire à la justice pour ce blog, je tiens à mettre en garde mes lecteurs, et à rassurer mes juges : l’auteur de ce blog continuera à respecter les qualités, notamment de conscience, d’impartialité et de réserve, nécessaires au plein accomplissement de sa mission d’expert, fut-il ancien expert judiciaire. La porte dérobée que je vais vous présenter n’est à installer que sur un réseau sur lequel vous disposez de toutes les autorisations du propriétaire dudit réseau. Si vous vivez encore chez vos parents, demandez leur la permission (en expliquant bien tous les risques). Bref, respectez la loi, et si vous avez un doute, abstenez-vous. Ce billet est écrit avec un esprit pédagogique, et avec en tête qu’il peut peut-être sauver les miches de quelques admins… Cette parenthèse est un peu longue, mais elle me paraissait nécessaire pour expliquer le contexte à mes lecteurs magistrats.

Je souhaite donc mettre en place une porte dérobée me permettant d’accéder à une console à distance sur mon réseau personnel pour rebondir sur mes serveurs à moi.

Cahier des charges sommaire : je veux que cette porte dérobée soit discrète pour le reste du monde, et que je sois le seul à pouvoir y accéder. Je ne veux pas faire de redirection de ports sur ma box. Elle doit me permettre de faire un ssh vers un terminal situé au cœur de mon réseau personnel. Personne d’autre que moi ne doit pouvoir y accéder, sauf à disposer de la puissance d’un ordinateur quantique. Elle doit fonctionner 24/7 et donc consommer peu d’énergie.

Voici la solution que j’ai mise en place : un service ssh caché privé Tor sur un Raspberry Pi sous Debian, c’est-à-dire un v3 Onion Hidden Service Stealth for ssh. Procédons par étapes.

Étape 1 : installer Debian sur un Raspberry Pi (ou une VM)

Je ne détaillerai pas cette étape, voici une liste de liens. Attention, Debian pour Raspberry Pi qui s’appelait Raspbian, s’appelle maintenant Raspberry Pi OS.
https://wiki.debian.org/RaspberryPi
https://www.raspberrypi-france.fr/guide/installer-raspbian-raspberry-pi/

Étape 2 : se connecter en ssh sur le serveur mis en place à l’étape 1

Idem : voir par exemple ce tuto https://raspberry-pi.fr/activer-ssh/
L’idée est d’arriver à se connecter au serveur depuis une machine cliente sous GNU/Linux avec la commande suivante :

zythom@Client:~$ ssh pi@ip-serveur

pi@Serveur:~$ 

Étape 3 : se connecter en ssh sans mot de passe
Source : Comment configurer une authentification par clé SSH sur un serveur Linux

L’objectif est de limiter les possibilités de connexion aux seuls comptes clients qui disposent de la clé privée. Si vous disposez déjà d’une paire de clés privée/publique, il vous suffit de placer la clé privée id_rsa dans le répertoire .ssh de votre compte (sans écraser celle qui s’y trouve !) et installer la clé publique sur le serveur avec la commande indiquée à la fin de l’étape 3. Sinon, vous pouvez générer la paire de clés avec la commande suivante :

zythom@Client:~$ ssh-keygen

L’ajout d’une phrase de passe est facultatif. Si vous en entrez une, vous devrez la saisir à chaque fois que vous utiliserez cette clé (à moins que vous utilisiez un logiciel d’agent SSH qui stocke la clé en clair). Je vous recommande d’utiliser une phrase de passe, mais si vous ne le souhaitez pas, il vous suffit d’appuyer sur ENTER pour contourner cette invite.

Your identification has been saved in /home/zythom/.ssh/id_rsa.
Your public key has been saved in /home/zythom/.ssh/id_rsa.pub.

Vous disposez désormais d’une clé publique et privée (sur votre machine cliente) que vous allez pouvoir utiliser pour vous authentifier. Je vous recommande de conserver précieusement une copie de ces deux fichiers dans votre Keepass.

L’action suivante consiste à placer la clé publique sur votre serveur afin que vous puissiez utiliser l’authentification par clé pour vous connecter :

zythom@Client:~$ cat ~/.ssh/id_rsa.pub | \
 ssh pi@ip-serveur "mkdir -p ~/.ssh && cat >> \
 ~/.ssh/authorized_keys"

Vous devriez pouvoir ensuite vous connecter au serveur en ssh, comme à l’étape 2, sans avoir à entrer de mot de passe lié au compte, mais une phrase de passe liée aux clés.

Étape 4 : Installer Tor sur le serveur et configurer un Hidden Service pour ssh

Sur le serveur, exécutez la commande suivante pour rejoindre le réseau Tor :

pi@Serveur:~$ sudo apt install tor

Toujours sur le serveur, modifiez /etc/tor/torrc en ajoutant les lignes suivantes (j’ai choisi le port 6001 pour éviter le port 22, plus par superstition que pour une raison valable) :

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 6001 127.0.0.1:22

Redémarrez Tor :

pi@Serveur:~$ sudo service tor restart

Vérifiez la création du répertoire /var/lib/tor/ssh
et récupérez le contenu du fichier /var/lib/tor/ssh/hostname

pi@Serveur:~$ sudo cat /var/lib/tor/ssh/hostname
3bjgocu36yuyggl...utbofs7us27gd6gvopwuvlywaodabzsad.onion

pi@Serveur:~$ 

La longue ligne se terminant par .onion est le petit nom de votre serveur sur Tor : je l’appellerai “nom-tor-etape4.onion” dans la suite du billet. Il est d’ores et déjà joignable depuis toute la planète depuis le réseau Tor (voir étape suivante), sans avoir à intervenir sur sa box pour rediriger des ports…

Étape 5 : utiliser Tor pour se connecter en ssh sur votre serveur

Vous avez deux manières de faire :

Soit en utilisant torsocks

zythom@Client:~$ sudo apt install torsocks

zythom@Client:~$ torsocks ssh -p 6001 pi@nom-tor-etape4.onion

pi@Serveur:~$ 

Soit en utilisant ncat et les options de ssh (source https://debian-facile.org/doc:reseau:tor)

zythom@Client:~$ sudo apt install ncat

zythom@Client:~$ ssh -o VerifyHostKeyDNS=no -o CheckHostIP=no -o IdentitiesOnly=yes -o ProxyCommand="ncat --proxy 127.0.0.1:9050 --proxy-type socks5 %h %p" -p 6001 pi@nom-tor-etape4.onion

pi@Serveur:~$ 

Étape 6 : transformer votre Hidden Service en Hidden Service Stealth

C’est l’étape la plus intéressante. Elle permet d’interdire à toute machine non autorisée d’essayer de se connecter au service ssh de votre serveur caché. Pour cela, vous allez avoir besoin de générer des clés que vous associerez à vos deux machines.

S1) Sur la machine cliente, générez une paire de clés en utilisant l’algorithme x25519 :

zythom@Client:~$ openssl genpkey -algorithm x25519 \
 -out toto.prv.pem

S2) Transformez les clés en format base32 :

zythom@Client:~$ sudo apt install basez

zythom@Client:~$ cat toto.prv.pem | \
 grep -v " PRIVATE KEY" | \
 base64pem -d | \
 tail --bytes=32 | \
 base32 | \
 sed 's/=//g' > toto.prv.key

zythom@Client:~$ openssl pkey -in toto.prv.pem -pubout | \
 grep -v " PUBLIC KEY" | \
 base64pem -d | \
 tail --bytes=32 | \
 base32 | \
 sed 's/=//g' > toto.pub.key

S3) affichez la clé publique :

zythom@Client:~$ cat toto.pub.key WWRQ37XF6U6FNWH...VHFK7CH4OX4THEUHC5N75IHA

S4) affichez la clé privée :

zythom@Client:~$ cat toto.prv.key GACZ2JCBS4CBKTPYX...4A6PMQANRDK66NBKGYTFAA

S5) Côté serveur :
Créez un fichier zythom.auth dans le répertoire /var/lib/tor/ssh/authorized_clients
contenant la clé publique du S3) formaté comme suit : descriptor:x25519:clé-du-S3

pi@Serveur:~$ sudo su
pi@Serveur:# echo "descriptor:x25519:WWRQ37XF6U6FNWH...VHFK7CH4OX4THEUHC5N75IHA" > /var/lib/tor/ssh/authorized_clients/zythom.auth

pi@Serveur:# cd /var/lib/tor/ssh/authorized_clients
pi@Serveur:# chown debian-tor.debian-tor zythom.auth
pi@Serveur:# chmod 600 zythom.auth
pi@Serveur:# service tor restart

S6) Côté client :
Modifiez le fichier /etc/tor/torrc pour y ajouter la ligne suivante :

ClientOnionAuthDir /var/lib/tor/onion_auth

Puis créez le répertoire /var/lib/tor/onion_auth

zythom@Client:~$ sudo su
zythom@Client:# cd /var/lib/tor
zythom@Client:# mkdir onion_auth
zythom@Client:# chown debian-tor.debian-tor onion_auth
zythom@Client:# chmod 700 onion_auth

Créez dans ce répertoire onion_auth un fichier zythom.auth_private contenant 
adresse-en-onion-sans-le-onion:descriptor:x25519:la-clef-privée-affichée-en-S4

zythom@Client:# cd onion_auth/
zythom@Client:# echo "nom-tor-etape4:descriptor:x25519:GACZ2JCBS4CBKTPYX...4A6PMQANRDK66NBKGYTFAA" > zythom.auth_private

zythom@Client:# chown debian-tor.debian-tor zythom.auth_private
zythom@Client:# chmod 600 zythom.auth_private
zythom@Client:# service tor restart

Étape 7 : utiliser Tor pour se connecter en ssh sur votre serveur

Ce sont les mêmes commandes qu’à l’étape 5, mais qui ne peuvent être exécutées que depuis votre machine cliente :

zythom@Client:~$ torsocks ssh -p 6001 pi@nom-tor-etape4.onion 

Ou :

zythom@Client:~$ ssh -o VerifyHostKeyDNS=no -o CheckHostIP=no -o IdentitiesOnly=yes -o ProxyCommand="ncat --proxy 127.0.0.1:9050  --proxy-type socks5 %h %p" -p 6001 pi@nom-tor-etape4.onion

Et voilà. Vous pouvez bien sûr créer des alias pour ces commandes afin de vous faciliter la vie. Amusez-vous bien.

Dans mon univers professionnel, Retex signifie “Retour d’expérience” (on dit aussi Rex). Je vais donc vous faire le retour d’expérience d’une alerte cyber ratée. Ce blog me permet en effet de partager mes expériences, et en particulier mes peines.

A 12h22 ce jour là, je reçois une alerte curieuse en provenance de ma supervision “Microsoft Defender for Cloud Apps” : une adresse IP suspecte détourne du trafic de mes utilisateurs.

Aussitôt, je procède à quelques vérifications : cette adresse IP est repérée par Microsoft comme utilisée par un “Serveur C&C pour la propagation de programmes malveillants”.

Pour le lecteur profane en la matière, il faut comprendre qu’aujourd’hui les pirates attaquent souvent leurs cibles avec l’aide de botnets, c’est-à-dire avec l’aide de réseaux de machines qu’ils contrôlent à l’insu de leurs propriétaires. Et pour contrôler ces ensembles de machines, ils utilisent des serveurs de commande et de contrôle (les serveurs C&C ou C2). Ces botnets sont utilisés pour des actions malveillantes, comme par exemple des exfiltrations de données, des envois de spam ou de malwares, ou des attaque DDOS…

Je poursuis mes investigations : avec l’interface de Microsoft Defender for Cloud Apps, je filtre les journaux d’activité de mes utilisateurs reliés à ce serveur piraté. Le constat est grave : plusieurs dizaines de comptes de mes utilisateurs sont utilisés avec des authentifications valides, et cela depuis plusieurs applications Microsoft (Teams, Outlook, Sharepoint…)

Le pirate contrôle et utilise plusieurs dizaines de comptes de mon entreprise !

Je remonte un peu dans le temps, et je constate que le pirate a pénétré l’entreprise depuis au moins un mois ! Mon sang se glace.

Être RSSI (Responsable de la Sécurité du Système d’Information), c’est être en permanence sur le qui-vive. Tous les RSSI le savent, leur entreprise n’est pas à l’abri d’une attaque cyber de grande ampleur. Non seulement ils s’y préparent, mais ils savent que cette attaque majeure, celle qui mettra tout le système d’information par terre, ARRIVERA.

Nul ne sait quand, ni comment, ni l’aspect qu’elle prendra. Mais tout s’arrêtera.

Le RSSI est donc comme Giovanni Drogo, personnage central du “Désert des Tartares”, roman de Dino Buzzati : il se prépare toute sa vie à la grande attaque finale…

Me voici donc en train d’observer de l’intérieur cette prise de contrôle des comptes de mes utilisateurs.

Après quelques minutes de sidération, je prends la décision de faire cesser l’attaque : je demande à l’équipe en charge des parefeux d’isoler les flux en provenance et vers ce serveur C&C, à l’équipe d’admin de modifier tous les mots de passe des utilisateurs concernés, à l’équipe support de s’attendre à un grand nombre d’appel d’utilisateurs en détresse et j’active la pré-alerte pour les participants à la cellule de crise cyber.

Tous mes messages sont conditionnels par précaution, mais je ne cache à personne la gravité potentielle de la situation.

Je révise mes fiches de procédure dans mon classeur de gestion de crise fraîchement créé, je retrouve les numéros de téléphone des personnes à appeler pour les différentes phases de la crise.

L’un des ordinateurs compromis est rapidement récupéré par le support grâce à la rapidité d’un des utilisateurs. Je m’apprête à en faire une image disque pour analyse ultérieure.

Il est 12h30, j’ai déclenché tout ce que j’avais à déclencher.

Non : je contacte l’hébergeur gérant l’adresse IP compromise, via son formulaire “abuse” pour qu’il agisse afin d’isoler ce serveur C&C.

12h45, les ingénieurs réseaux commencent à me remonter de l’information. Nous faisons un point en conférence téléphonique pour évoquer toutes les causes possibles. Le SIEM on prem n’a pas réagi, mais le serveur de logs montre bien la présence de l’adresse IP du serveur C&C.

Et elle est présente en nombre.

Je me prépare à un week-end difficile.

13h, les ingénieurs réseaux m’informent que parmi les ordinateurs concernés, le mien en fait partie. Ils me donnent la date et la plage horaire exacte pendant laquelle tout le flux de mon poste est passé par le serveur C&C. J’arrête mon ordinateur.

Depuis mon ordinateur de secours (un vieil Apple perso que je garde vivant et à jour via ma 4G perso et sans mes comptes professionnels), je vérifie ce que j’ai fait au moment indiqué par les équipes réseaux.

J’étais en train de travailler dans le train.

Avec cette information cruciale, et après quelques vérifications techniques, voici donc le message que j’ai envoyé à toutes les personnes impactées par cette alerte :

[...explications sur le contexte de l'attaque...]
Suite aux investigations techniques plus approfondies, menées avec diligence par l’équipe  Réseaux, il s’avère que Microsoft s’est trompé en indiquant que l’adresse IP XXX est malveillante.

Il s’agit en fait d’une adresse IP utilisée par le service Wifi de la SNCF.

L’alerte était donc un faux positif : je peux donc vous annoncer que votre compte n’a pas été compromis, ni piraté.

La rapidité est un élément clé dans une attaque informatique, et j’assume seul la responsabilité de cette décision. Néanmoins, j’ai conscience du dérangement important occasionné et je vous présente mes excuses les plus sincères.
[Zythom]

Fin du Retex, vous pouvez relire le billet avec la solution en tête et vous moquer autant que vous voulez, mais le soir, toute honte bue, j’ai ouvert une bouteille de champagne.

PS:
– Toujours utiliser le conditionnel quand on explique aux utilisateurs que leur compte a été compromis.
– Ne pas faire confiance aveuglément aux classifications des outils d’alerte.
– Garder à l’esprit que nos raisonnements restent faillibles, surtout sous la pression.
– Lorsque les utilisateurs ont pu lire mon message après avoir récupéré le contrôle de leur compte suite au changement de mot de passe, la plupart m’ont remercié et encouragé.
– Je pense que si quelqu’un lit les remontées des formulaires “abuse”, et s’il fait les vérifications, il doit parfois bien rire…

J’ai déjeuné avec un jeune RSSI dynamique et enthousiaste. Il s’agissait d’un repas professionnel, ce que j’évite en général tant les postures y sont artificielles.

La discussion était pourtant intéressante et nous en étions à échanger sur nos parcours respectifs quand le jeune me dit soudainement :
“vous ne seriez pas Zythom par hasard ?”

Un peu interloqué, j’acquiesce puisque je ne me cache pas vraiment derrière ce pseudonyme, qui me sert plus de sas entre ma vie professionnelle et ma vie de blogueur. C’est alors qu’il me dit “Incroyable, j’ai choisi mes études et ce métier (de RSSI) grâce à votre blog !”

Nous avons ensuite discuté jusqu’à une heure avancée de la nuit, partageant nos passions de l’informatique en général, et de la sécurité informatique en particulier. Mais sa remarque m’avait profondément ému.

Mes 10 années comme professeur d’informatique à plein temps dans une école d’ingénieurs m’ont appris ce plaisir de revoir des anciens étudiants aux détours de leur carrière et d’échanger sur leur jeunesse et mon impitoyable “UN ALGORITHME, CA DOIT TOUJOURS TENIR SUR UNE FEUILLE A4 !”, et sur les 1000 petites anecdotes qui rythment les amphis, les TD, les TP ou les salles informatiques en libre service. Mais c’est la première fois qu’un expert de la sécurité me dit que ce blog est à l’origine de sa passion et de son métier.

“Vous avez raconté la réalité des enquêtes informatiques que vous avez menées pour le compte de la justice, et vous l’avez expliqué dans des termes accessibles à l’adolescent que j’étais…”

Diantre, cela m’a touché beaucoup plus que je ne le pensais.

Je me suis souvenu alors de mes années d’adolescent écartelé entre les filles et les bricolages électroniques, entre les filles et le club d’informatique, entre les filles et les revues scientifiques, entre les filles et les avancées de l’intelligence artificielle, entre les filles et le LISP, entre les filles et le calcul des prédicats…

Je me suis souvenu que dans le club d’informatique de mon école, il y avait un panneau à l’entrée de la salle sur lequel nous avions écrit “Hacker’s corner” et qu’à l’époque, “hacker” signifiait simplement “bidouilleur”. Nous étions à la fois des jeunes curieux et de curieux jeunes. Nous étions passionnés et nous avions envie de partager notre passion. Nous avions envie de montrer que l’informatique pouvait être facile, pouvait faciliter la vie des gens, pouvait offrir un monde meilleur.

Et puis le temps est passé, la réalité des adultes s’est imposée à moi. La vie a été une longue descente aux enfers : chercheur en IA, puis professeur d’informatique, puis DSI et expert judiciaire, puis enfin RSSI. De la tour d’ivoire, à la soute.

Alors quelles ont été mes motivations ? Qu’est-ce qui peut bien motiver le RSSI que je suis devenu ? Voici mon top 3 :

La première me semble être la soif d’apprendre. Bidouiller, démonter, comprendre, hacker restent mes moteurs principaux. En 1159, Jean de Salisbury prête à son maître Bernard de Chartres la citation suivante : “Nous sommes comme des nains assis sur des épaules de géants. Si nous voyons plus de choses et plus lointaines qu’eux, ce n’est pas à cause de la perspicacité de notre vue, ni de notre grandeur, c’est parce que nous sommes élevés par eux.” Le philosophe Francis Bacon ne nous enseigne-t-il pas également que “Nam et ipsa scientia potestas est” (Savoir, c’est pouvoir), lui qui a inventé en 1605 un système de stéganographie qu’il a appelé “alphabet bilitère“, basé sur un code binaire et un texte de couverture. Pour revenir à mon époque, je dirai plutôt que je me sens comme un homme de petite taille cherchant à escalader des géants.

Ma seconde motivation est sans doute plus pragmatique : dans un monde numérique qui va de plus en plus mal, il faut/faudra de plus en plus de soldats pour défendre le village global. J’ai envie d’être membre du bataillon d’exploration avec pour objectif de rendre à l’être humain la liberté qu’il a perdue lors de l’attaque des Titans (ne spoilez pas, je n’en suis qu’à la saison 2 !).

Enfin, ma troisième motivation vient de ma rencontre, certes (sans jeu de mot) brutale, avec le monde de la cyber lors des 10 ans du SSTIC en 2012. J’y ai découvert des intelligences hors normes (et hors diplômes), des techniciens hors pairs et une agitation cérébrale bon enfant. J’ai eu envie d’en rencontrer plus.

Mais vous, si un jour vous croisez quelqu’un qui a déclenché en vous le déclic, n’hésitez pas à le lui dire, cela l’emplira de bonheur.

Je suis fréquemment interrogé par des avocates pour mener un audit de la sécurité informatique de leur cabinet. Cela vient bien sûr de mon parcours d’expert judiciaire en informatique, de mon travail comme informaticien responsable de la sécurité du système d’information d’une grande école de commerce, mais aussi du fait que la femme de ma vie exerce avec brio la difficile profession d’avocate. Ses consœurs me contactent donc de temps en temps pour que je les conseille sur leurs usages numériques.

Je me suis dit que cela pourrait intéresser un cercle plus large d’avocates, en particulier les jeunes qui sortent fraîchement diplômées et souhaitent poser rapidement leur plaque.

Comme je suis prudent, je vais commencer par un avertissement : suivre mes conseils se fait intégralement à vos risques et périls. Je ne pourrais pas être tenu responsable des dommages pouvant résulter des recommandations que je donne sur ce blog, ni des conséquences de l’usage de l’informatique que je préconise, dans le passé, le présent ou le futur. Il est fait attribution exclusive de juridiction aux tribunaux compétents de Tandaloor.

Ma première recommandation : faites appel à un informaticien connu et reconnu, de la même manière que vous recommanderiez à un justiciable de se faire accompagner par une avocate pour tout problème juridique. Vous pouvez donc stopper ici la lecture de ce billet, ou continuer, mais seulement si vous êtes curieuse.

Point grammaire : j’utilise à dessein le terme d’avocate plutôt que celui d’avocat depuis le début de ce billet, non seulement parce que l’une d’entre elles est la femme qui illumine ma vie de ses plaidoiries enflammées, mais aussi parce que les femmes sont majoritaires dans cette profession depuis 2009 (source) et que j’ai envie d’inventer une nouvelle règle de grammaire : celle du genre majoritaire. J’espère que vous me passerez cette coquetterie, qui n’a pour seul objectif que d’agacer les trolls qui ne manqueront pas de venir pleurer en commentaire pour défendre la règle dite du “masculin l’emporte sur le féminin”.

Seconde recommandation : chiffrez le disque dur de votre ordinateur.

J’ai commencé par cette question simple, lors de mon intervention à la table ronde des Confluences pénales de l’Ouest 2019 dont le thème était “Justice et secret(s)”: qui dans la salle chiffre le disque dur de son ordinateur ? Seules quelques mains se sont alors levées parmi les centaines d’avocates présentes, et j’ai même entendu quelques unes poser la question “mais ça veut dire quoi chiffrer ?”.

Point définition : Le chiffrement (ou cryptage) est un procédé de cryptographie grâce auquel on souhaite rendre la compréhension d’un document impossible à toute personne qui n’a pas la clé de (dé)chiffrement. Les québecoises définissent ainsi le chiffrement : Opération par laquelle est transformé, à l’aide d’un algorithme de chiffrement, un texte en clair en un texte inintelligible, inexploitable pour quiconque ne possède pas la clé cryptographique permettant de le ramener à sa forme initiale.
Je vous laisse fureter sur les liens pour parfaire votre connaissance du terme et de ses dérivés.

Point terminologie : J’ai pu vérifier que les oreilles des juristes saignent quand elles entendent que la loi stipule, mais les informaticiens tuent un chaton à chaque utilisation du mot cryptage. De même que “le contrat stipule et la loi dispose”, on chiffre les messages et on crypte les chaînes de télévision. Et pour moi, crypter, c’est mettre en crypte.

Chiffrer le disque dur de son ordinateur, c’est donc le rendre inexploitable pour quelqu’un qui ne dispose pas du “sésame ouvre toi”.
Par exemple, en cas de perte ou de vol.

A ce stade de la lecture, avec mon expérience d’enseignant-chercheur basée sur 100% des étudiants de mon cours d’initiation à la sécurité informatique, vous devez être en train de penser : “bah, ça ne me concerne pas, ça ne m’arrivera pas, pas à moi… Si je me fais assez petite, dans toute ma vie professionnelle, jamais je ne perdrai mon ordinateur ou ne me ferai cambrioler.“

J’ai la même statistique pour mon conseil sur les sauvegardes, qui fera l’objet d’un autre billet.

En tant qu’avocate, vous êtes une cible privilégiée. D’une part tout le monde pense que vous êtes riche (alors qu’en fait ce sont les notaires), et d’autre part votre assurance Responsabilité Civile Professionnelle (Complémentaire) ne couvre pas la perte d’image professionnelle quand toutes les données de vos clients seront dans la nature…

Donc chiffrez le disque dur de votre ordinateur.

Comment chiffrer le disque dur de son ordinateur ?

Si vous êtes sous Windows, je vous recommande d’activer BitLocker (par exemple en suivant cet article). Attention, si votre ordinateur est ancien ou dans une vieille version de Windows, il faudra passer au tiroir caisse et acheter un ordinateur plus récent ou installer une version plus récente de Windows. Faites vous aider par un informaticien et sauvegardez vos données auparavant (fichiers, mots de passe, etc.).

Si vous êtes sous macOS d’Apple, activez FileVault (par exemple en suivant l’aide du support Apple). Attention, si votre ordinateur est ancien ou dans une vieille version de macOS, il faudra passer au tiroir caisse et acheter un ordinateur plus récent ou installer une version plus récente de macOS. Faites vous aider par un informaticien et sauvegardez vos données auparavant (fichiers, mots de passe, etc.).

Si vous êtes sous GNU/Linux, félicitation. Vous trouverez beaucoup de tutos sur les différents outils de chiffrement disponibles pour votre distribution, ainsi que l’aide directe de nombreux bénévoles. Pour ma part, mon conseil est simple : sauvegardez toutes vos données et réinstallez votre distribution en cochant l’option “tout chiffrer” ad-hoc lors de l’installation. Quoiqu’il en soit, vous n’aurez a priori pas besoin de l’aide d’un informaticien, ni de passer par le tiroir caisse. Par contre, vous allez galérer avec le support du Cloud des Avocats du CNB qui ne prend pas en compte d’autres OS que Windows ou MacOS… Je vous invite à rejoindre (si pas déjà fait) le groupe “Avocats sous Linux” sur Facebook ou sur Google Groups.

Si vous utilisez un autre système d’exploitation (par exemple NetBSD, FreeBSD, OpenBSD…), vous savez sans doute déjà comment faire, moi pas.

Ce billet commence à être très long, vous avez certainement beaucoup de pain sur la planche, et moi aussi car ma douce et tendre est encore en garde à vue à cette heure avancée de la nuit et qu’il me faut mettre en page ses conclusions.

A bientôt pour la suite de ce billet qui devrait être consacrée aux sauvegardes. SGDZ.