nginx Digest, Vol 139, Issue 19
Amila Gunathilaka
amila.kdam at gmail.com
Wed May 19 02:25:24 UTC 2021
Hi All,
Any update for my issue guys ?
2. Help: Using Nginx Reverse Proxy bypass traffic in to a
application running in a container (Amila Gunathilaka)
Thanks
On Tue, May 18, 2021 at 4:44 PM <nginx-request at nginx.org> wrote:
> Send nginx mailing list submissions to
> nginx at nginx.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.nginx.org/mailman/listinfo/nginx
> or, via email, send a message with subject or body 'help' to
> nginx-request at nginx.org
>
> You can reach the person managing the list at
> nginx-owner at nginx.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nginx digest..."
>
>
> Today's Topics:
>
> 1. Re: Memory usage in nginx proxy setup and use of min_uses
> (Maxim Dounin)
> 2. Help: Using Nginx Reverse Proxy bypass traffic in to a
> application running in a container (Amila Gunathilaka)
> 3. How to spawn fastcgi c++ app on windows? (hkaroly)
> 4. net::ERR_HTTP2_SERVER_REFUSED_STREAM (Anoop Alias)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 18 May 2021 04:27:02 +0300
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx at nginx.org
> Subject: Re: Memory usage in nginx proxy setup and use of min_uses
> Message-ID: <YKMX5jSb+Qr1oA70 at mdounin.ru>
> Content-Type: text/plain; charset=us-ascii
>
> Hello!
>
> On Mon, May 17, 2021 at 07:33:43PM +0000, Lucas Rolff wrote:
>
> > Hi Maxim!
> >
> > > - The attack you are considering is not about "poisoning". At
> > > most, it can be used to make the cache less efficient.
> >
> > Poisoning is probably the wrong word indeed, and since nginx
> > doesn't really handle reaching the limit of keys_zone, it simply
> > starts to return a 500 internal server error. So I don't think
> > it's making the cache less efficient (Other than you won't be
> > able to cache that much), you're ending up breaking nginx
> > because when the keys_zone limit has been reached, nginx simply
> > starts returning 500 internal server error for items that are
> > not already in proxy_cache - if it would do an LRU/LFU on the
> > keys - then yes, you could probably end up with a cache less
> > efficient.
>
> While 500 is possible in some cases, especially in configurations
> with many worker processes and high request concurrency, even in
> the worst case it's expected to happen at most for half of the
> requests, usually much less than that. Further, cache manager
> monitors the number of cache items in the keys_zone, cleaning
> things in advance, making 500 almost impossible in practice.
>
> If you nevertheless observe 500 being returned in practice, this
> might be the actual thing to focus on.
>
> [...]
>
> > Unless nginx very recently implemented that reaching keys_zone
> > limit, will start purging old cache - then no, it would still
> > break the nginx for non-cached requests (returning 500 internal
> > server error). If nginx has started to purge old things if the
> > limit is reached, then sure the attacker would still be able to
> > wipe out the cache.
>
> Clearing old cache items when it is not possible to allocate a
> cache node dates back to initial cache support in nginx 0.7.44[1].
> And cache manager monitoring of the keys_zone and clearing it in
> advance dates back to nginx 1.9.13 released about five years
> ago[2]. Not sure any of these counts as "very recently".
>
> > But let's say we have an "inactive" set to 24+ hours (Which is
> > often used for static files) - an attack where someone would
> > append random query strings - those keys would first be removed
> > after 24 hours (or higher, depending on the limit) - with a
> > separate flag, one could set this counter to something like 60
> > seconds (So delete the key from memory if the key haven't
> > reached it's min_uses within 60 seconds) - this way, you're
> > still rotating those keys out *a lot* faster.
>
> While this may be preferable for some use cases (and sounds close
> to the "Segmented LRU" cache policy[3]), this certainly don't
> protect from the attack you've initially described. As previously
> suggested, an attacker can easily request the same resource
> several times, moving it to the "normal" category, so it will stay
> in the cache for 24+ hours you've configured. So instead this
> distinction might make things worse, making it harder for actually
> requested resources to get into cache.
>
> > > In particular, this can be done with limit_req
> >
> > If we'd limit this to 20 req/s, this would allow a single IP to
> > use up 1.78 million keys in the keys_zone if "inactive" is 24
> > hours - do this with 10 IPs, we're at 17.8 million.
>
> The basic idea of burst-based limiting the limit_req module
> implements is that you don't need to set high rates for IP
> addresses. Rather, you have to configure something you expect to
> be seen on average per hour (or even day), and allow large enough
> bursts. So instead of limiting to 20 r/s you can limit to 1 r/m
> with burst set to, say, 1000.
>
> [...]
>
> [1] http://hg.nginx.org/nginx/rev/3a8a53c0c42f#l19.478
> [2] http://hg.nginx.org/nginx/rev/c9d680b00744
> [3]
> https://en.wikipedia.org/wiki/Cache_replacement_policies#Segmented_LRU_(SLRU)
>
> --
> Maxim Dounin
> http://mdounin.ru/
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 18 May 2021 07:29:20 +0530
> From: Amila Gunathilaka <amila.kdam at gmail.com>
> To: nginx at nginx.org, nginx-request at nginx.org
> Subject: Help: Using Nginx Reverse Proxy bypass traffic in to a
> application running in a container
> Message-ID:
> <CALqQtdzar46fDhYTGOkbjAn0vhUeG3HWpYAxK9m=
> 0NegXm2WXg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> >
> > Hello All !
>
>
> I have nginx installed on my linux host and* listen on http port 80* and I
> want to bypass external traffic coming from external load balancer
> (up-stream server) into my *nginx reverse proxy server (80 port) *and want
> to bypass that http traffic into y application running in a docker
> container (application host port 9091),
>
> But my nginx configuration file didn't work as it always says *405 method
> not allowed* error when request passing from nginx into the external load
> balancer (up-stream server).
>
> Is anyone familiar with this kind of problem? my nginx configuration file
> is below.
>
> http {
> server {
> listen 80 proxy_protocol;
> #listen [::]:80 proxy_protocol;
> server_name 172.25.234.105;
> set_real_ip_from 172.25.234.2;
> real_ip_header proxy_protocol;
>
> location / {
> proxy_pass http://127.0.0.1:9091;
> #proxy_http_version 1.1;
> proxy_set_header Upgrade $http_upgrade;
> proxy_set_header Connection 'upgrade';
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $proxy_protocol_addr;
> proxy_set_header X-Forwarded-For $proxy_protocol_addr;
> proxy_cache_bypass $http_upgrade;
> auth_basic "PROMETHEUS PUSHGATEWAY Login Area";
> auth_basic_user_file /etc/nginx/.htpasswd;
> }
> }
> }
>
> --
> Amila
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.nginx.org/pipermail/nginx/attachments/20210518/f4d248f5/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 18 May 2021 07:02:08 -0400
> From: "hkaroly" <nginx-forum at forum.nginx.org>
> To: nginx at nginx.org
> Subject: How to spawn fastcgi c++ app on windows?
> Message-ID:
> <
> 88445089077dd6ece3a75d7d5ba882fc.NginxMailingListEnglish at forum.nginx.org>
>
> Content-Type: text/plain; charset=UTF-8
>
> I followed
> http://chriswu.me/blog/writing-hello-world-in-fcgi-with-c-plus-plus/ to
> create a C++ fastcgi server app together with nginx. On linux is working
> fine.
>
> On Windows 10 however the server process is started by spawn-fcgi but later
> the FCGI_Accept_r() will return with an "Unkown listenType" internal error.
> I have the suspicion that spawn-fcgi is broken on Windows since the very
> same c++ build is working fine with apache. In case of apache there is no
> need to use spawn-fcgi , it can spawn the fastcgi process by it's own. I
> think spawn-fcgi is not forwarding the standard input/output and the
> standard error.
>
> I used Cygwin to build spawn-fcgi on windows.
>
> Is there an alternative to spawn-fcgi on windows ?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?2,291545,291545#msg-291545
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 18 May 2021 16:44:26 +0530
> From: Anoop Alias <anoopalias01 at gmail.com>
> To: Nginx <nginx at nginx.org>
> Subject: net::ERR_HTTP2_SERVER_REFUSED_STREAM
> Message-ID:
> <CAO6TEX3pfPNak23mbLu9fLKsz2uE4XU-70J1O=
> OnJwvexiFiUg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> Browser consoles are showing error net::ERR_HTTP2_SERVER_REFUSED_STREAM and
> resources are not loading when enabling http2 ( see attached screenshot)
>
> The error go away when http2 is disabled
>
> #################################################
> [root at vps ~]# nginx -V
> nginx version: nginx/1.19.10
> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
> built with OpenSSL 1.1.1k 25 Mar 2021
> TLS SNI support enabled
> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
> --modules-path=/etc/nginx/modules --with-pcre=./pcre-8.44 --with-pcre-jit
> --with-zlib=./zlib-1.2.11 --with-openssl=./openssl-1.1.1k
> --with-openssl-opt=enable-tls1_3 --conf-path=/etc/nginx/nginx.conf
> --error-log-path=/var/log/nginx/error_log
> --http-log-path=/var/log/nginx/access_log --pid-path=/var/run/nginx.pid
> --lock-path=/var/run/nginx.lock
> --http-client-body-temp-path=/dev/shm/client_temp
> --http-proxy-temp-path=/dev/shm/proxy_temp
> --http-fastcgi-temp-path=/dev/shm/fastcgi_temp
> --http-uwsgi-temp-path=/dev/shm/uwsgi_temp
> --http-scgi-temp-path=/dev/shm/scgi_temp --user=nobody --group=nobody
> --with-http_ssl_module --with-http_realip_module
> --with-http_addition_module --with-http_sub_module --with-http_dav_module
> --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module
> --with-http_gzip_static_module --with-http_random_index_module
> --with-http_secure_link_module --with-http_stub_status_module
> --with-http_auth_request_module --with-file-aio --with-threads
> --with-stream --with-stream_ssl_module --with-http_slice_module
> --with-compat --with-http_v2_module
>
> --add-dynamic-module=/usr/local/rvm/gems/ruby-2.6.6/gems/passenger-6.0.7/src/nginx_module
> --add-dynamic-module=echo-nginx-module-0.61
> --add-dynamic-module=headers-more-nginx-module-0.32
> --add-dynamic-module=ngx_http_redis-0.3.8
> --add-dynamic-module=redis2-nginx-module
> --add-dynamic-module=srcache-nginx-module-0.31
> --add-dynamic-module=ngx_devel_kit-0.3.0
> --add-dynamic-module=set-misc-nginx-module-0.31
> --add-dynamic-module=ngx_http_geoip2_module
> --add-dynamic-module=testcookie-nginx-module --with-cc-opt='-O2 -g -pipe
> -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
> --with-ld-opt=-Wl,-E
> ######################################################
>
> I had enabled debug logging, but it is hard to decipher for me the exact
> cause
> from the debug log
>
> I am using the latest nginx so https://trac.nginx.org/nginx/ticket/2155 is
> ruled out as well
>
> Debug log -- https://autom8n.com/nginx_debug.txt
>
> Any help is much appreciated
>
> --
> *Anoop P Alias*
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.nginx.org/pipermail/nginx/attachments/20210518/20362cc2/attachment.htm
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: x2.png
> Type: image/png
> Size: 146746 bytes
> Desc: not available
> URL: <
> http://mailman.nginx.org/pipermail/nginx/attachments/20210518/20362cc2/attachment.png
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
> ------------------------------
>
> End of nginx Digest, Vol 139, Issue 19
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20210519/ee892044/attachment-0001.htm>
More information about the nginx
mailing list