Hi,

On 05/11/2010 11:51, Weibin Yao wrote:
> I think it's good to divide the determination from the Nginx. It's
> hard to determine the IP by single Nginx whether is good or bad.
> Actually we have 20+ reverse proxy Nginx servers in the front. Each
> Nginx doesn't known others status. In our DDOS attack, the bad-IP's
> request rate is a little higher than the normal request.
I agree it's a good idea to split the determination, and I think it
might be good to put the lookup code inside the get handler for the
variable - so that the lookup is only made if it is required.

You might want to also think about having a setting to check for the
existence or value of a cookie before doing the IP lookup - to avoid
unnecessary overhead. It might also be better to handle the setting of
the cookie value inside your Nginx module, since it would make keeping
the generation and checking of cookie values consistent easier to manage.

You could perhaps handle the setting / value of the cookie inside Nginx,
and have a system similar to Maxim's auth_request module - whereby a
subrequest which would check the reCaptcha (or whatever) value, and
return 200 for success or anything else for failure.

You could have directives like :

limit_access_cookie [cookie_name];
limit_access_cookie_str [cookie_value];

and you might want to add optional hashing (e.g. MD5) of the cookie
string, to make it harder for determined hackers to get past cookie
authentication - e.g.

limit_access_cookie_hash md5;

I think the overhead of checking hashed values of a cookie wouldn't be
too high, since in most cases under DDoS, the cookie wouldn't exist, so
you'd generally only be hashing for genuine users.

Just a few ideas, anyway. Good luck with it!

Marcus.

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx