Konfigurieren Sie eine Firewall für Discourse

Dokumentation Selbst-Hosting
,
1

It’s unclear if Linux distributions really “need” a firewall – but we have found that the following Uncomplicated Firewall rules work fine with a standard Docker based Discourse install:

ufw allow http
ufw allow https
ufw allow ssh
ufw enable

That is, allow HTTP (port 80), HTTPS (port 443), and SSH (port 22), and nothing else.

Check the current status of your firewall with

ufw status verbose

Sample output:

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)

And if you ever want to turn it off

ufw disable

A firewall should not matter if you are using a default Docker install of Discourse, for the same reason almost no Linux distribution ships with a firewall enabled by default.

But if you have somehow installed extra services that talk to the outside world, adding a firewall gives you “belt and suspenders” security, if that is of interest to you.

33 „Gefällt mir“
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.