APM Security: Protecting Internal Resources Using ACLs

If you've used APM, you probably have setup the APM in Portal Access mode at one time. It is easy and gives instant access to internal resources, but aren’t you allowing more access than imagined?

APM Portal Access Mode

Let’s setup a simple test environment. There are three internal resources: OWA, an intranet website, and a website where programming source code can be accessed. The first two should be accessible through the APM but the source code website not.

The following Access Policy is created:

In the Advanced Resource Assign the two Portal Access Resources and the Webtop are assigned to the user session. Then the access profile is associated to a virtual server.

The above configuration provides access to both resources. However, note the URL Entry Field that says “Enter an internal resource”. What would happen if I enter the address of the source code resource into this field?

This results in access:

So next to the two defined resources the APM allows access to any internal resource it can reach.

The first response might be to remove the URL Entry field. This is quite easy via the “Show URL Entry Field” option on the full Webtop configuration. If this option is missing in your TMOS version please consult SOL 13593 http://support.f5.com/kb/en-us/solutions/public/13000/500/sol13593.html

Turning off the option will cause the URL Entry Field to disappear from the Webtop.

Portal Access Address

Does removing the URL Entry Field really prevent access to the source code website? Let’s have a look at the address for a Portal Access Resource.

As can be seen in the screenshot the address is:

https://webportal.brt.loc/f5-w-687474703a2f2f696e7472612e6272742e6c6f63$$/

That long string of characters between f5-w- and $$ may look like random data. However it is a hex ASCII representation of a human readable string (68 = h, 74 = t, etc.).

As we humans don’t read hex as well as computers a converter quickly converts the hex string to human readable text (http://www.string-functions.com/hex-string.aspx). It turns out to be http://intra.brt.loc.

So what if we would replace this URI with the one for the website that shouldn’t be accessible through the APM: http://cvs.brt.loc. First, the URI of the resource is converted into hex: 687474703a2f2f6376732e6272742e6c6f63. Then we substitute this hex string in the original URI and paste it into the address bar of the browser.

Just as with using the URL Entry Field there is access to a resource that is not intended to be accessible through the APM.

APM ACLs

So removing the URL Entry Field does not really prevent unintended access to internal resources. The only method on the APM to prevent unintended access is to use APM ACLs.

This means creating an deny all ACL that blocks all traffic and attach it to the session via the ACL or Advanced Resource Assignment in the VPE.

Note that this does not block traffic to the published Portal Access Resources on the Webtop as long as they include their required access. When you create a Portal Access Resource based on a template this happens automatically. For a Portal Access Resource without a template the access is configured via the Resource Items on the bottom of the Portal Access Resource configuration.

When adding new Portal Access Resource please remember to place them before the deny all ACL via the All ACLs configuration.

So to complete the setup I created a L7 ACL that denies all traffic to http and https and put it after the portal access ones. The All ACLs list is shown below:

Then it must be assigned to the user session via the Advanced Resource Assign.

After starting a new APM session when I now attempt to access the source code website via the URL Entry Field or the address field of the browser then access is blocked.

So only the published Portal Access Resources on the Webtop are accessible, and all other internal resources are unavailable through the APM.

I’d like to thank Kees van de Bos for bringing this to my attention and thereby providing the final push to write this article. Also I’d like to thank Frank ten Wolde for his input and review of the article. Hopefully it will help others in creating an even more secure APM environment.