On Thu, Jun 18, 2020 at 5:04 PM lists <lists@lazygranch.com> wrote:
> In theory not a problem, but look at the text on this page about placing
> root in location blocks.
>
> https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
>
> I saw your first post and thought it was entertaining. Somebody needs to
> annoy those hackers. Since I don't use php I trap those requests in a map
> and return a 444. That way I can use some scripts and pull the hacker IPs
> out of the log file. If they come from a server, the IP space of that host
> gets blocked. There are no eyeballs at servers. But I do like the idea of
> feeding the hacker something unpleasant.
>
>
If you have enough resources you can send them a 200 OK response with 10MB
html file with an enormous DOM tree using chunked transfer and no
content-length header. They will lost huge amount of resources to download
and parse this (probably multiple times).
On Thu, Jun 18, 2020 at 5:04 PM lists <lists@lazygranch.com> wrote:
> In theory not a problem, but look at the text on this page about placing
> root in location blocks.
>
> https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
>
> I saw your first post and thought it was entertaining. Somebody needs to
> annoy those hackers. Since I don't use php I trap those requests in a map
> and return a 444. That way I can use some scripts and pull the hacker IPs
> out of the log file. If they come from a server, the IP space of that host
> gets blocked. There are no eyeballs at servers. But I do like the idea of
> feeding the hacker something unpleasant.
>
>
>
>
>
> Original Message
>
>
> From: pizwer88@wp.pl
> Sent: June 18, 2020 4:08 AM
> To: nginx@nginx.org
> Reply-to: nginx@nginx.org
> Subject: Nginx potentially leaking real filenames? (hopefully properly
> formatted)
>
>
> Hi,
>
> I am experimenting with various ways of annoying bots and automated
> vulnerability scanners that reach my service. In one instance I am
> serving a recursive decompression bomb for all requests for .php files.
> Since none of my services run PHP, and never have, all such traffic can
> be safely assumed malicious.
> Recently (a couple of months since first deployment) I started seeing
> repeated requests to the server trying to fetch the recursive
> decompression bomb by its real file name, which should have never been
> exposed anywhere.
>
> Is it possible for nginx to leak the real file name? Through
> misconfiguration or other means?
>
> I am using nginx (version 1.14.2-2+deb10u1) as a reverse proxy and for
> SSL termination.
> The custom application behind it is not aware of the existence of the
> decompression bomb and lives in its own completely separate directory
> tree. It never reads nor serves any files from the local server, all its
> data is in physically separate database and cache servers. While I
> cannot prove absence of vulnerabilities in this custom app, I have not
> found any evidence of it being used to (nor leaking) local directory
> contents.
> The decompression bomb does not contain its file name in its contents.
>
> Given the above, I believe something in my nginx setup leaked the real
> file name of the decompression bomb.
> I've tried using all request methods (GET, HEAD, PUT, POST, DELETE,
> CONNECT, OPTIONS, TRACE, PATCH) on the server from curl like following:
> $ curl --verbose -X <method> <redacted>.com/index.php
> and (as expected) none of the responses leaked the file name in any of
> the headers nor contents.
>
> Below is a redacted and inlined version of my nginx configuration. There
> is only one server defined, the Debian default server config has been
> removed. The error code mapping is there to avoid triggering high error
> rate alerts when hit by hundreds of consecutive bot requests.
> I would appreciate any help in figuring out what I am doing wrong and
> how could the <redacted-payload-filename> have been leaked?
>
> Thanks,
> Pizab
>
> # nginx.conf
> http {
> sendfile on;
> tcp_nopush on;
> tcp_nodelay on;
> keepalive_timeout 165;
> types_hash_max_size 2048;
>
> include /etc/nginx/mime.types;
> default_type application/octet-stream;
>
> limit_req_zone "php" zone=attackzone:10m rate=1r/s;
>
> ssl_certificate <redacted>;
> ssl_certificate_key <redacted>;
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
> ssl_session_cache shared:SSL:10m;
> ssl_session_timeout 10m;
>
> server_tokens off;
>
> access_log /var/log/nginx/access.log;
> error_log /var/log/nginx/error.log;
>
> client_body_buffer_size 1M;
>
> server {
> listen 443 default_server ssl;
> listen 80;
>
> server_name <redacted>.com;
> rewrite_log on;
>
> location /.well-known/acme-challenge {
> alias /var/www/html/.well-known/acme-challenge;
> }
>
> location / {
> access_log /<redacted>/logs/nginx_access.log;
> proxy_set_header Host $http_host;
> proxy_redirect off;
> proxy_connect_timeout 60;
> proxy_read_timeout 160;
> proxy_pass http://localhost:10000;
> }
>
> error_page 429 =229 /error429;
>
> location ~ \.php$ {
> limit_rate_after 1k;
> limit_rate 2k;
> limit_req zone=attackzone burst=2;
> limit_req_status 429;
> keepalive_timeout 0;
> root /var/www/html/<redacted>/;
> default_type "application/xml";
> add_header Content-Encoding "br";
> try_files /<redacted-payload-filename> =400;
> }
>
> location = /error429 {
> return 229 "Too many requests.";
> }
> }
> }
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
