Ja aber wenn du einen 301 auf https machst, ist ja dann die Nextcloud erreichbar. Warum nicht einen 404 servieren? So könntest du Port 80 dauerhaft offen lassen, und niemand würde deine Nextcloud erreichen. Oder mache ich da einen Denkfehler?
Der einzige Nachteil, den ich damit sehe, ist, dass du das Erneuern der Zertifikate nicht automatisieren kannst. Oder geht das Öffnen des Ports irgendwie über eine API in deinem Router und einem Skript?
Die DNS Challenge geht vollautomatisch (wenn dein DNS Provider eine API anbietet), und du musst gar keine Ports dafür öffnen, auch nicht für 90 Sekunden.
Wenn die DNS-Challenge aus irgendeinem Grund nicht genutzt werden kann und Port 80 nicht dauerhaft auf den Nextcloud-Server weitergeleitet werden soll, aber auch nicht alle 60–90 Tage manuell geöffnet werden soll, könnte man das natürlich auch komplett separieren. Man könnte eine separate Server-/VM-Instanz bereitstellen, auf der nur Certbot oder ein Webserver wie Caddy läuft. Dann könnte man Port 80 dauerhaft auf diese VM weiterleiten und die Zertifikate über Skripte auf die anderen Server/VMs verteilen, auf denen die Applikationen laufen.
Ein vielleicht kleiner Nachteil ist noch, dass der weltweite Name cloud.domain.tld einer IP-Adresse zugewiesen ist und im ganzen Internet auflösbar ist bzw. sein muss. Da diese IP-Adresse wiederum im Normalfall dynamisch ist, braucht man auch noch einen DynDNS-Service oder muss die IP-Adresse immer manuell setzen, da sie sich ja zwischen den Rezertifizierungen ändert. Ich für meinen Fall nutze daher einen DynDNS-Server und mein Name cloud.domain.tld verweist auf die DynDNS-Adresse per CNAME. Mag aber einfachere Lösungen geben.
Meiner persönlichen Auffassung nach ist das sowieso eine mehr oder weniger theoretische Diskussion. Wer seine Nextcloud nur im eigenen LAN oder maximal noch per VPN erreichen will, kann doch auch selbst signierte Zertifikate nutzen. Dann sagt man dem Browser und Clients einmal, dass man denen vertraut (hat man ja selbst erstellt) und gut is.
Ich persönlich will aber mehr von einer Nextcloud. Also Kalender und Adressbuch auch auf mobilen Geräten nutzen, statt Kalender und Adressbuch von Google oder der Apfelfirma. Daher ist meine Nextcloud auch aus dem Internet erreichbar, sonst macht das ja keinen Sinn.
Allerdings ist meine Nextcloud nur per IPv6 aus dem Internet erreichbar, aber nicht per IPv4. Warum? Es gibt 340 Sextillionen IPv6-Adressen. Ich wünsche allen viel Spaß und vor allem ein seeehhhr langes Leben, die versuchen sollten per Portscan die mir täglich vom ISP (Zwangstrennung) neu zugewiesene IPv6-Adresse unter diesen 340 Sextillionen IPv6-Adressen herauszufiltern und zu finden.
Hoffentlich teilst du keine Shares mit Dritten. Vor allen nicht mit Freuden, die virenverseuchte Windows-Rechner verwenden, die alles wie z. B. Servernamen an die Angreifer weiterleiten. Ach es gibt Hunderttausende bis Millionen an Nextcloud-Instanzen. So oft wird man nicht angegriffen, oder? Und wenn doch ist der erste Angriff bestimmt auf /status.php. Also immer schön aktuell halten.
Nein es ist keine theoretische Diskussion, wie du siehst. Es gibt Leute, die wollen ihre Dienste oder gewisse Dienste nur lokal oder via VPN nutzen, und aber trotzdem global signierte Zertifikate nutzen. Warum ist doch am Ende des Tages egal. Abgesehen davon habe ich Gründe dafür genannt, und auch wenn die für dich banal sein mögen, kann man doch Möglichkeiten aufzeigen, wie man das, möglichst automatisiert realisieren kann.
Und geanu dafür brauchst du z.B. gültige HTTPS Zertifikate! Und klar kann man den Kalender und die Kontakete auch über ein VPN synchronisieren, und einigen reicht es vielleicht schon, wenn die einfach am Abend synchronisiert werden, wenn man nach Hause kommt.
Hab’ ichs mir doch gedacht, bereue es schon fast wieder, dass ich meinen Post oben korrigiert habe.
Aber ja, ich mache es auch so. Ich sehe aber durchaus auch Gründe es nicht so tun, und sicherer ist es dann auf jeden Fall.
Security by Obscurity also. Kann helfen die Logs clean zu halten, viel mehr aber auch nicht.
Das übernimmt Let’s Encrypt bereits für dich: https://crt.sh/
Das ist aber kein Problem, denn alles, was aus dem Internet erreichbar ist, ist per se öffentlich und kann nicht wirklich versteckt werden. Starke Authentifizierung, und Dinge wie Fail2Ban und/oder die eingebaute Brute-Force-Protection sowie natürlich Patchen sind am Ende des Tages die einzigen Dinge, die dich wirklich schützen.
Einfach nochmal um klarzustellen wie das alles gemeint war.
Mir ging es lediglich darum, aufzuzeigen, wie man gültige Zertifikate installiert, ohne dabei Ports zu öffnen oder Nextcloud (oder andere Dienste) aus dem Internet erreichbar zu machen.
Ich möchte hier weder jemanden davon überzeugen, seine Nextcloud nicht aus dem Internet erreichbar zu machen, noch sie erreichbar zu machen. Am Ende des Tages muss jeder seine Risikotoleranz selbst einschätzen. Fakt ist: Wenn man Dinge öffentlich macht, besteht immer ein gewisses Risiko. Wenn es sich also vermeiden lässt, ist „nicht erreichbar machen” zunächst einmal die bessere Wahl.
Konkret bei Nextcloud denke ich, dass sie grundsätzlich “on top of security” sind, man sie (minus des immer bestehenden Restrisikos) also erreichbar machen kann, sofern man alle gängigen Security-Best-Practices anwendet und seine Instanz regelmässig patcht. Wenn man aber Zweifel hat, spricht auch nichts dagegen, es nicht zu tun, und wenn einem die Zeit und/oder das Wissen fehlt, um es “richtig” zu machen, ist es auf jeden Fall besser, ein VPN zu nutzen.
Bei anderen beliebten Anwendungen, die von vielen Homelabbern genutzt wreden, die oft von Hobbyisten (no offense) entwickelt werden, und ganz Wichtig! Bei Management-Interfaces, würde ich das aber nicht tun. Daher nutze ich persönlich dort ein VPN und die DNS-Challenge, um diese Apps und Interfaces mit Zertifikaten zu versorgen.
Würden die meisten dieser Dinge auch mit selbstsignierten Zertifikaten funktionieren? Sicher, aber ich möchte halt gültige Zertifikate haben.
Genau, weil sich deine MAC geändert hat. Hättest du eventuell auch auf die alte Adresse spoofen können.
Klar. Ich sprach zwar von der certbot http challenge, aber ja.
Stimmt auch. Nur würde ich dann http anstelle von DNS verwenden, weil einfacher. Für wildcard muss ich DNS verwenden.
Finde ich auch nett. Darum macht mein reverse proxy das auch. Ab das hintenrum dann mit http oder https läuft halte ich aber für egal.
Und wenn man vergisst den VPN zu patchen, ist der Angreifer gleich im ganzen Netz
Nicht falsch verstehen, bin völlig mit dir einverstanden. Ich sehe nur VPN nicht als das angepriesene Allheilmittel an, während Port 443 auf einer Fritte zu öffnen angeblich fürchterlich gefährlich ist.
Grundsätzlich hast du natürlich recht und man verlagert das Risiko so an einen anderen Eingangspunkt.
Aber…
Ich traue den Entwicklern eines VPN-Protokolls, dessen einzige Aufgabe es ist, eine sichere Verbindung herzustellen, eher, dass sie „on top of security” sind, als irgendwelchen App- und Webentwicklern.
Genau deshalb will man eben auch im LAN starke Authentifizierung und verschlüsselte Verbindungen haben.
Der Trend geht onehin von Firewalls richtung “Zero Trust” (ja ich weiss, Buzword-Alarm) Aber vereinfacht gesagt bedeutet das, Identitätsbasierte Zugangskontrolle anstatt rein netzwerkbasierte. Das setzt aber voraus, dass auch im LAN alles so abgesichert ist, als wäre es öffentlich erreichbar, weil dann hat es ein Angreifer schwer, selbst wenn er irgendwie einen Weg in dein Netz gefunden hat.
Die Frage ist immer welchen Grad an Sicherheit man erreichen will bzw. welches Risiko man eingehen will. Ich weiß gar nicht wie viel Promille Alkohol man aktuell zum Auto fahren noch trinken darf. Aber schon der erste Tropfen stellt ein erstes Risiko dar. Komisch, dass dieses Risiko auch gegenüber Dritten z. B. Kindern im Straßenverkehr vielen so wenig bedeutet. Da schaut man dann vielleicht doch lieber auf das was vom Gesetz gerade noch erlaubt ist. Wird wohl nichts passieren.
Ja, wenn ich ehrlich bin bin ich früher auch noch alkoholisiert Auto gefahren, immer im erlaubten Bereich, der in der Schweiz damals noch 0.8‰ betrug, was aber natürlich deutlich zuviel ist, um noch angemessen zu reagieren in einer Notsituation. Zum Glück ist nie etwas passiert.
Mittlerweile gilt für mich 0,0 ‰, wenn ich fahre. Und ja, ich habe auch zunehmend Mühe mit dem, wenn man böse sein will, schon fast menschenverachtenden Mindset gewisser Leute, das du beschreibst. Das liegt gerade in ländlichen Gebieten aber auch daran, dass das Auto bei der Infrastruktur- und Zonenplanung immer noch viel zu viel Priorität hat und zu wenig in den ÖV investiert wird, wobei, zumindest in der Schweiz ist es mittlerweile schon viel besser als noch vor 20 oder 30 Jahren.
Jetzt sind wir aber komplett offtopic hier
Um wieder auf das IT-Thema zurückzukommen. Vor 20 Jahren, hatte ich auch mal noch eine Weile einen RDP Port offen im Internet, um von ausserhalb auf meinen PC zuzugreifen, und es ist nie etwas passert. Würde ich heute auch nicht mehr machen.
Die Frage ist wirklich, ob heute so viel passiert. Ich denke wenn man zuhause seine Nextcloud mit Lets Encrypt Zertifikat, aktuellem Ubuntu/Debian (damit auch aktuellem Apache2 oder nginx, MariaDB, PHP, …) sowie aktuellem Nextcloud einsetzt, so ist es NICHT unsicherer als eine Managed Nextcloud im Internet. Gerne kann mich jemand davon überzeugen, dass eine Firewall, die TCP 443/80 erlauben muss, zusätzlich hilft. Oder irgendein wichtiges Hardening. Das glaube ich nicht. Ok vielleicht bei gezielten Überlastungen … aber nicht gegenüber irgendwelchen Hackern.
Zurück zum Auto. Viele Leute wechseln selbst ihre Autoreifen und wuchten sie nicht aus. Das erscheint mir weit kritischer als eine On-Prem Nextcloud.
Bin einem Security Typen auf twitter gefolgt, der hat dazu eingeladen seine public RDP anzugreifen. Der Trick ist einfach bessere Einstellungen zu verwenden. Microsoft ist schon schlecht, aber noch viel schlechter sind deren defaults.
War an einem Windows Server 2025 Tech Talk, da wurde doch tatsächlich der neue default Login delay als ein neues geiles Feature verkauft. Wow, der Angreifer kann nicht mehr brute forcen, weil es einen 5s delay gibt
Selbstverständlich war es aber wichtiger Windows Server 2025 einen Security Ai Clippy zu geben, um damit schlechte defaults anzupassen. Durchgehen gute defaults von Beginn weg, wäre auch zu viel verlangt /s
Nein, ist es nicht, und ich denke das kann man so machen, und ich mache es ja auch.
Nein. Wenn du einen Router hast, der regelmässig Sicherheitsupdates erhält, wie z.B. eine FritzBox, kannst du die Ports weiterleiten und ene zusätzliche Firewall ist nicht nötig, um die Nextcloud von aussen zu schützen.
Die Firewall kann aber nützlich sein um das Netzwerk intern zu segemntieren. Ich habe z.B. ein separtes IOT Netzwerk, ein separtes Netzwerk für trusted Devices wie z.B.meinen PC, ein separtes Management Netzwerk und auch die Dienste, die aus dem Internet erreichbar sind, befinden sich in einem eigenen Netzwerksegment, welches keinen Zugriff auf andere Netzwerksegmente hat.
Braucht man das alles? Warscheinlich nicht, aber falls wirklich mal jemand reinkommt, kommt er zumindest nicht gleich überall hin.
Das schon eher, und das wird umso wichtiger, wenn man obiges nicht hat
Aber auch da muss man realistisch bleiben. Jeden einzelnen Service auf einem Linux Server extra zu härten mit Tools wie SELinux etc pp, ist nicht realitisch für Heimuser, und warscheinlich selbst für viele Profis im KMU Umfeld nicht. Aber Dinge wie Zertifikate, überall starke Passwörter und wenn möglich 2FA, und vielleicht noch eine lokale Firewall auf dem Linux Servern wie UFW, um sicher zu sein, dass wirklich nur die Ports offen sind, die benötigt werden, sind mittlerweile so einfach zu installieren bzw. zu managen, dass man das doch auch für interne Dienste einfach machen kann.
Das grösste Einfallstor, sowohl bei Privatusern wie auch in Firmen befindet sich aber immer noch auf Layer 8. User, die Malware auf ihre Clientgeräte herunterladen und installieren, auf Phishing hereinfallen usw.
Das wichtigste “Sicherheitsfeature” für Privatpersonen, welches leider oft vernachlässigt wird, sind aber imho Backups, so dass man keine Daten verliert, wenn wirklich mal etwas passiert. Sei es weil man “gehackt” wurde oder viel warscheinlicher, weil man selbst einen Fehler gemacht hat, oder die Platte auf der die Daten liegen den Geist aufgegeben hat.
Dabei aber bitte folgendes nicht vergessen:
Ungetestete Backups sind keine Backups! Synchronisation ist kein Backup! RAID ist kein Backup! Ein Backup auf der gleichen Platte, dem gleichen Gerät, und wenn man wirklich 100% sicher sein will, auch im gleichen Gebäude oder gar der gleichen Region ist kein Backup!
Ja, bei Microsoft scheint die Sicherheit bei allem irgendwie immer nur ein „Afterthought“ zu sein. Erst mal Features raushauen und danach schauen, wie man sie sicher kriegt.
