Ist meine Nextcloud sicher vor Hackerangriffen?

bb77 · January 22, 2024, 4:32pm

Ja, zumindest wenn die die Sicherheit ihrer Control Server im Griff haben, wovon ich mal ausgehe. Die Frage ist halt, ob du diesen Zusatzaufwand betreiben willst, und du kannst dann natürlich keine Dateien mit Dritten teilen, wenn deine Nextcloud nicht öffentlich erreichbar ist.

linux-helmut · January 22, 2024, 4:54pm

Da spricht mir jemand aus der Seele.

Ohne Firewall einen VPS zu betreiben ist möglich und zeigt vielleicht das “Können”, aber es bleibt fahrlässig.

Welches Grundsystem hat nicht einen Port geöffnet?

Norman_Energy · February 26, 2024, 1:02pm

Hallo zusammen, ich finde diese Diskussion sehr interessant, und gehe conform mit den meisten Aussagen, aber eine ufw alleine reicht eben leider heute nicht aus.

Was ich hier vermisse, ist die Erwähnung einer sogenannten Level 7 (angelehnt an das OSI Modell) oder auch Nextgen Firewall.

Szenario: um eine Nextcloud (inkl. Talk nur für Text) öffentlich zugänglich zu machen, benötigt man Port 443 (SSL) und vielleicht noch Port 80 (für z.B. Let’s Encrypt Zertifikat, ist aber nicht empfehlenswert und sollte nur dann geöffnet werden um eine Re-Zertifizierung durchzuführen))

Nun sprechen einige hier von der ufw Firewall. Was macht diese “Firewall”? Mit dem ufw Service erlaubt man das das System für bestimmte Ports offen ist, der Rest wird geblockt. In unserem Szenario eben Port 443/80. Das wars aber auch schon. Gehen wir davon aus, wir haben unseren Web-/Nextcloud-Server genügend abgesichert, und wir erhalten unsere A+ bei SSL Server Test (Powered by Qualys SSL Labs) oder ähnlichem, ist unser System trotzdem nicht abgesichert. Da nun sich der Hacker nur noch eben auf diese offenen Ports konzentrieren muss.

Heisst er/sie versucht nun, durch geschickte Manipulationen, den HTTP/HTTPS Traffic so zu verändern (gerade beim alten TLS1.0,1.1), damit er/sie auf unserem System Schreibrechte erhält oder zumindest die privaten Daten lesen kann. Und genau bei dieser Traffic Manipulation hilft keine ufw (OSI Modell 3/4), da der eigentlich Traffic nicht analysiert wird.

Hierzu benötigen wir eine Layer (OSI-Modell) 7 Firewall, der eben genau diesen Traffic untersucht, und den Angriff dann blockiert. Entweder kauft man sich eine Firewall wie z.B. eine Fortigate, Checkpoint etc. (sehr teuer, besonders das Lizenzverfahren), oder man benutzt die kostenlose OpnSense (braucht viel einarbeit).

Hier mal ein Beispiel welches ich vor kurzem durchgeführt habe, um genau auf dieses Hackerverhalten hinzuweisen:

Ich habe am 21.2.24 einen NGINX Nexcloud ins Netz freigegeben, mit 2FA, Nextcloud GeoBlocking, Web-Server gehardet, Let’s Encrypt Zertifikat, SSL Teststelle meldet A+. Fertig gestellt um 23:30. Die ersten Angriffe kamen schon 14! Minuten später:

Hier ein Auszug aus meinem Firewall Log

The following intrusion was observed: SystemBC.Botnet.
date=2024-02-21 time=23:44:42

The following intrusion was observed: Mirai.Botnet.
date=2024-02-22 time=23:50:36

The following intrusion was observed: FritzBox.Webcm.Unauthenticated.Command.Injection.
date=2024-02-23 time=10:03:27 

The following intrusion was observed: Generic.XXE.Detection.
date=2024-02-23 time=16:42:25

The following intrusion was observed: D-Link.Devices.HNAP.SOAPAction-Header.Command.Execution.
date=2024-02-23 time=16:48:49

The following intrusion was observed: PHPUnit.Eval-stdin.PHP.Remote.Code.Execution.
date=2024-02-23 time=16:46:49

