Keeping your Nginx limit_* Anti-DDoS behind CloudFlare's servers

lists at lazygranch.com lists at lazygranch.com
Tue Sep 13 09:34:39 UTC 2016


‎I'm assuming at this point if cookies are too much, then logins or captcha aren't going to happen. 

How about just blocking the offending websites at the firewall? I'm assuming you see the proxy and not the eyeballs at the ISP. 

I have my hacker detection schemes in nginx. I flag the clowns, yank the IPs every day or so, and block the IP space of any VPS, colo, etc. ‎I have blocked so much of the hacker IP space that I can go days before finding a new VPS/etc to feed the firewall. Amazon, Google hosting, Rackspace, Linode, Digital Ocean, Soft layer and especially Ubiquity/Nobis is probably 3/4 of the clowns. Machines are not eyeballs, or in your case, ear canals. Block 'em. 

Oh yeah, I block Cloud Flare.

  Original Message  
From: c0nw0nk
Sent: Tuesday, September 13, 2016 1:52 AM
To: nginx at nginx.org
Reply To: nginx at nginx.org
Subject: Re: Keeping your Nginx limit_* Anti-DDoS behind CloudFlare's servers

I was going to do a cookie method but its bad because on browsers with no
cookies that make legitimate requests (first time visitors maybe that don't
have a cookie set) or browsers on legitimate users who disable cookies or
use extensions / add-ons to only whitelist cookies from sites they
specifically allow like facebook, youtube etc.

So that's why I decide to peruse the connection and requests per second /
min limits because it can't be spoofed by the server proxying / making the
request.

It is so easy for me to proxy and spoof those client headers its pretty
funny.

proxy_set_header "User-Agent" "custom agent";
proxy_set_header "Cookie" "cookiename=cookievalue";
proxy_set_header "Referer" "networkflare.com";

And my example above is why I am not trusting the client for anything and
want to go with the one thing they can't fake to me their IP.




gariac Wrote:
-------------------------------------------------------
> ‎What about Roboo? It requires a cookie on the website before the
> download takes place. (My usual warning this is my understanding of
> how it works, but I have no first hand knowledge.) I presume the hot
> linkers won't have the cookie.
> 
> https://github.com/yuri-gushin/Roboo
> 
>   Original Message  
> From: c0nw0nk
> Sent: Tuesday, September 13, 2016 1:09 AM
> To: nginx at nginx.org
> Reply To: nginx at nginx.org
> Subject: Keeping your Nginx limit_* Anti-DDoS behind CloudFlare's
> servers
> 
> So I noticed some unusual stuff going on lately mostly to do with
> people
> using proxies to spoof / fake that files from my sites are hosted of
> their
> sites.
> 
> Sitting behind CloudFlare the only decent way I can come up with to
> prevent
> these websites who use proxy_pass and proxy_set_header to pretend that
> files
> they are really hotlinking of my site is on and hosted by theirs is
> using
> Nginx's built in Anti-DDoS feature.
> 
> Now if I was to use "$binary_remote_addr" I would end up blocking
> CloudFlare
> IP's from serving traffic but CloudFlare do provide us with the real
> IP
> address of users that pass through their service.
> It comes in the form of "HTTP_CF_CONNECTING_IP"
> 
> But when it comes to limiting files that are being hot linked to break
> their
> servers from serving traffic they are stealing from mine I don't know
> if I
> should be using "$http_cf_connecting_ip" or the equivalent with
> "$binary_"
> ?
> 
> limit_req_zone $http_cf_connecting_ip zone=one:10m rate=30r/m;
> limit_conn_zone $http_cf_connecting_ip zone=addr:10m;
> 
> location ~ \.mp4$ {
> limit_conn addr 10; #Limit open connections from same ip
> limit_req zone=one; #Limit max number of requests from same ip
> 
> mp4;
> limit_rate_after 1m; #Limit download rate
> limit_rate 1m; #Limit download rate
> root '//172.168.0.1/StorageServ1/server/networkflare/public_www';
> expires max;
> valid_referers none blocked networkflare.com *.networkflare.com;
> if ($invalid_referer) {
> return 403;
> }
> }
> 
> So the above is my config that should work I have not tested it yet
> but I
> really wanted to know what the purpose of the "$binary_" on these
> would be
> and if i should make them resemble this. (Not even sure if the below
> is
> correct I am sure someone will correct me if
> "$binary_http_cf_connecting_ip"
> won't work.)
> 
> limit_req_zone $binary_http_cf_connecting_ip zone=one:10m rate=30r/m;
> limit_conn_zone $binary_http_cf_connecting_ip zone=addr:10m;
> 
> Thanks for reading :) looking forward to anyone's better idea's /
> solutions
> and also recommended changes to preventing stealing of my bandwidth on
> these
> kinds of static files that can be up to >=2GB in size.
> 
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?2,269502,269502#msg-269502
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,269502,269506#msg-269506

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



More information about the nginx mailing list