Anti-Virus solutions are common in all environments these days. Hard to find a corporate machine that isn’t running some form of antivirus/protection software. Some Anti-Virus solutions include a client side firewall. The client side firewall allows you to create and deploy firewall policies to your desktop/laptop fleet. These policies will include rules that will define what traffic can pass through the fleet. The traffic coming in or going out will be evaluated against the firewall policy and will then be determined if the traffic is able to continue or is it to be blocked. The policies can be defined by executable, ports, IPs, etc. Any traffic not defined in the policy will be blocked, or conversely any policy defined for blockage will be blocked. With that said, what ports, executables, IP, etc. need to be unblocked via a client side firewall rule when deploying Nomad in an environment?
Nomad in the Environment:
Once Nomad is installed on a PC that is running the ConfigMgr client, it becomes the Alternate Content Provider. Alternate content provider is the framework within ConfigMgr that allows 3rd party solutions to play the role of the content transferor. Nomad Branch has to be enabled on the package, applications (Client Settings – ConfigMgr 2012), software updates (Client Agent, Software Update – ConfigMgr 2007 or Client Settings – ConfigMgr 2012) or task sequence. The fact that Nomad is installed on a ConfigMgr client does not automatically invoke Nomad as the Alternate Content Provider. When a package, application, software updates or task sequence is deployed to a Nomad enabled client, the Nomadbranch.exe service will broadcast an election request over UDP port 1779 for the content that package, application or task sequence has associated with it. The other Nomad enabled clients on the same subnet will listen and respond on UDP port 1779. Once the Nomad clients elect the master, the Nomad peer will connect to the Nomad share of the elected master via the SMB protocol. If the content is not on the local subnet and ActiveEfficiency is not used, the client then uses the protocol defined on the ConfigMgr Distribution Point (DP) to obtain content. HTTP or HTTPS protocol will be used for ConfigMgr 2012 Distribution Point (DP) or BITS-HTTP enabled ConfigMgr 2007 Distribution Point (DP). ConfigMgr 2007 standard Distribution Point (DP) will use SMB protocol to transfer content.
If ActiveEfficiency is in use, then after the election is held and no client on the local subnet has the content, the ActiveEfficiency database is queried. The call to ActiveEfficiency is made on TCP port 80. ActiveEfficiency holds information about a site. A site is defined as a group of subnets. Once ActiveEfficiency is queried, it can be determined if there is another Nomad client within the defined site that has the content regardless of the subnet. If content is on another Nomad client that client is elected as the master and the content is downloaded via the SMB protocol. If the content is not at the site then the client connects to the ConfigMgr Distribution Point (DP) and downloads the content using the protocol defined on the ConfigMgr Distribution Point (DP).
|NomadBranch.exe||139-TCP||Content Transfer by SMB|
|NomadBranch.exe||445-TCP||Content Transfer by SMB over TCP|
|NomadBranch.exe||80-TCP (HTTP)||Master downloads from DP|
|NomadBranch.exe||443-TCP (HTTPS)||Master downloads from DP|
|NomadBranch.exe||1779-UDP||LsZ File Request/Response|
Anti-Virus Firewall Exceptions:
A firewall rule allowing traffic from the NomadBranch.exe on UDP port 1779 will need to be created on the client side firewall the running on the PCs. The Nomad Branch installer will open up UDP port 1779 within the Windows firewall. The recommendation is to allow NomadBranch.exe and File and Print sharing and not define ports. If your network team requires additional security the ports are listed in table 2.
Symantec Endpoint Protection example firewall rule:
|Actions||Executable||UDP Port||TCP Ports|
|Allow||NomadBranch.exe||1779, 137, 138||139, 445, 80, 443|
Anti-Virus File Scanning Exceptions:
1E best practice is to exclude the Nomad cache folder (C:\Programdata\1E\NomadBranch – Windows 7 and later or C:\Documents and Settings\All Users\Application Data\1E\NomadBranch – Windows XP) from the on access scan. Microsoft also recommends excluding the ConfigMgr Client cache folder, ccmcache, from the on access scan. 1E recommends to exclude the ConfigMgr Client cache folder, ccmcache, due to the fact that Nomad will hard-link the contents of the Nomad cache folder to the ConfigMgr Client cache folder, ccmcache. On Access Scanning the Nomad cache will slow down the ability for a Nomad peer to download the content in a timely manner. It is however OK to scan this location during a scheduled scan. It is also recommended to take in mind deploying packages, applications, software updates or task sequences during times where the clients would be performing a scheduled anti-virus scan. The time it takes a Nomad client to download the content from a peer during this time could will be significantly higher than normal.
One question that is asked most often is, “what if one of the files in the Nomad cache location is compromised in a malicious way.” Nomad limits this potential malicious intent by the use of .LSZ files. .LSZ files are created on the ConfigMgr Distribution Point (DP) the first time content for a package, application or software updates is requested. The .LSZ file contains detailed information about the content of the package, application and software updates. The first thing a Nomad master does is request and download the .LSZ file for that content. The .LSZ request happens on HTTP port 80 or HTTPS port 443 depending on what the SpecialNetShare value on ConfigMgr Distribution Point (DP) is set to. When an .LSZ request is made and the request contains a hash, Nomad client computes a corresponding hash of the content on its disk. If the computed hash does not match the hash by the Nomad client, the content is considered invalid (hash mismatch). If the hash matches, the content is considered valid. For valid content, a normal valid .LSZ is generated. Nomad clients download the LSZ from the ConfigMgr Distribution Point (DP) and check the content and hash are valid. If errors exists during the content validation and hashing, the Nomad client terminates the download immediately. If there’s no such error, the download proceeds normally. This way, any content that is invalid (i.e. compromised) is prevented from being downloaded by the Nomad client.
Other Network Considerations:
PXE Everywhere is often deployed as part of the Nomad Branch. PXE Everywhere will replace the need for a PXE enabled Distribution Points and Windows Deployment Services (WDS). It will also replace the need for IP Helpers in the environment. PXE Everywhere communicates on UDP port 69 (TFTP) and UDP port 4011 (BOOTP). Ports 69, 4011, and UDP 2012 will need to be allowed within the firewall. The PXE Everywhere client will also communicate on HTTP port 80 back to the PXE Central Server. This is usually installed on the ConfigMgr Primary site.
PXE Everywhere Ports:
Some vendor-specific security features such a rogue DHCP protection can interfere with PXE Everywhere’s communication. Table 3 lists the PXE Everywhere ports and the communication that occurs on them.
|PXE Everywhere||67-UDP||DHCP Request BOOTP Broadcast|
|PXE Everywhere||68-UDP||DHCP Reply BOOTP Broadcast|
|PXE Everywhere||2012-UDP||Master Election|
|PXE Everywhere||69-UDP||Boot Image Download TFTP|
|PXE Everywhere||80-TCP||Query PXE Lite Central for OSD Ad|