Bodet-Time
  • Accueil
  • Ressources
  • Blog
  • Pourquoi faut-il maintenir la sécurité du réseau avec une synchronisation horaire NTP ?

La distribution d'une heure précise est un élément essentiel pour le fonctionnement quotidien et le maintien opérationnel d’une infrastructure réseau. C'est aussi un élément clé pour garantir la sécurité du réseau, à la fois en ce qui concerne les dates d'expiration des certificats numériques de sécurité (SSL/TLS) et l’horodatage d’évènements enregistrés dans les journaux système (journaux de logs).

Les activités malveillantes en ligne ont fortement augmenté ces dernières années. Les réseaux NTP (Network Time Protocol) étant particulièrement visés, de nombreuses études ont été menées pour tenter de les protéger des cyberattaques. Un moyen simple pour les pirates d'affecter la synchronisation NTP d’une entreprise est l’usurpation d’identité (spoofing). L’usurpation consiste à tromper le réseau d’une entreprise en lui fournissant une heure incorrecte.

Le meilleur moyen pour un pirate de réaliser une attaque par usurpation (spoofing attack) est d’accéder directement au serveur NTP et d’en modifier l’heure distribuée. Dans ce cas précis, une protection standard du serveur ne suffit pas. En accédant au réseau, les pirates peuvent alors surveiller l’ensemble du trafic NTP. Ils accèdent alors à l'adresse IP du serveur NTP et peuvent ainsi duper l’ensemble des clients NTP du serveur en leur distribuant une heure erronée.

Les attaques par usurpation sont d’autant plus difficiles à éviter lorsque la source de synchronisation horaire est externe, notamment lorsque l’heure est récupérée sur internet. Bien que des solutions existent pour détecter et protéger son réseau contre les logiciels malveillants, utiliser une source externe NTP expose à un manque de fiabilité et à un risque de validité. Bien qu'un Fournisseur d'Accès à Internet (FAI) soit en mesure d’empêcher l'usurpation d’identité, rien ne remplace la fiabilité de serveurs temps NTP locaux associée à la mise en place de procédures de sécurité réseau strictes.

Ci-dessous, quelques recommandations usuelles pour maintenir la sécurité d’un réseau lorsqu’une synchronisation NTP est utilisée.

Pourquoi utiliser plusieurs serveurs de temps NTP ?

Le protocole NTP peut être configuré pour récupérer l’heure depuis plusieurs sources horaires de références différentes. Si une horloge de référence diffère des autres, cette référence temps sera automatiquement ignorée. De ce fait, l'utilisation de plusieurs serveurs de temps NTP est un moyen simple et efficace de renforcer la sécurité d’un réseau. En effet, il devient plus difficile pour les pirates (hackers) de duper l’ensemble des clients NTP qui rejettent systématiquement la source horaire de référence qui dérive (non synchronisée aux autres sources). Les clients NTP se réfèrent alors aux autres sources horaires de référence qui indiquent quant à elles une heure identique et synchronisée. Plutôt que d’usurper la référence horaire d’un seul et unique serveur de temps, les pirates devront dupliquer l’usurpation sur l’ensemble des serveurs NTP.

Pourquoi mettre en place le cryptage NTP ?

Partie intégrante de la synchronisation horaire, les paquets de données NTP sont une mine d'informations sensibles qui, entre de mauvaises mains, peuvent être utilisées pour violer les réseaux. Il est donc essentiel pour les administrateurs réseau d’empêcher l'accès à ces données aux utilisateurs non autorisés. Pour cela, il est recommandé d’utiliser les options de cryptage NTP telles que les clés symétriques. Protéger les paquets de données de cette manière augmente ainsi la probabilité que les attaques par usurpation échouent.

Pourquoi redémarrer le service NTP ?

Si un paquet de données NTP entrant indique un décalage horaire important, le client devrait détecter une anomalie et le rejeter dans le cadre du processus de synchronisation NTP automatisé. Le décalage horaire nécessaire pour déclencher ce processus est appelé « seuil de panique ». Si ce « seuil de panique » est déclenché, il est recommandé de fermer le service NTP après avoir horodaté l’évènement dans les journaux système. Le vrai danger demeure dans ce qui arrive souvent ensuite.

Lorsqu'un service essentiel s'arrête de fonctionner, le comportement par défaut de la plupart des systèmes d'exploitation consiste simplement à le redémarrer. Cependant, après un redémarrage, de nombreux services NTP sont configurés pour ignorer ledit « seuil de panique ». La succession de ces deux actions facilitent la réussite d’une attaque par usurpation. En effet, tout pirate souhaitant leurrer un client doit simplement lui envoyer en continue des paquets de données avec une information horaire indiquant un décalage horaire important. Par conséquent, le service NTP s'arrêtera et sera redémarré par le système d'exploitation. Il acceptera alors l'heure erronée fournie dans ce paquet de données en ignorant temporairement le seuil de panique servant de bouclier protecteur.

Plusieurs actions peuvent être mises en place pour éviter ce type d’attaque par usurpation, notamment la vérification des journaux système dans lesquels sont enregistrés les évènements horodatés. En effet, lorsqu’un service NTP s’arrête au déclenchement du seuil de panique, les journaux systèmes enregistrent un évènement (horodatage), ce qui peut alerter sur une possible activité malveillante.

D’où l’importance d'utiliser plusieurs serveurs NTP pour maintenir la sécurité d’un réseau. Cela implique d'augmenter le nombre de serveurs NTP qui vont fournir au client des données horaires identiques avant que l'heure ne soit ajustée. Si la majorité des paquets de données ne transmettent pas une heure identique, le paquet de données usurpé ne sera pas considéré comme une source fiable. Dans ce cas, le process de synchronisation de l'heure du client NTP ne se fait pas et le seuil de panique ne sera jamais détecté.

Ces recommandations peuvent protéger le réseau d’une entreprise contre les attaques NTP et assurent que tous les équipements connectés au réseau, possèdent une heure fiable et sécurisée.

 

Partagez l'article