Full request line variable

Server NGINX
1

What 0.7.62 variable gives the full request line?
We need to defeat proxying attempts.
Here’s what we find in access logs:

Good: GET /valid HTTP/1.1
Evil: GET http://www.externaldomain.com/ HTTP/1.1

The proxy attempt should get a 444, but right now
redirects to our home page. We want to use 444
to conserve CPU and bandwidth. We use ^http
but it fails:

if ($request_uri ~* (^http.*|.proxy.) ) {
return 444;
}

2

Hi,

Add this virtual server to your configuration file:

server {
listen 80;
server_name ~.proxy.;

        return 444;

}

On Sat, Sep 19, 2009 at 10:02 AM, [email protected] wrote:

but it fails:

Cheers,

3

On Sat, Sep 19, 2009 at 02:02:02AM +0000, [email protected] wrote:

What 0.7.62 variable gives the full request line?

$request_uri

if ($request_uri ~* (^http.*|.proxy.) ) {
return 444;
}

You should use default server.

4

On Sat, Sep 19, 2009 at 10:54:12AM +0800, Joshua Z. wrote:

Hi,

Add this virtual server to your configuration file:

server {
listen 80;
server_name ~.proxy.;

        return 444;

}

It’s better to set default server to handle all not your names:

server {
listen 80 default;
server_name ; # "" is nonexistant DNS name
return 444;
}

server {
listen 80;
server_name www.main.name
“” # this server will also handle requests
# without Host at all
;
…
}

5

Igor,

Thank you, but I believe the answers were given too fast.

(0) We already considered default servers
(1) $request_uri is not the actual, full, HTTP request line
(2) nginx has NO way to match ^http after GET (that we found)
(3) I suggest a new variable,

$full_request_line =
FULL TRUE HTTP REQUEST LINE

  • INCLUDING GET/PUT/POST/HEAD VERB
  • INCLUDING SCHEME
  • REGARDLESS OF SERVER BLOCK

That would be fully general.

We require that raw IP address reach our working server.
So http://1.2.3.4/ must work like http://goodhostname.com/
and can’t go to a “_” 444 block as you suggest.

We already thought of that and tried it a long time ago.

But proxy attempts use http://1.2.3.4 too, so they can only be
defeated with regular expressions. In nginx, this matching is
nearly impossible, because of hidden assumptions in the
software.

Please consider $full_request_line for future improvement,
thank you. Nginx is excellent and we appreciate your work.

6

On Sat, Sep 19, 2009 at 07:17:15PM -0700, Wohbah wrote:

$full_request_line =
and can’t go to a “_” 444 block as you suggest.

We already thought of that and tried it a long time ago.

But proxy attempts use http://1.2.3.4 too, so they can only be
defeated with regular expressions. In nginx, this matching is
nearly impossible, because of hidden assumptions in the
software.

Please consider $full_request_line for future improvement,
thank you. Nginx is excellent and we appreciate your work.

Sorry, I mistaked: $request_uri is just URI part.
The required variable aleady exists: $request and it’s usually used
in access_log.

7

Yes, that’s it - thanks!

The variable is missing from English documentation.
All the other $request_XYZ variables are there, but
not the main one!

Please add it!

http://wiki.nginx.org/NginxHttpCoreModule#Variables