Site ist über die IP-Adresse erreichbar, wenn die Installationsanleitung nicht befolgt wird

Beitragen Merkmal
1

Aus Sicherheitsgründen wäre es meiner Meinung nach besser, wenn Discourse-Foren standardmäßig nicht sichtbar sind, wenn man im Browser direkt auf die IP-Adresse zugreift.

Ein paar Gründe:

  • Ermöglicht die Nutzung der Seite ohne HTTPS, sowohl für Benutzer als auch für die initiale Konfiguration durch den Administrator.
  • Enthüllt die Adresse des Ursprungsservers, was problematisch ist, wenn Sie Cloudflare oder Ähnliches verwenden, um Ihre Ursprungs-IP vor DDoS-Angriffen oder Server-Hacking-Versuchen zu schützen, falls Hacker den Server als hochgradig wertvoll einstufen. Es gibt Personen, die Bots betreiben, die alle IP-Bereiche von Webhostern durchsuchen.

Außerdem bestätigt der Discourse-Installer mittlerweile, dass die Domain/Subdomain ordnungsgemäß konfiguriert ist, bevor er mit der Installation fortfährt.

Alles, was am unteren Ende der Datei /etc/nginx/conf.d/discourse.conf (innerhalb des Docker-Containers) hinzugefügt werden muss, ist:

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

Dabei ist 1.1.1.1 die öffentliche IP-Adresse Ihres Servers. Es gibt wahrscheinlich eine elegantere Möglichkeit, die IP-Adresse einzubinden, als sie hart zu kodieren. Ich habe es mit ein paar Varianten versucht, konnte sie aber nicht zum Laufen bringen.

Bei mir funktioniert das gut (auch mit Cloudflare-Proxy), und ich kann mir kaum Fälle vorstellen, in denen ein direkter Webzugriff über die IP nützlich oder notwendig wäre. Es scheint eher üblich zu sein, dies zu untersagen. Ich bin jedoch gerne offen für Gründe, warum man es nicht tun sollte!

1 „Gefällt mir“
2

Warum etwas ändern, wenn unsere Standardanleitung Sie mit einer funktionierenden HTTPS-only-Website zurücklässt?

Personen mit speziellen Bedürfnissen können herumexperimentieren, aber unser Standard bleibt so, wie er ist: eine funktionierende Domain und HTTPS.

9 „Gefällt mir“
3

Vielen Dank!

1 „Gefällt mir“
4

Objektiv betrachtet ist das nicht korrekt. Es ist nicht ausschließlich HTTPS, da du die Website direkt über die IP-Adresse erreichen kannst, die kein HTTPS verwendet.

Der Unterschied liegt darin, unsichere Verbindungen ohne HTTPS zu unterbinden und die Origin-IP des Servers offenzulegen. Mir sind keine Vorteile dafür bekannt.

Wenn du eine DNS-Abfrage für die Top 50-Websites der Welt durchführst, scheint keine davon unsicher direkt über die IP erreichbar zu sein. Ich halte es nicht für unangemessen anzunehmen, dass die Top 50-Websites der Welt Best Practices anwenden.

Hier ist eine ziemlich genaue Top-Liste:

Hier ist ein DNS-Abfrage-Tool:

5

Standardmäßig führt der Zugriff über die IP-Adresse zu einer 301-Weiterleitung zur richtigen Domain:

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

Ist Ihr Vorschlag, von einer 301- auf eine 404-Antwort umzustellen?

3 „Gefällt mir“
6

Von 8 Installationen wurden alle über das DigitalOcean-Image installiert. Sowohl Communiteq (ehemals DiscourseHosting), das installiert (und später migriert) wurde, als auch die manuelle Installation gemäß dieser Anleitung: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub – alle sind standardmäßig unsicher über die IP-Adresse erreichbar. Zwei davon wurden in der letzten Woche installiert (unter Verwendung der oben genannten GitHub-Anleitung).

Fehlt vielleicht ein zusätzlicher Schritt? Ich würde sagen, ein 404 ist besser als ein 301, da die meisten Personen, die sich IP-Adressen ansehen, wahrscheinlich nicht mit guten Absichten unterwegs sind. Ein 301 ist jedoch besser als ein unsicherer Zugriff.

7

Nicht reproduzierbar..

http://38.242.24.122 leitet mich korrekt auf https://discourse.codinghorror.com/ weiter.

4 „Gefällt mir“
8

Hmm, vielleicht liegt es an der Cloudflare-Vorlage. Das ist wahrscheinlich der einzige konsistente Unterschied zu einer komplett reinen Installation bei allen von ihnen.

1 „Gefällt mir“
9

Wenn Sie Schritte durchgeführt haben, die in der Cloud-Installation nicht aufgeführt sind, handelt es sich per Definition nicht um eine „Vanilla-Installation".

Die Cloudflare-Vorlage greift auf offensichtliche Weise nicht in eine Weiterleitung ein:

run:
  - file:
      path: /tmp/add-cloudflare-ips
      chmod: +x
      contents: |
        #!/bin/bash -e
        # Download list of CloudFlare ips
        wget https://www.cloudflare.com/ips-v4/ -O - > /tmp/cloudflare-ips
        wget https://www.cloudflare.com/ips-v6/ -O - >> /tmp/cloudflare-ips
        # Make into nginx commands and escape for inclusion into sed append command
        CONTENTS=$(</tmp/cloudflare-ips sed 's/^/set_real_ip_from /' | sed 's/$/;/' | tr '\n' '\\' | sed 's/\\/\\n/g')
        
        echo CloudFlare IPs:
        echo $(echo | sed "/^/a $CONTENTS")
        # Insert into discourse.conf
        sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header CF-Connecting-IP;" /etc/nginx/conf.d/discourse.conf
        # Clean up
        rm /tmp/cloudflare-ips

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