The following intrusion was observed: PHPUnit.Eval-stdin.PHP.Remote.Code.Execution.
date=2024-02-23 time=16:55:09

The following intrusion was observed: Apache.Solr.SolrResourceLoader.Directory.Traversal.
date=2024-02-23 time=17:01:43

The following intrusion was observed: Zyxel.zhttpd.Webserver.Command.Injection.
date=2024-02-23 time=17:50:51

The following intrusion was observed: Multiple.Routers.GPON.formLogin.Remote.Command.Injection.
date=2024-02-23 time=19:16:46

The following intrusion was observed: Bladabindi.Botnet.
date=2024-02-23 time=20:54:36

The following intrusion was observed: SystemBC.Botnet.
date=2024-02-24 time=16:53:07

The following intrusion was observed: Gh0st.Rat.Botnet.
date=2024-02-24 time=17:17:59

The following intrusion was observed: Generic.XXE.Detection.
date=2024-02-24 time=18:52:46

The following intrusion was observed: PHPUnit.Eval-stdin.PHP.Remote.Code.Execution.
date=2024-02-24 time=18:59:01

The following intrusion was observed: PHPUnit.Eval-stdin.PHP.Remote.Code.Execution.
date=2024-02-24 time=19:06:35

The following intrusion was observed: Apache.Solr.SolrResourceLoader.Directory.Traversal.
date=2024-02-24 time=19:12:09

The following intrusion was observed: D-Link.Devices.HNAP.SOAPAction-Header.Command.Execution.
date=2024-02-25 time=02:38:37

The following intrusion was observed: Multiple.Routers.GPON.formLogin.Remote.Command.Injection.
date=2024-02-25 time=14:15:26

The following intrusion was observed: Generic.XXE.Detection.
date=2024-02-25 time=20:45:57

The following intrusion was observed: PHPUnit.Eval-stdin.PHP.Remote.Code.Execution.
date=2024-02-25 time=20:49:44

The following intrusion was observed: PHPUnit.Eval-stdin.PHP.Remote.Code.Execution.
date=2024-02-25 time=20:58:18

The following intrusion was observed: Apache.Solr.SolrResourceLoader.Directory.Traversal.
date=2024-02-25 time=21:07:17

Wir sehen hier diverse Angriffe die nur im eigentlichem HTTP/HTTPS Stream erkannt worden sind, und dank meiner Layer 7 Fortigate und durch das IPS (Indruder Prevention System), AV, WebFilter usw. wurden diese Angriffe geblockt, die sonst direkt auf dem Nextcloud Server durchgeführt worden wären.

Man hätte auch das kostenlose SNORT (IPS/IDS) auf dem Nextcloud Server laufen lassen können, aber das frisst nun mal Resourcen, die das System verlangsamen.
Aber immerhin besser, als kein IPS/IDS System.

Daher meine Empfehlung, so wenig wie möglich an das Nextcloud System rankommen lassen, und so viel wie möglich vorher abfangen. Sei es mit einer OpenSense oder einem (teuerem) Fertigprodukt wir Fortigate, Checkpoint, PaloAlto usw.

Aktuell, nach den o.g. Angriffe, konnte ich mein System soweit schützen (einen 100% Schutz gibt es leider nicht, Stichwort Zeroday Angriffe), mit dieser Konfiguration:

Frontend Layer 7 Firewall (Fortigate 81), dabei ist das Nextcloud System in einer eigenen DMZ Zone.
drei Rules:

Rule 1, eine GeoBlocking Rule, die jeglichen Traffic blockt der nicht aus Deutschland ist (kann auch die Nextcloud direkt, aber jeder zusätzlich Service kosten eben Resourcen, und die wollen wir der Nextcloud ja sparen)
Rule 2, eine explizite IP Blocking Rule, die Angreifer aus Deutschland blockt, um das eigene IPS/IDS System zu entlasten
Rule 3, die eigentliche HTTPS/HTTP rule mit den Access zum Nextcloud System reglementiert via IPS/IDS, AV, Web und DNS Filter

Zudem läuft auf meinem Nextcloud noch 2FA, Brute Force Protection und nochmal der Check via ClamAV.

