HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Brèves > NTP Multicast authentifié
Accéder au : Site HSC des formations
Télécharger le catalogue des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Bulletin juridique HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|NTP Multicast authentifié  

par Alain Thivillon (05/03/2005)






Cet article traite de la mise en place d'échanges NTP sécurisés en
utilisant en particulier le mode multicast.

1. Rappels sur NTP

NTP (Network Time Protocol) est un protocole normalisé à l'IETF (RFC
1305 et 2030) permettant de synchroniser l'horloge d'équipements de
manière très précise, en tenant compte du temps de transit sur le réseau
et de la dérive de l'horloge matérielle des systèmes.

De très nombreuses informations sur NTP v3 et son successeur en cours de
normalisation sont disponibles sur http://www.ntp.org/.

L'infrastructure NTP est organisée en "strates" : un serveur de strate 1
est connecté directement à une horloge très précise : horloge atomique,
récepteur GPS (le plus courant de nos jours), ou DCF (récepteur radio).
Les serveurs se synchronisant sur une strate 1 sont dit de strate 2, etc.

Afin de synchroniser un système en utilisant NTP, deux méthodes sont
utilisables:
- utiliser SNTP (RFC 2030), version réduite du protocole et permettant
  d'interroger l'horloge du serveur de manière périodique (par exemple
  sous Unix dans une crontab avec l'utilitaire ntpdate).
- installer un vrai serveur (l'implémentation de référence sous Unix est
  ntpd) qui tournera en permanence sous forme de démon et gérera de 
  manière continue l'horloge du système. C'est cette méthode qui est
  privilégiée dans le modèle et étudiée dans la suite.

En effet, pourquoi préférer utiliser un démon NTP plutôt qu'une
synchronisation régulière effectuée toutes les heures ? La raison est
simple bien que souvent ignorée : le démon NTP assure que l'heure du
système ne reviendra jamais en arrière : si le système est en avance, le
démon va ralentir l'horloge système (par exemple en utilisant l'appel
système adjtimex sous Linux ou adjtime sous SVR4 et BSD) en augmentant
le nombre de tics d'horloges nécessaires à l'écoulement d'une seconde.
Ainsi nous avons l'assurance que le temps est toujours croissant, ce qui
est d'une importance vitale pour certains programmes qui effectuent des
calculs d'intervalles.  L'utilisation d'un démon NTP permet également de
prendre en compte sur le long terme la dérive de l'horloge matérielle,
et d'agir à priori sur cette dérive, ce qui permet de maintenir une
synchronisation en général à la milliseconde sur de très longues périodes
même sur des architectures matérielles médiocres comme les PCs.

A noter que l'utilisation de ntpd transforme de manière automatique la
machine en serveur de strate n+1 : il faudra donc prendre les
précautions pour que ce serveur soit protégé (acls NTP, firewall, ...).

Dans la suite, on appellera toutefois "serveur" le système qui se
synchronise sur une horloge externe, et "client" les systèmes qui vont
utiliser le serveur précédemment configuré. Dans les deux cas, le même
logiciel est lancé, néanmoins configuré différemment. Dans le cas d'une
recherche de temps sur Internet, le "serveur" sera le seul système en
contact avec l'extérieur.

2. Authentification dans NTP

NTP utilise bien entendu UDP (communications du port 123 vers le port
123 pour les serveurs entre deux, depuis un port non privilégié > 1023
vers le port 123 pour les clients SNTP), afin de garder une
"spontanéité" nécessaire à la synchronisation, et pouvoir être utilisé
en multicast ou en broadcast.

Cette facilité est bien évidemment une faiblesse en terme de sécurité,
puisqu'il est dès lors très facile d'injecter des paquets usurpés
(spoofing, au moins sur le réseau local) et de changer potentiellement
l'horloge des machines.

NTP a quelques mécanismes pour se défendre, en particulier les serveurs
refusent de changer d'heure brutalement, et vont éliminer les bases de
temps qui sont trop éloignées de leur référentiel ou dont l'horloge
n'est pas stable. Il n'empêche que la question de l'authentification est
primordiale.

Plusieurs mécanismes sont utilisables:
- une signature des paquets par secret partagé et un algorithme connu. 
  L'algorithme le plus utilisé actuellement est MD5 : même si des
  faiblesses y ont été trouvées récemment, l'usage demandé (une
  signature d'une information très volatile) est encore largement 
  couvert.
