WordPress Security Pro Tips – ZB Block Tutorial

Article Updated: 11 May 2018

This article is kept for historical reasons. It is no longer updated. If you still use old/original ZAP’s ZB Block version and maintain it by yourself, information contained in here may still prove to be useful.
You may consider using other similar actively maintained projects, such as CIDRAM, which partially covers ZB Block’s main functionality to block cloud services and spammers, but it is a newer script, frequently updated, and also comes in a form of simple WordPress plugin.
Information about future development of ZB Block can be found here: http://www.zb-block.net/zbf/


In this post I will describe the proper way to protect your WordPress website installation with one of a kind anti-spam anti-hacking tool called ZB Block.


ZB Block is a PHP-based (same programming language WordPress is written-in) protection script for websites / forums / blogs / other CMS platforms. It acts as an anti-spam and anti-hacking protection layer. It can protect ANY .php file on your server, as long as you include the call to ZB Block inside it.

If your .php files are part of larger CMS installation (CMS = Content Management System like WordPress, Joomla, Drupal, Invision Power Board, phpBB, MyBB, vBulletin, Vanilla, FluxBB, XenForo etc.), then it is enough to include this call only once in an appropriate file.

Usually, this is index.php, or a file first called inside it in code flow via require_once() function (examples: wp-load.php, global.php, loader.php) but often it might not be, as it will be demonstrated later with WordPress later.

ZB Block is not a simple plugin for WordPress that you install, configure and forget about. ZB Block is wrapper (outer layer) that protects your website even before the attacker hits it! This is one very important advantage* of it against any “security” plugins for WP.

* And a downside, sort of, at the same time. Why? Well, you include it as an external tool into key WordPress file, which will become overwritten with any new WP upgrade, so you need to repeat this procedure every time new version of WordPress comes out.

This task could be automated via cron with, for example PHP script, to check regularly content of wp-load.php file every hour or every 24 hours and automatically insert ZB Block line if not present. This would leave you without a protection for some period after the automatic upgrade of WordPress site.

ZB Block offers following security protections of your WordPress installation:

  • SPAM protection
  • Cross Site Scripting (XSS)
  • MySQL database injection
  • Bad User Agents blocking
  • Referrer SPAM blocking
  • Effectively reducing traffic bandwidth / server cost

ZB Block consists of 2 parts:

  • main application
  • signatures rules

Application and signatures are periodically updated. Signatures come in 2 flavors:

  • default “hardened” version
  • special unblocked “light” version

Default signatures include protections against known servers/machines/botnets/spammers and it is included and used by default. Unblocked version is less strict, it does not contain any banned people/machines/bot hosts that can access your site, however, general protection from the main script still applies and can mark them as hostile.


As shown inside the video, once you install ZB Block on your server, you will automatically get prepared code that you should copy/paste inside wp-load.php file (a good place, for example). However, soon you will realize that absolute paths sometimes suck, especially if you plan to move to a live server or change hosting provider at some point in the future. So, instead of absolute paths you can include it with a relative path this way:


index.php OR wp-load.php ?

After several months, we decided to move call to ZB Block into WordPress’s root index.php file (exactly the same as it was back in wp-load.php – just after the opening <?php line). This move seemed highly logical, because the WordPress / Server file call flow looks like this:

index.php → wp-blog-header.php → wp-load.php

However, there was a problem which was not observed immediately. The above was fine for frontend (ordinary users / visitors). But, what about admin side? It will be left unprotected.

Admin loading sequence is different, and looks like this:

wp-admin/index.php → wp-admin/admin.php → (root) wp-load.php

As you can see above, in order to include ZB Block (and potentially, any other protection script in the stack), now we had to maintain two instead of a single common file. That was not desired side-effect at all.

In the end, we returned to the wp-load.php solution, as a reflection of simplicity.

TIP: There is another method you can use to embed ZB Block: PHP supports auto_prepend_file which will be executed automatically after each server request and before loading main script code (e.g. WordPress or other CMS in general). The advantage of this method is that you are not required to modify any WordPress core files at all!<IfModule mod_php*.c>
php_value auto_prepend_file /relative/path/to/zbblock/zbblock.php
where * is usually PHP version and relative path is something along these lines:

[1] /var/www/mywebsite.com/zbblock/zbblock.php

[2] /home/user_name/public_html/zbblock/zbblock.php

[3] root/mywebsite.com/htdocs/zbblock/zbblock.php

However, there are several conditions that needs to be met in order for the above command to work:

1) This method requires Apache configured to use PHP as a module (mod_php), otherwise you will need a PECL module for htaccess support in FCGI/FastCGI setups.

2) This method requires root access to php.ini configuration file or – at least – enabled support for outside .ini directives overrides (outside ini overrides could be a security threat, though).

3) Auto-Prepend function allows to include one and only one PHP file for execution. In order to execute multiple chained files (for example, if you use more than one protection script), you will have to combine them all within a single .php file, using include_once() or require_once() PHP functions.


include()/include_once() are error-friendly, if the file is not found, PHP will still execute the rest of the things, while require()/require_once() will throw fatal error if the file is not found or inaccessible.


After installation, ZB Block will create a vault directory inside zbblock installation folder which, among other things, contains zbblock.ini config file. Open this file with Notepad++ or similar code editor of your choice and study the documentation that comes with ZB Block (PDF file in your install directory). Please note that not everything inside config file is universal, some sections are specificaly and only designed for certain CMS scripts.

— most important ZB Block parameters —

fault_count = 3 (default 3) – controls how many 403s an attacker is presented, before they are permanently banned from the system and served the “503: Service Temporarily Unavailable” much faster error page instead (saving CPU and bandwidth).

As with the next parameter, the value of 3 is fine for most users, but may hurt you – the administrator in case you forget to whitelist yourself, and even some legit users in my experience. After installation of ZB Block, my advice is to raise fault_count to a higher value if you experience any trouble with lockdown (for example, 10) and watch how it goes, then try to lower it down. In case of false positives, you need to consult log file and pinpoint the signature rule that causes it.

heavy_hit = 3 (default 3) – instantly show HTTP Error 503 if an IP address (from which user is accessing your website) gains a certain “score“. This is the most important configuration parameter in my opinion, and it is placed at the very bottom of the .ini file.

From my personal experience and by recommended default value, value of “3” is enough for ordinary legit users/visitors and known bots, but for heavy use such as administration and alike, this can lock you out. For this reason I advise you to increase heavy_hit limit at least to “5”, to prevent yourself from troubles, but with any new installation and clean websites, I would definitively go with “7” and gradually lower the value when things settle down.

die_503 = 0 (default 0, turned off) – ; How many times an IP address (user) can trigger a 503 error page before ZB Block tells the attacker that the site has moved to (itself, localhost) and terminate the connection. This will additionally save you CPU and bandwidth, but be careful though, this is not user-friendly in case of false positives! This is why it is set to 0 (OFF) by default.

— less important options —

ajax_optout = Yes (default Yes) – this is turned ON by default, but it may break some non-standard AJAX requests that do not properly escape HTTP_POST data. If you experience issues with dynamic ajax requests, set this option to No. You will loose some protection and increase Ajax compatibility.

According to the ZB Block author, Ajax is broken protocol for javascript/PHP communication. However, if you find yourself banned (under default WordPress and ZB Block installation), this might be one of the top reasons. Check your killed_log.txt file and look for lines similar to this:

Violation count: 3 BANNED
Why blocked: POST unescaped ‘ (POST-013)
Query: …
Referer: https://example.com/wp-admin/post.php?post=xxx&action=edit

In this cases you should simply set this option to No. Or consider creating some custom bypass rules/signatures to target specific URL structure (example given later in the article).

log = on (default ON) – log banned users/IP addresses with explanations into killed_log.txt file. This is a 1st goto place in case of troubleshooting.

block_tor = off (default OFF) – block users who are accessing your website via TOR proxy network

block_tor_registration = on (default ON) – block users who are trying to register on your website via TOR proxy network

timer_trap = 0 (phpBB only) – default value is 0, recommended value is 10. This option will slow down page load and new user registration process by X seconds.

hourly_reg = 8 (phpBB only) – limit successive registration atempts for users/bots

— for complete list of ini parameters please consult ZB Block user manual and zbblock.ini file —


By default, during installation procedure ZB Block will perform several things:

  • set entire vault directory and file permissions to 777
  • install .htaccess file inside vault to block any external access to vault directory

.htaccess rule to block external web access to files and directory:

<Files *>
	Order Allow,Deny
	Deny from All
Order Deny,Allow
Deny from All

While, this is a great security practice if you run Apache (or htaccess-compatible) server, however, this will NOT work for nginx and other different servers that do not support htaccess files and rules.

Additionally, that 777 is really a bad thing, despite the fact it is protected by .htaccess file itself.

Our recommendation is to set entire ZB Block directory to 0600 or 0700 (yes, you can allow execution) and remove the .htaccess file (or, you can keep it just in case, it will not cause any harm). This is a much better and higher security practice than original strategy. Keep your file/dir permissions and ownerships in order!

Vault holds some key files for the script operation and you will find every information about banned IPs in there in case of troubleshooting. A brief description of the CSVs and TXT files and their functions is given below:

(list with explanations taken and adapted from here)

bannedips.csv – contains IPs from stopforumspam.com, ZB Block performs live lookups and finds positive IP hits. This local list of IPs relieves load on StopForumSpam by keeping a local cache of known spamming IPs.

signatures.inc – contains all the rules (matching patterns) with which all the incoming traffic is being tested against. If the pattern is recognized, the appropriate error will be triggered and access to the website will be blocked. In beta versions of signatures.inc this file is broken into it’s components: cookies.inc, badhost.inc, badip.inc etc. and they are called (included) from the main file (signatures.inc).

You should be aware of the fact that factory version of the signatures database comes with some services blocked by default, as per ZB Block author’s desire, but you might need to bypass those rules inside customsig.inc file. For example, bots from SEO services such as Majestic, Ahrefs and alike are automatically blocked.

Reason why? Simply, because they are scanning and analyzing your websites and selling trade SEO secrets (such as keywords, backlink profiles etc.) to their premium members.

Also, search engine bots such as Yandex are also blocked, thus you should be really careful and bypass it with custom rules if your traffic depends on it.

customsig.inc – contains all the customized bypass rules that you wish to be either blocked, skipped and allowed. This is very useful, since it will not be overwritten with new updates.

confirmation_attempts.csv / registration_attempts.csv – First number represents hour of the day (local server time) followed by a list of IPs that have loaded registration pages in the last hour slot on your server. These files help with bots that will hammer your website all day due to bad optical character recognition on your CAPTCHAs. A human will come back in an hour. A bot will hopefully crash on the unexpected response.

ipddb.csv – First number represents the day of the current month (local server time) followed by a list of IPs that have been thrown with 403s in the last 24 hours. The list is restored every 24 hours with new day. If you find your IP inside this list – it means you have been locked-out from your own website! :)

ippbdb.csv / ippbdb.txt – contains IPs and Domain Names (ippbdb.txt file only) permanently banned from your site. This list usually contains list of proven and heavy spammers/bots and this ban is permanent. RENEWED: Never. Every 24 hours a delete duplicates process is run on the text file to remove duplicates left by hammer-bots. You should also check this regularly to make sure no google, yahoo, bing bots have been accidentally trapped. If found, remove the known / false positive IP found in the .txt file from the coresponding .csv version. If the reverse DNS lookup fails, .txt version will not contain domain name (makes sense / sounds logical).

killed_log.txt – Log file contains information of all blocked access attempts and explanations why they occured. If you are debugging ZB Block and lockdowns, this is a place to go to. Please note that log can easily get large, so you need to maintain it from time to time.

