SPA112 et ligne VoIP OVH

En début d’année 2018, je m’attelais à l’amélioration de mon réseau LAN, en cherchant à en maîtriser le plus de composants possibles. À l’époque, j’étais chez OVH pour ma connexion au réseau internet, et je disposais à ce titre, d’une ligne téléphonique. Afin de pouvoir me passer du modem OVH, j’avais donc commandé un petit boîtier Cisco SPA112, afin de pouvoir brancher mon téléphone et d’être en mesure de passer et de recevoir des appels. Voici quelques notes prises au moment de la mise en place et que je publie ici pour référence.

Sur le SPA112, le couple login/mot de passe par défaut est admin/admin. Avant même de m’attaquer à la configuration de la ligne, j’avais commencé par mettre à jour le firmware. Celui-ci est à récupérer directement sur le site de Cisco, je note d’ailleurs qu’une nouvelle version du firmware a été publié en avril de cette année. Dans mes souvenirs, le processus de mise à jour ne présente aucune difficulté, dans l’onglet dédié, il suffit de sélectionner le zip sur son disque, puis de valider pour démarrer la mise à jour. Évidemment, dans l’idéal, on prendra quelques minutes pour vérifier la somme de contrôle du fichier récupéré.

Pour ce qui est de la configuration de la ligne, je me suis inspiré de la page Cisco SPA112 du wiki VoIP.ms qui fournit une documentation très complète sur le boîtier. Toujours en fouillant dans ma mémoire, je crois me souvenir d’avoir effectué la configuration via la page « Quick Setup », et n’avoir eu qu’à remplir les champs proxy, display name, user id et password avec les informations de ma ligne OVH. Il ne me semble pas avoir eu besoin de mettre en place une configuration particulière pour le dial plan. Voici donc un extrait de ma configuration:

  • Proxy: sip3.ovh.fr
  • Display Name: 0033900000000
  • User ID: 0033900000000
  • Password: <mot de passe>
  • Dial Plan: (*xx|[3469]11|0|00|[2-9]xxxxxx|1xxx[2-9]xxxxxxS0|xxxxxxxxxxxx.)

A ce stade, les propriétaires d’un accès internet OVH s’étonneront peut-être du fait que je disposais des informations de connexions à la ligne téléphonique incluse dans mon abonnement. En effet, il faut savoir qu’OVH ne fournit pas ces informations dans le cadre de l’offre d’abonnement internet. Le seul moyen d’avoir ces informations via OVH, consiste à demander l’envoi contre caution d’un SPA112 déjà configuré, ou de s’abonner spécifiquement à une offre de ligne téléphonique sur IP.

Une autre solution, celle que j’ai choisi, consiste à ruser pour obtenir le mot de passe de la ligne. D’après ce que j’avais pu lire sur les forums OVH, il faut savoir que cette manière de faire vient avec quelques limitations d’usage comparée à une véritable solution VoIP. En effet, OVH vérifie que cette ligne n’est utilisée qu’à partir de votre réseau domestique. Il n’est à priori pas possible d’utiliser sa ligne depuis une application Android en étant connecté au réseau 4G. Les utilisateurs ayant tentés l’opération, ont vu les informations de connexion de leur ligne VoIP être réinitialisées, les obligeant ainsi à refaire la procédure de récupération des identifiants de connexion. En revanche, il est tout à fait possible d’utiliser la ligne depuis une application Android, avec son téléphone connecté à son réseau local. Du point de vue d’OVH, l’appel est passé depuis l’IP associée à la connexion internet et cela ne pose donc aucun problème. Si vous disposez donc d’un VPN vous permettant de vous connecter à votre réseau local, il devient alors possible d’utiliser la ligne téléphonique depuis l’extérieur, comme par exemple, depuis un pays étranger dans lequel vous n’auriez pas de réseau, mais simplement un accès à internet non restreint.

Passons maintenant à l’exposition succincte et non détaillée du processus de récupération des identifiants de connexion. À partir d’un modem OVH configuré et disposant de la ligne téléphonique activée et fonctionnelle, on commence par configurer un service dyndns pointant vers un nom de domaine en notre possession et sur lequel on fait tourner un petit bout de code ayant pour seul rôle de logger les informations provenant des requêtes entrantes. Une fois le service configuré, on sauvegarde la configuration du modem dans un fichier via la page prévue dans l’interface. Dans le fichier de configuration, on cherche la ligne correspondant aux identifiants de la ligne VoIP et on récupère le hash du mot de passe associé. On remplace ensuite le hash du mot de passe associé à la configuration de notre service dyndns par le hash du mot de passe de la ligne VoIP récupéré à l’étape précédente. Une fois le fichier modifié de cette manière, on procède à la restauration de la configuration du modem à partir du fichier que l’on vient de modifier. Une fois la nouvelle configuration en place, le modem va faire un appel vers notre service dydns pour l’informer de la configuration IP actuelle et utilisera dans la requête les informations d’authentification, à savoir, le mot de passe de la ligne VoIP. Il ne reste plus qu’à aller consulter les logs du service dyndns que nous avons mis en place pour y découvrir le mot de passe VoIP en clair. Une fois en possession de cette information, on peut alors configurer une application Android ou un SPA112 pour se connecter à la ligne téléphonique.

Sur ce point, je trouve dommage qu’OVH ne fournisse pas directement les informations de connexion, même en précisant par exemple, que la ligne téléphonique n’est utilisable que depuis l’adresse IP associée à la connexion internet fournie. Au passage, je remercie toutes les personnes qui ont échangé autour du processus à suivre et dont les discussions, posts après posts m’ont permis de reconstituer une solution fonctionnelle, et de profiter de la ligne téléphonique au sein de mon LAN comme je l’entendais.

[Vidéo] I don’t have to tell you things are bad – Network (1976)

Lien vers l’extrait vidéo.

I don’t have to tell you things are bad.
Everybody knows things are bad.
It’s a depression.

Everybody’s out of work or scared of losing their job.
The dollar buys a nickel’s worth, banks are going bust, shopkeepers keep a gun under the counter. Punks are running wild in the street and there’s nobody anywhere who seems to know what to do, and there’s no end to it.

We know the air is unfit to breathe and our food is unfit to eat, and we sit watching our TV’s while some local newscaster tells us that today we had fifteen homicides and sixty-three violent crimes, as if that’s the way it’s supposed to be. We know things are bad – worse than bad. They’re crazy. It’s like everything everywhere is going crazy, so we don’t go out anymore. We sit in the house, and slowly the world we are living in is getting smaller, and all we say is, ‘Please, at least leave us alone in our living rooms. Let me have my toaster and my TV and my steel-belted radials and I won’t say anything. Just leave us alone.’ Well, I’m not gonna leave you alone.

I want you to get mad!

I don’t want you to protest. I don’t want you to riot – I don’t want you to write to your congressman because I wouldn’t know what to tell you to write. I don’t know what to do about the depression and the inflation and the Russians and the crime in the street. All I know is that first you’ve got to get mad. You’ve got to say, ‘I’m a human being, God damn it! My life has value!’

So I want you to get up now.
I want all of you to get up out of your chairs.
I want you to get up right now and go to the window. Open it, and stick your head out, and yell, ‘I’m as mad as hell, and I’m not going to take this anymore!’

I want you to get up right now, sit up, go to your windows, open them and stick your head out and yell – ‘I’m as mad as hell and I’m not going to take this anymore!’ Things have got to change. But first, you’ve gotta get mad!… You’ve got to say, ‘I’m as mad as hell, and I’m not going to take this anymore!’ Then we’ll figure out what to do about the depression and the inflation and the oil crisis. But first get up out of your chairs, open the window, stick your head out, and yell, and say it: « I’m as mad as hell, and I’m not going to take this anymore! »

Network (1976)

Réinitialisation du jeton cryptographique Gnuk