- une cryptographie à clé publique, implémentée dans le draft NTPv4,
  qui permet de ne pas devoir installer de secret dans les clients: 
  le serveur signe la réponse et le client connaissant la clé publique
  du serveur peut la vérifier. Ce mode est appelé "autokey".

Ce mode n'étant pas encore implémenté dans un nombre suffisant de
clients (équipements réseau notamment), le reste de cet article traite
de la signature MD5 des paquets NTP.

Chaque clients et serveurs vont partager un certain nombre de secrets
partagés (au moins un) : le numéro du secret utilisé pour signer le
paquet est annoncé dans le paquet qui se termine par une signature MD5.

Le format du paquet tel qu'il est décodé par Ethereal par exemple est 
le suivant:

No.     Time            Source                Destination           Protocol Info
     22 14:40:23.859083 192.168.230.1         224.0.1.1             NTP      NTP

Internet Protocol, Src Addr: 192.168.230.1 (192.168.230.1), Dst Addr: 224.0.1.1 (224.0.1.1)
User Datagram Protocol, Src Port: ntp (123), Dst Port: ntp (123)
    Source port: ntp (123)
    Destination port: ntp (123)
    Length: 76
    Checksum: 0x0982 (correct)
Network Time Protocol
    Flags: 0x25
        00.. .... = Leap Indicator: no warning (0)
        ..10 0... = Version number: NTP Version 4 (4)
        .... .101 = Mode: broadcast (5)
    Peer Clock Stratum: secondary reference (2)
    Peer Polling Interval: 6 (64 sec)
    Peer Clock Precision: 0.000000 sec
    Root Delay:    0.0469 sec
    Clock Dispersion:    0.0472 sec
    Reference Clock ID: 212.242.86.172
    Reference Clock Update Time: 2005-03-15 13:29:47.9111 UTC
    Originate Time Stamp: NULL
    Receive Time Stamp: NULL
    Transmit Time Stamp: 2005-03-15 13:40:23.8607 UTC
    Key ID: 00000007
    Message Authentication Code: 0D0AD03090FE720B1DC81809A3732334

3. Multicast

La mise en oeuvre du protocole multicast permet d'optimiser l'utilisaton
de NTP. En effet, il peut être difficile de maintenir un réseau ntp :
si des serveurs doivent être déplacés ou en maintenance, il faut
repasser sur tous les clients afin de les reconfigurer ou les relancer
pour que la nouvelle entrée DNS soit prise en compte. Certes l'adresse
du serveur NTP peut être donnée par DHCP mais cette méthode n'est pas
adaptée aux serveurs d'adresse IP fixe.

En mode multicast, les serveurs s'annoncent sur l'adresse 224.0.1.1
(NTP.MCAST.NET), sur laquelle les clients sont en écoute. On évite ainsi
l'utilisation d'un broadcast qui va perturber l'ensemble du réseau :
seules les machines ayant besoin des paquets vont les traiter. D'autre
part, le multicast est routable : un serveur NTP peut ainsi diffuser
l'heure sur un réseau étendu sans avoir besoin de configuration
particulière. Si plusieurs serveurs envoient l'heure, les clients
peuvent choisir de manière dynamique vers lequel ils vont se tourner, et
estimer quel est le plus fiable et le plus proche d'eux.

Évidemment, cette mise en oeuvre ne peut s'imaginer que dans le mode
authentifié, puisque il serait alors très facile d'injecter des faux
serveurs dans le réseau (de même qu'OSPF non authentifié, utilisant
aussi le multicast est un piège de sécurité).

Les machines désirant émettre et recevoir des paquets Multicast doivent
être configurées spécialement, en particulier si le serveur n'est pas
sur le même LAN et que le routage multicast va être nécessaire. Sous
Linux notamment, l'abonnement au groupe multicast par IGMP demande que
le noyau soit configuré avec l'option CONFIG_IP_MULTICAST=y (de fait il
suffit qu'un seul client sur chaque LAN connaisse IGMP pour que le
routage multicast soit mis en place, il n'est donc pas forcément
nécessaire de refaire le noyau de chaque machine).

Après réception des paquets multicast indiquant l'heure, le
fonctionnement dépend légèrement de la version de ntpd:

- en V3, le "client" attend les paquets multicast sans interroger
  le serveur à chaque paquet. C'est donc un mode purement passif mais
  moins précis, puisque le client n'a pas moyen de connaître le temps
  de transport par le réseau.

- en V4, le "client" choisit le meilleur serveur écouté et commence un
  dialogue en unicast avec lui, tout en continuant à suivre l'heure 
  envoyée par les autres serveurs.

4. Mise en oeuvre

4.1 Génération des clés

Il faut commencer par générer des clés MD5 permettant la signature des
paquets.

Cela peut être effectué en lançant l'utilitaire ntp-genkeys qui va créer
(avec l'option -h) un fichier de clés dans le répertoire courant. Ce
fichier va être relié par un lien symbolique sur /etc/ntp.keys .

root # cd /etc
root # ntp-genkeys -h        
root # ls -l ntp.key*
-rw-------  1 root root 574 Mar  6 16:36 ntp.keys.3319112185
# ln -s ntp.keys.3319112185 ntp.keys

Le fichier généré contient 16 clés MD5:

root # cat ntp.keys
# MD5 key file ntp.keys.3319112185
# Sun Mar  6 16:36:25 2005
 1 M ?++6%-Z}@zI\1Kms   # MD5 key
 2 M 7e_q>D}z}+}l;``K   # MD5 key
 3 M vL60(;X+37\h2f>\   # MD5 key
 4 M p;\NEQu1R`9if>e\   # MD5 key
 5 M rG{W,~|\sM`5c$]\   # MD5 key
 6 M Seg1=$hF/E_(eOAt   # MD5 key
 7 M b\XE3@,X^>I'$lQr   # MD5 key
 8 M ?i1tW=j6Vv8_$E!B   # MD5 key
 9 M 7EmH7.7jUe^]eb%3   # MD5 key
10 M ;*lpmKclo`/i6j}[   # MD5 key
11 M jup)hZ-A<(jzkVL5   # MD5 key
12 M BrtPTN-=owJGKaM3   # MD5 key
13 M Xe;IpdLzNan6%y+0   # MD5 key
14 M L6gq0kgYhSxtylI?   # MD5 key
15 M gS0?([y^[04|36g6   # MD5 key
16 M 6"|f7p-n`U\rI:3&   # MD5 key

Il est bien évidemment possible d'utiliser des clés générées à la main
plus facilement distribuables telles que:

root # cat ntp.keys
12 M CLE-DE-DOUZE
42 M LA-REPONSE-EST-42
1966 M BONNE-ANNEE

Le numéro de la clé est un entier sur 32 bits.

4.2 Configuration du serveur

Il faut ensuite configurer le fichier /etc/ntp.conf afin de spécifier 
les serveurs à utiliser, les restrictions d'accès, et les clés à charger.

Les serveurs à utiliser sont pris dans le pool de NTP.ORG (qui sont en
général des serveurs de strate 2 ou 3). Si votre opérateur internet met
ce service à votre disposition, vous avez plutôt intérêt à l'utiliser.

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org

Quelques serveurs sont également en accès semi-public, en France il faut
citer ntp.cru.fr qui est ouvert à la communauté enseignement-recherche
et qui est une strate 1.

Le fichier driftfile permet de sauvegarder la dérive de l'horloge du
système afin de pouvoir converger plus rapidement lors des démarrages,
il est ici placé sur /var/log/ntp.drift.

driftfile /var/log/ntp.drift

Les restrictions d'accès sont mise en places par le mot clé "restrict".
Ici en utilisant pool.ntp.org, qui peut renvoyer des adresses IP
tournantes, il est difficile de configurer le serveur de manière forte,
on va simplement interdire la modification et les interrogations par
défaut, et autoriser les interrogations uniquement depuis le réseau
192.168.230.0/24. L'adresse IP de loopback a tous les droits.

restrict default nomodify noqyery
restrict 192.168.230.0 mask 255.255.255.0 nomodify
restrict 127.0.0.1

Avec une configuration plus fermée utilisant un seul serveur, d'adresse
IP fixe 192.168.10.1, on pourrait ignorer tous les paquets:

restrict default nomodify noquery ignore
restrict 192.168.10.1 nomodify noquery
restrict 192.168.230.0 mask 255.255.255.0 nomodify notrust
restrict 127.0.0.1

