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-requ...@nginx.org> wrote: > Send nginx mailing list submissions to > nginx@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-requ...@nginx.org > > You can reach the person managing the list at > nginx-ow...@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 <mdou...@mdounin.ru> > To: nginx@nginx.org > Subject: Re: Memory usage in nginx proxy setup and use of min_uses > Message-ID: <ykmx5jsb+qr1o...@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.k...@gmail.com> > To: nginx@nginx.org, nginx-requ...@nginx.org > Subject: Help: Using Nginx Reverse Proxy bypass traffic in to a > application running in a container > Message-ID: > <CALqQtdzar46fDhYTGOkbjAn0vhUeG3HWpYAxK9m= > 0negxm2...@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-fo...@forum.nginx.org> > To: nginx@nginx.org > Subject: How to spawn fastcgi c++ app on windows? > Message-ID: > < > 88445089077dd6ece3a75d7d5ba882fc.nginxmailinglistengl...@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 <anoopalia...@gmail.com> > To: Nginx <nginx@nginx.org> > Subject: net::ERR_HTTP2_SERVER_REFUSED_STREAM > Message-ID: > <CAO6TEX3pfPNak23mbLu9fLKsz2uE4XU-70J1O= > onjwvexif...@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@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@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > > ------------------------------ > > End of nginx Digest, Vol 139, Issue 19 > ************************************** >
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx