Il sito è accessibile all'indirizzo IP se non si segue la guida di installazione

Contribuisci Funzionalità
1

Per motivi di sicurezza, ritengo che sarebbe meglio se, per impostazione predefinita, i forum Discourse non siano visibili quando si naviga direttamente all’indirizzo IP tramite un browser.

Alcuni motivi:

  • Consente l’utilizzo del sito senza HTTPS, sia per gli utenti che per la configurazione iniziale da parte dell’amministratore.
  • Espone l’indirizzo del server di origine, il che è negativo se si utilizza Cloudflare o servizi simili per proteggere l’IP di origine da attacchi DDoS o tentativi di hacking del server, nel caso in cui gli hacker ritengano il server di alto valore. Ci sono persone che eseguono bot che scansionano tutti gli intervalli di IP posseduti dagli hosting provider.

Inoltre, l’installer di Discourse ora verifica che il dominio o sottodominio sia configurato correttamente; altrimenti non procede con l’installazione.

Tutto ciò che è necessario aggiungere alla fine del file /etc/nginx/conf.d/discourse.conf (all’interno del contenitore Docker) è:

server {
    listen 80;
    server_name 1.1.1.1;
    server_tokens off;
    return 404;
}

Dove 1.1.1.1 è l’indirizzo IP pubblico del tuo server. Probabilmente esiste un modo più elegante per includere l’indirizzo IP rispetto all’hardcoding. Ho provato alcune soluzioni, ma non sono riuscito a farle funzionare.

Funziona bene per me (incluso con il proxy di Cloudflare); non riesco a pensare a molti casi in cui consentire l’accesso web diretto tramite l’IP sia utile o necessario. Sembra una pratica abbastanza comune disabilitare questa possibilità. Sono comunque felice di ascoltare eventuali ragioni per cui non si dovrebbe fare questo!

1 Mi Piace
2

Perché apportare modifiche quando la nostra guida predefinita ti lascia con un sito funzionante solo in HTTPS?

Gli utenti con esigenze particolari possono intervenire manualmente, ma la nostra configurazione predefinita rimarrà invariata, impostando di default un nome di dominio funzionante e HTTPS.

9 Mi Piace
3

Grazie mille!

1 Mi Piace
4

Parlando oggettivamente, questa affermazione non è accurata. Non è solo HTTPS, poiché è possibile accedere al sito direttamente tramite l’indirizzo IP che non è HTTPS.

La differenza consiste nel disabilitare le connessioni non sicure senza HTTPS ed esporre l’IP di origine del server. Non sono a conoscenza di alcun vantaggio in tal senso.

Se si esegue una ricerca DNS sui primi 50 siti al mondo, sembra che nessuno di essi sia accessibile in modo non sicuro direttamente tramite l’IP. Non penso sia irragionevole assumere che i primi 50 siti al mondo stiano utilizzando le migliori pratiche.

Ecco una lista abbastanza accurata dei siti principali:

Ecco uno strumento per la ricerca DNS:

5

Di default, tentando di accedere tramite IP si ottiene un 301 Redirect verso il dominio corretto:

$ curl 159.203.68.6 -I
HTTP/1.1 301 Moved Permanently
Server: nginx/1.16.1
Date: Mon, 29 Jun 2020 20:24:41 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive
Location: https://falcoland.falco.dev/

La tua proposta è passare da un 301 a un 404?

3 Mi Piace
6

8 su 8 installazioni, effettuate utilizzando l’immagine di Digital Ocean, Communiteq (precedentemente DiscourseHosting) installata (e successivamente migrata) così come manualmente seguendo questa guida discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub sono tutte accessibili in modo non sicuro tramite IP per impostazione predefinita. Due di esse sono state installate nell’ultima settimana (utilizzando la guida GitHub sopra citata).

Forse manca un passaggio aggiuntivo? Direi che un 404 è meglio di un 301, dato che probabilmente la maggior parte delle persone che esplorano gli indirizzi IP non ha intenzioni buone. Tuttavia, un 301 è meglio di un accesso non sicuro.

7

Nessuna ripro..

http://38.242.24.122 reindirizza correttamente a https://discourse.codinghorror.com/

4 Mi Piace
8

Hmmm, forse è il template di Cloudflare. Probabilmente è l’unica differenza costante rispetto a un’installazione completamente vanilla tra tutti.

1 Mi Piace
9

Se hai intrapreso passaggi non elencati nell’installazione cloud, per definizione non si tratta di un’installazione “vanilla”.

Il template di Cloudflare non fa nulla di evidente per interferire con un reindirizzamento:

run:
  - file:
      path: /tmp/add-cloudflare-ips
      chmod: +x
      contents: |
        #!/bin/bash -e
        # Scarica l'elenco degli indirizzi IP di CloudFlare
        wget https://www.cloudflare.com/ips-v4/ -O - > /tmp/cloudflare-ips
        wget https://www.cloudflare.com/ips-v6/ -O - >> /tmp/cloudflare-ips
        # Trasforma in comandi nginx e scala per l'inserimento nel comando sed append
        CONTENTS=$(</tmp/cloudflare-ips sed 's/^/set_real_ip_from /' | sed 's/$/;/' | tr '\n' '\\' | sed 's/\\/\\n/g')
        
        echo Indirizzi IP di CloudFlare:
        echo $(echo | sed "/^/a $CONTENTS")
        # Inserisci in discourse.conf
        sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header CF-Connecting-IP;" /etc/nginx/conf.d/discourse.conf
        # Pulisci
        rm /tmp/cloudflare-ips

  - exec: "/tmp/add-cloudflare-ips"
  - exec: "rm /tmp/add-cloudflare-ips"

Estrae gli intervalli di indirizzi IP, li salva temporaneamente come cloudflare-ips e aggiunge il supporto per CF-Connecting-IP.

2 Mi Piace
10

Giusto. Non ho affermato che si trattasse di “installazioni vanilla”.

Quindi ho testato la rimozione del template ufficiale di Cloudflare su una di esse e poi la ricostruzione; purtroppo non ha fatto alcuna differenza. Rimane ancora accessibile in modo non sicuro tramite IP.

Non riesco davvero a pensare a nulla di insolito tra quelle installazioni. Gli unici plugin su quell’istanza erano il gestore Docker incluso di default e il plugin ufficiale per gli annunci. Si trova sul ramo stable, ma anche gli altri siti che presentano lo stesso comportamento sono su una combinazione di stable, beta e tests-passed.

11

Non specifico di alcuna configurazione, né di Cloudflare, ma solo un altro punto dati e un’altra prospettiva:

Possiamo impostare un proxy per reindirizzare un “indirizzo IP nudo sulla porta 80” (ad esempio) a qualsiasi altro FQDN in diversi modi, sia con Apache2 che con Nginx.

Esistono molti modi per farlo (rewrite e redirect, virtual host e redirect, ecc.).

Ad esempio, possiamo creare un virtual host su un reverse proxy con il reverse proxy in ascolto sull’indirizzo IP sulla porta 80, e reindirizzare tutte quelle richieste a qualsiasi FQDN (o indirizzo IP) scegliamo.

Possiamo farlo anche con un reverse proxy utilizzando mod_rewrite in Apache2 e regole di rewrite con Nginx.

Per tutte le nostre configurazioni di Discourse (in produzione), abbiamo un reverse proxy davanti a Discourse (alcuni Apache2, altri Nginx) ed è facile mitigare questo tipo di problemi (man mano che si presentano) configurando il reverse proxy per gestire queste problematiche e casi particolari.

Detto questo, non uso il caso particolare di cloudflare come proxy, ma sembra che qualsiasi proxy sia configurabile per gestire questo tipo di problemi, proprio come qualsiasi reverse proxy può essere configurato per reindirizzare “quasi tutto a qualcos’altro”.

Portando questo un passo oltre, se fossi un utente commerciale di un proxy (come Cloudflare) e avessi un particolare indirizzo IP o nome di dominio che volevo reindirizzato (o blackholed), configurerei (o richiederei) al proxy (in questo caso Cloudflare) di reindirizzare l’“indirizzo IP nudo sulla porta 80” al FQDN (o dove preferisco) che scelgo.

È il tipo di cosa che i proxy sono progettati per gestire (per progettazione); e come accennato, questo tipo di reindirizzamento è facile da realizzare con Apache2 o Nginx, quindi presumo (non essendo un utente di Cloudflare) che un servizio commerciale come Cloudflare possa gestire questo tipo di reindirizzamento banale con facilità.

3 Mi Piace
12

Io uso questo per un sito per reindirizzare i bot che lo colpiscono tramite IP grezzo a una pagina speciale:

server {
        listen 80;
        # listen [::]:80;

        server_name ~^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+;

        root /var/www/ip-address;
        default_type text/plain;
        index nothing.doing;
        location / {
                try_files $uri /nothing.doing;
        }
}

MA sono d’accordo con gli altri nel dire che non riesco a riprodurre l’accesso tramite IP nemmeno per il mio forum privato. Ricevo il reindirizzamento. E il mio non ha alcuna configurazione speciale, nessun Cloudflare, ed sta letteralmente eseguendo un server virtuale a $0 al mese che non mi offre funzionalità extra.

3 Mi Piace
13

Ma se ci pensi, potresti renderti conto che tutti hanno configurazioni con bilanciamento del carico su un’infrastruttura che costa (decine di) milioni di dollari. Quindi non sono nemmeno rappresentativi.

La migrazione non copia alcuna configurazione nginx, quindi in realtà si tratta di una nuova installazione.

2 Mi Piace
14

Ottimo, grazie per aver condiviso quel frammento @elijah, apprezzo molto! Sostituirò l’IP hardcoded con la tua espressione regolare o userò l’intero frammento. :slight_smile:

2 Mi Piace
15

Sì, questo conferma ulteriormente che questi siti probabilmente non sono accessibili via web tramite un IP diretto. Comunque, sembra che nessuno sia a favore di consentire l’accesso diretto e non sicuro tramite IP sul web.

Sì, hai ragione.

1 Mi Piace
16

Ho appena testato l’avvio di due istanze di Discourse su Digital Ocean utilizzando la loro app del marketplace per avvistarle rapidamente.

Volevo provare questa configurazione con praticamente zero personalizzazione, modificando solo smtp, dev email e discourse_hostname con dati fittizi (per permettere il rebuild).

L’installer si è fermato a causa del dominio/sottodominio fittizio impostato, che non ha superato la fase di validazione del dominio (e consiglia di modificare manualmente il file app.yml e poi eseguire il rebuild).

Dopo aver modificato app.yml e eseguito il rebuild (solo smtp, dev email e discourse_hostname), il sito è accessibile in modo non sicuro tramite l’indirizzo IP, senza alcun coinvolgimento di Cloudflare. Non viene effettuato il reindirizzamento al discourse_hostname impostato.

La maggior parte delle mie installazioni non ha utilizzato l’app del marketplace di Digital Ocean per la configurazione, ma è stata eseguita manualmente seguendo la guida standard di installazione Docker.

Si noti che l’arresto dell’installer dovuto all’impossibilità di validare il dominio si è verificato anche in due recenti installazioni che utilizzavano Cloudflare, probabilmente a causa del proxying. Le altre installazioni sono state effettuate prima dell’introduzione della fase di validazione del dominio nell’installer.

modifica: Si noti che solo 2 delle 8 installazioni di Discourse hanno avuto problemi di verifica del dominio durante l’installazione iniziale (escludendo le due istanze di test sopra menzionate). Lo script di configurazione di Discourse suggerisce all’utente di modificare manualmente app.yml e di eseguire il rebuild in caso di errore di verifica del dominio. Nessun problema se questa indicazione non è utile; per me non è stata una soluzione.

modifica: In generale si utilizza Cloudflare Flexible SSL, non letsencrypt (che sarebbe meglio). Grazie a @neounix.

17

Per tua informazione @markersocial

Tutte le nostre installazioni di Discourse reindirizzano http://l.ip.add.res verso https://FQDN configurato tramite LETSENCRYPT abilitato nel file .yml del container Discourse.

Affinché tutto funzioni correttamente e i certificati LETSENCRYPT operino come previsto, è necessaria una configurazione SSL completamente funzionante (normalmente con LETSENCRYPT), come sicuramente già sai.

Solo un promemoria… spero che questo sia utile.

2 Mi Piace
18

Vanilla ha un dominio valido e utilizza lo script di configurazione di Discourse.

Se non si fa né l’uno né l’altro, non è inaspettato che il risultato sia diverso.

Questa discussione non contiene informazioni utilizzabili e non possiamo riprodurre il problema se le istruzioni vengono seguite.

7 Mi Piace