Les clés sont ensuite chargées depuis le fichier /etc/ntp.keys, et on
spécifie quelles sont celles à utiliser (celles qui sont de confiance),
ici les clés 1,2 et 7.

keys /etc/ntp.keys
trustedkey 1
trustedkey 2
trustedkey 7

On spécifie enfin que le serveur doit envoyer les paquets sur l'adresse
multicast prévue pour cela (224.0.1.1 == ntp.mcast.net), en signant les
paquets avec une des clés (ici la numéro 2) et en utilisant un ttl de 2
(ce qui signifie que le paquet peut traverser un seul routeur
multicast): 

broadcast 224.0.1.1 key 2 ttl 2

Le mot clé à utiliser est bien "broadcast", et non pas "manycast" qui
est un mode utilisant aussi multicast mais implémenté seulement par les
serveurs et clients NTP récents (V4).

Si vous avez un réseau ne comprenant pas de routeur multicast et que
vous désirez seulement envoyer les paquets sur le réseau local, vous
pouvez supprimer le mot clé ttl (ce qui revient à le placer sur 1).

broadcast 224.0.1.1 key 2

Le numéro de clé utilisé est important: ce numéro sera échangé par les
clients et serveurs, il faut donc impérativement que la clé choisie *et*
son numéro soient communs aux serveurs et aux clients.

Enfin les mots clés "enable auth" et les deux suivants permettent de
spécifier que le serveur est modifiable dynamiquement en utilisant une
des clés (ici la 1) avec les utilitaires ntpdc et ntpq. Attention: cette
clé doit être réservée aux administrateurs, il ne faut donc pas utiliser
la même que celle qui sera placée sur les clients.

enable auth
controlkey 1 
requestkey 1

La clé 1 peut ensuite être utilisée par exemple pour ajouter un serveur avec 
ntpq, ou ajouter un réseau autorisé sans avoir à redémarrer le serveur.

Le fichier /etc/ntp.conf complet est donc :

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
driftfile /var/log/ntp.drift

keys /etc/ntp.keys
trustedkey 1
trustedkey 2
trustedkey 7

restrict default nomodify noquery
restrict 192.168.230.0 mask 255.255.255.0 nomodify notrust
restrict 127.0.0.1

broadcast 224.0.1.1 key 2 ttl 2
enable auth
controlkey 1
requestkey 1

4.3 Lancement et vérification de l'état du serveur.

Avant de lancer le serveur ntp, il faut s'assurer qu'il est globalement
à l'heure, et que son décalage n'excède pas quelques secondes avec
l'heure vraie, sinon ntpd peut refuser de rattraper le décalage, ou être
très lent à converger. Le plus simple est donc de synchroniser le
serveur en une fois avec l'utilitaire ntpdate :

# ntpdate 1.pool.ntp.org 
6 Mar 17:48:16 ntpdate[4458]: adjust time server 131.111.226.25 offset 0.004687 sec

On peut ensuite démarrer le serveur (en général le systeme fournit un
script de démarrage tel que /etc/init.d/ntpd). Les bonnes distributions
utiliseront l'option -U permettant de baisser les privilèges après que
les sockets UDP aient été créés.

Un des problèmes de ntp est que la convergence peut être longue, c'est à
dire que le serveur attend très longtemps avant qu'il ne soit déclaré
synchronisé et qu'il commence à répondre aux demandes des clients (et
ici à envoyer les paquets multicast). Il n'est donc pas facile de
débugger, et il faut s'armer de patience (et n'être pas pressé, et
éventuellement avoir d'autres tâches urgentes entre plusieurs lancements...).

La convergence peut être accélérée en ajoutant le mot clé "iburst" sur la
ligne server, au risque toutefois de faire confiance à un serveur
déréglé :

server 0.pool.ntp.org iburst

L'état du serveur s'interroge en utilisant l'utilitaire ntpq, ici
avec l'option -n permettant de ne pas effectuer la résolution inverse
des noms. La commande "pe" permet de visualiser l'état des peers:

% ntpq -n
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 224.0.1.1       0.0.0.0         16 u    -   64    0    0.000    0.000 4000.00
-206.168.186.2   128.105.39.11    3 u   33   64  377  191.340   -1.220   4.363
+67.159.5.117    67.159.5.116     3 u   32   64  357  152.354    0.598   0.835
+62.152.126.5    146.48.83.182    3 u   34   64  377   84.847    4.645   2.629
*195.220.94.163  .GPS.            1 u   37   64  377   62.652    6.696   6.049

Si vous ne récupérez que des "16" dans la colonne "st", cela signifie en
général qu'aucune réponse n'a été reçue des serveurs, ce qui est mauvais
signe (réseau coupé, problème de firewall, ou restrictions trop fortes). 

Après plusieurs minutes (en général il faut au moins 3 ou 4
interrogations soit 4*64 secondes), quand le serveur est synchronisé,
une "*" apparaît dans la première colonne (ici sur la ligne
correspondant au serveur strate 1 utilisé, qui a été élu meilleur
serveur). A partir de ce moment, les paquets multicast vont être envoyés
sur le réseau (ici toutes les 64 secondes).

Il est possible de modifier dynamiquement la configuration du serveur,
en utilisant la clé placée dans "controlkey".  On peut ainsi ajouter un
serveur ou un réseau de confiance, avec l'utilitaire ntpdc , en
précisant la clé utilisée (ici la 1) et en la tapant en réponse de
l'invite de la commande passwd (ici "?++6%-Z}@zI\1Kms" a été entré).

% ntpdc
ntpdc> keyid 1
ntpdc> passwd
MD5 Password: 
ntpdc> addserver 195.220.94.163
done!
ntpdc> restrict 192.168.231.0 255.255.255.0 nomodify notrust
done!

Attention les modifications effectuées ne sont pas sauvegardées dans
ntp.conf, il faut les y ajouter statiquement pour qu'elles soient prises
en compte lors du prochain démarrage.

4.2 Client

La configuration du client est similaire à celle du serveur, elle
s'effectue également dans le fichier ntp.conf et ntp.keys.

Dans /etc/ntp.keys se place (par copier/coller par exemple) la clé
numéro 2 dans notre exemple. Il est évident que la clé ne doit pas être
lisible des utilisateurs non sûrs (le fichier doit appartenir à root et
être en mode 600), et qu'elle doit être placé via un canal sécurisé (par
ssh par exemple, et non telnet).

# cat /etc/ntp.keys 
 2 M 7e_q>D}z}+}l;``K   # MD5 key

Le fichier ntp.conf contient:

# cat /etc/ntp.conf
restrict default noquery notrust nomodify
restrict 127.0.0.1
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log
keys /etc/ntp.keys
trustedkey 2
multicastclient 224.0.1.1

La clé 2 est considérée comme sûre, rien n'interdit si la machine voyage
entre deux réseaux (un portable par exemple) d'en charger plusieurs (de
n° différents toutefois).

La dernière ligne permet de spécifier que le client utilise le mode
multicast, et qu'il est donc en écoute sur l'adresse 224.0.1.1 afin
de détecter les serveurs.

Le lancement du démon s'effectue comme sur le serveur, en vérifiant là
également que l'heure est "a peu près" juste avant le démarrage (ou en
effectuant une synchronisation initiale avec ntpdate).

La sortie de la commande ntpq doit montrer successivement qu'aucun
serveur n'a encore été entendu, puis qu'un ou plusieurs serveurs ont été
entendus sur l'adresse multicast, puis après convergence que la
synchronisation a été effectuée:

# /etc/init.d/ntpd start
 * Starting ntpd...
[ ok ]

# ntpq -n
ntpq> pe
No association ID's returned
ntpq> q

# ntpq -n
ntpq> pe
     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
 82.123.191.181  195.220.94.163   2 -    8   64    1    0.000    0.000 4000.00

# ntpq -n          
ntpq> pe
     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
*82.123.191.181  195.220.94.163   2 -   25   64   37    0.637    6.157 0.117

4.3 Routage multicast

Le routage des paquets multicast entre deux réseaux nécessite une
infrastructure spéciale, puisque l'adresse destination ne suffit
évidemment pas à savoir sur quels réseaux envoyer les paquets. Une
solution stupide consisterait à envoyer les paquets sur chaque interface
du routeur, sans discernement, en décrémentant le TTL. Ce mode appelé
"flooding" s'il n'est pas très gênant dans le cas de NTP (a condition
bien sûr de gérer les boucles et les routeurs multiples) puisque le
trafic est faible, est bien évidemment inutilisable dans le cas de flux
video.

Les routeurs multicast ont donc la responsabilité de gérer les
abonnements à chaque adresse multicast : dans le cas de NTP, chaque
client va signaler en démarrant sa présence en envoyant sur l'adresse
224.0.1.1 un paquet IGMP de "Host Membership", puis le routeur
interrogera à intervalles régulier chacun de ses réseaux afin de savoir
si des machines sont encore présentes (IGMP Query sur 224.0.0.1).

Les routeurs sont ainsi censés connaître sur chacune de leur interfaces:
- les groupes multicast qui sont présents, éventuellement envoyés par
  d'autres routeurs.
- les systèmes abonnés à chaque groupe.
 
Quand sur une des interfaces, plus aucun système n'est abonné (plus
d'envoi de paquet IGMP Host Memebership), le routeur peut cesser de
diffuser les paquets multicast du groupe. 

Par rapport à un routeur IP classique, un routeur multicast doit donc
faire preuve de plus d'intelligence et faire évoluer ces tables d'états
de manière très dynamique.  Les internals du routage multicast sont de
plus très complexes (le protocole IGMP en est à sa 3e version), en
particulier quand des routeurs multicast doivent échanger des tables de
routages ou quand plusieurs routeurs peuvent annoncer le même groupe.

Sous Unix, le logiciel mrouted permet de transformer un système comme
Linux ou FreeBSD en routeur multicast (IGMP v2).

La configuration est simple quand on ne cherche pas à s'écarter du
défaut et qu'aucun tunnel multicast n'est configuré, le fichier
/etc/mrouted.conf contient par exemple:

phyint em1
     disable
phyint vlan2
     disable

pour signifier que le traitement du multicast doit être désactivé sur
ces deux interfaces (ici sous Freebsd).

Le problème le plus complexe est probablement de faire cohabiter le
multicast avec le filtrage IP.

Dans le cas de NTP, il faut surtout comprendre que le routage multicast
n'est nécessaire que si le "serveur" n'est pas situé sur le même réseau
que le "client", ou bien qu'il est multi-homé et qu'il doit diffuser NTP
sur chacune de ces interfaces (ce qui n'est pas possible sous les Unix
standard sans démon de routage).

4.4 Traces réseau et debug

La trace réseau ci-dessous a été effectuée avec le logiciel Ethereal
qui décode parfaitement NTP et IGMP.

Le "client" Linux est à l'adresse 192.168.230.6, le serveur NTP en
82.123.45.116 et le routeur Multicast en 192.168.230.1 (c'est la même
machine mais qui exprime NTP sur son interface externe).

Les premiers paquets son émis par le client qui signale son abonnement
au groupe multicast 224.0.1.1:

  6  10.640218 192.168.230.6 -> 224.0.1.1    IGMP V2 Membership Report
  8  17.279600 192.168.230.6 -> 224.0.1.1    IGMP V2 Membership Report

Le serveur NTP diffuse l'heure de manière régulière sur le réseau, et le
paquet est transmis par le routeur multicast sur le réseau
192.168.230.0):

 10  29.701309 82.123.45.116 -> 224.0.1.1    NTP NTP
 17  93.702984 82.123.45.116 -> 224.0.1.1    NTP NTP

Après réception du 2e paquet, le client se synchronise sur le serveur en
unicast:

 18  94.132625 192.168.230.6 -> 82.123.45.116 NTP NTP
 19  94.133218 82.123.45.116 -> 192.168.230.6 NTP NTP

Le routeur multicast envoie régulièrement des paquets IGMP pour vérifier
que des machines sont encore présentes dans le groupe NTP, la couche IP
du client répond (avec un délai aléatoire afin de ne pas collisionner):

 23 125.485843 192.168.230.1 -> 224.0.0.1    IGMP V2 Membership Query
 25 129.507140 192.168.230.6 -> 224.0.1.1    IGMP V2 Membership Report

Nouvelle synchronisation:

 31 158.190600 192.168.230.6 -> 82.123.45.116 NTP NTP
 32 158.191202 82.123.45.116 -> 192.168.230.6 NTP NTP

