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 !


Posté par Philippe Latu | permalien | dans : debian, système | Read it in english with Google
blog comments powered by Disqus