Django + Nginx + Gunicorn设置的外部IP错误

时间:2016-05-24 14:56:31

标签: django security nginx gunicorn

我在使用Django + Gunicorn + Nginx的生产环境中遇到了一个奇怪的错误,应用程序似乎运行良好,但我至少得到了这个错误:

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)}>

似乎这些错误是由外部攻击尝试触发的,但我对于为什么他们能够在HTTP HOST头中注入运行我的Django应用程序的套接字的确切位置一无所知。关于如何避免此错误的任何想法,这是否会在我的网站上暴露出一个可能的漏洞?

编辑:

这是我的nginx配置文件:

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/;
    }
}

1 个答案:

答案 0 :(得分:2)

哇,很奇怪。

nginx.conf文件中进行修改(通常在基于Debian的系统上的/etc/nginx中)

你可以通过告诉Nginx放弃它来绕过这个特定地址的请求尝试。

location ~ ^/home/ubuntu/my_apps/myapp/gunicorn.sock {
            deny all;
}

或者您可以简单地否定来自此可疑用户代理的传入连接

if ($http_user_agent ~ (~*masscan)) {
 return 444;
}