Archives par mot-clé : Technique

Je suis curieux par nature, et par construction, aussi j’aime apprendre et comprendre des domaines qui ne sont pas de ma compétence métier première. C’est le cas de la gestion technique d’un réseau informatique. Au fil des années, la maîtrise d’un réseau informatique est devenue de plus en plus complexe, au point que les admin réseaux sont maintenant des experts indispensables à la mise au point, au fonctionnement, à l’entretien et à la sécurité d’un réseau informatique. Et je ne suis pas admin réseaux…

Je ne pouvais donc pas continuer à empiler des technologies dans mon réseau informatique personnel, et j’ai donc décidé de faire un grand nettoyage concernant son fonctionnement. C’est ce que je vais décrire sommairement ici, si cela peut aider un internaute à avoir une idée de ce dans quoi il s’embarque quand on touche aux réseaux.

Je ne suis pas certifié CISCO, ni HP, ni par aucun constructeur, mais j’ai apprécié le fonctionnement professionnel d’un bon nombre de leurs équipements, malgré le niveau de bruit des ventilateurs et la chauffe des composants. Je me suis tourné vers un constructeur d’équipement semi pro, avec une interface clicodrome qui me simplifie la vie. J’ai supprimé tous mes équipements réseaux hétérogènes (enfin presque).

Mes équipements réseaux sont tous de la marque Ubiquiti (ce billet n’est pas sponsorisé) : j’ai un cœur de réseau UDM Pro et quatre bornes Wifi UAP AC Pro. Le réseau filaire est de catégorie 5E en attendant de le remplacer par de la fibre optique, et pour m’éviter d’ajouter des câbles qui manquent parfois dans un coin de la maison, j’ajoute des petits switchs ER-X qui font le job silencieusement à un prix mini.

Les équipements filaires propagent 7 VLAN : Hébergement, Management, Bureau professionnel, Maison, IoT, Guest et FreePlayer. Les 4 derniers réseaux sont également propagés sur des réseaux Wifi associés.

La box de l’opérateur Free est en amont de l’UDM Pro que j’ai placé dans la DMZ de la box.

L’hébergement de ce blog est porté par une machine virtuelle Debian avec WordPress au sein d’un NAS Synology équipé de Virtual Machine Manager, et situé dans le réseau intitulé « Hébergement ». Ce réseau contient également une VM Debian avec mon serveur de flux RSS FreshRSS autohébergé.

Tous les réseaux sont étanches, avec des règles de firewall inspirées de cet excellent billet de Mikaël Guillerm. Pour l’anecdote, le réseau intitulé FreePlayer me permet de faire fonctionner correctement la télévision branchée dessus, en passant par un réseau Wifi dédié. En analysant les trames du FreePlayer, et en lisant un certain nombres d’articles sur le sujet, j’ai choisi un VLAN 100 avec un réseau IPv4 en 192.168.27.0/24 et un réseau IPv6 en mode SLAAC.

Plusieurs services sont accessibles depuis l’extérieur : ce blog, un serveur VPN Wireguard et un serveur VPN de secours OpenVPN. Ces trois services m’ont donné beaucoup de soucis car très attaqués. J’ai donc là aussi choisi la facilité : j’ai ouvert un compte gratuit chez Cloudflare et seules les adresses IP Cloudflare sont autorisées pour l’accès à ce blog. Pour le serveur VPN Wireguard, il est proposé nativement par l’UDM Pro et semble bien protégé. Pour le serveur OpenVPN du NAS Synology, je n’ai autorisé que les adresses IP françaises. Le monitoring de ces services est fait par UptimeRobot sur lequel j’ai ouvert un compte gratuit. J’ai un peu pesté contre Synology dont le parefeu ne permet pas d’autoriser la liste des adresses IP des sondes UptimeRobot sans bidouille.

Le réseau professionnel me sert pour le télétravail, pour ma machine de minage / cassage de mots de passe, et pour tous les tests que je peux faire sur mon Proxmox et sur mon poste d’attaque Kali.

J’ai encore mon NAS DIY basé sur un petit cube MicroServer Gen 8 HP sous OpenMediaVault pour mes sauvegardes dont je parlais ici en 2016. mais dans la simplification des technologies que je mène, j’ai acheté un espace « à vie » de 2To chez pcloud qui double mes sauvegardes distantes que je fais sur mon vieux Synology que j’ai placé dans ma coquette studette parisienne. L’application pcloud a simplifié également les transferts de photos entre nos différents téléphones.

