By Wolf_22 on

I've been getting visitors from a specific set of user agents which keep trying to access node/add and user/register. They haven't been successful in doing anything because I have security configurations in place to assist with things like this. However, what I want to do is block these visitors entirely at the server level so that their visits don't consume server resources like CPU and RAM as every hit to those paths causes Drupal to trigger various processes that sap up resources.

I've been trying to implement things at the HTACCESS level but I've been told that even this uses resources due to HTACCESS needing to be re-parsed during each visit. This led me to being told that the httpd.conf file should be used, but since I'm in a shared environment, I doubt that's an option.

I posted about all this over on Reddit (Drupal Subreddit). I also posted about this on the Apache Subreddit. The Drupal Subreddit is where I learned that the settings.php file could be used to manipulate cookie functionality (outside of HTACCESS as an easier means of debugging requests) but the Apache post hasn't yet been responded to and I'm not expecting anyone to respond to it due to the verbosity of it.

So, this leads me to posting about all this here: what's the best way to block a variable set of IP-identified requests at the server? I get hits from all across the globe and every time, it's always a different IP that requests node/add or user/register. They frequently have a version of the Apple WebKit user agent, but that's the only commonality to it.

Any insights would be appreciated and thanks in advance.

⋅ Categories: Drupal 7.x

Comments

yelvington’s picture

yelvington commented

So, this leads me to posting about all this here: what's the best way to block a variable set of IP-identified requests at the server? I get hits from all across the globe and every time, it's always a different IP that requests node/add or user/register.

The best place to implement a IP address block would be at the firewall level, but you can't do that on shared server. The second best place is at the webserver level (config or .htaccess). The most "expensive" place is in Drupal.

But your question indicates that you don't know the addresses until after they've visited. You can waste an awful lot of time blocking would-be spammers working in Internet cafes in India and China.

If you're concerned about anonymous visitors chewing up resources, you should start by implementing a cache strategy, which benefits everybody. For a small site, start with https://www.drupal.org/project/boost.

Wolf_22’s picture

Wolf_22 commented

Thanks for the link, yelvington! Judging by what I'm seeing from that project page, it sounds like that is an all-around beneficial thing to add. I'm curious: have you used that module before? What did you think of it?

I'm thinking I need to add some things to my htaccess file for various visitor signature blocks. I have some things now but the issue is that I think I've done some poor testing with the rules I've added because A.) I didn't realize that htaccess can be cached, and B.) it seems as if htaccess can sometimes be interpreted differently between different browsers. I might do both: add a caching solution like the one you proposed, but also keep moving forward with the htaccess security implementation I'm moving forward with. I think it mostly nails it using the rules I have, but I think I just need to tweak them a bit to verify their logic.

yelvington’s picture

yelvington commented

I've used Boost. It works very well and is a good solution for sites that can't justify a high-end caching solution (Varnish). Anonymous pages are saved in the filesystem as HTML, and served without involving Drupal, MySQL, or PHP.

As for .htaccess ... it doesn't work differently across browsers, because it's never seen by browsers. It's a set of configuration instructions to the Apache webserver. The same instructions could be implemented in the server's config file (read only once, when the server is booted up).

Road Runner’s picture

Road Runner commented

TO block IPs or range of IPs and then CPanel adds soemthing like following to your .htaccess
deny from 195.154.215.76

That's a real world example.
I assume you can just edit .htaccess yourself and add the above commandwith appropriate IP you want blocked

Wolf_22’s picture

Wolf_22 commented

Road Runner, the whole point of this is blocking system-intensive requests made by IP addresses that change each request. Blocking entire blocks isn't a worthy solution here since some legitimate requests are made even in bad blocks.