La synchronisation temporelle précise est critique pour la sécurité et l'exploitation. L'ISO 27002 mesure 8.17 recommande cinq principes :

• Corrélation événements multi-sources : reconstituer timeline attaque en corrélant logs firewall, serveurs, IDS, Active Directory, endpoints nécessite timestamps cohérents entre toutes sources sinon séquence impossible à établir
• Validité juridique logs : preuves numériques doivent avoir horodatage fiable et vérifiable pour être recevables en justice, désynchronisation invalide preuves lors contentieux ou procédures légales
• Conformité réglementaire : nombreux standards exigent synchronisation précise (PCI DSS, ISO 27001, HDS santé, eIDAS signatures), audits vérifient systématiquement configuration NTP
• Fonctionnement protocoles : Kerberos tolère maximum 5 minutes décalage (sinon authentification échoue), certificats SSL/TLS validité temporelle stricte, transactions horodatées (bases données, blockchain)
• Forensic et investigation : reconstitution précise attaque nécessite timeline fiable au milliseconde près, identifier patient zero, séquence propagation malware, actions attaquant

Ces principes démontrent que NTP n'est pas option mais fondation sécurité et conformité.

Fonctionnement NTP

Synchronisation hiérarchique : architecture stratum : niveau 0 = sources temps autoritaires (horloges atomiques, GPS), niveau 1 = serveurs NTP directement connectés stratum 0, niveau 2 = serveurs synchronisés sur stratum 1, niveau 3 = clients synchronisés sur stratum 2, client interroge : serveur NTP toutes les 64-1024 secondes (poll interval adaptatif), ajuste horloge locale progressivement (slewing) ou brutalement si écart >128ms (stepping).

Précision : NTP peut atteindre précision 1-10 millisecondes sur réseau local, 10-100 millisecondes via Internet.

Ports : UDP 123 (client et serveur).

Stratum hierarchy

Hiérarchie qualité temps : Stratum 0 : horloges atomiques (césium, rubidium), GPS receivers, non accessibles réseau directement, Stratum 1 : serveurs NTP connectés directement stratum 0, haute précision (<1ms), exemples : ntp1.obspm.fr (Observatoire Paris), time.nist.gov (NIST US), Stratum 2 : serveurs synchronisés sur stratum 1, précision <10ms, pool.ntp.org distribué mondial, **Stratum 3+** : clients finaux (serveurs, postes travail).

Règle : serveurs internes = stratum 2 ou 3, clients = stratum 3 ou 4.

NTPv4 vs SNTP

Versions protocole : NTPv4 (RFC 5905) : version complète, algorithmes compensation dérive, filtrage sources, haute précision, serveurs et clients exigeants, SNTP (Simple NTP) : version allégée, clients uniquement (pas serveurs), moins précis mais suffisant équipements simples (switches, imprimantes).

Serveurs NTP locaux (recommandé)

Infrastructure temps interne : avantages : indépendance Internet (fonctionne même si coupure WAN), précision meilleure (réseau local <1ms vs 10-100ms Internet), contrôle total (pas dépendance services tiers).

Architecture : 2-3 serveurs NTP internes (stratum 2) synchronisés sur pool.ntp.org (stratum 1 Internet), serveurs et équipements réseau synchronisent sur NTP internes (stratum 3), clients postes/laptops via AD ou NTP interne.

Matériel dédié : petits serveurs Linux (Raspberry Pi suffit), appliances NTP (Meinberg, Microsemi), ou VMs dédiées.

Serveurs NTP redondants

Haute disponibilité temps : minimum 3 serveurs NTP : algorithme NTP nécessite 3+ sources pour détecter serveur défaillant (majorité vote), avec 2 serveurs seulement impossible savoir lequel est faux.

Le client choisit automatiquement la meilleure source (latence, stabilité).

Serveurs NTP externes publics

Pool NTP mondial : pool.ntp.org : milliers serveurs volontaires mondiaux, DNS round-robin géographique (0.fr.pool.ntp.org = serveurs France), gratuit, fiable, serveurs institutionnels : ntp.obspm.fr (Observatoire Paris), time.google.com (Google), time.cloudflare.com (Cloudflare), time.windows.com (Microsoft).

Recommandation : combiner pool.ntp.org + serveurs institutionnels pour redondance.

NTP Authentication

Éviter serveurs NTP malveillants : risque : attaquant peut créer faux serveur NTP (MitM), décaler horloges (casser Kerberos, invalider certificats), masquer attaque (logs mal horodatés).

Solution : clés symétriques partagées serveur/client.

Restriction accès

Limiter qui peut interroger : principe : serveurs NTP internes ne doivent répondre qu'aux clients internes.

Firewall : bloquer UDP 123 entrant depuis Internet (sauf serveurs NTP publics si vous en hébergez).

NTS - Network Time Security

Nouveau standard chiffré : fonctionnement : TLS 1.3 chiffre trafic NTP, authentification mutuelle serveur/client, support : chronyd 4.0+ (2020), pas encore ntpd classique.

Alertes drift

Monitoring dérive horloge : seuils alertes : warning si offset >100ms (vérifier), critical si offset >1000ms (1 seconde, action immédiate), outils : Nagios/Icinga checks NTP, PRTG sensors, scripts personnalisés.

