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 OK interface 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: . 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/ par Alain Thivillon (05/03/2005)