Introduction
The first part of this series provided the background of Altiris Network filtering, with two sample files hinting at the customization options. Building upon that foundation, this article focuses more on how to define the customized Network Filtering configurations which might assist with the day-to-day technician and helpdesk operations. The next article in this series will provide more of the step-by-step process and miscellaneous items in regards to creating and applying customized network filters.
This article includes the previously shared sample files, along with an additional attachment on Altiris ports and protocols. The sample network filtering configuration files will be the reference point in stepping through the "how-to". As a quick review, "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.
Understand What Traffic Is To Be Allowed
In defining allowed network communications for the target client system, the six core points of consideration are being restated for easy reference:
- 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
Access to documentation which specifies ports and protocols used for a particular service or application will assist in determining the customized network filter configuration. Although a little outdated, the attached PDF (Altiris Products Ports and Protocols) was obtained from http://kb.altiris.com article 1176. In addition, testing and validation of traffic with a network sniffer will help confirm reported or desired behavior. This article includes screenshots from Wireshark, with more explanation later on how this helped determine the correct ports and traffic behavior.
Closer Look at the MSTSC Example
The following screenshot shows the four entries added to the base network filtering configuration for this example. Building from the base network filtering configuration file, 15 of the allowed 32 customized network filter settings are now used for inbound and outbound traffic respectively. (i.e. a total of 30 entries now exist)
The four changes will allow the following:
- Incoming connections received at the target computer sent from a source port of TCP 445 (Server Message Blocks used for Microsoft network fileshares)
- Outgoing connections from the target computer sent on TCP port 445
- Incoming connection sent from system on IP address 192.168.0.103 TCP port 3389 (Microsoft Remote Desktop using mstsc.exe)
- Outgoing connections from system on IP address 192.168.0.103 TCP port 3389
This will allow the target client to access any Microsoft network file share within the environment. (Note of caution here: Viruses will sometimes scan for and proliferate via network fileshare from the client on port 445, thus this filter may not quarantine a virus). However, an external system such as client at IP 192.168.0.103 cannot access any network fileshares on the target computer which received the network filtering.
This filter will also allow Microsoft RDP requests ONLY from 192.168.0.103. The target client system will not be able to initiate a session out. This situation reinforces the previous guidance that the network filter - as is presently defined - should specify a static IP address. Perhaps a future product improvement, or an opportunity for a handy utility to check the IP address of the user applying the customized network filter and inserting that user's IP address into the customized configuration.
To reinforce what is happening:
- Can the PC Technician access any fileshares on the target client system over the network? (No)
- Can the target client access any fileshares on other systems? (yes)
- In addition to the system at 192.168.0.103, can any other system access the client via Microsoft Remote Desktop? (no)
Perhaps that configuration is not exactly what you are looking for. The intent is to explain "what" is happening in order to better understand "how" to appropriately configure the enterprise network filter.
What if you wanted to allow the target client to access a defined remote fileshare which contains patches, diagnostic utilities, and so forth? (I am intentionally withholding the exact answer - yet will give you a hint. If the remote fileshare were at 192.168.0.103, reuse the third and fourth custom settings noted above with two settings swapped…. If unsure, post a comment below)
Closer Look at the PCAnywhere Example
The following screenshot shows the two entries made to allow PC Anywhere connections to the client. If added to the base network filtering configuration, 14 defined inbound and outbound settings have been specified resulting in a total of 28 entries.
The two entries are as follows:
- Allow incoming connections received by the target computer on TCP port 5631 as the destination port
- Allow outgoing connections sent by the target computer on TCP port 5631 as the source port
Although PCAnywhere status advertisements on UDP 5632 will be blocked, the target client system will receive a PCAnywhere request from any system which specifies the correct destination port. The target client will be unable to initiate a PCAnywhere request to another client.
This example raises a focus point which has caused a lot of misunderstanding around network filter - not all applications communicate on the same source and destination ports. In fact, often one of those ports is randomly selected based on the application and network configuration. Notice the selection of words used above regarding destination versus source port in relation to the direction of traffic and the focus IP address.
To provide a visual reference of what is happening, the following screenshots show a network trace during a PCAnywhere session. In the first example, the PC Technician is at IP address 192.168.0.2 and the target client is at IP address 192.168.0.105. Notice that the source port is 3529 and the destination port is 5631. The source port - which could be referred to as the outbound port from the PC Technician's system - was randomly selected by the application. A future PCAnywhere session might use a different outbound and inbound port from the context of the PC Technician's PC. If the Target Client which was filtered attempted to initiate a PCAnywhere session to a different client, the source port of the communication would not match 5631 and the connection would be blocked at the physical network interface on the client device.
In the above example, the PC Technician is using PCAnywhere QuickConnect (PCAQuickConnect.exe). When the PC Technician attempts to connect, since the client is filtered the following prompt will occur as PCAnywhere quick connect is unable to connect on UDP port 5632 to check status of the PCAnywhere service. Clicking "Yes" will send the request on TCP port 5632 which will succeed in this scenario.
If the technician were using the full PCAnywhere application (WinAw32.exe), the advanced configuration options allow changes to the remote communications parameters. In the example above, the outbound port from the PC Technician's system was randomly selected. However, as shown in the screenshot below, the outbound port could be forced to 5631 instead of randomly selected port.
As shown in the following Wireshark network trace, the source and destination port is now the same (i.e. TCP port 5631). This capability to define the exact outbound data port will vary among applications, yet provides a nice reference point in this scenario.
To help reinforce what the configuration is doing, what two additions would be needed to restrict PCAnywhere access ONLY to those PC Technicians which are able to define the outbound PCAnywhere communication? The additional entries would include a minor change in the designation of data port as Source or Destination.
- PCA_RX2 | Incoming | TCP | Target computer address | Destination | 5631 | Source
- PCA_RX2 | Outgoing | TCP | Target computer address | Source | 5631 | Destination
This states that incoming traffic to the target computer address must have a source port TCP 5631, and that traffic sent from the target computer must have a destination port TCP 5631.
What are some of the key differences between the PCAnywhere example and the previous example with Microsoft RDP into the client and fileshare access from the target client?
- With the PCAnywhere example, fileshare access is blocked. File transfers can occur via PCAnywhere to the target client system using the PCAnywhere network ports
- The PCAnywhere example allows any PC Technician to access the target client, since the focus address is the target client system and not the PC Technicians system.
Additional Network Filtering Scenarios
The above explanations have likely raised some thought about additional network filtering scenarios and configurations. Within the Altiris Network Filtering configuration parameters, the desired customized filter may include one of the following:
- Customized filter to allow Deployment Server communication to the client. Thus secure the client during update or image deployment process.
- Based on an inventory report, identify client system requiring remediation. Client systems are placed in a dynamic collection, a remediation network filter is applied, technicians are notified to address, and the user receives a text message advising them of the situation
- Migration between client security solution will temporarily expose the client to network risks. Apply a customized network filter to isolate the client system, migrate the client security solution, and then remove the network filter.
- Allow for SWD packages and materials from a Package Server which would require a designated IP address to be defined
The attached PDF document provides some insights to the ports and protocols used in the Altiris environment. This information, along with other production materials and internet searches, will help define what permitted traffic to be specified in your custom enterprise network filter.
If you have additional ideas, please share or reach out to validate the idea and possibly collaborate on how it might be configured. As noted in the Microsoft RDP section above, the focus IP address is recommended to be static. In principle, a handy tool or interface change would check the IP address of the system initiating the network filtering (i.e. PC Technician's PC from which webconsole session is running). If that were done, a dynamic IP address could be inserted at the time the customized network filter were applied.
Concluding Thoughts
The next article in the series will focus more on how-to add or customize the actual settings. It will also provide some miscellaneous data points relating to network filtering. By this point, I certainly hope that a great appreciation and resulting usage of network filtering will be made. It is a powerful tool which is often misunderstood. Network filtering is not a replacement to Symantec EndPoint Protection or similar PC security solutions, yet it could be used to enhance the overall security of the client by allowing only permitted inbound and outbound traffic at the physical network interface of the client.
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
Part 1: Using Network Filtering to Enhance Your Security Control
Part 3 - Using Network Filtering to Enhance Your Security Control