2

I'm trying to protect my applications from some bots that are either malfunctioning or trying to take my sites down (lots of requests from the same IPs in the logs).

Every time someone requests an expensive or security-related action, I save the name of that action, the IP, and the date. Then I check for some limits, eg: the action login.fail has a limit of 10 attempts every 10 minutes, and 20 per hour. If the limit is exceeded, I save the ban and allow no more actions from that IP (I simplified the description a bit).

This works well, but this could leave legitimate users out. For example, if lots of users are coming from the same VPN and share the same IP (even if the bots are not coming from that IP). And I don't want to create sites that hinder privacy (by banning VPNs) just to be safe from bots.

I can't check for headers like the User-Agent because those can be faked.

So what can I do? Is there a way around this? Anything else I can check other than the IP?

ChocoDeveloper
  • 141
  • 3

2 Answers2

4

Have you ever considered protecting your site behind a service like CloudFlare? They act as a reverse proxy for your site and will scrub bad traffic at their edge nodes based on some very advanced heuristics. Even their free accounts offer a great level of protection because it's in their interest to drop malicious traffic so it doesn't pass through their network. Not only that but they have many advanced features like auto-minification of HTML/JS/CSS, CDN, analytics and more. I wrote a quick blog covering them after I started using them here.

Scott Helme
  • 3,178
  • 3
  • 21
  • 32
  • Yes thanks, I used them in the past. But Cloudflare is US based and also it left me outside of many sites by default. And many other sites even had broken javascript and it was their fault (they made localStorage mandatory, which I have disabled for privacy). So that's the kind of thing I want to avoid. – ChocoDeveloper Oct 25 '13 at 21:05
  • I'm sorry, I'm not sure I understand. What do you mean "left me outside of many sites" and about making localStorage mandatory? Yes there can be issues with JavaScript, I've had to disable rocket loader on some of my sites but you just do that on an 'as needed' basis. Personally I've found them to be great :) – Scott Helme Oct 25 '13 at 21:10
  • I mean that sites I visited regularly added Cloudflare and now I can't use them anymore. In some of them Cloudflare blocked me, in others asked for a captcha (didn't work for some reason, maybe js was broken there too), in others it didn't block me but there was a cloudflare.min.js file with errors. The error was that they were using localStorage without graceful degradation (if you don't have localStorage enabled, it breaks their javascript and the site is unusable). – ChocoDeveloper Oct 25 '13 at 21:13
  • 1
    Interesting. I will have a look into it. As I say I use them across all my sites but I have never had an issue. I like to look into things that can be a problem ;-) – Scott Helme Oct 25 '13 at 21:18
2

Well if you can (I assume as you mentioned login.fail) you should cross-relate functions with usernames / logins so that each user can only perform your watched functions X times in a given window of time.

Other than this there aren't really anything you could do to secure your application as privacy can be an effective means for breaking security.
(Because if I can be completely indistinguishable from other people why shouldn't I go robbing banks and have law-enforcement arrest someone else?)

Wolfer
  • 298
  • 2
  • 13
  • Many of the actions I wanted to protect can be performed anonymously (login, register, forgot password, contact us), so I can't cross-relate with usernames. For other actions it might work. – ChocoDeveloper Oct 25 '13 at 21:10
  • Logging in isn't really "anonymus" from your point of view as someone logging in as `xy` user must know that user's password, and as such you can consider the person to be that user (which does not make it necessary for you to know WHO he/she is, but allows you to track said username's actions). The same goes for most of the stuff except the contact us feature, which looks like something that will get abused a lot (except if you make logging in a prerequisite for it, in which case the previous stuff about you having the user's session/login/cookie/whatever tracked still applies). – Wolfer Oct 26 '13 at 13:28