Constant Invalid HTTP_HOST header spam

[Jon Ribbens]

I'm getting spammed with constant "Invalid HTTP_HOST header: '10.9.8.7:443'. You may need to add '10.9.8.7' to ALLOWED_HOSTS" emails, due to the Internet being the Internet. How can I disable these emails, without turning off error emails completely? I don't particularly want to add the IP address to the ALLOWED_HOSTS. It seems to me this email shouldn't be being generated if the HTTP_HOST value is an IP literal.

[Antonis Christofides]

Hello Jon,

the documentation describes how to silence this error at https://docs.djangoproject.com/en/2.0/topics/logging/#django-security.

How have you deployed your Django project? I always configure Apache or nginx in such a way so that such invalid requests never reach Django.

Regards,

Antonis

Antonis Christofides
http://djangodeployment.com

On 2017-12-18 21:44, Jon Ribbens wrote:

I'm getting spammed with constant "Invalid HTTP_HOST header: '10.9.8.7:443'. You may need to add '10.9.8.7' to ALLOWED_HOSTS" emails, due to the Internet being the Internet. How can I disable these emails, without turning off error emails completely? I don't particularly want to add the IP address to the ALLOWED_HOSTS. It seems to me this email shouldn't be being generated if the HTTP_HOST value is an IP literal.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0f07d6ca-626c-4887-86e5-a5d10190bc49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jon Ribbens]

On 18 Dec 2017, at 23:26, Antonis Christofides <ant...@djangodeployment.com> wrote:

the documentation describes how to silence this error at https://docs.djangoproject.com/en/2.0/topics/logging/#django-security.

It’s not obvious from that how to silence it only for IP literals. I’d still like to receive it for actual unknown hosts.

How have you deployed your Django project? I always configure Apache or nginx in such a way so that such invalid requests never reach Django.

A couple of weeks. The nginx configuration idea is a good one, although I was trying to allow the site to work without SNI, but it’s probably not vital.

[Antonis Christofides]

I may be wrong of course, but I don't recall SNI having anything to do with it. Just using something like

server {
    listen 80;
    listen 443 ssl;
    server_name my.django.site.com;
    ...
}

will only send requests for my.django.site.com to the django project. I really don't know about SNI, but I recall having used SSL on Apache before SNI existed and I don't remember any difference with respect to that. Why does SNI affect this?

Regards,

Antonis

Antonis Christofides
http://djangodeployment.com

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/11A18532-A2F4-4F02-AA24-9B6AD9C90DE2%40gmail.com.

[Jon Ribbens]

On Tuesday, 19 December 2017 07:24:23 UTC, Antonis Christofides wrote:

I may be wrong of course, but I don't recall SNI having anything to do with it. Just using something like

server {
    listen 80;
    listen 443 ssl;
    server_name my.django.site.com;
    ...
}

will only send requests for my.django.site.com to the django project. I really don't know about SNI, but I recall having used SSL on Apache before SNI existed and I don't remember any difference with respect to that. Why does SNI affect this?

Because unless I'm misremembering something, if you don't add default_server to the listen directive then requests without SNI will not end up being served the desired SSL certificate, but if you do add default_server then requests with the wrong/missing/IP-literal Host: header will end up going to Django, which is what we wanted to avoid.

I guess I'll just have to decide which of lack-of-SNI support and alerting-on-wrong-Host I want to lose.

[Daniel Hepper]

From my understanding, deciding which certificate to use and actually serving the request are two separate step in Nginx.

I assume you only have one valid domain name you want to serve. Every other HTTPS request will result in a certificate warning and should be rejected. You could try a configuration like this:

server {
    listen 80;
    listen 443 ssl;
    server_name my.django.site.com

;
    ssl_certificate /path/to/my.django.site.com.cert;

    ssl_certificate_key /path/to/my.django.site.com.key;

    ... # serve the request with your Django app
}

server {
    listen 80 default_server;
    listen 443 default_server ssl;
    server_name _;
    ssl_certificate /path/to/my.django.site.com.cert;

    ssl_certificate_key /path/to/my.django.site.com.key;

    return 444; # reject the request
}

This should ensure that only requests with valid Host headers reach your application while still supporting Non-SNI clients. You can test it with "open_ssl client" or "gnutls-cli":

$ gnutls-cli --disable-sni my.django.site.com

...

- Simple Client Mode:

GET / HTTP/1.0

Host: my.django.site.com

...your site...

$ gnutls-cli --disable-sni my.django.site.com

...

- Simple Client Mode:

GET / HTTP/1.0

Host: foobar.com

- Peer has closed the GnuTLS connection

Note that you won't receive any emails for unknown hosts anymore, as those requests never reach your Django app, as it should be. If you still want to keep an eye on those requests, you could configure logging in the default server block.

Hope that helps,

Daniel

[Jon Ribbens]

On Tuesday, 19 December 2017 13:37:06 UTC, Daniel Hepper wrote:

This should ensure that only requests with valid Host headers reach your application while still supporting Non-SNI clients. You can test it with "open_ssl client" or "gnutls-cli":

Yes, that looks good to me. Many thanks! 

[Dylan Reinhold]

John,

  You could set the logger to send all DisallowedHost errors to a log file, then just check it ever so often for the bad domains you are looking for. Or better yet have a daily script email them to you (you can exclude your IPs then)

Dylan

--

You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/88236646-9f3c-4984-a6d6-970d024b235b%40googlegroups.com.

[Antonis Christofides]

So nginx chooses the "server {}" block that contains "default_server" to choose the SSL certificate, and after it receives the headers it choose another "server {}" block as needed? If that is the case, you can create another "server {}" block with "default_server" (usually this is somewhere like /etc/nginx/sites-available/default) that shall contain the certificate and always return 404.

Regards,

Antonis

Antonis Christofides
http://djangodeployment.com

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/bf3e62f2-2584-4a28-8680-5cb83dd88753%40googlegroups.com.