Es werden die IP-Bereiche abgerufen, vorübergehend als cloudflare-ips gespeichert und die Unterstützung für CF-Connecting-IP hinzugefügt.

2 „Gefällt mir“
10

Richtig. Ich habe nicht behauptet, dass es sich um „Vanilla-Installationen

11

Nicht spezifisch für eine bestimmte Konfiguration oder Cloudflare, sondern einfach ein weiterer Datenpunkt und eine weitere Perspektive:

Wir können einen Proxy einrichten, um eine „nackte IP-Adresse auf Port 80

3 „Gefällt mir“
12

Ich verwende dies für eine Website, um Bots, die sie über eine Roh-IP-Adresse erreichen, auf eine spezielle Seite umzuleiten:

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

ABER ich stimme den anderen zu, dass ich auch für mein privates Forum keinen Zugriff über die IP-Adresse reproduzieren kann. Ich erhalte die Umleitung. Und meine hat keine spezielle Konfiguration, kein Cloudflare und läuft auf einem virtuellen Server für 0 $ pro Monat, der mir keine Extras bietet.

3 „Gefällt mir“
13

Aber wenn du einmal darüber nachdenkst, wirst du vielleicht feststellen, dass alle von ihnen lastverteilende Setups auf einer Infrastruktur betreiben, die (zig) Millionen Dollar kostet. Daher sind sie ebenfalls nicht repräsentativ.

Bei einer Migration werden keine Nginx-Einstellungen kopiert, also ist das in der Tat nur eine Neuinstallation.

2 „Gefällt mir“
14

Super, danke, dass du diesen Snippet geteilt hast, @elijah, das schätze ich! Ich werde die fest codierte IP durch deinen Regex ersetzen oder den vollständigen Snippet verwenden. :slight_smile:

2 „Gefällt mir“
15

Ja, das deutet weiter darauf hin, dass diese Seiten höchstwahrscheinlich über das Web nicht über eine direkte IP-Adresse nutzbar sind. Wie auch immer, niemand scheint dafür zu sein, unsicheren direkten IP-Zugriff über das Web zuzulassen.

Ja, du hast recht.

1 „Gefällt mir“
16

Ich habe gerade getestet, wie man zwei Discourse-Instanzen auf Digital Ocean über deren Marketplace-App schnell startet.

Ich wollte dies mit praktisch keiner benutzerdefinierten Konfiguration testen, nur mit Änderungen an SMTP, der E-Mail für Entwickler und discourse_hostname unter Verwendung von falschen Daten (um den Neuaufbau zu ermöglichen).

Der Installer stoppt, weil die von mir festgelegte falsche Domain/Subdomain den Validierungsschritt für Domains nicht besteht (und empfiehlt, die app.yml-Datei manuell zu bearbeiten und dann neu zu erstellen).

Nachdem ich die app.yml bearbeitet und neu erstellt habe (nur SMTP, E-Mail für Entwickler und discourse_hostname), ist die Seite unsicher über die IP-Adresse verfügbar, ohne dass Cloudflare beteiligt ist. Es erfolgt keine Weiterleitung zur festgelegten discourse_hostname.

Die meisten meiner Installationen wurden nicht über die Digital Ocean Marketplace-App eingerichtet, sondern manuell gemäß dem Standard-Docker-Installationshandbuch durchgeführt.

Hinweis: Dass der Installer aufgrund einer nicht validierbaren Domain stoppt, trat auch bei zwei kürzlich durchgeführten Installationen auf, die Cloudflare verwendeten, wahrscheinlich aufgrund des Proxys. Die anderen Installationen wurden durchgeführt, bevor es einen Validierungsschritt für Domains im Installer gab.

Bearbeitung: Hinweis: Nur 2 der 8 Discourse-Installationen hatten während der initialen Installation Probleme mit der Domainverifizierung (ohne die beiden oben genannten Testinstanzen). Das Discourse-Einrichtungsskript schlägt dem Benutzer vor, die app.yml bei einem Fehler der Domainverifizierung manuell zu bearbeiten und neu zu erstellen. Kein Problem, falls dies nicht hilfreich ist; für mich war dies keine Lösung.

Bearbeitung: Im Allgemeinen wird Cloudflare Flexible SSL verwendet, nicht letsencrypt (was besser wäre). Danke @neounix.

17

FYI @markersocial

Alle unsere Discourse-Installationen leiten http://die.ip.addresse auf die https://FQDN um, die in der .yml-Discourse-Containerdatei durch aktiviertes LETSENCRYPT konfiguriert ist.

Damit dies alles ordnungsgemäß funktioniert und die LETSENCRYPT-Zertifikate funktionieren, benötigen Sie eine vollständig funktionierende SSL-Konfiguration (normalerweise mit LETSENCRYPT), wie Sie es sicher bereits wissen.

Nur eine Erinnerung… ich hoffe, das hilft.

2 „Gefällt mir“
18

Vanilla verfügt über eine gültige Domain und verwendet das Discourse-Einrichtungsskript.

Wenn du beides nicht tust, ist es nicht überraschend, dass das Ergebnis anders ausfällt.

Dieses Thema enthält keine handlungsrelevanten Informationen, und wir können es nicht nachvollziehen, wenn die Anweisungen befolgt werden.

7 „Gefällt mir“