Understanding Session 0: In Windows, Session ID 0 is reserved for system services and processes running under the SYSTEM account. Any network traffic originating from these services (e.g. Windows system services, antivirus agents) appears as “Session 0” traffic. In Virtual Desktop (VDI) or multi-user environments, this traffic is shared by all users on the machine and isn’t tied to any interactive user session (Learn more). This poses unique challenges for ZTNA, which often enforces policy per user.
Best Practices (Applicable to any ZTNA, including Netskope NPA):
- Separate System Traffic from User Traffic: Use ZTNA features to route system-initiated (Session 0) traffic through a dedicated channel or virtual user account. For example, Netskope NPA introduces a special “VDI tunnel user” to handle Session 0 traffic (Learn more). This ensures traffic from system processes (like SMB file share access or domain controller lookups) is identified separately and gets its own Zero Trust policies (Learn more). Generally, isolate and tag Session 0 traffic so it can be governed independently of any logged-in user.
- Least Privilege Policy for Session 0: Apply strict ZTNA policies that only allow required system-level communications and block everything else. Identify essential services (see table below) and explicitly permit their traffic (by destination, port, and protocol) for Session 0. For instance, allow the system to reach corporate DNS on port 53, domain controllers on Kerberos/LDAP ports, or Windows Update servers on HTTPS, but block unauthorized or unexpected destinations. This limits abuse. Since malware often runs as a service to get SYSTEM privileges, a least-privilege approach ensures a malicious service can’t freely communicate to internal resources or the internet.
- Group Similar Users/Systems: In VDI or multi-user scenarios, group users with similar access needs on the same host or pool (Learn more). Because Session 0 traffic is shared, having users with vastly different access requirements on one machine could cause conflicts. For example, an admin’s system processes might legitimately access more internal services than a regular user’s.
Rationale: Grouping by access profile prevents a less-privileged user from indirectly piggybacking on system traffic needed by a high-privilege user (Learn more).
Implementation: Consider separate VMs or desktops for admins vs. standard users to align Session 0 traffic policies with the users’ roles (Learn more). - Use a Consistent Dedicated Account for Session 0 Tunnel: If your ZTNA uses a service account or virtual user for system traffic (like NPA’s VDI user), assign one consistently per host group (Learn more). Avoid configurations with multiple different tunnel users on the same machine, as this can cause tunnel instability or policy confusion (Learn more). Consistency ensures the system traffic always uses the expected identity and policy set.
- Monitor and Audit System Traffic: Enable logging and regular monitoring of Session 0 traffic through your ZTNA platform (Learn more). Audit which system processes are generating traffic and where it’s going. This helps catch misrouted traffic or potential breaches. For example, if you see the system (Session 0) trying to contact an unknown IP on an unusual port, investigate; it could be a rogue service. Netskope recommends checking client logs (like npadebug.log) to verify the dedicated tunnel is working and carrying only intended traffic (Learn more). Regular reviews can identify policy mismatches or needed adjustments (Learn more).
- Plan for Maintenance and Updates: Ensure your ZTNA solution is up-to-date to support these features. For NPA specifically, note that upgrading an existing client won’t retroactively enable VDI mode; a fresh install is needed (Learn more). Also be mindful that a Session 0 tunnel persists as long as any user is logged on, and only terminates when the last user logs off (Learn more). Design your policies knowing this tunnel may stay up between user sessions (like during fast user switching or brief logoff periods). Always test policy changes in a controlled way to ensure critical system functions (time sync, updates, etc.) aren’t inadvertently blocked.
By following these best practices, you ensure system-originated traffic is tightly controlled yet allowed where necessary, maintaining security without breaking essential services. The table below identifies common services/applications that run in Session 0 and the typical network traffic they generate. These should be accounted for in your ZTNA policy design.
Common Session ID 0 Network Traffic on Windows 10/11
The following table lists default Windows services and common third-party applications that frequently generate network traffic from Session ID 0 (the system context). For each, here are the ports and protocols used, and why the traffic originates from Session 0. This information is crucial for crafting ZTNA rules. You’ll want to permit legitimate traffic for these services while blocking or scrutinizing others.
| Service / Application | TCP/UDP Ports | Protocol | Description (Function & Why Session 0) |
|---|---|---|---|
| Windows Time (W32Time) | UDP/123 | NTP (Network Time Protocol) | The system clock syncs with time sources as a Windows service running in Session 0. In domain-joined environments, this synchronization happens with internal domain controllers. In standalone setups, organizations often configure internal NTP servers to maintain consistent time. Time sync uses NTP/SNTP over UDP port 123. ZTNA policies should allow this traffic only to approved internal NTP servers to ensure clock accuracy, which is critical for log integrity and Kerberos authentication. |
| Windows Update and BITS (Windows) | TCP/80, TCP/443 | HTTP and HTTPS | The Windows Update and Background Intelligent Transfer Service (BITS) runs as SYSTEM in Session 0 to keep devices up-to-date. In enterprise environments, updates are typically sourced from an internal WSUS or SCCM server instead of the public Microsoft update servers. ZTNA policies should allow these services to reach only the organization’s internal update servers (like WSUS) over HTTP/HTTPS (ports 80/443). Blocking this access can prevent critical OS and application updates from being installed. |
| Active Directory Domain Services (Kerberos, LDAP, SMB) | UDP/88, TCP/88 (Kerberos KDC) TCP/445 (SMB/CIFS) TCP/389 (LDAP; 636 for LDAPS) | Kerberos, SMB, LDAP | When a device is joined to an Active Directory domain, it communicates with internal domain controllers in Session 0 using the SYSTEM context. This includes Kerberos (TCP/UDP 88), LDAP/LDAPS (TCP 389/636), and SMB (TCP 445) for authentication, directory access, and Group Policy processing. ZTNA should allow these protocols only to designated internal domain controllers. Preventing access would disrupt domain logins and policy enforcement, while overly broad access increases risk of lateral movement. |
| Certificate Revocation and OSCP Checks (Windows) | TCP/80 (HTTP) TCP/443 (HTTPS) | HTTP (CRL/OCSP) | Windows services running in Session 0 periodically validate certificates using CRLs and OCSP, typically over HTTP/HTTPS. In enterprise setups with internal PKI or SSL inspection, these checks are directed to internal certificate validation infrastructure or approved proxy services. ZTNA policies should allow CRL/OCSP traffic only to internal or explicitly trusted certificate servers to ensure secure TLS communications and prevent certificate-related failures. |
| Symantec Endpoint Protection (SEP) (Enterprise AV) | TCP/8014 or 80 (HTTP) TCP/443 (HTTPS) | HTTP/HTTPS (REST API) | Symantec’s endpoint agent (SEP) runs as a SYSTEM service in Session 0, communicating with an internal Symantec Endpoint Protection Manager (SEPM) for policy and definition updates. This uses HTTP port 8014 (or optionally HTTPS 443). ZTNA should allow this traffic only to the internal SEPM server. Blocking it will prevent the endpoint from receiving security updates and could impact threat detection. |
| McAfee ePO Agent (Endpoint Mgmt) | TCP/80 (HTTP) TCP/443 (HTTPS) | HTTP/HTTPS | The Trellix (formerly McAfee) Agent operates in Session 0 to connect with the internal ePolicy Orchestrator (ePO) server for policy sync and reporting. Modern agents use HTTPS (TCP 443), while older ones may use HTTP (port 80). ZTNA policies should permit this traffic only to the internal ePO server. Inbound management (like wake-up calls on port 8081) typically happens within the LAN and doesn’t need remote ZTNA allowance. |
| SCCM/ConfigMgr Client (Microsoft Endpoint Configuration Manager) | TCP/80 (HTTP) TCP/443 (HTTPS) (TCP/445 SMB for some content) | HTTP/HTTPS, SMB | The SCCM client runs as a SYSTEM service and communicates with internal management and distribution points for software deployment and compliance. This typically uses HTTP or HTTPS (ports 80/443), and sometimes SMB (TCP 445) for content delivery. ZTNA rules should allow outbound traffic only to internal SCCM infrastructure (management points and content distribution points). Without this, endpoints may fail to receive applications, updates, or configuration baselines. |
Note that the above list is not exhaustive, but covers the most common system-originated network traffic on Windows clients. Other services or third-party agents (backup software, monitoring agents, print spooler to network printers, etc.) may also send Session 0 traffic. Always review what’s installed on your hosts and adjust policies accordingly.
Security Considerations and Mitigations for Session 0 Traffic
Properly handling Session 0 traffic in ZTNA is crucial for security and functionality. Misconfiguring it can either break core services or introduce security gaps. Here are some key considerations:
- Ensure Essential Services Are Allowed: From the table, identify which services are in use in your environment and verify your ZTNA policy permits their required traffic. For example, if the device is domain-joined, allow it to reach domain controllers on Kerberos, LDAP, or SMB. If you use a particular EDR or AV agent, allow its cloud communication. Blocking these can lead to system malfunctions (like failing to apply Group Policy if Kerberos or SMB is blocked (Learn more). Always restrict the allowed destinations to the minimum (like only your organization’s AD servers, and only the vendor’s cloud addresses for EDR) to reduce risk.
- Restrict and Inspect Non-Essential Traffic: Any network traffic from Session 0 that is not explicitly needed should be blocked by default. Since services run with high privileges, malware or attackers often abuse them to spread or exfiltrate data. For instance, an attacker who gains SYSTEM access could try to use the machine’s network access to scan or connect to internal systems. A Zero Trust policy should prevent the SYSTEM context from reaching anything not on the approved list (principle of least privilege). Consider enabling logging or alerts for unusual Session 0 connections, like the system process attempting to contact an IP or port that doesn’t match any known service. This could indicate malicious activity leveraging a service process.
- Separate Policy Rules for Session 0 (VDI Tunnel User): It’s a best practice to manage Session 0 traffic under a distinct policy identity (like the dedicated VDI user in Netskope NPA, Learn more). This way, you can craft tighter rules without affecting user-initiated traffic. For example, a regular user might be allowed to access many internal web apps, but the system (Session 0) really shouldn’t be initiating connections to those in most cases. By segmenting policies, you can enforce stricter controls on system traffic, like only allow DNS to your DNS server, Windows updates to Microsoft, and block everything else. This segmentation contains any potential misuse of system processes.
- Mitigate Lateral Movement and Spoofing: Be cautious with services like SMB (445) that could be used for lateral movement. Ideally, the ZTNA broker should only allow the endpoint’s Session 0 SMB traffic to specific servers (file servers or domain controllers) and drop attempts to reach other clients. Similarly, limit RPC or other internal service ports. This prevents a compromised host from acting as a pivot using its SYSTEM-level network access. If possible, enable client device authentication for system-initiated traffic as well (some ZTNA solutions can use device identity or posture checks in addition to the tunnel user identity).
- Monitor Compliance and Adjust: Continually monitor Session 0 traffic patterns. If you deploy a new software agent (like a new backup solution) that uses a system service, update your policies to allow its necessary traffic. Conversely, if you find allowed system traffic that is no longer needed (perhaps a legacy service that was removed), tighten the policy. Regular audits help maintain a strong security posture.
By following these practices: allowing what’s needed, denying everything else, and isolating/monitoring Session 0 traffic, you can safely enable critical Windows services and third-party agents through ZTNA. This approach minimizes the attack surface while ensuring that essential system functions (updates, time sync, domain connectivity, security agents, etc.) work reliably under a Zero Trust model. Each organization should tailor the specifics to their environment, but the general theme is strict control and visibility over all system-originating traffic.
Sources: Windows OS network behavior and port requirements (Learn more); Netskope NPA VDI configuration guide; Microsoft and vendor documentation for services and applications as cited in the table above.