Sophos Firewall comme relais NTP via NAT

Dans de nombreux réseaux, les clients, serveurs, commutateurs, points d’accès ou appareils spéciaux doivent simplement utiliser le Gateway-IP comme serveur de temps. Cependant, dans ce scénario, aucun serveur NTP interne complet ne s’exécute sur Sophos Firewall, qui fournit lui-même l’heure aux clients.

La solution pratique consiste à utiliser un relais NTP via NAT. Les appareils envoient NTP à l’IP du firewall, et Sophos Firewall transmet ces requêtes à un véritable serveur de temps externe ou interne. Le firewall ne devient donc pas la source de temps réelle; il traduit et autorise le trafic correspondant.

Ceci est particulièrement utile si les appareils sont configurés en permanence sur le Gateway-IP, si un environnement UTM précédent a été remplacé ou si vous souhaitez contrôler de manière centralisée les cibles NTP. Pour les nouvelles conceptions DHCP, il est souvent plus simple de distribuer le bon serveur de temps directement via l’option DHCP. Les bases peuvent être trouvées dans Sophos Firewall Configurer les options DHCP.

⚠️ Important : Le Sophos Firewall ne doit pas fournir de service NTP ouvert sur Internet. Les zones sources, les réseaux sources, les serveurs cibles et les règles de pare-feu doivent être délibérément restreints. WAN comme Source Zone sont généralement incorrects pour ce modèle.

Quelle variante convient ?

NTP via NAT est un modèle pragmatique, mais pas toujours la meilleure architecture.

Deux variantes sont importantes pour cet article :

• Variante A : Les appareils internes utilisent le pare-feu IP comme serveur NTP, le pare-feu redirige vers un serveur externe NTP.
• Variante B : Les appareils internes utilisent le pare-feu IP comme serveur NTP, le pare-feu redirige vers un serveur interne NTP. De plus, le serveur interne NTP doit être autorisé à se synchroniser en externe.

La deuxième variante nécessite donc deux règles NAT et deux règles de pare-feu. C’est le point qui manque dans de nombreuses brèves notes sur ce sujet.

Exigences

Avant la configuration, ces points doivent être clairs :

• Quels réseaux internes sont autorisés à utiliser NTP ?
• Quelle adresse IP les clients utilisent-ils comme destination NTP, par exemple Gateway-IP ?
• Quel vrai serveur NTP utiliser ?
• Faut-il utiliser un serveur de temps interne ou un service externe tel que time.google.com ou pool.ntp.org ?
• Le pare-feu peut-il résoudre de manière fiable le DNS pour les cibles FQDN ?
• L’heure système du pare-feu est-elle correctement synchronisée ? L’heure correcte est importante pour les fonctions critiques telles que l’authentification MFA, WAF, les certificats, les journaux, la corrélation VPN et SIEM. Si le pare-feu lui-même a une heure incorrecte, l’heure du système doit d’abord être vérifiée avant de rediriger Client-NTP.

Les étapes de cet article se basent sur Sophos Firewall 22.0. Les chemins de menu et les noms de champs peuvent varier légèrement dans des versions SFOS plus anciennes ou plus récentes. La configuration se fait dans l’interface WebAdmin de Sophos Firewall ou dans une automatisation API/CLI soigneusement vérifiée. Dans Sophos Central, cet ensemble de règles NAT et firewall n’est normalement pas géré comme une configuration NTP relay autonome.

Les exemples sont volontairement décrits comme une configuration IPv4, car Sophos montre également la création de l’hôte avec IP version: IPv4 dans la documentation officielle. Dans les environnements IPv6 ou dual-stack, ce modèle ne doit pas être copié tel quel. Il faut d’abord clarifier si les clients ont vraiment besoin de NTP via IPv6, quelles fonctions firewall et NAT s’appliquent dans la version SFOS utilisée, et si DHCPv6, Router Advertisements ou un serveur de temps interne direct constituent la solution la plus propre.

Quick Reference

Pour les admins expérimentés, la logique courte est simple: les clients envoient UDP 123 vers l’IP du firewall ou de la passerelle. Une règle DNAT réécrit la destination vers le vrai serveur NTP, une règle firewall autorise exactement ce trafic, puis Log Viewer confirme la Firewall Rule ID et la NAT Rule ID.

Serveur NTP externe: une règle DNAT transfère NTP de l’IP du firewall vers l’objet FQDN ou hôte du serveur NTP externe. Une règle firewall autorise NTP depuis les sources internes concernées vers WAN. Le champ critique est Original destination: il doit pointer vers l’IP du firewall ou de la passerelle.

Serveur NTP interne: deux flux sont nécessaires. D’abord, le serveur NTP interne doit pouvoir se synchroniser vers l’extérieur via SNAT/MASQ. Ensuite, une règle DNAT transfère les requêtes client de l’IP du firewall vers le serveur NTP interne. Les deux paires de règles doivent être vérifiées séparément dans Log Viewer.

Pour la première mise en œuvre, la position de règle doit être volontairement élevée, typiquement Top ou au-dessus des règles LAN-to-WAN et NAT générales. Ensuite, la position peut être intégrée au concept de règles existant tant que Log Viewer et Packet Capture montrent toujours que la règle attendue matche en premier.

Variante A : Utiliser un serveur NTP externe

Cette variante convient si les clients doivent utiliser le pare-feu IP comme serveur NTP et qu’il n’y a pas de serveur de temps interne propre. Le pare-feu traduit la requête NTP vers un serveur de temps externe, par exemple 1.sophos.pool.ntp.org, time.google.com ou un serveur de temps fournisseur délibérément choisi.

Créer un hôte FQDN pour le serveur externe NTP

Le chemin du menu est :

Hosts and services > FQDN host

Procédure :

1. Sélectionnez Add.
2. Attribuez un Nom, par exemple NTP_1_sophos_pool.
3. Saisissez le serveur externe NTP sous FQDN, par exemple 1.sophos.pool.ntp.org.
4. Enregistrez.

Si un serveur de temps interne ou externe avec un IP fixe est utilisé à la place du FQDN, un objet hôte normal peut avoir plus de sens. Il est important que la cible puisse être clairement reconnue ultérieurement dans la règle NAT et de pare-feu.

Créer une règle NAT pour le serveur externe NTP

La règle NAT garantit que les requêtes NTP adressées au pare-feu IP sont réécrites sur le serveur de temps externe. Le chemin du menu est :

Rules and policies > NAT rules

Procédure :

1. Sélectionnez Add NAT rule > New NAT rule.
2. Définissez Rule name, par exemple DNAT_Client_NTP_to_External.
3. Définissez Rule position sur Top ou placez-le au-dessus des règles générales NAT.
4. Définissez Original source sur le réseau interne concerné, par exemple LAN_NET ou IOT_NET.
5. Définissez Original destination sur le pare-feu ou Gateway-IP que les clients utilisent comme serveur NTP.
6. Pour Original service, supprimez Any et sélectionnez NTP.
7. Pour Translated source (SNAT), sélectionnez MASQ.
8. Pour Translated destination (DNAT), sélectionnez l’hôte FQDN ou l’hôte du serveur NTP externe.
9. Pour Inbound interface, sélectionnez l’interface interne ou les interfaces internes concernées.
10. Enregistrez.

    

⚠️ Ne pas laisser Original destination ouverte: si Original destination n’est pas limitée à l’IP du firewall ou de la passerelle, la règle peut agir beaucoup plus largement selon le reste du design NAT. Elle peut alors ne pas seulement transférer le trafic destiné à l’IP du firewall, mais aussi rediriger de manière transparente du trafic NTP du réseau. Pour un relais contrôlé, la règle ne doit matcher que lorsque les clients utilisent réellement l’IP du firewall ou de la passerelle comme destination NTP. Dans la vue détaillée, vous devez prêter une attention particulière à quatre points : la destination d’origine doit être réellement le pare-feu ou Gateway-IP, le service doit rester limité à NTP ou UDP 123, la destination traduite doit pointer vers le serveur de temps prévu et SNAT doit correspondre à l’itinéraire de retour.

Si les bases de NAT ou les champs DNAT ne sont pas clairs, Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT vous aidera. Cela explique également pourquoi NAT ne remplace pas une version de pare-feu.

Autoriser la règle de pare-feu pour les NTP externes

Selon la règle NAT, une règle de pare-feu appropriée est requise. Cela autorise le trafic NTP depuis les réseaux internes vers le serveur cible. Le chemin du menu est :

Rules and policies > Firewall rules

Procédure :

1. Sélectionnez Add firewall rule > New firewall rule.
2. Définissez Rule name, par exemple LAN_to_External_NTP.
3. Définissez Rule position sur Top ou placez-la au-dessus des règles générales LAN-to-WAN si celles-ci matcheraient autrement en premier.
4. Activez Log firewall traffic.
5. Définissez Source zones sur les zones internes, par exemple LAN, DMZ ou une zone IoT. WAN et Any sont incorrects pour ce modèle.
6. Définissez Source networks and devices sur les réseaux ou appareils concernés. Ce n’est pas un Any général si seuls certains réseaux doivent utiliser NTP.
7. Définissez Destination zones sur WAN.
8. Définissez Services sur NTP.
9. Définissez Action sur Accept.
10. Enregistrez.

Dans des exemples officiels ou simplifiés, Source networks and devices apparaît parfois avec Any. C’est pratique en laboratoire, mais rarement le meilleur choix en production. Un objet réseau concret comme LAN_NET, IOT_NET ou un petit groupe d’hôtes est plus propre, car il reste clair quels appareils peuvent utiliser cette redirection NTP.

La règle est principalement limitée via Source Zone, Source Network, le service, la position de la règle et la cible NAT. Si Destination networks doit également être utilisé, vous devez alors vérifier l’effet dans Log Viewer, car les règles DNAT peuvent modifier l’adresse cible visible dans l’analyse.

La connexion à cette règle est utile pour l’introduction. Après le test, vous devriez pouvoir voir dans le Log Viewer de quel réseau client provient la demande, quel Firewall Rule ID a été utilisé et si le NAT Rule ID attendu est également visible. Si aucun ID de règle ou une règle incorrecte n’apparaît, l’ordre ou la correspondance de la règle est plus important que la configuration NTP elle-même.

Pour la structure des règles, la séquence, Services et la journalisation, Comprendre et configurer correctement les règles Sophos Firewall convient également.

Variante B : Utiliser le serveur interne NTP

Cette variante convient si un contrôleur de domaine interne, un serveur de temps Linux ou un autre système interne doit être la source de temps pour les clients, mais que les clients continuent à utiliser le pare-feu IP comme serveur NTP.

Deux paires de règles sont nécessaires ici :

Créer un hôte pour le serveur interne NTP

Le chemin du menu est :

Hosts and services

Procédure :

1. Sélectionnez Add.
2. Définissez Nom, par exemple NTP_Server_Internal.
3. Définissez IP version sur IPv4 si IPv4 est utilisé.
4. Définissez Type sur IP.
5. Saisissez IP address du serveur interne NTP.
6. Enregistrez.

Paire de règles 1 : le serveur interne NTP se synchronise en externe

Premièrement, le serveur interne NTP doit pouvoir accéder lui-même à un serveur de temps externe s’il n’est pas déjà synchronisé ailleurs.

Règle NAT :

1. Ouvrez Rules and policies > NAT rules.
2. Sélectionnez Add NAT rule > New NAT rule.
3. Définissez Rule name, par exemple SNAT_Internal_NTP_to_WAN.
4. Définissez Rule position sur Top ou placez-la de manière appropriée au-dessus des règles NAT larges.
5. Définissez Original source pour héberger NTP_Server_Internal.
6. Pour Original service, supprimez Any et sélectionnez NTP.
7. Pour Translated source (SNAT), sélectionnez MASQ.
8. Enregistrez.

Règle de pare-feu :

1. Ouvrez Rules and policies > Firewall rules.
2. Sélectionnez Add firewall rule > New firewall rule.
3. Définissez Rule name, par exemple Internal_NTP_to_WAN.
4. Activez Log firewall traffic.
5. Définissez Source zones sur la zone du serveur interne NTP, par exemple LAN.
6. Définissez Source networks and devices sur NTP_Server_Internal.
7. Définissez Destination zones sur WAN.
8. Définissez Services sur NTP.
9. Enregistrez.

Paire de règles 2 : Guider les clients vers le serveur interne NTP via le pare-feu-IP

Le transfert proprement dit est ensuite construit : les clients envoient NTP au pare-feu-IP, le pare-feu transmet au serveur interne NTP.

Règle NAT :

1. Ouvrez Rules and policies > NAT rules.
2. Sélectionnez Add NAT rule > New NAT rule.
3. Définissez Rule name, par exemple DNAT_Client_NTP_to_Internal.
4. Définissez Rule position sur Top ou placez-la au-dessus des règles NAT générales.
5. Définissez Original source sur les réseaux clients internes concernés.
6. Définissez Original destination sur le pare-feu ou Gateway-IP que les clients utilisent comme destination NTP.
7. Pour Original service, supprimez Any et sélectionnez NTP.
8. Pour Translated source (SNAT), sélectionnez MASQ.
9. Pour Translated destination (DNAT), sélectionnez NTP_Server_Internal.
10. Enregistrez.

Ici aussi, Original destination est décisif: la règle doit uniquement traduire les requêtes NTP adressées à l’IP du firewall ou de la passerelle. Si ce champ reste trop large, le firewall peut aussi capturer des requêtes NTP que les clients voulaient en réalité envoyer directement à un autre serveur de temps.

Règle de pare-feu :

1. Ouvrez Rules and policies > Firewall rules.
2. Sélectionnez Add firewall rule > New firewall rule.
3. Définissez Rule name, par exemple LAN_to_Internal_NTP.
4. Activez Log firewall traffic.
5. Définissez Source zones sur les zones client internes. Évitez WAN et Any.
6. Définissez Source networks and devices sur les réseaux clients concernés.
7. Définissez Destination zones sur la zone du serveur interne NTP, par exemple LAN ou DMZ.
8. Définissez Services sur NTP.
9. Enregistrez. Si un Réseau de destination est également défini, vous devez alors tester spécifiquement si la règle de pare-feu continue de correspondre selon DNAT. Pour l’acceptation initiale, le réseau source, la zone de destination, le service, la règle NAT et Log Viewer sont généralement les points de contrôle les plus clairs.

Si le serveur interne NTP lui-même est un contrôleur de domaine, vous devez effectuer une analyse particulièrement minutieuse. Tous les réseaux clients ne doivent pas nécessairement atteindre directement chaque contrôleur de domaine. NTP peut être autorisé sans ouvrir des accès au contrôleur de domaine tout aussi larges.

Opérations, sécurité et tests

Classer les fonctionnalités IPS et de sécurité

NTP est techniquement un petit service UDP, mais UDP 123 devient également pertinent en pratique en cas d’abus, de mauvaise configuration ou de cibles externes indésirables. Si une licence Network Protection est disponible, une politique IPS adaptée sur la règle de pare-feu peut avoir du sens.

Plus important que le plus grand nombre possible de fonctionnalités de sécurité avec le NTP, c’est une conception étroite :

• Source Zone interne uniquement : empêche le pare-feu d’agir comme un relais public NTP.
• Réseaux sources en particulier : limite NTP aux clients, serveurs ou appareils qui ont réellement besoin de ce transfert.
• Set Destination Server : empêche tout serveur de temps externe et rend les journaux évaluables.
• Service uniquement NTP : évite une règle UDP trop large.
• Activer la journalisation : indique dans Log Viewer si Firewall Rule ID et NAT Rule ID fonctionnent comme prévu.

L’IPS doit donc être considéré comme un contrôle supplémentaire et non comme un remplacement d’une règle claire. Si la règle NTP autorise uniquement quelques réseaux internes à un serveur de temps défini, le gain de sécurité le plus important est déjà obtenu grâce à la portée et à la traçabilité. Lorsqu’un grand nombre de réseaux, des appareils peu clairs ou des zones IoT/OT sont impliqués, une politique IPS ciblée devient plus intéressante.

⚠️ IPS nécessite une licence de protection réseau adaptée. Si IPS est activé sur une règle très largement utilisée, les journaux et les performances doivent être surveillés. Pour un simple transfert NTP, une portée claire est plus importante qu’une combinaison inutilement large de fonctionnalités de sécurité.

Si une politique IPS dédiée est utilisée à cette fin, elle ne doit pas être copiée de manière généralisée sur tous les réseaux internes. Il est plus logique d’avoir une petite règle avec une source claire, une cible NTP définie, une journalisation active et un contrôle ultérieur dans Log Viewer.

Les autres fonctionnalités de sécurité doivent être délibérément traitées avec prudence avec NTP. Pour ce simple service UDP, Web Filtering, TLS Inspection, Application Control ou Malware Scan n’aident généralement pas avec la fonction NTP réelle. Si de tels profils sont actifs sur une règle collective, il convient de vérifier si NTP serait mieux placé dans sa propre petite règle.

Distribuez proprement NTP avec DHCP

Si les clients reçoivent leur configuration réseau via DHCP, vous devez vérifier si un transfert NAT est même nécessaire. Pour de nombreux environnements, il est plus propre de distribuer le serveur NTP souhaité directement via DHCP.

S’il existe un contrôleur de domaine ou un serveur de temps central, l’option DHCP 42 peut pointer directement vers ce serveur. NAT est particulièrement utile si les appareils utilisent déjà le Gateway-IP ou sont difficiles à reconfigurer. Pour les options spéciales DHCP, Sophos Firewall Configure DHCP Options est un meilleur début.

Vérifiez l’heure du système du pare-feu séparément

La redirection du client NTP n’est pas la même que l’heure système Sophos Firewall. Les deux doivent être vérifiés séparément :

• Heure système du pare-feu : pertinent pour Log Viewer, les certificats, MFA, VPN, l’authentification WAF, les rapports, Syslog et l’analyse de support.
• Client-NTP via NAT : Les appareils du réseau interne reçoivent l’heure via le Gateway-IP ou une adresse NTP redirigée.

Si le pare-feu lui-même a une heure ou un fuseau horaire incorrect, les entrées du journal peuvent être difficiles à corréler, les vérifications des certificats peuvent échouer ou une authentification basée sur l’heure telle que TOTP/MFA peut causer des problèmes. Ensuite, l’heure système du pare-feu et l’accès au pare-feu NTP doivent être corrigés en premier. Ce n’est qu’alors qu’il est judicieux de valider le client NTP via NAT.

Pour les environnements SIEM ou Syslog, ce point est particulièrement important : le pare-feu peut acheminer correctement le trafic NTP et quand même envoyer des horodatages incorrects à un SIEM si sa propre heure ou son fuseau horaire est incorrect.

Pour le transfert de journaux, Envoyer Sophos Firewall Syslog à SIEM convient. Pour les problèmes MFA, MFA pour Sophos Firewall WebAdmin, VPN Activer le portail et l’accès à distance doit également être inclus.

Testez NTP et isolez les erreurs

Après l’enregistrement, vous ne devez pas seulement vérifier si la règle existe. Ce qui est crucial est de savoir si un client peut réellement synchroniser NTP et si la règle NAT et le pare-feu attendus sont respectés.

Le test commence de la même manière pour les deux variantes : un client du réseau concerné utilise le pare-feu ou Gateway-IP comme serveur NTP. Une synchronisation horaire est alors déclenchée ou une courte attente est effectuée jusqu’à ce que le client envoie NTP.

Dans Log Viewer, vous filtrez par service NTP ou UDP 123.

Avec la variante A, il doit être visible :

• Le client est issu du réseau interne attendu.
• La règle de pare-feu NTP pour les hits externes NTP.
• La règle DNAT correspond à la source horaire externe.
• La cible est le serveur externe NTP prévu.

Deux choses sont à vérifier pour la variante B :

• Le serveur interne NTP est autorisé à envoyer NTP en externe.
• Les clients sont routés via DNAT du pare-feu-IP vers le serveur interne NTP. Si le Log Viewer n’indique pas clairement quelle règle s’applique, Diagnostics > Packet capture vous aidera. Là, vous devez vérifier si les paquets du client vers UDP 123 arrivent sur le pare-feu et si les paquets continuent ensuite vers le serveur de temps externe ou interne attendu.

Si aucun journal n’est visible, la demande ne peut pas du tout être envoyée au client, la règle de pare-feu n’enregistre pas ou le trafic emprunte un chemin différent. Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture convient à la vérification systématique.

Pour les problèmes NTP spécifiques au pare-feu, le journal client NTP est également pertinent. La présentation des journaux se trouve dans Dépannage Sophos Firewall : Services et journaux.

Acceptation courte

Avant l’achèvement productif, cinq points doivent être corrects :

1. Les clients utilisent réellement le pare-feu ou Gateway-IP comme serveur NTP.
2. Les règles NTP autorisent uniquement les réseaux sources internes prévus.
3. Les Firewall Rule ID et NAT Rule ID attendus sont visibles dans le Log Viewer.
4. L’heure du système du pare-feu est correcte séparément.
5. Après DHCP, VLAN, NAT ou des modifications de règles, NTP sera à nouveau testé.

Erreurs typiques

• WAN autorisé en tant que Source Zone : Le pare-feu peut involontairement agir comme un relais NTP ouvert. Limitez les zones sources aux zones internes.
• Any pour la source et la destination : La règle est difficile à contrôler. Définissez spécifiquement les réseaux sources et les serveurs cibles.
• Règle NAT présente, mais pas de règle de pare-feu : Le trafic est traduit mais n’est pas autorisé. Vérifiez Log Viewer pour l’ID de règle et l’ID NAT.
• Règle de pare-feu sans journalisation : L’analyse des erreurs devient inutilement difficile. Activez Log firewall traffic au moins pendant le test.
• La cible FQDN n’est pas résolue : La cible DNAT n’est pas atteinte. Vérifiez la résolution DNS du pare-feu.
• Le client utilise un autre serveur NTP : La règle n’est jamais respectée. Vérifiez la configuration du client ou l’option DHCP.
• Le serveur de temps ne répond pas : Le client reste non synchronisé. Vérifiez le serveur de destination, le routage et UDP 123.

FAQ