Rate limiting Django admin login with Nginx to prevent dictionary attack

I'm looking into the various methods of rate limiting the Django admin login to prevent dictionary attacks.

One solution is explained here: http://simonwillison.net/2009/Jan/7/ratelimitcache/

However, I would prefer to do the rate limiting at the web server side, using Nginx.

Nginx's limit_req module does just that - allowing you to specify the maximum number of requests per minute, and sending a 503 if the user goes over: http://wiki.nginx.org/NginxHttpLimitReqModule

Perfect! I thought I'd cracked it until I realised that Django a开发者_运维知识库dmin's login page is not in a consistent place, eg /admin/blah/ gives you a login page at that URL, rather than bouncing to a standard login page.

So I can't match on the URL. Can anyone think of another way to know that the admin page was being displayed (regexp the response HTML?)

first of all: to secure the django admin a little bit, i always use a url for the admin different to /admin/ a good idea would be to deploy the admin as a second application on another domain or subdomain

you can limit the requests per minute to the whole webapp via IPTABLES/NETFILTER. a tutorial how this is done can be found at debian administrator. this is an example how to secure the ssh-port, but you can use the same technique for http.

You can use NginxHttpLimitZone module to limit the number of simultaneous connections for the assigned session or as a special case, from one IP address. Edit nginx.conf:

from www.cyberciti.biz

### Directive describes the zone, in which the session states are stored i.e. store in slimits. ###
### 1m can handle 32000 sessions with 32 bytes/session, set to 5m x 32000 session ###
       limit_zone slimits $binary_remote_addr 5m;

### Control maximum number of simultaneous connections for one session i.e. ###
### restricts the amount of connections from a single ip address ###
        limit_conn slimits 5;

The above will limits remote clients to no more than 5 concurrently "open" connections per remote ip address.

bmaeser is right, you should run admin in a separate instance (ie separate domain/subdomain/port).

You might also be interested in django-sentinel, which does dynamic greylisting of suspicious ip addresses/networks using memcached and auto-blacklists repeat offenders.