Contourner le filtrage web en entreprise

Je suis fatigué et irrité par les politiques de filtrage web des grandes entreprises qui, pour des raisons de sécurité ou par manque de confiance envers leurs employés, appliquent un filtrage bien trop agressif sur leur trafic web de sortie.

J’avais rencontré ce problème sur mon premier poste en sortant d’école. Tous les employés étaient d’ailleurs pris pour des étudiants, puisque l’entreprise utilisait des listes de filtrages en usage dans les universités françaises. Impossible donc de consulter la carte de l’enseigne de restauration du coin (Jamais compris le gain de sécurité). Plus embêtant était le blocage pur et simple de gist, ou d’outils similaires – ce qui est quand même fort dommage quand, au détour d’une discussion web sur un problème technique, tout le monde pointe vers une solution à laquelle vous n’avez pas accès.

Comme d’habitude dans ces cas-là, certains employés ont trouvé une solution pour simplement pouvoir faire leur travail sans qu’on leur mette constamment des bâtons dans les roues. A l’époque, l’intégralité de mon équipe avait configuré son poste de travail pour que le trafic passe par le même proxy que celui utilisé par les machines qui hébergeaient nos environnements de développement et de test. Proxy qui était pas ou peu filtré.

Je pensais naïvement qu’en presque 10 ans, les choses s’étaient améliorées, et pourtant, je suis à nouveau confronté aux mêmes problèmes idiots. Un exemple parmi d’autres: récemment, le système de surveillance du trafic réseau du client chez lequel j’interviens a décidé de bloquer le site web de npm, à savoir https://www.npmjs.com. Plus d’accès à la documentation (sauf à trouver le dépôt des sources). Terminé la récupération des dépendances en local… Le blocage fut heureusement de courte durée, mais bon, c’est rapidement une journée de travail perdue pour les personnes concernées. 

Autre exemple, impossible de faire des recherches sur les technologies WebGL, et tout ce qui tourne autour des modèles 3D dans le navigateur. Pourquoi donc, me direz-vous ? Où est le danger ? Ce coup là, le blocage est effectué car ces sujets sont assimilés au domaine du jeu vidéo et donc bloqués de peur que les employées passent leur journée à jouer. Bravo, vous venez par la même occasion de vous assurer que l’entreprise n’innovera pas dans ce domaine, ou avec difficulté.

En fait, le problème est en général tellement courant, qu’on finit par apprendre que pour pouvoir travailler, une équipe entière s’est fait installer une connexion internet domestique pour son propre usage.

Revenons à nos moutons, filtrage excessif du trafic web: ras-le-bol. Pas de droits d’admin sur ma machine, et installations limitées au catalogue de logiciels autorisés… Je dispose par contre d’une machine virtuelle chez l’un des grands fournisseurs mondiaux de cloud (il faut bien trouver une manière de travailler quand tout est bloqué). La solution: utiliser cette machine comme nœud de sortie pour mon trafic web.

Pour ce faire, je dispose bien entendu d’une entrée dans mon fichier .ssh/config, de la forme:

Host proxy
  HostName <ip_machine_distante>
  User <username>
  IdentityFile <chemin_vers_le_fichier_pem>

A partir de là, je vais donc lancer un proxy SOCKS via ssh avec la commande: ssh proxy -N -D 9090.
-N précise qu’aucune commande ne sera exécutée sur l’hôte distant et -D pour utiliser, ici le port 9090, comme port sur la machine local exposant le proxy SOCKS.

Deuxième étape: télécharger Firefox en version portable pour disposer d’un navigateur sur lequel j’ai la main sur la configuration des paramètres de proxy: https://portableapps.com/apps/internet/firefox_portable .

Enfin, configurer notre Firefox en version portable pour utiliser notre proxy SOCKS. Dans la partie préférence, rechercher le terme proxy. Choisir ensuite “Manual proxy configuration”, et renseigner “127.0.0.1” dans “SOCKS Host” et “9090” dans “Port”. Conserver la case “SOCKS v5” cochée et valider.

