Hello!

On Sat, Nov 09, 2013 at 09:44:52PM +0100, Ondrej Jombik wrote:

> Recently we have seen some kind of hacker attempt on our hosting
> servers, passing very long hostnames in the HTTP Host: header. That
> means length(hostname) was higher than 2000, for few requests even more
> than 10000.
>
> This was processed well by nginx, passed further to our upstreams, what
> caused only little trouble there: logs were filled with a lot of
> garbage.
>
> After bit of investigation, I have found that according to RFC, the
> longest domain name should not be more than 253 characters. Also,
> splitting domain into labels (labels are strings between dots), each
> label should not exceed 63 characters.
>
> For more info: http://en.wikipedia.org/wiki/Domain_Name_System
> (search for "Domain name syntax" part)
>
> That raises question how nginx handles this kind of long hostnames, and
> why it still pasess those invalid hostnames to backends (upstreams).

While DNS names are indeed limited to no more than 255 octets,
it's not a case for HTTP, which can be used with non-DNS names as
well.

> However it still passes it, and we want to filter that out. Because the
> performance matters us much, we want to do that the best possible way.
>
> CASE #1:
>
> if ($host ~* "^.{254,}$") {
> return 403;
> }
>
> CASE #2: (this is probably more efficient)
>
> server {
> server_name "~^.{254,}$";
> listen 80;
> return 403;
> }
>
> Case #2 is probably more efficient, but in both cases are regular
> expressions used.

Recommended use is to list valid names in a server_name
directives, and filter out anything else by using a default server
which returns an appropriate error.

Between the above two cases I would recommend case #2, mostly
because it's easier to support.

> Would it matter if we put that server {} block at the
> end of our server list?

As long as there are no other regexp server names in your
configuration - position doesn't matter, see
http://nginx.org/en/docs/http/server_names.html.

> Also would it make any sense to check for a dot (\.) in a server_name or
> $host, and when not dot is present, return 403 as well?

You may do so if your configuration assumes access via fully
qualified domain names only, and you are not hosting TLDs.
Otherwise it may cause problems. See here for details:

http://en.wikipedia.org/wiki/Fully_qualified_domain_name

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx