nginx - Come impedire l'elaborazione delle richieste con nomi di server non definiti con HTTPS

Question

nginx - Come impedire l'elaborazione delle richieste con nomi di server non definiti con HTTPS

#1 da (11 voti)
#2 da (9 voti)
#3 da (4 voti)
#4 da (0 voti)

15

Come evitare che nginx elabori una richiesta con un nome server indefinito utilizzando il protocollo https.

La seguente configurazione rende questo lavoro per normali richieste http. Reimposta la connessione per le richieste con host headers vuoto che equivale a server_name nella configurazione di nginx:

server {
    listen      80;
    server_name "";
    return      444;
}

Aggiornato per chiarezza:

Il server, tuttavia, fornisce html del blocco server di supporto ssl predefinito quando viene inviata una richiesta su https con host header vuota. Come può essere evitato?

Vorrei ottenere il comportamento esatto delle richieste http con host header vuoto - non html servito, reset della connessione (restituisce 444).

Quale sarebbe il modo corretto per bloccare tali richieste https e ottenere il comportamento menzionato anche per le connessioni https? (Vorrei evitare di usare il certificato SSL corretto per questo, poiché questo potrebbe solo suggerire agli spammer il vero dominio del server.)

Aggiornamento 13.03.2015

Mettere un haproxy davanti a nginx con l'impostazione

strict-sni

risolto completamente il problema.

nginx tls web-scanners

posta binaryanomaly 14.04.2014 - 23:15

fonte

4 risposte

9

A causa della natura di come funziona SSL, l'handshake SSL / TLS viene eseguito prima che il nome host previsto sia dato al server web. Ciò significa che il certificato (primo) predefinito viene utilizzato quando si tenta di accedere al sito, indipendentemente dal nome di dominio utilizzato.

Questo vale sia per Apache che per Nginx.

Dal Wiki di Apache :

As a rule, it is impossible to host more than one SSL virtual host on the same IP address and port. This is because Apache needs to know the name of the host in order to choose the correct certificate to setup the encryption layer. But the name of the host being requested is contained only in the HTTP request headers, which are part of the encrypted content. It is therefore not available until after the encryption is already negotiated. This means that the correct certificate cannot be selected, and clients will receive certificate mismatch warnings and be vulnerable to man-in-the-middle attacks.

Dalla documentazione di nginx :

With this configuration a browser receives the default server’s certificate, i.e. www.example.com regardless of the requested server name. This is caused by SSL protocol behaviour. The SSL connection is established before the browser sends an HTTP request and nginx does not know the name of the requested server. Therefore, it may only offer the default server’s certificate.

Come puoi risolvere questo problema?

La soluzione più semplice è utilizzare indirizzi IP separati per ogni sito che desideri proteggere.

Se ciò non è possibile, potrebbe essere possibile risolvere il problema utilizzando Indicazione del nome del server (SNI, RFC 6066 ). Ciò consente a un browser di passare il nome di dominio al server durante l'handshake.

Sia Nginx che Apache supportano SNI. Puoi scoprire di più su nginx SNI nella documentazione .

Vale la pena notare che SNI può essere utilizzato solo per i nomi di dominio e non per gli indirizzi IP. Quando si configura il server Web è necessario adottare ulteriori precauzioni per risolvere il problema, pertanto qualsiasi richiesta relativa all'IP viene gestita correttamente.

Only domain names can be passed in SNI, however some browsers may erroneously pass an IP address of the server as its name if a request includes literal IP address. One should not rely on this.

Il Wiki di Apache ha ulteriori informazioni sull'implementazione di SNI . Ma anche la loro documentazione consiglia che questa soluzione non è perfetta.

Using name-based virtual hosts with SSL adds another layer of complication. Without the SNI extension, it's not generally possible (though a subset of virtual host might work). With SNI, it's necessary to consider the configuration carefully to ensure security is maintained.

Detto questo, puoi vedere come questa configurazione non è semplice come i normali host virtuali. Per trovare una soluzione al tuo problema, dovremmo conoscere maggiori dettagli sulla tua configurazione e il comportamento previsto quando viene inviata una richiesta solo IP.

Generalmente, per "bloccare" un dominio non configurato o una richiesta IP, devi configurarlo come sito predefinito e quindi visualizzare un errore, reindirizzare, uscire, ecc.

risposta data 26.04.2014 - 12:21

fonte

4