Enfin, vérifier que l’url précédemment bloquée est accessible.

Dernière étape, aller chercher un café et le siroter en parcourant un web non filtré. Hourra !

Pour essayer de simplifier le lancement du proxy, j’ai créé 2 scripts: proxy.bat et start_proxy.sh. proxy.bat me sert de point d’entrée pour lancer le script principal start_proxy.sh via git bash, simplement en cliquant sur le fichier dans l’explorateur Windows.

"C:\Program Files\Git\bin\bash.exe" --login -i -c "C:/Users/<username>/APPS/start_proxy.sh"
# pause

Le script start_proxy.sh est quant à lui une copie inspirée d’un script partagé au détour d’un gist.

#! /bin/bash
# Inspired by: https://gist.github.com/scy/6781836?permalink_comment_id=2777535#gistcomment-2777535

set -eu
SOCKS_PROXY_PORT=9090
HOST=proxy

socket=$(mktemp -t deploy-ssh-socket.XXXXXX)
rm ${socket} # delete socket file so path can be used by ssh

exit_code=0

cleanup () {
    # Stop SSH port forwarding process, this function may be
    # called twice, so only terminate port forwarding if the
    # socket still exists
    if [ -S ${socket} ]; then
        echo
        echo "Sending exit signal to SSH process"
        ssh -S ${socket} -O exit ${HOST}
    fi
    exit $exit_code
}

trap cleanup EXIT ERR INT TERM

echo "Starting SOCKS proxy on port ${SOCKS_PROXY_PORT}"
# https://mpharrigan.com/2016/05/17/background-ssh.html
# Start SSH port forwarding process
ssh -M -S ${socket} -fNT -o ExitOnForwardFailure=yes -D ${SOCKS_PROXY_PORT} ${HOST}

# -f : Run in the background before command execution.
# -N : Do not execute a remote command; this is useful for just forwarding ports.
# -T : Disable pseudo-tty allocation.
# -S <socketname>: Use a control socket.
# -M : Put control socket in master mode.
# ExitOnForwardFailure : if set to "yes", the connection shall be terminated 
#   if ssh cannot set up all requested dynamic, tunnel, local, and remote port forwardings,
#   (e.g. if either end is unable to bind and listen on a specified port).
# -D <port>: Port on which to expose on the local machine.

ssh -S ${socket} -O check ${HOST}
# -O check,exit : Control command

# launching a shell here causes the script to not exit and allows you
#   to keep the forwarding running for as long as you want.
#   I also like to customise the prompt to indicate that this isn't a normal shell.

bash --rcfile <(echo 'PS1="\nwith-ports> "')

Le tout fonctionne plutôt, avec parfois une perte de connexion en revenant de la pause déjeuner, après une interruption trop longue de la connexion internet, ou une période d’inactivité. Dans cette situation, je ferme simplement la fenêtre “cmd” où tournait le script, et je relance le tout par un double clic sur mon premier fichier.

Simple, efficace et surtout fonctionnel.

Déploiement d’un routeur R7000 supplémentaire sous FreshTomato

Ca y est, le domicile parentale est enfin équipé en fibre optique, en remplacement d’une connexion Adsl vieillissante. Si la qualité et la stabilité du signal s’est donc grandement améliorée, l’organisation physique du réseau a quelque peu changée. La box fibre du fournisseur d’accès se retrouve à la cave, avec l’impact que vous devinez sur la couverture du signal WiFi.

Pour palier au problème, et plutôt que de souscrire à une option de répétiteur WiFi facturée mensuellement, je me suis procuré un routeur R7000 d’occasion. Comme d’habitude, plutôt que de rester sur le firmware Netgear, j’ai immédiatement procédé à l’installation de FreshTomato, pour disposer d’un système bien plus à jour et de nombreuses fonctionnalités supplémentaires, en particulier: des règles de filtrage DNS directement au niveau du routeur.

