È sicuro impostare l'indirizzo IP per il reindirizzamento del nome di dominio?

From a security point of view, is it safe to redirect an http request for direct IP address to the domain name?

Sì, di solito non è un problema. se sei in modalità super-paranoica potresti seguire l'approccio di seguito.

Il traffico diretto all'IP, anche se ci sono nomi di domini registrati, di solito sono scanner e robot, e forse, ogni tanto, uno sviluppatore. I motori di ricerca non accedono direttamente agli IP, tranne quando non si dispone di nomi di dominio configurati.

Questo è un setup catch-all abbastanza legittimo per nginx che definisce una risposta ad ogni accesso che non è definito attraverso un virtual-server-conf (restituisce semplicemente lo stato HTTP 400):

server {

    listen 80 default_server;

    access_log off;
    error_log off;

    # basically just return an error
    return 400;

}

Non è un problema di sicurezza, ma è una cosa un po 'strana da fare. Complifica la configurazione ed è soggetto a errori se l'indirizzo IP dovesse cambiare o se si desidera passare a servizi basati su cloud. AFAIK questo non è una pratica standard per reindirizzare le ricerche degli indirizzi IP a un dominio.

Stai chiedendo una risposta dal punto di vista della sicurezza. Tuttavia, esiste più di un punto di vista della sicurezza a seconda del modello di minaccia che hai in mente.

Se il tuo modello di minaccia è un utente malintenzionato che tenta di compromettere il tuo server inviando richieste al tuo server, direi che non fa alcuna differenza nel modo in cui gestisci le richieste specificando un indirizzo IP nell'intestazione host piuttosto che in un nome di dominio.

È molto improbabile che la gestione aggiornata delle richieste con un indirizzo IP nell'intestazione dell'host ti possa aprire a nuovi modi di compromettere il server. E gli attacchi compromettenti contro l'intera applicazione sul nome di dominio primario funzionerebbero a prescindere, dal momento che l'autore dell'attacco può semplicemente inserire quel nome di dominio nell'intestazione host.

Se il tuo modello di minaccia è un utente malintenzionato che cerca di attirare gli utenti in una trappola fornendo loro collegamenti a nomi di dominio non ufficiali che puntano al tuo server, ricorda che un utente malintenzionato potrebbe ottenere lo stesso impostando un proxy sul proprio IP, che modifica l'intestazione dell'host prima di inviarti la richiesta e potrebbero apportare eventuali modifiche alle risposte prima di restituirle all'utente.

In quanto tale, non vi è alcun rischio significativo in quest'area. A meno che l'attaccante non stia tentando di eseguire un attacco di phishing. Il meglio che puoi fare per assicurarti che gli utenti non si innamorino di un attacco di phishing è avere solo un nome di dominio legittimo che devono essere in grado di riconoscere. Il reindirizzamento di tutte le richieste con un IP o un nome di dominio secondario nell'intestazione dell'host al dominio legittimo è un approccio user friendly a questo.

Tuttavia potrebbe essere un po 'troppo facile da usare. Dopo tutto, gli utenti non dovrebbero passare attraverso un URL usando IP o nome di dominio secondario in primo luogo. Quindi il reindirizzamento potrebbe portare a una situazione in cui non viene data sufficiente attenzione agli URL che non utilizzano il dominio appropriato, perché "funzionano". Se gli utenti si abituano a una varietà di domini e indirizzi IP utilizzati negli URL, quegli utenti saranno un obiettivo più facile per il phishing.

Avere i domini secondari e gli IP tutti generano un messaggio di errore che include un collegamento al dominio appropriato può aiutare a garantire che sia gli utenti sia gli sviluppatori siano consapevoli del fatto che gli URL dovrebbero contenere il dominio principale e nient'altro. La pubblicazione delle pagine di errore con un codice di errore 4xx appropriato produrrebbe risultati più prevedibili se qualsiasi software automatico accede a URL impropri. Tuttavia, pubblicare le pagine di errore con un codice di 200 potrebbe rendere più facile per i motori di ricerca trovare il contenuto in caso di link esterni al di fuori del tuo controllo, che capita di puntare all'IP o ai domini secondari.

Indipendentemente dal fatto che si utilizzi il codice 2xx, 3xx o 4xx per tali risposte, la configurazione più pulita per ottenerlo sarebbe un vhost separato nella configurazione del server web. Una risposta precedente fornisce un esempio di come questo potrebbe essere raggiunto. Altri server web possono farlo anche.

Un altro modello di minaccia da tenere a mente sono le richieste alla tua applicazione che cercano di indurre la tua applicazione a utilizzare un nome di dominio errato passato attraverso l'intestazione host in contenuto generato dinamicamente. Se il nome del dominio dall'intestazione dell'host viene utilizzato solo per generare una risposta alla richiesta che ha utilizzato un'intestazione dell'host errata in primo luogo, questa non è una preoccupazione importante. Tuttavia, se l'applicazione utilizza l'intestazione host per generare URL che verranno successivamente visualizzati nelle e-mail o nel database, questo è motivo di preoccupazione.

Come dipendente di una società che gestisce l'hosting, posso informarti che facciamo quanto segue per i nostri server di hosting.

Abbiamo una configurazione di base (virtuale) (virtuale) host che si riferisce a una pagina di caricamento veloce senza alcun contenuto reale. (come un banner con il nostro logo e un link al nostro sito web aziendale). Questo approccio ha diversi vantaggi.

• se un utente finale immette il nome URL errato ottiene un sito Web che carica rapidamente. Chiunque raccolga gli URL non occuperà gran parte delle risorse dei server
• Gli hacker che tentano di raccogliere usign solo l'IP non andranno da nessuna parte poiché il sito che sta ospitato non è un CMS / web app (che potrebbe essere vulnerabile).