我在使用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/;
}
}
最佳答案 哇,很奇怪.
在nginx.conf文件中编辑(通常在基于Debian的系统上的/ etc / nginx中)
你可以通过告诉Nginx放弃它来绕过这个特定地址的请求尝试.
location ~ ^/home/ubuntu/my_apps/myapp/gunicorn.sock {
deny all;
}
或者您可以简单地否定来自此可疑用户代理的传入连接
if ($http_user_agent ~ (~*masscan)) {
return 444;
}