Le site est accessible via l'adresse IP sans suivre le guide d'installation

Contribuer Fonctionnalité
1

Pour des raisons de sécurité, je pense qu’il serait préférable que, par défaut, les forums Discourse ne soient pas accessibles lorsque l’on navigue directement vers l’adresse IP dans un navigateur.

Voici quelques raisons :

  • Cela permet d’utiliser le site sans HTTPS, tant pour les utilisateurs que pour la configuration initiale par l’administrateur.
  • Cela évite de révéler l’adresse du serveur d’origine, ce qui est problématique si vous utilisez Cloudflare ou un service similaire pour protéger votre IP d’origine contre les attaques DDoS ou les tentatives de piratage, surtout si les pirates considèrent le serveur comme une cible de haute valeur. Il existe des personnes qui font tourner des bots scannant toutes les plages d’IP appartenant à des hébergeurs web.

De plus, l’installateur de Discourse vérifie désormais que le domaine ou le sous-domaine est correctement configuré ; sinon, il ne poursuit pas l’installation.

Tout ce qu’il faut ajouter tout en bas du fichier /etc/nginx/conf.d/discourse.conf (à l’intérieur du conteneur Docker) est :

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

Où 1.1.1.1 est l’adresse IP publique de votre serveur. Il existe probablement un moyen plus élégant d’inclure l’adresse IP que de l’écrire en dur. J’ai essayé plusieurs approches, mais aucune n’a fonctionné.

Cela fonctionne très bien pour moi (y compris avec le proxy Cloudflare). Je ne vois pas beaucoup de cas où autoriser l’accès web direct via l’adresse IP serait utile ou nécessaire. Il semble que ce soit une pratique assez courante de l’interdire. Je suis ouvert à toute raison valable de ne pas le faire, cependant !

1 « J'aime »
2

Pourquoi changer quoi que ce soit alors que notre guide par défaut vous laisse avec un site fonctionnel uniquement en HTTPS ?

Les personnes ayant des besoins spéciaux peuvent aller bidouiller, mais notre configuration par défaut restera telle quelle, avec un nom de domaine fonctionnel et HTTPS.

9 « J'aime »
3

Merci beaucoup !

1 « J'aime »
4

Objectivement, ce n’est pas exact. Ce n’est pas uniquement en HTTPS, car vous pouvez accéder au site directement via l’adresse IP qui n’est pas sécurisée en HTTPS.

La différence réside dans l’interdiction de se connecter de manière non sécurisée sans HTTPS et dans la divulgation de l’adresse IP d’origine du serveur. Je ne connais aucun avantage à cela.

Si vous effectuez une recherche DNS sur les 50 premiers sites du monde, il semble qu’aucun d’entre eux ne soit accessible de manière non sécurisée directement via l’adresse IP. Je ne pense pas qu’il soit déraisonnable de supposer que les 50 premiers sites du monde utilisent les meilleures pratiques.

Voici une liste assez précise :

Voici un outil de recherche DNS :

5

Par défaut, toute tentative d’accès via l’adresse IP renvoie une redirection 301 vers le bon domaine :

$ 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/

En

Votre proposition consiste-t-elle à passer d’une redirection 301 à une erreur 404 ?

3 « J'aime »
6

8 installations sur 8, effectuées via l’image Digital Ocean, avec Communiteq (anciennement DiscourseHosting) installé (puis migré) ainsi que manuellement en suivant ce guide : discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub. Toutes sont accessibles de manière non sécurisée via l’adresse IP par défaut. Deux d’entre elles ont été installées la semaine dernière (en utilisant le guide GitHub ci-dessus).

Y a-t-il peut-être une étape supplémentaire que j’aurais oubliée ? Je dirais qu’un code 404 est préférable à un 301, car la plupart des personnes qui fouinent autour des adresses IP n’ont probablement rien de bon en tête. Mais un 301 est mieux qu’un accès non sécurisé.

7

Pas de repro…

http://38.242.24.122 me redirige correctement vers https://discourse.codinghorror.com/

4 « J'aime »
8

Hmmm, peut-être que c’est le modèle Cloudflare. C’est probablement la seule différence constante par rapport à une installation totalement vanilla entre tous.

