For what it's worth, on Drupal 6 I used .htaccess deny from rules to ruthlessly block networks with spammers... and oddly enough, that was effective. It took a couple weeks to build up a complete enough .htaccess block list. This is complete crap, but it might still be useful regardless of drupal version. Here's the related excerpt from my current .htaccess. - Dan Order allow,deny allow from all # AhrefsBot deny from 173.199.114 173.199.115 173.199.116 173.199.117 173.199.120 # webmeup.com / blexbot deny from 108.178.53.226 108.178.60.2 198.143.187.202 # Too-frequent registers #$ grep register www_logs/access_log | awk '{print $2}' | sort | uniq -c | sort -n | awk '$1 > 7 {print $2}' > bad.new #$ zcat www_logs/www.20130521.gz | grep register | awk '{print $1}' | sort | uniq -c | sort -n | awk '$1 > 7 {print $2}' > bad.old #$ fgrep -f bad.old bad.new # Aw, screw it, deny everybody who over-accessed the register page on 20130825. # First, class C or B network with multiple hits: deny from 5.135 deny from 5.39 deny from 23.19 deny from 37.59 deny from 46.105 deny from 50.115 deny from 50.117 deny from 93.182 deny from 94.23 deny from 96.127 deny from 108.178 deny from 151.237 deny from 173.0 deny from 173.236 deny from 176.31 deny from 178.32 deny from 178.238 deny from 184.154 deny from 188.165 deny from 192.95 deny from 198.143 deny from 199.180 # Then individual addresses. These probably aren't worth blocking. deny from 1.83.33.254 deny from 108.163.224.181 deny from 108.62.71.76 deny from 109.231.47.99 deny from 110.86.185.249 deny from 118.208.100.93 deny from 120.37.243.163 deny from 138.91.33.87 deny from 142.91.79.16 deny from 142.91.79.6 deny from 173.208.2.157 deny from 173.213.90.5 deny from 173.254.255.133 deny from 176.61.140.238 deny from 178.137.83.252 deny from 178.216.48.237 deny from 178.63.199.209 deny from 180.180.104.227 deny from 182.52.46.99 deny from 192.157.239.74 deny from 192.254.78.26 deny from 192.40.88.202 deny from 198.12.124.103 deny from 198.175.125.173 deny from 198.2.198.132 deny from 198.49.70.131 deny from 198.52.240.60 deny from 199.119.226.123 deny from 199.59.63.245 deny from 199.91.174.227 deny from 204.12.208.162 deny from 206.214.93.150 deny from 208.89.208.165 deny from 219.83.100.195 deny from 27.159.239.22 deny from 37.187.73.26 deny from 5.34.242.16 deny from 5.39.44.28 deny from 59.183.7.52 deny from 66.248.193.63 deny from 69.175.39.229 deny from 78.10.93.101 deny from 79.133.196.50 deny from 80.72.38.195 deny from 83.111.98.126 deny from 88.156.13.111 deny from 89.230.79.51 deny from 91.121.164.212 deny from 91.236.74.165 # Login attacks # grep 'POST /.q=user' www_logs/access_log | awk '{print $2}' | sort | uniq -c | sort -n deny from 188.143.233.136

Wow. I want to thank everyone for their quick and extensive replies. I will look at botcha and Honeypot and see if they help. I have the math captcha on another drupal site but that hasn't stemmed the tide. These replies have given me enough to keep me bust for a while. On Tue, Feb 4, 2014 at 6:58 PM, Neil Adair <neiltadair@gmail.com> wrote:

I use honeypot on all sites and it does a pretty good job, not perfect. I've also been surprised how well the mathematical CAPTCHA works (an option in CAPTCHA module) , it's easier for users and it seems the bots can't deal with it as easily as they do the regular image CAPTCHA probably because they don't encounter it much. I've also used https://drupal.org/project/user_restrictions to block repeated account registrations from some domains.

Neil

On 4 February 2014 17:17, MBR <mbr@arlsoft.com> wrote:

...

