vendredi 26 août 2016, 11:51:56 (UTC+0200)

Les bases du stockage réseau sur IP

L'édition 2016 de la présentation sur les bases du stockage réseau sur IP est disponible !

Cette nouvelle édition introduit les distinctions entre les 3 modes d'accès aux données : bloc, fichier et objet.

Les grandes parties portent sur les définitions des types de réseaux de stockage, la caractérisation des natures d'accès aux données (dont le fameux I/O Blender effect), la présentation des protocoles de stockage sur IP et du scénario de la partie travaux pratiques sur le protocole iSCSI.

Les bases du stockage réseau sur IP

Comme d'habitude, les commentaires et critiques sont les bienvenus.

mardi 26 avril 2016, 11:00:05 (UTC+0200)

Évolution des fichiers image de machines virtuelles

Voici un nouveau billet sur le mode pense-bête consacré à la gestion des fichiers image de machines virtuelles au format qed.

J'ai l'habitude de fournir aux étudiants en début de projet des «images maître» ou masters de machines virtuelles pour que les manipulations démarrent plus vite et plus facilement. Lors de la dernière édition du projet sécurité de M2, j'ai remarqué que la gestion de ces images pose de grosses difficultés lors des échanges entre équipes et dans la mise au point des plans de reprise d'activité (PRA).

Le format de fichiers QED présente des caractéristiques très intéressantes pour l'échange de fichiers images de machines virtuelles. Ce type de fichier Qemu Enhanced Disk format fait partie de la famille Copy On Write qui permet d'effectuer des copies instantanées en cours de fonctionnement. De plus, ces fichiers n'occupent que l'espace effectivement alloué ce qui limite le volume de données à échanger lors d'une copie ou d'un transfert. Ce sont des Sparse files.

Voici une représentation qui illustre en 4 étapes comment préserver l'intégrité d'une image maître en lançant des instances de systèmes virtuels à partir d'images différentielles et comment créer une nouvelle image maître lorsque l'on souhaite conserver les modifications apportées à une image différentielle.

Évolution des fichiers images de machines virtuelles

Dans le schéma ci-dessus, les images différentielles 1 à 3 sont des fichiers d'instances «consommables» que l'on peut supprimer après usage tandis que l'image différentielle 'n' sert à produire une nouvelle image maître.

Voilà ! J'espère que ce pense-bête, disponible sous plusieurs formats (PDF, PNG et ODG), permettra de développer les scénarios d'utilisation des instances de machines virtuelles. Le guide Virtualisation système et enseignement fournit d'autres ressources sur les outils de virtualisation et leur utilisation avec le commutateur virtuel Open vSwitch.

lundi 8 février 2016, 19:07:11 (UTC+0100)

Réglage de l'heure avec NTP sur un système client Debian GNU/Linux

Aujourd'hui, le protocole NTP (Network Time Protocol) est devenu incontournable pour mettre à l'heure tous les systèmes d'exploitation. Sur les systèmes Debian GNU/Linux, le réglage de l'heure a évolué avec l'arrivée du système d'initialisation systemd. La «solution de facilité» a longtemps été d'installer le paquet ntp et donc de transformer son système en serveur NTP sans se préoccuper de sa configuration puisque ce paquet arrive avec une configuration par défaut qui pointe vers un cluster de serveurs NTP.

systemd-timesyncd status

Seulement voilà ! Le service NTP est devenu sensible. Il s'agit d'un service Internet «historique» qui s'appuie sur un simple jeu de questions/réponses au dessus du protocole de transport UDP ; tout comme le service de noms de domaines (DNS). Les instances de démons NTP «non configurées» sont susceptibles d'être utilisées pour des attaques en déni de service par amplification. Un paquet de requête est émis avec une adresse IP source falsifiée (celle de la victime) vers un serveur NTP et celui-ci émet sa réponse à destination de l'adresse falsifiée. Le phénomène d'amplification a lieu lorsqu'une même source provoque de multiples réponses.

Plus récemment, il est apparu que les démons de service NTP enregsitrés dans les clusters permettent d'optimiser les activités de reconnaissance dans l'espace d'adressage IPv6. À première vue, un espace d'adressage sur 128 bits dont 64 peuvent être choisis aléatoirement doit faire chuter l'efficacité des scanners et autres robots à la recherche de vulnérabilités. Avec un serveur NTP, il faut faire une croix sur cette forme d'anonymat puisque le démon désigne les adresses IPv6 et IPv4 d'un système actif. Les moteurs de recherche de vulnérabilités tels que Shodan utilisent ces informations de façon à se concentrer sur les systèmes actifs au lieu de parcourir un espace d'adresses gigantesque au hasard.

Bref ! Il faut apporter une attention toute particulière à la configuration du réglage de l'heure sur ses systèmes.

Au moment de la rédaction de ces lignes, les configurations des «clients» NTP fournis avec systemd diffèrent entre les versions stable/Jessie et testing/Stretch.

Debian GNU/Linux stable/Jessie

La partie cliente NTP de systemd est appelée timesyncd. Elle n'est pas activée par défaut lors de l'installation. On pourrait alors croire qu'il est nécessaire de faire appel à un logiciel tiers.

etu@vm0:~$ systemctl status systemd-timesyncd 
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled)
   Active: inactive (dead)
     Docs: man:systemd-timesyncd.service(8)

