([!tag debian DNS]]

Introduction

Depuis quelques années déjà, j'utilise un serveur auto-hébergé qui fait à la fois des choses publiques (genre ce site web) mais également des choses privées, à disposition des machines qui se situent sur mon réseau local.

Parmi ces services privés, j'héberge un service de DNS à la fois local pour le réseau local mais également en tant que résolveur pour les autres machines. Chaque fois qu'une machine a besoin d'un nom public, elle passe par ce service DNS privé qui interroge toute la chaîne DNS avant de renvoyer la réponse aux clients.

Pourquoi faire comme ça me direz-vous ? Pourquoi ne pas utiliser simplement les serveurs DNS du fournisseur d'accès à Internet ? Ma réponse tient en plusieurs points:

  • D'abord parce que ces serveurs DNS sont parfois lents ou ont du mal à répondre. Effectivement, très souvent auparavant, j'avais de vrais de soucis avec les résolveurs DNS de Free. Tout le monde rallait à certain moments de la journée parce qu'il y avait un lag dans les réponses DNS ce qui donnait l'impression qu'Internet était lent !

  • Ensuite, pour des questions de vie privée. Avec toutes les requêtes DNS, mon FAI sait éxactement quels sont les sites que les gens de mon réseau local consultent. Ce n'est pas du tout son affaire de savoir ça. Notamment, ça ne regarde pas mon FAI de savoir que je me connecte à une plate-forme technique hyper-sécurisée du gouvernement. Le travail du FAI que je rémunère est de me fournir un accès à Internet, point. Et ne me dite pas que c'est pour prévenir des problèmes techniques: nous avons tout le loisir de faire remonter les problèmes quand ils surviennent, pas besoin de payer des gens pour faire de la surveillance préventive en scannant et analysant ce qui se passe au niveau DNS (en dehors de la supervision de base du service, bien entendu). Après, il se peut très bien que le FAI ne fasse rien de ces données mais, dans tous les cas, ce n'est pas contractuel, donc le doute est permis.

  • Enfin, c'est surtout parce que ces DNS sont souvent menteurs. Parfois c'est la justice française qui ordonne ça (une forme de censure légale) et dans ce cas, pourquoi pas. Mais c'est surtout que les DNS peuvent conduire à une forme d'abus de pouvoir privé, notamment si le FAI décide de lui même de ne pas répondre à certaines requêtes tout à fait légitimes.

  • Par ailleurs, ce n'est pas comme ça que fonctionne le DNS qui est un système complètement décentralisé: n'importe qui peut monter son propre service qui interroge les serveurs racines et rebondit ensuite sur les différents serveurs qui font autorité sur les domaines.

  • De plus, ça permet de soulager les ressources du FAI. Si tout le monde disposait de son serveur DNS dans sa machin box, il n'y aurait sans doute plus besoin de monter des serveurs monstres pour répondre aux requêtes DNS internes. Bon après, ça chargerait sans doute pas mal les serveurs racines.

  • Et pour terminer: le défi technique ! Se dire qu'on peut monter un service DNS (presque) celui d'un FAI donne l'impression qu'on sait faire des choses avec Internet. Ça peut toujours être un bon point à mettre sur un CV ou lors d'un entretien d'embauche.

Donc, depuis des années, j'utilise un service DNS interne. Pourtant le DNS évolue avec des choses comme DNSSEC, DNS over TLS et, plus récemment, DNS-over-HTTPS.

Je me suis dit qu'il fallait que je commence à m'intéresser à tout ce qui permet de chiffrer les accès clients-serveurs. Je l'ai déjà fait pour la messagerie électronique. A présent, ce sera pour le DNS avec DNS-over-TLS.

Pourquoi DNS-over-TLS et pas DNS-over-HTTPS ? Tout simplement parce qu'en 2019, DNS-over-TLS est la seule solution qui peut s'appliquer à tout un système d'exploitation et pas uniquement au navigateur web.

Cet article a pour objet de présenter l'installation d'un résolveur DNS exploitant DNS-over-TLS.

Quel serveur utiliser en 2019 ?

Traditionnellement, il existe bind dans sa version 9. Je l'ai utilisé pendant de nombreuses années. Il fait le job, reste simple à configurer et est packagé dans Debian. Néanmoins, depuis quelques années, de nombreuses distributions recommendent l'utilisation d'Unbound.

Comme Bind, il est codé en C (ce qui pour un gamin de 12 ans en 1990, signifie le graal de la puissance brute) ce qui permet de le déployer sur des petites configurations.

Par ailleurs, Unbound gère [un grand nombre de RFC sur le DNS]( https://nlnetlabs.nl/projects/unbound/rfc-compliance/).

Et pour terminer, Bind ne gère pas nativement les tunnels TLS. Pour activer DNS-Over-TLS, il faut s'appuyer sur stunnel alors qu'avec Unbound, il n'y a rien à faire.

Qu'est-ce-que nous voulons faire ?

  • Disposer d'un service de résolution DNS pour les clients du réseau local.
  • Le service ne doit pas être public (limité au réseau local).
  • Il doit être disponible en IPv6 et IPv4.
  • Il doit mettre en oeuvre DNS-over-TLS.
  • Il doit mettre en oeuvre le service DNS classique sur UDP et TCP.
  • Il doit faire en sorte de chiffrer au maximum ce qui sort du réseau local.
  • Il doit utiliser de préférence le protocole IPv6 pour les interrogations DNS.
  • Tout ce qui ne sert pas doit être éteint/fermé.

Configuration nftables

Avant de commencer, autant ouvrir les ports DNS (UDP/53 et TCP/53) et DNS-over-TLS (TCP/853) aux clients du réseau local. Mon réseau local est disponible en IPv4 et en IPv6 donc ça donne les éléments suivants:

Pour la chaîne en entrée

#!/usr/sbin/nft -h

# Configuration spécifique d'Unbound
# Ouverture des ports privés en entrée sur le réseau local
add rule inet public_server entree ip saddr 192.168.0.0/24 udp dport { 53 } accept
add rule inet public_server entree ip saddr 192.168.0.0/24 tcp dport { 53, 853 } accept
add rule inet public_server entree ip6 saddr 2a01:e0a:14:9be0::/64 udp dport { 53 } accept
add rule inet public_server entree ip6 saddr 2a01:e0a:14:9be0::/64 tcp dport { 53, 853 } accept

# Ouverture des ports privés en sortie sur le réseau local
add rule inet public_server sortie ip daddr 192.168.0.0/24 udp sport { 53 } accept
add rule inet public_server sortie ip daddr 192.168.0.0/24 tcp sport { 53, 853 } accept
add rule inet public_server sortie ip6 daddr 2a01:e0a:14:9be0::/64 udp sport { 53 } accept
add rule inet public_server sortie ip6 daddr 2a01:e0a:14:9be0::/64 tcp sport { 53, 853 } accept

N'oubliez pas non plus d'ouvrir les ports UDP/TCP/53 et TCP/853 pour que votre serveur puisse faire des requêtes DNS aux serveurs faisant autorité.

Installation de unbound

Sous Debian Buster, unbound est consituté d'au moins deux paquets:

  • unbound qui est le serveur en lui-même.
  • unbound-anchor qui est le programme permettant de récupérer les certificats DNSSEC de la racine DNS.

Ici, un simple apt-get install unbound suffit à faire le job.

Gestion des certificats Letsencrypt

Avant de commencer à configurer, n'oubliez pas la gestion des clefs de chiffrement. Si vous faîtes du DNS-Over-TLS, vous devez disposer d'un certificat en bonne et due forme. Il n'y a pas de miracle. Si vous utilisez Letsencrypt et que vous souhaitez réutiliser le certificat émis par cette AC, il vous faudra ruser un petit peu.

En effet, unbound est une application "apparmorée": apparmor gère finement quels fichiers l'application peut accéder et, bien évidemment, unbound n'a pas accès au répertoire /etc/letsencrypt.

Vous devrez donc amender la configuration apparmor d'unbound en ajoutant le contenu qui suit dans le fichier `/etc/apparmor.d/local/usr.sbin.unbound':

# Access to Let's Encrypt keys
  /etc/letsencrypt/live/votre_domaine/*.pem r,
  /etc/letsencrypt/archive/votre_domaine/*.pem r,

Ensuite, un simple systemctl restart apparmor devrait gérer les problèmes d'accès aux clefs letsencrypt.

Configuration globale d'unbound

Ce qui est pratique avec unbound c'est quon peut tout configurer dans un seul fichier ou choisir de séparer la configuration en plusieurs fichiers. C'est d'ailleurs le parti pris de Debian. Donc on va faire avec ce mode de configuration.

La configuration par défaut vous permet de bénéficier d'un résolveur DNS (un truc qui fait les requêtes DNS vers l'extérieur en passant par les serveurs racines) sur localhost.

Mais nous allons modifier cette configuration en ajoutant le fichier /etc/unbound/unbound.conf.d/resolver.conf avec le contenu suivant:

# Configuration du résolveur local
server:

  # Ports et adresses
  port: 53
  interface: 127.0.0.1
  interface: ::1
  interface: 192.168.0.4@53
  interface: 192.168.0.4@853
  interface: 2a01:e0a:14:9be0:bab:babe:bab:baba@53
  interface: 2a01:e0a:14:9be0:bab:babe:bab:baba@853
  interface-automatic: no
  outgoing-interface: 192.168.0.4
  outgoing-interface: 2a01:e0a:14:9be0:bab:babe:bab:baba
  prefer-ip6: yes
  do-ip4: yes
  do-ip6: yes
  do-udp: yes
  do-tcp: yes

  # DNS-over-TLS
  tls-service-key: "/etc/letsencrypt/live/votre_domaine/privkey.pem"
  tls-service-pem: "/etc/letsencrypt/live/votre_domaine/fullchain.pem"
  tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"
  tls-port: 853

  # Restriction de service
  access-control: 127.0.0.1 allow
  access-control: ::1 allow
  access-control: 192.168.0.0/24 allow
  access-control: 2a01:e0a:14:9be0::/64 allow

  # Configuration des logs
  verbosity: 1
  use-syslog: yes
  log-queries: yes
  log-servfail: yes

remote-control:
  control-enable: no

Un simple systemctl restart unbound devrait faire le job. Sinon journalctl est votre ami.

Quelques explications toutefois sur cette configuration. D'abord, la partie relative aux interfaces où le service unbound est disponible. Il y a en effet, de nombreuses déclarations d'interfaces. C'est essentiellement à cause de DNS-Over-TLS car Unbound a besoin qu'on lui indique sur quelles interfaces activer le port 853.

Pour le contrôle d'accès, normalement, la configuration du firewall fait que ça ne sert à rien mais j'ai préferé l'ajouter (ceinture et bretelle) au cas où la conf du firewall bouge. Par défaut tout ce qui n'est pas localhost est en mode "refused" (renvoie une réponse DNS REFUSED au client). Mettre en allow les sous-réseaux autorisés suffit à ouvrir le service aux clients des sous-réseaux.

Configuration des clients

Ok, vous êtes moderne et vous avez sytemd d'installé sur votre système. Vous vous dites donc que tout est correct et configuré correctement out-of-the-box. Mais ce ne sera pas forcément le cas et pour cette hypothèse, mieux vaut comprendre comment faire.

Systemd met à disposition un service de gestion de la résolution de noms DNS qui se nomme systemd-resolved. Ce dernier est configuré à un niveau global dans le fichier /etc/systemd/resolved.conf. Ensuite, si vous utilisez systemd-networkd, chaque carte réseau peut également embarquer sa propre configuration DNS. Néanmoins, tout ce qui sera déclaré dans resolved.conf s'appliquera à tout ce qui n'est pas déjà configuré.

systemd-resolved met à disposition 3 moyens de résolution de noms:

  • Par l'API systemd-resolved via une interface D-Bus.
  • Via l'API NSS.
  • Et enfin, via le traditionnel /etc/resolv.conf via un serveur DNS local (le stub), fourni par systemd-resolved sur le port 53 de 127.0.0.53 uniquement (pas en IPv6).

Pour résumer:

  • On déclare les serveurs DNS de base dans /etc/systemd/resolved.conf.
  • Si on a des interfaces réseaux qui utilisent des serveurs DNS spécifiques, on l'indique dans la conf networkd.
  • En utilisant nss-resolve, et un peu de conf, les applis compatibles NSS utiliseront systemd-resolved.
  • Pour tout le reste, on utilisera le stub.

Pour l'API par D-Bus, on n'a rien à faire !

Pour NSS, il faut installer le paquet libnss-systemd (mais il devrait déjà être installé de facto). Ensuite, il faut simplement modifier le fichier /etc/nsswitch.conf en ajoutant le module systemd dedans.

Pour info, NSS est une API qui vise à concentrer tout ce qui a trait aux noms qu'on peut trouver sur une machine, que ce soit des noms d'utilisateurs, de groupes, de machines, etc. Pour chaque type (on appelle ça une base de noms), on peut utiliser différents modules qui vont chercher dans des fichiers textes, sur un serveur DNS, sur un serveur LDAP les noms qu'on cherche. L'ordre des modules donne l'ordre de ce qui sera joué en termes de recherche. Par exemple, la ligne:

hosts:  files dns

indique qu'on commence par rechercher des noms de machine dans un fichier (généralement /etc/hosts) puis sur un serveur DNS.

Dans notre cas, il suffit d'ajouter le module systemd à cette ligne pour bénéficier de systemd-resolved:

hosts:  files resolve [!UNAVAIL=return] dns

On place resolve avant dns car il est possible d'utiliser un fichier resolv.conf différent de celui configuré par la méthode qui suit.

Pour le dernier cas où vos applications n'utilisent ni l'API resolved ni NSS, il vous reste à utiliser le serveur local DNS de systemd-resolved (le stub) en effectuant un lien entre le fichier de configuration dynamique généré par systemd-resolved et le traditionnel /etc/resolv.conf:

# ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Un truc de base comme la commande host utilisera ce cas de figure.

Bien entendu, voici le contenu de votre fichier /etc/systemd/resolved.conf:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
DNS=ipv6_de_votre_serveur_DNS ipv4_de_votre_serveur_DNS
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
#Domains=
LLMNR=no
#MulticastDNS=yes
#DNSSEC=allow-downgrade
#Cache=yes
DNSStubListener=yes
DNSOverTLS=opportunistic
ReadEtcHosts=yes

A partir de cet instant, toutes vos requêtes doivent passer par votre serveur DNS via le protocole DNS-over-TLS.

Une tâche pour Ansible

Pour les gens qui utilisent Ansible pour gérer le déploiement de leurs machines, voici un fichier de tâche à insérer où vous voulez dans votre playbook:

---
# Installation et configuration de Unbound en mode résolveur
- name: Unbound installation
  apt:
    name: unbound
    install_recommends: no
    state: latest
    force_apt_get: yes
    autoclean: yes

- name: Unbound nftables configuration
  copy:
    src: nftables/unbound.nft
    dest: /etc/nftables/unbound.nft
    owner: root
    group: root
    mode: 0644

- name: Restart nftables
  systemd:
    name: nftables
    state: restarted

- name: Unbound resolver configuration
  copy:
    src: unbound/resolver.conf
    dest: /etc/unbound/unbound.conf.d/resolver.conf
    owner: root
    group: root
    mode: 0644

- name: Add unbound to ssl-cert group
  user:
    name: unbound
    append: yes
    groups: ssl-cert

- name: Improve apparmor configuration of unbound
  copy:
    src: apparmor.d/usr.sbin.unbound
    dest: /etc/apparmor.d/local/usr.sbin.unbound
    owner: root
    group: root
    mode: 0644

- name: Restart apparmor
  systemd:
    name: apparmor
    state: restarted

- name: Uninstall bind9
  apt:
    name: bind9
    install_recommends: no
    state: absent
    force_apt_get: yes
    autoclean: yes

- name: Restart unbound
  systemd:
    name: unbound
    state: restarted
...

Les fichiers mentionnés sont ceux présentés dans les paragraphes précédents.

Conclusions

Bon, voilà un sujet bien couvert. Après quelques enquêtes (apparmor est à prendre en compte très souvent) et un peu de configuration, vous devriez disposer d'un service DNS qui gère à la fois le DNS en clair et DNS-Over-TLS.

Au niveau des limites, vous comprendrez aisément qu'une machine hostile sur votre réseau local pourra quand même étudier les requêtes DNS en clair qui passent car DNS-over-TLS ne s'adresse qu'aux requêtes clients-résolveurs, pas vers des serveurs faisant autorité. Pour ce dernier point, il faudra sans doute que le protocole ADoT (Authoritative DNS over TLS) soit établi dans une RFC définitive.

Il reste d'autres choses à explorer comme DNS-over-HTTPS mais j'ai choisi de ne pas l'implémenter pour l'instant. D'abord parce que les implémentations au niveau des clients se limitent à Firefox dans mon cas, ce qui est bien mais pas suffisant. Ensuite, je pense que DNS-over-HTTPS n'apporte pas grand chose comparé à DNS-Over-TLS, c'est juste la même chose sauf qu'on tape sur le port 443. A moins d'être derrière un firewall nazi, ça ne fait pas plus que DNS-over-TLS. Enfin, les seules implémentations de serveurs DNS-over-HTTPS sont des résolveurs publics, pas les serveurs faisant autorité et ça ne viendra pas plus combler ce manque au niveau du chiffrement du DNS.

En attendant, vous avez quand même de quoi sécuriser plus globalement le flux entre vos clients et votre résolveur interne, ce qui est déjà pas si mal à votre niveau.

Posted mer. 28 août 2019 21:21:21

I have taken some time to deal with raster bands. I just wanted to understand the concept. Here is what I have found...

A band can be understood as a sort of layer inside the raster data. A raster is a matrix representation of some data with each cell a discrete value. The matrix has got X and Y size, and, of course, the matrix is georeferenced in the space: the position of the 0,0 and sizeX, sizeY cells are translated into the chosen coordinate reference system. So now, 0,0 cell points to an lat,long place. From then, you can deduce the resolution of the image in meters.

A raster with multiple bands is a raster with multiple matrices. Each matrix covers the same cells than the others. The area is the same for each band, but the values are not (well, they are independent).

What are the differente use cases of bands? Well, plenty of different uses actuallay:

  • When using aerial photos, you have three bands: one the Red channel, one for the Green channel and another one for the Blue channel. "Assembling" the three channels make it look like a photo.
  • But you can go further by adding a 4th band which will deal with transparency (alpha channel): the cells in this matrix will tell the level of transparency of the other bands cells.
  • You can go a little more further by using a mask band. In this one, data are telling if the cell should be displayed or not.
  • Ok, this is the most common use of rasters but there is also a much more complex one: sometimes, data in the bands are not just RGB components but data from different sensors. Most of the time, sattelites have different sensors: temperature, humidity, infrared, altitude, etc. Each band will store an instrument value. That is why SENTINEL2 sattelite rasters are 13 bands rasters. The way to display data are controlled by your GIS software.
  • You can also do some math on the matrices and store the results on another band.

How are the bands stored into the raster file? Well it depends on the format. For example, for tiffs files, the cells are storing all data for each band next to the other band. It means that when you want to display only one band, you have to seek N bytes just to get the data you want. For other formats, the data of each band is stored in a different part of the file.

By the way, I have built some tools to deal with raster bands. They are coded in Python3 with the gdal library and you can use numpy to deal with the matrices and you can read the code in this public repository

Posted lun. 19 août 2019 12:00:00

Ah, le charme du retro-gaming !

Il y a vingt ans sortait Command & Conquer Tiberian Sun par le studio Westwood. Évidemment à l'époque, je ne pouvais pas y jouer: pas de sous et pas la machine suffisamment performante pour pouvoir gérer correctement l'affichage.

J'avais certes vu (et un peu pratiqué) l'excellentissime Red Alert en 1997 quand j'étais au Lycée Militaire d'Autun. J'en avais gardé un avis plutôt positif et enthousiaste. Sans doute l'innocence de la jeunesse...

Il n'y a pas si longtemps, je suis tombé sur une vidéo parlant de Tiberian Sun et je me suis rappelé Red Alert. Je me suis demandé si, vingt ans plus tard, il était possible de jouer encore à un jeu vidéo sur une configuration moderne. Par moderne, j'entends les éléments suivants:

  • Debian Buster.
  • Un bureau Wayland (j'utilise Sway).
  • N'importe quelle version de Wine.

Et bien, comme le confirme cette capture d'écran, ça semble possible ! Tiberian Sun Screenshot

J'ai simplement téléchargé une archive toute prête du jeu (qui a été "libéré" sous forme de freeware en 2010). J'ai décompressé tout ça dans un répertoire et j'ai lancé le script suivant:

#!/bin/bash

# Set video to 800x600
swaymsg output DP-1 pos 0 0 mode 800x600

# Launch game
WINEPREFIX="/media/games/CCTS" wine '/media/games/archives/C&C/EA Games/Command & Conquer The First Decade/Command & Conquer(tm) Tiberian Sun(tm)/SUN/SUN.EXE'

# reset old mode
swaymsg output DP-1 pos 0 0 mode 1920x1080

exit 0

Pour les explications:

  • swaymsg output permet de changer la résolution d'écran en 800x600 qui est la résolution native du jeu.
  • WINEPREFIX permet d'indiquer de stocker la partie disque de l'OS émulé par Wine (un windows 7 32bits en l'occurence) dans un répertoir dédié plutôt que dans ~/.wine
  • wine lance ensuite l'exécutable directement depuis son stockage.
  • Enfin, on recharge la configuration graphique initiale.
  • Vous devez disposer de la version 32bits i386 de Wine. Sous Debian, ça se fait assez facilement.
  • J'ai également dû configurer mon moniteur pour utiliser un mode 4:3 une fois que le jeu est lancé.

Et au final, je dois bien avouer que je suis bien surpris car le jeu fonctionne correctement, sans aucun plantage et en plein écran.

Bon, allez, je retourne dégommer du NOD et du GDI...

Posted ven. 16 août 2019 11:01:00 Tags:

Introduction

Debian Buster est sortie récemment et prend en charge SecureBoot. J'avais toujours refusé de m'occuper de cette manière de booter mais, à l'occasion de la sortie de la dernière Debian, je me suis dit que je devais essayer de m'intéresser au sujet.

En suivant les instructions officielles, je suis parvenu à booter avec SecureBoot en pratiquement une seule ligne de commande et une manipulation dans le BIOS (j'étais déjà en boot UEFI).

Mais après l'effet whaou, je me suis rendu compte que Wireguard ne fonctionnait plus. En effet, ce dernier n'est (pas encore) inclus dans le noyau Linux et il est fourni via DKMS sous Debian (il est compilé à l'installation du paquet). Or, quand SecureBoot est activé, les modules non signés par la clef Debian ne sont pas activé (une conf du kernel pour ça). Sur mon portable, ça va encore plus loin: le pilote Wifi est en DKMS !

Néanmoins, j'ai lu qu'il devait être possible de signer ces modules pour pouvoir les lancer. Voici ce que j'ai trouvé (qui bien sûr n'est pas une référence)...

Pré-requis

  • Avoir un BIOS qui gère UEFI et SecureBoot.
  • Avoir installé shim-signed et consorts.
  • Avoir des modules DKMS installés (sinon, vous n'avez pas de problème avec SecureBoot).
  • Installer le paquet: mokutil

Génération des clefs de signature

Ici, rien de fantoche, on va juste créér un couple clef privée/publique en RSA sur 2048bits. La clef publique sera convertie au format DER puis uploadée dans la base MOK.

Pour des questions de sécurité et aussi de facilités, nous allons stocker ces clefs dans le répertoire /etc/dkms/keys créé en mode 700.

On va donc commencer à génerer le couple clef privée/publique. Elle sera valable 10 ans et pour l'identifier, je vais mettre un CN avec le nom de la machine:

# mkdir -p /etc/dkms/keys
# chmod 700 /etc/dkms/keys
# cd /etc/dkms/keys/
# openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt -nodes -days 3650 -subj "/CN=nom_de_machine/"

Ensuite, nous allons simplement la convertir au format DER:

# openssl x509 -in MOK.crt -out MOK.der -outform DER

Ok, nos clefs sont disponibles.

Chargement des clefs dans la "base" MOK

Maintenant, il reste à injecter la clef publique dans la base MOK. Pour cela, nous allons utiliser l'outil mokutil qui indique à shim de charger des clefs au prochain reboot:

# mokutil --import /etc/dkms/MOK.der

Attention, mokutil va vous demander un mot de passe pour protéger l'accès à cette clef (uniquement pour son chargement dans la base MOK via shim). Je vous conseille de mettre un mot de passe qui se tape bien en qwerty sinon, vous pourriez très bien ne pas pouvoir le taper au clavier.

Vous pouvez maintenant redémarrer la machine et vous aurez un écran spécifique de shim pour importer la clef publiquer dans la base MOK. Oui, ça fait bizarre de devoir rebooter mais c'est la méthode sécurisée pour le faire: ça évite qu'un mex qui accès à mokutil puisse balancer des clefs dans votre dos...

Procédure de signature manuelle

Voyons maintenant comment signer nos modules pour les faires prendre en compte par MOK. Il existe tout simplement un outil dédié à ça dans le paquet linux-kbuild.

# cd /usr/lib/modules/4.19.0-5-adm64/updates/dkms/
# /usr/lib/linux-kbuild-/scripts/sign-file sha256 /etc/dkms/keys/MOK.key /etc/dkms/keys/MOK.der ./monmodule.ko

Sous Debian, les modules DKMS ne sont pas compressés donc on peut les signer directement. Si vous voulez faire un test, faites un simple modprobe sur votre module et il devrait se charger tout seul.

Automatisation

Maintenant que nous avons une méthode assez basique, il reste à l'automatiser. En effet, à chaque mise à jour du noyau, il faudrait resigner les modules. Le faire à la main à chaque fois est fastidieux. Heureusement, dkms possède des éléments permettant de faire le job. Encore faut-il les connaître.

Bon, DKMS est un utilitaire codé en Bash ! En lisant le code et aussi le manuel qui semble complet, on apprend que le fichier /etc/dkms/framework.conf contient des directives de configuration qui s'appliquent à tous les scripts dkms.conf.

En poursuivant l'étude, on voit une variable nommée POST_BUILD qui contient l'emplacement d'un script à lancer après le build des modules. Parfait, ça semble être le bon endroit pour indiquer un script de signature. Néanmoins, le script est lancé sans arguments...

Mais, pas de bol, POST_BUILD, comme d'autres variables ne sont pas accessibles via framework.conf. Le seul "truc" qu'on peut faire, c'est de nommer un fichier .conf avec le même nom que le module et y ajouter notre POST_BUILD. Un peu laborieux si on a beaucoup de modules mais ça ne se fait qu'une fois !

Avant tout ça, il nous faut un script qui puisse se lancer sans arguments et qui récupère les variables définies auparavant dans la chaîne DKMS pour nous permettre de signer le bon module (avec la bonne clef).

#!/bin/bash

# Sign a DKMS module with a key

privKey="/etc/dkms/keys/MOK.key"
pubKey="/etc/dkms/keys/MOK.der"
KERNVER=$(awk -F . '{print $1"."$2}' <<< "$(uname -r)")

cd ../$kernelver/$arch/module/

for kernel_object in *ko; do
    echo "Signing kernel_object: $kernel_object"
    /usr/lib/linux-kbuild-$KERNVER/scripts/sign-file sha256 $privKey $pubKey "$kernel_object";
done

exit 0

N"oubliez pas de le rendre exécutable par root au moins.

Ensuite, il reste à modifier le fichier /etc/dkms/monmodule.conf et y ajouter la ligne:

POST_BUILD=../../../../../../etc/dkms/sign_module.sh

Au prochain build DKMS du module, votre module sera automatiquement signé (même si en passant par apt install, on ne voit pas forcément le message de notre script).

Conclusions

Ce que j'ai décris ressemble presqu'à un hack mais ça fonctionne à peu près. Quelle joie de se dire qu'on a une machine sécurisée par SecureBoot mais qui utilise aussi des modules signés avec notre propre clef.

Avec l'implémentation Debian de SecureBoot, il n'y a finalement pas tant de choses à faire que ça et c'est tant mieux. Peut-être qu'un jour il y aura une méthode officielle pour ça ?

Références

Posted sam. 20 juil. 2019 23:56:52 Tags:

Introduction

Cela fait maintenant de nombreuses années que je gère ma propre plate-forme publique Internet et par la même occasion ma propre plate-forme de courrier électronique. D'une manière générale, je suis assez content de ce que j'ai mis en place.

C'est souvent le cas sur le courrier électronique, au moins sur la partie serveur. Les logiciels sont "vieux" matures, ils ont fait leur preuve. Les protocoles évoluent peu. Une fois que la chaîne est en place, à part suivre les correctifs de sécurité et les évolutions majeures des logiciels serveurs, il n'y a pas grand chose à faire et c'est tant mieux.

Ceci dit, le courrier électronique continue à évoluer dans le temps, notamment à l'initiative du renforcement de la sécurité et de la protection de la vie privée. C'est le cas avec la RFC8314 qui vient un peu bousculer la manière de gérer une plate-forme de courrier électronique. Cela faisait quelques temps que je l'avais vue passer et, après avoir trouvé un peu de temps et un prétexte pour revoir la configuration de mon serveur public, j'ai essayé de la mettre en oeuvre.

Cet article a pour but d'illustrer les principaux changements que j'ai intégré sur ma plate-forme de courrier électronique pour me conformer du mieux que possible à la RFC8314.

Qu'est-ce-qu'il y a dans cette RFC ?

Dans les faits, la RFC est plutôt courte en contenus spécifiques. Pour résumer sérieusement, elle indique qu'il faut faire en sorte de chiffrer au maximum tous les canaux d'accès clients à un serveur SMTP (un MTA).

Pour rappel un MTA peut faire grosso modo deux choses: - Récupérer des courriers électroniques envoyés par un autre MTA pour un des clients de notre plate-forme. - Envoyer, pour le compte des clients de la plate-forme, des courriers électroniques à d'autres MTA.

La RFC8314 s'attaque au deuxième point. Elle stipule qu'il est maintenant temps de passer au tout chiffré pour la communication entre tous les composants serveurs de la plate-forme (MTA/MDA comme Dovecot) et les clients. Pour ce faire, deux ports réseaux sont dédiés à ces communications:

  • le port 465 pour le protocole SMTPS.
  • le port 993 pour le protocole IMAPS.

Les accès non chiffrés sont à proscrire ainsi que les accès en STARTTLS. Cette dernière technique permettait d'initier une communication chiffrée à partir d'un port en clair. Le début de la conversation réseau était néamoins en clair. C'est ce que j'avais mis en place sur ma plate-forme de courrier électronique car c'était plus simple pour moi d'avoir un seul port pour chaque service (143 pour IMAP+STARTTLS et 25 pour SMTP+STARTTLS).

De plus, cette RFC lève une grosse ambiguité sur le port SMTP à utiliser pour les clients. Jusque là, on avait le choix entre le port 25 (qui sert également pour le traffic MTA à MTA), le port 587 (pour les clients en clair et en STARTTLS) et le port 465 pour l'accès complet TLS. Ce dernier n'était qu'un standard de fait, pas un truc obligatoire et, à une époque donnée, déconseillé. Le port IANA 465 a méme été affecté à un autre protocole même si de nombreux administrateurs de MTA continuaient à l'utiliser pour leurs clients.

Pour le coup, la RFC clarifie vraiment les choses. Néanmoins, elle permet de conserver certaines anciennes configurations, histoire de gagner du temps. Néanmoins, ce n'est pas l'approche que j'ai retenue. En effet, tant qu'à faire de faire une modification de configuration, autant y aller franco et se mettre dans les clous tout de suite. De plus, comme j'ai très peu de clients à gérer, la migration est assez simple.

La RFC8314 ne s'adresse qu'aux communications clients MTA et pas à celles entre MTA car, si en règle générale, un administrateur de MTA peut avoir un controle sur les clients de sa plate-forme, ce n'est pas vrai du tout pour les autres MTA. Certains peuvent très bien ne pas savoir utiliser de canal chiffré, ou ne pas vouloir (enfin en 2019, cette affirmation tient plus de la paresse que de l'écueil technique).

Le traffic de MTA continuera donc à se faire sur le port 25, que ce soit en clair ou en STARTTLS.

Résumé de ce que nous devons faire

  • Créer une conf dans Exim pour ouvrir le port 465 en TLS v1.2.
  • Interdire la soumission authentifiée des clients sur le port 25 (y compris pour STARTTLS) tout en maintenant l'accès pour les autres MTA.
  • Modifier la conf de Dovecot pour ouvrir le port imaps et fermer le port imap en clair (TLS sur demande).
  • Ouvrir le firewall sur les nouveaux ports.
  • Publier les annonces de service dans le DNS.

Ouverture des ports au niveau du pare-feu

Nous allons commencer avec le pare-feu. En effet, ça ne sert à rien de configurer un truc si on ne peut pas le tester. Pour ma part, j'ai juste ajouté les ports TCP 465 et 993 et retiré le port TCP 143 étant donné que je vais supprimer l'accès IMAP en clair.

Voici mon fichier de configuration de nftables (/etc/nftables.conf):

#!/usr/sbin/nft -f

# Configuration NFT de serveur

# On vide toutes les règles
flush ruleset

# Table pour un serveur public un peu fermé
table inet public_server {
  # Chaîne de gestion de tout ce qui rentre
  chain entree {
    # Chaîne de type filtre, en entrée
    type filter hook input priority 0;

    # Accepter tout ce qui vient de l'interface loopback
    meta iif lo accept

    # Accepte le trafic qui vient de la machine
    ct state established,related accept

    # Réponse au ping IPv4
    ip protocol icmp accept

    # OUverture de i2pd
    meta skuid i2pd accept

    # Ouverture des ports publics
    tcp dport { 25,53,80,443,465,993 } accept
    udp dport { 53 } accept

    # Compter et journaliser ce qui est rejeté
    counter log prefix "Connexion entrante rejetée: " level warn drop
  }

  # Chaîne de gestion de tout ce qui sort
  chain sortie {
    type filter hook output priority 0;

    # On accepte les sorties vers l'interface loopback
    meta oif lo accept

    # Réponse au ping IPv4
    ip protocol icmp accept

    # Ouverture pour i2pd
    meta skuid i2pd accept

    # Ouverture des ports publics
    tcp sport { 25,53,80,443,465,993  } accept
    udp sport { 53 } accept

    # Ouverture des ports externes classiques utilisés par le système
    tcp dport { 25,53,80,143,443,465,993,995 } accept
    udp dport { 53 } accept

    # count and drop any other traffic
    counter log flags skuid prefix "Connexion sortante rejetée: "
    level warn drop
    }
}

Je vous invite à le mettre en service au moment où vous terminez les configurations des différents logiciels serveurs histoire de minimiser l'arrêt de service (lancé en l'état, le port 143 peut encore être utilisé par des clients).

Configuration d'Exim4

Introduction

Pour comprendre ce qu'il faut faire, mieux vaut d'abord lire la documentation à ce sujet.

Autre point à noter au cas où: la version d'Exim4. Pour ma part, j'utilise le backport de Debian Stretch, soit la version 4.92-8 qui est la même que celle de Debian Buster (la nouvelle distribution stable de Debian au moment de la rédaction de cet article). Je peux donc utiliser la documentation du dessus.

Autre chose à savoir, Exim4 sous Debian utilise GNUTls et non openssl. Cela a une incidence sur la configuration.

Enfin, comme si cela n'était pas déjà assez compliqué, Debian a une manière particulière de configurer Exim4. Pour ma part, j'ai choisi la configuration éclatée. Ce qui suit concerne ce type de configuration. Néanmoins, vous pouvez vous en inspirer pour faire vos modifications.

Préparation d'un fichier de paramètres Diffie-Hellman digne de ce nom

Les bonnes pratiques de sécurité recommendent d'utiliser une meilleure taille de clef dans les échanges Diffie-Hellman. En général, la taille des échanges de clef est limitée à 2048. Pour ma part, je préfère la monter à 4096 octets grâce à la commande suivante:

$ openssl dhparam 4096 > dh.pem

Attention, la génération de ce fichier prend pratiquement 1h sur ma station de travail (de 2012).

Ensuite, vous pouvez utiliser ce fichier dans Exim4 (/etc/exim4/dh.pem) et également dans Dovecot (remplacer /etc/dovecot/dh.pem). Ce fichier peut être public.

Configuration TLS d'Exim4

La première des choses, c'est de modifier la configuration principale d'Exim (le main). Sous Debian, on trouve essentiellement conf.d/main/03_exim4-config_tlsoptions pour gérer ces éléments de configuration.

### main/03_exim4-config_tlsoptions
#################################

# TLS/SSL configuration for exim as an SMTP server.
# See /usr/share/doc/exim4-base/README.Debian.gz for explanations.

.ifdef MAIN_TLS_ENABLE
# On affiche qu'on souhaite avertir tout le monde qu'on fait du TLS.
.ifndef MAIN_TLS_ADVERTISE_HOSTS
MAIN_TLS_ADVERTISE_HOSTS = *
.endif
tls_advertise_hosts = MAIN_TLS_ADVERTISE_HOSTS

# Configuration des clefs/certificats TLS
.ifdef MAIN_TLS_CERTKEY
tls_certificate = MAIN_TLS_CERTKEY
.else
.ifndef MAIN_TLS_CERTIFICATE
MAIN_TLS_CERTIFICATE = CONFDIR/exim.crt
.endif
tls_certificate = MAIN_TLS_CERTIFICATE

.ifndef MAIN_TLS_PRIVATEKEY
MAIN_TLS_PRIVATEKEY = CONFDIR/exim.key
.endif
tls_privatekey = MAIN_TLS_PRIVATEKEY
.endif

# On indique le fichier de paramétrage de Diffie-Hellman
.ifdef _HAVE_GNUTLS
tls_dhparam = /etc/exim4/dh.pem
tls_dh_max_bits = 4096
.endif

# On ajoute le port submissions
tls_on_connect_ports = 465

# On active le port submissions en plus du smtp simple
daemon_smtp_ports = 25 : 465

.else
# Si l'option MAIN_TLS_ENABLE n'est pas activée, on n'affiche rien.
tls_advertise_hosts =
.endif

Une fois rédigé, il reste à renseigner les valeurs des macros sus-citées (ce qui est en majuscule). Pour ma part, je place tout dans conf.d/main/000_localmacros:

# on active TLS:
MAIN_TLS_ENABLE = true

# Emplacements des fichiers de clef pour TLS:
MAIN_TLS_CERTIFICATE = /etc/exim4/keys/medspx.fr.cert.pem
MAIN_TLS_PRIVATEKEY = /etc/exim4/keys/medspx.fr.pkey.pem

Les fichiers de clefs mentionnés ci-dessus sont des symlinks vers une configuration Let's Encrypt.

Gestion de l'authentification

Pour ma part, je n'ai pas eu grand chose à faire si ce n'est relire ma conf existante et considérer qu'elle était suffisante, à un petit détail près. En effet, pour l'authentification, je n'ai activé que le pilote d'authentification PLAIN. Depuis le début, je fais du STARTTLS et j'ai bien sûr indiqué que la commande SMTP AUTH ne serait présentée (et activée) uniquement lorsque la communication est chiffrée (par STARTTLS ou par TLS en direct).

Néanmoins, je souhaite aussi désactiver l'authentification en dehors du port dédié à ça (le port 465). Tout ce que j'ai trouvé de bon est d'utiliser la directive server_advertise_condition et de la faire tester que le port utilisé sur le serveur est le port 465. En pratique, ça donne ces quelques lignes dans le fichier conf.d/auth/20_exim4-config_virtual:

### auth/20_exim4-config_virtual
#################################

# Configuration de l'authentification avec un compte virtuel

plain_server:
  driver = plaintext
  public_name = PLAIN
  server_condition = "${if crypteq{$auth3}{\\\{md5\\\}${extract{1}{:}{${lookup{$auth2}lsearch{CONFDIR/passwd}{$value}{fail}}}}}{1}{0}}"
  server_set_id = $auth2
  server_prompts = :
  server_advertise_condition = ${if eq{$tls_in_cipher}{} {}{${if eq{$received_port}{465} {*}{}}} }

L'astuce consiste à indiquer dans la partie de vérification de la présentation de l'option AUTH une double condition: si la connexion est chiffrée (par TLS ou STARTTLS), alors on regarde si le port utilisé est 465, dans ce cas, on renvoie '*', dans les 2 autres cas, on ne renvoie rien, ce qui a pour effet de ne pas présenter l'option AUTH et donc d'invalider toute tentative d'authentification.

On aurait pu désactiver complètement STARTTLS sur le serveur mais c'est un mécanisme de chiffrement utilisé aussi par les serveurs MTA qui vous relaient un message (et sur lesquels, vous avez peu d'impact).

Si vous lisez la variable server_condition, vous vous rendrez compte que ma méthode de gestion des comptes authentifiés est pourrie (mais j'assume). En effet, le fichier d'authentification se nomme /etc/exim4/passwd et il contient un truc du genre:

nom_du_compte:hash_md5_du_mot_de_passe

Pour générer le hash MD5 du mot de passe, il suffit de faire:

$ echo -n the_harsh_password | md5sum

C'est la méthode de stockage de mots de passe que j'utilise depuis longtemps et elle a fait ses preuves, notamment parce qu'elle se passe de tout lien entre le compte utilisé dans Exim et le compte de l'utilisateur sur le système. Ok, MD5 en 2019... Oui, j'avais la flemme de changer tous les comptes !

Remise en service

Un simple systemctl restart exim4 devrait suffire. Pour vérifier que le service est fonctionnel sur le bon port, vous pouvez utiliser ss:

# ss -tlp

Configuration de Dovecot

Planification

Maintenant, passons à Dovecot. Nous voulons supprimer l'écoute sur le port 143, activer l'écoute sur le port 993 (imaps) et également indiquer d'utiliser TLSv1.2 ainsi que l'utilisation de Diffie-Hellman un peu partout.

Pour ma part, j'utilise la version 2.3 de Dovecot (il y a eu des évolutions entre la 2.2 et la 2.3 sur TLS notamment).

Gestion des ports

Pour cette partie, il suffit d'éditer le fichier /etc/dovecot/conf.d/10-master.conf:

# On désactive le protocole IMAP sur le port réservé
service imap-login {
  inet_listener imap {
    port = 0
  }

# On active le service IMAPS
  inet_listener imaps {
    port = 993
    ssl = yes
  }

  # Nombre de connexions clientes simultanées max avant kill du processus.
  service_count = 10
}

# On désactive complètement POP3
service pop3-login {
  inet_listener pop3 {
    port = 0
  }
  inet_listener pop3s {
    port = 0
    #ssl = yes
  }
}

Implémentation de TLSv1.2

Tout se passe dans le fichier /etc/dovecot/conf.d/10-ssl.conf:

##
## SSL settings
##

# On force l'utilisation de TLS par défaut
ssl = required

# Le chemin vers les clefs/certificats pour le chiffrement
ssl_cert = </etc/letsencrypt/live/medspx.fr/fullchain.pem
ssl_key = </etc/letsencrypt/live/medspx.fr/privkey.pem

# Paramètres Diffie-Hellman
ssl_dh = </etc/dovecot/dh.pem

# Version minimum de TLS: v1.2
ssl_min_protocol = TLSv1.2

# Liste des ciphers autorisés
ssl_cipher_list = ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH

# On indique qu'il faut   suivre l'ordre des ciphers du serveur
ssl_prefer_server_ciphers = yes

# On supprime la compression TLS (qui peut poser problème)
ssl_options = no_compression

Remise en service

Un simple systemctl restart dovecot devrait suffire. Pour vérifier que le service est fonctionnel sur le bon port, vous pouvez utiliser ss:

# ss -tlp

Annonces DNS

Il reste à faire les annonces de services sur le DNS. Pour ma part, je n'ai eu à ajouter que peu de choses: les deux lignes qui suivent...

_imaps._tcp 84600 IN SRV 0 5 993 medspx.fr.
_submissions._tcp 84600 IN SRV 0 5 465 medspx.fr.

La première concerne imaps sur le port 993, la seconde le service de soumission client mail sur le port 465. Pour ce dernier, le nom du service est submissions avec un s pour indiquer que ce service est en TLS direct.

Pensez également à supprimer les anciennes déclarations des ports qui ne sont maintenant plus accessibles.

Configuration des clients

msmtp

J'utilise mstmp pour faire remonter les messages de courrier électroniques des serveurs vers mon compte (humain) afin d'avoir des informations en cas de problème.

Voici un fichier de configuration global pour msmtp (/etc/msmtprc):

# Configuration par défaut
defaults
aliases /etc/aliases
auth on
tls on
tls_starttls off

# Définition du compte
account medspx.fr
domain medspx.fr
host medspx.fr
port 465
from jerk@medspx.fr
user jerk
password password

# Activation du compte par défaut
account default : medspx.fr

La phrase importante ici c'est tls_starttls. En effet, par défaut, lorsqu'on active TLS dans msmtp, celui-ci essaye de faire du STARTTLS. Or, nous avons du TLS implicite (par défaut). Il faut donc désactiver STARTTLS et c'est ce que fait la variable tls_starttls à off.

mutt

Pour mutt, il suffit de remplacer les url du type imap: par imaps: et smtp par smtps, pardi !

Voici un exemple de configuration (~/.muttrc):

set smtp_url = "smtps://mederic.ribreux@medspx.fr/"
set spoolfile = "imaps://medspx.fr/INBOX"
set folder = "imaps://medspx.fr/"

Attention, mutt utilise la libsasl2 pour gérer l'authentification SMTP (et bizarrement, pas pour IMAP). Or, par défaut cette dernière a besoin de modules pour gérer l'authentification en mode PLAIN. Vous devez donc installer le paquet libsasl2-modules.

Thunderbird

De ce côté, rien à signaler, il suffit de modifier les protocoles STARTTLS en SSL/TLS purs. Ça marche, y compris pour la version ESR de thunderbird !

Roundcube

J'utilise Roundcube et j'ai dû modifier l'URL de connexion pour la partie IMAP. Néanmoins, ce n'est pas suffisant. En effet, je souhaite que le traffic entre Roundcube et le serveur IMAP se fasse sur localhost et non en sortant sur le réseau. Le problème de passer par localhost, c'est que le certificat qui est utilisé par Dovecot prend en compte un CN qui est le FQDN du serveur et non localhost.

Pour contourner le problème, on peut utiliser la directive de configuration 'imap_conn_options':

$config['default_host'] = 'imaps://localhost:993';
$config['imap_conn_options'] = array(
  'ssl' => array(
      'peer_name'  => 'FQDN of server'
  ),
);

Pareil pour la partie SMTP:

$config['smtp_server'] = 'ssl://localhost';
$config['smtp_conn_options'] = array(
  'ssl' => array(
        'peer_name'  => 'FQDN of server'
  ),
);

$config['smtp_port'] = 465;

Conclusions

Ouf, c'est fini et ça semble fonctionner. Encore une fois, Exim4 est riche de fonctionnalités mais reste complexe à configurer. J'ai dû passer environ 2ou 3h de recherches pour vraiment comprendre et trouver comment faire. Et encore, je n'ai pas touché à la gestion des algos de chiffrement pour TLSv1.2. En même temps, je ne fais pas ça tous les jours...

Du côté de Dovecot, ça se passe plus facilement. Seule la génération de la conf TLS prend un peu de temps pour comprendre.

Du côté de la configuration des clients, j'ai eu aussi quelques suprises, notamment pour mutt (à cause du SASL) et pour Roundcube (ce qui m'a valu quelques bannissement par fail2ban).

Ce RFC fait quand même du bien au sysadmins de la chaîne de courrier électronique. En effet, il clarifie avec précision ce qu'il faut désormais faire. Auparavant, il subsistait un problème avec le standard de fait (donc pas un standard) du port 465. J'ai toujours refusé de le mettre en place sur ma plate-forme de courrier électronique à cause de ce manque de clarification.

Maintenant, tout est (à peu près) correct et je suis reparti pour 2 ou 3 ans de paix avec mon courrier électronique qui arrive à destination et mes clients qui communiquent maintenant uniquement sur canal chiffré.

Références

Posted mar. 16 juil. 2019 23:34:57 Tags:

Il y a quelques semaines, j'ai commencé à remarquer un phénomène étrange sur ma station de travail personnelle. A chaque démarrage à froid, le BIOS interrompait la séquence de boot en m'indiquant que des paramètres internes avaient été modifiés. J'étais alors obligé d'aller dans le BIOS, de choisir manuellement le périphérique de boot et de lancer la procédure de démarrage avant de retomber sur mon écran de Grub préferré.

Au début, je n'y ai pas trop prêté attention mais, à la longue, ça commençait à devenir pénible car j'étais sollicité à chaque démarrage. Avec le temps, j'ai essayé de corriger le problème en refaisant le tour de la configuration du BIOS. Il devait démarrer par le disque SSD qui est le périphérique de démarrage attitré.

Mais à chaque fois que je débranchait le PC (chaque fois que je l'éteinds en fait), aucun de mes paramètres n'étaient conservés. J'ai commencé à me poser d'autres questions. Encore un coup de UEFI ou de SecureBoot ? Ou alors, quelqu'un a essayé de m'implanter un module pirate ? Peut-être les chinois du FBI ?

Et puis, un détail m'a frappé, comme une évidence: l'ordinateur remettait à zéro la date du jour. A chaque démarrage de la machine, la date du jour était le 01/01/2009. Au début, je ne voyais rien car, après démarrage, cette machine utilise le protocole NTP pour synchroniser son horloge. Alors, j'ai pris mon courage à deux mains pour déterrer cette tour, enlever la poussière qui s'y était accumulée depuis plusieurs années, démonter la carte graphique pour pouvoir avoir accès à ce que je pensais être le coupable idéal: la pile de l'horloge RTC.

Voici le voltage que j'ai pu mesurer à ses bornes:

Batterie RTC HS

Verdict: à 39.6 mV, la pile est déchargée. Par bonheur, j'en avais une autre qui traînait dans mon stock et qui affichait la valeur correcte d'un peu plus de 3V. J'ai donc fait l'échange et mon problème a été résolu (attention à remettre la pile dans le bon sens, sinon ça ne marche pas).

Que retirer de cette histoire ? C'est la première fois que je vois une batterie CR2032 HS depuis le temps que je possède des ordinateurs. Ça ne m'était jamais arrivé auparavant. Ça signifie que je possède cette tour depuis longtemps. Effectivement, je l'ai achetée en 2012, ce qui fait près de 7 ans au moment de la rédaction de cet article.

Pour autant, je crois que je n'ai jamais gardé une machine aussi longtemps. C'est la machine la plus puissante de mon parc et je sais que je n'ai pas encore atteint ses limites. Je m'en sert très régulièrement pour tout un tas de travaux qui vont de compilations lourdes à de l'encodage vidéo. Et je trouve qu'elle a toujours du répondant. Serait-ce le signe que l'amélioration des performances des ordinateurs commence à stagner ? Qu'on a enfin atteint les limites ? Que les logiciels sont enfin moins consommateurs de ressources ? Que mon utilisation personnelle de cette machine est en phase avec ses capacités ? Je n'en sais rien...

... mais, sans nul doute, c'est un signe !

Posted lun. 15 juil. 2019 18:39:45 Tags:

It's been three months since we have adopted this beautiful little kitty. Her name is "Michoune" (with a french accent, of course).

Michoune 1 Michoune 2

She is very kind for a cat even if she's got some nerves. She should be approximatively 5 years old but her behaviour is much more a two years old cat because she is always playing with everything (chasing flies, hunting every cable, biting anything that rests on the floor, etc.).

The loss of mimi-pop has been very hard for us and it took me a lot of time before being able just to think about adopting a new cat. But finaly on march the 23th of the year 2019, we decided to go to the animal shelter in order to take a new cat with us. The choice had been really harsh and I believe that it took something like three hours to make a common decision.

But after all those discussions and three months at home, here she will stay with us and we are all really happy ! So, welcome Michoune...

Michoune 3 Michoune 4

Posted lun. 24 juin 2019 09:13:30 Tags:

Introduction

Il y a une activité qui occupe maintenant une bonne partie de mon temps libre et dont je n'ai pas encore parlé sur ce blog. Peut-être serait-il temps d'en faire un sujet de réflexion ? Pour lancer le sujet, parlons-donc de ma pratique de la course à pied...

Je cours depuis que je suis gamin. Pas forcément de manière assidue mais très certainement de manière régulière. Que ce soit pour le sport, pour l'amélioration de la condition physique ou pour le fun, je me lance dans les paysages les plus divers, un short et des chaussures adaptées pour profiter, à chaque fois, un nouveau voyage. J'ai toujours apprécié cette pratique au point, maintenant, d'en faire toutes les semaines depuis plusieurs années.

J'ai des phases de repos où je m'arrête complètement pendant plusieurs mois (pendant lesquels je me remet à fumer la pipe). Et puis un jour, ça me reprend, je me lance à nouveau et je parviens, à force d'essoufflements à refaire mes premiers 8 kms de l'année. Et le cycle repart...

Pourquoi ?

Qu'est-ce-que j'apprécie dans tout cet effort ? D'abord, physiquement, ça fait plutôt du bien. Comme je passe le plus clair de mon temps de travail le cul vissé sur une chaise, je ne fais vraiment pas beaucoup d'exercice physique. Or, je finis par croire, avec le temps qui passe et l'âge qui s'accumule, que le corps humain a été conçu pour réagir à un minimum de tension, de challenge physique. Pas mal de fonctions de notre corps, sans doute dans un objectif d'adaptation générale au mileu, font que le corps peut être sollicité plus que d'habitude et qu'il s'habitue à cet état.

Cet exercice physique fait aussi du bien mentalement. Quand je pars courir, je consacre surtout du temps à moi-même. Je peux m'enfermer dans une bulle de protection qui, comme tout autiste qui se respecte est une bénédiction. Effectivement, quand je cours comme un dératé, personne ne vient m'ennuyer avec son discours ou avec ses histoires. Je peux fuir la civilisation pendant toute la durée de la course. L'effort fait également que le cerveau ne peut pas se concentrer sur beaucoup de choses en même temps. On finit par oublier les problèmes, les ennuis et même qui on est (après un temps de course assez long).

Ce que j'aime dans la course, c'est l'aspect libre des choses. Tu pars en voyage pendant quelques minutes, dans l'inconnu, sans forcément de point de chute. C'est ça la vraie liberté: pas besoin de planifier, pas besoin d'un moyen de locomotion spécifique à entretenir. De plus, il ne faut pas beaucoup de matériel pour pratiquer: un short, un t-shirt, une paire de chaussettes et chaussures et c'est tout. Comme la pratique des déplacements doux, courir permet de remettre un peu de lenteur dans le paysage et d'en apprécier les détails, sans pour autant rester dans la contemplation comme lorsque je pars en randonnée.

Un sport de masse

Néanmoins, nous vivons dans un monde où la course est devenu un sport de masse et ce, depuis je dirais à peu près quarante ans. Il ne faut pas oublier qu'à la base, tout est parti de quelques types qui voulaient juste courir: un truc de base que l'homme chasseur cueilleur fait depuis toujours. Dans les années 60 je crois que tu pouvais te faire arrêter par les flics si tu courais sur la route. Les femmes n'ont été admises au marathon que vers 1967 (ça fait 50 ans) et les premiers JO qui ont accueillis les femmes dans le marathon sont ceux de 1984 ! On était loin d'un sport de masse.

Aujourd'hui, le marathon des grandes villes est devenu un évènement planifié chaque année en utilisant de plus en plus de moyens pour toujours de plus en plus de participants. Il y a tellement de monde qu'il faut temporiser les départs. L'effet de la masse de gens est visible au départ qui prend plusieurs minutes, à cause de l'inertie de la foule. Tout ça pour quoi ? Sans doute pour voir figurer son nom sur un listing de classement. Car, au final, c'est tout ce que tu obtiendras de spécifique. Rien ne t'interdit de refaire le parcours du marathon (en l'adaptant) quand tu veux, pour te permettre d'apprécier la ville (si apprécier une ville est seulement imaginable). Rien ne t'interdit de courir aussi longtemps pour en avoir les sensations physiques sur n'importe quel autre parcours.

Ce n'est pas du tout ce que je cherche quand je cours. Au contraire, je dirais que courir est une activité plutôt solitaire et en aucun cas grégaire, de par sa nature même. En effet, si tu cours, tu es en effort physique de longue durée. Ce n'est pas un temps que tu peux consacrer à essayer de "partager" des choses avec les autres. Tu es trop occupé à réguler ton souffle, comment imaginer tenir une conversation ? Par ailleurs, courir en groupe implique que tu doives t'adapter à son rythme qui sera forcément trop lent ou trop rapide pour toi. Je ne connais pas deux coureurs qui peuvent avoir le même rythme. Dans ces conditions, le partage ne semble pas très facile, pas adapté du tout. Si tu veux partager un effort physique avec quelqu'un, fait un sport collectif: c'est prévu pour. Tu dois communiquer, bouger en harmonie et partager un moment d'équipe. C'est fait pour ça. La course ? Pas du tout.

La mondialisation du phénomène amène également d'autres problèmes

D'abord, comme tout phénomène de masse, les marchands du temple ont investigué les lieux. Tout donne lieu à échange monétaire avec toute la merde du commerce qui va avec. Quand je croise des coureurs, j'ai l'impression de croiser des hommes sandwichs avec leurs couleurs chatoyantes. Je ne serais pas vraiment surpris que des néons s'allument à leur passage s'ils courraient la nuit. Et c'est vrai que plus le temps passe, plus le monde de la course pue le fric. Alors qu'à la base, c'est un truc fait pour tout le monde avec peu de moyens. Plus le temps passe, plus c'est à la mode de courir, plus les pompes coutent une blinde et durent moins de deux ans.

Si j'en crois certaines études économiques, le budget des coureurs français va chercher dans les 500€. Un demi mois de SMIC pour le sport le plus universel du monde ! Ça fait beaucoup. Dans ce budget, il y a forcément les chaussures. Le choix est hyper-large, soit-disant hyper-technique, ultra coloré et ultra-cher au final. Je ne parle pas du reste de l'équipement. La gamme est devenue ultra-détaillée. Mais, je crois que dans le budget on retrouve surtout le fric dépensé pour participer aux courses. J'avoue que ça me ferait bien mal de dépenser du fric juste pour me faire du mal à courir pendant 21 ou 42km avec des milliers d'inconnus. Si c'était gratos ou si j'étais payé pour le faire, pourquoi pas mais là, c'est se faire mal deux fois, non ?

Pourtant, j'ai participé à quelques courses officielles et j'ai toujours été choqué que les organisateurs demandent un certificat médical pour participer. D'abord, je n'ai pas que ça à foutre d'aller voir un médecin pour qu'il me fasse un papelard. En plus, ça permet à la sécurité sociale de dépenser du fric pour pas grand chose car, en règle générale, si tu veux faire une course, c'est que tu es un miminmum entraîné. De plus, ce n'est pas parce que tu as un papelard qui te dis que tu peux participer à une course que tu ne vas pas faire d'infarct au km 27. Non vraiment, payer pour courir, voilà donc une idée saugrenue !

Vous allez me dire qu'il faut bien des ressources pour organiser tout ça et c'est sans doute vrai. Mais ça n'a pas forcément d'intérêt à mon sens et dans ma pratique de la course. On pourrait faire des évènements plus coopératifs où on demanderait aux gens de participer davantage. Par exemple, ce que j'adorerais, c'est organiser la course aux déchets du marathon. Tu forme une équipe de coureurs, tu leur files un sac à chaque point de ravitaillement et leur mission est de ramasser au moins un gobelet entre chaque point de ravitaillement, après la vraie course du marathon. Tu formes 1000 coureurs de deuxième troupe et le nettoyage est assuré au même titre que la course pour ce deuxième groupe (que tu ne fais pas payer). rappelons-le, courir est un truc simple que n'importe quel humain sans trop de problèmes de santé peut faire. Il faut que ça le reste, sinon, il y aura trop de dérives et ces évènements généreront de la merde (comme tout élément où il y a trop de gens en même temps au même endroit).

Au delà de ces éléments, je finis toujours par m'interroger sur le rapport de compétition dans la société mondialisée. 10000 participants à un marathon implique 10000 compétiteurs qui s'affrontent. Pour ma part, je n'aime pas cet état d'esprit. La seule compétition que j'accepte est celle que je mène avec moi-même. Car il est bien là le truc à dépasser: soi-même. Doubler les autres c'est une chose mais se doubler soi-même, dépasser son temps, dépasser sa douleur, ses habitudes pour finir par dépasser son être, voilà le vrai défi ! Car juste après la séance où vous êtes parvenu à triompher de votre challenger, à courir plus vite que lui, vous devenez alors le nouvel adversaire, le nouveau compétiteur qu'il faudra battre lors de la prochaine course.

La course libre

Alors, qu'est-ce-que je fais pour contrer tout ça, que fais-je pour mettre en adéquation ma pratique avec mes engagements ? J'adopte juste un regard simple et orienté sur ce qui me plaît. J'appelle ça, la course libre. Le truc ultime d'un être humain qui court, comme ça, simplement pour lui, sans stress, sans compétition, sans trop de technique, sans défi, sans challenge mais toujours dans l'effort.

Quelle tenue ?

Ça se traduit par exemple dans ma tenue qui est souvent la même: un t-shirt de base, un short (été comme hiver), des chaussettes de course légères et des chaussures de trail. Dans la pratique, je réutilise ces vêtements pendant toute la semaine de course (donc 3 fois les mêmes). Cela me permet d'éviter de faire cinquante-mille lessives et puis, 45 minutes d'efforts ne viennent pas forcément salir la tenue au point de ne plus pouvoir la remettre après. J'utilise des vêtements de base qui me servent aussi pour autre chose, des trucs qu'on m'a offert bien souvent. Ca ne sert à rien de mettre des milliers d'euros dans une tenue, juste pour courir librement là où bon nous semble.

Toutefois, il y a un élément sur lequel je ne lésine pas: les pieds. Mes chaussures et mes chaussettes coutent donc assez cher. J'ai bien noté une différence technique entre les trucs premiers prix et ce que j'ai fini par trouver. Car j'ai un gros problème qui peut, s'il n'est pas géré, finir par me blesser: j'ai des ampoules qui se forment assez rapidement. Après une seule séance, il est possible que du sang se soit déjà accumulé dans une poche (surtout sur mon pied droit) de liquide. Après 3 séances, c'est insupportable, je ne peux plus courir du tout. J'ai essayé pendant des années de trouver la formule idéale pour pallier à ce problème. Ma solution imparfaite consiste à trouver la bonne chaussure de sport. Elle doit être légère, résistante, offrir une bonne base d'amorti et surtout, sa forme doit limiter au maximum les zones de frottements sur les pieds. Si en plus elle peut durer plusieurs années et servir pendant plus de 3000 kilomètres (à peu près trois ans de course), c'est mieux. Après, il faut qu'elle soit sobre et je bannis le fluo ou les couleurs vives car je ne fais pas de pub en courant, même si le fabricant qui réalise ces chaussures qui me correspondent bien est un réel bienfaiteur. Mes chaussures sont donc noires, des chaussures de trail, discrètes, qui sèchent vite, qui ne me donnent pas trop d'ampoules. Un truc qui m'a aidé à trouver la bonne paire consiste à éviter les modèles "one-shot". En règle générale dans la société capitaliste, on se soucie surtout de faire des trucs faciles à acheter et qui brillent pour pouvoir en vendre fréquemment le plus possible, au lieu de faire un produit techniquement performant, robuste, qui peut se réparer et durer dans le temps, même si ce dernier coûte cher. Néanmoins, aussi capitaliste que soit notre société, vendre de la merde, ça finit par se voir. Donc, pour choisir une bonne paire de chaussure, il faut trouver celle qui n'est pas remise en cause tout le temps, celle qui est un bon modèle et qui n'est pas produite pour une seule saison. Si vous regardez ce que les fabricants de chaussures de sport font, c'est surtout des chaussures qui sont produites pendant une seule saison. Tous les ans, il y a une masse incroyable de paires de pompes qui ne dépassent une seule année de fabrication. Mais dans le lot, il y a des modèles qui restent pendant plus de 10 ans. Je vous invite à choisir votre paire dans ces modèles.

Pour compléter la partie sur les pieds, j'utilise aussi des chaussettes de trail, résistantes et fermes. Elles me permettent de réduire les frottements sur les pieds et elles se révèlent un bon investissement. Leur durée de vie dépasse les 5 ans, ce qui ne sera jamais le cas pour les chaussettes classiques en coton. J'en utilise une paire qui a un trou au niveau de la base du pied, près de la voute plantaire. Enfin, parfois, j'utilise de la crème NOK, surtout en début de saison. Ça a une action assez réelle même s'il faut être assidu dans son application.

Pour résumer, avec ces éléments qui, effectivement coûtent assez cher, j'ai moins de problème et je peux partir comme bon me semble. Néanmoins, il y a toujours une phase où des ampoules se forment, se percent, du sang s'accumule, ça fait mal... mais à la fin, la peau s'épaissie sur ces parties et la corne s'accumule. A partir de cet instant, je sais que je n'aurai plus de problème jusqu'à la fin de la saison.

Pas de montre.

Régulièrement, je pars sans montre et je refuse de mesurer mon temps de parcours. J'ai remarqué que ça améliore sensiblement ma vitesse car , sans repère temporel, on est plus enclin à suivre son propre rythme plutôt que l'objectif de temps fixé au départ. Et puis, regarder une montre, c'est chiant quand on cours vite et qu'on doit faire attention à l'environnement immédiat.

Sans repère de temps, on court plus avec les sensations du corps qui prend le pas sur le cerveau. La montre apporterait trop de rationalité à l'exercice, obligeant l'esprit à se focaliser sur le temps.

Néanmoins, j'avoue que parfois, je chronomètre mon temps. Ne serait-ce que pour savoir si j'ai progressé dans mes performances personnelles, pour juger de mon état de fatigue physique.

Mais en aucun cas la montre ne peut constituer une règle systématique. Cela devient une trop grande contrainte sur la pratique et on finit par courir contre la montre plutôt que contre soi-même.

Pas d'eau, pas de ravitaillement.

C'est l'autre défi que j'ai commencé à aborder depuis quelques années, par souci de simplicité. Quand je pars courir, j'aime ne rien avoir avec moi: pas de montre, pas de clé, pas de truc superflu. Aussi, la nourriture et l'eau font également partie des trucs superflus.

C'est très inconfortable d'emmener ne serait-ce qu'un demi-litre d'eau, soit à la main (donc il faut le porter et la main finit par transpirer à fond; il faut donc changer de main régulièrement), soit avec un camelback (qui te permet de perdre en eau de transpiration du dos le volume d'eau qu'il transporte).

J'avoue que quand il fait chaud, un peu d'eau à mi-parcours ou vers la fin ne serait pas de refus, surtout lorsque je suis en sortie longue (soit 16km). Lorsque du blanc commence à s'accumuler sur tes lèvres, c'est le signe du début d'une déshydratation. Mais, avec le temps, je sais que cette distance peut tout à fait se faire sans boire et, ainsi, je suis plus serein par rapport au manque d'eau.

Par ailleurs, je me force à boire beaucoup avant le départ et à surtout ne pas uriner pendant la course. Au bout de 5 minutes, ma vessie est pleine à craquer mais au bout de 15 minutes, elle est vide et toute l'eau a été recyclée dans le corps. Ça permet de tenir plus longtemps.

Quant au ravitaillement, je crois qu'il ne sert à rien sur une distance inférieure à 16km. J'ai même fait quelques 20km sans rien avaler pendant la course et ce, sans faire d'hypoglycémie. Là encore, le corps s'habitue. Mon premier 16km sans ravitaillement s'est effectivement mal passé car j'étais en manque de jus sur les 2 derniers kilomètres. Mais depuis cette seule dat, je n'ai plus jamais eu aucun problème pour terminer une course.

Mon heure de sortie est généralement le soir, vers 18h-18h30. C'est là que j'ai le plus d'énergie de toute la journée. Mon estomac a fini la digestion donc plus de lourdeur dans le ventre et toute l'énergie est disponible pour le corps. J'ai déjà essayé d'autres périodes mais à chaque fois, c'était vraiment plus difficile.

La course est une promenade

Quand je pars courir, j'aborde la course non pas comme un défi, comme un challenge, comme une piste, comme un temps à dépasser ou une performance à atteindre. Au contraire, je me dis que je pars en ballade.

Car, on a tendance à l'oublier mais la course ce n'est qu'une marche rapide. Prise dans ce contexte, on dédramatise complètement l'action. De fait, le sport devient plus doux, plus humain, moins machinal et plus basé sur des sensations qu'une abstraction de temps.

Donc, quand je pars en sortie longue, je vais simplement me ballader. Certe le territoire est connu car déjà parcouru plus d'une centaine de fois mais, il en reste la sensation de départ d'un bon moment plutot que la direction d'un effort, d'une souffrance.

Et croyez-moi, ce simple point de vue change tout. Je crois même qu'il me permet d'être plus performant, de courir plus vite car libéré de tout objectif de réussite. Ça change complètement la donne...

Courir sous la pluie.

S'il y a bien un environnement que j'affectionne lorsque je cours, c'est la pluie. A quel bonheur quand tu pars courir sous la pluie, quand le temps est frais voire froid ! C'est tout simplement un régal:

  • D'un seul coup, il n'y a plus personne sur ton chemin pour te barrer la route, te ralentir ou que tu dois dépasser ou prévenir de ta présence. Le circuit est plus fluide, plus simple, sans détour et sans devoir porter une attention constante.
  • Comme le terrain est moins favorable, tu ne croises plus les types qui se tirent la bourre. Il ne reste que les vrais coureurs, sans couleurs, sans néons; ceux qui sont la réalité de la régularité sans faille.
  • Plus de pluie, plus d'eau et moins d'appareils électroniques dans l'espace public. Stop la musique des autres, terminés les jukeboxes qui m'imposent leur musique de merde.
  • Moins de transpiration, de chaleur et la course devient beaucoup plus facile.
  • Le vent sur le corps te donne un nouveau défi à affronter mais aussi un coup de pouce lorsqu'il te suit.

Le seul inconvénient c'est que tes pieds sont mouillés et que tu auras forcément une ampoule à la fin. Mais ce sacrifice et cette petite souffrance en vaut largement la peine. Si tout pouvait être tout le temps comme quand il pleut, le monde serait plus calme, plus serein, plus vivable et vivant, à la portée de tous, dans la douceur permise par les relations quotidiennes plus distantes.

Conclusions

Revenons donc aux sources du mouvement ! La course peut être un sport de masse sans tous les défauts engendrés par la trop grande force du trop grand nombre. Il suffit de la prendre pour ce qu'elle est: un sport simple et accessible, un sport qui libère le corps et l'esprit.

Pas besoin de budget, pas besoin de beaucoup de temps, pas besoin de performances, de niveau, de temps, de montre, de smartphone, de groupe, de licence, de certicicat médical, de comité de course, de piste, de compagnon de course, de drapeau, de point de départ, de point d'arrivée.

Simplement, un short, des chaussures, des chaussettes, un t-shirt et te voilà parti en ballade pour là où tu voudras bien aller...

Posted mer. 24 avril 2019 13:02:30

Oui, moi aussi je fais du #trashtag, à ma manière !

Le jeu consiste à partir à pied de chez soi pour faire une petite promenade dans la campagne. Il faut partir avec un sac assez solide et ramasser tous les déchets croisés sur le chemin lors de la promenade. Quand le sac est plein, on peut revenir à la maison et prendre une photo avant de benner tout ça dans les conteneurs de recyclages publics.

Voici, le résultat d'une petite ballade dans la campagne à partir de chez moi le 24/11/2018:

Un sac remplit de détritus

J'ai juste dû marcher 30 minutes pour remplir le sac à rabord.

Le même chemin une quinzaine plus tard mais au bout d'une 1h30:

Un autre sac remplit de détritus

C'est un peu mieux ! Même s'il y a encore du travail. Dans tous les cas, le jeu est sympathique et on a l'impression de servir à quelque-chose. Sans doute un erzatz de service public commun de nettoyage de l'espace public.

Mais au fait, pourquoi nettoyer pour les autres ? Pour pleins de raisons, chacun a les siennes. Voici les miennes:

  • Les hommes sont faibles. Plus un lieu est sale, plus ils pensent qu'ils peuvent abuser de lui. A l'inverse, quand c'est nickel, il y a une plus grande chance que ça le reste.
  • La Nature n'en peut plus de gérer nos déchets. On trouve du plastique partout dans la chaîne alimentaire. La mer déborde de merde de déchets. Il y a même un continent qui s'est formé à partir de cette merde.
  • Quand tu vois ce qu'il y a dans les estomacs des oiseaux marins, tu pleures car si tu as un brin d'intelligence, tu te doutes bien que toi-même ou ta descendance suit le même chemin et que tôt ou tard, tu finiras toi aussi avec le bide plein de plastoc.
  • C'est un vrai travail d'autiste: on passe d'un état sale à un état propre complet. Le passe-temps est très valorisant, il n'y a qu'à voir le buzz avec #trashtag !
  • Quand un poivreau laisse une bouteille en verre dans la Nature, des rongeurs finissent par s'y noyer. Moins de rongeurs, c'est plus d'insectes nuisibles et moins de diversité dans la Nature. Donc il faut aussi ramasser les bouteilles en verre. Surtout que ce dernier se recycle.
  • C'est plus efficace que de faire la morale aux gens crades. Quand ils savent que d'autres se bougent pour nettoyer leur merde, ça les incite à se poser des questions sur leur comportement. Ce n'est pas garanti mais au moins, ça ne participe pas à renforcer leur action néfaste en les engueulants (les gens crades sont généralement assez susceptibles).
  • Ça fait moins de travail pour les agents publics chargés de nettoyer les chemins. Potentiellement, ça les libère pour des actions plus valorisantes et d'une plus grande portée comme faire de la prévention ou passer plus de temps à sécuriser ou à restaurer des balisages.
  • Ça montre l'exemple pour les autres pays qui ont une politique plus laxiste sur les déchets.

Voilà, avec tout ça, le mieux que vous puissiez faire c'est de ramasser librement des déchets sur les chemins. Je vous garantie que ça fait du bien...

Posted sam. 06 avril 2019 12:18:30

Introduction

Si vous avez lu ma page dédiée à mon infrastructure de sauvegarde, vous savez que j'utilise Borg et que mon installation est particulière.

En effet, le serveur de sauvegarde n'est pas relié directement au réseau local (qui est en Wifi chez moi) mais relié en ethernet à une station de travail principale. Cette dernière héberge le contenu le plus volumineux et relier le serveur de sauvegarde directement par un câble réseau me permet de disposer d'un débit de l'ordre du Gigabits/seconde soit près de 125Mo/seconde. Le Wifi ne monterait qu'à 54MBits/s soit 6,5Mo/seconde, près de 20 fois plus lent.

Donc, ma station de travail qui est également reliée au Wifi sert de passerelle Wifi au serveur de sauvegarde. Dans un sens j'ai le meilleur des deux mondes car les clients à sauvegarder du réseau local peuvent tous attaquer le serveur local via la station de travail.

Néanmoins depuis près d'un an, je loue un serveur dans le "cloud" et j'ai besoin de récupérer une partie de son contenu pour faire une sauvegarde. Or, il est difficile pour ce serveur de franchir les 2 NAT.

J'ai testé l'utilisation de SSHFS et je dois dire que, même si ça marchait, je n'étais pas du tout satisfait des performances.

Au final, après avoir déployé Wireguard sur toutes mes machines, je me suis demandé s'il était simple de passer par le VPN pour faire la sauvegarde du client "cloud". Cet article montre un élément d'explication de la méthode que j'ai employée avec succès.

Un rappel du schéma d'infrastructure de backup

Voici un petit schéma de comment le tout est organisé:

                                                        __   _
                                                      _(  )_( )_
                                     Wi-Fi           (_   _    _)
        +--------+                   .....             (_) (__)
        |        |                  .......            Internet
        |        |                 .  ...  .            ^   ^
        +--------+                     .                |   |
        +--------+                  +------+            |   |
          Laptop ^ - - - - - - - - >|      |<-----------+   |
                                    +------+                |
                                     Router                 | 
                                       ^                    |
                                       |                    |
                                                            |
                                       |                    |
 +-------+        +-------+                            +----+--+
 |       |  Eth   |       |            |               |       |
 |       +<------>+       +< - - - - - +               |       |
 |       |        |       |                            |       |
 |       |        |       |                            |       |
 +-------+        +-------+                            +-------+
BackupServer      WorkStation                         CloudServer
  • Workstation fait du NAT pour BackupServer.
  • Router fait du NAT pour le réseau local vers Internet.

Configuration du VPN wireguard

Vous allez me dire que Wireguard pour écrire derrière un double NAT c'est un peu overkilling. Vous n'aurez sans doute pas tort mais, à bien y réfléchir, ce n'est pas si compliqué à faire et, dans tous les cas, cela demande bien moins de compétences réseau de bas niveau que d'autres solutions.

Ce qui est bien dans Wireguard, c'est qu'il suffit de peu pour faire en sorte que les clients puissent se parler les uns les autres et ce, peu importe le réseau qui est en dessous. A partir du moment où un client arrive à sortir sur Internet, il fait partie du VPN.

Le principe que j'ai suivi est donné dans l'exemple de passerelle Wireguard que j'ai trouvé sur la mailing list du logiciel.

Globalement il consiste à disposer d'une machine qui servira de passerelle à l'ensemble du VPN. Cette dernière connaît tous les clients potentiels et elle dispose de toutes les clefs publiques des clients du VPN. Chaque client ne connaît que la passerelle et accepte tout ce qui vient du sous-réseau du VPN (la variable AllowedIPs de la passerelle est le sous-réseau Wireguard). De cette manière, la passerelle peut transmettre n'importe quel paquet venu d'un client A vers un client B.

Bien entendu, la passerelle sait faire de l'IP Forwarding.

Dans mon cas, la passerelle est le serveur "Cloud". De cette manière, elle peut facilement atteindre le serveur de sauvegarde via le VPN car Wireguard traverse tous les NAT. L'intérêt de passer par l'interface réseau du VPN (wg0) est que borg ou ssh peuvent l'utiliser directement pour atteindre la machine cible sans avoir à se préocupper de la gestion réseau derrière.

Configuration nftables fonctionnelle

Mais avant de pouvoir faire passer Wireguard, il faut encore configurer comme il se doit la station de travail et notamment activer le NAT de manière sécurisée. C'est sur ce point que j'ai dû bataillé ferme et que j'ai pris le temps de comprendre comment ça fonctionnait.

Globalement, il faut:

  • Activer l'ip forwarding au niveau de la station de travail.
  • Mettre en place du NAT entre le serveur de sauvegarde et la station de travail vers le LAN et Internet.
  • Faire en sorte que la station de travail puisse faire partie du VPN.

L'IP forwarding s'active en indiquant la ligne suivante dans /etc/systctl.conf:

net.ipv4.ip_forward=1

Pour le reste, j'ai utilisé nftables qui est l'outil de configuration de netfilter recommendé dans Debian. Voici mon fichier de configuration que j'ai détaillé:

#!/usr/sbin/nft -f

# On vide la table
flush ruleset

# Gestion de la table ip (v4)
table ip filter {
  # On scanne ce qui passe en entrée
  chain input {
    type filter hook input priority 0; policy drop;

    # On autorise les connexions est déjà acceptées
    ct state {established, related} accept

    # On jete ce qui est invalide
    ct state invalid drop

    # On accepte ce qui vient de loopback
    iifname lo accept

    # On accepte ce qui vient de Wireguard
    iifname wg0 accept

    # On accepte le trafic qui vient de la carte Ethernet
    # C'est tout ce qui vient du serveur de sauvegarde.
    iifname eno1 accept

    # On permet le ping
    ip protocol icmp accept comment "Accept all icmp types"

    # On accepte tout ce qui vient du réseau local
    ip saddr 192.168.0.0/24 accept

    # On rejete le reste    
    counter log prefix "Rejecting input " level warn reject
  }

  # Chaîne qui sert à faire le forwarding
  chain forward {
    type filter hook forward priority 0; policy accept;
    # Règles d'acceptation du forward
    ## ça vient du réseau ethernet et ça veut sortir sur le wifi
    iifname "eno1" oifname "wlp6s0" accept

    ## ça vient du réseau Wifi et ça veut rentrer sur ethernet
    ## ON accepte ce qui est en relation ou établi et ce qui vient
    ## du LAN Wifi.
    iifname "wlp6s0" oifname "eno1" ct state established accept
    iifname "wlp6s0" oifname "eno1" ct state related accept
    iifname "wlp6s0" oifname "eno1" ip saddr 192.168.0.0/24 accept

    ## Sinon, on jette
    iifname "wlp6s0" oifname "eno1" drop
    counter log prefix "rejecting forward shit " level warn
  }

  # Chaîne de sortie (non filtrée)
  chain output {
    type filter hook output priority 0; policy accept;
  }

}

# Gestion du NAT via nftables
table ip nat {
  # Globalement, on accepte tout
  chain prerouting {
    type nat hook prerouting priority 0; policy accept;
  }

  chain input {
    type nat hook input priority 0; policy accept;
  }

  chain output {
    type nat hook output priority 0; policy accept;
  }
  # Mais au moment du postrouting, on active le masquerade
  # sur l'interface Wi-fi de la station de travail
  chain postrouting {
    type nat hook postrouting priority 0; policy accept;
    oifname "wlp6s0" masquerade
    # Et on compte les paquets pour voir ce qui passe.
    counter log prefix "nat postrouting " level warn
  }
}

Configuration du client à sauvegarder dans le cloud

Enfin, pour le client final, il reste à configurer certains points:

  • borgmatic.
  • la clef SSH vers le dépôt Borg.

Mais tout est déjà décrit dans la documentation générale.

Conclusions

Voilà, grâce à ce dispositif, je peux utiliser borgbackup sur un client dans le "cloud" qui peut écrire directement sur mon serveur de sauvegarde, situé derrière 2 réseaux IP nattés. Les performances sont bonnes et grâce à la déduplication et au fait que le client conserve les blocs de fichiers en cache, je suis passé d'une sauvegarde de près d'une heure via SSHFS à quelques secondes via Wireguard. C'est vraiment impressionnant !

En conclusion, Wireguard c'est bien, mangez-en...

Posted mar. 26 févr. 2019 10:20:45 Tags: