Tja, und du vergisst IPv6. Das wird geroutet und wegen CG-NAT / DS-Lite und Mangel an noch verfügbaren IPv4-Adressen immer unvermeidbarer.
Ich ignoriere mal die persönliche Ebene und bleibe auf der Sachebene.
Professionell lässt sich so ziemlich alles zerlegen. Die Frage ist halt eher, was ist das schwächste Glied in einer Kette bei einem Homeuser? Ganz sicher nicht die Fritte.
Was beim zero trust Ansatz auch egal ist.
Ok, meine Smarte Glühbirne wurde gehackt.
Was nun?
Was will sie mit meiner Nextcloud Instanz anstellen?
Eine Sicherheitslücke über 443 ausnutzen? Das ginge auch von Ausserhalb.
Meine Debian VM angreifen? Ja das geht. Ist das realistisch? Bei Passwort Test1234 für SSH vielleicht. Ansonsten eher schwierig.
Also ich würde mal sagen in 90% der Heimnetze mit Fritten finden sich im LAN / WLAN Windows Notebooks / PC. Wäre ich also bis zu deiner smarten Beleuchtung gekommen, würd’ ich die suchen und als nächstes versuchen zu übernehmen. Herstellerseitig eingebaute Schwachstellen bieten die Betriebssysteme aus Redmond ja genug.
Die Lösung dafür heisst DNS-01-Challenge: Challenge Types - Let's Encrypt
Das lässt sich auch automatisieren. Voraussetzungen dafür sind:
Man kann wohl Nextcloud auch ganz ohne TLS/SSL betreiben. Wenn es sowieso nur intern genutzt wird, könnte man auf die Transportverschlüsselung TLS/SSL verzichten. Auch wenn es dann natürlich wieder interne Angriffsszenarien wie z. B. der genannte verseuchte Windows-Rechner im LAN gibt, so muss man festhalten, dass bei verseuchten Windows-Rechnern Man-in-the-Middle-Angriffe eher unüblich sind, so dass eine Ende-zu-Ende-Verschlüsselung nicht unbedingt notwendig ist bzw. keinen wirklichen Mehrwert bringen.
Ja kommt halt darauf an was für Fetaures und Apps man nutzen möchte. Braucht man es nur für lokales Filesharing, geht das. Aber schon bei Kalender und Kontakte Sync kann es Probleme geben, z.B. auf iOS, wenn ich nicht komplett falsch liege.
Abgesehen davon sollte man im Jahr 2025 einfach weder im LAN noch im Internet unverschlüsselt kommunizieren. Ein Domainname kostet vielleicht 10 € im Jahr, und damit kann man so viele Subdomains hosten, wie man will. Mit der Let’s-Encrypt-DNS-Challenge kann man sogar Wildcard-Zertifikate erstellen.
Ich sehe absolut keinen Grund, es nicht zu tun und sich dadurch potenzielle Sicherheits- oder Kompatibilitätsprobleme einzuhandeln, auch wenn erstere im LAN wahrscheinlich nicht allzu gravierend sind. Letzteres wird hingegen immer mehr zum Problem, da Betriebssysteme und Apps heutzutage in vielen Fällen schlichtweg HTTPS erwarten und HTTP sowie selbstsignierte Zertifikate nicht mehr überall funktionieren.
Letzteres kann man auch mit einer eigenen CA umgehen. Dann muss man allerdings auf allen Geräten die Zertifikate manuell installieren. Das dürfte deutlich mehr Aufwand sein, als ein paar Stunden zu investieren, um zu lernen, wie man einen ACME-Client korrekt für die DNS-Challenge konfiguriert. 
Ich rate auch nicht zum Verzicht auf TLS/SSL im LAN. Aber die Verwendung eigener Zertifikate wird wohl spätestens bei iPhone und Android zum Problem. Daher würde ich ich alles für das IP-Forwarding an der FRITZ!Box konfigurieren und darüber laufen lassen. Man könnte theoretisch es nur aktivieren, wenn man das Zertifikat erneuert. Aber das wird bei Lets Encrypt auch immer öfter.
Ich halte die Angriffsmöglichkeiten aus dem Internet für eher gering. Ich weiß nicht, ob man nicht einfach den Zugriff von weltweiten IP-Adressen irgendwo in Nextcloud sperren kann. Das wäre vielleicht noch eine Option.
Vielleicht einfach alternativ im LAN ein normales NAS mit SMB bzw. CIFS verwenden und auf Nextcloud ganz verzichten. Und fürs Teilen unkritischer Daten im Internet einen kostenlosen Nextcloud-Account irgendwo anlegen. Und wenn die Daten doch etwas kritischer sind eine Verschlüsselung wie z. B. AES-256 bei 7-Zip verwenden. Das ist dann sicherer als egal was - selbst sicherer als das eigene abgeschottene LAN. Bis auf die vielleicht therotisch immer wieder beschriebenen Sicherheitsrisiken wie Verschlüsselung ist auch nicht sicher, ich werde bestimmt angegriffen und die Welt ist doch eine Scheibe.
Ja das ist am einfachsten, mache ich bei der Nextcloud auch so. Ich werde aber den Teufel tun, jemanden zu überreden selbstgehostete Dienste ins Internet zu stellen, wenn die Person das selbst nicht unbedingt will, auch wenn ich Nextcloud, sofern sie immer gepatcht wird, nicht per se für ein Risiko halte.
Ja das wäre eine Möglichkeit, lässt sich aber schlecht automatisieren.
Warum?
Die DNS Challnege wird ja genu für diesen Fall angeboten. Ich nutze sie auch für gewisse interne Dienste, die ich nur über VPN erreichbar mache. Dinge wie Management Interfaces, und gewisse selbstgehostet Apps, denen ich nicht traue, dass die Entwickler genug in die Sicherheit invetieren, um sie bedenkenlos ins Internet stellen zu können. Und nein einfach einen Nginx oder Caddy mit Zertifikaten davor, schützt dich nicht vor allen Expoits.
Ob man Nextcloud wirklich braucht, nur um Dateien intern zu teilen, ist nochmal eine andere Frage. Bei reiner Dateifreigabe würde ein SMB-Share in den meisten Fällen vielleicht tatsächlich reichen. Allerdings kann Nextcloud deutlich mehr als nur Filesharing: Die Integration der mobilen Apps, die Synchronisierung von Kalender und Kontakten, der Texteditor, Nextcloud Office und Talk lassen sich durchaus via VPN verwenden.
Und selbst wenn man nur Filesharing und Dokumentenbearbeitung nutzt, und das ganze nur intern, bietet Nextcloud Vorteile gegenüber SMB-Shares, vor allem (aber nicht nur) auf mobilen Geräten. Wir leben nicht mehr in den 90ern und die Leute sind sich zunehmend gewohnt im Browser und auf mobilen Geräten zu arbeiten. Klassische Desktop-Apps sind eine aussterbende Spezies.
Kann man. Mit ufw / iptables. Allerdings sollte man das dann nur für https (tcp-Port 443) machen und per ufw / iptables nur die IP-Adressen des LAN’s (z.B. 192.168.178.0/24 bei Fritten) freigeben. Für http kann man das nicht machen, wegen Let’s Encrypt. Man kann aber zudem den Webserver der Nextcloud so konfigurieren, dass der eh nur https-Anfragen für die Nextcloud annimmt. Dann geht per tcp 80 nur die Erneuerung der Zertifikate.
Ds stimmt. Ich dachte aber eher an eine App. So wäre es z. B. cool, wenn man von intern also z. B. 192.168.178.0/24 mit Benutzername und Passwort und von anderen Netzen gar nicht oder nur mit 2FA zugreifen könnte. Man müsste ja kein 2FA vergeben. So würde man das Risiko vermeiden, dass jemand z. B. per Windows-Keylogger an die internen Benutzerdaten der Nextcloud gelangt und sie von außen nutzt falls sie erlaubt wäre. Dieses Risiko wäre nun wirklich leicht vermeitbar.
Das ist auch eine Möglichkeit, wenn man die DNS-Challenge unbedingt „avoiden” will. Oder wenn der eigene DNS-Provider keine API anbietet. In diesem Fall kann man aber auch entweder alle 60–90 Tage eine manuelle DNS-Challenge durchführen – oder vielleicht besser den DNS-Provider wechseln.
Ich verstehe jetzt nicht so genau, warum man mit meinem Vorschlag eine DNS-Challenge „avoiden”, also vermeiden würde.
Ich mach das ziemlich simpel mit nginx-vHosts.
upstream php-handler {
server unix:/run/php/php8.2-fpm.sock;
}
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name nextcloud.abcdefghijklmn.de 192.168.0.2;
root /var/www;
location ^~ /.well-known/acme-challenge {
default_type text/plain;
root /var/www/letsencrypt;
}
location / {
return 301 https://$host$request_uri;
}
}
Dieser vHost nimmt also sämtliche Anfragen über HTTP (Port 80) entgegen. Wenn es sich dabei um eine Let’s Encrypt Challenge handelt, wird dieser Request direkt über HTTP behandelt. Alle anderen Anfragen (z.B. an die Cloud) werden automatisch auf HTTPS „umgebogen“. Auf diese Weise wird erzwungen, dass alle Anfragen (außer über Let’s Encrypt) ausschließlich über HTTPS ablaufen.
Die Nextcloud hat einen eigenen vHost. Dieser hört nur auf 443 und enthält u.a. die SSL configuration.
Oder certbot nutzten, welcher das automatisch für dich macht
Das ist dann, so ganz nebenbei, auch sicherer als wildcard certs 
Die Beurteilung darüber, wie wichtig dieser Sicherheitsgewinn ist, überlasse ich euch.
Wer so viel Wert auf Sicherheit legt, dass er/sie den LAN traffic verschlüsselt oder wer seine Instanz nur in Sicherheit wähnt, wenn sie in einem eigenen VLAN ist, wird wohl kaum so etwas riskantes wie wildcard certs verwenden? Oder liege ich da falsch?
Hallo MPenzi,
ich weiss nicht woher die Tabelle stammt. Aber diese stimmt leider nicht. Die Fritz!Box ist bei der Konfiguration sehr eigen. In der Oberfläsche kann man nur IP’s eingeben, aber die Konfiguration selber bassiert auf den MAC Filter.
Hatte mal den Rechner eine bessere Netzwerkkarte gegeben und musste dann alles in der Fritz!Box bezüglich VPN und Portweiterleitung neu einstellen.
Grüße, Bernd
Ich danke allen für die viele Hilfe und Informationen. Einiges war für mich auch neu.
Mein Problem habe ich erstmal durch folgende zwei Punkte gelöst, bzw. werde ich dadurch lösen:
- Ich wollte von NextCloud den Mailclient nutzen und habe jetzt erfahren das diese auch Standalone laufen. SO teste ich gerade Roundcube und das zwingt einen nicht auf HTTPS umzusteigen.
- Das Problem mit den SSL Zertifikat habe ich auch fast gelöst, muss nur noch einige Scripte dazu tippen um es im Cron Job laufen lassen zu können. Ich kann mein SSL Zertifikat vom Hoster meiner Webseite nutzen. Dazu gibt es ein Script acme.sh. Dafür muss ich nur etwas meine DNS Konfiguration ändern. Also mein Public Server www.XXX.de bleibt und mein Lokale Netz wird dann www.my.XXX.de.
@ Lucky0472 evtl. ist das auch für Dich die Lösung.
Und an alle die die Fritz!Box für schlecht halten. Schaut Euch mal Telekoms Boxen an. Da gibt es nicht mal ein Protokoll für die Firewall und da sind doch einige Türen und Tore offen. Hatte deswegen echt Probleme gehabt. Und iptable ist Mächtig und Kompliziert. Habe dazu auch Scripte zur Konfiguration geschrieben. Und die Beste Methode war immer alles von außen zu sperren. Naja und genau das macht die Fritz!Box.
Grüße, Bernd
Bei der DNS-Challenge brauchst du einen API Zugang damit Certbot oder ein anderer ACME Client den benötigten TXT Record automatisiert im DNS eintragen kann. Ohne API-Zugang kann das auch Certbot nicht automatisch.
Du musst keine Wildcard Certs verwenden bei der DNS Challenge, aber du kannst.
Und wenn du deine Dienste ausschliesslich im LAN betreibst, ist ein Wilcard Zertifikat meiner Meinung nach sicher genug. Ich nutze ein Wilcard *.local.meinedomain.tld, für interne Dienste via DNS Challenge, und für die Dienste, die aus dem Internet erreichbar sind, nutze ich ganz normal die HTTP Challenge via Port 80.
Ein weiterer Grund, den ich btw. ebenfalls schon erwähnt habe, warum man auch im LAN gültige Zertifikate verwenden möchte, ist, dass immer mehr Clientsoftware diese erwartet, und Plain HTTP oder selbsignierte Zertifikate nicht mehr überall funktionieren. Und es ist auch einfach nett, wenn man überall ein Schloss mit “Sichere Verbindung” angezeigt bekommt, ansstatt “Unsicher” oder bei selbstsignierten Zertifikaten, zuerst eine Meldung wegklicken muss.
Ja so mache ich das mit Nextcloud und ein paar anderen Dingen, die ich aus dem Internet erreichbar mache auch.
Aber warum wollen hier alle OP überreden seine Nextcloud direkt aus dem Internet erreichbar zu machen, wenn er es doch explizit nicht will?
Prinzipiell finde ich es besser, wenn man erst einmal nichts aus dem Internet erreichbar macht und ein VPN nutzt. Dann ist es auch nicht so schlimm, wenn man seine Server – vor allem die Nextcloud – mal vergisst zu patchen. Das Gleiche gilt, wenn man bei der Konfiguration einen Fehler macht – vor allem, wenn man noch etwas unerfahren ist, was Selfhosting betrifft. Wenn man mehr Erfahrung hat und sich sicherer fühlt, kann man es ja immer noch tun. Aber selbst dann, solange man es nicht zwingend benötigt, sage ich: „Better safe than sorry”.
Nextcloud hatte durchaus schon kritische Sicherheitslückenen, und wenn man hier im Forum sieht, mit was für Versionen die Leute teilw. noch unterwegs sind, hätten die wohl besser auch davon abgesehen ihre Nextcloud ins Internet zu stellen.
Will ich doch gar nicht. Hast meine Vorschlag leider nicht richtig verstanden. Wenn tcp 443 in der Fritte zu ist, dann ist die Nextcloud auch nicht von außen erreichbar. Nur tcp 80 müsste für Let’s Encrypt offen sein und das eigentlich auch nur alle 80-90 Tage zum Erneuern der Zertifikate. Wenn man dann aber mal vergisst danach tcp 80 zu schließen, wäre es auch nicht schlimm, denn die Nextcöoud selbst würde ja tcp 80 ignorieren und tcp 443 wäre ohnehin ständig dicht.
Stimmt, da hast du natürlich recht. Und ich habe ja sogar weiter oben erwähnt, dass das auch noch eine Möglichkeit wäre. 
Trotzdem, bei deiner Methode ist der Webserver von aussen erreichbar, sprich es ist zumindest theoretisch unsicherer, als wenn gar nichts erreichbar ist.
Ja, er ist von außen erreichbar. Aber wenn man es macht wie ich vorschlage, dann nur alle 80-90 Tage für die 90 Sekunden oder so, die das Erneuern der Let’s Encrypt Zertifikate dauert. Denn nur dafür muss ja tcp 80 offen sein.