Se capisco che vuoi negare le richieste HTTP, che non contengono un'intestazione Host, anche se queste richieste si trovano all'interno di una connessione SSL (ad esempio https-Requests). Si tratta di richieste HTTP / 1.0 di vecchio stile, HTTP / 1.1 richiede un'intestazione Host ma anche la maggior parte dei client HTTP / 1.0 ne invia uno. Il blocco di questi client può essere fatto con:

    if ( $http_host = '' ) {
            return 444;
    }

Ma questo non aiuta se il client usa un'intestazione Host con junk o l'indirizzo IP al suo interno. Quindi sarebbe meglio verificare che l'intestazione host contenga i valori attesi (come bonus aiuta anche contro gli attacchi di rebinding DNS), ad es.

    if ( $http_host !~* ^(example\.com|www\.example\.com)$ ) {
            return 444;
    }

risposta data 26.04.2014 - 16:51

fonte

0

Ho usato il metodo simile a @int_ua menzionato, ma un po 'complicato.

Ho configurato il mio nginx per utilizzare RSA e ECDSA come metodo di autenticazione TLS, ma ho emesso un certificato DSA per il server predefinito.
Poiché non esiste una suite di crittografia disponibile, l'handshake TLS fallirebbe prima di servire qualsiasi pagina.
Penso che avrebbe lo stesso risultato di quello che hai configurato (HAproxy strict-sni) e credo che il mio metodo avrebbe prestazioni migliori.

Puoi visualizzare il risultato della mia configurazione:

Invalid SNI: https://207.246.127.148/
(You can configure your hosts to this IP address and view the result as well)
Valid SNI: https://cloud.jemmylovejenny.tk/
The Valid SNI link points to the same IP address as above

Vorrei dare la mia configurazione qui:

Configurazione SSL
(Ho usato un codice openssl uguale cipher in modo che le cifre siano un po 'strane ... Puoi anche rimanere la tua configurazione , ma ricorda che non contengono alcuna crittografia DSS!)

    #Protocols
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
    #
    #Key Exchange
    ssl_ecdh_curve X25519:P-256:P-384:P-224:P-521;
    ssl_dhparam /var/SSL/DH-param.pem;
    #
    #Cipher Suites
    ssl_ciphers "[TLS_AES_128_GCM_SHA256|TLS_CHACHA20_POLY1305_SHA256]:[TLS_AES_256_GCM_SHA384|TLS_AES_128_CCM_8_SHA256|TLS_AES_128_CCM_SHA256]:[ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305|ECDHE-RSA-AES128-GCM-SHA256|DHE-RSA-CHACHA20-POLY1305]:[ECDHE-ECDSA-AES256-GCM-SHA384|ECDHE-RSA-AES256-GCM-SHA384]:[ECDHE-ECDSA-AES128-SHA|ECDHE-RSA-AES128-SHA]:[ECDHE-ECDSA-AES256-SHA|ECDHE-RSA-AES256-SHA]:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA";
    ssl_prefer_server_ciphers on;

Configurazione server predefinita

##
# General
##
# Listen
listen 8080 default_server;
listen 8443 ssl spdy http2 default_server;
#
# Server Name
server_name _;

##
# SSL Settings
##
#
# Certificate
#  DSA
ssl_certificate /var/SSL/certificates/DEFAULT.dsa.crt;
ssl_certificate_key /var/SSL/keys/DEFAULT.dsa.key;

root /var/www/html/nginx/;

La chiave DSA viene generata da OpenSSL e il certificato viene emesso dalla mia PKI personale. Puoi usare questo certificato se vuoi.
(Questo certificato non verrebbe mai inviato dal server nginx, quindi tutto questo certificato, inclusi keylength e periodo valido non ha senso)

Certificato:

Chiave:

risposta data 02.08.2018 - 10:41

fonte

Leggi altre domande sui tag nginx tls web-scanners

È possibile non memorizzare le password localmente, del tutto? Quali sono i vantaggi dei moduli di sicurezza hardware quando le chiavi non sono memorizzate al loro interno?

score 11 · Accepted Answer

L'ho risolto generando un certificato falso che non rivela il nome di dominio e aggiungendolo come predefinito all'inizio della configurazione:

server {
    listen 443 default;
    server_name     _;

    ssl     on;
    ssl_certificate         /path/to/fake.crt;
    ssl_certificate_key     /path/to/fake.key;

    return 403;
}

E sì, richiede un nginx con supporto SNI (controlla nginx -V ).

Seguire su: Come creare un certificato SSL autofirmato per scopi di test