1 « J'aime »
9

Si vous avez effectué des étapes qui ne figurent pas dans l’installation Cloud, ce n’est pas, par définition, une « installation vanilla ».

Le modèle Cloudflare ne fait rien d’évident pour interférer avec une redirection :

run:
  - file:
      path: /tmp/add-cloudflare-ips
      chmod: +x
      contents: |
        #!/bin/bash -e
        # Télécharger la liste des adresses IP de CloudFlare
        wget https://www.cloudflare.com/ips-v4/ -O - > /tmp/cloudflare-ips
        wget https://www.cloudflare.com/ips-v6/ -O - >> /tmp/cloudflare-ips
        # Convertir en commandes nginx et échapper pour inclusion dans la commande d'ajout sed
        CONTENTS=$(< /tmp/cloudflare-ips sed 's/^/set_real_ip_from /' | sed 's/$/;/' | tr '\n' '\\' | sed 's/\\/\\n/g')
        
        echo Adresses IP CloudFlare :
        echo $(echo | sed "/^/a $CONTENTS")
        # Insérer dans discourse.conf
        sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header CF-Connecting-IP;" /etc/nginx/conf.d/discourse.conf
        # Nettoyage
        rm /tmp/cloudflare-ips

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

Il récupère les plages d’adresses IP, les stocke temporairement sous le nom cloudflare-ips et ajoute le support pour CF-Connecting-IP.

2 « J'aime »
10

Exact. Je n’ai pas affirmé qu’il s’agissait d’« installations vanilla ».

J’ai donc testé la suppression du modèle Cloudflare officiel sur l’un d’eux, puis une reconstruction. Malheureusement, cela n’a rien changé. L’accès non sécurisé via l’adresse IP persiste.

Je ne vois vraiment rien d’autre d’anormal entre ces installations. Les seuls plugins présents sur cette instance étaient le gestionnaire Docker inclus par défaut et le plugin officiel d’annonce. Il est sur la branche stable, mais les autres sites qui se comportent de la même manière sont sur un mélange de stable, beta et tests-passés.

11

Non spécifique à une configuration donnée ou à Cloudflare, il s’agit simplement d’un autre point de données et d’un autre point de vue :

Nous pouvons configurer un proxy pour rediriger une « adresse IP nue sur le port 80 » (à titre d’exemple) vers n’importe quel nom de domaine complet (FQDN) de plusieurs manières, tant avec Apache2 qu’avec Nginx.

Il existe de nombreuses façons de procéder (réécriture et redirection, hôte virtuel et redirection, etc.).

Par exemple, nous pouvons créer un hôte virtuel sur un proxy inverse, ce dernier écoutant sur l’adresse IP au port 80, et rediriger toutes ces requêtes vers n’importe quel FQDN (ou adresse IP) de notre choix.

Nous pouvons également le faire avec un proxy inverse en utilisant mod_rewrite dans Apache2 et des règles de réécriture dans Nginx.

Pour tous nos déploiements Discourse (en production), nous plaçons un proxy inverse devant Discourse (certains avec Apache2, d’autres avec Nginx), et il est facile de résoudre ce type de problèmes (lorsqu’ils surviennent) en configurant le proxy inverse pour gérer ces cas et situations particulières.

Cela dit, je n’utilise pas le cas particulier de cloudflare comme proxy, mais il semble que n’importe quel proxy puisse être configuré pour gérer ce type de problèmes, tout comme n’importe quel proxy inverse peut être configuré pour rediriger « à peu près n’importe quoi vers n’importe quoi d’autre ».

En allant plus loin, si j’étais un utilisateur commercial d’un proxy (comme Cloudflare) et que je souhaitais qu’une adresse IP ou un nom de domaine particulier soit redirigé (ou mis en blackhole), je configurerais (ou demanderais) au proxy (dans ce cas, Cloudflare) de rediriger l’« adresse IP nue sur le port 80 » vers le FQDN (ou l’endroit de mon choix).

C’est le type de problème que les proxies sont conçus pour gérer (par conception) ; et comme mentionné, ce type de redirection est facile à réaliser avec Apache2 ou Nginx, donc je suppose (n’étant pas utilisateur de Cloudflare) qu’un service commercial comme Cloudflare peut gérer ce type de redirection triviale avec aisance.

