Understanding Session 0: Sous Windows, l’ID de session 0 est réservé aux services système et aux processus s’exécutant sous le compte SYSTEM. Tout trafic réseau provenant de ces services (par exemple, Services système Windows, agents antivirus) apparaît comme le trafic « Session 0 ». Dans les environnements Virtual Desktop (VDI) ou multi-utilisateurs, ce trafic est partagé par tous les utilisateurs de la machine et n’est lié à aucune session interactive utilisateur (En savoir plus). Cela pose des défis uniques pour ZTNA, qui applique souvent une politique par utilisateur.
Best Practices (Applicable to any ZTNA, including Netskope NPA):
- Separate System Traffic from User Traffic: Utilisez les fonctionnalités ZTNA pour acheminer le trafic initié par le système (Session 0) via un canal dédié ou un compte utilisateur virtuel. Par exemple, Netskope NPA introduit un « utilisateur de tunnel VDI » spécial pour gérer le trafic de la session 0 (En savoir plus). Cela garantit que le trafic provenant des processus système (comme l'accès au partage de fichiers SMB ou les recherches de contrôleur de domaine) est identifié séparément et bénéficie de ses propres politiques Zero Trust (En savoir plus). De manière générale, isolez et étiquetez le trafic de la session 0 afin qu'il puisse être géré indépendamment de tout utilisateur connecté.
- Least Privilege Policy for Session 0: Appliquez des politiques ZTNA strictes qui n’autorisent que les communications requises au niveau système et bloquez tout le reste. Identifier les services essentiels (voir tableau ci-dessous) et autoriser explicitement leur trafic (par destination, port et protocole) pour la Session 0. Par exemple, permettre au système d’atteindre le DNS d’entreprise via le port 53, les contrôleurs de domaine sur les ports Kerberos/LDAP, ou les serveurs Windows Update sur HTTPS, mais bloquer les destinations non autorisées ou inattendues. Cela limite les abus. Puisque les logiciels malveillants s’exécutent souvent en tant que service pour obtenir des privilèges SYSTÈME, une approche de privilège minimum garantit qu’un service malveillant ne peut pas communiquer librement avec les ressources internes ou Internet.
- Group Similar Users/Systems: Dans les scénarios VDI ou multi-utilisateurs, regroupez les utilisateurs ayant des besoins d'accès similaires sur le même hôte ou pool (En savoir plus). Étant donné que le trafic de la session 0 est partagé, la présence d'utilisateurs ayant des exigences d'accès très différentes sur une même machine peut engendrer des conflits. Par exemple, les processus système d'un administrateur peuvent légitimement accéder à davantage de services internes qu'un utilisateur standard.
Rationale: Le regroupement par profil d'accès empêche un utilisateur moins privilégié d'utiliser indirectement le trafic système nécessaire à un utilisateur disposant de privilèges élevés (En savoir plus).
Implementation: Envisagez des machines virtuelles ou des bureaux distincts pour les administrateurs par rapport aux utilisateurs standard afin d'aligner les politiques de trafic de la session 0 sur les rôles des utilisateurs (En savoir plus). - Use a Consistent Dedicated Account for Session 0 Tunnel: Si votre ZTNA utilise un compte de service ou un utilisateur virtuel pour le trafic système (comme l’utilisateur VDI de NPA), attribuez-en un de manière cohérente par groupe hôte (en savoir plus). Évitez les configurations avec plusieurs utilisateurs différents de tunnels sur la même machine, car cela peut entraîner une instabilité ou une confusion de politique (en savoir plus). La cohérence garantit que le trafic système utilise toujours l’identité et l’ensemble de politiques attendus.
- Monitor and Audit System Traffic: Activez la journalisation et la surveillance régulière du trafic de la Session 0 via votre plateforme ZTNA (en savoir plus). Auditez quels processus système génèrent du trafic et où il se dirige. Cela permet de détecter les déroutements égarés ou les violations potentielles. Par exemple, si vous voyez le système (Session 0) essayer de contacter une IP inconnue sur un port inhabituel, enquêtez ; Cela pourrait être un service clandestin. Netskope recommande de vérifier les journaux clients (comme npadebug.log). pour vérifier que le tunnel dédié fonctionne et ne transporte que le trafic prévu (en savoir plus). Des examens réguliers peuvent identifier des incompatibilités de politique ou des ajustements nécessaires (en savoir plus).
- Plan for Maintenance and Updates: Assurez-vous que votre solution ZTNA est à jour pour prendre en charge ces fonctionnalités. Pour NPA en particulier, veuillez noter que la mise à niveau d'un client existant n'activera pas rétroactivement le mode VDI ; une nouvelle installation est nécessaire (En savoir plus). Notez également qu'un tunnel de session 0 persiste tant qu'un utilisateur est connecté et ne se termine que lorsque le dernier utilisateur se déconnecte (En savoir plus). Concevez vos politiques en sachant que ce tunnel peut rester actif entre les sessions utilisateur (par exemple lors de changements rapides d'utilisateur ou de brèves périodes de déconnexion). Il est impératif de toujours tester les modifications de politique de manière contrôlée afin de s'assurer que les fonctions critiques du système (synchronisation horaire, mises à jour, etc.) ne soient pas bloquées par inadvertance.
En suivant ces bonnes pratiques, vous vous assurez que le trafic provenant du système est étroitement contrôlé mais autorisé si nécessaire, ce qui permet de maintenir la sécurité sans interrompre les services essentiels. Le tableau ci-dessous identifie les services/applications courants qui s'exécutent dans la session 0 et le trafic réseau typique qu'ils génèrent. Ces éléments doivent être pris en compte dans l'élaboration de votre politique ZTNA.
Trafic réseau commun Session ID 0 sur Windows 10/11
Le tableau suivant répertorie les services Windows par défaut et les applications tierces courantes qui génèrent fréquemment du trafic réseau à partir de l'ID de session 0 (le contexte du système). Pour chacun d'entre eux, voici les ports et les protocoles utilisés, ainsi que la raison pour laquelle le trafic provient de la session 0. Ces informations sont cruciales pour l'élaboration des règles ZTNA. Vous devrez autoriser le trafic légitime de ces services tout en bloquant ou en contrôlant les autres.
| Service / Application | Ports TCP/UDP | Protocole | Description (Fonction & Pourquoi Session 0) |
|---|---|---|---|
| Windows Time (W32Time) | UDP/123 | NTP (Network Time Protocol) | L'horloge du système se synchronise avec les sources de temps en tant que service Windows fonctionnant dans la session 0. Dans les environnements reliés à un domaine, cette synchronisation s'effectue avec les contrôleurs de domaine internes. Dans les installations autonomes, les organisations configurent souvent des serveurs NTP internes pour maintenir une heure cohérente. La synchronisation du temps utilise NTP/SNTP sur le port UDP 123. Les politiques ZTNA ne doivent autoriser ce trafic que vers les serveurs NTP internes approuvés afin de garantir l'exactitude de l'horloge, ce qui est essentiel pour l'intégrité des journaux et l'authentification Kerberos. |
| Windows Update and BITS (Windows) | TCP/80, TCP/443 | HTTP et HTTPS | Le service de mise à jour de Windows et de transfert intelligent en arrière-plan (BITS) s'exécute en tant que SYSTÈME dans la session 0 pour maintenir le périphérique à jour. Dans les environnements d'entreprise, les mises à jour proviennent généralement d'un serveur WSUS ou SCCM interne au lieu des serveurs de mise à jour publics de Microsoft. Les politiques ZTNA doivent permettre à ces services d'atteindre uniquement les serveurs de mise à jour internes de l'organisation (comme WSUS) via HTTP/HTTPS (ports 80/443). Le blocage de cet accès peut empêcher l'installation de mises à jour critiques du système d'exploitation et des applications. |
| Active Directory Domain Services (Kerberos, LDAP, SMB) | UDP/88, TCP/88 (Kerberos KDC) TCP/445 (SMB/CIFS) TCP/389 (LDAP ; 636 pour LDAPS) | Kerberos, SMB, LDAP | Lorsqu'un périphérique est relié à un domaine Active Directory, il communique avec les contrôleurs de domaine internes dans la session 0 en utilisant le contexte SYSTEM. Il s'agit de Kerberos (TCP/UDP 88), LDAP/LDAPS (TCP 389/636) et SMB (TCP 445) pour l'authentification, l'accès à l'annuaire et le traitement des stratégies de groupe. ZTNA ne doit autoriser ces protocoles que pour les contrôleurs de domaine internes désignés. Empêcher l'accès perturberait les connexions au domaine et l'application de la politique, tandis qu'un accès trop large augmente le risque de mouvement latéral. |
| Certificate Revocation and OSCP Checks (Windows) | TCP/80 (HTTP) TCP/443 (HTTPS) | HTTP (CRL/OCSP) | Les services Windows fonctionnant dans la session 0 valident périodiquement les certificats à l'aide de LCR et d'OCSP, généralement via HTTP/HTTPS. Dans les entreprises dotées d'une ICP interne ou d'une inspection SSL, ces contrôles sont dirigés vers l'infrastructure interne de validation des certificats ou vers des services proxy approuvés. Les politiques ZTNA doivent autoriser le trafic CRL/OCSP uniquement vers des serveurs de certificats internes ou explicitement approuvés afin de garantir la sécurité des communications TLS et d'éviter les défaillances liées aux certificats. |
| Symantec Endpoint Protection (SEP) (Entreprise AV) | TCP/8014 ou 80 (HTTP) TCP/443 (HTTPS) | HTTP/HTTPS (REST API) | L'agent de Symantec pour les points finaux (SEP) fonctionne comme un service SYSTEM dans la session 0, communiquant avec un gestionnaire interne de protection des points finaux de Symantec (SEPM) pour les mises à jour des politiques et des définitions. Cela utilise le port HTTP 8014 (ou éventuellement HTTPS 443). ZTNA doit autoriser ce trafic uniquement vers le serveur SEPM interne. En le bloquant, vous empêchez le terminal de recevoir les mises à jour de sécurité et vous risquez d'avoir un impact sur la détection des menaces. |
| McAfee ePO Agent (Gestion des points finaux) | TCP/80 (HTTP) TCP/443 (HTTPS) | HTTP/HTTPS | L'agent Trellix (anciennement McAfee) fonctionne en session 0 pour se connecter au serveur interne ePolicy Orchestrator (ePO) pour la synchronisation des politiques et la création de rapports. Les agents modernes utilisent HTTPS (TCP 443), tandis que les agents plus anciens peuvent utiliser HTTP (port 80). Les règles ZTNA ne doivent autoriser ce trafic que vers le serveur ePO interne. La gestion entrante (comme les appels de réveil sur le port 8081) se fait généralement au sein du réseau local et ne nécessite pas d'autorisation ZTNA à distance. |
| SCCM/ConfigMgr Client (Microsoft Endpoint Configuration Manager) | TCP/80 (HTTP) TCP/443 (HTTPS) (TCP/445 SMB pour certains contenus) | HTTP/HTTPS, SMB | Le client SCCM fonctionne comme un service SYSTEM et communique avec les points de gestion et de distribution internes pour le déploiement et la conformité des logiciels. Il utilise généralement HTTP ou HTTPS (ports 80/443), et parfois SMB (TCP 445) pour la diffusion du contenu. Les règles ZTNA ne doivent autoriser le trafic sortant que vers l'infrastructure interne de SCCM (points de gestion et points de distribution de contenu). Sans cela, les points d'extrémité risquent de ne pas recevoir les applications, les mises à jour ou les bases de configuration. |
Notez que la liste ci-dessus n'est pas exhaustive, mais qu'elle couvre le trafic réseau d'origine système le plus courant sur les clients Windows. D'autres services ou agents tiers (logiciels de sauvegarde, agents de surveillance, spouleur d'impression pour les imprimantes réseau, etc.) peuvent également envoyer du trafic de session 0. Vérifiez toujours ce qui est installé sur vos hôtes et adaptez vos politiques en conséquence.
Considérations de sécurité et mesures d'atténuation pour le trafic de session 0
Le traitement correct du trafic de session 0 dans ZTNA est crucial pour la sécurité et la fonctionnalité. Une mauvaise configuration peut soit interrompre les services de base, soit introduire des failles de sécurité. Voici quelques éléments clés à prendre en compte :
- Ensure Essential Services Are Allowed: À partir du tableau, identifiez quels services sont utilisés dans votre environnement et vérifiez que votre politique ZTNA permet leur trafic requis. Par exemple, si le périphérique est uni-domaine, permettez-lui d’atteindre les contrôleurs de domaine sur Kerberos, LDAP ou SMB. Si vous utilisez un agent EDR ou antivirus particulier, autorisez sa communication cloud. Bloquer ces systèmes peut entraîner des dysfonctionnements système (comme ne pas appliquer la Stratégie de Groupe si Kerberos ou SMB est bloqué (en savoir plus). Restreignez toujours les destinations autorisées au minimum (comme seulement les serveurs AD de votre organisation, et uniquement les adresses cloud du fournisseur pour l’EDR) afin de réduire les risques.
- Restrict and Inspect Non-Essential Traffic: Tout trafic réseau en provenance de la session 0 qui n'est pas explicitement nécessaire doit être bloqué par défaut. Les services étant exécutés avec des privilèges élevés, les logiciels malveillants ou les attaquants en abusent souvent pour diffuser ou exfiltrer des données. Par exemple, un attaquant qui obtient l'accès au système pourrait essayer d'utiliser l'accès au réseau de la machine pour scanner ou se connecter à des systèmes internes. Une politique de confiance zéro doit empêcher le contexte SYSTEM d'accéder à tout ce qui ne figure pas sur la liste approuvée (principe du moindre privilège). Envisagez d'activer la journalisation ou les alertes pour les connexions de session 0 inhabituelles, comme le processus système qui tente de contacter une IP ou un port qui ne correspond à aucun service connu. Cela pourrait indiquer une activité malveillante exploitant un processus de service.
- Separate Policy Rules for Session 0 (VDI Tunnel User): Il est recommandé de gérer le trafic de la session 0 sous une identité de politique distincte (comme l'utilisateur VDI dédié dans Netskope NPA, En savoir plus). De cette manière, vous pouvez élaborer des règles plus strictes sans affecter le trafic initié par l'utilisateur. Par exemple, un utilisateur régulier peut être autorisé à accéder à de nombreuses applications Web internes, mais le système (Session 0) ne devrait pas, dans la plupart des cas, initier de connexions à celles-ci. En segmentant les politiques, vous pouvez appliquer des contrôles plus stricts sur le trafic système, par exemple autoriser uniquement le DNS vers votre serveur DNS, les mises à jour Windows vers Microsoft et bloquer tout le reste. Cette segmentation permet de détecter toute utilisation abusive potentielle des processus système.
- Mitigate Lateral Movement and Spoofing: Soyez prudent avec les services comme SMB (445) qui pourraient être utilisés pour un déplacement latéral. Idéalement, le broker ZTNA devrait autoriser uniquement le trafic SMB de session 0 du point de terminaison vers des serveurs spécifiques (serveurs de fichiers ou contrôleurs de domaine) et bloquer les tentatives de connexion à d'autres clients. De même, limitez les ports RPC ou autres ports de service internes. Cela empêche un hôte compromis de servir de pivot en utilisant son accès réseau au niveau SYSTÈME. Si possible, activez également l'authentification du périphérique client pour le trafic initié par le système (certaines solutions ZTNA peuvent utiliser l'identité ou la vérification de la posture du périphérique en plus de l'identité de l'utilisateur du tunnel ).
- Monitor Compliance and Adjust: Surveillez en permanence les schémas de trafic de la session 0. Si vous déployez un agent logiciel New (comme une solution de sauvegarde New ) qui utilise un service système, mettez à jour vos règles pour autoriser le trafic nécessaire. Inversement, si vous trouvez du trafic système autorisé qui n'est plus nécessaire (peut-être un service ancien qui a été supprimé), renforcez la politique. Des audits réguliers permettent de maintenir un niveau de sécurité élevé.
En suivant ces pratiques : autoriser ce qui est nécessaire, refuser tout le reste et isoler/surveiller le trafic de session 0, vous pouvez activer en toute sécurité les services Windows critiques et les agents tiers par le biais de ZTNA. Cette approche minimise la surface d'attaque tout en garantissant que les fonctions essentielles du système (mises à jour, synchronisation de l'heure, connectivité de domaine, agents de sécurité, etc. Chaque organisation doit adapter les spécificités à son environnement, mais le thème général est le contrôle strict et la visibilité de tout le trafic provenant du système.
Sources: Comportement réseau et exigences de port du système d'exploitation Windows (En savoir plus) ; Guide de configuration Netskope NPA VDI; Documentation Microsoft et des fournisseurs pour les services et applications cités dans le tableau ci-dessus.