Sans rentrer dans les détails, la procédure d’installation tient en quelques étapes:

Principales difficultés dans l’opération: ne pas oublier qu’il faut commencer par installer l’image initial et ensuite, trouver ou retrouver les couples utilisateur/mot de passe à utiliser pour chaque image. Ce qui nous donne:

  • initial: admin/@newdig ou root/admin
  • AIO: root/admin

Et pour de plus amples détails, direction la documentation en anglais: Installing FreshTomato.

Gandi c’est fini

Et dire que c’était l’hébergeur de ma première adresse email associée à mon nom de domaine.

Et oui, j’en ai désormais terminé avec Gandi depuis presque un mois maintenant. Propriétaire depuis plusieurs années d’un nom de domaine géré chez Gandi, j’avais fait le choix de cet hébergeur pour sa réputation, les bons retours que j’avais pu lire à plusieurs reprises en ligne, et surtout, pour les quelques adresses mails incluses dans leur offre nom de domaine.

L’histoire commence à la mi-2023, après réception et lecture d’un mail de Gandi informant ses clients des changements à venir et des évolutions de leurs tarifs. Trahison ! L’offre mail associée à un nom de domaine va être arrêtée et les clients forcés à souscrire à une offre mail facturée à l’adresse mail. Augmentation des coûts x8 dans mon cas, puisque deux adresses sont activement utilisées. Je me félicite de n’avoir finalement pas incité mes proches à migrer leur adresse email sur mon domaine.

A l’époque, de mémoire, il était possible de créer jusqu’à 5 adresses mails associées à un nom de domaine. Mon frère et moi-même avons donc pu troquer nos adresses gérées par le FAI du moment pour passer sur des adresses plus pérennes (du moins en théorie), et affichant notre nom de domaine: unicoda.fr. Ce qui faisait pour moi l’intérêt de cette offre en particulier, était la possibilité de définir des alias en mode regex *, permettant ainsi d’avoir facilement une adresse dynamique par contexte, par site ou par provenance. Avec par exemple l’alias suivant : moi-*@mondomaine.fr, je pouvais au besoin donner l’adresse moi-vendeur1@mondomaine.fr pour les communications en provenance de vendeur1 et moi-association-xy@mondomaine.fr pour les communications en provenance de association-xy. Et cela en toute simplicité.

Cette organisation a l’intérêt de ne pas exposer son adresse mail principale à des acteurs commerciaux parfois peu scrupuleux et dont les fichiers clients peuvent être réutilisés, malgré l’opposition explicite à l’envoi de mails commerciaux, mais aussi d’identifier immédiatement la source d’une fuite de données, en cas de faille de sécurité chez le contact x ou y. Heureusement chose exceptionnelle, il m’est arrivé de recevoir des spams sur l’une de mes adresses spécifiques, m’indiquant ainsi que l’adresse confiée au contact et à son système informatique avait fini par fuiter. Si les protections anti-spam ne font pas effet, il est alors possible de mettre l’adresse en liste noire, pour bloquer définitivement les mails entrants sur cette adresse et conserver ainsi une adresse saine. Mon erreur ici, a peut-être été de ne pas choisir d’utiliser le caractère `+` pour définir mon alias, car ce type d’alias est plus standard et donc souvent supporté chez les autres fournisseurs de mail.

Revenons à nos moutons. Alors que je commençais à envisager de faire migrer d’autres membres de la famille en utilisant les adresses restantes, Gandi annonça une baisse du nombre de mail associés à un domaine et limita leur nombre à 3 adresses. Statu quo. Nous restons donc à deux utilisateurs des adresses mails fournies. Avance rapide au 14 juin 2023 et à l’annonce de la fin des adresses mails fournies avec un nom de domaine au 30 novembre de la même année. Une solution simple consisterait à migrer les 2 comptes mails que nous utilisons vers l’offre de mail de Gandi, mais celle-ci, avec l’augmentation des tarifs, va passer de 0,42e/mois à 4,2e/mois. Rien de moi qu’un x10. Pour l’utilisation que nous faisons de nos comptes personnels, l’addition est salée.

Ayant bien d’autres choses à traiter, nous avons donc cherché à limiter les dégâts. Sur les deux adresses liées à mon domaine, je n’ai conservé que la mienne, l’autre ayant été décommissionnée, et j’ai donc commencé à me voir facturer le coût mensuel d’une adresse. Une migration durant cette période me semblait hasardeuse, car risquait de me faire perdre des emails, en réception, ou en envoi, du moins le temps de résoudre les éventuels problèmes de configuration.

Les mois passant, la routine s’installe. Le service fonctionne toujours correctement et je n’ai pas l’envie ni le temps de me concentrer sur la migration de mon adresse mail, bien qu’une courte interruption de service soit maintenant acceptable.

Jusqu’à début septembre 2024, qui voit arriver le renouvellement du nom de domaine auquel sont liées les adresses. Alors que je démarre la procédure, le prix du renouvellement d’un .fr pour un an s’affiche: 30 euros et des brouettes. J’avais bien vu passer un document listant les augmentations de tarifs, mais celle-ci m’avait échappé… Une nouvelle fois, on sent que la politique tarifaire a changé après le rachat par un groupe d’investissement en 2019 : il faut que le fric rentre ! (Lire à ce sujet « Gandi, passe de « no bullshit » à « bait and switch » ? » chez linuxfr) A une semaine de la date d’expiration, j’hésite quelques instants. Rester encore un an et consentir à me faire racketter, le temps de trouver une autre solution, ou entamer une migration d’urgence.

Ce sera une migration d’urgence vers OVH, où les tarifs sont bien plus raisonnables et que j’utilise déjà pour unicoda.com: nom de domaine et serveur, sans avoir eu à m’en plaindre jusqu’à présent – excepté peut-être lorsqu’unicoda a littéralement migré dans le cloud avec l’incendie du datacenter de Strasbourg (Mais j’avais trouvé l’expérience plutôt enrichissante. Voir: Unicoda a brûlé !). Problème, les offres mail ne proposent pas de configuration d’alias * comme celle décrite plus haut. L’adresse mail comprise dans l’offre nom de domaine propose la création de 1000 alias, et l’offre pro, l’utilisation du + pour la création dynamique d’adresses. Il va falloir migrer toutes mes adresses existantes, vers un format +, en remplacement du caractère que j’utilisais jusqu’à présent.

J’ouvre une ligne de commande, et lance une analyse sur le contenu de mon password store: pass grep -E ‘monPrefix-.*@unicoda.fr’ > compte_a_migrer.txt. J’ouvre le fichier et me retrouve nez-à-nez avec 300 lignes de données, chaque compte occupant deux lignes, soit pas loin de 150 comptes à mettre à jour. Commence alors la tâche répétitive et gargantuesque de modification du mail: connexion au compte, changement du mail, validation de la nouvelle adresse, suppression de l’ancienne, mise à jour de l’entrée dans le gestionnaire de mot de passe, et on recommence.

Après trois soirées de désœuvrement intellectuel, ça y est, la majorité des adresses est migrée, et les adresses restantes ont fait l’objet d’une création d’alias manuelle. J’enclenche donc la procédure de transfert du nom de domaine, à 72h de son expiration, scotché à mon écran comme un papillon de nuit à sa lumière, inquiet de voir le processus automatisé se gripper. Tel ne fut heureusement pas le cas. La migration s’est déroulée sans accroc en ce qui m’a semblé moins de 3h et, après quelques heures de sommeil bien méritées, la partie mail a suivi, avec test d’envoi et de réception dans la foulée.

Rétrospectivement, j’aurais pu m’éviter énormément de travail en choisissant de ne migrer que les comptes importants et considérer de nombreux comptes de boutiques ou de services en ligne comme des comptes historiques. Ne pas les migrer signifiait une possibilité de perte d’accès en cas de reset forcé du mot de passe, le mail de contact n’existant plus mais, dans une telle situation, il aurait été seulement nécessaire de créer l’alias manquant pour débloquer la situation. Une autre solution, qui ne m’est venu malheureusement que bien après, aurait été d’utiliser les APIs OVH pour scripter la création des alias (POST /email/mxplan/{service}/account/{email}/alias et POST /email/pro/{service}/account/{email}/alias). Si l’idée d’automatiser ce processus rébarbatif de mise à jour des adresses mail m’a bien traversé l’esprit, l’urgence de la situation et le peu de temps restant pour migrer le domaine, via une procédure qui m’était jusqu’alors inconnue, m’ont empêchés de prendre le recul nécessaire pour envisager cette solution.

Finalement, le transfert d’un nom de domaine, opération que j’appréhendais quelque peu, est d’une simplicité enfantine et ce changement d’hébergeur me permet de limiter l’augmentation du coût des services que j’utilise et de simplifier un peu le suivi, la gestion et la facturation en les regroupant. La découverte des APIs OVH quant à elle, me donne quelques idées à explorer, un jour peut-être et vient me rappeler que, dans une situation d’urgence, il faut parfois savoir ralentir pour prendre un peu de recul. Et, qui sait, s’accorder d’explorer un autre chemin qui, s’il s’avère praticable, permettra de simplifier les choses et de gagner du temps.

Oh Gandi, c’est fini. Je ne crois pas que j’y retournerai un jour.

[Ansible] Liste des valeurs disponibles pour ansible_os_family

Petit pense-bête, pour éviter de perdre plusieurs dizaines de minutes à retrouver la liste des valeurs possibles pour la variable ansible_os_family dans ansible, après plusieurs semaines ou mois sans pratiquer.

La liste est par là:
ansible/ansible/module_utils/facts/system/distribution.py#L511

cmd#11 – GitHub – Clone de dépôt via HTTPS et token

De temps en temps, j’ai besoin de cloner l’un de mes dépôts GitHub, vers un poste de travail sur lequel je ne souhaite pas ou ne peut pas utiliser ma clef SSH pour réaliser l’opération. Dans ces cas là, je passe par la génération d’un token via Settings > Developer settings > Personal access tokens > Fined-grained tokens, auquel je ne n’assigne que l’autorisation « Content » avec « Read and Write », sur le dépôt concerné.

Avec une validité maximum d’un an, la sélection des dépôts concernés et une sélection minimale des permissions, je réduit ainsi grandement la surface d’exposition de mes dépôts. Une fois en possession du token généré, vient ensuite le moment de cloner le dépôt via git. Pour mémoire, voici la syntaxe à utiliser, par exemple, pour cloner mon dépôt yt-auto-dark:

git clone https://oauth2:<token>@github.com/vvision/yt-auto-dark.git

Voilà pour l’aide-mémoire.

Seul bémol de la solution, n’importe qui ayant accès au dépôt cloné pourra effectuer des modifications pendant toute la durée de validité du token, ou jusqu’à ce que ce dernier soit révoqué. A ne pas utiliser n’importe comment, n’importe où donc. En sacrifiant un peu de simplicité (et encore) et en fonction de l’environnement, on pourra préférer la génération d’une clef SSH spécifique à la machine, auquel on veillera bien à associer une pass phrase de qualité. On aura alors accès à tous nos dépôts, mais il faudra penser nous-même à retirer la clef des clefs autorisées lors de la décommission de la machine utilisée.

Bref, plusieurs solutions possibles en fonction des besoins et des environnements, à choisir en connaissance de cause.