Wie kann Discourse UFW umgehen? Ich hatte nur Port 22 aktiviert, sodass alle anderen Ports geschlossen sein sollten. Aber ein Forum funktionierte trotzdem. Wie ist das möglich?
DigitalOcean Droplet, aber das sollte nichts bedeuten. Und keine One-Click-Installation, sondern der offizielle Weg.
Dies ist keine reine Support-Frage, aber wir haben hier keine Kategorie namens Dumme Anfängerfragen 
Wenn Sie also ufw status verbose ausführen, sehen Sie nur sshd?
Das ist richtig. Und UFW war aktiviert.
Was wurde als Standard aufgeführt, als Sie ufw status verbose ausgeführt haben?
Für das, was Sie meiner Meinung nach wollen, würde ich Folgendes erwarten:
Standard: deny (incoming), allow (outgoing), disabled (routed)
Bei dem von Ihnen beschriebenen Verhalten würde ich Folgendes erwarten:
Standard: allow (incoming), allow (outgoing), disabled (routed)
Haben Sie versucht, das Forum in einem Inkognito-Fenster oder einem anderen Browser zu öffnen? Es ist leicht, sich von der zwischengespeicherten Version täuschen zu lassen, die angezeigt wird. Ich wurde selbst getäuscht und ein anderer Entwickler sagte mir, dass die Staging-Site gut aussah, obwohl sie überhaupt nicht lief.
Nur 22/tcp (OpenSSH) ALLOW IN Anywhere, wie es sein sollte. Das sind die beiden Dinge, die ich immer tue: OpenSSH erlauben und UFW aktivieren.
Ich öffne Ports nur, wenn es nötig ist, wie zum Beispiel, wenn ich Nginx installiere. Aber da der VPS nur für Discourse war, habe ich nichts weiter getan – ich habe UFW völlig vergessen.
Das kann nicht sein. Dieses Forum war wochenlang aktiv.
Ich bin auf diese Situation gestoßen, als ich Nginx/Varnish mit diesem VPS verbunden habe und einen weiteren Port öffnen musste – und mir wurde klar, dass nur Port 22 geöffnet war.
Bearbeiten:
Wie konnte ich E-Mails senden? Port 587 war auch nicht geöffnet 
Das ist wirklich seltsam.
Ich bin mir nicht sicher, ob Sie sagen, dass der Standard auf „deny“ gesetzt ist oder nicht. Der Grund, warum ich speziell nach der Zeile „Default“ frage, ist, dass es möglich ist, sowohl einen Standard von „allow“ zu haben als auch einen bestimmten Port zum Erlauben festzulegen, obwohl letzteres in dieser Anordnung nichts ändert.
Wenn jemand anderes Discourse eingerichtet hat, ist es möglich, dass diese Person den Standard von „allow“ anstelle des Erlaubens der HTTP/HTTPS-Ports geändert hat?
Ich gehe davon aus, dass dies SMTP irgendwo anders ist, Ihr Discourse-Server, der sich mit diesem SMTP-Server über Port 587 verbindet. Ausgehende Verbindungen sind standardmäßig für alle Ports erlaubt, sodass UFW dem Senden von E-Mails nicht im Wege steht, es sei denn, Sie ändern die ausgehende Richtlinie ausdrücklich.
Mein Fehler 
Standard: verweigern (eingehend), zulassen (ausgehend), verweigern (weitergeleitet)
Nein. Aber erlaubt zulassen (ausgehend) irgendetwas ausgehend? Wenn ja, dann sind wir wieder bei „Wir haben hier keine Kategorie namens Dumme Anfängerfragen“ und ich habe neue Dinge gelernt.
Bearbeiten:
Ich bin immer noch verloren – aber wie ist verweigern (eingehend)?
Ich habe das hier gefunden:
Die kurze Antwort ist, dass Discourse Ihre Firewall-Regeln nicht umgehen kann und der Ort, an dem Sie dumme Fragen zu Betriebssystemen stellen können, so etwas wie Stack Exchange ist. (Bitte denken Sie nicht, ich sei unhöflich. Dort liegen diese Antworten. Nachdem ich Linux seit den frühesten Versionen betreibe, gehe ich immer noch an solche Orte, um all meine dummen Fragen zu stellen. Ich habe sie immer noch!)
Ich kenne den Ort Es gibt ein viel zu hohes Signal/Rausch-Verhältnis. Nun, das war eine unfaire Charakterisierung, aber ich meinte, es ist wirklich schwer, dort relevante Dinge zu finden. Es ist so massiv.
Das ist eigentlich eine sehr gute Frage, und ich bin überrascht, dass noch niemand sie gestellt hat. Die Antwort ist kompliziert, aber bisher waren die Antworten zu diesem Thema leider abweisend und beantworteten die Frage nicht.
Es ist nicht so, dass Discourse ufw umgeht, sondern docker umgeht ufw, indem es Regeln hinzufügt, die dazu führen, dass alle exponierten Ports von Docker-Containern trotz der Anwesenheit von ufw funktionieren.
Eingehende Pakete, die für einen Container bestimmt sind, treffen auf die FORWARD-Tabelle und nicht auf die INPUT-Tabelle, wie man vielleicht erwarten würde.
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ufw-before-logging-forward all -- any any anywhere anywhere
0 0 ufw-before-forward all -- any any anywhere anywhere
0 0 ufw-after-forward all -- any any anywhere anywhere
0 0 ufw-after-logging-forward all -- any any anywhere anywhere
0 0 ufw-reject-forward all -- any any anywhere anywhere
0 0 ufw-track-forward all -- any any anywhere anywhere
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
8 416 DOCKER-USER all -- any any anywhere anywhere
8 416 DOCKER-ISOLATION-STAGE-1 all -- any any anywhere anywhere
0 0 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
4 256 DOCKER all -- any docker0 anywhere anywhere
4 160 ACCEPT all -- docker0 !docker0 anywhere anywhere
0 0 ACCEPT all -- docker0 docker0 anywhere anywhere
0 0 ufw-before-logging-forward all -- any any anywhere anywhere
0 0 ufw-before-forward all -- any any anywhere anywhere
0 0 ufw-after-forward all -- any any anywhere anywhere
0 0 ufw-after-logging-forward all -- any any anywhere anywhere
0 0 ufw-reject-forward all -- any any anywhere anywhere
0 0 ufw-track-forward all -- any any anywhere anywhere
Der Grund, warum die Pakete die Forward-Tabelle treffen, liegt an Regeln, die Docker zur nat-Tabelle hinzufügt:
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
210 12734 DOCKER all -- any any anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- docker0 any anywhere anywhere
0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:https to:172.17.0.2:443
107 6848 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:http to:172.17.0.2:80
nat/PREROUTING wird vor der Entscheidung, ob Pakete über INPUT oder FORWARD gesendet werden sollen, verarbeitet.
Letztendlich liegt das Problem darin, dass zwei Dienste auf dem System die Firewall-Regeln ändern. ufw weiß nichts davon, daher kann es nur berichten, was es konfiguriert hat.
Dafür ist die Neukonfiguration der Firewall, um auch für Docker bestimmte Daten über die ufw-Chains weiterzuleiten:
Ich verwende die folgende leichte Anpassung ihrer Arbeit, die vor der Aktivierung von ufw eingerichtet wird:
# gestohlen von https://github.com/chaifeng/ufw-docker - sieht vernünftig aus
# das Hinzufügen der Weiterleitung zu ufw-user-input ermöglicht Verbindungen zu
# weitergeleiteten Ports, die wir explizit geöffnet haben
cat <<EOUFW >> /etc/ufw/after.rules
# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16
-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN
-A DOCKER-USER -j ufw-user-forward
-A DOCKER-USER -j ufw-user-input
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER
EOUFW
Danke! Das war eine vollständige Erklärung.
Willkommen, so bin ich drauf 
Dieses Thema ist gelöst, aber es hat ein kleines Problem mit meinem Setup aufgedeckt. Ich werde es erklären, falls jemand eines Tages nach etwas Ähnlichem sucht.
Ich hatte einen VPS, auf dem Nginx SSL und einige andere Dinge für alle meine Websites (viele davon, Englisch ist eine sehr seltsame Sprache ) übernimmt. Nginx leitet Anfragen an Varnish weiter. Es ist ein nutzloser Reverse-Proxy für Discourse, aber es führt einige Filterungen durch. Varnish leitet Anfragen an einen anderen VPS weiter, auf dem Discourse über Port 83 läuft. Beide VPS hören auf denselben Port und es ist nur beiden IPs erlaubt. Ich war total glücklich – bis jetzt.
Ich habe versucht, was passiert, wenn ich Port 443 verwende curl -I https://forum.example.tld:443. Es funktionierte gut, weil ich auf der Seite von Discourse immer noch ein gültiges SSL-Zertifikat habe (diese Änderung habe ich vor einigen Wochen vorgenommen).
Die Antwort von @supermathie erklärt, warum das passiert und wie man es behebt. Sicher, es gibt keinerlei Sicherheitsprobleme, soweit ich weiß, aber es ist wirklich ärgerlich 
Wow. Das ist verrückt! Danke
Ich schätze, es wird nicht gefragt, weil nicht jeder, der Discourse installiert, möchte, dass es nicht funktioniert. Wenn Docker es also zum Laufen bringt, obwohl man die Firewall so konfiguriert hat, dass es nicht funktionieren sollte, beschweren sich die meisten Leute nicht.
Es ist ein sehr interessantes Problem, aber es scheint ein wenig esoterisch zu sein, und es ist kein Discourse-Problem, sondern eine Eigenart von Docker. Die Frage läuft darauf hinaus: “Wie kann ich meine Firewall so konfigurieren, dass Discourse nicht funktioniert?” Ich werde versuchen, mich an diese prerouting-Sachen zu erinnern.
Wenn ich die Antwort gewusst hätte, wäre ich nicht abweisend gewesen! Danke, dass du das heute gerettet hast!
Ich habe sicherlich nicht versucht, abweisend zu sein, sondern eher zu troubleshooten… und war offensichtlich unwissend darüber, was Docker tat. Das sind alles sehr nützliche Informationen, danke für die Antwort!
Wenn der OP oder jemand anderes es ändern kann, könnte es sich lohnen, die markierte Lösung zu ändern.
Obwohl es mehr eine Docker-Sache ist, kann ich einige Discourse-Hypothetiken sehen, die daraus entstehen. Zum Beispiel könnte ich einen Büroserver haben, der von der Welt erreichbar ist, aber ich möchte UFW konfigurieren, um Discourse nur aus dem Büro zugänglich zu machen. Docker-Ergänzungen würden diese Einrichtung verhindern.
In diesem speziellen Szenario würde ich es jedoch eher über eine Hardware-/Hypervisor-Firewall einrichten als über UFW auf dem Host.
Ich bin gerade zum selben Git-Repository gekommen, das du gefunden hast, und habe mir ein ufw/docker-Problem angesehen. Das hat mich an dieses Thema erinnert.
Was genau hast du geändert (ich meine, ich sehe die hinzugefügten Zeilen, aber was bedeutet das?), und sind diese Änderungen speziell für Discourse?
Ich habe den Standardcode im Repository verwendet und mein UFW-Problem schien danach behoben zu sein.
EDIT: Wenn ich deinen bearbeiteten Code verwende, erhalte ich beim ersten Ausführen von ufw reload die folgende Fehlermeldung:
FEHLER: Konnte keine Logging-Regeln laden
Tatsächlich habe ich es nach einer Weile herausgefunden und dieses Bash-Skript geschrieben, um die Aufgabe für Discourse-Installationen zu erledigen.
Es setzt Ihre Firewall zurück, installiert ufw-docker-util (das die after.rules bearbeitet) und fügt dann die Ports 443 und 80 zu Ihrer Zulassungsliste hinzu. Voila.
Es erlaubt auch Port 22 von jeder IP, um sicherzustellen, dass Sie nicht ausgesperrt werden. Nachdem alles funktioniert, sichern Sie Port 22 wieder.
EDIT: Das Skript funktioniert, aber das anschließende Rebuild von Discourse schlägt fehl:
fatal: unable to access 'https://github.com/discourse/discourse.git/': Could not resolve host: github.com- Verwenden Sie das Skript also NICHT, es sei denn, Sie wissen, wie Sie dies lösen können.
EDIT 2: Funktioniert unter Ubuntu, aber nicht unter CentOS!
Letzten Mal, als ich ein Bash-Skript gemacht habe, habe ich den Besitzer aller Verzeichnisse auf www-data:www-data geändert – also macht so etwas die Arbeit für mich etwas einfacher
Aber im Allgemeinen – ich möchte, dass Docker UFW/iptables vollständig folgt. Nur weil ich GeoIP-Blocking über iptables verwende (ja, ich weiß – UFW ist nur eine minimalistische Benutzeroberfläche für iptables).
Sicher, wir sind nicht mehr bei Discourse, aber hier sehen wir, warum Programmierer und Endbenutzer sich nicht immer so gut verstehen können: Programmierer sehen die Welt als logische Blöcke und Wenn/Dann/Sonst-Konstruktionen, aber Endbenutzer sehen sie als vollen Kontext. Das bedeutet – weil ich Discourse benutze, auch wenn es innerhalb von Docker läuft, ist es aus meiner Sicht Discourse, das meinen Regeln nicht folgt 
Das sollte unter Praise stehen, aber ich habe die URL des Forums vor einigen Wochen geändert. Und ich habe alle Skript-Kiddies und nutzlosen SEO-Bots der Welt dazu gebracht, mich zu besuchen. Ich hatte auf einem 2 GB/1 vCPU VPS von DigitalOcean 3000 verschiedene User Agents pro Stunde und Discourse war es egal. Jede WordPress-Installation wäre nach dieser Art von DDoS-Ansturm langsam/ausgefallen.
Also, ich muss Discourse (naja, Docker) nicht wirklich zwingen, die Sperren von Fail2ban und meine Regeln zu befolgen – aber ich hasse diese Bots so sehr.