This module has 2 dependencies, flood_unblock and flood_control. Rather than re-invent the wheel, I use these modules instead. This module protects against Bruteforce logins and bans any IP that tries to login to your website X times and reports those IP's back to a crowdsource server to help everyone protect themselves from that IP.

NEW: Data! has a great database that has data we would be interested in including. So along with our own collection methods, we're adding IP's from their DB as well (so that we dont need to query their server again for the same IP and we have longer retention rules). Querying our server results in a query to the SFS server if an IP is not blacklisted in our own DB. I'm considering other services as well. The more data we have the better.

NEW: Honeypot integration! This module can now create ip bans based on blocked Honeypot form submissions. However, I've elected to only ban based on honeypot block types of 'honeypot' and not 'honeypot_timestamp' since it's the only method that is 100% certain to be a spammy submission.

Also note that your server must be able to contact outside servers on ports 6443, 6980 or 443 or it will not report to the crowd source server. There is a test connection feature to test the connection from your server to the crowd source server and you can enable/disable both sending and receiving from the crowd source server. Please only disable these if it's absolutely necessary (dev servers for example). This will only work if we all participate ;)

What is Crowd Bruteforce Protection?
Well, it's exactly what it says, it uses the Crowd Sourcing mentality for protecting your website, wikipedia explains it best: Currently it protects against Bruteforce logins/Honeypot rejections and bans any IP that tries spam your website forms (via Honeypot rejections) or tries to login to your website X times (this is configurable via the flood_control module which I have set as a requirement for this module). If an IP fails at logging into your website within X tries (X failed tries locks the user account like normal drupal operation, also configurable), it's then banned on your local website but it's also reported back to my server and added to the "blocked IPs" list for other websites to see. If 3 other websites (all must come from different originating IPs and must have valid domain names that point at the originating IP) reports the same IP as having failed X times, then my server marks it as "banned". From that point forward, for a period of 7 days (may change in the future, but just starting out with this as a test limit), all Drupal websites that have this module installed will automatically block the offending IP from viewing their websites entirely. So the end result is that this should help protect against not only bruteforce login attempts, but it could also help protect against worms, rogue servers, spam, and other illegal non-sense that bad guys tend to do from their infected servers since they tend to use the same server for multiple attack vectors.

The data the we collect are IP's that fail at trying to login. So our "services, ideas, or content" (as described in the aforementioned wikipedia link) are in the form of IP addresses of bad guys. Then we take that knowledge and kick those bums to the curb :) So, the more people that install this module, the more effective it will become. It will connect us all together like one big Drupal install and allow us to put a stop to bruteforce login attempts which for whatever reason, are currently on the rise. BTW, it should also be noted that IP's who do bruteforce login attacks are usually also up to no good in other areas. Getting a lot of spam from china are we? Well, guess what else they're up to. They're also trying to break into your accounts so they can post even more spam lol. So I'm hoping that this endeavor also helps decrease spam/worms on Drupal sites as well. I selected logins because it's the easiest thing I could think of that everyone does exactly the same. I thought of doing comment spam and other things like that, but not all sites do that and not everyone does it the same way. We all probably login the same way so that seemed like the most logical place to begin a Crowd Sourced Protection scheme for Drupal. I'm not a genius or anything, but I like to think I do have a good idea every now and then heh. Hopefully this turns out to be one of my better ideas/side projects. This project is NOT sponsored by anyone, I am currently doing this on my own. If you want to sponsor it by providing servers, cash, coding, anything like that, just let me know. Right now I dont need help, but if this thing becomes as large as I would like it to be, I'm not going to be able to go it alone with my meager pay as a lowly developer lol. I do have ideas on how to monetize it in case it needs to support itself, but I'm not at that point..... yet. And if it comes to that, it will still somehow manage to be 100% free to use. One of the ideas I've been tossing around is to offer a subscription to import the entire DB into your drupal install on a schedule so you dont need to hit my servers at all which will give you a slight speed boost as well as help me keep the DB growing by giving it a better server, etc. We're not at that point yet though, so its nothing more than and idea and I'm always open to suggestions.

What if no one else installs this module? Would it still be useful? If so, why?
Yes, this module is VERY useful even without the crowd sourcing capabilities and here is why. Drupal's own flood control and ip blocking are very rudimentary and is not really a complete "feature" in my opinion. It lacks many features such as a whitelist and the ability to modify it's own internal configuration settings. Now, while this module doesnt deal with configuration options (another module does that very well), it does glue the two features together to create a useful automated bruteforce login protection scheme that is better than what comes with Drupal by default. For example, did you know that if you hit drupal's built in User Flood limit of 5 tries, you are still not able to login even after changing your pw with the one-time login link even though it "says" you will be able to login after that? This is because the one time login process does not clear out the flood table like it should. So your users would essentially still be "blocked" even when they shouldnt be. This IMO is a bug that will likely never be fixed, and thus this module fixes the quirks that drupal has like this. There are several others also. So the bottom line is, yes, this module is very useful even without the crowd sourcing. So for the brave souls who install this module initially, you will still be installing something useful. Once more people dip their toes in and this grows, it will only get better at it's job which is to kick the bad guys to the curb :)

Why not just use built in Drupal Flood features/table and IP Blocking?
1. For starters like I mentioned above, Drupal's flood control is very rudimentary. Example, if a user gets blocked after 5 attempts, it REMAINS blocked whether they reset their pw or not. Go ahead and try it. Good luck getting back in lmao. It's also an unfinished feature and I believe it was abandoned when D8 was started or at least it appears to have been. The only way to "unblock" a user is to install a module that allows you to do it manually or has this bug fixed (such as this module), or write your own module that does it for you when they login successfully from a pw reset link, or wait for the entries to expire, OR install this module of course heh. The flood control also uses 2 variables that are never even set nor are they modifyable anywhere without installing contrib modules. This module is one of those contrib modules that allows you to modify the flood control variables (via a requirement on another contrib module, thanks for that bro lol) so that you can use something other than drupals hardcoded defaults of 5 failed logins per account or 50 failed logins per IP. This module lowers the failed logins to 3 and the per IP to 7. The reason Drupal set 50 so high is because they were accounting for "institutions" such as universities, etc where the logins for multiple users come from the same IP. We dont need it set that high since each install can modify those settings to suit their own website just fine. So lowering it by default makes the most sense.

2. Drupal's IP Blocking is also manual, you have to manually block IP's yourself by typing them in. It's also not connected to the built in Drupal Flood features at all either. So if you unblock an IP, it would still have entries in the flood table which essentially still blocks IPs, so that bug has been fixed by this module as well. When you delete something from the IP Block table, it also clears the flood table for that IP (seems logical to do to me, idk why that wasnt being done in the first place). It's a real shame because the blocking mechanism itself is EXCELLENT since it starts extremely low in the bootstrap. Heck even the t() function isnt available before the IP Blocking kicks in let alone your snazzy 900K logo :). The sad truth is that Drupal's Flood control has it's own blocking mechanism and doesnt even make use of Drupals own IP Blocking features (this module fixes that also by gluing them together). Dont ask how that one got into core, IDK the answer to that. It is what it is. So this module sort of connects these two features together into one great service, and then adds to it by adding the crowd sourcing options which is just an extra added bonus that will only improve as more people install this module.

3. This module does however make use of Drupals built in "IP Blocking" features unlike drupal's flood control. But you will only see IPs that are added locally. So what is the definition of Locally? Well, that is any IP that comes to your website and fails to login X amount of times. This means you wont see Crowdsource banned IPs show up in the block list UNLESS they visit your website (they are added the second they hit your website in hook_boot, they wont even see the login page. See ya bad guys lmao). Then it will cache that IP locally and it would then show up in the "blocked IPs list" that comes with drupal. However, deleting it would really have no effect since the cloud server would just re-add it and it would keep doing so until the ban expires. The only way to stop this is to add a feature that drupal DOESNT have and that is a Whitelist. Drupal is great at blocking, but allowing people based on a whitelist, naa, that was completely ignored as a feature for god knows why lol. So this module adds that missing feature to drupal as well. So any IP that is in the whitelist table will cause that IP to be removed from the blocked_ips table and the interface will then no longer allow you to add that as an IP. The login process will also no longer add any flood entries for that IP nor will it bother to check the cloud server to see if that IP is banned. This results in a truly whitelisted IP as long as you only use drupal's built in ip blocking of course and not some other module that provides ip blocking (idk if any even exist anyway). It wont however stop drupal from locking your account if you fail X amount of times. The user still screwed of that happens, but it's at that point that you need to go ahead and use the reset password features anyway and that portion of Drupal works great, so its a non-issue.

4. It has no options to connect to a crowd sourcing server, duh, Drupal would never have such a feature. Since bad guys tend to eat up CPU resources on your website until they hit the IP login failure threshold it would be nice if we could stop them from doing that in the first place. This is where the crowd sourcing comes into play. Other websites that install this module tell us who the bad guys are by reporting them automatically and thus we're able to stop them from eating ANY bandwidth at all rather than giving them a small piece of our bandwidth/server resources pie. This way if a whole gang of bad guys comes to your website (either separately or as a group) with hopes and dreams of gobbling up all your users pw's, they wont be able to eat ALL of your pie leaving none for your regular users. You will be able to slam the door in their face before they even get to see what the pie looks like let alone eat some :) So make sure you ask all your friends to install this module! The more people we get to install this, the more reliable the network will become and the faster all of our drupal sites will run because we're not giving away CPU/Ram/Disk IO/Bandwidth to the bad guys. Another interesting thing is that these IPs we collect will be useful in OTHER areas because if they are up to no good with logins, they're probably up to no good in other areas too like filling out forms, scanning for vuln's and what not. So this will probably also stop spammers and worms from ever visiting us! Whether or not that comes to fruition I dont really know, but it's not a bad educated guess either. It's something I'm hoping will come about as a side effect. Anything that reduces spam/worms is welcome at my dinner table any day! I dont have plans to enter the spam/worm fighting vectors since there are plenty of modules that do that already, but I certainly wont mind helping contribute another small piece even if it's done inadvertently.

Recommended modules:
- With this module enabled, you will greatly increase the number of spammer IP's to the crowd source server which in turn allows everyone else to block that IP before it ever even gets to submit anything to their site! And of course you benefit from others using the same Honeypot + CBP combination as well. So I HIGHLY HIGHLY recommend installing Honeypot and configuring it properly (there are plenty of docs on the honeypot page to do that).

Why this module instead of spambot which uses
Simple. That module does NOT block low in the bootstrap like this module does. It provides you with zero performance enhancements when it blocks an IP. This module provides significant performance enhancements because it blocks the IP before your website is ever even loaded. Other than that, it's almost identical. I am considering using the Stop Forum Spam API in this module as well, but I'm not sure how many false positives it has in it so I'm a little hesitant at the moment, but giving it a lot of thought and doing research to see if it's a worthy addition. Also, it has not integrations with other modules and it does not make use of drupal's own banning features. IE: It has no honeypot integration :/ Thus it's almost useless in providing new IP data to the database. It's really only good for using data from sfs, not giving it new data which is sort of purpose defeating.

There are currently NO sponsors for this module. I pay for the server myself and as of right now, it's doing just fine but that may change as the module becomes more popular. If you're willing to pay for new infrastructure for this module (I'd like to use Amazon or Heroku at some point), we may have things to talk about. If you have ideas on monetization, I MAY be open to that as I do have ideas, but I will not compromise any of the current functionality in order to monetize it. Any monetization would include features that are nice to have but not necessary for the module to do its main job. Message me here if you have ideas or want to talk about sponsorship.

Will you help me secure my site? (IE: it was hacked or something) I seem to get this question a lot since starting this little project. Short answer: No. I only contract for large projects. If you cant afford 10K, you cant afford me. But hey, if you're looking to offer me a large contract then we can at least talk. Large to me is 100K+. So that should weed out about 99% of you out there :) For the remaining 1%, lets talk :D

Project information