Notification

  Latest launch: DarkMatter Cyber Security Report. Click here to read more

31 Oct 18

Palo Alto Application Dependencies – Reducing the Exposure

The following article describes best practices implementation of Next-Generation Firewalls to reduce exposure of the server to the source zone due to the mandatory application dependencies. Communication between VMware Horizon Virtual Desktop and Connection server is used as an example. Palo Alto Networks (PAN) firewall is used as an example of a NGFW.

The task is to configure communication between the View Desktop subnet and Connection server. In the secured networks those subnets are segregated with the firewall. It is considered that all other rules at the firewall are already created.

According to the VMware knowledge base https://kb.vmware.com/s/article/1027217, TCP ports 4001 and 4002 should be allowed between Horizon Virtual Desktop subnet(s) and Connection server(s):

 

 

A traditional L4 firewall requires source/destination address and port for rule creation which is the standard method of implementation for many years now.

NGFWs are able to dig deeper at traffic and recognize an application based on the App-ID engine. In this example, PAN firewalls consider this traffic as a ‘vmware-application’. Basically, this rule looks as follows:

 

 

But after we try to commit this change, firewall will generate application dependency warning:

 

 

Application dependencies in this case mean that additional applications have to be white-listed to allow successful communication between VDI desktops and the Connection server, even if all communication is happening on TCP ports 4001 and 4002. Hence, additional applications have to be allowed within the same rule, such as: apache-jserv, ldap, ms-rdp, pcoip, ssl, swiftmq, and web-browsing. If dependencies are not met, it is likely that the application will not work properly because the firewall will drop the traffic.

So adjusted rule should look like this:

 

 

Now all the dependencies and the application TCP/UDP ports are included within the rule and this can be a problem. Many network engineers have concerns about dependencies and opening additional TCP/UDP ports.

Allowing those applications will open a whole range of additional ports if ‘application-default’ is chosen as a service within the security rule (TCP80, TCP/UDP 389, TCP443, UDP/TCP3389, UDP/TCP4172, TCP 4001, TCP4002, TCP4009, TCP32111…). Many security assessment tools will flag this as an issue where there are too many open rules. Some environments consider that traffic using un-encrypted protocols (web-browsing or un-encrypted ldap) to be unacceptable.

Furthermore, connection server might have TCP port 80 open, but the View Desktop subnet doesn’t require to communicate to this port.

We have to keep in mind that only two communication sessions are required, one at the TCP port 4001 and the other at the TCP 4002. Initially created rule, named TEST, has to be verified with the VDI desktops communication to the Connection server. Hits should be verified at TCP ports 4001 and 4002.

After verification can be noted that:

  • TCP 4001 is logged with application vmware-view recognized
  • TCP 4002 is logged with application SSL recognized

Consequently the initial rule can be split into two more specific rules to define only relevant TCP ports required for communication and have more granularity. However application dependencies for ‘vmware-view’ remain the same.

Newly created rules are based at the traffic logs of the first rule and should have the following parameters.

Rule No

Source Zone

Destination Zone

Source Address

Destination Address

Application

Service

1

Inside

Outside

10.10.10.0/24

10.10.11.1/32

ssl

TCP 4002

2

Inside

Outside

10.10.10.0/24

10.10.11.1/32

apache-jserv

ldap

ms-rdp

pcoip

ssl

swiftmq

vmware-view

web-browsing

TCP 4001

 

Rules from the table should be positioned above the first TEST rule. After new rules are created and committed, verification of the traffic match should be done. Successful verification means that new rules are generating logs, while there are no new hits at the TEST rule. The TEST rule should be deleted.

The described procedure is also related to configuration differences between L4 firewall vs NGFW, and application dependencies in case of upgrades from older versions of PAN to more recent versions of software and application updates. New application updates can bring changes to application dependencies and consequently security rules adjustment is required.

Palo Alto software used in this example is 7.1.16, and the app-version database is 722-4157.

Author

Vjekoslav Crvelin

Sr. Engineer - Security and Network