[Elgg 1.8-1.12 & 2.X & 3.X: http:blacklist] v1.8.2

Release Notes

Changelog:

  • Separation of plugin releases for Elgg 1.8 and Elgg 1.9 due to BC-breaking changes in 'route' plugin hook introduced in Elgg 1.9. For the Elgg 1.8 version there's no changes in the code but only this README file is updated.

Feedback appreciated! Does it work for you? Any noticeable reduction in spam? How many blocked/redirected accessed per day/per week? Not only negative feedback would be helpful as I would also like to know if it works perfectly fine.

  • Installed it and disabled IP checks on spam login filter plugin to test it in the wild. Will let you know if I have any data. Thanks for the plugin

  • @Gerard: I don't think it's necessary to completely disable the Spam Filter plugin to test the http:blacklist plugin. The http:blacklist plugin checks the IP already when a visitor opens the register / login / lostpassword pages and blocks the access, if the IP is listed in the http:bl blacklist. The Spam Filter plugin has an option to protect pages in a similar way (you would have to enter the pages to protect in the plugin settings first) but otherwise the Spam Filter check is performed only after a user has entered the account credentials and tries to create the account (there's also an option to re-check on later logins). So, if you do not use the "protect pages" option of the Spam Filter plugin, you would still see the http:blacklist plugin blocking register/login attempts (see its counter on the settings page) while the Spam Filter plugin can continue to filter registrations/logins after that. Even the "protect pages" option of the Spam Filter plugin can be used in parallel to the http:blacklist plugin. It would depend on the plugin priority which plugin would then block the access first (because it's plugin hook callback gets executed first), so the http:blacklist block counter might be slightly lower in this case if the Spam Filter plugin acts first as it would only count the attempts that were missed by the Spam Filter plugin.

  • Maybe I am doing someting wrong then. I had 20 blocked IP from SFS last night (seems I did not disable IP blocking properly or that plugin setting is not working) but the counter on http:blacklist is still 0

    I do have to mention that I block any automated attemps to post in htacess (so also for register and login).  

  • @Gerard: two possible explanations:

    1. these IPs were not in the http:bl blacklist for spamming and therefore not blocked,
    2. either the Spam Filter plugin or your htaccess config prevented the http:blacklist plugin from blocking them.

    I might tend to say the first reason might be true. But maybe a 1 day evaluation is too short to say if the http:bl is of use for Elgg sites or not. Sadly (in this case but luckily in general), I can verify the http:blacklist plugin myself not really extensively apart from making sure that the code works because I don't have a spammer problem myself...

  • It looks like the second option. I have disabled ip checking in spam_login_filter by hardcoding ip whitelist to true.

    Now your blacklist starts working. I have now 15 blocks on the counter. It is always a bit slow in the weekend, but it is working and I am curious if your plugin is doing a better job (less false positives and more true positives).

    Two things, you said it would kick in before spam_login_filter, but that does not seem to be true.

    Second, is a question. If I want to protect other pages with the plugin, I just need to add them to the list in start.php, but is it the pagehandler that is protected or just that single page ? I have made a contact plugin for everyone and that needs protection against spammers. But it uses a pagehander . Pages are constructed using /contact/username

  • Good to hear that the plugin does indeed is capable of blocking some accesses!!! :-D

    What I meant regarding using Spam Login Filter and http:blacklist in parallel: both are using the 'route', 'all' plugin hook to protect access to certain pages. Neither of the two plugins does define a priority for executing the plugin callback currently. Therefore, the order of execution should only depend on the plugin order. It's not that the http:blacklist check will be executed first in any case but the order should change depending on the current plugin order (I will do some tests here though).

    The check for the current uri matching one of the uris included in the protected uris array works for both the pagehandler alone plus the complete uri. So, including "contact" in the protected uris array should work for protecting all contact form pages for all users. If you would include for example "contact/specific_username" in the protected uris array, only the contact form for this user would be protected. Likewise, you could add "blog" to protect access to any blog-related pages/ subpages while adding "blog/add" would only protect access to the blog add form.

  • Thanks, I think it is a valueable plugin. Recommended.

    For future development it might be good to built in admin validation instead of blocking users, that would make it very distinctive and admins could lower the threat score.

  • Thanks for the feedback.

    Let's see what new features I might be able to include in future versions. I've followed the discussion between you and ura in the feedback thread at http://community.elgg.org/discussion/view/1663716/any-feedback-positive-or-negative-regarding-my-anti-spam-ip-blocker-plugin. I'll think about if there's a good way to implement an "admin validation" (at least as alternative to the strict blocking). Maybe allowing for configuring the protected pages via the plugin settings page would be another useful feature.

  • I promised some stats. Number of accesses blocked or redirected: 528 in 27 days.

    But still some spammers are getting through and I am catching them (hopefully all) with my spam_checker plugin (around 5 a day) Spam_login_filter is also catching some before your plugin.

    I do have a feature request. "Delete user and put on http:blacklist" avoiding some hard headed spammers to re register. Alternative would be do that in my plugin, but that would introduce a third blocking list and that does n't seem right.

    Anyway, this plugin is here to stay for me. Nice Job. Thanks !

     

  • @Gerard: thanks for the feedback. Nice to know that it's working.

    Hasn't the Spam Login filter plugin already a local blacklist (= site specific)? I thought this would be the case. Then it might not make sense to add a separate local blacklist to the http:blacklist plugin (especially since it sadly not possible to report back IPs to the http:bl database as they rely only on data that comes from their honeypots). I will keep your suggestion in mind for sure. I might have to evaluate all the different anti-spam plugins (also including Matt's Truster User Spam Report plugin) to see how they might work together best and which functionality is still missing and to which plugin it might be added best.


     

Stats

  • Category: Spam
  • License: GNU General Public License (GPL) version 2
  • Updated: 2019-4-7
  • Downloads: 2067
  • Recommendations: 7

Other Projects

View iionly's plugins