Seitdem ist erstmal Ruhe in den Firewall Logs (OK, hab das Logging auf den Deny Rules ausgeschalten).

Ihr seht, um einen Web-Server (sei es Nextcloud, oder wir auch immer) einigermaßen abzusichern, benötigt es mehr, als nur den einer ufw, und den Nextcloud Schutz Mechanissmen (die im Prinzip schon gut sind, besser als keine zu haben).

Aber, meiner Meinung (und beruflichen Erfahrung) sind sogenannte Frontend Firewall pflicht, wer plant ein System öffentlich frei zu geben.

Es sei noch zu erwähnen, das ein weitere Absicherung ein Reverse Proxy herstellt. Hiezu gibt es sehr viele YouTube Videos zu (NGINX Reverse Proxy).

Um auf die Eingangsfrage dieser Diskussion zurück zu kommen, Ist meine Nextcloud sicher vor Hackerangriffen? Ein klares JEIN. Aber je mehr vorher Abgefangen wird, durch eben eine Layer 7 Firewall, umso sicherer wird es, aber leider eben kein 100% Schutz.

bb77 · February 26, 2024, 1:52pm

Braucht man für eine im Heimnetz gehostete Nextcloud nicht.

Port 80 wird im Apache auf Port 443 weitergeleitet, bietet also keinen zusätzlichen Angriffsvektor.

Wenn du ein A+ hast, funktionieren SSL Downgradeattacken und Attacken gegen TLS1.0,1.1 schon mal nicht, denn wenn du TLS1.0 und 1.1 noch aktiviert hast, kriegst du kein A+.

Was dann meistens so endet, dass man erst mal alle Haken setzt, und dann nichts mehr funktioniert, und man dann entweder ellenlange Ausnahmelisten definiert, oder das Ding wieder abschaltet.

Na dann schauen wir mal:

Eine Windows Schadsoftware. Bist du sicher, dass diese Meldung von eingehendem Traffic verursacht wurde, und sich nicht eine Kiste in deinem Netzwerk, dieses Ding bereits eingefangen hat? https://www.fortiguard.com/encyclopedia/ips/49827/systembc-botnet

Ok das könnte eine tatsächliche Gefahr sein, in der Praxis sagt aber schon der Name “Generic”, dass da eine aktuelle Nextcloud auf einem aktuellen OS mit einem aktuellen Apache oder NGINX, der vernünftig konfiguriert ist, ziemlich sicher nicht anfällig ist dagegen.

Benötigt uralte PHP Versionen: Intrusion Prevention | FortiGuard

Der Rest sind Angriffe auf spezifische Geräte oder Softwareprodukte, die man sowieso nicht direkt aus dem Netz erreichbar machen sollte, und die dazugehörigen Lücken auch längst gefixt sein sollten, wenn man seine Software und Geräte regelmässig patcht.

Macht vom Konzept her Sinn, da die grössere Gefahr sowieso von irgendwelchen Windowskisten im LAN ausgeht …aber auch dafür braucht man kein Layer 7 IDS/IPS. Normale Netzwerksegmentation mit VLANS oder mehreren physischen Ports in der pfSense oder OPNsense genügen für das.

Da würde ich Homelabbern folgendes empfehlen, anstatt einfach stur Geoblocking zu betreiben: https://www.crowdsec.net/

Kann man z.B. in Verbindung mit einem Reverse Proxy in der “DMZ” verwenden.

…oh und Geoblocking funktioniert auf IP Basis, braucht also keine Layer 7 Firewall.

Antivirus, macht man imho am besten auf den Clients. Hat man viele öffentliche Freigaben, wo viele Leute alles mögliche hochladen können, kann aber ein ClamAV auf dem Nextcloud Server als Ergänzung Sinn machen.

EDIT: Kleine Ergänzung / Erklärung:

Ich spreche hier von Heimanwendern und “Homelabs”. In Firmen wird man wahrscheinlich IDS/IPS einsetzen wollen, alleine schon um “compliant” mit irgendwelchen Regelwerken zu sein.

Norman_Energy · February 26, 2024, 3:48pm

Hallo bb77,

