Jekyll2024-01-12T23:39:35+01:00http://172.16.255.10:4000/feed.xmlQuentin DemoulièreMon blog personnel tout simplement. Welcome at 127.0.0.1. Copyleft ® 2013 and powered by Jekyll.
Authentification passwordless sur Kali Linux avec FIDO U2F et la yubikey 52024-01-12T08:00:00+01:002024-01-12T08:00:00+01:00http://172.16.255.10:4000/sysadmin/2024/01/12/pam-u2f<h2 id="i-introduction">I. Introduction</h2>
<p style="text-align: justify;">Cela fait plusieurs années que j’utilise une yubikey pour m’authentifier sur mes PC personnels sous GNU/Linux avec la méthode “Challenge-Response” propre à yubico reposant sur HMAC-SHA1.</p>
<p style="text-align: justify;">Sur ma machine actuelle tournant sur Kali Linux, j’ai décidé de mettre en place une authentification “passwordless” utilisant la norme ouverte FIDO U2F. J’ai recherché si une implémentation de FIDO 2 existait pour PAM. À priori, c’est dans les cartons, mais cela reste encore un projet en cours de développement.</p>
<h2 id="ii-u2f-et-pam">II. U2F et PAM</h2>
<p style="text-align: justify;">Comment fonctionne, dans les grands principes, l’authentification U2F avec la yubikey sur le système GNU/Linux ?</p>
<ol>
<li>
<p>Grâce à la commande pamu2fcfg, une paire de clés publique/privée est générée. La clé publique (associée à un utilisateur précis) sera publiée dans un fichier de configuration présent dans le répertoire personnel de l’utilisateur (/home/bilbo/.config/Yubico/u2f_keys) sur le système GNU/Linux. La clé privée (associée au même utilisateur) sera conservée sur la clé de sécurité physique USB.</p>
</li>
<li>
<p>Le système d’exploitation envoie un challenge concernant l’utilisateur qui souhaite s’authentifier à la clé de sécurité matérielle via USB.</p>
</li>
<li>
<p>La clé de sécurité signe ce challenge à l’aide de la clé privée qu’elle possède.</p>
</li>
<li>
<p>Le système d’exploitation va alors vérifier le challenge signé à l’aide de la clé publique qui a été associée précédemment à l’utilisateur concerné (l’OS assurera également d’autres contrôles permettant d’éviter les attaques MITM ou par rejeu).</p>
</li>
<li>
<p>L’utilisateur concerné peut ensuite finaliser l’authentification U2F en appuyant sur la touche prévue à cet effet sur la clé de sécurité physique.</p>
</li>
</ol>
<h2 id="ii-mise-en-oeuvre">II. Mise en oeuvre</h2>
<p style="text-align: justify;">Installer les paquets permettant à PAM de prendre en compte l’authentification U2F mais également l’outil de configuration lié à cette norme.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bilbo@comte:~$</span><span class="w"> </span><span class="nb">sudo </span>apt-get <span class="nb">install </span>pamu2fcfg libpam-u2f</code></pre></figure>
<p style="text-align: justify;">Insérer la yubikey et vérifier si celle-ci est bien compatible U2F (il n’y a normalement aucun problème).</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bilbo@comte:~$</span><span class="w"> </span>lsusb | <span class="nb">grep </span>U2F
<span class="go">Bus 003 Device 008: ID 2130:9147 Yubico.com Yubikey 4/5 OTP+U2F+CCID</span></code></pre></figure>
<p style="text-align: justify;">Générer un fichier de configuration pour l’utilisateur concerné par l’authentification “passwordless”</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bilbo@comte:~$</span><span class="w"> </span>pamu2fcfg <span class="o">>></span> ~/.config/Yubico/u2f_keys</code></pre></figure>
<p style="text-align: justify;">Modifier le fichier de configuration PAM lié au gestionnaire de sessions de la distribution GNU/Linux utilisée (ici lightdm). La ligne importante à ajouter est : <strong>auth sufficient pam_u2f.so</strong>. Elle se place en amont de la ligne concernant l’authentification par mot de passe.</p>
<p style="text-align: justify;">L’utilisation de la méthode sufficient permet de dire que ce type d’authentification (ici U2F) n’est pas obligatoire et qu’en cas d’absence ou d’échec lié à U2F, il sera tout de même possible d’utiliser un mot de passe traditionnel.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bilbo@comte:~$</span><span class="w"> </span>sudoedit /etc/pam.d/lightdm
<span class="gp">#</span>%PAM-1.0
<span class="go">
auth requisite pam_nologin.so
session required pam_env.so readenv=1
session required pam_env.so readenv=1 envfile=/etc/default/locale
auth sufficient pam_u2f.so
</span><span class="c">.....</span></code></pre></figure>
<p style="text-align: justify;">Il suffit ensuite de fermer la session et de se réauthentifier. Entrer l’identifiant, insérer la yubikey, appuyer sur le touche “y” et enjoy. :D</p>
<h2 id="iii-conclusion">III. Conclusion</h2>
<p style="text-align: justify;">L’authentification U2F avec une yubikey et PAM est relativement triviale à mettre en place. Si vous souhaitez l’étendre à l’usage de sudo par exemple, il faudra ajouter la même ligne spécifique dans le fichier de configuration PAM correspondant (/etc/pam.d/sudo).</p>
<p style="text-align: justify;">En termes de robustesse, Challenge-Response et U2F se valent mais FIDO U2F a l’avantage d’être une norme ouverte et un standard compatible avec n’importe quel type de clé de sécurité matérielle quand l’authentification “Challenge-Response” reste spécifique à la yubikey.</p>
<p style="text-align: justify;">FIDO 2 étant le remplaçant de U2F, j’attends avec impatience l’intégration de cette norme au niveau du service d’authentification PAM de façon stable.</p>
<h2 id="iv-sources">IV. Sources</h2>
<p><a href="https://wiki.debian.org/Security/U2F">https://wiki.debian.org/Security/U2F</a></p>
<p><a href="https://wiki.gentoo.org/wiki/PAM/U2F">https://wiki.gentoo.org/wiki/PAM/U2F</a></p>
<p><a href="https://github.com/WiSECURE/pam-fido2">https://github.com/WiSECURE/pam-fido2</a></p>I. IntroductionConfiguration d’une connexion VPN respectueuse de la neutralité du net pour l’ensemble de mes terminaux2023-09-15T01:00:00+02:002023-09-15T01:00:00+02:00http://172.16.255.10:4000/netadmin/2023/09/15/vpn-fdn<h2 id="i-expression-des-besoins">I. Expression des besoins</h2>
<p style="text-align: justify;">Je dispose d’un abonnement VPN auprès d’un FAI associatif. Grâce à cet accès qui respecte la neutralité du net, je possède une adresse IPv4 publique, un bloc d’adresses IPv6 globales en /48.</p>
<p style="text-align: justify;">Le problème s’avère être la diffusion d’une seule configuration à disposition de l’adhérent. Ainsi, si l’on fait le choix de la mettre en place sur son ordinateur, on monopolise cet accès pour un seul et unique équipement. Impossible de l’utiliser simultanément sur un smartphone et un autre PC en même temps.</p>
<p style="text-align: justify;">J’ai donc décidé de remédier à ce problème en louant un VPS pour quelques euros par mois. Ce VPS servira de relais entre mes différents clients VPN et la connexion VPN offerte par mon FAI associatif. Cela me permettra relativement facilement d’exploiter ce service pour l’ensemble des périphériques à ma disposition.</p>
<h2 id="ii-prérequis">II. Prérequis</h2>
<ul style="text-align: justify;">
<li>Un VPS avec Debian 12 disposant d’une adresse IPv4 publique, d’une adresse IPv6 globale.</li>
<li>Le paquet openvpn installé sur le VPS.</li>
<li>Les fichiers de configuration clients pour la connexion VPN vers le serveur du FAI associatif.</li>
<li>Activation du routage, utilisation d’iproute2, de netfilter, et du routage PBR sur le VPS.</li>
<li>Un client OpenVPN sur les terminaux.</li>
</ul>
<h2 id="iii-schéma-réseau-logique-de-larchitecture-proposée">III. Schéma réseau logique de l’architecture proposée</h2>
<p><img src="https://quentin.demouliere.eu/data/images/vpnfdn.png" alt="VPN FDN VPS" /></p>
<h2 id="iv-mise-en-oeuvre-technique">IV. Mise en oeuvre technique</h2>
<p style="text-align: justify;">Sur le papier l’idée semble plutôt simple :</p>
<ul style="text-align: justify;">
<li>Utilisation d’un VPS avec OpenVPN et enjoy.</li>
</ul>
<p style="text-align: justify;">En réalité, quelques éléments importants doivent être pris en compte :</p>
<ul style="text-align: justify;">
<li>Tout le trafic émis et reçu par le serveur VPS doit passer par la carte réseau (ens3) classique de la machine et non pas par le tunnel VPN (tun0).</li>
<li>À contrario, le trafic correspondant aux clients devra être routé dans le tunnel VPN à destination du FAI associatif afin d’utiliser l’adresse IPv4 publique qui m’a été assignée.</li>
</ul>
<p style="text-align: justify;">C’est là que la notion de routage basé sur les stratégies (PBR) intervient. Contrairement au routage statique traditionnel qui se base sur l’adresse IP de destination du paquet, le routage PBR est une technique de routage basée sur des filtres particuliers supplémentaires. Ainsi, il est possible de définir une stratégie de routage en fonction de paramètres spécifiques tels que les adresses IP sources, les ports, la taille du paquet, etc.</p>
<h3 id="a-configuration-de-la-connexion-vpn-cliente-sur-le-vps-vers-le-fai-associatif">A. Configuration de la connexion VPN cliente sur le VPS vers le FAI associatif</h3>
<p style="text-align: justify;">Tout d’abord, il est nécessaire d’installer les paquets indispensables sur le VPS Debian 12.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:~$</span><span class="w"> </span><span class="nb">sudo </span>apt <span class="nb">install </span>openvpn tcpdump htop tmux easy-rsa</code></pre></figure>
<p style="text-align: justify;">Puis, il faut se déplacer dans le répertoire <em>/etc/openvpn/client/</em> et passer à la configuration de la connexion vers le serveur VPN du FAI associatif.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:~$</span><span class="w"> </span><span class="nb">ls</span> /etc/openvpn/client</code></pre></figure>
<p style="text-align: justify;">Nous récupérons le certificat X509 de l’autorité de certification du FAI associatif.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:/etc/openvpn/client$</span><span class="w"> </span>wget <span class="nt">--no-check-certificate</span> https://www.fdn.fr/ca-vpn-fdn.crt</code></pre></figure>
<p style="text-align: justify;">Nous définissons ensuite un nouveau fichier contenant le login et le mot de passe nous permettant de nous authentifier sur le serveur OpenVPN du FAI associatif.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:etc/openvpn/client$</span><span class="w"> </span>vim auth-vpn.conf</code></pre></figure>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>bram.moolenaar@fdn.fr
FREEasinfreedom
</code></pre></div></div>
<p style="text-align: justify;">Enfin, nous définissons un fichier de configuration client.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:etc/openvpn/client$</span><span class="w"> </span>vim fdn.conf</code></pre></figure>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># C'est nous qui prenons l'initiative de nous connecter au serveur.
client
# On route de l'IP, on ne fait pas de l'ethernet.
dev tun
# Certains réseaux ont en fait une MTU bien inférieure à 1450. Dire aux connexions
# TCP d'être très conservatives, pour que ça marche plus ou moins partout.
#mssfix 1300
# En UDP, on peut s'assurer que ça passe de toutes façons en fragmentant au besoin
# quand ça dépasse.
# fragment 1300
# Idéalement, ça devrait être détecté tout seul, mais c'est loin de toujours fonctionner...
# mtu-disc yes
# Ne pas utiliser un port local statique, on est client de toutes façons.
nobind
# Il est préférable d'utiliser udp, le résultat fonctionne mieux. Il est
# cependant notable que les restrictions d'accès Internet laissent souvent
# plus facilement passer tcp. Essayer donc udp, et seulement s'il ne fonctionne
# pas, essayer tcp.
server-poll-timeout 3
# Les adresses des serveurs.
<connection>
remote vpn.fdn.fr 1194
explicit-exit-notify
</connection>
<connection>
remote vpn-rw.fdn.fr 53
explicit-exit-notify
</connection>
<connection>
remote vpn.fdn.fr 1194 tcp
</connection>
<connection>
remote vpn-rw.fdn.fr 80 tcp
</connection>
<connection>
remote vpn-rw.fdn.fr 443 tcp
</connection>
<connection>
remote vpn-rw.fdn.fr 993 tcp
</connection>
<connection>
remote vpn-rw.fdn.fr 22 tcp
</connection>
# Éventuellement, on peut avoir besoin de passer par un proxy http, décommenter cette ligne en mettant l'adresse et le port du proxy.
#http-proxy 192.0.2.1 8080
# Pour windows: utiliser route.exe.
#route-method exe
# Attendre un peu avant d'ajouter les routes.
route-delay 2
# Garder la clé en mémoire, pour ne pas avoir besoin de la relire lors d'un
# redémarrage.
persist-key
# On peut éventuellement ne pas tuer l'interface du tunnel lors d'un redémarrage, mais cela pose problème pour
# résoudre le nom de domaine du serveur si les résolutions DNS passent par le VPN, et aussi si au redémarrage
# on change de serveur (changement de passerelle).
#persist-tun
# Faire passer tout le trafic via le VPN:
#redirect-gateway def1
# Mais pas le trafic local:
#route 10.0.0.0 255.0.0.0 net_gateway
#route 172.16.0.0 255.240.0.0 net_gateway
#route 192.168.0.0 255.255.0.0 net_gateway
# Ajouter éventuellement d'autres routes locales, par exemple vers votre cache DNS
# Activer IPv6
tun-ipv6
# et faire passer tout le trafic IPv6 via le VPN:
#route-ipv6 ::/1
#route-ipv6 8000::/1
# On peut aussi vouloir plutôt router seulement quelques destinations, par
# exemple ici tout Gitoyen:
#route 80.67.160.0 255.255.224.0
# Envoyer un login et un mot de passe. Pour éviter de taper à la main login
# et mot de passe, vous pouvez ajouter à droite de "auth-user-pass" le nom d'un
# fichier contenant ces deux informations, une par ligne.
#auth-user-pass
auth-user-pass /etc/openvpn/client/auth-vpn.conf
# Un minimum de debug, c'est toujours bien.
verb 3
# Certificat permettant de vérifier que c'est bien à FDN que
# l'on se connecte et donc à qui on donne notre mot de passe.
verify-x509-name *.fdn.fr name
<ca>
-----BEGIN CERTIFICATE-----
MIIFGTCCAwGgAwIBAgIEWgh7mjANBgkqhkiG9w0BAQsFADAsMQswCQYDVQQGEwJG
UjEMMAoGA1UEChMDRkROMQ8wDQYDVQQDEwZDQSBGRE4wHhcNMTcxMTEyMTY0OTMx
WhcNMzcwMTExMTY0OTQzWjAsMQswCQYDVQQGEwJGUjEMMAoGA1UEChMDRkROMQ8w
DQYDVQQDEwZDQSBGRE4wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC/
kZzJVsN4vpK7phHW7sX4UpJ1bEd1BveKBATiMTDIOY8ioVv7tAmNOSTABBi8KYzS
LmflAVgsMGh1JI4+b5O4ZN1DKjKp9WAkJZvotsmHnCYsKBhoYc4JqkZQgG2s7zOm
b7eigEWZQf0F5PIaNUzT2nZZlIjxnv7DiAI+lu46qWQfu09IAca4DyN3ViFmlv03
PD4QpTqdungSWCr2gv3VOVF3yX1+b/P4kX7oWae+U2XFL9hYDUuWaFFdWCTzSRvv
JV7QMSflicb7fCRKC6E2r8x7igxyzr5NT6NAkYWvazgyNc7NOsy2hJ9EkN4IWs/0
GORkzYKBcA0MMFdt5CgbAPBFXleLwoaFpZ4BVkFIhREJHNgK6ZFfK60U4O+F552R
QZPbgD+5geJOi6XbrBD3lQ/yb3qaNoejo1g39D7h571rPRYorDlTj6BZ925D+A+7
Mb6DOZMxYUfQ6SYqZSnWf7aivdLpNNsN8K0un8Z2BB98eK6cIhUv298FxF0+tSZI
ok9T5SxF8URU2VfI6wVcSVRh8Q5aeKf2NINIxN6wrBYSwAls3gkwDEsAny+tCwwL
3hy3Y7SEvg+ItFS+d2RYdqav72Av5H2o6Uxr9025ZPKo89/Czd6XPID96znK2x/N
l851UCjHfvNG2xzRqJa0HhUl2pLyEMpC62g31wKv+wIDAQABo0MwQTAPBgNVHRMB
Af8EBTADAQH/MA8GA1UdDwEB/wQFAwMHBAAwHQYDVR0OBBYEFCtQ0M1liMFOkprT
3G5JCpfc/pNAMA0GCSqGSIb3DQEBCwUAA4ICAQAscgi/f2oJIRwHHR+Yt/nW2Z43
hBVLTf0/u/Doa2m7Ae7Bv138ofaFwwF2q7iwnrb2F6L5deD0ZZoLtL0cNtNz7ajw
46SurhoftZh98ZaEmga6UtdNBDz8EO6aJtcwH4nXmzsfQFJ6WHdoKsWTC2L8u3Q8
nbxVF8x/J5QZKOiNp7hlxGEaFABmfaPvRXa4Fm/KLuITL74pEZ3K0+ufnrsT2S4+
8RcgFYkRsKBkXPbhaGp10XDKHC4PPq26fZYVKMb4WzoeDMVMcfotGmdOrehah0mu
0fC9qElVoKtuEEvKtzAsnAX/jRPRMYqqtD90fqL6txoVKzVQcP8cyY0L6eZhIdYe
nt0NfGhmxo6sRAnVmjA5yIriHOE70Zcd2ebeBcUITe7MReIynuygd85BhYyIegBB
WGsj3iSp2Gg5CBNOe8JBLV6UU7iexThlEfWwbSpgigpdICaAaqjTATsO9PWeIM+v
TsH51AC2wh63U5o6OCp3H18/bVJ3oX2F9fba8pPY5r7T7ou0Sq5Jy6i2US03vtDA
NT2/q5MXAHy7kdMCHzT4KQp81pUTY3bNtujUyGC9Nhgf0CMQMLOmwL7lF9aKWk8J
tG1ixRwplTEHEuJARpKp+MebiyfI87OoCSRJP+LygnkKeYNGxV0fhQnIW3+44bnw
NH0QlNNxLH0iV4UJQA==
-----END CERTIFICATE-----
</ca>
</code></pre></div></div>
<p style="text-align: justify;">On lance ensuite la connexion cliente VPN afin de s’assurer que tout fonctionne correctement. L’usage de tmux permettra de simplifier l’administration de la solution.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:/etc/openvpn/client$</span><span class="w"> </span>tmux new <span class="nt">-s</span> vpn</code></pre></figure>
<p style="text-align: justify;">Pour créer plusieurs sessions simultanées sur tmux, il suffit de taper la raccourci clavier Ctrl+b-c.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:/etc/openvpn/client$</span><span class="w"> </span><span class="nb">sudo </span>openvpn <span class="nt">--config</span> fdn.conf <span class="nt">--verb</span> 3</code></pre></figure>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:/etc/openvpn/client$</span><span class="w"> </span>ip addr show
<span class="gp">1: lo: <LOOPBACK,UP,LOWER_UP></span><span class="w"> </span>mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
<span class="go"> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
</span><span class="gp">2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP></span><span class="w"> </span>mtu 1500 qdisc fq_codel state UP group default qlen 1000
<span class="go"> link/ether 88:01:02:75:f0:95 brd ff:ff:ff:ff:ff:ff
altname enp0s3
altname ens3
inet 192.0.2.10/32 brd 192.0.2.10 scope global dynamic eth0
valid_lft 49398sec preferred_lft 49398sec
inet6 2001:db8::10/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5400:2fff:fe85:bc08/64 scope link
valid_lft forever preferred_lft forever
</span><span class="gp">3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP></span><span class="w"> </span>mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
<span class="go"> link/none
inet 80.67.169.10/22 scope global tun0
valid_lft forever preferred_lft forever
inet6 2001:910:169::10/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::309f:dfe1:acad:eb0d/64 scope link stable-privacy
valid_lft forever preferred_lft forever</span></code></pre></figure>
<p style="text-align: justify;">Nous pouvons ensuite quitter le multiplexeur de terminaux à l’aide du raccourci clavier <em>Ctrl+b-d</em></p>
<h3 id="b-configuration-dun-service-openvpn-serveur-sur-le-vps">B. Configuration d’un service OpenVPN serveur sur le VPS</h3>
<p style="text-align: justify;">Tout d’abord nous allons mettre en place l’autorité de certification qui sera en charge de générer un couple clé privée - certificat X509 pour l’ensemble des hôtes utilisant OpenVPN (clients et serveur). Pour gagner du temps, j’ai fait le choix d’utiliser le logiciel <em>easy-rsa</em>.</p>
<p style="text-align: justify;">Dans un premier temps, nous allons créer l’autorité de certification puis générer les clés et les certificats X509 nécessaires au serveur ainsi qu’aux clients. La commande <em>./easyrsa gen-dh</em> permet ensuite d’implémenter le principe d’échange de clés Diffie-Hellman lors des connexions VPN. DH est utilisé lors de l’échange de clés. Il permet au serveur d’envoyer aux clients VPN des paramètres leur permettant d’établir une <em>“pre-master key”</em> partagée.</p>
<p style="text-align: justify;">Enfin, la dernière commande permet de générer une clé statique qui devra être présente sur le serveur et les clients. Elle permettra lors de l’établissement de la connexion TLS par les clients VPN de vérifier l’intégrité de la communication à l’aide d’un code d’authentification du message (HMAC) généré à l’aide de cette clé. C’est un paramètre recommandé pour renforcer la sécurité du service VPN.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:~$</span><span class="w"> </span><span class="nb">cd</span> /usr/share/easy-rsa
<span class="gp">bmoolenar@vps:/usr/share/easy-rsa$</span><span class="w"> </span><span class="nb">sudo</span> <span class="nt">-i</span>
<span class="gp">root@vps:/usr/share/easy-rsa#</span><span class="w"> </span>./easyrsa init-pki
<span class="gp">root@vps:/usr/share/easy-rsa#</span><span class="w"> </span>./easyrsa build-ca
<span class="gp">root@vps:/usr/share/easy-rsa#</span><span class="w"> </span>./easyrsa build-server-full servervpn nopass
<span class="gp">root@vps:/usr/share/easy-rsa#</span><span class="w"> </span>./easyrsa build-client-full laptop1 nopass
<span class="gp">root@vps:/usr/share/easy-rsa#</span><span class="w"> </span>./easyrsa gen-dh
<span class="gp">root@vps:/usr/share/easy-rsa#</span><span class="w"> </span>openvpn <span class="nt">--genkey</span> secret ./pki/ta.key</code></pre></figure>
<p style="text-align: justify;">Nous déplaçons ensuite les fichiers nécessaires dans le répertoire de configuration du service OpenVPN.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">root@vps:/usr/share/easy-rsa#</span><span class="w"> </span><span class="nb">cp</span> <span class="nt">-pR</span> /usr/share/easy-rsa/pki/<span class="o">{</span>issued,private,ca.crt,dh.pem,ta.key<span class="o">}</span> /etc/openvpn/server/</code></pre></figure>
<p style="text-align: justify;">Il est alors nécessaire de produire un fichier de configuration adéquat pour le serveur VPN.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">root@vps:/usr/share/easy-rsa#</span><span class="w"> </span><span class="nb">cd</span> /etc/openvpn/server
<span class="gp">root@vps:/etc/openvpn/server#</span><span class="w"> </span>nano server.conf</code></pre></figure>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># On utilise le port 443 afin de contourner certains pare-feux
port 443
# TCP or UDP server?
proto tcp
# On monte une interface tun de niveau 3 pour faire du routage par le tunnel VPN
dev tun
# On déclare le certificat X509 de l'autorité, le certificat X509 et la clé privée du serveur VPN
ca ca.crt
cert issued/servervpn.crt
key private/servervpn.key # This file should be kept secret
# On déclare le fichier permettant de créer l'échange de clé Diffie Hellman
# Generate your own with:
# openssl dhparam -out dh2048.pem 2048
dh dh.pem
# On active le protocole IPv6 pour l'utiliser dans le tunnel VPN
server-ipv6 2001:910:1339:1::/64
tun-ipv6
push tun-ipv6
# On déclare le réseau IPv4 à utiliser entre les clients VPN et le serveur
server 172.16.169.0 255.255.255.0
# Permet d'enregistrer et de maintenir la configuration des clients VPN
ifconfig-pool-persist /var/log/openvpn/ipp.txt
# On force la redirection de tout le trafic du client VPN à passer par le tunnel en IPv4
push "redirect-gateway def1 bypass-dhcp"
# La même chose en IPv6, on définit une métrique plus petite pour prendre le pas sur la route
# par défaut classique définie dans les paramètres réseaux du client
push "route-ipv6 ::/0"
push "route-metric 200"
# Permet de maintenir le tunnel envoyant des ping tous les 10 secondes
# On considère que l'hôte distant est éteint si aucun ping n'est reçu pendant 120 secondes
keepalive 10 120
# Définition de la clé statique permettant de mettre en oeuvre le code d'authentification HMAC
tls-auth ta.key
# Algorithme cryptographique à utiliser
cipher AES-256-CBC
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status /var/log/openvpn/openvpn-status.log
verb 3
# Notify the client that when the server restarts so it
# can automatically reconnect.
explicit-exit-notify 1
</code></pre></div></div>
<p style="text-align: justify;">On peut démarrer ensuite le service OpenVPN.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:/etc/openvpn/server$</span><span class="w"> </span>tmux attach <span class="nt">-t</span> vpn
<span class="gp">bmoolenar@vps:/etc/openvpn/server$</span><span class="w"> </span><span class="nb">sudo </span>openvpn <span class="nt">--config</span> server.conf <span class="nt">--verb</span> 3</code></pre></figure>
<p style="text-align: justify;">Nous pouvons vérifier que la nouvelle interface <em>tun1</em> a correctement été montée à l’aide de la commande <em>ip addr show</em>.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:/etc/openvpn/client$</span><span class="w"> </span>ip addr show
<span class="gp">1: lo: <LOOPBACK,UP,LOWER_UP></span><span class="w"> </span>mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
<span class="go"> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
</span><span class="gp">2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP></span><span class="w"> </span>mtu 1500 qdisc fq_codel state UP group default qlen 1000
<span class="go"> link/ether 88:01:02:75:f0:95 brd ff:ff:ff:ff:ff:ff
altname enp0s3
altname ens3
inet 192.0.2.10/32 brd 192.0.2.10 scope global dynamic eth0
valid_lft 49398sec preferred_lft 49398sec
inet6 2001:db8::10/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5400:2fff:fe85:bc08/64 scope link
valid_lft forever preferred_lft forever
</span><span class="gp">3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP></span><span class="w"> </span>mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
<span class="go"> link/none
inet 80.67.169.10/22 scope global tun0
valid_lft forever preferred_lft forever
inet6 2001:910:169::10/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::309f:dfe1:acad:eb0d/64 scope link stable-privacy
valid_lft forever preferred_lft forever
</span><span class="gp">4: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP></span><span class="w"> </span>mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
<span class="go"> link/none
inet 172.16.169.1 peer 172.16.169.2/32 scope global tun1
valid_lft forever preferred_lft forever
inet6 2001:910:168::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::39f4:e59:744e:5023/64 scope link stable-privacy
valid_lft forever preferred_lft forever</span></code></pre></figure>
<h3 id="c-mise-en-place-du-routage-et-du-nat">C. Mise en place du routage et du NAT</h3>
<p style="text-align: justify;">Il nous reste ensuite à prendre en charge toute la partie routage avec les problématiques évoquées en introduction. On active le routage de paquets IPv4 et IPv6.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:~$</span><span class="w"> </span>sudoedit /etc/sysctl.conf</code></pre></figure>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code># Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
# Uncomment the next line to enable packet forwarding for IPv6
# Enabling this option disables Stateless Address Autoconfiguration
# based on Router Advertisements for this host
net.ipv6.conf.all.forwarding=1
</code></pre></div></div>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:~$</span><span class="w"> </span><span class="nb">sudo </span>sysctl <span class="nt">-p</span> /etc/sysctl.conf</code></pre></figure>
<p style="text-align: justify;">Nous mettons enfin en place la politique de routage PBR qui permettra le routage du trafic provenant des clients VPN dans le tunnel VPN à destination du FAI associatif. La translation d’adresses NAPT sera aussi implémentée.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bmoolenar@vps:~$</span><span class="w"> </span><span class="nb">sudo </span>ip rule add prio 100 from 172.16.169.0/24 lookup vpn
<span class="gp">bmoolenar@vps:~$</span><span class="w"> </span><span class="nb">sudo </span>ip <span class="nt">-6</span> rule add prio 100 from 2001:910:168::/64 lookup vpn
<span class="gp">bmoolenar@vps:~$</span><span class="w"> </span><span class="nb">sudo </span>ip route add default dev tun0 table vpn
<span class="gp">bmoolenar@vps:~$</span><span class="w"> </span><span class="nb">sudo </span>ip <span class="nt">-6</span> route add default dev tun0 table vpnuser
<span class="gp">bmoolenar@vps:~$</span><span class="w"> </span><span class="nb">sudo </span>iptables <span class="nt">-t</span> nat <span class="nt">-A</span> POSTROUTING <span class="nt">-o</span> tun0 <span class="nt">-j</span> MASQUERADE
<span class="gp">bmoolenar@vps:~$</span><span class="w"> </span><span class="nb">sudo </span>ip6tables <span class="nt">-t</span> nat <span class="nt">-A</span> POSTROUTING <span class="nt">-o</span> tun0 <span class="nt">-j</span> MASQUERADE</code></pre></figure>
<p style="text-align: justify;">Il est bien évidemment possible de scripter l’ensemble des commandes présenté ci-dessus et de les activer automatiquement après le lancement du VPN.</p>
<h3 id="d-configuration-du-client-vpn">D. Configuration du client VPN</h3>
<p style="text-align: justify;">Sur le client, il est nécessaire d’avoir à disposition le certificat X509 de l’autorité de certification générée avec <em>easy-rsa</em>, la clé privée du client et le certificat X509 du client ainsi que le fichier commun ta.key. Enfin, il faudra disposer également d’un fichier de configuration OpenVPN client valide.</p>
<p style="text-align: justify;">Pour récupérer les fichiers créés sur le serveur VPN avec easy-rsa la solution la plus simple s’avère être SFTP ou SCP.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">kmitnick@client:~/confvpn$</span><span class="w"> </span><span class="nb">ls</span>
<span class="go">ca.crt client.conf ta.key laptop1.crt laptop1.key</span></code></pre></figure>
<p style="text-align: justify;">Voici le contenu du fichier de configuration client.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>client
dev tun
proto tcp
remote 192.0.2.10 443
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert laptop1.crt
key laptop1.key
tls-auth ta.key 1
verb 3
</code></pre></div></div>
<p style="text-align: justify;">On lance ensuite la connexion du client OpenVPN vers le serveur.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">kmitnick@client:~/confvpn$</span><span class="w"> </span><span class="nb">sudo </span>openvpn <span class="nt">--config</span> client.conf <span class="nt">--verb</span> 3</code></pre></figure>
<p style="text-align: justify;">On verifie que l’interface tun OpenVPN est présente dans les paramètres réseaux de la machine cliente.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">kmitnick@client:~/confvpn$</span><span class="w"> </span>ip a
<span class="gp">6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP></span><span class="w"> </span>mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
<span class="go"> link/none
inet 172.16.169.6 peer 172.16.169.5/32 scope global noprefixroute tun0
valid_lft forever preferred_lft forever
inet6 2001:910:168::1000/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::f834:3452:2ac7:7029/64 scope link stable-privacy proto kernel_ll
valid_lft forever preferred_lft forever</span></code></pre></figure>
<p style="text-align: justify;">Plusieurs tests sont possibles pour vérifier la bonne connectivité de notre vpn depuis le client.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">kmitnick@client:~/confvpn$</span><span class="w"> </span>traceroute www.debian.org
<span class="go">traceroute to www.debian.org (130.89.148.77), 30 hops max, 60 byte packets
1 172.16.169.1 (172.16.169.1) 56.730 ms 119.145 ms 119.123 ms
2 gw.vpn.fdn.fr (80.67.179.1) 119.065 ms 119.001 ms 118.944 ms
3 80.67.169.251 (80.67.169.251) 118.884 ms 118.832 ms 118.777 ms
4 x-ray.gitoyen.net (80.67.168.4) 118.721 ms 118.669 ms 118.619 ms
5 vodka.gitoyen.net (80.67.168.7) 118.571 ms 154.615 ms 154.576 ms
6 surf.telecity2.nl-ix.net (193.239.117.149) 154.524 ms 152.198 ms 165.490 ms
7 ae23.zl001a-jnx-01.surf.net (145.145.176.51) 167.384 ms 167.368 ms 167.275 ms
8 e4-0-0-0.es001b-jnx-01.surf.net (145.145.0.78) 167.060 ms 167.070 ms 167.038 ms
9 utwente-router.customer.surf.net (145.145.4.46) 165.076 ms 167.002 ms 166.957 ms
10 cr1-sein-to-bdr1-sein.routing.utwente.nl (130.89.254.0) 209.515 ms 112.758 ms 216.542 ms
11 130.89.254.131 (130.89.254.131) 216.471 ms 216.324 ms 216.368 ms
12 klecker-misc.debian.org (130.89.148.77) 167.375 ms 266.437 ms 266.425 ms</span></code></pre></figure>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">kmitnick@client:~/confvpn$</span><span class="w"> </span>traceroute <span class="nt">-6</span> www.debian.org
<span class="go">traceroute -6 www.debian.org
traceroute to www.debian.org (2001:67c:2564:a119::77), 30 hops max, 80 byte packets
1 * * *
2 2001:910:169::1 (2001:910:169::1) 103.254 ms 128.263 ms 128.322 ms
3 2001:910:800::251 (2001:910:800::251) 128.337 ms 128.347 ms 128.356 ms
4 fdn-x-ray.gitoyen.net (2001:910:0:800::210) 128.363 ms 128.374 ms 128.386 ms
5 vodka.gitoyen.net (2001:910::7) 128.396 ms surfnet.nikhef.nlsix.net (2001:7f8:13::a500:1103:1) 160.543 ms 160.608 ms
6 surfnet.nikhef.nlsix.net (2001:7f8:13::a500:1103:1) 160.622 ms 113.551 ms 144.434 ms
7 ae21.zl001a-jnx-01.surf.net (2001:610:e00:2::2a) 144.474 ms 144.445 ms e4-0-0-0.es001b-jnx-01.surf.net (2001:610:fc7:0:145:145:0:78) 144.365 ms
8 utwente-router.customer.surf.net (2001:610:f00:4044::46) 144.205 ms e4-0-0-0.es001b-jnx-01.surf.net (2001:610:fc7:0:145:145:0:78) 144.253 ms utwente-router.customer.surf.net (2001:610:f00:4044::46) 144.140 ms
9 2001:67c:2564:aa13::193 (2001:67c:2564:aa13::193) 144.207 ms 144.148 ms 169.734 ms
10 2001:67c:2564:aa13::193 (2001:67c:2564:aa13::193) 169.666 ms 2001:67c:2564:aa21::253 (2001:67c:2564:aa21::253) 169.520 ms 2001:67c:2564:aa13::193 (2001:67c:2564:aa13::193) 170.394 ms
11 klecker.debian.org (2001:67c:2564:a119::77) 170.813 ms 170.810 ms 170.782 ms</span></code></pre></figure>
<h2 id="conclusion">Conclusion</h2>
<p style="text-align: justify;">Grâce à ces éléments de configuration, il est dorénavant possible de fournir un accès VPN commun à l’ensemble des machines clientes à notre disposition. Elles vont pouvoir ainsi bénéficier d’un accès Internet respectueux de la neutralité du net. Enjoy !</p>I. Expression des besoinsAuthentification par clés SSH avec FIDO 22023-09-12T09:00:00+02:002023-09-12T09:00:00+02:00http://172.16.255.10:4000/sysadmin/2023/09/12/ssh-fido2<h2 id="i-introduction">I. Introduction</h2>
<p style="text-align: justify;">Cela fait déjà de nombreuses années que l’authentification par mot de passe sur un service SSH est considérée comme problématique. Elle est sensible à de nombreuses attaques : MiTM, attaques par force brute ou par dictionnaire, keylogger notamment.</p>
<p style="text-align: justify;">Ainsi, il est fortement recommandé de mettre en place une authentification forte à l’aide d’une paire de clés. Cette solution est efficace mais elle repose avant tout sur la clé privée qui doit être conservée jalousement et ne doit pas être dérobée par une personne malveillante. Cette clé est par ailleurs généralement stockée sur le disque dur du poste client (.ssh/id_*).</p>
<p style="text-align: justify;">Depuis la sortie d’OpenSSH 8.2 en février 2020, il est possible de renforcer la sécurité dans
l’utilisation de cette paire de clés à l’aide de la norme FIDO 2. Ainsi, un attaquant devra dérober une première clé (handle private key) servant à générer (dérivation) la clé privée SSH mais également avoir un accès physique à la clé de sécurité matérielle comme la yubikey par exemple.</p>
<h2 id="ii-mise-en-oeuvre">II. Mise en oeuvre</h2>
<h3 id="a-préambule">a. Préambule</h3>
<p>Il existe deux méthodes de sécurisation FIDO2 possibles :</p>
<ul style="text-align: justify;">
<li>Le mode “résident” qui permet de stocker la clé (handle private key) nécessaire à la génération de la clé privée dans la clé de sécurité matérielle. L’avantage de cette méthode est qu’elle permet de s’authentifier à partir de différents clients. Par contre, il est indispensable de mettre en place un code PIN autorisant l’accès à la “handle private key” ainsi qu’une solution de secours en cas de perte ou de vol de le clé de sécurité physique.</li>
</ul>
<ul style="text-align: justify;">
<li>Le mode “non résident” ou partagé qui impose la présence d’un fichier sur le client (~/.ssh/id_*_sk) et de la clé de sécurité matérielle pour être en mesure de générer la clé privée nécessaire à l’authentification sur le serveur SSH. L’avantage de cette méthode est que seul le client disposant du fichier <em>id_*_sk</em> sera en mesure de s’authentifier.</li>
</ul>
<h3 id="b-schéma-concernant-le-mode-résident">b. Schéma concernant le mode résident</h3>
<p><img src="https://quentin.demouliere.eu/data/images/authfido2v2.png" alt="Fido2 SSH" /></p>
<h3 id="c-paramétrage-sur-le-client">c. Paramétrage sur le client</h3>
<p style="text-align: justify;">Dans le cas présent, nous allons configurer l’authentification avec la méthode “résident”.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bilbo@comte:~$</span><span class="w"> </span>ssh-keygen <span class="nt">-t</span> ed25519-sk <span class="nt">-O</span> resident <span class="nt">-O</span> <span class="nv">application</span><span class="o">=</span>ssh:bilbo <span class="nt">-O</span> verify-required</code></pre></figure>
<p style="text-align: justify;">Dans le cas présent, la clé privée sera stockée dans la clé de sécurité physique elle-même grâce au paramétre <em>-O resident</em>.</p>
<ul style="text-align: justify;">
<li>Le paramétre <em>-O application=ssh:</em> permet d’utiliser un slot particulier sur la clé de sécurité.</li>
</ul>
<ul style="text-align: justify;">
<li>Le paramètre <em>-O verify-required</em> oblige l’utilisateur à utiliser un code PIN et à toucher la clé de sécurité pour y avoir accès. Ce paramètre est donc important pour renforcer la sécurité.</li>
</ul>
<h3 id="d-paramétrage-sur-le-serveur">d. Paramétrage sur le serveur</h3>
<p style="text-align: justify;">La première étape consiste à transférer notre clé publique SSH générée sur le client (~/.ssh/id_*_sk.pub) sur le serveur SSH.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bilbo@comte:~$</span><span class="w"> </span>ssh-copy-id <span class="nt">-i</span> ~/.ssh/id_ed25519_sk.pub bilbo@fondcombe.middleearth.fr</code></pre></figure>
<p style="text-align: justify;">La seconde consiste à nous assurer que le serveur supporte ce format de clés SSH (version d’OpenSSH >= 8.2 pour le mode non résident et OpenSSH >= 8.3 pour le mode résident).</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">elrond@fondcombe:~$</span><span class="w"> </span>sudoedit /etc/ssh/sshd_config</code></pre></figure>
<p style="text-align: justify;">Il faut ajouter la ligne suivante dans le fichier <em>/etc/ssh/sshd_config</em> puis redémarrer le service OpenSSH.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>PubkeyAcceptedKeyTypes ssh-ed25519,sk-ssh-ed25519@openssh.com
</code></pre></div></div>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">elrond@fondcombe:~$</span><span class="w"> </span><span class="nb">sudo </span>systemctl restart ssh</code></pre></figure>
<h3 id="e-test-de-connexion-ssh-depuis-le-client">e. Test de connexion SSH depuis le client</h3>
<p style="text-align: justify;">Insérer la clé de sécurité sur le poste client. Ouvrir un terminal et taper la commande :</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">bilbo@comte:~$</span><span class="w"> </span>ssh bilbo@fondcombe.middleearth.fr
<span class="go">Confirm user presence for key ED25519-SK SHA256:
Enter PIN for ED25519-SK key /home/bilbo/.ssh/id_ed25519_sk:
User presence confirmed
</span><span class="gp">Linux fondcombe 5.10.0-13-amd64 #</span>1 SMP Debian 5.10.106-1 x86_64
<span class="gp">bilbo@fondcombe:~$</span></code></pre></figure>
<p style="text-align: justify;">Il faudra alors rentrer le code PIN puis toucher la clé pour pouvoir accéder à son contenu. L’authentification est valide, l’accès SSH opérationnel.</p>
<h2 id="iii-conclusion">III. Conclusion</h2>
<p style="text-align: justify;">Cette méthode permet de renforcer la sécurité de l’authentification par clés SSH sur un serveur. Elle sera d’autant plus pertinente dans des environnements sensibles tout en respectant l’état de l’art.</p>
<p style="text-align: justify;">Si vous n’avez pas de clé de sécurité matérielle, vous pouvez vous en procurer une auprès de Yubico ou Nitrokey par exemple.</p>
<h2 id="sources">Sources</h2>
<p><a href="https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html">https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html</a></p>
<p><a href="https://wonderfall.dev/openssh-fido2/">https://wonderfall.dev/openssh-fido2/</a></p>
<p><a href="https://blog.maxds.fr/ssh-with-yubikey/">https://blog.maxds.fr/ssh-with-yubikey/</a></p>I. IntroductionDéchiffrer un flux TLS pour établir un diagnostic2023-07-15T09:00:00+02:002023-07-15T09:00:00+02:00http://172.16.255.10:4000/netadmin/2023/07/15/tls-wireshark<h2 id="introduction">Introduction</h2>
<p style="text-align: justify;">La plupart des applications et des flux réseaux sont actuellement chiffrés à l’aide du protocole TLS. On peut s’en réjouir en termes de sécurité informatique, respect de la vie privée, etc. Mais cela peut poser des problèmes en particulier lorsque l’on souhaite réaliser des diagnostics précis en cas de problèmes ou dysfonctionnements.</p>
<p style="text-align: justify;">Cette documentation explique comment récupérer légitimement la clé de session symétrique TLS en cours d’utilisation afin d’être en mesure de déchiffrer le trafic dans l’outil de capture de trames Wireshark.</p>
<p style="text-align: justify;">Cette procédure fonctionne normalement avec Firefox, Chrome et Chromium installés sur un système Windows, GNU/Linux ou macOS.</p>
<p style="text-align: justify;"><strong>Attention !</strong> Certaines versions de Firefox ont été compilées avec la désactivation du stockage de la clé de session à partir d’une variable d’environnement (exemple sur Kali Linux : aucun fichier créé avec Firefox ESR 102.12.0 mais cela fonctionne très bien avec la dernière version 114.02).</p>
<h2 id="procédure-sous-gnulinux">Procédure sous GNU/Linux</h2>
<ul>
<li>
<p>Être connecté avec l’utilisateur qui sera amené à utiliser la clé de session.</p>
</li>
<li>
<p>Fermer les navigateurs (ou applications) concernés qui utilisent TLS.</p>
</li>
<li>
<p>Ouvrir un terminal puis rentrer la commande suivante.</p>
</li>
</ul>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">etudiant@pcsio:~$</span><span class="w"> </span><span class="nb">export </span><span class="nv">SSLKEYLOGFILE</span><span class="o">=</span><span class="s2">"/home/etudiant/cledesession"</span></code></pre></figure>
<ul>
<li>
<p>Démarrer Wireshark et la capture de trames.</p>
</li>
<li>
<p>Toujours dans le même terminal utilisé pour exporter la variable d’environnement, lancer une nouvelle commande.</p>
</li>
</ul>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">etudiant@pcsio:~$</span><span class="w"> </span>firefox &</code></pre></figure>
<ul>
<li>
<p>Se connecter sur le site web souhaité à l’aide du protocole HTTPS et réaliser les opérations voulues.</p>
</li>
<li>
<p>Stopper ensuite la capture, la sauvegarder et fermer Wireshark.</p>
</li>
<li>
<p>Ouvrir à nouveau Wireshark, aller dans Editer > Préférences > Protocols > TLS.</p>
</li>
</ul>
<p><img src="https://quentin.demouliere.eu/data/images/wireshark1.png" alt="Configuration Wireshark 1" /></p>
<ul>
<li>Puis cliquer sur Parcourir dans le menu (Pre)-Master-Secret log filename afin de sélectionner le fichier /home/etudiant/cledesession.</li>
</ul>
<p><img src="https://quentin.demouliere.eu/data/images/wireshark2.png" alt="Configuration Wireshark 2" /></p>
<ul style="text-align: justify;">
<li>Ouvrir le fichier de capture de trames sauvegardé précédemment. Il est dorénavant possible d’observer le contenu des flux HTTPS (TLS) en clair (exemple : récupération d’un couple login et mot de passe à l’aide d’un filtre Wireshark http.request.method==”POST”).</li>
</ul>
<h3 id="sources">Sources</h3>
<p><a href="https://www.bortzmeyer.org/files/capitole-libre-2022-tout-chiffre.pdf">https://www.bortzmeyer.org/files/capitole-libre-2022-tout-chiffre.pdf</a></p>
<p><a href="https://my.f5.com/manage/s/article/K50557518https://my.f5.com/manage/s/article/K50557518">https://my.f5.com/manage/s/article/K50557518</a></p>IntroductionGérer la publication sur son site statique Jekyll avec GIT2020-11-23T08:00:00+01:002020-11-23T08:00:00+01:00http://172.16.255.10:4000/sysadmin/2020/11/23/jekyll-git<h2 id="introduction">Introduction</h2>
<p style="text-align: justify;">J’ai décidé de migrer de Pluxml que j’utilisais depuis 7 ans vers Jekyll, un outil développé en Ruby permettant de générer un site web statique à partir de fichiers utilisant la syntaxe Markdown.</p>
<p style="text-align: justify;">L’un des intérêts de Jekyll est de pouvoir utiliser GIT pour créer des posts sur notre ordinateur et de les synchroniser sur le serveur qui héberge le site.</p>
<p style="text-align: justify;">Le serveur se nomme <code class="language-plaintext highlighter-rouge">comte.eriador.fr</code> et il dispose de l’utilisateur <code class="language-plaintext highlighter-rouge">jekyll</code> dédié à la gestion du site. Le poste local se nomme <code class="language-plaintext highlighter-rouge">gondor.eriador.fr</code> et l’utilisateur se nomme <code class="language-plaintext highlighter-rouge">aragorn</code>.</p>
<h2 id="mise-en-place">Mise en place</h2>
<p style="text-align: justify;">Nous allons utiliser le protocole SSH entre le client et le serveur avec une authentification par clés. Pour cela, nous allons copier le condensat de notre clé publique personnelle dans le fichier ~/.ssh/authorized_keys de l’utilisateur jekyll sur le serveur.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">aragorn@gondor:~$</span><span class="w"> </span>ssh-copy-id jekyll@comte.eriador.fr</code></pre></figure>
<p>Puis paramétrons le serveur (je ne détaillerais pas l’installation de Jekyll ici).</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">jekyll@comte:~$</span><span class="w"> </span><span class="nb">cd </span>monsite
<span class="gp">jekyll@comte:~/monsite$</span><span class="w"> </span>git init
<span class="gp">jekyll@comte:~/monsite$</span><span class="w"> </span>git add <span class="nb">.</span>
<span class="gp">jekyll@comte:~/monsite$</span><span class="w"> </span>git commit <span class="nt">-m</span> <span class="s2">"Premier commit du site Jekyll"</span></code></pre></figure>
<p>Sur l’ordinateur client, initialisons un dépôt GIT.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">aragorn@gondor:~$</span><span class="w"> </span><span class="nb">sudo </span>apt <span class="nb">install </span>git
<span class="gp">aragorn@gondor:~$</span><span class="w"> </span>git clone jekyll@comte.eriador.fr:/home/jekyll/monsite
<span class="gp">aragorn@gondor:~$</span><span class="w"> </span><span class="nb">cd </span>monsite
<span class="gp">aragorn@gondor:~/monsite$</span><span class="w"> </span>git init
<span class="gp">aragorn@gondor:~/monsite$</span><span class="w"> </span>git add <span class="nb">.</span>
<span class="gp">aragorn@gondor:~/monsite$</span><span class="w"> </span>git commit <span class="nt">-m</span> <span class="s2">"Premier commit sur mon ordinateur pour mes posts"</span></code></pre></figure>
<p style="text-align: justify;">Ensuite, sur le serveur, nous allons passer à la création d’un dépôt git un mode bare afin de pouvoir synchroniser le dépôt local présent sur le poste vers le serveur.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">jekyll@comte:~$</span><span class="w"> </span><span class="nb">rm</span> <span class="nt">-rf</span> monsite
<span class="gp">jekyll@comte:~$</span><span class="w"> </span><span class="nb">mkdir </span>monsite.git
<span class="gp">jekyll@comte:~$</span><span class="w"> </span><span class="nb">cd </span>monsite.git
<span class="gp">jekyll@comte:~/monsite.git$</span><span class="w"> </span>git init <span class="nt">--bare</span>
<span class="gp">jekyll@comte:~/monsite.git$</span><span class="w"> </span>nano hooks/post-receive</code></pre></figure>
<figure class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="c">#!/bin/sh</span>
<span class="nv">GIT_WORK_TREE</span><span class="o">=</span>/home/jekyll/monsite git checkout <span class="nt">-f</span></code></pre></figure>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">jekyll@comte:~/monsite.git$</span><span class="w"> </span><span class="nb">chmod</span> +x hooks/post-receive</code></pre></figure>
<p style="text-align: justify;">La configuration est maintenant terminée. Lorsque nous publierons un nouveau post en Markdown sur notre ordinateur local, il nous restera simplement à le synchroniser sur le serveur.</p>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">aragorn@gondor:~/monsite$</span><span class="w"> </span><span class="nb">cd </span>_posts
<span class="gp">aragorn@gondor:~/monsite/_posts$</span><span class="w"> </span>nano 2020-11-20-monarticle.markdown</code></pre></figure>
<figure class="highlight"><pre><code class="language-markdown" data-lang="markdown"><span class="nn">---</span>
<span class="na">layout</span><span class="pi">:</span> <span class="s">post</span>
<span class="na">title</span><span class="pi">:</span> <span class="s2">"</span><span class="s">Mon</span><span class="nv"> </span><span class="s">joli</span><span class="nv"> </span><span class="s">article</span><span class="nv"> </span><span class="s">en</span><span class="nv"> </span><span class="s">markdown"</span>
<span class="na">date</span><span class="pi">:</span> <span class="s">2020-11-20 12:00:00 +0100</span>
<span class="na">categories</span><span class="pi">:</span> <span class="s">test</span>
<span class="nn">---</span>
<span class="gu">## Titre 1</span>
Ceci est un premier article rédigé à l'aide de la syntaxe markdown.
<span class="p">
*</span> Have lot of fun !</code></pre></figure>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">aragorn@gondor:~/monsite$</span><span class="w"> </span>git add <span class="nb">.</span>
<span class="gp">aragorn@gondor:~/monsite$</span><span class="w"> </span>git commit <span class="nt">-m</span> <span class="s2">"Ajout d'un article le 20 novembre"</span>
<span class="gp">aragorn@gondor:~/monsite$</span><span class="w"> </span>git remote add website jekyll@comte.eriador.fr:/home/jekyll/monsite.git
<span class="gp">aragorn@gondor:~/monsite$</span><span class="w"> </span>git push website +master:refs/heads/master</code></pre></figure>
<p>Puis si nous sommes amenés à synchroniser à nouveau notre dépôt local et notre serveur :</p>
<p><code class="language-plaintext highlighter-rouge">aragorn@gondor:~/monsite$ git push website master</code></p>
<p style="text-align: justify;">Et voilà. Il ne nous reste plus qu’à créer autant de posts que nous voulons et à les synchroniser sur notre serveur via GIT. Enjoy !</p>IntroductionSauvegarde de machines virtuelles sous Proxmox avec SSHFS2020-11-21T12:00:00+01:002020-11-21T12:00:00+01:00http://172.16.255.10:4000/sysadmin/2020/11/21/proxmox-sshfs<h2 id="introduction">Introduction</h2>
<p>J’ai décidé de mettre en place un dispositif de sauvegarde concernant les machines virtuelles que j’héberge sur mon hyperviseur Proxmox 6.2. Je souhaitais un système simple et sans prise de tête dans la mise en oeuvre. Pour cela, je me suis tourné vers les “Storage box” proposées par l’hébergeur Hetzner. J’ai choisi le modèle BX20 disposant de 512 Go de stockage.</p>
<p>Comme je souhaitais que la communication soient chiffrée entre l’hyperviseur et la storage box, je me suis tourné vers la solution suivante :</p>
<ol>
<li>Création d’un petit script permettant de monter la box sur l’arborescence de mon proxmox via SSHFS.</li>
<li>Définition de cette arborescence dans l’hyperviseur comme espace de sauvegarde.</li>
<li>Mise en place d’une tâche planifiée pour l’automatiser.</li>
</ol>
<h2 id="mise-en-oeuvre">Mise en oeuvre</h2>
<p>Sur l’hyperviseur Proxmox :</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>gandalf@manwe:~$ sudo apt update && sudo apt upgrade
gandalf@manwe:~$ sudo apt install sshfs
</code></pre></div></div>
<p><code class="language-plaintext highlighter-rouge">gandalf@manwe:~$ nano backup.sh</code></p>
<figure class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="c">#!/bin/sh</span>
<span class="c"># Vérifier sur la box est bien montee sur le systeme</span>
<span class="k">if</span> <span class="o">[</span> <span class="si">$(</span>mount | <span class="nb">grep</span> <span class="s1">'user@uxxxxx.storagebox.com:/backup'</span> | <span class="nb">wc</span> <span class="nt">-l</span><span class="si">)</span> <span class="nt">-ne</span> 1 <span class="o">]</span>
<span class="k">then</span>
<span class="c"># umask=000 permet la permission 777</span>
<span class="nb">echo</span> <span class="s1">'myboxpassword'</span> | sshfs <span class="nt">-o</span> reconnect,ServerAliveInterval<span class="o">=</span>15,ServerAliveCountMax<span class="o">=</span>3 <span class="nt">-o</span> <span class="nb">umask</span><span class="o">=</span>000 user@uxxxxx.storagebox.com:/backup /mnt/backup <span class="nt">-o</span> password_stdin,allow_other
<span class="nv">secs</span><span class="o">=</span><span class="k">$((</span><span class="m">2</span> <span class="o">*</span> <span class="m">2</span><span class="k">))</span>
<span class="k">while</span> <span class="o">[</span> <span class="nv">$secs</span> <span class="nt">-gt</span> 0 <span class="o">]</span><span class="p">;</span> <span class="k">do
</span><span class="nb">echo</span> <span class="nt">-ne</span> <span class="s2">"</span><span class="nv">$secs</span><span class="se">\0</span><span class="s2">33[0K</span><span class="se">\r</span><span class="s2">"</span>
<span class="nb">sleep </span>1
: <span class="k">$((</span>secs--<span class="k">))</span>
<span class="k">done
</span><span class="nb">echo</span> <span class="s1">'La box via SSHFS a ete montee correctement.'</span>
<span class="k">else
</span><span class="nb">echo</span> <span class="s1">'La box est deja montee.'</span>
<span class="k">fi</span></code></pre></figure>
<figure class="highlight"><pre><code class="language-console" data-lang="console"><span class="gp">gandalf@manwe:~$</span><span class="w"> </span><span class="nb">chmod</span> +x backup.sh
<span class="gp">gandalf@manwe:~$</span><span class="w"> </span>crontab <span class="nt">-e</span>
<span class="go">*/5 * * * * echo "mysudopassword" | sudo sh /home/gandalf/backup.sh</span></code></pre></figure>
<p>Ensuite, il est nécessaire de se connecter sur l’interface web d’administration de l’hyperviseur :</p>
<ul>
<li>https://manwe.eriador.fr:8006</li>
</ul>
<p>La première étape consiste à déclarer le chemin absolu de votre montage comme nouvel espace de stockage sur Proxmox. Pour cela, cliquez sur Datacenter > Storage > Add > Directory puis précisez /mnt/backup</p>
<p><img src="https://quentin.demouliere.eu/data/images/proxmox1.png" alt="proxmox1" /></p>
<p>La seconde étape consiste à mettre en place une politique de sauvegarde. Pour cela, cliquez sur Datacenter > Backup > Add et définissez les paramètres les plus adaptés à vos besoins.</p>
<p><img src="https://quentin.demouliere.eu/data/images/proxmox2.png" alt="proxmox1" /></p>
<p>Et enjoy ! Vous pouvez dorénavant sauvegarder vos VM dans votre storage box Hetzner.</p>IntroductionLinux Mint 19.3, Unbound et systemd-resolved2020-05-05T11:00:00+02:002020-05-05T11:00:00+02:00http://172.16.255.10:4000/sysadmin/2020/05/05/unbound-systemd<p>J’ai eu la bonne surprise de découvrir récemment que mon système Linux Mint utilise sans que je le sache le stubresolveur de systemd. Problème, j’avais fait le choix dès l’installation de l’OS d’avoir mon propre résolveur sur mon ordinateur à savoir Unbourd.</p>
<p>J’ai fini par m’en rendre compte suite à des tests de résolution de nom de domaine avec l’outil dig. En effet, je n’arrivais pas à comprendre que DNSSEC ne fonctionnait pas alors que j’avais configuré Unbound pour gérer cette technologie. Chose étrange, au lieu d’interroger unbound sur l’adresse localhost 127.0.0.1, dig choisissait 127.0.0.53. C’est ce dernier élément qui m’a mis la puce à l’oreille.</p>
<p>Après quelques recherches sur le Web, j’ai fini par découvrir le pot aux roses. Linux Mint utilise par défaut le stubresolveur de systemd à savoir systemd-resolved qui prend le dessus sur Network-Manager. Car oui, je m’étais dit qu’en précisant une adresse IP de DNS récursif statique dans ma configuration réseau Network-Manager, cela ferait l’affaire. Et bien non.</p>
<p>Ce qui me gêne le plus dans l’histoire, c’est que le système faisait un choix concernant la gestion DNS incidieux pendant que j’étais persuadé que cette dernière fonctionnait normalement via Network-Manager. Ce petit évènement m’a donc passablement mis les nerfs et n’a fait que confirmer que systemd était bien trop intrusif pour un gestionnaire d’init.</p>
<p></troll>Les béni-oui-oui qui, il y a encore quelques mois, soutenaient mordicus que non mais dans systemd tout est paramétrable et modulable, et puis on peut choisir quelle brique on installe, se sont fourvoyés. Car non, je ne peux pas désinstaller systemd-resolved car cela casserait des dépendances systèmes. Oui, Lennart et son soft continuent d’imposer des services pourris qui sortent totalement du cadre d’un gestionnaire d’init. Je n’en dirais pas plus…</troll></p>
<p>Bref pour ceux qui rencontreraient une situation similaire, voici ce que j’ai trouvé pour résoudre ce désagrément et pouvoir utiliser Unbound tranquillement via le stubresolver classique de l’OS.</p>
<p>Dans un premier temps, on éteint le service systemd-resolved, puis on le désactive lors du démarrage du système et enfin on supprime le fichier /etc/resolv.conf qui est en fait un lien symbolique vers un fichier de configuration de systemd-resolved.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ sudo systemctl stop systemd-resolved
$ sudo systemctl disable systemd-resolved
$ sudo rm /etc/resolv.conf
</code></pre></div></div>
<p>Ensuite on édite le fichier de configuration de Network-Manager afin de lui spécifier que la gestion du DNS se fera normalement et plus via systemd.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ sudo nano /etc/NetworkManager/NetworkManager.conf
[main]
dns=default
</code></pre></div></div>
<p>Enfin, on redémarre le service. Et voilà, les paramètres réseaux définis dans Network-Manager sont correctement pris en compte.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ sudo systemctl restart network-manager
</code></pre></div></div>
<p>J’espère que ce billet aidera les personnes ayant rencontrées une problématique identique. Il est clair que si je n’étais pas contraint de rester sur une distribution de ce type, cela ferait bien longtemps que j’aurais migré sur FreeBSD, ou VoidLinux.</p>
<p>À bon entendeur…</p>J’ai eu la bonne surprise de découvrir récemment que mon système Linux Mint utilise sans que je le sache le stubresolveur de systemd. Problème, j’avais fait le choix dès l’installation de l’OS d’avoir mon propre résolveur sur mon ordinateur à savoir Unbourd.Comment obtenir l’adresse IP source d’une requête http sur un serveur web présent derrière un reverse-proxy ?2019-02-05T09:53:25+01:002019-02-05T09:53:25+01:00http://172.16.255.10:4000/sysadmin/2019/02/05/reverse-proxy-backend<h2 id="1-préambule">1. Préambule</h2>
<p>Un proxy inverse (reverse-proxy) est un type de serveur, habituellement placé en frontal des serveurs web. Ainsi, le client web passe par cet intermédiaire pour accéder aux applications des serveurs internes. Le reverse-proxy peut fournir différentes fonctionnalités intéressantes comme une fonction de cache, des fonctions de répartition de charges, des fonctions de sécurité (WAF), le chiffrement TLS et la compression.</p>
<h2 id="2-introduction">2. Introduction</h2>
<p>Si vous fonctionnez dans une architecture où vous disposez d’un reverse-proxy situé en amont de vos serveurs applicatifs classiques, alors vous avez certainement remarqué que l’adresse IP source présente dans les fichiers journaux de vos serveurs applicatifs est celle de votre serveur mandataire inversé et non celle du client réel.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>anakin@tatooine:~$ sudo cat /var/log/apache2/access.log
192.0.2.10 - - [05/Feb/2019:00:00:40 +0100] "GET / HTTP/1.0" 200 6458
</code></pre></div></div>
<p>Nous constatons dans l’exemple précédent que l’adresse IP indiquée est celle du serveur mandataire inverse et non celle de la source réel de la requête http. Heureusement, le reverse-proxy peut générer deux en-têtes http permettant de fournir aux serveurs web présents en arrière-plan l’adresse IP de l’émetteur de la requête http originale : X-Forwarded-For et X-Real-IP.</p>
<p>Le RFC 7239 définit plus précisément le fonctionnement du mécanisme Forwarded. À noter qu’il existe également un en-tête Forwarded qui permettrait d’ajouter un mécanisme d’authentification (token) qui garantirait l’identité du reverse-proxy.
X-Forwarded-For fournit l’adresse IP du client d’origine ainsi que l’adresse des différents répartiteurs de charge ou serveurs mandataires inversés sollicités. Concernant l’en-tête X-Real-IP, je n’ai pas trouvé d’informations précises sur son mode de fonctionnement. Il semblerait qu’il permette de fournir l’adresse IP du client qui est pour le reverse-proxy, l’hôte qui lui a envoyé la requête.</p>
<h2 id="3-configurations">3. Configurations</h2>
<h1 id="a-le-reverse-proxy">a. Le reverse-proxy</h1>
<p>Dans un premier temps, il est nécessaire de configurer le reverse-proxy (basé ici sur nginx) afin qu’il ajoute les en-têtes nécessaires aux requêtes http qu’il transmettra aux serveurs web situés en arrière-plan. Ces derniers pourront ainsi utiliser l’une des deux en-têtes pour récupérer l’adresse IP réelle de l’émetteur.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>vador@mustafar:~$ sudo nano /etc/nginx/sites-available/reverse
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
</code></pre></div></div>
<h1 id="b-le-cas-dun-serveur-apache-en-arrière-plan">b. Le cas d’un serveur Apache en arrière-plan</h1>
<p>Dans un second temps, nous allons nous occuper des serveurs situés à l’arrière-plan. Si vous diposez de serveurs fonctionnant avec le service Apache alors voici les différentes étapes nécessaires pour permettre à celui-ci de récupérer l’information désirée :</p>
<p><code class="language-plaintext highlighter-rouge">anakin@tatooine:~$ sudo a2enmod remoteip</code></p>
<p>Puis nous allons configurer ce module :</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>anakin@tatooine:~$ sudo nano /etc/apache2/conf-available/remoteip.conf
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 192.0.2.10
anakin@tatooine:~$ sudo a2enconf remoteip
</code></pre></div></div>
<p>Nous allons maintenant spécifié dans la configuration globale du service web que nous souhaitons que ce soit l’adresse IP du client et non du serveur mandataire inversé qui soient pris en compte dans les logs :</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>anakin@tatooine:~$ sudo nano /etc/apache2/apache2.conf
LogFormat "%v:%p %a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%a %l %u %t \"%r\" %>s %O" common
</code></pre></div></div>
<p>Ici l’important est le %a. Si l’on s’en réfère à la documentation officielle de Apache 2, cette variable permet d’afficher l’adresse IP distante et non celle du reverse-proxy dans les fichiers journaux.</p>
<p>Enfin il est nécessaire de recharger la configuration de notre service Apache :</p>
<p><code class="language-plaintext highlighter-rouge">anakin@tatooine:~$ sudo systemctl reload apache2</code></p>
<p>Un petit tour dans les logs du serveur :</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>anakin@tatooine:~$ sudo cat /var/log/apache2/access.log
69.89.31.134 - - [05/Feb/2019:00:00:40 +0100] "GET / HTTP/1.0" 200 6458
</code></pre></div></div>
<h1 id="c-le-cas-dun-serveur-nginx-en-arrière-plan">c. Le cas d’un serveur nginx en arrière-plan</h1>
<p>Il se peut que vous ayez plutôt un autre service nginx en arrière-plan. Dans ce cas, la configuration n’est pas la même que celle du service Apache. Voici les étapes nécessaires si vous avez fait le choix d’utiliser ce service :</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>yoda@dagobah:~$ sudo nano /etc/nginx/nginx.conf
log_format specialLog '$remote_addr forwarded for $http_x_real_ip - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';
yoda@dagobah:~$ sudo systemctl reload nginx
</code></pre></div></div>
<p>Un petit tour dans les logs du serveur :</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>yoda@dagobah:~$ sudo cat /var/log/nginx/access.log
69.89.31.134 forwarded for 69.89.31.134 - - [05/Feb/2019:00:00:40 +0100] "GET / HTTP/1.1" 200 728 "-" "-"
</code></pre></div></div>
<h2 id="4-conclusion">4. Conclusion</h2>
<p>Voilà ! Si vous avez des remarques, des corrections ou des précisions à apporter sur mon article, n’hésitez pas ! Ce sera avec plaisir que je les prendrai en compte.</p>
<p>Enjoy :D</p>1. PréambuleÀ propos de mes publications2018-11-05T09:53:25+01:002018-11-05T09:53:25+01:00http://172.16.255.10:4000/humeur/2018/11/05/publications<p>Comme vous avez pu le constater, l’intégralité de ce que je publie sur ce blog est sous <a href="https://creativecommons.org/licenses/by-nc-sa/4.0/">GNU Free Documentation License 1.3</a>. J’ai fait également le choix d’utiliser une licence <a href="https://creativecommons.org/licenses/by-nc-sa/4.0/">Creative Commons CC BY-NC-SA 4.0</a> pour l’ensemble de mes productions dans le domaine professionnel.</p>
<p>Quels sont les arguments qui m’ont amené à choisir ce type de licence ?</p>
<ol>
<li>Je crois que la culture, les connaissances, les savoirs sont les biens communs de l’humanité et que n’importe qui doit pouvoir y accéder sans discrimination ou ségrégation.</li>
<li>Mes idées et mon savoir sont les miens mais je n’aurais pu les construire seul. Je les ai moi-même puisé auprès d’autres en me réappropriant des idées, des concepts, en les modifiant ou en les complétant.</li>
<li>Internet est l’outil dont s’est doté l’humanité pour favoriser cette démarche. Le savoir encyclopédique n’est plus au main uniquement des universitaires, savants, ou experts.</li>
<li>Dans le domaine des idées et des savoirs, il n’y a pas de notion de vol ou de soustraction. Lorsque je partage une idée ou un savoir, je ne les perds pas, je les conserve et je les diffuse. Ainsi, l’effet produit est plutôt une multiplication qu’une soustraction.</li>
<li>Je crois enfin au libre partage et à la diffusion du savoir, de la culture, des idées comme facteurs mélioratifs pour tous les individus.</li>
</ol>
<p>Si vous souhaitez creuser et approfondir ces concepts, je vous mets quelques liens à disposition :</p>
<p><a href="https://fr.wikipedia.org/wiki/Creative_Commons">https://fr.wikipedia.org/wiki/Creative_Commons</a></p>
<p><a href="https://fr.wikipedia.org/wiki/Licence_de_documentation_libre_GNU">https://fr.wikipedia.org/wiki/Licence_de_documentation_libre_GNU</a></p>
<p><a href="https://peertube.fr/videos/watch/69bb6e90-ec0f-49a3-9e28-41792f4a7c5f">https://peertube.fr/videos/watch/69bb6e90-ec0f-49a3-9e28-41792f4a7c5f</a></p>
<p><a href="https://www.youtube.com/watch?v=9GrPSt16WIE">https://www.youtube.com/watch?v=9GrPSt16WIE</a></p>Comme vous avez pu le constater, l’intégralité de ce que je publie sur ce blog est sous GNU Free Documentation License 1.3. J’ai fait également le choix d’utiliser une licence Creative Commons CC BY-NC-SA 4.0 pour l’ensemble de mes productions dans le domaine professionnel.Migration vers Devuan Testing Beowulf2018-10-30T09:53:25+01:002018-10-30T09:53:25+01:00http://172.16.255.10:4000/linux/2018/10/30/devuan-beowulf<p>J’ai décidé, il y a de cela plusieurs semaines, de migrer de Devuan ASCII vers Devuan Beowulf. J’ai toujours fait le choix de prendre des versions testing de Debian-Devuan sur mes machines de bureau. Cela me permet de conserver tous les atouts de cette distribution en ayant un système semi-rolling release.</p>
<p>Alors que je n’avais eu aucun souci depuis 2 ans avec la version testing de Devuan, la mise à jour vers Beowulf m’a généré un petit crash en bonne et due forme. J’ai pu finalisé l’installation après quelques réinstallations de paquets à la miminne via une clef USB (apt-get me générait un gros fail). Hormis cet incident, le passage à la nouvelle version testing semblait s’être bien passée. Je constatais quand même un bug avec XFCE. Je n’avais plus du tout accès aux boutons Redémarrer-Arrêter-Suspendre.</p>
<p>Mes recherches sur le web faisaient apparaître un problème de permission entre mon Display Manager (LightDM-Greeter) et PolicyKit (qui dépend lui même de ConsoleKit, dbus et systemd). Je suis donc allé sur le forum de Devuan et je suis tombé sur cet excellent topic :</p>
<ul>
<li><a href="http://dev1galaxy.org/viewtopic.php?id=2301">http://dev1galaxy.org/viewtopic.php?id=2301</a></li>
</ul>
<p>On y apprend que lorsque l’on migre de ascii à testing, les paquets de substitutions à systemd reposant sur elogind sont absents. Il est donc indispensable de les conserver depuis la version stable et de mettre en place des priorités via les apt-pinning afin que certaines librairies liées à elogind ne soient pas mises à jour.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>tom@bombadil:~$ sudo nano /etc/apt/sources.list
# On rajoute les dépots de la Devuan stable temporairement pour installer elogind
deb http://fr.mirror.devuan.org/merged/ stable main contrib non-free
deb-src http://fr.mirror.devuan.org/merged/ stable main contrib non-free
# Dépôts de la version testing de Devuan
deb http://fr.mirror.devuan.org/merged/ beowulf main contrib non-free
deb-src http://fr.mirror.devuan.org/merged/ beowulf main contrib non-free
# beowulf-security, previously known as 'volatile'
deb http://fr.mirror.devuan.org/merged/ beowulf-security main contrib non-free
deb-src http://fr.mirror.devuan.org/merged/ beowulf-security main contrib non-free
# beowulf-updates, previously known as 'volatile'
deb http://fr.mirror.devuan.org/merged/ beowulf-updates main contrib non-free
deb-src http://fr.mirror.devuan.org/merged/ beowulf-updates main contrib non-free
# backports
deb http://fr.mirror.devuan.org/merged/ beowulf-proposed-updates main contrib non-free
deb-src http://fr.mirror.devuan.org/merged/ beowulf-proposed-updates main contrib non-free
</code></pre></div></div>
<p>On crée maintenant un fichier permettant de définir des priorités afin que certains paquets liés à elogind ne soient pas upgradés via les dépots testing.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>tom@bombadil:~$ sudo nano /etc/apt/preferences.d/avoid-systemd
Package: policykit-1
Pin: release a=beowulf
Pin-Priority: -1
Package: libpolkit-agent-1-0
Pin: release a=beowulf
Pin-Priority: -1
Package: libpolkit-backend-1-0
Pin: release a=beowulf
Pin-Priority: -1
Package: libpolkit-gobject-1-0
Pin: release a=beowulf
Pin-Priority: -1
</code></pre></div></div>
<p>Nous pouvons maintenant réinstaller elogind et l’ensemble de ses dépendances via apt, apt-get ou aptitude.</p>
<p><code class="language-plaintext highlighter-rouge">tom@bombadil:~$ sudo aptitude install -t stable elogind eudev libpam-elogind libelogind0 libeudev1 libpolkit-backend-elogind-1-0 libpolkit-gobject-elogind-1-0</code></p>
<p>Vous pouvez maintenant commenter ou supprimer les lignes concernant la version stable de Devuan présents dans /etc/apt/sources.list. Puis il est nécessaire de modifier le fichier /etc/pam.d/lightdm-greeter afin de préciser que l’on utilise elogind et non pas systemd (http://dev1galaxy.org/viewtopic.php?id=2282).</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>tom@bombadil:~$ sudo nano /etc/pam.d/lightdm-greeter
#session optional pam_systemd.so
session optional pam_elogind.so
</code></pre></div></div>
<p>Je me retrouve maintenant avec une Devuan Beowulf totalement fonctionnelle et un XFCE qui tourne bien. Il me reste encore quelques points à creuser notamment sur la possibilité d’installer un applet XFCE pour ALSA (oui je ne veux pas de pulseaudio, comprenne qui voudra). Malheureusement, les seuls applets Son disponibles sur XFCE 4.12 fonctionnent uniquement avec pulse audio. Si vous avez des tuyaux, je suis preneur.</p>
<p>:D</p>J’ai décidé, il y a de cela plusieurs semaines, de migrer de Devuan ASCII vers Devuan Beowulf. J’ai toujours fait le choix de prendre des versions testing de Debian-Devuan sur mes machines de bureau. Cela me permet de conserver tous les atouts de cette distribution en ayant un système semi-rolling release.