J’ai encore beaucoup de choses à apprendre, en particulier sur IPv6 qui n’est autorisé chez moi pour l’instant que sur un seul réseau filaire. Bien sûr, le parefeu IPv6 de la Freebox est activé, ainsi que celui de l’UDM Pro. Je lis aussi avec attention les articles de Stéphane Bortzmeyer sur DNSSEC, mais j’avoue que je suis encore très tâtonnant sur le sujet. Les équipements et les ordinateurs de la maison utilisent les DNS sécurisés de Quad9, sauf ma machine perso qui héberge son propre serveur DNS non censuré.

Le plus dur reste à faire : ranger mon bureau, et jeter les câbles BNC et leurs bouchons de terminaison…

Ce billet est la suite de celui-ci et me permet de faire un bilan de cette expérience.

Tout d’abord, je voulais utiliser du matériel d’occasion pour me faire une machine de cassage de mots de passe basée sur les anciennes cartes graphiques de mon gamer de fils. Puis est née l’envie de regarder un peu du côté des cryptomonnaies, pour découvrir cet univers. Enfin, l’idée était de remplacer mon chauffage électrique d’appoint qui me chauffe l’hiver. J’ai donc mené cette expérience tout l’hiver, prolongée jusqu’au mois de mai où j’ai éteint ce mini rig de minage.

La machine

Il s’agit d’un ancien PC dont la carte mère possède trois ports PCI-Express 1x qui me permettent de déporter les cartes graphiques loin du boîtier, grâce à des « Riser PCI » achetés pour mettre les cartes à la verticale.

Si au départ j’ai utilisé plusieurs alimentations séparées, « bricolées » pour démarrer sans être reliées à la carte mère, j’ai fini par récupérer une alimentation unique de 850W qui me permet d’alimenter la carte mère et les cartes graphiques. Notez que j’aurais pu simplement acheter un câble « double alimentation » à 12€ permettant de brancher deux alims ATX sur la même carte mère. Mais bon, les alims étaient vieilles, chauffaient beaucoup et je n’avais pas trop envie de mettre le feu à ma studette…

J’ai utilisé trois cartes graphiques : 2 GTX1080Ti (dont une achetée sur LeBonCoin) et 1 GTX1060, toutes branchées sur leur riser. J’ai ajoutée quelques radiateurs passifs qui traînaient dans mon bazar, afin d’extraire le plus vite possible la chaleur des GPU (en plus des ventilateurs d’origine) et les maintenir à environ 70°C en fonctionnement.

A vu de nez, l’ensemble consomme environ 700Wh, ce qui correspond à un petit chauffage d’appoint électrique. Attention toutefois, celui-ci va fonctionner 24h/24 et 7j/7 : il faut donc qu’il soit utile et permette de gagner quelques degrés par rapport au chauffage collectif de mon immeuble (ce qui est le cas : sans chauffage d’appoint, il fait 18°C dans ma studette l’hiver).

Le choix de la cryptomonnaie et de l’équipe de minage

Après avoir fait pas mal de tests, j’ai choisi de miner de l’Ethereum (ETH) et d’être payé sans frais en Bitcoin (BTC) en participant à l’équipe de minage eth.2miners.com. Il n’est pas nécessaire d’y créer un compte et les frais de participation sont corrects (1%). J’ai choisi d’être payé dès que possible, c’est-à-dire dès que la rémunération de mon système de minage arrive à 0.005 ETH, ce qu’il atteint tous les 4 jours. Cet hiver, cela correspondait environ à 14 euros tous les 4 jours.

J’utilise le logiciel Gminer qui utilise bien les ressources de ma configuration, là aussi à un coût raisonnable dû aux développeurs (1%).

Enfin j’utilise le logiciel Exodus comme portefeuille crypto pour obtenir une adresse BTC et y stocker mes Bitcoins obtenus pour les blocs ETH minés. J’ai fait le choix d’un portefeuille logiciel installé sur ma machine (et mon téléphone) pour éviter d’utiliser celui fourni par les plateforme (Binance, ZenGo…). Cela demande de bien faire attention à ses sauvegardes.

Le transfert en euros

Mon objectif initial n’était pas de faire des plus-values d’investissements, et donc je pensais transférer rapidement mes Bitcoins en Euros. Mais j’ai été relativement désappointé par l’application ZenGo que j’utilisais initialement (car sans obligation de créer un compte). En effet, il s’est passée 3 heures entre la demande de conversion de mes Bitcoins en Euros et sa réalisation effective par ZenGo, ce qui a fait que j’ai perdu 3% du montant attendu (le BTC avait baissé pendant ces 3h). Ça laisse une impression désagréable, loin de l’idée de l’ordre de vente à la corbeille que je vois dans les films.

J’ai donc fini par me créer un compte sur une plateforme d’échange, et j’ai choisi Binance. J’ai mis un peu de temps à trouver les menus des seules actions qui m’intéressent, mais j’ai fini par comprendre (la plateforme est surtout conçue pour ceux qui veulent trader).

Je transfère donc de temps en temps mes Bitcoins avec Exodus vers Binance, puis je choisis sur Binance le moment de la cotation du BTC la plus intéressante pour faire la conversion en euros vers mon compte bancaire. C’est amusant comment on en arrive à regarder les cours du BTC tous les jours en « espérant » que ça monte (bull market ou marché taureau). Autant dire qu’en ce moment, je ne transfère pas grand chose (bear market ou marché ours).

Au passage, j’ai appris qu’en bourse, on appelle un marché à la baisse « bear market » et un marché à la hausse « bull market », à cause de la façon dont ces deux animaux se battent : l’ours attaque avec ses griffes de haut en bas, alors que le taureau utilise ses cornes de bas en haut 🙂

Ma machine de minage est maintenant éteinte jusqu’à l’hiver prochain, sauf bien sur de temps en temps pour un petit cassage de mots de passe avec hashcat… et ça, c’est une autre histoire.

Il existe de nombreux tutoriels consacrés à ce sujet, je ne vais donc faire que survoler le sujet. Mon objectif est surtout de rappeler des règles simples.

Le serveur

Si vous faites de l’autohébergement complet, le serveur est chez vous. Il faut donc sécuriser la machine d’un point de vue physique et logiciel. J’ai fait le choix d’une machine virtuelle dédiée uniquement au fonctionnement du service WordPress. Elle est située sur un NAS Synology permettant de faire fonctionner des machines virtuelles. Ce NAS est en hauteur (pour échapper aux coups de balais ou de serpillières) et branché sur un onduleur électrique pour l’isoler des micro-coupures, des variations de tension et des coupures électriques de moins d’une demi heure.

La machine virtuelle (que j’appellerai « le serveur » dans la suite de ce billet) est une Debian 11 minimaliste (sans interface graphique) avec ssh. Un snapshot à chaud du serveur est pris chaque jour par le virtualiseur du Synology, et un « apt update && apt upgrade -y » (yolo) est lancé automatiquement chaque jour. Les vrais admin utiliseront plutôt un cron-apt ou unattended-upgrades.

Le virtualiseur Synology permet aussi de créer un clone du serveur à partir d’un snapshot et de l’exporter au format OVA. Je fais cela de temps en temps (manuellement) pour disposer d’un fichier qui suivra ensuite toute la procédure de sauvegarde 3-2-1 des autres fichiers du NAS. C’est plus pour reconstruire rapidement un serveur en cas de problème, puisque les contenus WordPress seront sauvegardés de manière spécifique (voir plus loin).

Les services qui tournent sur le serveur sont protégés par un pare-feu local (ufw) qui vient compléter celui du NAS Synology, celui du routeur ER-X de mon réseau et celui de la box fournie par mon FAI (nous vivons dans un monde formidable).

Il y a un seul utilisateur local, en plus de root, et celui-ci est configuré pour accéder au serveur en ssh avec une authentification par clef SSH. Les mots de passe font 32 caractères, comprennent des majuscules, des minuscules, des chiffres et des caractères spéciaux classiques et français. Ils sont générés aléatoirement par KeePass et y sont stockés, ainsi que les clefs SSH et tout ce qui relèvera de la sécurité de ce serveur (les codes 2FA par exemple, voir plus loin). Vous trouverez plus de détails techniques, sur ce lien : https://www.digitalocean.com/community/tutorials/initial-server-setup-with-debian-11

Installation du CMS

Il faut ensuite installer apache2, php8, mariadb et pour finir WordPress. Vous trouverez tous les détails techniques, sur ces liens (kudos à leurs auteurs):
https://cloudinfrastructureservices.co.uk/install-wordpress-on-debian-10-11/
https://www.linuxcapable.com/how-to-install-wordpress-with-lamp-stack-on-debian-11-bullseye/

N’oubliez pas le passage sur la commande « mysql_secure_installation », ni la génération des sels dans wp-config.php grâce au site https://api.wordpress.org/secret-key/1.1/salt/

Certificats SSL

Il faut maintenant mettre en place vos certificats SSL pour accéder à votre nouveau serveur en https. Pour ma part, ayant en tête d’utiliser les différents services de Cloudflare, j’ai suivi ce tuto : https://devanswers.co/configure-cloudflare-origin-ca-apache/

Les fichiers .htaccess

Plutôt qu’un cours sur les fichiers .htaccess, voici le contenu de ceux que j’utilise :

.htaccess à la racine du site WordPress (le répertoire où l’on trouve les répertoire wp-admin, wp-content et wp-includes

#Blocage de la visibilité du fichier wp-config.php
<Files wp-config.php>
order allow,deny
deny from all
</Files>
#Fin du blocage

#Blocage de la visibilité du fichier xmlrpc.php
<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>
#Fin du blocage

#Interdiction de visualisation des repertoires du site :
Options All -Indexes

# Protéger .htaccess et .htpasswds
<Files ~ "^.*\.([Hh][Tt][AaPp])">
order allow,deny
deny from all
satisfy all
</Files>

# Protections diverses (XSS, clickjacking et MIME-Type sniffing)
<ifModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</ifModule>

# Redirection vers HTTPS 
RewriteEngine On
RewriteCond %{SERVER_PORT} ^80$ [OR]
RewriteCond %{HTTPS} =off
RewriteRule ^(.*)$ /$1 [R=301,L]

# Redirection du www vers non-www en HTTPS
RewriteCond %{HTTP_HOST} ^www\.zythom\.fr [NC]
RewriteRule ^(.*)$ /$1 [R=301,L]

.htaccess dans wp-admin (attention, une fois en place, vous ne pourrez accéder à l’interface d’administration WordPress que depuis ces adresses IP) :

order deny,allow
deny from all
# IP de la maison
allow from W1.X1.Y1.Z1
# IP de la ligne de secours
allow from W2.X2.Y2.Z2
# IP locales
allow from 192.168.N1.M1
allow from 192.168.N2.M2

.htaccess dans wp-content :

# Bloque les accès directs aux fichiers PHP (Merci à Sucuri)
<FilesMatch "\.(?i:php)$">
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
  </IfModule>
  <IfModule mod_authz_core.c>
    Require all denied
  </IfModule>
</FilesMatch>

.htaccess dans wp-includes :

# Bloque les accès directs aux fichiers PHP (Merci à Sucuri)
<Files wp-tinymce.php>
allow from all
</Files>
<FilesMatch "\.(?i:php)$">
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
  </IfModule>
  <IfModule mod_authz_core.c>
    Require all denied
  </IfModule>
</FilesMatch>
<Files wp-tinymce.php>
  Allow from all
</Files>
<Files ms-files.php>
  Allow from all
</Files>

Les plugins WordPress

Il existe de nombreux modules d’extension qui font la richesse de l’écosystème WordPress mais également son danger : je vous conseille de minimiser le nombre de plugins et de veiller à leurs mises à jour régulière.

Le premier plugin que je vous recommande permet justement la mise à jour des tous les plugins : il s’agit de Companion Auto Update.

Le plugin suivant vous permet de mettre en place l’authentification multi facteurs sur votre site (indispensable) : Two-Factor.

Un pare-feu dédié à WordPress viendra compléter les différentes barrières déjà mises en place : NinjaFirewall.

J’aime beaucoup le concept de protection communautaire associé au produit Crowdsec que vous pourrez installer en suivant ce billet : https://www.it-connect.fr/comment-proteger-son-site-wordpress-avec-crowdsec/

Enfin, la sauvegarde de vos billets, commentaires, thèmes et plugins pourra se faire simplement avec le plugin UpdraftPlus qui m’a déjà sauvé la vie.

J’ajouterai deux plugins dans ma revue de sécurité car ils aident beaucoup le blogueur à survivre aux spammeurs (j’ai installé les deux qui fonctionnent très bien en parallèle) : Akismet Anti-Spam et Antispam Bee.

Voilà ce que j’ai mis en place. En parler diminue déjà la sécurité, mais comme le partage, lui, augmente la sécurité, n’hésitez pas à me faire part de vos conseils et recommandations en commentaire.

J’ai définitivement quitté mon hébergeur, qui persiste à nier le problème survenu le 2 avril dernier. J’ai pourtant contacté le service support, signalé les heure et date, décrit la nature du problème, exploré les logs qui me sont accessibles, demandé l’escalade dans le suivi de ma demande, pour me permettre de reprendre confiance, rien n’y a fait.

Le plus drôle est que le support s’est plusieurs fois étonné que je signale un problème alors que le blog fonctionne parfaitement. A chaque fois, j’ai du leur expliquer que si ce blog fonctionne de nouveau, c’est qu’il est hébergé ailleurs que sur leur plateforme…

Je ne souhaite pas « défoncer » ici cet hébergeur, car au fond de moi, je sais que ses équipes supports sont de plus en plus surchargées, de moins en moins bien payées, avec à la clef un service de moins en moins efficace. C’est le lot malheureusement de beaucoup d’entreprises de l’IT. Alors pourquoi dénoncer l’incapacité d’un service support à reconquérir la confiance d’un de leur client, quand leur entreprise ne leur donne pas les moyens et les exploite abusivement.

Bref, j’ai saisi cette occasion pour faire joujou avec différentes solutions, et finalement décider de rester chez moi, sur une machine virtuelle hébergée sur mon NAS, derrière Cloudflare et ma fibre optique.

J’en ai profité pour rapatrier l’intégralité des mille articles du blog v1 anciennement hébergé chez Google-Blogger et du coup faire un peu le ménage dans les URL. Si vous trouvez un lien qui pointe dans le vide, n’hésitez pas à me le signaler en commentaire ou par email.

Les publications qui compilent les meilleurs articles du blog sont encore hébergées sur le drive Google du compte zythom chez gmail.com, je m’en occuperai un peu plus tard. Ce n’est pas facile de se dégoogliser complètement et rapidement. A part ça, vous ne devriez plus avoir ici de traqueurs Google, y compris pour les polices de caractères.

Je reste pour l’instant sous WordPress, surtout pour les commentaires et la lecture sur Smartphone, mais je teste plusieurs générateurs de blogs statiques, plus faciles à sécuriser.

J’ai beaucoup de billets en mode brouillon. Je vais sans doute les débloquer et les publier un peu en vrac. Ça va partir dans tous les sens ^^

A+

Voici en partage ma fiche de procédure en cas de crash de mon serveur WordPress et que je viens d’utiliser pour le remettre en service.

Le contexte :
Je loue un serveur WordPress « clef en main » chez un hébergeur. Comme tout serveur WordPress, j’ai un compte administrateur qui me permet de le paramétrer et de choisir des extensions. Parmi les extensions que j’ai choisies, celle qui gère la sauvegarde de mon site s’appelle UpdraftPlus. Elle est paramétrée pour faire une sauvegarde complète (base de données WordPress, extensions, thèmes, etc.) régulièrement. Je transfère manuellement les fichiers de sauvegarde par ftp chez moi pour disposer de sauvegardes externalisées et respecter la règle 3-2-1.

L’incident :
J’ai mis en place une surveillance du fonctionnement de mon blog avec l’excellent « UptimeRobot » dont le service gratuit de monitoring me convient parfaitement. En cas de problème grave, les lecteurs me préviennent aussi (cf Pwned).
J’ai reçu la semaine dernière une alerte d’indisponibilité de mon blog, et après vérification, j’ai pu constater que l’hébergeur affichait une magnifique « Erreur 504 ». J’ai donc ouvert un ticket d’assistance, et appliqué le plan de reprise d’activité (PRA) du blog que je décris ci-après.

Procédure :

• Rester calme
• Configurer un serveur Yunohost hébergé chez moi (sur un Raspberry Pi)
• Configurer le nom de domaine zythom.fr sur ce serveur via l’interface Yunohost
• Rediriger les ports TCP 80 et 443 de ma box vers ce serveur Yunohost
• Modifier l’adresse IP du blog zythom.fr dans le DNS (je suis chez Gandi)
• Mettre en place le certificat SSL Letsencrypt via la procédure proposée par Yunohost
• Rester calme
• Installer l’application Yunohost WordPress
• Installer l’extension WordPress UpdraftPlus
• Transférer sur le serveur les fichiers de la dernière sauvegarde disponible
• Restaurer l’ensemble de la sauvegarde (base de données, extensions, thèmes, etc.)
• Option: mettre le blog derrière Cloudflare (compte gratuit) pour la mise en cache

Retour d’expérience :
La procédure s’est bien déroulée, avec un temps d’interruption assez court (compte tenu de l’audience modeste de ce blog) et essentiellement lié au temps de propagation DNS. Améliorations à faire :
– la sécurité du site repose en partie sur des fichiers .htaccess que je n’avais pas étudiés pour le serveur Yunohost.
– mettre en place une page de maintenance pour masquer toutes les pages temporaires (page par défaut du serveur web avant installation de WordPress, site WordPress par défaut avant restauration…)
Pendant trois jours, j’ai surveillé un peu tout cela, et j’ai publié hier un billet pour tester la charge, et tout s’est bien passé, sauf l’envoi des emails me prévenant des commentaires.

Le mot de la fin :
J’ai installé hier soir une nouvelle machine virtuelle Debian sur mon NAS Synology. J’y ai installé un WordPress classique sur lequel j’ai pu de nouveau basculer le blog. Je peux remettre en place une sécurité que je gère un peu mieux, même si je le rappelle, ce blog se fera pirater car je ne maîtrise pas tout.

Je découvre Cloudflare et c’est un peu déroutant.

Un technicien du support de mon hébergeur m’a contacté 3 jours après l’ouverture du ticket (et après la mise en place du PRA et donc la migration du site ailleurs) pour me dire qu’il ne voyait pas le problème car mon site répondait correctement… Je pense que je vais clore mon abonnement chez eux.

Kudos à tous les développeurs de Yunohost.

Avec tous les tests et les essais qu’il me reste à faire, ça va bagotter un peu ici.

J’ai d’abord envisagé d’écrire un billet complet sur les crypto-monnaies, en partant de la définition des blockchains jusqu’à la description des équipes de mineurs, mais finalement, vous trouverez beaucoup d’informations sur ces sujets dans des billets écrits par des personnes bien plus expertes que moi. Ceux qui voudraient des informations vraiment utiles peuvent aller par exemple parfaire leurs connaissances sur https://www.bortzmeyer.org/search?pattern=blockchain, ou sinon, j’ai trouvé l’ouvrage du CIGREF clair, même si je n’ai pas la prétention d’en juger le contenu (pdf gratuit) Blockchain : passer de la théorie à la pratique dans les grandes entreprises

L’histoire (de ce billet) commence quand je me suis retrouvé avec la « vieille » machine de mon gamer de fils : une belle tour équipée d’une carte graphique Nvidia GTX1080Ti (achetée d’occasion sur LeBonCoin…). Première idée : l’utiliser pour casser du mot de passe. Oui, mais j’ai déjà un PC dédié à cette tâche, acheté sur Backmarket et dans lequel j’ai mis l’ancienne-ancienne carte graphique de mon gamer de fils, une GTX1060…

Mais je n’ai pas besoin de casser du mot de passe tous les jours.

Ajoutez à cela les températures en chute libre, le froid qui se glisse dans le petit appartement que j’occupe depuis que je travaille 3 jours par semaine en région parisienne, et le besoin d’acheter un radiateur d’appoint à ce chauffage collectif qui a sans aucun doute été réglé sur le mode économe.

J’ai eu l’idée saugrenue de miner des crypto-monnaies.

Ma conscience écologique a été mise à rude épreuve, surtout en lisant ce que consomment certains algorithmes de consensus (cf Consommation énergétique des technologies blockchain), mais mon mauvais génie de la curiosité m’a convaincu d’essayer « un peu, pour voir et pour comprendre »…

Alors c’est parti dans tous les sens, entre lecture d’articles, navigation sur des sites plus ou moins sérieux, et surtout je me suis immergé dans un monde nouveau, avec ses codes, son jargon, ses concepts, ses arnaques, ses mafias, ses escrocs, ses taxes et ses pigeons.

J’ai essayé de ne pas être dans cette dernière catégorie, j’ai essayé de faire attention où je mettais mes pieds, et ce n’est pas facile.

ATTENTION / DISCLAIMER : investir de l’argent dans les crypto-monnaies est dangereux, vous pouvez perdre entièrement votre mise, vos cheveux et devenir stérile. NE VOUS LANCEZ PAS DANS CETTE ACTIVITÉ, sauf si vous disposez déjà de matériel ET si vous acceptez de couper votre chauffage électrique ET si vous avez fait une croix sur vos cheveux ET atteint votre quota d’enfants. Ce billet n’est sponsorisé par personne.

Voici donc ce que j’ai fait, et ce n’est valable sans doute qu’au moment de l’écriture de ce billet.

Le transfert vers mon compte en banque

Curieusement, j’ai commencé par ce problème, car je souhaitais protéger mes données personnelles sensibles tels que ma carte d’identité ou mon passeport. Quand on ne sait pas trop où l’on met les pieds, mieux vaut être un peu prudent.

Après quelques lectures sur différents sites, j’ai choisi l’application ZenGo sur Smartphone car elle permet d’ouvrir un compte sans devoir fournir des pièces d’identité, dès lors que les transactions restent limitées, ce qui sera mon cas. Une reconnaissance faciale sert de sésame en cas de perte du Smartphone, pour une réinstallation depuis iCloud (iPhone) ou autre prestataire de stockage. Moui.

Au niveau des commissions, ZenGo à l’air de se situer au milieu de la fourchette du marché, mais j’avoue que c’est un peu le cadet de mes soucis pour mon étude. ZenGo supporte plusieurs crypto-monnaies (voir ici la liste) et en particulier celles qui m’intéressent, j’ai nommé Ethereum et Bitcoin.

ZenGo embarque un portefeuille (Wallet) qui me permet de disposer d’une adresse sur la blockchain Ethereum (pour y stocker mes ETH) et d’une adresse sur la blockchain Bitcoin (pour mes BTC).

Attention, ZenGo ne sait transférer que des Bitcoins vers un compte bancaire en euros.

Choix de la crypto-monnaie à miner

Je suis tombé sur ce site https://2cryptocalc.com/what-to-mine-with-1080ti qui recommande de miner des Ethers quand on dispose d’une carte graphique GTX1080ti… Et comme je débute dans cet univers, j’ai suivi le conseil. Les gains espérés sont de 2€ par jour auxquels il faudra retirer les coûts divers dont en particulier les coûts électrique, puis les frais de transaction Ethereum (également appelés “frais de gaz“) qui sont très élevés en ce moment.

Pour éviter ces frais, j’ai trouvé une équipe de mineurs qui me permet de miner des Ethers et d’être récompensé (payé) en Bitcoins : l’équipe 2miners.com. Du coup, j’évite les frais élevés d’enregistrement de mes gains dans la blockchain Ethereum, tout en disposant directement dans ZenGo de Bitcoins que je peux transférer en euros sur mon vrai compte bancaire.

Je ne sais pas si c’est une bonne idée, mais ça m’a permis de commencer sans trop de risques, et sans investir autre chose que du temps de calcul d’une carte graphique de récupération (et des coûts électriques à faire saigner un peu mon cœur DD&RS…).

Commencer enfin à miner

J’ai suivi l’aide en ligne du site de l’équipe de minage : https://eth.2miners.com/help qui recommande (pour une carte Nvidia) soit le logiciel T-Rex, soit Gminer. Pouf pouf, j’ai choisi T-Rex… ce qui donne la commande suivante :

sudo ./t-rex -a ethash -o stratum+tcp://eth.2miners.com:2020 -u <mon adresse BTC ZenGo> -w rigZythom -p x

Six jours après, je recevais 15 euros en BTC. Au bout de trois semaines environ, je devrais dépasser la somme minimale de 37 euros sur mon portefeuille ZenGo me permettant un transfert vers mon compte en banque en euros. En vrai, je n’ai pas encore atteint cette somme, car je fais beaucoup d’essais de transferts entre divers crypto-monnaies et d’expériences en testant des portefeuilles logiciels (Jaxx, Exodus, Zelcore, Metamask), des réseaux secondaires (Polygon), et d’autres crypto-monnaies (FLUX, Monero, MATIC…).

J’ai le radiateur électrique le plus cher du monde, mais je me console en me disant qu’il est constitué de matériels de récupération et consomme moins que mon radiateur électrique « normal ». Ne me jugez pas trop.

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…

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.