Nouveaux paquets multicast du serveur:

 33 158.702552 82.123.45.116 -> 224.0.1.1    NTP NTP
 40 221.702518 82.123.45.116 -> 224.0.1.1    NTP NTP

La suite est une répétition de ces échanges. 

Lors de l'arret du "client" ntpd, un message multicast "LEAVE GROUP" est
envoyé par le système sur l'adresse correspondant aux routeurs multicast
(224.0.0.2), puis le routeur vérifie que plus aucun client n'est abonné
à NTP:

  1   0.000000 192.168.230.6 -> 224.0.0.2    IGMP V2 Leave Group
  2   0.000619 192.168.230.1 -> 224.0.1.1    IGMP V2 Membership Query
  3   1.001095 192.168.230.1 -> 224.0.1.1    IGMP V2 Membership Query

Attention néanmoins aux effets de bord de tcpdump ou autre sniffers: en
mettant l'interface réseau en mode promiscuous, ils forcent les paquets
multicast a entrer dans la machine: si le fonctionnement multicast du
noyau est incorrect, cela ne sera pas forcément détecté. Il est donc
important quand la configuration est validée d'arrêter tout sniffer
réseau sur la machine, de relancer ntpd et de vérifier que la
convergence est à nouveau obtenue.

Il est possible de débugger le démon ntpd en utilisant l'option -D, par
exemple avec le niveau 10:

# ntpd -D 10 -U ntp
Debug1: 10 -> a = 10
ntpd 4.1.2@1.892 Sun Feb  8 10:08:52 CET 2004 (1)
Debug1: 10 -> a = 10
adding new filegen
adding new filegen
adding new filegen
adding new filegen
create_sockets(123)
interface <lo> OK
interface <eth0> OK
bind() fd 4, family 2, port 123, addr 0.0.0.0, flags=1
flags for fd 4: 04002
bind() fd 5, family 2, port 123, addr 127.0.0.1, flags=0
flags for fd 5: 04002
bind() fd 6, family 2, port 123, addr 192.168.230.6, flags=1
flags for fd 6: 04002
create_sockets: ninterfaces=3
interface 0:  fd=4,  bfd=0,  name=wildcard,  flags=0x1
              sin=0.0.0.0  bcast=0.0.0.0,  mask=255.255.255.255
interface 1:  fd=5,  bfd=0,  name=lo,  flags=0x4
              sin=127.0.0.1  mask=255.0.0.0
interface 2:  fd=6,  bfd=0,  name=eth0,  flags=0x1
              sin=192.168.230.6  bcast=192.168.230.255, mask=255.255.255.0
...
getnetnum 224.0.1.1 step 3 buf 1 temp 1 netnum 3758096641
getnetnum given 224.0.1.1, got 224.0.1.1 (e0000101)
bind() fd 10, family 2, port 123, addr 224.0.1.1, flags=0

Les paquets multicast arrivent ensuite:

input_handler: if=4 fd=10 length 68 from 527b2d74 82.123.45.116
input_handler: if=0 fd=4 length 68 from 527b2d74 82.123.45.116
getrecvbufs returning 2 buffers
receive: at 98 224.0.1.1<-82.123.45.116 restrict 1c
receive: at 98 224.0.1.1<-82.123.45.116 mode 5 code 6 keyid 00000002 len 48 mac 20 auth 1
poll_updateear: at 14 assoc ID 0

Si par exemple une erreur d'authentification intervient, il sera
possible de le voir dans cette sortie:

receive: at 26 224.0.1.1<-82.123.45.116 restrict 1c
receive: at 26 224.0.1.1<-82.123.45.116 mode 5 code 5 keyid 00000002 len 48 mac 20 auth 0

La clé est correcte ( keyid 00000002) mais l'authentification a
échouée (auth 0)

4.5 Mise en place sur IOS

IOS sur Cisco supporte le broadcast NTP mais ne supporte le NTP
multicast (en tant que client) que depuis la version 12.1.  Dans notre
configuration, nous allons donc utiliser une configuration statique
incluant l'adresse réelle des serveurs, tout en gardant une
authentification par clé MD5.

Il faut commencer à indiquer que le mode NTP sera authentifié, puis
entrer les clés:

ntp authenticate
ntp authentication-key 42 md5 LA-REPONSE-EST-42