Après avoir réalisé quelques tests du jeton cryptographique fraîchement créé à partir d’un ST-Linkv2 et de Gnuk, j’ai cherché à nettoyer les clefs stockées sur ce jeton de test. Mes recherches m’ont guidé vers le dossier tool du dépôt gnuk, qui contient plusieurs scripts permettant de réaliser divers opérations sur le jeton. L’instruction factory-reset ne fonctionnant pas sur les jetons Gnuk, je me suis tourné vers le script gnuk_remove_keys_libusb.py. Script qui nécessite d’arrêter gpg-connect-agent avant d’être exécuté. Je n’ai au final pas pu valider son fonctionnement, pour la raison que vous découvrirez au paragraphe suivant.

gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye
./tool/gnuk_remove_keys_libusb.py -p

Lors de mes premières tentatives, je n’avais pas utilisé le paramètre p de la commande et celle-ci utilisait donc le PIN par défaut à savoir 12345678 pour le PIN admin. Ayant changé ce dernier, j’ai très vite atteint la limite d’essai autorisé et ai rendu mon jeton inopérant. Il a donc fallu s’intéresser à la façon de réinstaller Gnuk sur un jeton bloqué.

Pour effectuer la reprogrammation, il faut connecter le jeton à notre ST-Link comme dans l’article précédent. Afin de déverrouiller le jeton, il est également nécessaire de connecter les pins 7 (NRST) et 8 (VSSA) du micro-contrôleur STM8F103. Une fois les deux pins connectés, avec la pointe de mesure d’un multimètre par exemple, il faut lancer openocd comme précédemment. Une fois le programme en cours de fonctionnement, sans erreur ni tentative permanente de reconnexion, on peut arrêter de maintenir la connexion entre les deux pins.

Pour repérer les deux pins concernés, voir le schéma ci-dessous.

Pins d’un STM32F103C8T6

L’opération n’étant pas des plus évidentes, j’ai dû effectuer plusieurs tentatives avant de pouvoir reprendre la main pour reprogrammer le micro-contrôleur. Par ailleurs, impossible de me reconnecter correctement aux pins du ST-Link, j’ai donc été obligé de sortir le fer à souder, d’autant plus que le STM32 est positionné de l’autre côté de la carte et donc impossible d’y accéder pour connecter les deux pins en utilisant le précédent système de connexion.

Le montage après reprogrammation et juste avant de retirer les fils soudés.

Pas de changement dans les instructions de programmation à part l’ajout du mass_erase pour supprimer tout le contenu de la mémoire.

halt
stm32f1x unlock 0
reset halt
stm32f1x mass_erase 0
flash write_bank 0 ./src/build/gnuk-vidpid.bin 0
stm32f1x lock 0
reset halt

Après reprogrammation, le jeton est à nouveau vierge de toutes informations et prêt à recevoir de nouvelles clés!

De l’idée à la réalisation d’un jeu de société

Que vous soyez parents ou enfants, jeune ou vieux si vous avez la fibre créatrice cette article est fait pour vous.

Il y a quelques jours j’ai fini le montage d’une vidéo. J’ai réalisé cette vidéo dans le but de partager ma passion pour la création. Je me suis fixé comme objectif de réaliser un jeu de société papier en utilisant le logiciel de dessin vectoriel Inkscape. Je ne sais pas si l’on peut appeler cette vidéo un tutoriel puisque je ne détail pas toutes les actions à réaliser. Je vous laisse juger par vous même.

La capture et l’édition de la vidéo m’a pris environ 5 heures. J’estime que le jeu que je présente dans la vidéo peut être réalisé en 2 ou 3 heures par un débutant. Ça peut être un bon moyen de passer du temps avec des enfants et faire une activité enrichissante tant pour eux que pour vous.

Créer son propre jeu de société, même si il est créé par ordinateur vous permettra

  • de découvrir le dessin vectoriel
  • d’avoir une activité artistique
  • de développer l’imagination
  • d’apprendre les réglages d’impression
  • de travailler manuellement la découpe et l’assemblage des pièces.

