The Mechanics of Blocking a Country in Sueetie

I told you about the new Client Access Control module coming in the Sueetie Addon Pack. Now we’ll get into the mechanics of how the system works by using the example of adding a country to block not in the default country list. By doing so in this new How-To Guide in the Sueetie Wiki we’ll see where the IPs come from, how they are imported into Sueetie, how a client is blocked, and how to keep the system running at top efficiency over time.

__________________

Client Blocking Overview

The Client Access Control Module in the Sueetie Addon Pack gives you the ability to block access to your website by country using the IP address of the client. It does this by determining if the client IP address falls within the start-end range of IPs located in that country. If the IP address falls within any of those ranges, the client receives a 404 message. This How-To Guide will use the steps of adding a new country to block not in the Addon Pack default country list to explain how client access control is designed.

Client Access System Elements

The Client Access System has four primary elements: 1) a list of countries which can be selected as blocked, 2) a list of IP lookup addresses in CIDR format which are imported from a geo-location IP service, 3) a list of IP ranges for the countries flagged as blocked, and 4) an HttpModule on page request which determines if the client IP address falls within the range of the blocked IPs.

Add the Country

The primary purpose of this how-to is to explain how the Client Access Control system is designed by walking through the process of creating a new country to block which is not in the Addon Pack’s default country list. Let’s start by adding the country with the Manage Country List Page shown below. The important element to remember when adding a country is to use its correct 2-character DNS Country Code found on many locations on the Net. "CN" for China, as an example. You’ll be using this code later when importing IPs in your IP Lookup Table.

Image

Import the Country’s IP Lookup Records

All we’ve done so far is create a country record which we can associate with IPs we are now going to import from an IP Geo-Location service and which we are going to convert to an IpStart-IpEnd Range list for use by our BlockedIp HttpModule. Before we start the process, let’s look at the end result to know where we’re heading.

Image

The IP Life Cycle

  1. IPs are maintained by a 3rd party free or commercial geo-location service
  2. We download the IPs from the 3rd party in CIDR format and store them as .TXT files in /util/ips
  3. We use the Update Blocked Country IPs function to import the CIDR data in the .TXT files into a SQL Server IP Lookup Table
  4. The IPs in the Lookup Table in CIDR format are converted to IpStart-IpEnd Ranges with the Block Site Access By Country function

Obtaining the IPs from the geo-location IP Service Provider

For the initial release of the Sueetie Addon Pack I went with Ip2Location to obtain CIDR IP lists for countries. They have a free IP-by-Country download offering, but more importantly, after some R&D I determined that Ip2Location’s IPs were as accurate as I’ve seen. You can use any IP Provider, but you want to be confident about the accuracy of the data so you don’t inadvertently block users from, say, Cleveland by mistake.

We want to update our IP data on an ongoing basis because IP assignments are always in a state of change. Again, accuracy is key. I hope you’ll agree that the IP update process in the Client Access Control System is simple to perform.

We’ll start by placing the IP Provider download in our /util/ips directory in the following format:

import_ZZ.txt

where ZZ is the Country Code we entered when adding the country to the Client Access Control System earlier. This is where it’s important to use a matching Country Code in the country’s description as well as the IP import file. Here’s a screenshot of the import files on a Sueetie site.

Image

This is what the IPs in the import files look like in CIDR format.

Image

Importing the CIDR .TXT data into SQL Server

The Update Blocked Country IPs function takes the data in ALL /util/ips/import_ZZ.txt files and imports it file-by-file into SQL Server. Because the Update function also performs a TXT-to-SQL import, it must be performed before you can flag countries to be blocked with the Block Site Access By Country function.

Here’s a screenshot of the Block Site Access By Country page. Use this to define which countries you want to block. Once you define countries to block you never have to use this page again, but will want to use Update Blocked Country IPs periodically to keep your IpStart-IpEnd Range Data current.

Image

Review of the Steps In Adding A Country

  1. Create the Country in the Client Access System
  2. Import the CIDR data from IP Provider to /util/ips/import_ZZ.txt, substituting "ZZ" for the country’s 2-character code
  3. Run Update Blocked Country IPs to import the .TXT data into SQL
  4. Run Block Site Access By Country to flag your newly added country as blocked. This will use the imported .TXT data to create IpStart-IpEnd Range data the BlockedIp HttpModule will use.

Review of the Steps on Keeping Your IP Data Up To Date

You’ll want to update your IP Range data as an ongoing site maintenance procedure. I’ve found updating the data once every 60 days is usually sufficient. Some admins like to do it every 30 days, and there are RSS feeds from IP Providers for those who want to do it every day. Regardless your update frequency, here is the simple update process overview:

  1. Import updated CIDR data from IP Provider to /util/ips/ for the countries you are blocking
  2. Run Update Blocked Country IPs to import the .TXT data into SQL, which will also recreate the IpStart-IpEnd Range data for your blocked countries

Sidebar Info on Blocking

I designed the IP management process to be as efficient as possible. I also designed the IP Import and Update functions so that there was no waiting time for you by sending the processes to a background thread. IP Import and Update may require up to 60 seconds or more to execute depending on the number of countries you are blocking. When they are finished running, they will display the results of the process in the Sueetie Event Log as shown here.

Image

More time is required for processing because of the number of countries listed in your particular flavor of the Client Access Control System. Since IP processing runs on a background thread with no waiting on your part, there is no real reason to reduce processing time. But since all .TXT files located in /util/ips are processed in each IP Update process, the less files in this directory (with the corresponding country removed for thoroughness), the less processing time is required when you update your IP data.

Article written by

A long time developer, I was an early adopter of Linux in the mid-90's for a few years until I entered corporate environments and worked with Microsoft technologies like ASP, then .NET. In 2008 I released Sueetie, an Online Community Platform built in .NET. In late 2012 I returned to my Linux roots and locked in on Java development. Much of my work is available on GitHub.