Have you ever had one of those random moments where you have a light bulb go off and things just click? A little over six months ago, my wife and I were on vacation and I hadn’t touched a computer in days. I was in the shower, and my mind drifted onto IP blacklists and then it just clicked – why isn’t there some sort of IP blacklist functionality for WordPress? Over the course of the next week, I wrote the first iteration of tinyShield just as a proof of concept.

After my first iteration was in working order, I did a little digging into all of the security plugins of WordPress and only found a couple of plugins that actually offered blacklisting capability, and was somewhat shocked to find that next to none offered the ability in real time.

While researching these other security plugins, I noticed that most, if not all, tried to hit a number of different aspects of security. While security should certainly be multi-tiered, trying to include all aspects into one plugin can leave you with a very bloated plugin. So with that in mind, it is a development goal and mission of tinyShield to be simple, effective and efficient. The tag line, “Simple. Focused. Security.” was born.


The idea is that tinyShield will do just one thing, and it will be the absolute best at that one thing. And that one thing is blacklists. So why blacklists? The idea behind a blacklist is that each entry on said blacklist is a known producer of malicious traffic. For example, you have a compromised web server that is spewing out brute force login attacks to other websites and by chance it hits a honey pot. (A honey pot is a server that waits for attacks so that it can be recorded – a lot of blacklists are sourced this way.) Now that we have recorded this server’s IP address on a blacklist, we can use that to prevent the compromised server from connecting to our site. This functionality is very common in the technology world for everything from screening spam callers to being used in firewalls and email servers.

How does it work?

tinyShield itself works in two pieces. The plugin, which handles submitting the visitors requests over to the tinyShield servers for verification, is the piece that sits on your website. The other piece, our tinyShield servers, takes that information and compares it to our blacklist and then returns the decision to the site to allow the visitor or not. All of this is in real-time.

Each visitor is categorized into one of three different categories. Blacklisted, Whitelisted, and Permanent Whitelisted. Obviously a blacklisted visitor is one that was found on our blacklist and we’ve identified that as malicious traffic. Once that determination is made, we add that to a local cached blacklist on your site for the next 24 hours in case they try to connect again.

If a visitor is not found on a blacklist, we assume that it is legitimate traffic and allow the visitor to connect to the site, and add their IP address to a locally cached whitelist for 1 hour. The reasoning behind one hour is simple. If traffic that is whitelisted was in fact malicious and tinyShield identifies it as such, it doesn’t make sense to wait 24 hours to check that traffic again.

Finally, you have the option to permanently whitelist visitors by IPv4 address. Upon activation, your own IP address is added to the permanent whitelist so that you don’t get locked out of your site accidentally.

Infomercial Time!

But wait, there’s more! The future is crowd-sourced. While we do check well known, mature blacklists for some of our sources, one of the goals with tinyShield is to crowd-source security on the WordPress platform. Each installation, by default, will report back certain indicators that a site is under attack either by brute force attempts or other metrics. This information is then analyzed and, if determined to be malicious, added to our blacklist for all tinyShield sites. This is optional but we highly encourage it as it will help to identify and prevent future attacks on other sites. Think “herd immunity”. The cloud sourced data is only available to our premium subscribers.

Bots and Crawlers?

What about legitimate bots and crawlers? All traffic that we identify as coming from legitimate bots and web crawlers are considered non-malicious traffic, and allowed. Google, Facebook, web monitors, etc are all included in this.



Leave a Reply