Thanks, you give me some good ideas. <br><br><div class="gmail_quote">2010/11/5 Eugaia <span dir="ltr"><<a href="mailto:ngx.eugaia@gmail.com">ngx.eugaia@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<div class="im"><br>
<br>
On 05/11/2010 11:51, Weibin Yao wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote></div>
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.<br>
<br>
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.<br>
</blockquote><div>The IP lookup overhead is very low and quick, I allocated a big hash table.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
You could have directives like :<br>
<br>
limit_access_cookie [cookie_name];<br>
limit_access_cookie_str [cookie_value];<br>
<br>
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.<br>
<br>
limit_access_cookie_hash md5;<br>
<br>
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.<br></blockquote>
<div>I think it's a new and useful feature and should develop a different module. I will have a try after my limit_access module.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Just a few ideas, anyway. Good luck with it!<br></blockquote><div>Thank you. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Marcus.<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://nginx.org/mailman/listinfo/nginx" target="_blank">http://nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br>