nolookup.csv – If an IP Address is found to have an unresolvable DNS domain name, it will be added here. REASON: reverse lookups are costly / slow, so why look twice for the same IP RENEWED: Never. Purge from time to time.

ipwldb.csv – Whitelist IPs Database. You should add your IP address into this list, but remember if your IP address changes over time, this list needs to be updated, too. To find out your current IP address simply type into Google Search “my ip” and you will get the correct number. As of current version, this file is not automatically created upon installation and you need to create it manually inside /vault directory. However, you should be aware of the fact that “white list” inside ZB Block is more like a “grey list, in fact. But, more on this later…


First level of defense is HTTP Error 403 which looks like this:

ZB Block Error Page

ZB Block HTTP Error 403 Page

As you can see, the page is pretty informative in case a false positive occurs and visitor will be informed about the reasons why it cannot access.

This page can be also manually accessed for testing purposes by typing in your browser:


The template for ZB Block 403 file is contained inside zbblock.php after a commentary line labeled //Start blocked message (approx. lines 850 ~ 900) and you can modify some html/php part there if you’d like to customize it.

Second level of protection is a plain HTTP Error 503 which contains only text and it is triggered either when too many 403s occur for a particular IP address/user or if malicious action is detected:

Error 503 : Service Temporarily Unavailable

ZB Block HTTP Error 503

ZB Block HTTP Error 503


Don’t panic. When ZB Block is first installed, most users simply use default installation and admins typically visit specific website’s URLs that trigger protection wires, such as cron tasks (manual/auto), ajax requests and so on. First, you need to remove yourself from the blocked list, go to the zbblock/vault subdirectory and remove your IP address from these files:

  • ipddb.csv
  • ippbdb.csv
  • ippbdb.txt

Create a new file called:

  • ipwldb.csv

and enter your IP address into the whitelist and save. This will prevent your IP from being banned next time (in most cases at least*), but keep in mind that your IP may change over time, if your ISP assigns dynamic IPs instead of static. Additionally, you may consider changing some configuration constants explained above.

* Remember when we first mentioned white list file? Well, it turns out that this list is not exactly white list, but more of a grey list in its nature. This means that your IP address will have some immunity from ZB Block, but it will still be checked against some harmful signature rules and it will be banned if you trigger them.

You should definitely inspect the killed_log.txt content, locate your IP address and see the exact reason and matched detection rule code in Why? section. This will essentially tell you the exact reason why the ban happened in the first place (ajax, cron job URL or something else…) and next thing for you would be to decide how will you approach to the solution — either by creating custom signature/bypass rule or changing some .ini config options, if possible.


As with any protection script, there is always a factor of risk with false positives. The script comes with a banned IP addresses database (bannedips.csv file in your zbblock installation folder) and other detection rules (signatures.inc with accompanying files) that is updated periodically and you should try to keep up with it.

However, the main risk factor is preventing a legitimate user to access your website, and this includes even you – the administrator!

In case you suddenly start seeing either of the above 2 error messages, you should immediately suspect that you have tripped one of the security system alarms somehow and that ZB Block has banned your IP!

As a first step in troubleshooting, you can edit wp-load.php file and either remove completely ZB Block lines, or simply comment-it out with // (two consecutive slash characters are for a commentary line in PHP programming language).

Connect via FTP/SFTP and carefully inspect the contents of the vault directory. I strongly suggest that you carefully monitor ZB Block vault directory for few weeks after installation and additionally monitor your traffic logs. If you notice drastic traffic reduction, when you are *sure* those are the legitimate users, than you and your website might be in trouble. Remember, in that case first step is to try and lower the security level inside configuration .ini file. If that does not help, next stage is to inspect the log and check the reported signature rule that was triggered and either modify it, bypass it with custom signature or comment it out.


If your CMS uses external cron job calls like yourwebsite.com?page=cron, this might trigger one of the ZB Block’s rules defined in signatures.inc (in fact, did in my case) and prevent server crons from running (for exact rule code you need to check log file message)! In this case you might consider creating custom signature rules (“bypass”) for your particular script and problem:

Place this line in vault/customsig.inc file around ~ line 9:

// WordPress Cron
if ((inmatch($whyblockout,'(ASN-SFDNS’,”)) && ($ax == 1) && (lmatch($requesturi,’/wp-cron.php?doing_wp_cron=’,”))){$ax -= 1; $whyblockout = $whyblockout . “WordPress Cron Bypass”;}

Again, keep an eye on the log and watch for anything out of order.

ZB BLOCK TEMPLATE ARCHIVE: compatibility.tar.gz

Inside root installation ZB Block folder there is a template archive file compatibility.tar.gz. Once you unpack it, you will discover several custom signature (bypass) rules designed for few most popular CMS systems like WordPress and Invision Power Board (IPB), along some other plugins and tools.

What should you do with it and what is it for? Well, these are pre-made template files containing all the signatures for a given script (WordPress one is for WP, logically). Instead of manually adding one-by-one rule that you either found via Google, on spambotsecurity forums or created by yourself, you just need to copy the content of it and paste/overwrite inside the vault/customsig.inc.

In theory, this should be enough and now your WordPress admin side should function without any issues (such as blocked cron jobs, ajax requests denied, 403s and 503s of other countless causes).

We said “in theory”, since it still got us into trouble, for example, above rules will fix issues with most ajax requests (but not all) and below mentioned issue with editing comments, but not all of them:

Violation count: 3 BANNED
Why blocked: POST RFI (POST-052). POST EX (POST-066). POST EX (POST-073). POST CLOAK (POST-079). POST CLOAK (POST-081)

So, if the above template does not solve your issues and you do not know how to generate specific bypass rule by yourself, you might consider next step: completely bypassing ZB Block for admin side in WordPress (or any other CMS for that matter, patch is universal) described in the next chapter.


We also triggered some signatures while doing ordinary administration work inside WordPress Admin Dashboard, such as cleaning SPAM comments and alike. We got a little annoyed by this, since ZB Block will monitor and trigger 403s even when you explicitly setup your IP Address inside a White List.

Again, to find out your current IP address simply type into Google Search “my ip” and you will get the correct number.

So, we decided — on our own, to do some small modification to the code itself and bypass ZB Block entirely for white listed IPs. It was done in a smart way not to actually modify any of the ZB Block core files (for future compatibility), however it requires a creation of the new sidekick .php file inside ZB Block directory (main dir, not the vault subdir) and instead of calling for zbblock.php inside wp-load.php we will call our “wrapper” file instead.

Here is the modification code:

1) First, create zbwrapper.php empty file inside ZB Block main directory (along with other files in there: zbblock.php, hook.php, vault subdir etc.):

ZB Block White List IP Address Bypass Code

ZB Block White List IP Address Bypass Code

2) Copy/Paste this code into zbwrapper.php file:

// ZB Block White List Bypass
// White List Patch for ZB Block
// Ensures full override of ZB Block white listed IP Addresses
$whiteList = dirname(__FILE__) . '/' . 'vault/ipwldb.csv'; // White List Database
if (file_exists($whiteList)) {
    $whiteListContent = @file_get_contents($whiteList);
    $whiteListContent = str_replace(' ', '', $whiteListContent);
    $whiteListContent = rtrim($whiteListContent, ',');
    $whiteListContentArray = explode(',', $whiteListContent);
    $userAccessIPAddress = $_SERVER['REMOTE_ADDR'];
    if ( !in_array($userAccessIPAddress, $whiteListContentArray) ) {
        // call ZB Block
        require( dirname(__FILE__) . '/' . 'zbblock.php' );

3) Open wp-load.php and replace the original line that calls zbblock.php with the newly created file zbwrapper.php:

// ZB Block @ wp-load.php

or with relative path:

// ZB Block @ wp-load.php

Now ZB Block will be completely bypassed for trusted IPs and your WordPress administration work will be uninterrupted as it was never installed in the first place, but it will keep the protection ON for everyone else!


Since the original author of ZB Block went MIA for some time due lack of free time to run the project, there was a strong demand driven by the community for updating [many] obsolete signature rules, incorrect IP ranges and related issues.

Finally, one member from the community took most of those submitted modifications scattered across the forum and collected them into one “unofficial” collection here:




It is highly recommended that you use latest beta signatures from the main site and update badip.inc and dirty30.inc with the above unofficial versions.

However, keep in mind that this will only update main signature ranges, but there are other obsolete things in other components, as well, which are NOT addressed by the above maintenance update. Additionally, there are many other useful signatures and block ranges available in the forums, that needs to be added manually and per your discretion.

You should carefully inspect logs from time to time and make sure no real users gets blocked.


1) hook.php

In ZB Block’s root dir there is a file hook.php with example line:

<?php require(‘/var/www/my-website/zbblock-directory/zbblock.php’); ?>

This file calls main zbblock.php file defined with absolute path. However, for universal compatibility (e.g. without ZB Block actual installation) it is possible to try with relative path, e.g.:

<?php require(‘zbblock.php’); ?>

since hook.php and zbblock.php resides in the same root dir.

2) Where is $path_to_zbblock variable defined?