Action si drift : vérifier connectivité serveur NTP (firewall bloque ?), vérifier serveur NTP fonctionne, forcer resync, investiguer cause (hardware BIOS clock défaillante ?).

Logs NTP

Traçabilité synchronisation : fichiers logs : `/var/log/ntp.log` ou `/var/log/chrony/tracking.log`, événements : changements source NTP, ajustements importants horloge (stepping), erreurs synchronisation.

Centralisation : envoyer logs NTP vers SIEM pour corrélation (détection désynchronisations corrélées avec incidents).

Corrélation événements

Reconstitution attaque : scénario : attaquant compromet poste utilisateur 14h23, scan réseau interne 14h25-14h27, exploitation vulnérabilité serveur 14h29, élévation privilèges 14h31, exfiltration données 14h35-14h42.

Sans NTP : logs désynchronisés (firewall +10min, serveur -5min, endpoint +3min) → impossible reconstituer séquence → investigation échoue.

Avec NTP : tous logs horodatés précisément → timeline claire → identification vecteur attaque, durée compromission, données exfiltrées.

SIEM et corrélation

Centralisation logs : SIEM (Splunk, Sentinel, QRadar) collecte logs multi-sources, corrèle via timestamps (events <1s écart = possiblement liés), crée timeline automatique.

Règles corrélation : "Si connexion SSH depuis IP suspecte ET élévation privilèges <5min après ET accès base données <10min après → ALERTE", fonctionne UNIQUEMENT si timestamps précis et synchronisés.

Audit trails

Traçabilité réglementaire : exigences : PCI DSS exige synchronisation horloges tous systèmes traitant cartes bancaires, ISO 27001 nécessite logs horodatés précisément, RGPD traçabilité accès données personnelles, les auditeurs vérifient : configuration NTP active ?, serveurs référence fiables ?, logs montrant synchronisation continue ?.

UTC recommandé

Temps universel coordonné : avantages : pas de changements heure été/hiver (pas décalages logs 2 fois/an), cohérence globale (filiales internationales), simplicité corrélation.

Configuration : serveurs en UTC, conversion local time uniquement affichage utilisateur (interfaces web, emails).

Linux : `timedatectl set-timezone UTC`.

Windows : possible mais complexe (les applications attendent local time).

Fuseaux horaires

Gestion si local time : problème : changement heure été/hiver crée ambiguïté (3h du matin existe 2 fois lors passage hiver), logs 2h30-3h30 passage été = trou 1h, solution : timestamps en UTC dans logs, affichage local time pour humains, formats : ISO 8601 avec timezone (2025-01-25T14:23:45+01:00).

Environnements isolés

Réseaux sans Internet : problème : pas accès serveurs NTP publics (pool.ntp.org inaccessible), solutions : serveur NTP local avec GPS receiver (stratum 1 autonome), ou serveur NTP "local clock" (stratum 10, imprécis mais cohérence interne).

Systèmes embarqués et IoT

Contraintes ressources : NTP léger : SNTP suffit (client simple), synchronisation moins fréquente (économie batterie), fallback : si NTP inaccessible → horloge locale approximative, synchronisation dès connectivité rétablie.

• Serveur NTP unique : un seul serveur NTP = point unique défaillance. Minimum 3 serveurs NTP pour redondance et détection pannes (algorithme majorité).
• Pas d'authentification NTP : accepter tout serveur NTP expose à attaques MitM (faux serveurs). NTP authentication ou NTS obligatoire pour critique.
• Firewall bloque UDP 123 : pare-feu mal configuré empêche synchronisation. Autoriser UDP 123 sortant vers serveurs NTP, entrant depuis NTP si serveurs internes.
• Ne jamais vérifier synchronisation : dérive progressive passe inaperçue jusqu'à problèmes. Monitoring drift avec alertes obligatoire.

La synchronisation des horloges via NTP garantit corrélation événements multi-sources pour reconstituer timeline attaque précisément, validité juridique des logs avec horodatage fiable recevable en justice, et conformité réglementaire (PCI DSS, ISO 27001, HDS exigent NTP). Le protocole NTP utilise architecture stratum hiérarchique (0 horloges atomiques/GPS, 1 serveurs connectés stratum 0, 2-3 serveurs/clients synchronisés cascade) avec précision 1-10ms réseau local.

La configuration Linux utilise chronyd moderne (plus performant que ntpd) avec fichier /etc/chrony.conf listant serveurs pool fr.pool.ntp.org iburst, commandes chronyc sources et chronyc tracking pour vérification. Windows Time Service configure via w32tm avec PDC Emulator domaine Active Directory comme source autoritaire synchronisée sur NTP externe, autres systèmes domaine synchronisant automatiquement via hiérarchie AD.

L'architecture NTP interne déploie 2-3 serveurs NTP locaux (stratum 2) synchronisés sur pool.ntp.org avec minimum 3 serveurs pour algorithme majorité détectant pannes. La sécurisation utilise NTP authentication (clés symétriques MD5) ou NTS moderne (TLS 1.3 chiffré), restrictions accès (allow réseau interne uniquement), et firewall autorisant UDP 123.

Le monitoring vérifie synchronisation via ntpq -p (reach=377 OK), chronyc tracking (offset millisecondes), w32tm /query /status, avec alertes drift (warning >100ms, critical >1000ms). L'UTC est recommandé pour serveurs (évite ambiguïtés heure été/hiver) avec conversion local time uniquement affichage utilisateur.