Introduction:
What if you could truly isolate and remediate a client without involving network support or leaving your desk? What if the remediation process required isolating the target computer from the network to avoid spread of a virus? What if the client computer you are remediating needs to be protected from outside communications while you perform certain tasks?
Can all this be done with a remote desktop session and limited file transfer capability? With Intel® vPro™ Technology, Altiris Client Management Suite, and customized Network Filters - Yes! This article provides additional guidance and insight on how to benefit from Network Filtering. With the Enterprise Network Filter utility from Altiris, you have flexibility to define how the 32 inbound and 32 outbound network filters are actually used. A few example configuration files are attached for you reference and usage - the file "SampleCustomizedFilters.zip" contains two XML files:
- Mstsc restricted smb open - The additional filter settings will allow Microsoft Remote Desktop from a specific location, along with allowing the client to access any Microsoft based fileshare.
- PCA force port src dst - The additional filter settings will allow a PCAnywhere session to the target client. The file is configured to allow any PCAnywhere session as long as the incoming and outgoing communications from the target client are on TCP 5631. Interestingly, unlike a Microsoft RDP session, a PCAnywhere session will allow file transfer thus the network filter changes are simplified.
For those looking for some additional insight on how these configuration files were created or can be utilized, the next few sections provide the foundational understanding with an upcoming article getting into the details. Network Filtering customizations require an upfront learning curve, but once the principles are understand a number of possibilities open up. Even those using Symantec Endpoint Protection might be intrigued to learn how this out-of-band management functionality adds to the client security potential.
Example Network Filtering Scenario
There are a host of scenarios and situations where next filtering might benefit your enterprise. One scenario is shared here, and I invite the community to post their scenarios or ask questions. The scenario is as follows:
- Target Client Computer - Unbeknownst to the user, the system has an outdated security solution and has been infected by a virus\worm. The user is experiencing delayed performance and unexplained events which prompt a call to the IT Support Helpdesk.
- IT Support Technician - Receives support request to address the user's system troubles. Early diagnosis reveals the system has been infected. The user's system must be isolated from the network, meaning that communications in or out of the client must be restricted and remediated. The support technician will be using a Microsoft remote desktop to interact with the remote client computer, and will need to install files from a network share. (A similar concept would apply for PC Anywhere… yet to demonstrate the capability, I purposely chose this setup. Please keep reading)
- Altiris Notification Server - The technician accesses the Altiris Console to invoke a Network Filter. However, the default network filter limits traffic to a very limited set of functions between the Notification Server and a target Intel® vPro™ technology system. If the standard Network Filter is used, Microsoft remote desktop and file transfer will be restricted. Therefore, a customized network filter is required, which is provided via the Altiris Enterprise Network Filter (ENF) Utility. The customized filter will allow Microsoft remote desktop ONLY between the IT Support Technician PC and the Target Client Computer. (NOTE: The ENF is a free add-on for Altiris v6 environments, and included in Altiris v7 environments.
The following diagram provides a visual of the scenario:
Background Information on Network Filtering
Network Filtering is the Altiris implementation of the System Defense feature within Intel® vPro™ Technology platforms. The System Defense feature was formerly called Circuit Breaker. References to the legacy name (i.e. Circuit Breaker or CB) will appear in the provision profile access control list (ACL), the original configuration file, and so forth. Hence, "Network Filtering", "System Defense", and "Circuit Breaker" all refer to the same core feature and capability.
Network Filtering effectively blocks all inbound and outbound network communications at the physical network interface of the client system, except for the secured Intel® Active Management Technology communications to the firmware on TCP ports 16992-16995. These communications demand an authentication either via MD5 Digest or Kerberos, the authenticated user must be authorized to perform actions as defined by the ACL in the firmware, and optionally the session can be encrypted via TLS or Mutual TLS.
With the base filter blocking all traffic, the "Network Filtering" configuration actually define what communications are permitted - thus the name might be misleading to some, as it should be interpreted as "Permitted Network Communications". It allows for up to 32 inbound and 32 outbound types of communications to occur. Network filters can be applied whenever the Intel® AMT firmware within the Intel® vPro™ Technology platform can be contacted. Thus the state of the host operating system, security agents, or power-state of the network connected device is not an inhibitor. These network filter settings will remain in effect until an authorized and authenticated communication on the Intel AMT management ports (16992 or 16993) occurs, and the network filter settings are changed or removed. Rebooting the computer, reconfiguring software agents, or reinstalling the operating system will not change the applied network filters. For this reason, Intel® AMT is often referred to as "out-of-band management" for client systems, as it is able to operate regardless of the host operating system state.
A previous article provided an introduction to the Altiris Enterprise Network Filter (ENF) utility, along with an example customized network filtering configuration file to allow software distribution via Altiris TaskServer to a target client. A hands-on lab and video demonstration entitled "Isolate and Patch" was built to demonstrate this capability (see the second section and video)
The previous articles spawned additional thought on what else could be done - and how. Understanding network filtering and the Enterprise Network Filter (ENF) utility provides a new paradigm for efficient and secure remote remediation. The trick how these technologies work, how to properly define the network filtering configuration, exactly what types of communications to allow, whether specific application communication preferences require adjustment, and so forth.
Getting Into the Details of the Default Network Filter
The base filter blocks all communications, except for the Intel® AMT registered ports of 16992-16995 as defined by the IANA. This is the default nature of the Intel® vPro™ Technology System Defense capability. Keep in mind, network IP addressing, DNS or NetBIOS name resolution, and related base functionalities will be totally blocked by the default filter action.
Customization from the base filter defines what traffic is allowed. Defining the allowed communications requires a few consideration factors:
- Inbound or outbound traffic
- IP Protocol - whether TCP or UDP
- IP address defining the focus point (Target Computer, Notification Server, or Defined IP address) in the context of the Target Client system which receives the filtering configuration. It is highly recommended that this be a static IP address.
- Define whether the IP address is Source or Destination for the traffic in the context of the target client system
- Define which ports to allow
- Define whether the ports are Source or Destination
Altiris has provided a default network filter which allows the fundamental network addressing, name resolution, and so forth. It also allows basic communication ONLY between the Notification Server that issued the network filter configuration and the target client. The following image provides snapshot of the default network filter settings. Although the image is from CMS7, the same options and configuration exists with CMS6:
To help reinforce what is actually happening, the following list provides an explanation of each setting provided by the default Altiris Network Filter.
- Allow incoming TCP communications from the designated Notification Server to the target client on the defined NS ports (default is port 80), with the port treated as Source of the communication.
- Allow outgoing TCP communications to the designated Notification Server from the target client on the defined NS ports (default is port 80), with the port treated as Destination of the communication
- Allow incoming TCP DNS responses to the Target Client System from any system
- Allow outgoing TCP DNS queries from the Target Client System to any system
- Allow incoming UDP DNS responses to the Target Client System from any system
- Allow outgoing UDP DNS queries from the Target Client System to any system
- Allow incoming TCP LDAP responses to the Target Client System from any system
- Allow outgoing TCP LDAP queries from the Target Client System to any system
- Allow incoming UDP LDAP responses to the Target Client System from any system
- Allow outgoing UDP LDAP queries from the Target Client System to any system
- Allow incoming TCP secure LDAP responses to the Target Client System from any system
- Allow outgoing TCP secure LDAP queries from the Target Client System to any system
- Allow incoming UDP secure LDAP responses to the Target Client System from any system
- Allow outgoing UDP secure LDAP queries from the Target Client System to any system
- Allow incoming TCP communications from the designated Notification Server to the target client on the defined NS Tickle ports (ICMP Keep-Alive)
- Allow outgoing TCP communications to the designated Notification Server from the target client on the defined NS Tickle ports (ICMP Keep-Alive)
- Allow incoming UDP Kerberos responses to the Target Client System from any system
- Allow outgoing UDP Kerberos requests from the Target Client System to any system
- Allow the Target Client System to send ARP broadcasts
- Allow the Target Client System to receive ARP broadcasts
- Allow incoming UDP DHCP responses to the Target Client System from any system
- Allow outgoing UDP DHCP requests from the Target Client System to any system
- Allow incoming DHCP broadcasts from any system on the network to the Target Client System
- Allow outgoing DHCP broadcasts to any system on the network from the Target Client System
- Allow incoming NetBIOS Name Resolution from the designated Notification Server to the target client
- Allow outgoing NetBIOS Name Resolution to the designated Notification Server from the target client
At this point, 13 inbound and 13 outbound "allowed communications" have been defined.
Did you notice the subtle differences in the above explanations? Once the default network filter from the Notification Server has been applied to the client, the client can effectively:
- Obtain or renew an IP address
- Request and receive a DNS resolution
- Request and receive a directory authentication via Kerberos\LDAP
- Communicate via port 80 only to the designated Notification Server
What might be expected yet is inherently denied in this configuration includes the following:
- The Altiris agent is able to see new package advertisements, yet can only obtain the actual package from the designated Notification Server on port 80. If the Altiris agent is expecting to utilize a Package Server (different IP address) or use Server Message Blocks (TCP port 445) to download the package, this would not be allowed.
- The Target Client is able to resolve the IP address of the Notification Server, yet cannot access the NScap fileshare. (that would require TCP port 445)
- It may appear that the Target Client is able to access the Altiris Console, yet the console load process will fail since more than port 80 is required
With that lengthy explanation - a key question comes to mind: "How do you remotely remediate a client if the default network filter is tied to the issuing Notification Server, and no remote desktop session is possible?" This is one of the original intents of the technology. Doesn't this perceived limitation impact one of the original intents of the technology? What about the example scenario shared earlier in this article?
The short answer "No - this is not a limitation of the Altiris Network Filtering" - see the attached sample files as proof. The next part of this article will explain more.
The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries
Read Part 2 here: Part 2 - Using Network Filtering to Enhance Your Security Control