Firewall für Discourse konfigurieren

Dokumentation Selbst-Hosting
,
1

Wenn Sie eine Standard-Docker-basierte Discourse-Installation verwenden, schützen die folgenden Regeln der Uncomplicated Firewall alle Nicht-Docker-Dienste auf Ihrem Server:

ufw allow http
ufw allow https
ufw allow ssh
ufw enable

Das heißt, erlauben Sie HTTP (Port 80), HTTPS (Port 443) und SSH (Port 22) und nichts anderes.

:warning: Hinweis: Docker manipuliert iptables direkt und umgeht ufw-Regeln. Das bedeutet, dass ufw den Zugriff auf Ports, die von Docker-Containern freigegeben werden (Port 80 und 443 bei einer Standard-Discourse-Installation), nicht blockieren oder einschränken kann. Die oben genannten ufw-Regeln schützen nur Nicht-Docker-Dienste, die auf Ihrem Host laufen.

Überprüfen Sie den aktuellen Status Ihrer Firewall mit

ufw status verbose

Beispielausgabe:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80                         ALLOW IN    Anywhere
443                        ALLOW IN    Anywhere
22                         ALLOW IN    Anywhere
80 (v6)                    ALLOW IN    Anywhere (v6)
443 (v6)                   ALLOW IN    Anywhere (v6)
22 (v6)                    ALLOW IN    Anywhere (v6)

Und wenn Sie sie jemals ausschalten möchten

ufw disable

Eine Standard-Docker-Installation von Discourse gibt nur die Ports 80 und 443 frei, daher ist eine Host-Firewall nicht unbedingt erforderlich. Wenn Sie jedoch andere Dienste auf dem Host ausführen, die auf zusätzlichen Ports lauschen, bietet eine Firewall eine zusätzliche Ebene der „Sicherheit mit doppelter Absicherung“ für diese Dienste.

33 „Gefällt mir“
:cn: Discourse Official Install Guide | Discourse 云平台安装
How might we better structure #howto?
Mail-receiver relay access denied
I can't start a Discourse
4

Soweit ich das verstehe, hat der Docker-Container nur sehr wenige offene Ports zum Host-System, sodass Discourse effektiv von dem Server, auf dem es läuft, abgeschottet ist.

Wenn natürlich andere Dinge auf dem Host-System laufen, dann sagt Captain Obvious, dass man vernünftige Vorsichtsmaßnahmen treffen muss.

Ich hatte mal einen Server, von dem wir dachten, er sei ziemlich gut gesichert, der aber gehackt wurde, das war nicht schön.

1 „Gefällt mir“
5

Thema ist nicht ganz korrekt. Wenn UFW außerhalb von Docker verwendet wird, wie “normalerweise” auf einem VPS, gilt es nicht per se für Discourse. Ich kann Port 80 deaktivieren und er ist immer noch offen für Discourse/Docker.

Sicher, es schützt alles andere, aber wenn keine anderen Dienste lauschen, ist es unnötig.

Ich weiß nicht, wie UFW oder iptables funktionieren, wenn sie nach enter app verwendet werden, oder ob Firewall auf diese Weise überhaupt verwendet werden kann.

Ich beziehe mich auf dieses Thema:

3 „Gefällt mir“
6

Ich wäre definitiv daran interessiert, diese Geschichte zu hören, vielleicht in einem separaten Thread :slight_smile:

fwiw, Diskussionen über die Beziehung zwischen Docker und ufw / Firewalls sind fast so alt wie Docker selbst. Hier ist eine ziemlich hochkarätige Diskussion mit vielen interessanten Einblicken

Docker selbst hat sich in den letzten Jahren in Bezug auf die Dokumentation der relevanten Details verbessert; Packet filtering and firewalls | Docker Docs

Ich möchte das Thema nicht zu sehr mit Links spammen, aber wenn Sie sich für das Thema Firewalls interessieren, scheinen dies wirklich aufschlussreiche Artikel zu sein, die Sie zusammen mit einer allgemeinen Google-Suche nach weiteren Details überprüfen können.

Basierend auf einigen dieser Ansichten und dem äußerst hilfreichen Thread, der von @Jagster verlinkt wurde, scheint es, dass die Standard-Discourse-Installation mit Docker möglicherweise ausreichend ist? Schließlich sieht meine so aus;

$ docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED      STATUS        PORTS                                                                      NAMES
5dd4a572cd8e   local_discourse/app   \"/sbin/boot\"   6 days ago   Up 16 hours   0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp   app

Wenn ich mich nicht irre und keine anderen Ports von anderer Software auf dem Server verwendet werden, denke ich, dass der einzige eingehende Datenverkehr, der verbunden werden sollte, über diese aufgelisteten Ports 80 und 443 erfolgt.

Wenn Sie einen Sanity-Check durchführen möchten, sollten Sie netstat verwenden können, um die lauschenden Ports auf Ihrem Server zu überprüfen (How to Install netstat on Ubuntu ; https://linuxize.com/post/check-listening-ports-linux/)

netstat -tunlp

Für einen noch stärkeren Sanity-Check können Sie einen zweiten kleinen Linux-Server hochfahren und versuchen, die offenen Ports Ihres Discourse-Servers zu scannen; How To Use Nmap to Scan for Open Ports | DigitalOcean

# scan all ports ; insert your IP address here
sudo nmap -n -PN -sT -sU -p- 1.2.3.4
  • Überprüfen Sie den Link zu den DigitalOcean-Dokumenten für weitere Befehle zum Scannen usw.

Ich denke, wenn man sich Sorgen um die Server-Firewall für seinen Discourse-Server macht, sind diese Ressourcen und Einblicke sehr hilfreich :slight_smile:

3 „Gefällt mir“
7

Kleine Sache, aber dieser Link scheint tot zu sein.

1 „Gefällt mir“
8

[Zitat=“Discourse, Beitrag:1, Thema:20584”]
ALLOW IN
[/Zitat]

Die neueste Ubuntu LTS ufw verwendet ALLOW und nicht ALLOW IN.

Das hat den Admin des mail-receiver-Dienstes genervt, der bei der API-Vorbereitung in ./launcher logs mail-receiver einen Fehler bekommt, obwohl Port 25 in ufw offen ist.

Das Zulassen aller eingehenden und ausgehenden Verbindungen, gefolgt vom Blockieren der gewünschten Ports, hat als Lösung gedient.

Ich kenne mich noch nicht genug mit iptables aus, um es weiter feinzujustieren.