vielen Dank für dein Feedback, und stimme hier zu, wenn es sich um einen internen Homeserver handelt, ist eine Layer 7 FW nicht nötig.

Die Ausgangsfrage war aber: "…https ist aktiviert und Zugriff über Extern ". Somit macht die Nutzung von IPS/IDS System sinn.

Und in der Tat, waren alle gezeigten Firewall angriffe auf das Nextcloud System. Was Port 80 angeht, ist das nur für das Let’s Encrypt Zertifikat nötig, kann nachher abgeschaltet werden, und erst wieder eröffnet bei einem Renew des Zertifkats. Hat nichts mit dem weiterleiten auf HTTPS zu tun bzw hatte ich damit nicht gemeint.

Das erwähnen von TLS1.0 und TLS1.1 war nur ein Hinweis und hatte jetzt nichts mit dem A+ Result zu tun. Hier hätte ich bestimmt besser ausdrücken können.

Das mit allen Haken setzen und das wieder abschalten mag zwar für Anfänger das normale Szenario zu sein, eine Layer 7 FW ist aber auch nichts für Anfänger und benötigt hier ein gutes Grundwissen der Materie. Im allgemeinen sind IPS/IDS Systeme am Anfang nicht einfach zu verstehen. Hier gebe ich dir recht.

Nochmals, die gezeigten Firewall Logs zeigen die Angriffe an, seitdem mein System “Online” ging, heisst nicht das diese Erfolgreich waren. Sie sollten nur als Beispiel gelten wie schnell ein Angriff passiert und was versucht wird. Diese Angriffe sieht man nicht in den normalen OS Logs, wenn kein IPS/IDS aktiv ist.

Es ist schön zu lesen, das du von Netzwerksegmentation mit VLANs spricht, oder mehrere physischen Netzwerk Ports eine pfSense oder OPNsense, aber das verhindert nur den möglichen Zugriff auf Produktion Device von einer DMZ aus, nicht aber den Angriff auf das System selber.

Und natürlich funktioniert GeoBlocking via IP Subnetze, hier erwähnte ich nur den Mix aus einigen Möglichkeiten von reinem IP Blocking bishin zum Layer 7 blocking via certificate-inspection.

Aber auch mit deinem Feedback ist ersichtlich, das man ohne größeres IT Sicherheit heute keinen privaten WEB-Server ins Internet stellen sollte. Nochmals erwähnt, ich bezog mein Feedback auf die Ausgangsfrage, eine Nextcloud Server sicher(er) extern freizugeben.

bb77 · February 26, 2024, 4:07pm

Und spezifisch von letzterem ich halt nicht so ein grosser Fan, und irgendwann Encrypted SNI grossflächig eingeführt weden sollte, kannst du das privat sowieso vergessen, dann funktioneiren nämmlich alle Prosumer IDS Systeme mit automagischer “HTTPS Inspektion”, die man mit einem Haken aktivieren kann, analog “Splice ALL” in der pfSsense nicht mehr, ausser du installierst Zertifikate auf allen Endgräten, aber wer macht das schon zuhause.

Und auch Firmen müssen sich mittelfristig andere Lösungen überlegen, denn mit HTTP3/QUIC wird auch das schwieriger, wenn nicht unmöglich werden. Endpointprotection wird einen noch höheren Stellenwert einnehmen, oder man wechselt endgültig auf rein webbasierte Anwendungen, und riegelt die Geräte der User so ab, dass der Anwender ausser einem Browser nichts mehr öffnen kann und auch nichts mehr lokal speichern kann.

Aber ich schweife ab…

Betreffend Serversicherheit:

Etwas wie Crowdsec oder auch einfach nur Fail2ban sollte eigentlich reichen für privat. Oder du machst Cloudflare davor, wovon ich auch kein Fan bin.

Wichtiger als solche Dinge, ist imho, dass man den Server selbst sicher konfiguriert, sichere Passwörter und 2FA verwendet und alles up to date hält. Ich meine, der Server soll ja erreichbar sein, und dafür ist er auch gemacht.

Falls er das nicht zwingend sein muss oder man sich einen einen sicheren Betrieb nicht zutraut, macht man ihn besser gar nicht erst aus dem Internet erreichbar, und nutzt ein VPN oder ein Overlay Network wie ZeroTier oder Tailscale für den Remotezugriff. Denn ganz ehrlich, bei grober Fehlkonfiguartion, oder einem ZeroDay, würde ich mich nicht darauf verlassen wollen, dass ein IDS den Angriff blockt

linux-helmut · February 26, 2024, 4:28pm

Ist das Freischalten von Port 80 nicht schon fahrlässig?
Für die Erstellung und Erneuerung von Zertifikaten bedarf es Port 80 nicht mehr.

Wer seine Nextcloud schützen möchte betreibt sie hinter einem transparenten Proxy.
Wer seine Nextcloud nur wirklich für sich nutzen möchte, kann das über VPN machen und die Nextcloud nicht “frei geben”.

Das sind schon die simpelsten Methoden, welche neue User nicht abschrecken oder sie vor “unmöglichen” Lösungen stellen.
So einfach wie möglich und so sicher wie nötig.
Da gibt es dann keine Eierlegendewollmilchsau sondern nur individuelle Lösungen für jeden einzelnen.

bb77 · February 26, 2024, 4:33pm

I denke nicht, denn was soll mit folgender Konfiguartion schon passieren, was nicht auch direkt auf Port 443 passieren könnte:

<VirtualHost *:80>
Servername cloud.domain.tld
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =cloud.domain.tld
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Ich meine diese Frage durchaus ernst. Wenn mir jemand klar aufzeigen kann, dass ich mit so einer Konfiguration deutlich unsicherer unterwegs bin, als jemand der Port 80 geschlossen hat, mache ich Port 80 sofort zu.

Norman_Energy · February 26, 2024, 4:38pm

Dein letzter Absatz gefällt mir und entspricht auch meiner persönlichen Meinung. Wer ab und zu mal seine Daten mit einer Nectloud von außerhalb synchronisieren möchte, sollte ein VPN Tunnel benutzen, und dann seine Daten mit der internen Nextcloud abgleichen.

Und natürlich sind IPS/IDS System sind nur so gut wie Ihre Signaturen aktuell sind. Glaub mir, ist mein tägliches berufliches Brot, solche Signaturen zu erstellen und weiß was für ein Rennen wir täglich machen.

Das Thema HTTP3, sowie die Teilverschlüsselung des TLS-Handshakes und jetzt schon QUIC, sind Themen die uns SecEngs vor einigen Herausforderungen stellt bzw. noch stellen wird.

Norman_Energy · February 26, 2024, 4:57pm

Danke für den Hinweis linux-helmut. Inzwischen fand ich diesen Post, der das genauer erklärt:

https://community.letsencrypt.org/t/is-port-80-required-for-renewals/121432

bb77 · February 26, 2024, 5:15pm

Jup. Ich nutze certbot direkt in der VM, in der auch Apache und die Nextcloud läuft, weil ich keinen separaten Reverse Proxy nutze (kommt vielleicht irgendwann noch), und ich nutze ihn mit HTTP-validation weil ich keinen DNS Provider nutze, der eine API anbietet (kommt vielleicht irgendwann auch noch), und ich nicht manuell erneuern will alle drei Monate, und auch nichts scripten will, das mir Port 80 automatisch öffnet und wieder schliesst.

…unabhängig davon sehe ich aber immer noch nicht, wie das Schliessen eines Ports, hinter dem nichts passiert, ausser dass ein 302 Statuscode rausgehauen wird und ein Rewrite auf HTTPS stattfindet, meine Sicherheit erhöhen soll.

linux-helmut · February 27, 2024, 3:59pm

In erster Linie geht es darum, so wenig Angriffspunkte wie möglich zu liefern. Port 80 ist überflüssig, da das was da noch statt findet auf andere Wege lösbar ist.

Eine Firewall wie UFW macht dein System nicht sicherer, aber es setzt genau hier an und minimiert diese Angriffspunkte. Letztendlich hast du noch Port 443 übrig und kannst hier mit anderen Diensten ansetzen.

Mal eben 1000 Pings pro Sekunden auf den Port und das System ist lahm gelegt. An dieser Stelle kann dir ein Proxy dienen, da dieser und nicht dein System leiden muss.

