Nginx inoltra host indesiderati a Django

3

Ho ricevuto degli errori da Django sul mio server web (dietro Nginx / uWSGI) lamentandomi che è possibile accedervi con una richiesta in cui Host è l'indirizzo IP del server. Nginx usa gli host virtuali quindi mi aspetto che Host sia sempre il nome del server, quindi il ALLOWED_HOSTS di Django è proprio questo.

Invalid HTTP_HOST header: '###.###.###.###'. You may need to add '###.###.###.###' to ALLOWED_HOSTS.

Request repr():
<WSGIRequest
path:/,
GET:<QueryDict: {}>,
POST:<QueryDict: {}>,
COOKIES:{},
META:{'CONTENT_LENGTH': '',
 'CONTENT_TYPE': '',
 'DOCUMENT_ROOT': '/usr/share/nginx/html',
 'HTTP_HOST': '###.###.###.###',
 'PATH_INFO': '/',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '184.105.139.68',
 'REMOTE_PORT': '45409',
 'REQUEST_METHOD': 'GET',
 'REQUEST_URI': '/',
 'SCRIPT_NAME': '',
 'SERVER_NAME': 'subdomain.example.net',
 'SERVER_PORT': '443',
 'SERVER_PROTOCOL': 'HTTP/1.1',
 'UWSGI_SCHEME': 'https',
 'uwsgi.core': 1,
 'uwsgi.node': b'subdomain.example.net',
 'uwsgi.version': b'2.0.12',
 'wsgi.errors': <_io.TextIOWrapper name=2 mode='w' encoding='ANSI_X3.4-1968'>,
 'wsgi.file_wrapper': <built-in function uwsgi_sendfile>,
 'wsgi.input': <uwsgi._Input object at 0x7f...>,
 'wsgi.multiprocess': True,
 'wsgi.multithread': True,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'https',
 'wsgi.version': (1, 0)}>

Gli errori sono attivati da 184.105.247.195, 1 o 2 al giorno, che è di proprietà di "Shadowserver Foundation", quindi non sono sicuro che questi attacchi (simulati) vengano contrastati con successo (ma mi infastidiscono con un errore codice) o se qualcosa di estraneo sta succedendo ... come come / perché Nginx sta passando una richiesta con un IP Host a un blocco server che è del seguente formato (ho un blocco server catch-all che rifiuta Host- meno richieste):

server {
    listen 443;
    server_name abc.example.net;
    # ...
}

Questa risposta SO mi dice come configurare Nginx per rifiutare richieste malformate (errata Host intestazione), ma che sembra come un approccio con cintura e bretelle.

Questo indizio della mia cintura non viene chiuso correttamente mentre qualcuno sta cercando di mettermi nei pantaloni?

Come appendice, sta usando SSL (e sto ospitando più siti SSL sulla stessa porta, usando SNI per distinguerli, non sono sicuro che sia importante ...). Un po 'come questa risposta (ad un'altra domanda) cita , l'"attacco" consiste nel negoziare con uno dei Nginx blocchi di server, quindi nella richiesta crittografata cambiando l'intestazione Host sull'IP del mio server?

    
posta Nick T 23.03.2016 - 23:18
fonte

1 risposta

1

Il problema era causato da Nginx che utilizzava il mio host Django come predefinito, quindi una richiesta " collegamento " era stata delegata ad essa. La soluzione era aggiungere un server predefinito. Il valore predefinito viene utilizzato quando nessun altro server %% di blocco del blocco non corrisponde alla richiesta. È scelto da Nginx come:

  1. Un server server_name ing sulla porta (e indirizzo, se specificato) con la proprietà listen
  2. Altrimenti, il primo blocco del server nella configurazione.

Ho modificato il file default_server principale per includere blocchi server impliciti predefiniti che

  • reindirizza HTTP a qualsiasi host "predefinito" dovrebbe essere per il server o
  • chiudi le richieste HTTPS ai nomi host non validi.

Quest'ultimo non ha alcun impatto sugli utenti perché è impossibile ottenere un certificato valido per un indirizzo IP. È solo uno strano crawler / client che fa il giro degli host IP, ignorando la validità del certificato per qualche strano motivo, che viene scaricato.

server {
    # Redirect IP request to primary host
    listen 80;
    return 301 https://defaulthost.example.com/;
}
server {
    # Terminate any HTTPS connections made with the IP address as host
    # (or any other unrecognized host).
    listen 443;
    server_name _;

    ssl on;
    # this is just a self-signed cert; there needs to be 
    # a well-formed one for nginx to start
    ssl_certificate /srv/ssl/sham.cer;
    ssl_certificate_key /srv/ssl/sham.key;

    return 444;
}
    
risposta data 15.11.2016 - 21:19
fonte

Leggi altre domande sui tag