L'outil timedatectl affiche les informations sur le réglage l'heure du système.

etu@vm0:~$ timedatectl 
      Local time: mar. 2016-02-09 20:14:49 CET
  Universal time: mar. 2016-02-09 19:14:49 UTC
        RTC time: mar. 2016-02-09 19:14:56
       Time zone: Europe/Paris (CET, +0100)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  dim. 2015-10-25 02:59:59 CEST
                  dim. 2015-10-25 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  dim. 2016-03-27 01:59:59 CET
                  dim. 2016-03-27 03:00:00 CEST

La configuration de la liste des serveurs à interroger se fait via le fichier /etc/systemd/timesyncd.conf.

etu@vm0:~$ cat /etc/systemd/timesyncd.conf 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# See timesyncd.conf(5) for details

[Time]
#Servers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Il se trouve que sur le campus de mon université, le service NTP est filtré en sortie. Il a donc fallu mettre en œuvre un «service NTP spécifique» pour l'infrastructure de travaux pratiques de la formation STRI. La nouvelle version du fichier de configuration devient la suivante.

# egrep -v '(^#|^$)' /etc/systemd/timesyncd.conf
[Time]
Servers=0.ntp.infra.stri 1.ntp.infra.stri

Pour activer le client timesyncd, on utilise les deux commandes ci-dessous.

# systemctl enable systemd-timesyncd
Created symlink from /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service to /lib/systemd/system/systemd-timesyncd.service.
# systemctl start systemd-timesyncd

Pour connaître l'état du réglage de l'heure, on consulte le statut du logiciel client.

# systemctl status systemd-timesyncd
 systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled)
   Active: active (running) since mar. 2016-02-09 20:32:08 CET; 57min left
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 7014 (systemd-timesyn)
   Status: "Using Time Server 172.16.0.2:123 (0.ntp.infra.stri)."
   CGroup: /system.slice/systemd-timesyncd.service
           └─7014 /lib/systemd/systemd-timesyncd

févr. 09 20:32:08 vm0 systemd-timesyncd[7014]: Using NTP server 172.16.0.2:123 (0.ntp.infra.stri).
févr. 09 19:32:15 vm0 systemd-timesyncd[7014]: interval/delta/delay/jitter/drift 32s/-3593.138s/0.000s/0.000s/+0ppm
févr. 09 19:32:47 vm0 systemd-timesyncd[7014]: interval/delta/delay/jitter/drift 64s/+0.001s/0.001s/0.000s/+0ppm
févr. 09 19:33:51 vm0 systemd-timesyncd[7014]: interval/delta/delay/jitter/drift 128s/+0.002s/0.001s/0.001s/+7ppm

Pour terminer, la commande timedatectl renvoie aussi les informations sur la synchronisation horaire.

etu@vm0:~$ timedatectl 
      Local time: mar. 2016-02-09 21:08:55 CET
  Universal time: mar. 2016-02-09 20:08:55 UTC
        RTC time: mar. 2016-02-09 21:08:55
       Time zone: Europe/Paris (CET, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  dim. 2015-10-25 02:59:59 CEST
                  dim. 2015-10-25 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  dim. 2016-03-27 01:59:59 CET
                  dim. 2016-03-27 03:00:00 CEST

Debian GNU/Linux testing/Stretch

À la différence de la version stable/Jessie, la version testing/Stretch de la distribution fournit une version de systemd dans laquelle le service client NTP timesyncd est activé par défaut. Le jeu de commandes reste identique mais la syntaxe du fichier de configuration change et devient la suivante.

# egrep -v '(^#|^$)' /etc/systemd/timesyncd.conf
[Time]
NTP=0.ntp.infra.stri 1.ntp.infra.stri

Les informations sur le statut du service NTP client sont correctes.

$ systemctl status systemd-timesyncd
 systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since mer. 2016-02-10 10:18:32 CET; 58min left
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 402 (systemd-timesyn)
   Status: "Synchronized to time server [2001:db8:feb2:1::4]:123 (1.ntp.infra.stri)."
   CGroup: /system.slice/systemd-timesyncd.service
           └─402 /lib/systemd/systemd-timesyncd

Pour conclure ...

Avec les outils et la configuration présentés ci-dessus, il n'est plus nécessaire de lancer des instances de serveurs NTP sur les systèmes clients. On réduit ainsi le nombre de systèmes «exposés» aux robots de recherche de vulnérabilités.

Ce billet ne serait pas complet si il ne rappelait pas qu'il est nécessaire d'appliquer une règle minimale de protection contre les dénis de services via le fichier de configuration /etc/sysctl.conf. La fonction Reverse Path Filtering ou unicast Reverse Path Forwarding offre deux possibilités intéressantes dans le noyau Linux.

$ sudo sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 1
  • Avec la valeur 1, le système qui reçoit un paquet commence par vérifier que l'adresse IP source de ce paquet est joignable par l'interface sur laquelle il a été reçu.
  • Avec la valeur 2, le système qui reçoit un paquet vérifie que l'adresse IP source de ce paquet est joignable par n'importe laquelle des entrées de sa table de routage.

Avec l'une ou l'autre des deux valeurs ci-dessus, si la vérification échoue, le paquet est rejeté et toute tentative de déni de service par falsification de l'adresse IP source échoue aussi !