THE PROBLEM:

I've helped a number of people whose sites have this problem. It seems that CAPTCHA ("*C*ompletely *A*utomated *P*ublic Turing test<http://en.wikipedia.org/wiki/Turing_test>to tell *C*omputers and *H*umans *A*part") has been broken by the black hats. CAPTCHA asks the submitter of a form to demonstrate that he can perform a task that a computer is assumed to be unable to do. Google "CAPTCHA broken" and you'll find lots of articles. OCR (optical character recognition) software has been around for decades. CAPTCHA's distort the letters in the hope of making the OCR software's task more difficult.

But the black hats don't even need to do that. http://www.theguardian.com/technology/2008/aug/28/internet.captcha explains that the most successful CAPTCHA-breaking schemes involve social engineering. When the program that's trying to convince your website that it's human receives a CAPTCHA image to solve, it can pass it on to real humans to solve, and then send their solution back to your website. There are even business models where the bad guys pay people in third-world countries a small amount of money to do this.

TEMPORARY SOLUTION:

So, what's the answer. For the moment, the most effective approaches I know of involve a kind of inverted Turing test. Instead of asking the human to prove he's not malware, trick the malware into demonstrating it's not human. One way to do this is to note how quickly responses come back. If they come back faster than a human could type them, then they're being sent by a machine. Another way is to insert extra <input> tags into your forms and use CSS to hide them. They won't be displayed by the browser, so a human won't fill those fields in. But a piece of software pretending to be a browser operated by a human usually isn't coded to fetch the CSS and figure out which fields it shouldn't fill in. So it will fill in all the fields in the form, and the software on your server can then tell that the submission is not from a human.

Of course, with a little work the malware can be made to handle both of these tests. You wouldn't even have to write the code to fetch the CSS and figure out whether an input field is visible. It already exists in every browser. You'd just have to lift the right sections of the code from a browser, and maybe convert it into a different programming language. As for timing, it's trivial to introduce a random delay before the malware sends its response.

So, these tests probably won't work for very long.

TEMPORARY SOLUTION FOR DRUPAL SITES:

When I went looking for Drupal modules that implement these approach, I found Botcha, Honeypot, Spamicide, and Spambot. Initially I tried Botcha but it was a struggle to get it installed, and then it didn't seem to work properly. I then looked more closely at the statistics for each of the modules I was considering. I found that Botcha and Spamicide had critical bugs that had gone unfixed for a couple of months - not a good sign. Especially since the reported bug in Spamicide bug was that on installation it wiped the default/files directory. Spambot showed as unmaintained.

That left Honeypot, which impements both the timing test and the invisible input field test. It didn't have any bugs of severity "Critical", but did have one whose severity was "Major". So I read the bug report on that. It didn't sound like anything that would destroy data or stop the website from functioning. So that seemed like the best solution.

Immediately after I installed the Honeypot module, the bogus registrations dropped from about 10 to 15 per hour to about 4 per day. So, it seems to be the best available solution for now. But I fully expect the bad guys to improve their software in the near future to get around these tests. When that happens, we'll be back to square one.

Mark Rosenthal

On 2/4/2014 2:22 PM, john boris wrote:

I am working on a new site (Drupal 7) and I have reCaptcha module installed which includes the image captcha as well. This still isn't keeping out the gnats trying to get logins. I have the site set that all new users need to verified with a valid email and the admin needs to authorize the new user but it still hasn't stopped them. I am looking for other ideas where I can limit these issues. I am getting about 15 a day and they seem to be growing. I have a few mandatory fields setup but I don't want to make it totally a pain for new users to put in the valid info.

This might be just a cost of having the thing open for new users but if anyone can give me some other ideas on how to stem the tide I would appreciate it.

Thanks in advance.

-- John J. Boris, Sr. Online Services www.onlinesvc.com

-- [ Drupal support list | http://lists.drupal.org/ ]

-- [ Drupal support list | http://lists.drupal.org/ ]

-- John J. Boris, Sr. Online Services www.onlinesvc.com