3 « J'aime »
12

J’utilise ceci pour un site afin de rediriger les bots qui y accèdent via une adresse IP brute vers une page spéciale :

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;
        }
}

MAIS, comme les autres, je ne parviens pas non plus à reproduire l’accès par IP pour mon forum privé. Je reçois une redirection. Et le mien n’a aucune configuration spéciale, pas de Cloudflare, et fonctionne littéralement sur un serveur virtuel à 0 $ par mois sans options supplémentaires.

3 « J'aime »
13

Mais si vous y réfléchissez, vous réaliserez peut-être qu’ils disposent tous de configurations équilibrées en charge sur une infrastructure coûtant (des dizaines de) millions de dollars. Ils ne sont donc pas représentatifs non plus.

La migration ne copie aucun paramètre nginx, il s’agit donc en fait d’une nouvelle installation.

2 « J'aime »
14

Super, merci de partager cet extrait @elijah, je l’apprécie ! Je remplacerai l’adresse IP codée en dur par ton expression rationnelle, ou j’utiliserai l’extrait complet. :slight_smile:

2 « J'aime »
15

Oui, cela indique en outre que ces sites ne sont probablement pas utilisables sur le Web via une adresse IP directe. Quoi qu’il en soit, personne ne semble soutenir la possibilité d’un accès direct non sécurisé via une adresse IP sur le Web.

Oui, vous avez raison.

1 « J'aime »
16

Je viens de tester le lancement de deux instances Discourse sur Digital Ocean en utilisant leur application du marketplace pour les lancer rapidement.

Je voulais tester cela avec une configuration personnalisée quasi nulle, en modifiant uniquement smtp, dev email et discourse_hostname avec des informations fictives (pour permettre la reconstruction).

L’installateur s’arrête en raison du domaine/sous-domaine fictif que j’ai défini, qui ne passe pas l’étape de validation du domaine (et recommande d’éditer manuellement le fichier app.yml puis de reconstruire).

Après avoir édité app.yml et reconstruit (smtp, dev email et discourse_hostname uniquement), le site est accessible de manière non sécurisée via l’adresse IP, sans aucune intervention de Cloudflare. Il ne redirige pas vers le discourse_hostname défini.

La plupart de mes installations n’ont pas utilisé l’application du marketplace de Digital Ocean pour la configuration, mais ont été effectuées manuellement en suivant le guide d’installation Docker standard.

Notez que l’arrêt de l’installateur en raison de l’impossibilité de valider le domaine s’est également produit sur deux installations récentes que j’ai effectuées avec Cloudflare, probablement à cause de la mise en proxy. Les autres installations ont été réalisées avant qu’une étape de validation du domaine ne soit incluse dans l’installateur.

edit : Notez que seules 2 des 8 installations Discourse ont rencontré un problème de vérification de domaine lors de l’installation initiale (sans compter les deux instances de test mentionnées ci-dessus). Le script de configuration Discourse suggère à l’utilisateur d’éditer manuellement app.yml et de reconstruire en cas d’erreur de vérification de domaine. Ce n’est pas un problème si cela n’est pas utile, car ce n’était pas une solution pour moi.

edit : En général, j’utilise Cloudflare avec SSL flexible, et non letsencrypt (ce qui serait mieux). Merci @neounix.

17

FYI @markersocial

Toutes nos installations Discourse redirigent http://the.ip.add.res vers le https://FQDN configuré par l’option LETSENCRYPT activée dans le fichier .yml du conteneur Discourse.

Pour que tout fonctionne correctement et que les certificats LETSENCRYPT soient opérationnels, vous devez disposer d’une configuration SSL entièrement fonctionnelle (généralement avec LETSENCRYPT), comme vous le savez sûrement déjà.

Juste un rappel… j’espère que cela vous sera utile.

2 « J'aime »
18

Vanilla dispose d’un domaine valide et utilise le script de configuration de Discourse.

Si vous ne faites ni l’un ni l’autre, il n’est pas surprenant que le résultat soit différent.

Ce sujet ne contient aucune information exploitable et nous ne pouvons pas reproduire le problème si les instructions sont suivies.

7 « J'aime »