ASM Part 7: Geolocation

he ASM can do lots of great things to protect your application, not the least of which is the Geolocation features it offers. Geolocation enforcement allows you to configure which countries can access your web application. The ASM matches the client's IP address to its physical location and if your security policy is configured to allow that location, it allows the client to access your application. If you need to block certain geographical locations (i.e. you are getting several attacks from a specific country), then you can simply disallow that Geolocation in your security policy.

The ASM uses the layer 3 IP header to identify the client's IP address, but it can also be configured to use the X-Forwarded-For (XFF) address as the source address (we'll see this in a minute). If the XFF address is trusted, then the header's inner-most value will be used as the query input.

I know what you're probably thinking...in this crazy TCP/IP world, it's fairly easy to hide the true physical location of an IP address by using anonymity networks (like Tor), proxy servers, etc. And, you would be right. So, I'll simply say that it's important to keep this in mind as you allow or disallow certain locations in your security policy (i.e. don't think that just because you disallow a certain country that you have completely blocked every person from that country). Fortunately, the BIG-IP ASM has specific geolocations identified for Anonymous Proxies. In addition, if you are concerned about clients from anonymous networks accessing your application, be sure to read all about IP Address Intelligence to find even more options for blocking these anonymous users!

BIG-IP Configuration

Let's see how the BIG-IP is set up to configure all this goodness. Navigate to Security >> Application Security >> Geolocation Enforcement and you will see the screen shown below.

Notice that I selected a few unique geolocations for your viewing pleasure. I wanted to call these out since they are not typical country locations. N/A represents all the internal IP addresses that are not mapped to a country. Other represents external IP addresses that are not mapped to a specific country. Finally, as I mentioned earlier, Anonymous Proxy represents known servers that are acting as proxies (allow clients to mask their true source IP address).

As you can see, this interface keeps it really simple...you just scroll through the list of geolocations and add the ones you want blocked to the list of disallowed locations. Then, hit save...and don't forget to "Apply Policy" when you are finished!

Blocking : Settings

If you have been reading the other articles in this ASM series, you already know about this next setting. In order to block, the ASM requires you to do more than just move a geolocation to the "disallowed" list...you have to configure the blocking settings as well. After you finish listing all the geolocations that you want to block, you will need to navigate to Security >> Application Security >> Blocking >> Settings and make sure the "Access from disallowed Geolocation" is set to "Block" (you can set it to Learn and Alarm as well if you want). The screenshot below gives you all the details:

X-Forwarded-For

Let's check out how the ASM can be configured to trust the XFF header, and then we'll get into the test to make sure all this works correctly. To trust the XFF header, you will need to configure the properties of the security policy itself. Navigate to Security >> Application Security >> Security Policies and then click on the policy you want to change. This will take you to the properties page of the policy. Be sure to view the "Advanced" configuration on this page (Basic is the default view). When you are in the Advanced Configuration view, you will see the "Trust XFF Header" at the bottom of the page. Enable this setting and then add the name of the custom XFF header and click "Add". I named mine "XFF_Geo" since we're doing this crazy geolocation stuff. As a reminder, don't forget to "Apply Policy" after making these changes...or any other changes for that matter.

Now that the custom XFF header is configured and trusted, I can use this to build a GET request from any IP address I choose.

The Test...

I used Fiddler2 (awesome tool) to craft a GET request for the online auction site I've been using for this article series (https://auction.f5demo.com). You'll notice in the screenshot below that I used the XFF_Geo to allow for a different IP address than the one I normally use. In this case, I picked an address from Antarctica and sent the request...who knew they had IP addresses in Antarctica?

The Results...

Prior to adding the Antarctica geolocation to the list of Disallowed locations, I took a screenshot of the GET request from the ASM logs (Security >> Event Logs >> Application >> Requests). As you can see in the screenshot below, the request came through just fine. You can even see at the bottom of the page that the ASM knows this address is from Antarctica. In fact, if you want, you can click the "Disallow this Geolocation" right from this screen, and the ASM will move this location to the Disallowed locations for you (you still have to "Apply Policy" though). I will remind you, though...if you click on the Disallow this Geolocation button, it will disallow every IP address from that country. I'm not saying don't do it, but just be aware. In fact, this could actually be a really helpful button if you are in the middle of an attack and you need to quickly cut off access from a given location!

After I sent the first request from Fiddler2, I updated my security policy to disallow the Antarctica location. Then, I sent the request again. Here's what the ASM caught. Notice that the violation is the exact setting from the Blocking Settings we looked at earlier