Technical Articles
F5 SMEs share good practice.
cancel
Showing results for 
Search instead for 
Did you mean: 
Custom Alert Banner

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:

 

0151T000003d6JnQAI.png

 

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.

0151T000003d6JoQAI.png

 

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?

0151T000003d6JpQAI.png

 

This results in access:

0151T000003d6JqQAI.png

 

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.

 

0151T000003d6JrQAI.png

 

 

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.

0151T000003d6JsQAI.png

 

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.

0151T000003d6JqQAI.png

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.

0151T000003d6JuQAI.png

 

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:

0151T000003d6JvQAI.png

 

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

0151T000003d6JwQAI.png

 

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.

0151T000003d6JxQAI.png

 

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.

Comments
Nice work and article!! I think the need for a deny all ACL should be more clear in in both F5 documentation and during the F5 APM course
Mark_129802
Nimbostratus
Nimbostratus
This was EXACTLY what I was looking for! Thanks!
Georgi_Georgie1
Nimbostratus
Nimbostratus

Very good explained. Thanks!

 

reprobation_149
Nimbostratus
Nimbostratus

Great article! Just added it to my policies.

 

Lee_Sutcliffe
Nacreous
Nacreous

I have tried the above but when I add a deny ACL(placed at the very end) in Advanced Resource Assign it denies access to portal access resources with lower a lower ACL value. Not sure why the portal access resource ACLs are not taking precedence.

 

Brad_Otlin
F5 Employee
F5 Employee

MrPlastic: Does your Portal Access item have a "Resource Item" created? This should be required and will then create an ACE for that specific URL/IP.

 

Lee_Sutcliffe
Nacreous
Nacreous

Hi Brad, yes it certainly does, even with resource items created from templates such as OWA. I'm not working with the customer anymore but I can still replicate the error in my lab.

 

Version history
Last update:
‎24-Sep-2014 07:29
Updated by:
Contributors