The BIG-IP Application Security Manager Part 7: Geolocation
This is the seventh article in a 10-part series on the BIG-IP Application Security Manager (ASM). The first six articles in this series are: What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting The 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. Well, that wraps up the ASM Geolocation discussion. I hope you enjoyed learning about this really helpful feature. Come back next time for more fun with the ASM! Update: Now that the article series is complete, I wanted to share the links to each article. If I add any more in the future, I'll update this list. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event Logging
iRule error - bad IP address format (line x)
I just deployed this irule: when HTTP_REQUEST { if { [HTTP::header exists "X-Forwarded-For"] } { set client_ip [HTTP::header value "X-Forwarded-For"] set fromCountry [whereis $client_ip country] if { ( [class match $fromCountry equals Blocked_Countries]) }{ drop } } } And I'm getting this error in /var/log/ltm: TCL error: /parition1/BlockedCoun_XFF <HTTP_REQUEST> - bad IP address format (line 2) invoked from within "whereis $client_ip country" TCL error: /parition1/BlockedCoun_XFF <HTTP_REQUEST> - bad IP address format (line 3) invoked from within "whereis $client_ip country" I saw this article but not sure enough how to implement it in my irule https://support.f5.com/csp/article/K15450552 Could you please advise on this? Thanks
traffic flow between IPI, application security policy, bot detection, DoS protection, irule, and geolocation
I want to know how the traffic flow between IPI, application security policy, bot detection, DoS protection, irule, and Geolocation (using irule for Geolocation). I am using Global IPI (mean IPI does not attached to any VS) and have an irule for Geolocation and only have module ASM and LTM (No APM and AFM). I understand that irule can be arranged by the order. The application security policy, bot detection, DoS protection, irule are attached to VS. Here is what I understand the traffic flow. The traffic hits Global IPI -> reached VS for irules in order (including Geolocation, I always put Geolocation at first place) -> Application security policy -> DoS -> Bot detection. Is this correct? Or will application security policy , Dos, Bot detection happen at the same time? What is the best practice for Geolocation? Using an irule for Geolocation or using Geolocation in application security policy?
platform migration carry over Geolocation data file and ASM signature data file
I am working on platform migration from i5600 to i7600 by backing up UCS file and restoring it back to the i7600. I am wondering if geolocation data file, ASM signature, and bot signature will be updated as well. Recently I restore UCS file but see the Geolocation data file is 2020 which is last year and causing customer complain. When I did the geoip_lookup, it points to /usr/share/GeoIP/v2/F5GeoIP.dat which mean that there is no Geolocation data file under /shared/GeoIP/v2/F5GeoIP.dat and use the default location. What is the best way for me to compare the settings and configuration before and after the platform migration. I thought that UCS backup and restore should cover all the settings but I still missing Geolocation data file.
ASM IP Geo-location exemption
Hi, Is it possible to create exemptions to Geo-location configurations? The use case is fairly obvious and in our case: We're currently blocking all countries outside our own however a request has been raised to allow a single IP in a disallowed country. In newer iterations of ASM you can create an "IP Address Exception" configuration that gives you great flexibility in exempting a given IP from select ASM features. Geo-location seems to be a glaring omission from the available exemption options. Is there another way to create a Geo-location exception in a specific ASM Policy? Thanks, AndrewGeolocation when LDNS in a different geography than user doing the lookup
I am wondering if anyone has clever thoughts on how to address the situation with Topology load-balancing on F5 DNS. If a user is in EMEA but their ISP DNS server is in the US, it will be that DNS server in the US whose IP is analyzed by the geolocation database on the F5 and the GTM will respond with the DNS entry appropriate for US IP addresses. This circumvents our geolocation intent. Is there anything anyone has come up with to do to address this?
GTM/BIG IP DNS - Geolocation for a single URL/single country
Hello, So interesting thing came across my desk. Client wants to have a country be redirected to a datacenter for a single URL while leaving all other geolocation settings alone. I have multiple datacenters with two BIG IP DNS GTMs and this particular URL is load balanced via WideIP with Topology preference on the pool members. Currently traffic has 4 different datacenters it can go to, but due to how the geolocation is set, they feel that the traffic for this particular URL should go to another datacenter for latency reasons. They do not want to change geolocation for anything else, just this one URL dealing with this one country. I have seen some iRules that can be used for LTM and GTM stuff, but more for blocking, not redirecting. Is that something that can be done with the GTM? Guess the way to simplify it to the smallest form, Is there an iRule that can be placed on a WideIP that notices the country of origin and from that dictate what pool member it should send it to?
Excluding google from geolocation with IRULE
Hi, I am interested in an irule that will exclude google IPs from geolocation blocking. Since Google's IP list is dynamic, I need a way to take this list and turn it into a data group on a regular basis. The list is here: https://developers.google.com/search/apis/ipranges/googlebot.json And the ranges are here: https://www.gstatic.com/ipranges/goog.json Any ideas? Anybody done this already? Thanks, Vered
APM geolocation - N/A, others, anonymous proxy available?
Hi ASM's geolocation enforcement feature has (The BIG-IP Application Security Manager Part 7: Geolocation) N/A for internal/reserved IPs Others for external IPs not matching the geoDB Anonymous Proxy Is that available in APM too? Cannot find it in the documentation. Thanks Alex
