By nickbits on

Hi All,

I have just come across ZB Block, see http://www.spambotsecurity.com/zbblock.php. It has various claims, all of which I will take with a pinch of salt until I test it. I will try it out on a test machine. Anyway getting to the point, they claim on the website it is compatible with Drupal. What surprised me is, if this is true and the script/site legit, why has it not been mentioned on Drupal.org before? So has it been mentioned and I have missed it? And does anyone have any experience of this script, good or bad?

Nick

Comments

asb’s picture

asb commented

Drupal has a number of mechanisms for Spam prevention, but as far as I can tell none of them can handle the kind of attacks we get from today's Internet. "ZB Block" (short for "Zaphod B. Blocker") is a different kind of beast as it only targets today's attacks. I does not even bother to implement weak mechanisms like Captchas. If you are aware of those differences just go ahead and try it out.

The site spambotsecurity.com is legit, and actually, more innovative CMS like e107 already do support "ZB Block" out of the box: http://wiki.e107.org/index.php?title=HOWTO:Include_Security_Scripts

If you still don't trust their claims, you could read the forum (http://www.spambotsecurity.com/forum/) or join the IRC chat. I haven't found any indication that this script does not do what it claims to do.

According to the documentation, it should be easy to integrate "ZB Block" into Drupal ("Add ZB Hook to index.php in the root directory or the directory Drupal is run from"). As far as I know it's not that easy as you have to run a setup script from within Drupal's root directory, and that's a path that is being captured by Drupal; thus, running ./zbblock/setup.php fails with a 404 (that's where I stopped investigating "ZB Block").

Please share your experiences!

zaphodb777’s picture

zaphodb777 commented

The reason that the install failed, was probably due to the "friendly" URL modifications in your .htaccess . Temporary neutralizing of that, should allow you to execute scripts in other directories.

Also, it is recommended that you place ZB Block in your /pubhtml/ root, rather than in /pubhtml/drupal/ .

Honestly, I do not run Drupal personally, but I am a little surprised to see that it blocks out execution of other .php directly called by filename.

One final note, ZB Block is not a "mod", it is a security "wrapper" that is designed to execute before an attack can have access to your SQL system, and thus, the best place to hook it, would be at the beginning of the file that contains your SQL username and password (since all other operations must pass through there too, in a usual script). Also, due to this, it cannot be loaded as a mod, as mod access is made after interaction with SQL (once again, in a usual script).

Thanks for your consideration,
Zap :)

asb’s picture

asb commented

@zaphodb777: Thanks for dropping by ;)

Judging from the time I'm wasting every day with adding records to robots.txt, adding rewrites for bad bots to .htaccess, tailing through access.log for attack patterns, and manually block IP addresses, a tool like ZB Block would be a godsend. However, it's not so easy to hook something into Drupal without breaking something. Think of Drupal as a framework to build a web application, not as something ready-to use like Wordpress. Drupal sites might significantly differ, even if they run the same core version and similar contributed modules.

So if someone succeeded with to integrate ZB Block into his/her Drupal setup, I'd be really glad to read his/her experiences!

