see #1239762: make greylisting level configurable

I specifically would like to be able to switch blacklisting off.

Comments

bryrock’s picture

I'm thinking this could be accomplished by making blacklisting configurable in a similar manner as was done for greylisting, and allowing the numeric range for the threat level to be set to 100 for blacklisting, as that is the upper limit of threat levels. Thus, no blacklisting would occur.

Make sense?

killes@www.drop.org’s picture

Yes, that makes sense, but are you sure that 100 is actually the maximum? I was thinking the range was 0-255.

bryrock’s picture

You are correct. Top range is 255. Project Honeypot advises that scores over 200 are extremely unlikely, and, personally, I don't think I've ever seen anything in logs over 100.

Dane Powell’s picture

sub... a lot of spammers are getting greylisted and whitelisting themselves. Would like to be able to easily adjust the blacklist level to block them. Also, is there a way to see in the logs what a grey/blacklisted IP scored?

bryrock’s picture

a lot of spammers are getting greylisted and whitelisting themselves.

This seems somewhat unlikely to me. How did you reach the conclusion that actual spammers are whitelisting themselves? Keep in mind that there are some rogue computers out there that are owned by innocent people. Also, there are some who, through no fault of their own, have inherited IP addresses that have tarnished reputations. The whitelisting capability is there for those actual humans. The typical IPs found in Project Honeypot are often spiders, web-bots, etc., that are too dumb to whitelist themselves.

Also, is there a way to see in the logs what a grey/blacklisted IP scored?

Yes, there is. The log shows the return code from Project Honeypot, and the threat level is in the third set of numbers (from the left).

Here's an example, just caught today: 110.159.138.151 was greylisted (127.1.14.5)
The threat level is "14"

The same log entry will have a link in it to Project Honeypot. The link says "IP data" and, for the one above, goes to http://www.projecthoneypot.org/search_ip.php?ip=110.159.138.151 where you can verify the threat level.

bryrock’s picture

An addendum to the above: There are also spammer out there that are brand new, and are not yet present in Project Honeypot, thus no known threat level. They will get through, but they might also find any honeypots on your site, and effectively turn themselves in.

Dane Powell’s picture

Sorry, I guess you are right- the IPs don't seem to go on to do anything malicious. I think I was just interpreting the data incorrectly.

bryrock’s picture

Assigned: Unassigned » bryrock
Status: Active » Needs review

This has just been committed to 6.x-2.x-dev (but wait for the updated roll-out).

After review I will also add the feature to 7x version, and update release candidates for both 6 & 7.

Michael-IDA’s picture

Wanted something similar as well. Here's the relevent bits from my modified .module file. The immediately blacklisting comment spammers is the most useful change. Changing the blacklist threashold, not so much.

I'd have used a .diff, but there's too much other junk I'm playing with in the file atm.


/**
 * Visitor types.
 */
define('HTTPBL_VISITOR_SEARCH_ENGINE',   0); // Defined in the fourth octet
define('HTTPBL_VISITOR_SUSPICIOUS',      1); // http://www.projecthoneypot.org/httpbl_api.php
define('HTTPBL_VISITOR_HARVESTER',       2);
define('HTTPBL_VISITOR_UNDEFINED',       3);
define('HTTPBL_VISITOR_COMMENT_SPAMMER', 4);

---------------- (In function httpbl_check() {)
{replace the blacklist IF}

      // Blacklist?
      if ( ($response['threat'] > variable_get('httpbl_black_threshold', HTTPBL_THRESHOLD_BLACK) && $response['type']) || ( ( $response['type'] >= HTTPBL_VISITOR_COMMENT_SPAMMER ) && variable_get('httpbl_blacklist_comment_spammer', FALSE) ) ) {


---------------- (In function httpbl_admin_settings() {)

{after httpbl_grey_threshold}
{anything over 100 is near pointless, but add up to 255 as desired.}

  $blacklist_threshold_options = drupal_map_assoc(array(5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 75, 100));
  $form['advanced']['httpbl_black_threshold'] = array(
    '#type' => 'select',
    '#title' => t('Blacklisting Threshhold'),
    '#default_value' => variable_get('httpbl_black_threshold', HTTPBL_THRESHOLD_BLACK),
    '#options' => $blacklist_threshold_options,
    '#description' => t('Threshold at which a user is blacklisted.  Use this to fine-tune the Honeypot threat-levels that you are willing to permit for access to your site.'),
  );

  $form['advanced']['httpbl_blacklist_comment_spammer'] = array(
    '#type' => 'checkbox',
    '#title' => t('Blacklist Comment Spammers'),
    '#default_value' => variable_get('httpbl_blacklist_comment_spammer', FALSE),
    '#description' => t('Ignore all threat levels and immediately blacklist comment spammers.  An <a href="http://www.projecthoneypot.org/httpbl_api.php">explanation of type of visitors</a> (See the fourth octet).'),
  );

Bryan,

Shoot me an email if you're still around. We'll consider taking over this module as we have sites from D5-D7 that will need it (Mollon being the site killer it is), and there are several items that still need to be added to http:BL (permissions?!).

Best,
Sam

bryrock’s picture

Ok, unless I'm mistaken, you're actually using this request for an entirely different feature request. Normally I'd ask you to submit it as a separate request, but to be honest, I'm not really entertaining new features at this time, particularly for D6. I tend to agree with you about the need for blacklist threshold control, but I did it as a request from d.o.

bryrock’s picture

Status: Needs review » Closed (fixed)

As this feature has been sitting in the queue for a year now, as "needs review", I'm going to go ahead and roll it into a new rc.