Geoblocking Best Practices: When Geoblocking Is (and Isn't) Useful

Like other security researchers, I employ honeypot servers. One looks to the world like a WordPress server, and the and the other site sells items that no one would ever buy. The Wordpress server logs all IP addresses and their requests, and has no users. The sales site has no users, but you can click to buy something, enabling me to see who tries to log on and/or click. In this article I explore geoblocking best practices and when geoblocking--the practice of blocking internet access based on location--doesn't make sense or can't be used.

Recently, the WordPress site was slaughtered with fake admin logon attempts. From vastly different directions--including Laos, Vietnam, China, Azerbaijan, Brazil and Ukraine--bots attacked the site under question using the name of the site, as in $sitename. A few came from the European Union; none came from the United States or Canada.

In any case, geoblocking could have been used to cut these attempts off by virtually flipping a switch. However, geoblocking is not infallible, and it's not feasible for many situations. Finding other methods of fighting advanced persistent threats/APTs may be more effective.

The honeypot attacks carried a persistent threat--essentially, a dictionary attack of password attempts. The different IP address bots would attempt a dictionary attack on the site, then timeout. A dictionary attack using that contrived user name taken from the site name ensued from each attacker. So far, so normal. It’s likely that most WordPress sites will be attacked in this way. This is why it's so important to follow one of the most basic and important security rules: Create an unguessable administrator user name, and never use that name to post where it could be revealed (for example, as an author of a public post on a site).

The sales site was different. The purchasing sequence employs a click, which is trapped to move to another page whose buying buttons are fakes. Nothing is for sale; it’s there to catch the http_referrer to see if they match the entity that loaded the page. When the two don’t match, I know that something’s grabbed the sales page and is hitting it directly.

A lookup service finds the original address, maps it to a country about 99 percent of the time, logs this info, and the site carries on. There is a complaint address from the site; it’s never been used. Most buy page hacking/pounding comes from the same IP address as loaded the initial sales page, but not always, which means that the sales page sometimes gets special hacking “treatment."

The sales page gets pounded chiefly from IP addresses that resolve to small Southeast Asian countries. A dictionary attack using the site name + variations of admin ensues. Although a simple attack, against sloppy sites, it could be effective. I haven’t let them in to see what they do from there. Perhaps one day when I’ve backed up the site and can shadow their sessions I will.

For WordPress, the premium Wordfence is an example of an app that traps this problem with optional geofencing choices, although selective IP addresses and ranges can also be trapped in WordPress and even (with a little work) inside the cPanel app that controls these two sites. Wordfence offers specific IP or CIDR block rejection; Wordpress allows the same via manual entry, and the cPanel for the ISP host permits address/block rejection, effectively geofencing-by-ISP-source.

Blocking Geoblocking

Shutting out customers from suspect areas isn’t the best idea for some organizations. Others can't do it by law. For example, the GDPR forbids geofencing inside the 26-member European Union. The rationale is that geoblocking prevents member citizens from purchasing goods outside of their countries at fair prices.

Alternatives with their own malevolent IP blocks--like Akamai, CloudFront, and sites using Cisco Talos data and other access control blacklists--often use amalgamated intelligence sources. The amount of available test intelligence on their response is tough to find, and given waves of campaigns that seem to evolve from the ether, are undoubtedly hard to track.

When a legitimate IP address host is rejected, the host often can turn off its ACL rejection status, especially for email rejections, but geofencing pertains more to web access than email access.

Geoblocking is handy, where it can be used, but it’s a fairly drastic measure, and not totally without problems. VPNs, Tor exit nodes, proxy farms and other clever methods can jump international boundaries--and, thus, geofencing, with ease. Many of these addresses are known, however, making hostile access control intelligence very handy, and more surgical, than the blissful simplicity of geoblocking.