Also it might worth mentioning that there seem to be many possible server configurations to consider. We, for example, have never used a structure like ./pubhtml/drupal/ (probably derived from Apache's mod_userdir which uses paths like ~/public_html, /usr/web/*, or /home/*/www. Our sites reside in /var/www and do not share a common "root" dir, so we'd probably have to symlink a shared installation of ZB Block into the web application root dirs (where Drupal resides). Again, I don't know if this could even work as I don't understand what ZB Block is supposed to write into it's installation directory. If it does not write anything into it's installation dir, we could makt it read-only and skip the setup script (which appears to only generate a path to ZB Block's location).

DanZ’s picture

DanZ commented

Yes, the default Drupal install is intended to take over your entire Web site. If you're using Drupal, you're not really supposed to add non-Drupal components to your site. That said, though....

It is possible to allow access to non-Drupal components. You need to add something to your .htaccess file ahead of the Drupal rewrite rules that allows direct access to the ZB Block setup directory and scripts.

Also, the Drupal Way is to never modify a standard (distributed) PHP file on a production site. Instead, if you want to modify behavior, you add a module (possibly custom). The module registers with one of the assorted Drupal (or module) hooks. When the hook is invoked, the module code is executed.

Drupal has assorted hooks during the various page load stages. Some of them are quite early, and would be appropriate for a tool intended to shut down access. That said, it wouldn't be as lightweight as inserting a call right into the index.php file.

The Drupal Way would prefer a Drupal module that handles all the configuration in Drupal, without using an external page. It would prefer ZB Block to be in a loadable library. The module implement a hook. The hook implementation would load the ZB Block library and call a function in it to determine if the requester is bad. I could also see the hook making a library call that could possibly abort with a 403 error.

One thing.... The ZB Block Web site never really explains what the script checks for and how it does its checking. That would be useful to know....

--
www.ztwistbooks.com. Math books that are actually fun.

asb’s picture

asb commented

@DanZ: According to ZB Block's developer, "[…] ZB Block is not a "mod", it is […] designed to execute before an attack can have access to your SQL system". Considering what ZB Block tries to accomplish, this sound very reasonable. I don't think that it would be possible to hook a Drupal module into Drupal that is "executed before an attack can have access to your SQL system".

IMHO, ZB Block should hook into the operating system, like fail2ban does. Fail2ban includes several filters like apache-badbots.conf that are implemented as pluggable "jails", it works totally independent from any database and directly interacts with iptables. Another good place for ZB Block would be an Apache module as this would also run a level below the web application (Drupal) and not involve any database.

However, it shouldn't be necessary to fumble with Drupal core's files to get ZB Block integrated; this not only opposes Drupal standards, but might also cause trouble with security mechanisms like Tripwire (monitoring on specific file changes) and anything that works with checksums to detect tampered files on the system.

DanZ’s picture

DanZ commented

ZB Block is not a "mod"

Correct, and it is therefore not the Drupal Way of doing things, which is to have functionality hooked in via modules.

ZB Block should hook into the operating system ... Another good place for ZB Block would be an Apache module

That's a good place for that kind of functionality. However, then it wouldn't be much use to folks on hosted servers who don't maintain the OS or Apache.

However, it shouldn't be necessary to fumble with Drupal core's files to get ZB Block integrated

Due to the nature of ZB Block, it's absolutely necessary to edit the index.php core file (once) to get ZB Block to work with Drupal. You have to re-do that edit every time you update Drupal Core. That's a hassle, and not the Drupal way...but the payoff might well be worth it for you.

--
www.ztwistbooks.com. Math books that are actually fun.

HS’s picture

HS commented

Has anyone got ZB Block working and protecting a Drupal site?

kgordon’s picture

kgordon commented

Although I was aware of the spambots hitting my website for about a year, I assumed that Drupal was successful in preventing them from damaging my website. That all changed when I received am email from Google advising me that the email account linked to my website had some undesirable activity occurring. After a quick visit to the account I realised that hundreds of spambots were registering on my website. My website was overloaded with activity. Every action took more than 20 minutes to process. Finally I was able to place the site in maintenance mode. I then selected 160 spambots who had 200 to 2000 hits per week and checked their record on the database at http://stopforumspam.com. If the record was bad I added their ip address to Drupals ip address blocking list. I next deleted all spambots that had successfully authenticated as users (a large number deleted one by one). This cleaned out some content but other content needed individual treatment.

I had always kept Drupal cms core plus modules up-to-date. However at one stage with ubuntu I upgraded using do-release-upgrade which moved ubuntu from 10.04 to 11.10 giving my os a very short time to its end of life. Ubuntu updates were impossible using apt-get (no files available). Security updates had ceased.

Next I installed module Honeypot and reviewed my configuration of Mollom. I then sent an email to all proper users advising that I would delete their account unless they acknowledged the email. I also reviewed all Drupal permissions and all other file and folder permissions. Once this was complete I removed "Maintenance Mode". The spambots continued to hit my website at the same pace but failed to gain entry.

Using the "Backup and Migrate" module I made a backup of mysql and the Drupal system. I then installed ubuntu 14.04, mysql 5.5.37, php 5.5.9 and apache 2.4.7 and recovered the Drupal system.

Now I am ready to install ZB Block from http://www.spambotsecurity.com as an addition to my Drupal system.

Apache Root: (/var/www): Html front page with two buttons to the Drupal system: main files:
index.html, robots.txt, Bing.xml, google.html, .htaccess
Drupal Root: (/var/www/drupal): Standard Drupal system: main files:
authorize.php, cron.php, .htaccess, index.php, install.php, robots.txt, update.php, web.config, xmlrpc.php
Access points:
http://0.0.0.0/drupal/?q=user
http://0.0.0.0/drupal/?q=user/password
http://0.0.0.0/drupal/?q=user/register
PLAN FOR INSTALLATION OF ZB BLOCK:
In Drupal Configuration: Search and metadata > Clean URLs is off in my site
Download the manual: http://www.spambotsecurity.com/files/ZB_Block_Manual.pdf
#cd /usr/local/src
#w3m http://www.spambotsecurity.com/files/zbblock_0_4_10a3.tar.gz
#tar -xvzf zbblock_0_4_10a3.tar.gz
#mkdir -pv /var/www/zbblock
#mv zbblock_0_4_10a3/* /var/www/zbblock
#cd /var/www/zbblock
#chown -R www-data:www-data .
#chmod -R 755 .
#chmod 644 .
#cd /var/www
#chmod 755 zbblock
In Windows 7 IE: http://0.0.0.0/zbblock/setup.php
Choose method 7 for linux.
Done! (if script completed ok)
If you have difficulty accessing setup.php try http://www.thesitewizard.com/apache/access-non-drupal-folders.shtml
#nano /var/www/drupal/index.php
Edit /var/www/drupal/index.php first row:

<?php require('/var/www/zbblock/zbblock.php'); ?><?php

ALL on one line - see Manual
#cd /var/www/drupal/sites/default
#chmod a+w settings.php
#nano settings.php
Edit first row:

<?php require('/var/www/zbblock/zbblock.php'); ?><?php

ALL on one line - see Manual
#chmod 440 settings.php
I have set Drupal permissions so that only authenticated users may enter content or enter comments.
To be authenticated a user must log on. To logon, register or request a new password a visitor must enter Drupal via index.php
Set password in zbblock.ini (10 characters: upper and lower case, plus numbers).
#nano /var/www/zbblock/vault/zbblock.ini (see manual)
In Windows 7 IE: http://www.xxxbot.org/zbblock/zbblock.php?wlpw=the password in zbblock.ini without the quotes
Reply: "IP added to whitelist database"
Update to the latest beta signatures: download a fresh signatures.inc from: http://www.spambotsecurity.com/files/beta-signatures.zip
Unzip the file to /var/www/zbblock Move signatures.inc to the vault folder.
You should also subscribe to the 2 update subforums, viewforum.php?f=5 and viewforum.php?f=6 to be notified of updates as soon as they are out via email. http://www.spambotsecurity.com/forum/viewforum.php?f=5 http://www.spambotsecurity.com/forum/viewforum.php?f=6
Test your website no more than three times: http://www.xxxbot.org/drupal/?test=xtestx
I also had a problem with apache 2.4.7 exposing many folders to the public. This was resolved as follows:
Installed ubuntu 14.04, mysql 5.5.37, php 5.5.9 and apache 2.4.7
#nano /etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>
 ...
 DocumentRoot /var/www
 <Directory /var/www/>
 Options Indexes FollowSymLinks
 AllowOverride All
 Require all granted
 </Directory>
 ...
</VirtualHost>

#service apache2 reload
#nano /var/www/zbblock/.htaccess

<Directory /var/www/zbblock/vault/>
<Files *>
 Require all denied
</Files>
Require all denied
</Directory>

<Directory /var/www/zbblock/install/>
<Files *>
 Require all denied
</Files>
Require all denied
</Directory>

<Directory /var/www/zbblock/beta-signatures/>
<Files *>
 Require all denied
</Files>
Require all denied
</Directory>

To see the effect of zb block examine /var/www/zbblock/vault/killed_log.txt (6 entries a minute is not unusual) here the reason for blocking is defined!
All questions to http://www.spambotsecurity.com/forum "Drupal Help" as this is a Non-Drupal project.

The above is described solely for a Apache Root of /var/www and a Drupal Root of /var/www/drupal: No change was made to drupal .htaccess files: ZB Block was installed in /var/www/zbblock. Drupal 7 core updates should be completed in the normal way. This is NOT a Drupal module.

I hope that in the near future drupal will contain a similar security system in Drupal Core.