Building the 3G Blacklist, Part 5: Improving Site Security by Selectively Blocking Individual IPs

In this continuing five-article series, I share insights and discoveries concerning website security and protecting against malicious attacks. Wrapping up the series with this article, I provide the final key to our comprehensive blacklist strategy: selectively blocking individual IPs. Previous articles also focus on key blacklist strategies designed to protect your site transparently, effectively, and efficiently. In the next article, these five articles will culminate in the release of the next generation 3G Blacklist.

Improving Site Security by Selectively Blocking Individual IPs

The final component of the 3G Blacklist establishes a vehicle through which individual IPs may be blocked. As previously discussed, the goal of the 3G Blacklist involves moving away from extensive lists of blacklisted user agents, IP addresses, and other identifying attributes. Nonetheless, a comprehensive security strategy benefits from the ability to quickly and easily neutralize threats by directly blocking individual IP addresses.

In my experience, an effective IP blacklist should be kept as current as possible. Unfortunately, once lists grow to over 100 entries, they become quite unmanageable. Periodic verification of blocked IPs becomes increasingly difficult as lists grow in size. Uncultivated blacklists that continue to grow in size will eventually do more harm than good. Beyond the burden placed on server resources, constantly changing IP ownership inevitably results in unintentional blocking of legitimate traffic.

Just as with individual blocking of user agents, blocking individual (or ranges of) IP addresses provides a secondary layer of protection against direct attacks, corrupt networks, and other case-specific situations. This level of granular control enables defensive fine-tuning for targeting and blocking specific machines. Known repeat offenders should remain permanently blacklisted, whereas short-term offenders should be blocked temporarily. Examples of known repeat offenders typically include:

• Known attackers who have directly targeted your site
• Ranges of addresses belonging to a known corrupt network
• Agencies and businesses that need to be blocked indefinitely
• Anyone else that you decide does not deserve access to your site

Of course, IP addresses involved with any of the preceding situations should remain permanently blacklisted. Conversely, examples of one-shot, short-term offenders typically include:

• Malicious behavior observed only on a single occasion
• Random collections of IPs associated with decentralized attacks
• Temporary blocking of any/all traffic due to site maintenance, etc.
• Temporary blocking of specific (ranges of) IPs for testing purposes

Addresses involved with any of the preceding situations should be blocked only temporarily. A good method for keeping track of temporary versus permanent blacklist entries involves using comments to date and segregate. For example, consider the following portion of a hypothetical htaccess log file:

# PERMANENT BLACKLIST
<Limit GET POST PUT>
 order allow,deny
 allow from all
 deny from 123.123.        "# block bad network 2005-03-15 "
 deny from 456.456.456.    "# block competition 2006-04-17 "
 deny from 789.789.789.789 "# block bad cracker 2007-05-19 "
</Limit>

# TEMPORARY BLACKLIST
<Limit GET POST PUT>
 order allow,deny
 allow from all
 deny from 75.126.85.215 "# block zombie machine 2008-01-21 "
 deny from 84.122.143.99 "# block zombie machine 2008-03-23 "
 deny from 87.248.163.54 "# block zombie machine 2008-04-25 "
</Limit>

This method of organizing your individual IP blacklist facilitates cultivation and periodic maintenance. Segregate your entries into two sections: permanent and temporary. Then, on each line, include a comment specifying the associated date and identity. As new IPs are added to the list, make a point of removing temporary entries after a specified period of time.

For example, I generally clean up my temporary blacklist items at least once per year, more if needed. Overall, I have found this strategy to work very well. I have a solid template/system in place for easy blacklisting when necessary. Lifetime villains are locked out forever, and “drive-by” scumbags are locked out for a year or so, definitely long enough to send a clear message. Of course, the best part of this strategy is that my blacklist is highly flexible and easy to manage, making it concise, specific, and relevant.

Individual IP Blocking with the 3G Blacklist

Given the previous reasoning, the upcoming 3G Blacklist will include a template for blocking individual IP addresses. By default, it will include the current list of Blacklist Candidates to serve as pattern for additional entries.

# BLACKLIST CANDIDATES
<Limit GET POST PUT>
 order allow,deny
 allow from all
 deny from 75.126.85.215  "# blacklist candidate 2008-01-02 = block admin-ajax.php attacks "
 deny from 128.111.48.138 "# blacklist candidate 2008-02-10 = block cryptic character strings "
 deny from 87.248.163.54  "# blacklist candidate 2008-03-09 = block administrative attacks "
 deny from 84.122.143.99  "# blacklist candidate 2008-04-27 = block clam store loser "
</Limit>

For more information on any of these entries, check out the blacklist-candidate round-up. At the time of this writing, there are four seven such candidates to read about. Each exposé is a delightful romp ;)

Wrap Up..

I have thought quite a bit about whether or not to include some monster list of nasty IP addresses to the upcoming 3G blacklist. There are many excellent IP blacklists out there, ranging in scope from blocking several legions of the worst scumbags, to blocking nearly every address on the face of the planet. Deciding which IPs to blacklist is such a personal decision that I finally decided to present a minimum number of entries as an example, and then leave it up to the users to populate their own lists. Unless someone convinces me otherwise, I think this strategy works well for everyone.

Well, that’s it for this Building the 3G Blacklist series! I appreciate everyone who shared in the discussion with comments and emails, and look forward to finally releasing the much-anticipated 3G Blacklist. Yay!

Next..

Coming up next: Perishable Press Presents the 3G Blacklist! In the next article, I bring together the ideas, techniques, and strategies presented in the previous four articles to create an extremely effective, efficient, and precise blacklist method for improving site security. Don’t miss it!

About the Author

Jeff Starr = Fullstack Developer. Book Author. Teacher. Human Being.