Das sind alles simple Schritte dein System “sicherer” zu machen.

Wenn Port 80 geschlossen und per Firewall “gedropt” wird, ist das schon ein weiterer Schritt.
Eine wirklich gute Absicherung entsteht nur durch einzelne Schritt, bei denen jeder wichtig werden kann.

Sorry sorry sorry ABER:
In der Faulheit leidet deine Sicherheit!

Eines meiner “alten” Konfigurationen:
*Apache als Proxy only in einer VM
*Certbot mit DNS-01 in einer eigenen VM
*Nextcloud + Apache in einer VM
*meherer andere NExtclouds zum Testen in eigenen VMs
*usw.

bb77 · February 27, 2024, 4:18pm

Ja das ist prinzipiell richtig, aber in meiner Frage geht es mir konkret darum, ob ich mit der obigen Konfiguration deutlich sicherer wäre, wenn ich Port 80 schliessen würde.

Ja da stimme ich zu, aber soweit waren wir ja schon.

Naja, dann DDOSd der Angreifer halt Port 443, und ja, wenn Port 80 auch noch offen ist, kann er gegebenenfalls auch darauf nochmal 1000 Pings abfeuern. Aber bei einem DDOS wäre ja erst mal nur die Verfügbarkeit eingeschränkt und noch nicht unbedingt die Sicherheit.

Ja das ist geplant, und wird irgendwann umgesetzt… Ob es dann Apache, NGINX oder gar HA-Proxy wird, habe ich noch nicht endgültig entschieden.

Der ACME client wird dann ziemlich sicher in der selben VM sitzen wie der Reverse Proxy. Wir wollen es ja nicht übertreiben.

Habe ich bereits, und die öffentlich erreichbare produktive VM mit Apache und Nextcloud und die Testserver sind jeweils in ihren eigenen Netzwerksegmenten, und dürfen nicht miteinander sprechen.

linux-helmut · February 27, 2024, 5:01pm

Früher war es eine beliebte Methode, das System über Port 80 mit DDOS so zu überfordern, dass es auf 443 einen Fehler macht. Also erübrigt sich diese Frage.
Ob dein Apache auf Port 80 ein Hintertürchen hat… Da könnte man stundenlang deine Konfigurationen durch forsten. Die Konfig für deine Site ist da ja nicht alleine für entscheidend.
Früher gab es im Darknet diverse Tools um Server “anzugreifen”. Aber das ist schon ein paar Jährchen her.

Systeme, die an die Grenzen ihrer Leistung gebracht werden, können Fehler machen.
Genau hier drauf zielen diese Programm.

Warum nicht? Der Client kann somit nicht unter der Überlastung des Proxys leiden.
Der Proxy soll auch Proxy sein und nichts anderes. Auch sollte die VM vom Proxy eine Leistungsbeschränkung haben, um nicht das Hostsystem lahm zu legen.

Wie gesagt, es sind alles kleine Schritte für ein wenig mehr Sicherheit und Zuverlässigkeit.
Das NonPlusUltra und die Eierlegendewollmilchsau gibt es nicht.

Deine Sicherheit ist ein Eimer voll Schritte und mit allem was du nicht oder noch nicht möchtest nimmst du eine Handvoll raus.
Port 80 muss kein Sicherheitsproblem sein, kann aber eine Angriffsflanke werden um Port 443 zu schwächen. So solltest du es vielleicht mal betrachten.

linux-helmut · February 27, 2024, 5:09pm

Du kannst hier aber noch einen Schritt weiter gehen und Port 80 auf einer andern VM laufen lassen. So laufen Port 80 und 443 jeweils autark.

bb77 · February 27, 2024, 5:21pm

Weil ich nicht für jeden Dienst eines Dienstes eine separate VM hosten möchte. Das ist a) zu ressourcenintensiv, und b) denke ich auch, dass es sicherheitstechnisch voll okay ist, den ACME Client dort zu betreiben, wo auch die Zertifikate deployed werden. Auch erhöht ein separater ACME Server die Komplexität und dann muss man die Zertifikate ja auch noch irgendwie auf den Proxy pushen. Ja klar, alles machbar, aber eher nicht nötig imho.

Deshalb werde ich mittelfristig den Plan mit dem separaten Reverse Proxy auch weiterverfolgen, auch weil man damit flexibler ist, wenn man mal noch andere Dinge extern verfügbar machen möchte ausser der Nextcloud. Und spätestens dann ist es warscheinlich besser, wenn man das nicht in der selben VM und dem selben Webserver verwaltet, in der/hinter dem auch die Nextcloud läuft.

Theoretisch könnte ich das auch auf der pfSense mit HA-Proxy machen, aber etwas, was direkt auf meiner Firewall läuft öffentlich erreichbar zu machen, gibt mir erst recht kein gutes Gefühl.

Momentan nutze ich den HA-Proxy auf der pfSense aber für ein paar rein interne Dienste (*.local.meinedomain.tld), und ja da muss ich alle drei Monate manuell einen TXT Record erstellen, um die Certs zu erneuern. Das will ich für den Nextcloud Server nicht auch noch machen.

Bevor also das “public facing” Reverse Proxy Projekt starten kann, muss ich zuerst mein DNS fernsteuerbar kriegen, oder ich lasse dann halt auch auch auf dem Reverse Proxy Port 80 wieder offen.

wwe · February 28, 2024, 10:49am

Ich verstehe immer noch nicht ganz warum Port 80 ein Problem darstellen soll, aber auch dafür gibt’s eine Lösung: ACME TLS-ALPN-01 challenge erlaubt das ausstellen und erneuern der letencrypt Zertifikate ohne Port 80 rein über 443. Bei mir hat es mit traefik tlsChallenge nicht (auf Anhieb) funktioniert evtl weil ich CNAMEs verwende… habe aber nicht lange versucht…

bb77 · February 28, 2024, 10:57am

Ich auch nicht, oder sagen wir mal prinzipiell hat @linux-helmut natürlich recht, dass man so wenig wie möglich offen haben sollte. Aber in diesem Fall denke ich, dass wenn überhaupt, nur ein sehr geringes zusätzliches Risiko besteht und es daher absolut vertretbar ist, Port 80 offen zu haben, wenn dahinter alles richtig konfiguriert ist.

Kann ich mit meinem Setup schon wegen folgendem aus deinem Link nicht nutzen:

Cons:
It’s not supported by Apache, Nginx, or Certbot, and probably won’t be soon.

Jup ich auch, weil dynamische IP Adresse am Heimanschluss und dann ein CNAME für cloud.meinedomain.tld auf meindyndnsname.afraid.org.

linux-helmut · February 28, 2024, 1:53pm

Warum legt ihr nicht eine Subdomain an und gibt hier das Ziel an?
Der CNAME läßt sich auslesen und somit ermitteln, dass ihr hinter einer DynDNS seid. Mit der Subdomain ist das nicht der Fall.
Also bei mir hat Certbot mit DNS-01 viele Jahre hervorragend funktioniert. Auch läßt sich die Existenz der DynDNS verbergen.

Ich würde hier nicht über HTTPS only schreiben, wenn es die letzten Jahre nicht funktioniert hätte

Das sind wir wieder bei dem Eimer voll mit Sicherheit und wieder wurde eine Handvoll heraus genommen.

wwe · February 28, 2024, 4:10pm

Ich habe das Gefühl dass du die Begriffe CNAME und subdomain nicht ganz verstanden hast. IP Adressen sind komplet unabhängig vom DNS und oft sind die IPs der residential Kunden sogar per DNS reverse lookup auf den 1. Blick erkennbar - mit etwas Glück kann man sogar die Region/Stadt erkennen.

wenn du die letzten Nachrichten durchlesen würdest erkennst du dass wir von TLS-ALPN-01 gesprochen haben - ein ganz anderes Verfahren.

Sicherheit entsteht nicht durch verbergen: google nach “Security by obscurity” sondern durch regelmässiges Patchen und sichere Konfiguration. Es ist Blödsinn dass ein offener Port 80 mehr oder weniger Sicherheit bedeutet - es kommt darauf an was hinter dem Port passiert. Port 80 wo ein Webserver/Proxy einen https redirect macht ist nicht weniger sicher als der entsprechende Port 443!