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

B.R. reallfqq-nginx at yahoo.fr
Tue Sep 13 14:05:00 UTC 2016


You were just told the best way to get a meaningful $binary_remote_addr
variable using CloudFlare, with the added bonus of a list of network ranges
to use with set_real_ip_from to only filter out CloudFlare's IP addresses
as sources to be repalced and avoid false positives.

Using the $binary_remote_addr variable takes less space inside your
fixed-sized zone, thus allowing to store more entries.
I suggest you carefully read on the impacts of filling-up the zone memory
and why using as little data per client is highly advised in limit_req_zone
<http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_zone>
directive docs as you do not seem to know what you are doing...
---
*B. R.*

On Tue, Sep 13, 2016 at 3:08 PM, c0nw0nk <nginx-forum at forum.nginx.org>
wrote:

> Reinis Rozitis Wrote:
> -------------------------------------------------------
> > > But that book says it is to reduce the memory footprint  ?
> >
> > Correct, but that is for that specific varible.
> >
> > You can't take $http_cf_connecting_ip  which is a HTTP header comming
> > from
> > Cloudflare and prepend $binary_ just to "lower memory footprint".
> > There is no such functionality.
> >
> >
> > What you might do is still use $binary_remote_addr but in combination
> > with
> > RealIP module (
> > http://nginx.org/en/docs/http/ngx_http_realip_module.html ):
> >
> > real_ip_header CF-Connecting-IP;
> >
> > Detailed guide from Cloudflare:
> > (
> > https://support.cloudflare.com/hc/en-us/articles/200170706-How-do-I-re
> > store-original-visitor-IP-with-Nginx-
> >  )
> >
> >
> > Theoretically it should work but to be sure you would need to test it
> > or ask
> > a nginx dev for confirmation if the realip module takes precedence and
> >
> > updates also the ip binary variable before the limit_req module.
> >
> > rr
> >
> > _______________________________________________
> > nginx mailing list
> > nginx at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx
>
>
> Thanks for the info :) For now I will just stick with what I know is
> currently working either way I believe the stored key in memory won't be
> compressed due to being behind cloudflare's reverse proxy as you said only
> $binary_remote_addr is compressing their IP to reduce memory footprint.
>
> Here is my config for anyone who wants to test or play around same as in
> original email.
>
> map $http_cf_connecting_ip $client_ip_from_cf {
> default $http_cf_connecting_ip;
> }
>
> limit_req_zone $client_ip_from_cf zone=one:10m rate=30r/m;
> limit_conn_zone $client_ip_from_cf 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;
> }
> }
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?2,269502,269521#msg-269521
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160913/cb8f1ef1/attachment.html>


More information about the nginx mailing list