Reputation: 1520
I've been getting a weird error on a production environment with Django + Gunicorn + Nginx, the application seems to be running fine but I'm getting this error at least dialy:
Invalid HTTP_HOST header: u'/home/ubuntu/my_apps/myapp/gunicorn.sock:'. The domain name provided is not valid according to RFC 1034/1035.
Request repr():
<WSGIRequest
path:/SiteMap.xml,
GET:<QueryDict: {}>,
POST:<QueryDict: {}>,
COOKIES:{},
META:{'HTTP_ACCEPT': '*/*',
'HTTP_CONNECTION': 'close',
'HTTP_USER_AGENT': 'masscan/1.0 (https://github.com/robertdavidgraham/masscan)',
'HTTP_X_FORWARDED_FOR': '94.102.48.193',
'PATH_INFO': u'/SiteMap.xml',
'QUERY_STRING': '',
'RAW_URI': '/SiteMap.xml',
'REMOTE_ADDR': '',
'REQUEST_METHOD': 'GET',
'SCRIPT_NAME': u'',
'SERVER_NAME': '/home/ubuntu/my_apps/myapp/gunicorn.sock',
'SERVER_PORT': '',
'SERVER_PROTOCOL': 'HTTP/1.0',
'SERVER_SOFTWARE': 'gunicorn/19.4.5',
'gunicorn.socket': <socket._socketobject object at 0x7f86b919d4b0>,
'wsgi.errors': <gunicorn.http.wsgi.WSGIErrorsWrapper object at 0x7f86b92d1650>,
'wsgi.file_wrapper': <class 'gunicorn.http.wsgi.FileWrapper'>,
'wsgi.input': <gunicorn.http.body.Body object at 0x7f86b92d19d0>,
'wsgi.multiprocess': True,
'wsgi.multithread': False,
'wsgi.run_once': False,
'wsgi.url_scheme': 'http',
'wsgi.version': (1, 0)}>
It does seem like these errors are triggered by external attack attempts but I'm clueless about why they'd be able to inject the exact location of the socket running my Django app in the HTTP HOST header. Any ideas about how this error can be avoided, is this exposing a likely vulnerability on my site?
This is my nginx config file:
upstream myapp {
# fail_timeout=0 means we always retry an upstream even if it failed
# to return a good HTTP response (in case the Unicorn master nukes a
# single worker for timing out).
server unix:/home/ubuntu/my_apps/myapp/gunicorn.sock fail_timeout=0;
}
server {
listen 80;
server_name 0.0.0.0;
client_max_body_size 4G;
access_log /home/ubuntu/my_apps/myapp/logs/nginx-access.log;
error_log /home/ubuntu/my_apps/myapp/logs/nginx-error.log;
location /static/ {
alias /home/ubuntu/my_apps/myapp/myapp/static/;
}
location /media/ {
alias /home/ubuntu/my_apps/myapp/myapp/media/;
}
location /socket.io/ {
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_pass http://localhost:8888;
}
location / {
# an HTTP header important enough to have its own Wikipedia entry:
# http://en.wikipedia.org/wiki/X-Forwarded-For
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# enable this if and only if you use HTTPS, this helps Rack
# set the proper protocol for doing redirects:
# proxy_set_header X-Forwarded-Proto https;
# pass the Host: header from the client right along so redirects
# can be set properly within the Rack application
proxy_set_header Host $http_host;
# we don't want nginx trying to do something clever with
# redirects, we set the Host: header above already.
proxy_redirect off;
# set "proxy_buffering off" *only* for Rainbows! when doing
# Comet/long-poll stuff. It's also safe to set if you're
# using only serving fast clients with Unicorn + nginx.
# Otherwise you _want_ nginx to buffer responses to slow
# clients, really.
# proxy_buffering off;
# Try to serve static files from nginx, no point in making an
# *application* server like Unicorn/Rainbows! serve static files.
if (!-f $request_filename) {
proxy_pass http://myapp;
break;
}
}
# Error pages
error_page 500 502 503 504 /500.html;
location = /500.html {
root /home/ubuntu/my_apps/myapp/myapp/static/;
}
}
Upvotes: 4
Views: 1148
Reputation: 1016
Wow, weird.
Edits to do in nginx.conf
file (usually in /etc/nginx
on Debian based systems)
You could just bypass this request attempt on this specific address by telling Nginx to drop it.
location ~ ^/home/ubuntu/my_apps/myapp/gunicorn.sock {
deny all;
}
Or you can simply negates incoming connections from this suspicious User-Agent
if ($http_user_agent ~ (~*masscan)) {
return 444;
}
Upvotes: 2