Je vous offre aussi la possibilité de passer directement à la découpe des pièces puis au jeu en vous donnant gratuitement et librement les images du jeu ou encore le fichier vectoriel pour ceux qui aimeraient le modifier

N’hésitez pas à vous abonner à la chaine Youtube et à y laisser un commentaire ou un pouce voir même une photo de votre propre jeu.

Utilisation du jeton cryptographique Gnuk de secours

Dans un précédent article, j’avais décrit la manière de reprogrammer un STLinkv2 pour en faire un jeton cryptographique Gnuk. J’aurais pu m’arrêter là dans mes tests, mais alors, je n’aurais pas eu la garantie que ma solution de secours est valable. J’ai donc vérifié ma procédure, pas à pas, en reprenant si besoin les différents articles faisant offices de documentation. Voici quelques éléments à considérer.

Pour mener à bien la création d’un nouveau jeton cryptographique contenant les mêmes clés que mon jeton source, je commence par réinitialiser l’environnement sur le poste sécurisé ayant servi à la création des clés, après avoir pris soin de déchiffrer le dossier de sauvegarde contenant un exemplaire des clés :

export GNUPGHOME=/path/to/working/directory
cp dir-backup-mastersubkeys/* $GNUPGHOME/*

Pour la suite, l’export des clés sur le jeton s’effectue comme décrit dans les parties « Configuration de la cible » et « Export des sous-clefs vers la Yubikey » de mon article intitulé « GnuPG, clefs, YubiKey : c’est parti« . Par ailleurs, avant de commencer l’export des clés et pour compléter la configuration du jeton, on exécutera la commande kdf-setup dans l’éditeur de cartes GnuPG en mode admin, le but étant de renforcer la sécurité des clefs (Pour plus de détails à ce sujet, lire la partie « Protection des clefs » de l’article « Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre« ). Après import des clefs, on dispose alors d’un nouveau jeton cryptographique prêt à être utilisé.

Afin de faire fonctionner ma clé Gnuk avec gpg –card-status sans utiliser sudo, ajout d’une règle udev dans le fichier /lib/udev/rules.d/60-gnuk.rules.

ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0000", ENV{ID_MODEL_ID}=="0000", MODE="660", GROUP="users"

Puis application des changements.

# rechargement des règles
sudo udevadm control --reload-rules
# Éventuellement redémarrage du système
sudo reboot

Sur le poste cible, sauvegarde du dossier .gnupg/private-keys-v1.d. Puis suppression de son contenu.

cp -r .gnupg/private-keys-v1.d .gnupg/private-keys-v1.d-save
rm .gnupg/private-keys-v1.d/*
gpg --card-status

La commande gpg –card-status a pour effet de réimporter les informations des clefs présentes sur la carte. Ainsi, si j’effectue une commande pass pour déchiffrer l’un de mes mots de passe, c’est bien la nouvelle clé Gnuk qui est attendue et non ma Yubikey. Pour repasser à la Yubikey, il suffit de supprimer à nouveau le contenu du dossier private-keys-v1.d et le tour est joué (et d’inverser jeton Gnuk et YubiKey).

Je note qu’il n’est pas possible en l’état d’utiliser deux supports différents pour les mêmes clefs, sans une intervention de l’utilisateur ou une automatisation des changements à effectuer en fonction du support branché. Pour utiliser indifféremment deux supports différents, un internaute proposait de créer trois sous-clefs supplémentaires, soit six en tout et de répartir les trois nouvelles sous-clefs sur le support supplémentaire.

Effectuer ce que je peux qualifier de « test grandeur nature » était ici indispensable, afin de s’assurer de la robustesse de la solution retenue pour la sécurisation de mon environnement informatique. En effet, s’appuyer sur une solution sans jamais avoir vérifié les procédures de restauration, le retour à un fonctionnement normal, me semble bien périlleux. C’est donc un pas de plus sur le chemin de ma résilience informatique !

Source:
GnuPG mailing list – GnuPG card && using the backup secret key