Intel,Altiris Group

Introduction

The first and second part of this series provided a number of insights in what Altiris Network Filtering with Intel® vPro™ Technology is capable of doing. This article focuses more on the points of consideration in applying via Real-Time System Manager or TaskServer, step-by-step in modifying the default network filter, and other miscellaneous points of information.

The platform used in this series is CMS7 based, yet the core concepts apply to CMS version 6 environments. About a year ago, Joel Smith posted some guides and insights on using the Enterprise Network Filter utility. This information is helpful for those wanting to follow-on along in a version 6 environment. The guide is posted at http://communities.intel.com/docs/DOC-1927 with the utility posted at https://kb.altiris.com/article.asp?article=34891&p=1 (i.e. Altiris KB Article 34891 - PDF and EXE downloads available)

Creating a Backup, Loading a New Configuration File, or Finding Out What Filters are in Place

Before importing one of these customized files, or creating your own customized setting, it is suggested that a backup of the default network filtering configuration be obtained. The Network Filters configuration is accessible within the Altiris CMS 7 environment via Setting -> All Settings -> Remote Management -> Real-Time Systems Management. Select "Network Filters", select "Export to File" and define a folder or location to save the present filter configurations.

Changes that are saved via the interface will update the RTSM configuration file at \Program Files\Altiris\RTSM\UIData\CBFilters.xml. This is the configuration file used by RTSM whenever a call is made to "Filter Network Traffic" as shown in the interface below.

Since a single Network Filter configuration file is defined per Notification Server, this raises a few questions about how that network filter is created and utilized. Determining the appropriate focus IP address (Target Client, Notification Server, or other), incoming vs. outgoing traffic and ports, along with desired behavior has proven difficult upon first attempts. The other key reminder is that the last saved configuration file is what will be applied each time "Filter network traffic other than to and from the Notification Server" is applied. In essence, the target network file stored at \Program Files\Altiris\RTSM\UIData\CBFilters.xml has been modified enough to perform less or more than stated by the textual reference of the interface.

If editing the network filter configuration and wanting to reset to the current CBFilters.xml file, select "Load" from the interface shown below. If wanting to import an XML file for configuration changes, select "Import". Once you select "Save", the current customized network filters will then be applied and the default CBFilters.xml file will be updated. Again - this is the configuration file referenced by RTSM within the enterprise.

Should you ever come upon a target client with a network filter already in place, the "Export" button within the RTSM page for the client will become active. If unsure what network filter setting have been applied to the client, the "Export" button will create an XML file which can be saved and contains the network filter settings. Selecting "Allow all network traffic" will remove the filter. Why would you ever need to do this? Perhaps a previous remediation session with the client set the filter, yet the technician forgot to remove it.

Use of TaskServer to Apply Network Filter to Collections of Clients

If needing to set a filter across a collection of target clients, the TaskServer Network Filter task provides a handy option. The "Isolate and Patch" scenario mentioned in a previous article provides an example how this is accomplished. The following screenshot is the CMS v7 interface to TaskServer. The format of the Network Filtering task has minor changes from that an CMS v6 TaskServer interface.

To conclude this section, note that "Use RTSM default network filter settings" refers to the current version of \Program Files\Altiris\RTSM\UIData\CBFilters.xml. Thus, whatever changes were made via the Network Filter utility will apply. The TaskServer interface provides a second option to "Import network filtering settings from a custom XML file" - this allows a one-time use of a customized XML file from the ENF Utility for the purposes of the task. Note that the customized file must be accessible via UNC path if using a remote console.

Step-by-Step to Add or Modify a Custom Network Filter Setting

From the Network Filters setting menu shown below, or if using a CMS v6 environment the Enterprise Network Filter (ENF) Utility, select plus sign or double click on an existing setting to modify.

This will open a wizard to define the specific settings to be applied. The wizard helps step through the definition of the core options to each network filter:

Step 1 - Type and Direction

• IP Protocol - whether TCP or UDP
• Inbound or outbound traffic

Step 2 - Filter Address

• IP address defining the focus point (Target Computer, Notification Server, or Defined IP address) 
• Designate whether IP address is source or destination of the traffic

Steps 3 and 4 - Ports Scope and Port Number

• Designate a single port (assumes same Source\Destination port in the data packet)
• Designate a range of ports (allows you to define whether port is either source or destination in the data packet)

Step 5 - Filter Name

• A user-defined text string to identify the network filter.

The first step is define the "Type" and Direction" of the traffic. Either UDP or TCP can be defined as Type, with either Incoming or Outgoing defined at Direction. The following screenshot shows the interface:

Step 2 determines the filter address, with three options shown. The first option is static as defined at this point. The second and third option are based on when the network filter is applied (i.e. the IP address of the Notification Server which sent the network filter, or the address of the client that receives the network filter).

The "Treat this address as" indicates whether the address is Source or Destination as defined within the data packet header. Therefore, if an incoming packet to the Target Computer, "Destination" will likely be the selection. Similar, if an incoming packet from the Notification Server, "Source" will likely be the selection.

Step 3 leads to a branch condition on what will appear in Step 4 of the wizard. If you select "Single Port", then the data packet source and destination must match the intended ports. There is no option to change in the interface. If you select "Range of Ports", than an option appears in step 4 to designate whether the network filter is looking to the Source of Destination portion of the data packet header.

In the customized network filters shared earlier, the "Range of Ports" was selected.

In the next image below, notice that this version of Step 4 provides only Source and Destination port to be defined. In referring back to the default network filters, the example to refer to is the DHCP section. One of the four entries is restated below:

RTSM_DHCPU_RX1 | Incoming | UDP | Target Computer Address | Destination | 67/68 | Source/Destination

This states that UDP traffic received by the Target Computer with a source port 67 and destination port of 68 is allowed. In essence, a DHCP lease reply to the client.

In the previous article, the PCAnywhere example could have been enhanced to designate incoming traffic must occur on a source port of 3529 and destination port of 5631, with outgoing traffic on source port 5631 and destination port 3529... if port 3529 were directly specified in the PCAnywhere application (see previous article for more information.)

In the next screenshot below, an alternative version of Step 4 is shown. Notice the additional option to directly specify whether the data packet port is Source or Destination. Also notice the slight change to the wording. Instead of designated the exact source and destination port, the image below allows designation of the range (i.e. the lower and upper boundary.)

As shown in the example, TCP port 3389 will be allowed, which is the Microsoft RDP port.

The final screenshot allows for a user-defined label to be applied to the custom network filter.

Once the "Finish" button is selected, the changes are posted to the list of customized network filters. However, until the settings are saved or exported, the changes will not be retained.

Directly Modifying CBFilters.XML

Using the Wizard interface provides a number of options, along with structure, to help define desired network filters. With the customized network filter saved as an XML file for the RTSM module to use, the question was been raised: Can I directly modify the XML file?

Sure - with the understanding that direct modification might introduce unexpected errors. The upside is that successful modifications directly to the XML raise the possibilities of how Network Filtering could be utilized. For example, in the previous article a customized network filter allowed remote desktop sessions ONLY from a designated IP address. What if designated IP address were changed based on the user's IP address from which the RTSM page was accessed?

The following image shows a small portion of the XML. The IP address is highlighted, there would be two areas in the XML where this address would need to be changed. Understand - this is just a side idea and has not been tested or validated for large enterprise usage (i.e. direct changes to the XML file).

Why Does My Network Filter Not Work in CMS v6?

With all the ideas and insights shared, there's one final point to be noted. In an Altiris RTSM v6 environment, if you apply a Network Filter to an Intel® AMT version 4.x system an error will occur. This is a known issue as documented at https://kb.altiris.com/article.asp?article=45156&p=1 (Altiris KB Article 45156... in case that link does not work.)

Only the combination of RTSM v6 and Intel® AMT version 4.x have experienced this error. In preparing this article series, I used RTSM v7 on multiple Intel® AMT versions (2.x, 3.x, 4.x, and 5.x) and did not experience the error noted. The issue could likely be resolved, yet in the prioritization of development, bug fixes, and so forth... It appeared that network filtering was not used enough by customers to necessitate a fix.

Concluding Thoughts on the Series

Altiris Network Filtering with the Intel® vPro™ Technology is a powerful tool which extends the security capabilities of isolating or restricting client network communications. With the ability to define customized network filters, the Altiris Client Management Suite provides a number of options and possibilities. This series has explored how to put those options to use. I am always interested to hear how customers are using the technology to extend their reach, augment their client security, and so forth.

The information within this series focuses on the core System Defense capabilities as supported by Altiris. Starting with Intel® AMT 3.x and beyond, the firmware has support for Enhanced System Defense capabilities (see references to Heuristics and Rate Limiting). At this time, no production client management solutions support these enhanced features at an enterprise scale and usability - but the key to remember is that the firmware can support, and that "any authenticated and authorized request" can be made to activate those features... For now, focus on what is possible within the present environment and raise the awareness of how customers are truly using the technology.