Path to ZB Block is defined in /vault/directory.inc (despite the .inc file extension, this file is actually a .php script) with absolute pathname.

Example path:


Remember, if you move your website or ZB Block directory to another location, and you do not wish to repeat installation procedure for whatever reason, you must update $path_to_zbblock inside this file.

Alternatively, you can define a relative path which is universal and does not require future modifications if you move your website to another domain:


If you apply (replace) all absolute with relative paths presented in this comprehensive ZB Block guide, you will essentially make it universal, that is, you will never need to (re)install it again or adjust paths in other websites, hosting, domains and different servers! You can simply copy your entire zbblock directory to another instance (server or website), hook it up the usual way and you are ready to go!

3) Built-In FileScan Module

Inside signatures.inc file you can find special functions which belong to FileScan module. It is designed to scan content of uploaded files and detect/recognize some of the common dangerous PHP tags and commands inside of them (such as opening php tags, dangerous/risky built-in php functions, parsing of .ini files and so on).

// Filescan Module

// code between lines 50 ~ 250

It is probably not a bullet-proof protection out there, but it is certainly a nice add-on, never the less.

If, for whatever reason/troubleshooting you need to disable it, you can do this simply by locating and editing below line:

// To turn off filescan, change one of the 1s to a 0 on the next line.

if ((!empty($_FILES)) && (“1” == “1”)){

and replace above expression “1” == “1” with, for example, this: “0” == “1”


It is recommended to disable ZB Block before updating* your WordPress website, and restore it back afterwards:

  • Simply remove the line from wp-load.php
  • Update your WordPress website
  • Re-open wp-load.php file and restore ZB Block line

Remember: if you just update your WordPress website, wp-load.php will be over-written anyway and your ZB Block will be bypassed!

* If you’ve applied ZB Block WordPress Admin patch (code given above) and white listed your server’s local IP address, you will not need this step. However, remember to restore ZB Block line in case wp-load.php file gets overwritten by an update!



After installation of ZB Block we noticed a huge reduction in Comments SPAM and 75% reduction in Akismet API calls:

AKISMET API Calls ZB Block Relation Chart

AKISMET API Calls ZB Block Relation Chart

Here are some excerpts from our log files and examples how ZB Block acts upon bad requests and prevents some very serious attacks (notice: all IP addresses are censored for privacy):

Remote File Inclusion (RFI) attacks:

#: 320 @: Wed, 06 May 2015 10:45:27 +0200 Running: 0.4.10a3 / 76
Host: *.*.*.* Reverse DNS IP Address listed here
IP: *.*.*.*
Score: X (treat level)
Violation count: 1 INSTA-BANNED
Why blocked: POST unescaped < (POST-008). POST unescaped > (POST-009). POST unescaped ” (POST-012). POST RFI (POST-045). POST RFI (POST-047). POST RFI (POST-048). POST RFI (POST-049). POST RFI (POST-050). Heavy hit. INSTA-BAN. You have been instantly banned due to extremely hazardous behavior!
Referer: (referral website URL)
User Agent: PHP/5.2.36
Reconstructed URL: http:// example.com /xmlrpc.php

Known spammers:

#: 325 @: Wed, 06 May 2015 13:01:10 +0200 Running: 0.4.10a3 / 76
Host: abts-mh-dynamic-*.*.*.*.airtelbroadband.in
IP: *.*.*.*
Score: 1
Violation count: 2
Why blocked: Please use a different ISP, as Airtel India hides spammers via fast-flux DNS (HN-0087)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Reconstructed URL: http:// example.com /favicon.ico

Scrapers/Harvesters/Cloud Services:

#: 125 @: Mon, 04 May 2015 02:02:41 +0200 Running: 0.4.10a3 / 76
Host: *.*.*.*.members.linode.com
IP: *.*.*.*
Score: 3
Violation count: 1 INSTA-BANNED
Why blocked: Possibly hostile scraper/harvester (SPD-0117). Cloud Services. Not an access provider ISP (CLD-0213). Softlayer/ThePlanet/Everyone/Reach. (ASN-SLTP-018). Heavy hit. INSTA-BAN. You have been instantly banned due to extremely hazardous behavior!
Referer: http://api.twitter.com/1/statuses/show/595015630107049984.json
User Agent: InAGist URL Resolver

Fake GoogleBot:

#: 134 @: Mon, 04 May 2015 02:08:42 +0200 Running: 0.4.10a3 / 76
Host: ec2-*.*.*.*.compute-1.amazonaws.com
IP: *.*.*.*
Score: 2
Violation count: 1 INSTA-BANNED
Why blocked: Bad UA. *.*.*.*.compute-1.amazonaws.com is not a valid googlebot domain. See: http://googlewebmastercentral.blogspot.com/2006/09/how-to-verify-googlebot.html (UA-139.0). Amazon Web Services. Not an access provider ISP. Used by hackers, Keyword spamming SEO bots, and other unsavories (CLD-0AMZ). Checked for bypass – Heavy hit. INSTA-BAN. You have been instantly banned due to extremely hazardous behavior!
Referer: http://google.com
User Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

StopForumSpam black list

#: 328 @: Wed, 06 May 2015 15:09:43 +0200 Running: 0.4.10a3 / 76
Host: *.*.*.*
IP: *.*.*.*
Score: 1
Violation count: 1
Why blocked: No registrations, or logins, from hosts listed as hostile on Stop Forum Spam (http://www.stopforumspam.com/removal) (local block).
User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Reconstructed URL: http:// example.com /wp-comments-post.php

Hacking attempts via fckeditor

#: 190 @: Mon, 04 May 2015 10:07:12 +0200 Running: 0.4.10a3 / 76
Host: *.*.*.*
IP: *.*.*.*
Score: 2
Violation count: 1 INSTA-BANNED
Why blocked: Hacking attempt, fckeditor is vulnerable (QU-321). WholeSale Internet, Inc. Not an access provider ISP. (ASN-WHOLESHACK-15). Heavy hit. INSTA-BAN. You have been instantly banned due to extremely hazardous behavior!
User Agent:
Reconstructed URL: http:// example.com /admin/fckeditor/editor/

Phishing a WordPress plugin or theme

#: 208 @: Mon, 04 May 2015 15:23:14 +0200 Running: 0.4.10a3 / 76
Host: *.*.*.*.force9.co.uk
IP: *.*.*.*
Score: 1
Violation count: 1
Why blocked: Phishing a WordPress plugin or theme changelog or readme file is not allowed (QU-320).
User Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
Reconstructed URL: http:// example.com /wp-content/plugins/wpmarketplace/readme.txt

tags: ZB Block, ZBBlock, ZBB, Zaphod, Zap, Security, WordPress