Attention, il semble que l'algorithme d'obfuscation IOS aie du mal avec
certains caractères tels que "' , il faut donc de préférence utiliser
une clé textuelle comme celle proposée ici.

On exprime ensuite que la clé 42 est de confiance:

ntp trusted-key 42

puis on indique quels sont les serveurs à utiliser avec quelle clé:

ntp server 192.168.230.1 key 42
ntp server 192.168.231.7 key 42

Après convergence, on doit voir apparaitre les serveurs dans la sortie
de la commande "show ntp associations" et dnas "show ntp status":

catalyst#sh ntp associations 

      address         ref clock     st  when  poll reach  delay  offset disp
*~192.168.230.1    212.242.86.172    2    18    64  377     3.3    0.90 0.5
+~192.168.231.7    192.168.230.1     3     6    64  377     3.7    0.83 0.7
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

Ici le commutateur est synchronisé sur 192.168.230.1:

catalyst#sh ntp status       
Clock is synchronized, stratum 3, reference is 192.168.230.1
nominal freq is 381.4697 Hz, actual freq is 381.4679 Hz, precision is 2**17
reference time is C5E17834.86BFF4A0 (15:05:24.526 UTC Tue Mar 15 2005)
clock offset is 0.8970 msec, root delay is 50.20 msec
root dispersion is 71.61 msec, peer dispersion is 1.72 msec

Petite coquetterie de Cisco, la sortie de la commande "show clock"
inclue un . initial quand IOS n'est pas synchronisé par NTP:

catalyst#sh clock
.12:43:21.765 UTC Tue Mar 15 2005

catalyst#sh clock
15:06:50.189 UTC Tue Mar 15 2005

IOS est évidemment également serveur NTP, il répond même à la commande
ntpq effectuée depuis une machine unix:

% ntpq -n -c pe catalyst
     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
*192.168.230.1   212.242.86.172   2 u   13   64  377    3.330    1.038 0.520
+192.168.231.7   192.168.230.1    3 u    1   64  377    1.420    2.198 0.400

Il est donc nécessaire de spécifier quelles sont les machines autorisées
à l'interroger:

!
access-list 88 permit 192.168.230.1
access-list 88 permit 192.168.231.7
access-list 89 permit 192.168.230.0 0.0.0.255
!
! Clients
ntp access-group peer 89
! Serveurs
ntp access-group serve 88

Sur les IOS récents, on peut utiliser NTP Multicast en spécifiant sur
l'interface sur laquelle seront reçus les paquets:

int FastEthernet 0/1
 ntp multicast client

en ayant auparavant intégré les clés comme vu précédemment.

4.6 Windows

Windows 2000 et supérieurs contiennent un composant SNTP (client et
serveur), qui ne supporte malheureusement pas le mode multicast ni
l'authentification MD5. Son intégration sécurisée utilise des tickets
Kerberos et l'infrastructure Active Directory.

Il est possible de configurer le service de temps afin de se connecter à
un service de temps "étranger" sans authentification, via la commande
NET TIME /SETSNTP:<ipserver> .

Il est également possible d'installer une distribution Windows de NTPD
et d'utiliser les mêmes configurations que décrit pour Unix (en perdant
évidemment les mécanismes de sécurité purement Windows). Les liens
nécessaires à cette installation sont donnés ci-dessous.

5. Liens et références

Home of the Network Time Protocol: http://www.ntp.org/
Network Time Synchronization Project: http://www.eecis.udel.edu/~mills/ntp.html
Linux Multicast HOWTO: http://www.tldp.org/HOWTO/Multicast-HOWTO.htm
Mrouted: ftp://ftp.research.att.com/pub/fenner/mrouted/
Cisco Network Time Protocol Best Practices White Paper: http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a0080117070.shtml
Configuring NTP (IOS 12.2 et 12.3): http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/fcfprt3/fcf012.htm#wp1001170
Windows Time Service: http://www.microsoft.com/windows2000/techinfo/howitworks/security/wintimeserv.asp
NTP 4.x for Windows: http://www.eecis.udel.edu/~mills/ntp/html/hints/winnt.html
Binary packages for Windows: http://norloff.org/ntp/





Dernière modification le 16 mars 2005 à 11:57:19 CET - webmaster@hsc.fr
Mentions légales - Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants