mov ah,31h int 21h

Utilisation d'un kernel Mainline sous Ubuntu

2020-04-05T12:30:00+02:00

Salut à tous. Petite mise à jour après une longue absence pour vous parler de Kernel Linux dans sa version mainline, et de son installation sous Ubuntu quand vous utiliser SecureBoot (surement sans le savoir).

Introduction

Commençons par une simple question, pourquoi?

Plusieurs raison pour installer le kernel mainline:

Une version plus récente que le kernel fourni par Ubuntu est disponible, et celle-ci apporte des améliorations sur un ou plusieurs drivers dont vous avez besoin.
Vous développer un driver et avez besoin de la toute dernière version pour celui-ci.
Vous aimez vivre dangeureusement.

Personellement, ma nouvelle carte graphique, une Radeon RX5500 XT 8Go, basé sur l'architecture RDNA de AMD va bientôt arriver à la maison. Et coté driver, la dernier version 5.6 du kernel Linux apporte beaucoup d'amélioration. Voir sur le site Phoronix les pages Running The Linux 5.6 Kernel With AMD Radeon Graphics et Linux 5.6 Is The Most Exciting Kernel In Years.

Donc, j'anticipe un petit peu l'installation de cette version du kernel Linux sous Ubuntu 19.10.

Installation

L'installation du kernel mainline sur Ubuntu 19.10 est relativement simple. Il suffit de télécharger les packages .deb sur le site officiel des kernel Mainline pour Ubuntu.

Aller sur la page MainlineBuilds et naviguer vers le répertoire du dernier kernel disponible ici (5.6.2 à l'heure d'écrire cette petite page).

Puis télécharger tous les fichiers .deb nécessaire à votre architecture et vos besoins (kernel normal vs. lowlatency) ainsi que les fichiers CHECKSUMS. La liste si dessous pour mon cas:

CHECKSUMS
CHECKSUMS.gpg
linux-headers-5.6.2-050602_5.6.2-050602.202004020822_all.deb
linux-headers-5.6.2-050602-lowlatency_5.6.2-050602.202004020822_amd64.deb
linux-image-unsigned-5.6.2-050602-lowlatency_5.6.2-050602.202004020822_amd64.deb
linux-modules-5.6.2-050602-lowlatency_5.6.2-050602.202004020822_amd64.deb

Après téléchargement, verifiez les signatures des fichiers puis installez les avec la commande suivante:

bureau:~/Téléchargements$ gpg --recv-key "60AA7B6F30434AE68E569963E50C6A0917C622B0"
...

bureau:~/Téléchargements$ gpg --verify CHECKSUMS.gpg CHECKSUMS
gpg: Signature faite le jeu. 02 avril 2020 16:31:29 CEST
gpg:                avec la clef RSA E50C6A0917C622B0
gpg: Bonne signature de « Kernel PPA <kernel-ppa@canonical.com> » [inconnu]
gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
gpg:          Rien n'indique que la signature appartient à son propriétaire.
Empreinte de clef principale : 60AA 7B6F 3043 4AE6 8E56  9963 E50C 6A09 17C6 22B0

bureau:~/Téléchargements$ sha256sum -c --ignore-missing CHECKSUMS
linux-headers-5.6.2-050602_5.6.2-050602.202004020822_all.deb: Réussi
linux-headers-5.6.2-050602-lowlatency_5.6.2-050602.202004020822_amd64.deb: Réussi
linux-image-unsigned-5.6.2-050602-lowlatency_5.6.2-050602.202004020822_amd64.deb: Réussi
linux-modules-5.6.2-050602-lowlatency_5.6.2-050602.202004020822_amd64.deb: Réussi
sha256sum: Attention : 28 lignes ne sont pas correctement formatées

Si tout est OK, et seulement dans ce cas, alors vous pouvez installer:

bureau:~/Téléchargements$ sudo dpkg -i linux-*-5.6.2-*.deb

Et voilà, c'est installé.

Un petit conseil, avant de redémarrer votre ordinateur, assurez-vous que le menu de démarrage Grub est bien affiché au boot. Vérifiez que vous avez bien cette configuration dans le fichier /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=3

Si ce n'étais pas le cas, modifiez le ficher et re-générez la configuration de Grub avec la commande suivante:

bureau:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Sourcing file `/etc/default/grub.d/kdump-tools.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.6.2-050602-lowlatency
Found initrd image: /boot/initrd.img-5.6.2-050602-lowlatency
Found linux image: /boot/vmlinuz-5.3.0-46-generic
Found initrd image: /boot/initrd.img-5.3.0-46-generic
Found linux image: /boot/vmlinuz-5.3.0-45-generic
Found initrd image: /boot/initrd.img-5.3.0-45-generic
Adding boot menu entry for EFI firmware configuration
done

Maintenant, vous pouvez rebooter.

En cas de soucis, par exemple une erreur de chargement du kernel 5.6, selectionnez votre précédent kernel, Ubuntu, with Linux 5.3.0-46-generic dans le sous-menu Advanced options for Ubuntu et démarrez normalement.

Si votre nouveau kernel a bien démarrer, vous avez terminer. Enjoy! Sinon, passez au chapitre suivant.

SecureBoot

Si vous lisez ce chapitre, c'est que tout ne s'est pas bien passé et que vous avez surement été insulté par Grub sous prétexte que le fichier vmlinuz-5.6.2-050602-lowlatency has invalid signature.

Rassurez-vous, il y a une solution que j'ai trouvé sur le blog ubuntu. Pour faire court, j'ai simplement suivi les étapes suivantes indiqué sur cette page (le chapitre Certificates in shim):

Création d'un fichier de configuration pour OpenSSL. (Assurez-vous de bien avoir extendedKeyUsage avec la bonne valeur dedans.)
Création des clés publique et privée, MOK.der & MOK.priv, avec OpenSSL.
Création de la clé publique MOK.pem pour l'outil sbsign.
Signature du kernel.
Enrollement de la clé MOK.der dans shim.

Voici le fichier de configuration OpenSSL utilisé, MOK.cnf:

# This definition stops the following lines choking if HOME isn't
# defined.
HOME                    = .
RANDFILE                = $ENV::HOME/.rnd
[ req ]
distinguished_name      = req_distinguished_name
x509_extensions         = v3
string_mask             = utf8only
prompt                  = no

[ req_distinguished_name ]
countryName             = FR
stateOrProvinceName     = Paris
localityName            = Paris
0.organizationName      = whatyouwant
commonName              = Secure Boot Signing
emailAddress            = example@example.com

[ v3 ]
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer
basicConstraints        = critical,CA:FALSE
extendedKeyUsage        = codeSigning,1.3.6.1.4.1.311.10.3.6,1.3.6.1.4.1.2312.16.1.2
nsComment               = "OpenSSL Generated Certificate"

Et la séquence de commandes shell exécutée:

bureau:~$ openssl req -config ./MOK.cnf \
    -new -x509 -newkey rsa:2048 \
    -nodes -days 36500 -outform DER \
    -keyout "MOK.priv" \
    -out "MOK.der"
...
bureau:~$ openssl x509 -in MOK.der -inform DER -outform PEM -out MOK.pem
bureau:~$ sudo sbsign --key MOK.priv --cert MOK.pem \
    --output /boot/vmlinuz-5.6.2-050602-lowlatency.signed \
    /boot/vmlinuz-5.6.2-050602-lowlatency
...
bureau:~$ sudo mokutil --import MOK.der

Après appel de mokutil, vous devez rebooter pour finaliser l'enrollement de votre clé de signature dans shim qui est le module UEFI chargé avant Grub.

Lors du reboot, un écran bleu (non pas le Blue Screen of Death de Windows) apparait vous permettant de finalizer l'ajout de votre clé. Suivez les étapes à l'écran.

Ensuite, vous arrivez dans Grub. Appuyez sur Echap pour arrêter le décompte. Puis tapez la touche e pour éditer la première entrée.

Vers les dernières lignes, ajoutez .signed à la ligne commençant par linux.

Enfin, appuyez sur F10 ou Ctrl+x pour démarrer avec ce kernel signé.

Et voilà, normalement vous avez démarré sur votre nouveau kernel Mainline Linux 5.6.

Maintenant, remplacez le kernel non signé par la version que vous avez vous-même signé:

bureau:~$ sudo mv /boot/vmlinuz-5.6.2-050602-lowlatency{.signed,}

C'est fini.

Garder cette clé, elle vous permettra de signer les prochains kernels Mainline que vous installerez.

Signature automatique des prochains kernel

Suite à ces manipulations, j'ai ajouté un petit script dans le répertoire /etc/kernel/postinst.d/. Ce script auto-sign-kernel va permettre de signer automatiquement tous les kernels NON-signé que vous installerez comme précedement:

#!/bin/sh -e

KEY=/root/moksign/MOK.priv
CRT=/root/moksign/MOK.pem

version="$1"

# passing the kernel version is required
if [ -z "${version}" ]; then
    echo >&2 "W: auto-sign: ${DPKG_MAINTSCRIPT_PACKAGE:-kernel package} did not pass a version number"
    exit 2
fi

# sbsigntool package is mandatory

command -v sbverify >/dev/null 2>&1 || exit 0
command -v sbsign >/dev/null 2>&1 || exit 0

# check if kernel is already signed
name="/boot/vmlinuz-$version"
check=`sbverify --list $name 2>&1`

if [ "$check" == "No signature table present" ]; then

    # not signed, so sign it with registered MOK key

    echo "Signing kernel $name using personnal MOK key ..."
    sbsign --key $KEY --cert $CRT --output $name.signed $name
    mv ${name}{.signed,}
    echo "Done."

else

    echo "Kernel already signed, no need to sign it."

fi

Voilà, c'est terminé. Si tout se passe bien, quand vous installerez le prochain kernel Mainline, il sera automatiquement signé par ce script avec les clés publique et privée indiquées par les variables KEY & CRT, à modifier selon votre convenance.

Bonne journée.

Décodeur TV UHD Orange avec serveur DNS/DHCP sur NAS

2019-01-15T20:00:00+01:00

Introduction

Suite à l'installation de la Fibre Orange à mon domicile, j'ai souhaité installer le Décodeur TV UHD fourni avec. Hélas, celui-ci bloque dès le premier écran de configuration!

Tous les tests effectués, en Ethernet ou en WiFi ont échoué, donc je me suis résout à contacter le support Orange.

Je vous passe les détails, mais la seule piste qui en est ressorti, c'est que ma configuration de la Livebox 4 et de mon réseau posent problème. En gros, désactiver le serveur DHCP de la Livebox pour utiliser ses propres services DNS/DHCP n'est pas supporté et ne permet plus au décodeur TV de fonctionner! Et le Mr au bout du e-chat voulait limite que j'arrête mon serveur si je voulais la TV!!!

J'ai quand même fouiller un peu plus en regardant les logs coté serveur. Et différents points sont apparus:

Après avoir fourni une adresse DHCP au décodeur, ce dernier fait un certain nombre de requêtes DNS.
Ces requêtes pour la plupart ne retourne aucun résultats!
Si les requêtes sont envoyés à la Livebox ou aux serveurs DNS orange internes, on obtiens les bonnes réponses.

Après avoir corrigé ça avec une zone forward only dans la configuration de Bind9, ça ne fonctionnait toujours pas. Donc ce coup-ci, recherches à grand coup de Google et je suis tombé sur ce topic sur le forum de la communauté Orange dans lequel Blanquet94 envoie cette phrase couperet:

Le décodeur TV a absolument besoin de faire traiter sa requête DHCP par la Livebox sans quoi elle ne le reconnaît pas comme étant un décodeur TV et il ne pourra plus joindre la plateforme de service.

Nouvelles recherches et la conclusion est évidente. Le serveur DHCP de la Livebox 4 doit être actif et donner lui-même une adresse au décodeur!

Par chance, la Livebox 4 permet de spécifier la plage des adresses à fournir et le démon DHCPD sur le serveur peut ignorer un client spécifique.

Reconfiguration de la Livebox 4

C'est le plus simple. L'idée c'est que le serveur DHCP de la Livebox ne donne une IP qu'au décodeur, et uniquement à lui.

Donc:

On active le serveur DHCP,
On change la plage d'adresses pour n'avoir que 2 adresses IP possibles,
On ajoute les 2 adresses MAC du décodeur TV (Ethernet et WiFi) comme entrées statiques du serveur DHCP.

Avec cette configuration, le serveur DHCP n'est plus en mesure de donner des IPs à toutes les autres machines du réseau, et donc ne répond qu'aux demandes du décodeur et plus aux autres machines sur le réseau.

Modification de la configuration dhcpd

Du coté de mon serveur, il doit simplement ignorer les requêtes provenant du décodeur TV d'Orange.

Ça a l'air facile, mais c'est ce qui m'a pris le plus de temps!

Premièrement, il faut définir une classe dans le fichier de configuration /etc/dhcp/dhcpd.conf:

class "orange" {
  # exclude orange decodeur from pool! Ie. 30:24:78:8d:00:98/30:24:78:8d:00:9a
  match if substring (hardware,1,4) = 30:24:78:8d;
}

J'ai bataillé pas mal avec la directive hardware et la fonction substring, mais finalement log(), concat() et plus généralement man dhcp-eval sont nos amis! La mailing-list dhcp-users est aussi une bonne aide!

Ensuite, il faut ajouter la directive deny dans tous les pools définis, après les directives allow éventuelles:

subnet 192.168.0.0 netmask 255.255.255.0 {
  #...
  pool {
    range 192.168.0.24 192.168.0.63;
    allow unknown-clients;
    deny members of "orange";
  }
}

Ensuite, redémarrer dhcpd pour prendre en compte la nouvelle configuration. Vous devriez voir apparaître cette ligne dans les logs quand vous allumer le décodeur TV:

root@serveur:~# journalctl -u isc-dhcp-server.service -f
janv. 15 14:40:51 serveur dhcpd[26774]: DHCPDISCOVER from 30:24:78:8d:00:9a via eth0: network 192.168.0.0/24: no free leases

That's all! Le décodeur a enfin son IP en provenance de la Livebox. Celle-ci ne perturbe pas les autres clients qui continuent de recevoir leur IP du serveur principal.

Conclusion

Merci encore à la communauté d'utilisateurs, que ce soit celle d'orange ou de ISC Bind/DHCP pour toutes les informations qui permettent de débloquer une situation.

Par contre, Sagem et Orange, je dirais pas ce que je pense de leur matos ni de leur support...

Streamer la caméra du Raspberry Pi

2019-01-10T20:00:00+01:00

Introduction

En tant que possesseur d'une caméra sur mon Raspberry Pi 3B, je voulais pouvoir streamer le flux vidéo à la demande, sans avoir recours à des programmes externes.

Après avoir testé pendant quelques temps le mode serveur TCP du programme raspivid via l'option -o tcp://0.0.0.0:3333, je n'étais pas très satisfait. Cela m'obligeait à avoir un script qui relance automatiquement le programme après chaque déconnexion d'un client. De plus, le programme raspivid, plus le script shell, plus la session tmux, ça commence à faire beaucoup pour un truc qui n'est quasiment jamais utilisé!

Vu la distribution Raspbian qui équipe le Raspberry Pi est basé sur Debian, et que celui-ci utilise systemd depuis stretch, j'ai décidé d'ajouter un service pour le streaming.

Plusieurs avantages à utiliser systemd ici:

Pas besoin d'installer un gestionnaire de service réseau tel que inetd ou xinetd car c'est déjà possible avec systemd.
Pas de processus supplémentaire qui s'exécute tant qu'il n'y a aucun client qui souhaite recevoir le flux vidéo.
On bénéficie naturellement du journal de systemd pour le suivi du service.
C'est l'avenir, n'en déplaise à ses détracteurs.

Mise en place du service

Pour commencer, on va stocker dans un fichier séparé les options à utiliser pour lancer raspivid. Si dessous le fichier /etc/default/raspivid:

RASPIVID_OPTIONS = -w 1280 -h 720 -a 12 -fl -ih -b 800000 -fps 25 -pf main -g 25 -awb auto

Bien sur, vous pouvez adapter ces options là à votre besoin.

Ensuite on attaque la configuration du service. Pour un service activé à la demande via une connexion réseau, systemd requière la mise en place de 2 unités:

Un fichier nom.socket qui décrit le type de connexion réseaux qui va activer le service.
Un fichier nom@.service qui décrit le processus à exécuter lorsqu'un client se connecte à la connexion réseaux décrite par nom.socket.

Si dessous, mon fichier raspvid.socket qui active une socket TCP écoutant sur le port 3333 sur toutes les interfaces réseaux locales, en IPv4 ou IPv6:

[Unit]
Description=Raspivid Streaming Socket

[Socket]
ListenStream=3333
Accept=yes
MaxConnections=1
SendBuffer=1M

[Install]
WantedBy=sockets.target

Cette unité systemd sera mise en place dans la cible socket.target quand elle sera activée. Elle indique aussi que c'est à systemd d'accepter la connexion entrante, comme le fait inetd ou xinetd et qu'il ne peut y avoir qu'une seule connexion à la fois.

Si dessous le service associé qui sera lancé à chaque nouvelle connexion. Le fichier doit avoir le même nom de base mais suivi de @ et avec l'extension .service (voir man systemd.socket). Ici, c'est donc raspivid@.service:

[Unit]
Description=Raspivid Streaming Instance

[Service]
EnvironmentFile=-/etc/default/raspivid
ExecStart=-/usr/bin/env raspivid $RASPIVID_OPTIONS -v -n -t 0 -o -
StandardInput=socket
StandardError=journal

Le service est configuré pour utiliser la socket acceptée comme entrée/sortie standard et la sortie d'erreur est redirigée vers le journal.

Le caractère - juste après le = est nécessaire pour ignorer une éventuelle erreur lorsque le service se termine. Idem pour le fichier de configuration.

Il ne reste plus qu'à l'activer:

raspberrypi:~# systemctl enable raspivid.socket
Created symlink /etc/systemd/system/sockets.target.wants/raspivid.socket → /etc/systemd/system/raspivid.socket.
raspberrypi:~# systemctl status raspivid.socket
● raspivid.socket - Raspivid Streaming Socket
   Loaded: loaded (/etc/systemd/system/raspivid.socket; enabled; vendor preset: enabled)
   Active: active (listening) since Tue 2019-01-08 12:31:12 CET; 1 day 3h ago
   Listen: [::]:3333 (Stream)
 Accepted: 0; Connected: 0

janv. 08 12:31:12 raspberrypi systemd[1]: Listening on Raspivid Streaming Socket.

That's all! Maintenant, utiliser votre application de streaming préféré et ouvrez le flux réseau tcp://raspberrypi.local:3333.

Une nouvelle instance du service raspivid@.service est lancée. Par exemple raspivid@0-192.168.0.6:3333-192.168.0.4:41722.service.

raspberrypi:~# journalctl -u raspivid@0-192.168.0.6:3333-192.168.0.4:41722.service
-- Logs begin at Thu 2016-11-03 18:16:42 CET, end at Wed 2019-01-09 16:20:01 CET. --
janv. 08 15:05:55 raspberrypi systemd[1]: Started Raspivid Streaming Instance (192.168.0.4:41722).
janv. 08 15:05:55 raspberrypi raspivid[18482]: "raspivid" Camera App (commit 68e08be38191)
janv. 08 15:05:55 raspberrypi raspivid[18482]: Camera Name imx219
janv. 08 15:05:55 raspberrypi raspivid[18482]: Width 1280, Height 720, filename -
janv. 08 15:05:55 raspberrypi raspivid[18482]: Using camera 0, sensor mode 0
janv. 08 15:05:55 raspberrypi raspivid[18482]: GPS output Disabled
janv. 08 15:05:55 raspberrypi raspivid[18482]: bitrate 800000, framerate 25, time delay 0
janv. 08 15:05:55 raspberrypi raspivid[18482]: H264 Profile main
janv. 08 15:05:55 raspberrypi raspivid[18482]: H264 Level 4
janv. 08 15:05:55 raspberrypi raspivid[18482]: H264 Quantisation level 0, Inline headers Yes
janv. 08 15:05:55 raspberrypi raspivid[18482]: H264 Fill SPS Timings No
janv. 08 15:05:55 raspberrypi raspivid[18482]: H264 Intra refresh type (null), period 25
janv. 08 15:05:55 raspberrypi raspivid[18482]: H264 Slices 1
janv. 08 15:05:55 raspberrypi raspivid[18482]: Wait method : Capture forever
janv. 08 15:05:55 raspberrypi raspivid[18482]: Initial state 'record'
janv. 08 15:05:55 raspberrypi raspivid[18482]: Preview No, Full screen Yes
janv. 08 15:05:55 raspberrypi raspivid[18482]: Preview window 0,0,1024,768
janv. 08 15:05:55 raspberrypi raspivid[18482]: Opacity 255
janv. 08 15:05:55 raspberrypi raspivid[18482]: Sharpness 0, Contrast 0, Brightness 50
janv. 08 15:05:55 raspberrypi raspivid[18482]: Saturation 0, ISO 0, Video Stabilisation No, Exposure compensation 3
janv. 08 15:05:55 raspberrypi raspivid[18482]: Exposure Mode 'nightpreview', AWB Mode 'auto', Image Effect 'none'
janv. 08 15:05:55 raspberrypi raspivid[18482]: Flicker Avoid Mode 'off'
janv. 08 15:05:55 raspberrypi raspivid[18482]: Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
janv. 08 15:05:55 raspberrypi raspivid[18482]: Rotation 0, hflip No, vflip No
janv. 08 15:05:55 raspberrypi raspivid[18482]: ROI x 0.000000, y 0.000000, w 1.000000 h 1.000000
janv. 08 15:05:55 raspberrypi raspivid[18482]: Camera component done
janv. 08 15:05:55 raspberrypi raspivid[18482]: Encoder component done
janv. 08 15:05:55 raspberrypi raspivid[18482]: Starting component connection stage
janv. 08 15:05:55 raspberrypi raspivid[18482]: Connecting camera video port to encoder input port
janv. 08 15:05:56 raspberrypi raspivid[18482]: Enabling encoder output port
janv. 08 15:05:56 raspberrypi raspivid[18482]: Starting video capture
janv. 08 15:06:47 raspberrypi raspivid[18482]: mmal: Failed to write buffer data (4096 from 5109)- aborting
janv. 08 15:06:47 raspberrypi raspivid[18482]: Finished capture
janv. 08 15:06:47 raspberrypi raspivid[18482]: Closing down
janv. 08 15:06:47 raspberrypi raspivid[18482]: Close down completed, all components disconnected, disabled and destroyed

Attention, le programme raspivid a été patché pour qu'il se termine correctement quand le client se déconnecte. Voir le patch soumis au projet raspberrypi/userland sur Github.

Trafic SMTP(S)/IMAP via tunnel OpenVPN

2019-01-09T08:30:00+01:00

Introduction

Cette article fait suite à mon précédent article décrivant la mise en place d'un monitoring avec Munin pour mon nouveau VPS chez OVH.

Pour rappel, la mise en place de ce serveur VPS chez OVH fait suite à un changement de fournisseur d'accès internet, et la perte prochaine de mon adresse IPv4 fixe que celui-ci m'offrait gracieusement depuis quasiment 10 ans.

Sachant que mon serveur mail est auto-hébergé à mon domicile, la perte de l'adresse IPv4 fixe, ainsi que la possibilité de configurer le reverse DNS pour celle-ci est très problématique. Une IPv4 fixe est obligatoire pour mettre en place l'enregistrement MX dans le DNS pour que les emails arrivent sur le serveur.

Ajouté au blocage du trafic SMTP sortant imposé par mon futur opérateur, deux solutions s'offraient à moi:

Déplacer le serveur mail dans son intégralité sur mon VPS.
Garder le serveur mail à la maison, mais faire passer tout le trafic mail par le VPS.

Sachant que le VPS ne support pas le RAID et qu'il possède qu'une quantité très limité pour le stockage, j'ai décidé d'utiliser la solution du tunnel.

Mise en place du tunnel OpenVPN

Afin de simplifier la mise en place du VPN, celui-ci est dédié à la communication entre le VPS et le serveur chez moi que j'appellerais dorénavant Maison.

Il n'utilisera donc pas de certificats RSA, pas de KPI locale à gérer, pas de certificats à révoquer. Uniquement une clef statique partagée entre les 2 protagonistes.

L'installation dans ces conditions sur Debian stretch est très simple. Sur le VPS:

vps:~# apt install openvpn
...
vps:~# cd /etc/openvpn/serveur
vps:/etc/openvpn/serveur# openvpn --genkey --secret static.key
vps:/etc/openvpn/serveur# cat >tun0.conf <<EOF
dev tun0
ifconfig 172.16.123.1 172.16.123.2
secret static.key
cipher AES-256-CBC
;script-security 2
;route-up ./tun0.up
compress lz4
keepalive 15 60
persist-tun
persist-key
verb 3
EOF
vps:/etc/openvpn/serveur# systemctl enable openvpn-server@tun0.service

Si un firewall est actif sur le VPS, ce qui est extrêmement important, il faut autoriser le trafic OpenVPN. Ici, j'utilise UFW:

vps:~# cat >/etc/ufw/applications.d/openvpn-server <<EOF
[OpenVPN]
title=OpenVPN server
description=OpenVPN is a free secure VPN client/server implementation.
ports=1194/udp
EOF
vps:~# ufw allow OpenVPN
...

Sur Maison:

maison:~# apt install openvpn
...
maison:~# cd /etc/openvpn/client
maison:/etc/openvpn/client# cat >tun0.conf <<EOF
remote vps.example.com
dev tun0
ifconfig 172.16.123.2 172.16.123.1
secret static.key
cipher AES-256-CBC
;script-security 2
;route-up ./tun0.up
compress lz4
verb 3
EOF
maison:/etc/openvpn/client# systemctl enable openvpn-client@tun0.service

Puis copier le fichier static.key depuis le VPS vers Maison et mettez le dans /etc/openvpn/client. Veillez aux droits d'accès à ce fichier sur les 2 machines.

Vous pouvez dès maintenant lancer le tunnel en démarrant le service sur les 2 machines en même temps (ils s'attendent mutuellement).

vps:~# systemctl start openvpn-serveur@tun0.service

maison:~# systemctl start openvpn-client@tun0.service

Normalement, là, si tout se passe bien, un tunnel est actif et les 2 machines peuvent se pinguer via les IPs configurées (172.16.123.1 & 172.16.123.2).

vps:~# ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 172.16.123.1  netmask 255.255.255.255  destination 172.16.123.2
        inet6 fe80::ae7e:a7b8:b8dc:8e94  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 30082  bytes 8228000 (7.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 18936  bytes 4815846 (4.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Il reste maintenant à faire transiter le traffic mail entrant et sortant de Maison par ce tunnel.

Routage du trafic email via le tunnel

C'est la partie la plus compliquée. 2 configurations distinctes doivent être en place. La première, sur VPS, doit forwarder le trafic venant du tunnel vers internet, en changeant l'IP source (SNAT) et doit forwarder le trafic entrant sur le VPS vers le tunnel si et seulement si, c'est du trafic email.

Par commodité, les règles iptables pour le NAT sont mise en place automatiquement par OpenVPN après l'établissement des routes.

vps:~# cat >/etc/openvpn/server/tun0.up <<EOF
#!/bin/bash
# Forwarding is already configured by UFW at boot time.
echo "Set SMTP routing to/from tunnel peer"
# Incomming SMTP(S)/IMAPS connections are DNATed.
iptables -t nat -F PREROUTING
iptables -t nat -A PREROUTING -i ens3 -d 145.239.85.142/32 -p tcp --dport 25 -j DNAT --to-destination 172.16.123.2
iptables -t nat -A PREROUTING -i ens3 -d 145.239.85.142/32 -p tcp --dport 465 -j DNAT --to-destination 172.16.123.2
iptables -t nat -A PREROUTING -i ens3 -d 145.239.85.142/32 -p tcp --dport 993 -j DNAT --to-destination 172.16.123.2
# Outgoing SMTP connections are SNATed.
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -o ens3 -s 172.16.123.2/32 -p tcp --dport 25 -j SNAT --to-source 145.239.85.142
EOF

Comme vous pouvez le voir, il n'y a qu'un seul type de connexion sortante. Celles sur le port de destination 25 utilisé par le serveur pour envoyer les email aux serveurs des destinataires.

Le firewall doit aussi autoriser ce trafic:

vps:~# ufw route allow in on ens3 out on tun0 proto tcp to 172.16.123.2 port 25
vps:~# ufw route allow in on ens3 out on tun0 proto tcp to 172.16.123.2 port 465
vps:~# ufw route allow in on ens3 out on tun0 proto tcp to 172.16.123.2 port 993
vps:~# ufw route allow out on ens3 in on tun0 proto tcp to any port 25 from 172.16.123.2

Voilà, le VPS est prêt pour recevoir tout le trafic SMTP(S)/IMAPS. N'oubliez pas de supprimer les ; dans le fichier tun0.conf créé au précédent chapitre pour que OpenVPN puisse lancer le script qui contient les nouvelles règles iptables.

Vous pouvez relancer le service openvpn maintenant.

Le champ MX de la zone DNS pourrait déjà être mise à jour, mais on va attendre un petit peu car en l'état, impossible de recevoir un email. Si vous tester avec telnet, vous verrez qu'il est impossible de se connecter à VPS sur le port 25.

La demande de connexion (TCP SYN) est bien forwarder vers Maison via le tunnel, mais la réponse n'arrive jamais sur l'interface tun0 (tcpdump -i tun0 -n -v 0 tcp port 25 ne voit passer que les SYN).

Ceci est du aux règles de routage qui doivent être adapté. Plus précisément, il faut faire du routage en fonction de la source pour le trafic email.

Cela nécessite de créer une nouvelle table de routage en éditant la configuration iproute2. Ajouter la ligne suivant dans /etc/iproute2/rt_tables:

maison:~# echo "100 vpn" >>/etc/iproute2_rt_tables

Puis créer le script de configuration tun0.up:

maison:/etc/openvpn/client# cat >tun0.up <<EOF
#!/bin/bash
echo "Set SMTP routing to tunnel peer"
iptables -t mangle -F OUTPUT
iptables -t nat -F POSTROUTING
iptables -t nat -F PREROUTING
# add a default route throw tunnel for marked traffic
ip route del default table vpn
ip route add default via 172.16.123.1 dev tun0 table vpn
ip rule del fwmark 0x1 table vpn
ip rule add fwmark 0x1 table vpn
# mark all smtp output traffic so that iproute can route it through tun0
iptables -t mangle -A OUTPUT -o eth0 -p tcp --dport 25 -j MARK --set-mark 0x1
# mark all output from tun0 addr to route back through tun0
iptables -t mangle -A OUTPUT -o eth0 -s 172.16.123.2/32 -j MARK --set-mark 0x1
# and rewrite the src-addr of outgoing SMTP connection
iptables -t nat -A POSTROUTING -o tun0 -p tcp --dport 25 -j SNAT --to-source 172.16.123.2
EOF

C'est un peu plus compliqué. On commence par (re-)créer une nouvelle route par défaut dans la table de routage spécialement pour le tunnel qui s'appelle vpn.

Ensuite, on ajoute une rule pour activer l'usage de cette table de routage pour tous les paquets qui sont marqués avec la valeur 0x1.

Ensuite avec la table mangle de iptables, on marque tout le trafic vers les serveurs SMTP et le trafic associé à l'IP local du tunnel.

Enfin, on s'assure que les connexions sortantes vers les serveurs SMTP ont toutes pour origine l'IP locale du tunnel.

Tout est enfin prêt. Maintenant, redémarrage du tunnel en relançant le service openvpn sur les 2 machines, modification et vérification des champs MX et SPF dans la zone DNS.

Et voilà! Tout le trafic email passe par le VPN.

Pourquoi ce nom?

2019-01-04T16:42:00+01:00

Vous vous posez peut-être la question, mais pourquoi ce nom int21h.eu?

C'est relativement simple. C'est en rapport à mon apprentissage de l'informatique dans les années 90. Plus précisément vers 1991 quand j'ai commencé à développer des programmes résidents sous MS-DOS en Assembleur x86.

C'est l'époque de mes premiers hacks et ce site est un petit peu un hommage à mon premier programme résident utile, dévelopé pour protéger l'accès à mon répertoire de travail sur l'un des PC de la salle informatique du lycée où j'étais en Sup-TA.

Ce programme était relativement simple et léger. Il:

détournait l'interuption 21h (la principale interruption de l'API MS-DOS),
détectait l'usage des fonctions 3Ah jusqu'à 3Dh ainsi que la fonction 41h et verifiait les arguments pour interdire l'accès et l'écriture dans un répertoire protégé,
se terminait en restant résident via l'usage de la fonction 31h.

Associé à un autre hack (édition direct du système de fichier FAT16 pour ajouter une entrée de répertoire récursive), et l'outils PCTOOLS plantait lamentable lors de l'analyse du disque dur quand il atteignait le répertoire protégé.

Mes camarades et moi pouvions alors stocker sur les PC de la salle info des données personnelles et nos développements en cours sans risques d'être effacés par le professeur qui en avait la charge.

Connection à un Munin-node via SSH

2018-12-29T08:30:00+01:00

Suite à la mise en place d'un VPS sous Debian Stretch chez OVH afin de conserver une adresse IPv4 fixe pour mon serveur email hébergé chez moi (je vous passe les détails qui m'oblige à utiliser un VPS), je souhaite monitorer celui-ci avec la solution déjà mise en place sur mon server principal utilisant Munin.

Afin de minimiser les ressources utilisées sur ce serveur VPS, j'ai installé les paquets debian suivant:

munin-node-c et munin-plugins-c pour le node Munin et les plugins en C.
munin-plugins-core et munin-plugins-extra pour quelques plugins additionnels en Perl non implémentés en C (fail2ban par exemple).

Et là, un gros souci est apparu. Comment le serveur principal va communiquer avec le serveur VPS pour le traffic Munin sachant que munin-node-c ne supporte pas une connexion TLS?

Plusieurs solutions:

Un tunnel VPN entre mon serveur et le VPS
Un tunnel SSH avec port-forwarding
Une connexion SSH directement.

C'est la 3ieme solution qui a été choisi après analyse du code Perl du programe munin-update et plus spécialement de /usr/share/perl5/Munin/Master/Node.pm.

Ce dernier permet d'utiliser une connexion SSH pour lancer un programe sur le serveur distant. Pour ce faire, l'URL à utiliser doit avoir le format suivant:

[host.example.com]
address = ssh://user@host.example.com/path/to/program parameters

De plus, afin de permettre une connexion sans mot de passe au node Munin sur mon serveur VPS par le processus munin-update, j'ai créé une clef privée SSH que j'ai installée pour l'utilisateur munin dans /var/lib/munin/.ssh sur mon serveur principal.

Sachant que munin-node-c utilise inetd et est lancé automatiquement lors d'une connexion sur le port 4949, il ne reste plus qu'à relier la connexion SSH et le service lancé par inetd. C'est là que netcat intervient. Il permet de faire le lien entre la connexion SSH entrante et le service munin-node-c.

Et voilà. Le processus munin-update sur mon serveur principal communique avec le processus de collecte munin-node-c sur mon serveur VPS grace à cette config:

[vps.example.com]
address = ssh://munin@vps.example.com/bin/netcat -q 3

On pourrait aussi bypasser completement inetd en executant directement le démon munin-node-c lors de la connexion SSH, mais il s'execute alors avec l'utilisateur courant et non plus l'utilisateur nobody:

[vps.example.com]
address = ssh://munin@vps.example.com/usr/sbin/munin-node-c -H vps.example.com

Voilà, cette configuration me permet de suivre l'évolution de mon VPS dès maintenant et sans attendre de mettre en place le tunnel VPN qui sera de toute façon requis pour le traffic SMTP qui nécessite une IP fixe que je n'aurais bientôt plus à la maison.

Welcome

2018-12-28T18:42:00+01:00

Bienvenu sur mon nouveau site dédié aux hacks, tutoriels et autres développements autour de Linux, Android et autres systèmes.

Ce site reprendra progressivement mes anciens articles issu de mon précédent site SPIP, non maintenu depuis trop longtemps maintenant.

Si vous souhaitez me joindre pour discuter d'un article du site, contactez-moi par email ou via Mastodon.

Bonne visite à vous.