9
QNAP-Systeme und ZeroDay-Lücke "DeadBolt"
Hallo zusammen,
als Betreiber einiger QNAP-Systeme stelle ich mir derzeit einige Fragen bzgl. Sicherheit bei QNAP.
Wie jüngst hier nachzulesen, gibt es erneut eine ZeroDay-Lücke, die QNAP-Systeme die über das Internet erreichbar sind vulnerabel da stehen lassen.
Aber was heißt das genau?
Es gibt im Groben drei Möglichkeiten auf ein QNAP-System von außen zuzugreifen:
1. Man erstellt ein MyQnapCloud-Konto, verbindet/synced das System und der Dienst stellt eine Art DynDNS-Dienst zur Verfügung.
Man kann über den MyQNAPCloud-Dienst auf die QNAP zugreifen und Apps wie QSync etc. nutzen.
"Würde" bspw. die Datenbank bei QNAP ausgelesen, könnte man als Angreifer auslesen, welche Konten denn derzeit welche IP-Adresse haben, um dann darauf zugreifen zu können und die ZeroDay-Lücke ausnutzen zu können.
2. Man nutzt einen eigenen DynDNS-Dienst. Bspw. den, den man bei einer FritzBox ohnehin hat und leitet entsprechend den Port weiter. Oder eben auch andere Anbieter.
Die DynDNS ist meist nur einem selbst bekannt. Ebenso der Port denn man sich als Portweiterleitung aussucht und einrichtet.
Das ist so auch meine Lösung die ich mehrfach nutze um Dienste wie QSync, QuMagic, etc. zur Verfügung zu stellen. da es mir grundsätzlich missfällt das System unnötigen Abhängigkeiten wie eben den QNAPCloud-Dienst auszusetzen.
3. VPN Zugriff auf das Netzwerk
Die wohl sicherste, aber für den laienbehafteten Endbenutzer zum Teil auch unkomfortabelste Lösung. Gerade bei bestehender VPN-Verbindung und wechselnden IP-Netzen, kann es auch schon mal zu Konflikten kommen und Netzwerkgeräte sind ggf. nicht erreichbar.
Selbst erachte ich es höchst unwahrscheinlich, dass jemand den Zugang zu Punkt 2 ausfindig machen kann. In meinen Fällen sind die DynDNS Adressen entweder alphanumerisch selbst generiert oder z.B. durch den FritzBox Dienst von AVM generiert worden. Auch diese sind alphanumerisch.
Der Port ist ebenfalls nie ein Standardport und auch immer manuell generiert und freigegeben.
Sind mit DeadBolt eben nur die Zugriffe gemeint, welche ein Cloud-Konto von QNAP verwenden?
Wie ist eure Meinung? Ich frage mich, ob ich die Systeme nun besser vom Netz nehmen sollte.
als Betreiber einiger QNAP-Systeme stelle ich mir derzeit einige Fragen bzgl. Sicherheit bei QNAP.
Wie jüngst hier nachzulesen, gibt es erneut eine ZeroDay-Lücke, die QNAP-Systeme die über das Internet erreichbar sind vulnerabel da stehen lassen.
Aber was heißt das genau?
Es gibt im Groben drei Möglichkeiten auf ein QNAP-System von außen zuzugreifen:
1. Man erstellt ein MyQnapCloud-Konto, verbindet/synced das System und der Dienst stellt eine Art DynDNS-Dienst zur Verfügung.
Man kann über den MyQNAPCloud-Dienst auf die QNAP zugreifen und Apps wie QSync etc. nutzen.
"Würde" bspw. die Datenbank bei QNAP ausgelesen, könnte man als Angreifer auslesen, welche Konten denn derzeit welche IP-Adresse haben, um dann darauf zugreifen zu können und die ZeroDay-Lücke ausnutzen zu können.
2. Man nutzt einen eigenen DynDNS-Dienst. Bspw. den, den man bei einer FritzBox ohnehin hat und leitet entsprechend den Port weiter. Oder eben auch andere Anbieter.
Die DynDNS ist meist nur einem selbst bekannt. Ebenso der Port denn man sich als Portweiterleitung aussucht und einrichtet.
Das ist so auch meine Lösung die ich mehrfach nutze um Dienste wie QSync, QuMagic, etc. zur Verfügung zu stellen. da es mir grundsätzlich missfällt das System unnötigen Abhängigkeiten wie eben den QNAPCloud-Dienst auszusetzen.
3. VPN Zugriff auf das Netzwerk
Die wohl sicherste, aber für den laienbehafteten Endbenutzer zum Teil auch unkomfortabelste Lösung. Gerade bei bestehender VPN-Verbindung und wechselnden IP-Netzen, kann es auch schon mal zu Konflikten kommen und Netzwerkgeräte sind ggf. nicht erreichbar.
Selbst erachte ich es höchst unwahrscheinlich, dass jemand den Zugang zu Punkt 2 ausfindig machen kann. In meinen Fällen sind die DynDNS Adressen entweder alphanumerisch selbst generiert oder z.B. durch den FritzBox Dienst von AVM generiert worden. Auch diese sind alphanumerisch.
Der Port ist ebenfalls nie ein Standardport und auch immer manuell generiert und freigegeben.
Sind mit DeadBolt eben nur die Zugriffe gemeint, welche ein Cloud-Konto von QNAP verwenden?
Wie ist eure Meinung? Ich frage mich, ob ich die Systeme nun besser vom Netz nehmen sollte.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1767594903
Url: https://administrator.de/contentid/1767594903
Ausgedruckt am: 23.11.2024 um 18:11 Uhr
9 Kommentare
Neuester Kommentar
erachte ich es höchst unwahrscheinlich, dass jemand den Zugang zu Punkt 2 ausfindig machen kann.
Eine sehr laienhafte und gefährliche Annahme. Portscanner scannen weltweit solche Endgeräte Adressen im Zehntelsekundentakt. Aus der IP dann mit Reverse Lookup den DynDNS Namen zu erfahren erledigen diese Scanner gleich mit.2. ist also niemals eine Option. So oder so ein NAS ungeschützt und offen im Internet zu exponieren ist schon ein absolutes NoGo. Auch für Privatnutzer. Das sagt einem auch ohne KnowHow schon das Bauchgefühl.
3. ist die einzig gangbare Option wenn Datensicherheit gefordert ist.
Es ist auch unsinnig das moderne VPN Clients mit wechselnden IPs nicht umgehen können, zumindestens wenn man das in eimnem Administrator Forum behauptet. MOBIKE Funktionen u.a. supportet auch die heimische FritzBox und auch VPN Verbindungen kann man DAU gerecht einrichten. Dazu muss man sich nicht einmal besondere Mühe geben wie dir die zahllosen VPN Tutorials dieses Forums ja z.B. hier mit ihren weiterführenden Links vor Augen führen.
Hört sich eher so an als ob du deine Hausaufgaben nicht so wirklich gemacht hast...?!
Danke für deine Antwort. Deiner Meinung nach sollte es also vom Netzwerk genommen werden. Das habe ich verstanden.
Deiner Meinung nach sollte man auch Lösung 1. nie in Anspruch nehmen.
Das mache ich nach aktuellem Wissensstand über das offensichtliche Risiko und nach "meinem Bauchgefühl" ebenso wenig. Aber warum geben sich denn dann Millionen Benutzer mit dieser Lösung ab, wenn es doch so gefährlich ist?
Warum nutzen dann Menschen Cloudsysteme, wenn nur ein Login dazwischen steht? Weil Benutzernamen und sichere Passwörter mit 2FA eine "relativ" sichere Sache sind.
Lösung 2
ist seit Jahren Gang und Gäbe in meiner Umsetzung. Durchaus kann und darf man das infrage stellen. Genauso wie eine paranoide Umsetzung, die jedoch ebenfalls ihre Existenzberechtigungen haben.
Wenn es sich jedoch um ein solches Sicherheitsrisiko und laienhafte Einrichtung handelt wie du beschreibst, wie kann es dann sein, dass seit Jahren auf diese Adressen nie auch nur ein einziger Zugriffsversuch eingegangen ist? Weder unauthorisierte Anfragen, gesperrte IP-Adressen, fehlerhafte Loginversuche, etc?
Zu behaupten, dass Lösung 2 niemals eine Option ist, darf man ebenso infrage stellen.
Lösung 3
Ist natürlich das sicherste. Da stimme ich dir vollkommen zu.
Was ist jedoch mit den Personen die die Dienste auch vom Handy aus nutzen? Was ist mit Kollaborationssoftware wie NextCloud, Exchange, etc? Oder eben auch - wie in diesem Fall - Dienste von QNAP wie QSync, QuMagic usw? Glaubst du denn allen Ernstes, dass jeder der die Systeme so einsetzt ausnahmslos mittels VPN darauf zugreift?
Ich denke nicht, dass jeder bereit dazu ist sich eine VPN Software auf dem PC und Smartphone einzurichten und eine Dauerverbindung aufrechtzuerhalten. Dazu sind Menschen zu unterschiedlich und unter diesem Gesichtspunkt muss man Wünsche der Endanwender, wie best practise und Nutzerfreundlichkeit abwägen.
Wie eingangs bereist erwähnt; was ist mit Diensten von Google, Microsoft und Co? Auch dort steht nur eine Anmeldung dazwischen. Im besten Fall mit 2FA. Diese sind im entfernten Sinne auch nichts anderes als exponierte Systeme.
Sicherheit geht immer auf Kosten der Bequemlichkeit. Ich denke darauf kann man sich einigen.
Paranoide Sicherheitseinstellungen sind vollkommen gerechtfertigt.
Meine ursprüngliche Frage zielte jedoch mehr darauf ab, einschätzen zu können welche Art von Zugängen bei speziell diesem System denn nun einem erhöhten Risiko der DeadBolt ZeroDay-Lücke ausgesetzt sind. Handelt es sich dabei um ein reines QNAPCloud-Problem? Das kann ich den Medien leider nicht entnehmen.
Deiner Meinung nach sollte man auch Lösung 1. nie in Anspruch nehmen.
Das mache ich nach aktuellem Wissensstand über das offensichtliche Risiko und nach "meinem Bauchgefühl" ebenso wenig. Aber warum geben sich denn dann Millionen Benutzer mit dieser Lösung ab, wenn es doch so gefährlich ist?
Warum nutzen dann Menschen Cloudsysteme, wenn nur ein Login dazwischen steht? Weil Benutzernamen und sichere Passwörter mit 2FA eine "relativ" sichere Sache sind.
Lösung 2
ist seit Jahren Gang und Gäbe in meiner Umsetzung. Durchaus kann und darf man das infrage stellen. Genauso wie eine paranoide Umsetzung, die jedoch ebenfalls ihre Existenzberechtigungen haben.
Wenn es sich jedoch um ein solches Sicherheitsrisiko und laienhafte Einrichtung handelt wie du beschreibst, wie kann es dann sein, dass seit Jahren auf diese Adressen nie auch nur ein einziger Zugriffsversuch eingegangen ist? Weder unauthorisierte Anfragen, gesperrte IP-Adressen, fehlerhafte Loginversuche, etc?
Zu behaupten, dass Lösung 2 niemals eine Option ist, darf man ebenso infrage stellen.
Lösung 3
Ist natürlich das sicherste. Da stimme ich dir vollkommen zu.
Was ist jedoch mit den Personen die die Dienste auch vom Handy aus nutzen? Was ist mit Kollaborationssoftware wie NextCloud, Exchange, etc? Oder eben auch - wie in diesem Fall - Dienste von QNAP wie QSync, QuMagic usw? Glaubst du denn allen Ernstes, dass jeder der die Systeme so einsetzt ausnahmslos mittels VPN darauf zugreift?
Ich denke nicht, dass jeder bereit dazu ist sich eine VPN Software auf dem PC und Smartphone einzurichten und eine Dauerverbindung aufrechtzuerhalten. Dazu sind Menschen zu unterschiedlich und unter diesem Gesichtspunkt muss man Wünsche der Endanwender, wie best practise und Nutzerfreundlichkeit abwägen.
Wie eingangs bereist erwähnt; was ist mit Diensten von Google, Microsoft und Co? Auch dort steht nur eine Anmeldung dazwischen. Im besten Fall mit 2FA. Diese sind im entfernten Sinne auch nichts anderes als exponierte Systeme.
Sicherheit geht immer auf Kosten der Bequemlichkeit. Ich denke darauf kann man sich einigen.
Paranoide Sicherheitseinstellungen sind vollkommen gerechtfertigt.
Meine ursprüngliche Frage zielte jedoch mehr darauf ab, einschätzen zu können welche Art von Zugängen bei speziell diesem System denn nun einem erhöhten Risiko der DeadBolt ZeroDay-Lücke ausgesetzt sind. Handelt es sich dabei um ein reines QNAPCloud-Problem? Das kann ich den Medien leider nicht entnehmen.
Eine sehr laienhafte und gefährliche Annahme. Portscanner scannen weltweit solche Endgeräte Adressen im Zehntelsekundentakt. Aus der IP dann mit Reverse Lookup den DynDNS Namen zu erfahren erledigen diese Scanner gleich mit.
Muss er doch gar nicht ... scannt doch die IP direkt?! DynDNS ist doch nur die Krücke, damit Du Deinen Anschluss findest. Wenn jemand eh "blind" scant ist die Zuordnung doch peripher?!https://www.shodan.io
Prinzipiell geht nur 3. - VPN und DynDNS terminieren auf den Router/Fritzbox/Firewall OHNE Weiterleitungen an den QNAP. Ehrlicherweise ist das aber doch auch das häufigste Setup für ein NAS?!
Was Du Dir mal ansehen könntest - ist aber auch nicht über jeden Zweifel erhaben - wäre Zerotier.com. Damit sparst Du Dir VPN und DynDNS am Router, terminierst aufs Qnap - aber der Zugang ist nicht für andere sichtbar und zugänglich. Zumindest solange Zerotier nicht gehacked wird. Im Prinzip ähnlich Deiner Lösung 1.
VG
1
Also von deinen drei Szenarien ist mindestens Nr.2 von der Sicherheitslücke betroffen, deine NAS ist von außen per Portweiterleitung und/oder UPNP erreichbar und kann somit angegriffen werden. Die dynamische IP schützt hierbei in keinster Weise, die Schwachstelle kann von Außen erkannt und ausgenutzt werden.
Was die Menge an potenziellen Angriffen limitiert ist ein Geo Blocking. Das hat zwar keine wirkliche Schutzfunktion, macht dich aber für Portscans wie für Angriffe für einen deutlich keineren Teil der Menschheit zugänglich. Natürlich kann man das umgehen aber es hilft bei 0-Days nicht gleich ins Feuer zu laufen.
Für Nr.1 ist es etwas schwieriger eine Aussage zu treffen. Generell ist auch so ein Gerät von Außen erreichbar für den Dienst des Cloud-Anbieters. Ist also das Gerät verwundbar und lauscht auf einen Port nach Außen kann sich der Angreifer eventuell als "Cloud" ausgeben und erlangt so Zugriff. Die Angriffe sind aber ggf. schwieriger umzusetzen weil z.B. die ganze Kommunikation nicht auf bekannten Protokollen beruht oder weil zusätzliche Schutzmaßnahmen z.B. den Aufbau einer Verbindung mit einer IP-Adresse die nicht auf den DNS-Namen des Cloud-Anbieters antwortet ausgeschlossen wurde.
Man kann da vieles machen aber im SOHO Umfeld erwartet man natürlich einen möglichst barrierefreien Betrieb und der Anbieter legt mehr Wert auf Komfort als auf Sicherheit.
Nr.3 ist mit Abstand am sichersten mit VPN Lösungen die sehr verbreitet sind. Hier findet man nicht so einfach einen 0-Day und wenn dann gibt es schnell eine enorme Anzahl an Betroffenen und damit einfach schnell Abhilfe und Know-How. Außerdem hat man "!!nur!!" das VPN geknackt hat man ja noch nicht gleich das System dahinter im Visir.
Was die Menge an potenziellen Angriffen limitiert ist ein Geo Blocking. Das hat zwar keine wirkliche Schutzfunktion, macht dich aber für Portscans wie für Angriffe für einen deutlich keineren Teil der Menschheit zugänglich. Natürlich kann man das umgehen aber es hilft bei 0-Days nicht gleich ins Feuer zu laufen.
Für Nr.1 ist es etwas schwieriger eine Aussage zu treffen. Generell ist auch so ein Gerät von Außen erreichbar für den Dienst des Cloud-Anbieters. Ist also das Gerät verwundbar und lauscht auf einen Port nach Außen kann sich der Angreifer eventuell als "Cloud" ausgeben und erlangt so Zugriff. Die Angriffe sind aber ggf. schwieriger umzusetzen weil z.B. die ganze Kommunikation nicht auf bekannten Protokollen beruht oder weil zusätzliche Schutzmaßnahmen z.B. den Aufbau einer Verbindung mit einer IP-Adresse die nicht auf den DNS-Namen des Cloud-Anbieters antwortet ausgeschlossen wurde.
Man kann da vieles machen aber im SOHO Umfeld erwartet man natürlich einen möglichst barrierefreien Betrieb und der Anbieter legt mehr Wert auf Komfort als auf Sicherheit.
Nr.3 ist mit Abstand am sichersten mit VPN Lösungen die sehr verbreitet sind. Hier findet man nicht so einfach einen 0-Day und wenn dann gibt es schnell eine enorme Anzahl an Betroffenen und damit einfach schnell Abhilfe und Know-How. Außerdem hat man "!!nur!!" das VPN geknackt hat man ja noch nicht gleich das System dahinter im Visir.
1
Vielen Dank für die konstruktiven Antworten.
https://www.shodan.io/ scheint ein interessantes Tool zu sein.
Ich habe daraufhin Scans angestellt. Es werden "bisher" keine Ports angezeigt die tatsächlich auch freigegeben sind. Noch nicht. Jetzt habe ich zumindest einmal eine Anfrage gestellt.
Lediglich bei FritzBox-Systemen wird der Port 8089 angezeigt.
Je nach Ansicht und Anwendungszweck ein sehr kontroverses Thema. Auch wenn man am Ende vor einem Login-Screen steht und sich mehrfach authentifizieren muss, ist ein "potentielles" Sicherheitsrisiko immer vorhanden. Selbstredend. Die Frage ist inwiefern man den Lösungen vertraut. Wäre es ein solches Tabuthema, würden alle Alarmleuchten angehen bei dem Versuch eine Port-Weiterleitung einzurichten.
Ich nehme mit, dass VPN nach wie vor die sicherste Lösung für solche Unterfangen ist.
Das ist mir natürlich selbst bewusst und ist so teilweise auch im Einsatz. Zumindest bei reinen Desktoplösungen die "statisch" sind.
Auch wenn ich bisher mit Lösung 2 in der Vergangenheit nun mal nie Probleme hatte und es auch nie zu Angriffsversuchen gekommen ist. Ich denke man muss über die reine "Möglichkeit des Risikos" und des "tatsächlichen Eintretens" differenzieren.
Interessant wird es jedoch bei symbiotischen Lösungen mit Handy, Tablet und PC/NB.
Ich denke an die Probleme in der Praxis, wie:
- schlechter Empfang
- Abbruch der VPN-Verbindung mit folgender Fehlermeldung die weggewischt werden muss
- dass sich ein Dienst deswegen nicht syncen konnte
- etc.
Am Ende muss es praxistauglich sein ohne, dass der Anwender (DAU) vermeidbare Fehlermeldungen wegklicken muss, das VPN neu verbinden muss, einen Resync machen muss, weil die Verbindung während einer Übertragung abgebrochen ist usw. Was eben am Ende alles so eintreten kann.
Am Ende wird man angerufen oder bekommt eine Mail in der man von der nicht funktionierenden Lösung genervt ist. Dann haben wir zwar den Faktor Sicherheit, jedoch keine Nutzerfreundlichkeit.
Vielen Dank für die Anregungen.
https://www.shodan.io/ scheint ein interessantes Tool zu sein.
Ich habe daraufhin Scans angestellt. Es werden "bisher" keine Ports angezeigt die tatsächlich auch freigegeben sind. Noch nicht. Jetzt habe ich zumindest einmal eine Anfrage gestellt.
Lediglich bei FritzBox-Systemen wird der Port 8089 angezeigt.
Je nach Ansicht und Anwendungszweck ein sehr kontroverses Thema. Auch wenn man am Ende vor einem Login-Screen steht und sich mehrfach authentifizieren muss, ist ein "potentielles" Sicherheitsrisiko immer vorhanden. Selbstredend. Die Frage ist inwiefern man den Lösungen vertraut. Wäre es ein solches Tabuthema, würden alle Alarmleuchten angehen bei dem Versuch eine Port-Weiterleitung einzurichten.
Ich nehme mit, dass VPN nach wie vor die sicherste Lösung für solche Unterfangen ist.
Das ist mir natürlich selbst bewusst und ist so teilweise auch im Einsatz. Zumindest bei reinen Desktoplösungen die "statisch" sind.
Auch wenn ich bisher mit Lösung 2 in der Vergangenheit nun mal nie Probleme hatte und es auch nie zu Angriffsversuchen gekommen ist. Ich denke man muss über die reine "Möglichkeit des Risikos" und des "tatsächlichen Eintretens" differenzieren.
Interessant wird es jedoch bei symbiotischen Lösungen mit Handy, Tablet und PC/NB.
Ich denke an die Probleme in der Praxis, wie:
- schlechter Empfang
- Abbruch der VPN-Verbindung mit folgender Fehlermeldung die weggewischt werden muss
- dass sich ein Dienst deswegen nicht syncen konnte
- etc.
Am Ende muss es praxistauglich sein ohne, dass der Anwender (DAU) vermeidbare Fehlermeldungen wegklicken muss, das VPN neu verbinden muss, einen Resync machen muss, weil die Verbindung während einer Übertragung abgebrochen ist usw. Was eben am Ende alles so eintreten kann.
Am Ende wird man angerufen oder bekommt eine Mail in der man von der nicht funktionierenden Lösung genervt ist. Dann haben wir zwar den Faktor Sicherheit, jedoch keine Nutzerfreundlichkeit.
Vielen Dank für die Anregungen.
Wenn Du Deine Systeme "testen" willst, kannst Du auch den Heise Sec-Check laufen lassen:
https://www.heise.de/security/dienste/Netzwerkcheck-2114.html
Macht aber im Prinzip auch nix anderes als ein Portscan auf eine öffentliche IP-Adresse. Wenn Du Google mit online-portscanner fütterst, wirst Du bestimmt fündig.
Wichtig, wie immer: Den "admin" umbenennen. Die Authentifikation besteht ja nicht nur aus PW sondern ebenso(!) aus Username! Und Du kannst natürlich die Firewall des NAS auch im lokalen Netzwerk "hochfahren" und nur die genutzten Dienste freigeben.
Das Problem an Vulnerabilities ist aber im Besonderen, dass deren Möglichkeiten am "normalen Zugang" vorbeigehen. Und da bist Du am Ende doch auf den Hersteller angewiesen.
https://www.heise.de/security/dienste/Netzwerkcheck-2114.html
Macht aber im Prinzip auch nix anderes als ein Portscan auf eine öffentliche IP-Adresse. Wenn Du Google mit online-portscanner fütterst, wirst Du bestimmt fündig.
Wichtig, wie immer: Den "admin" umbenennen. Die Authentifikation besteht ja nicht nur aus PW sondern ebenso(!) aus Username! Und Du kannst natürlich die Firewall des NAS auch im lokalen Netzwerk "hochfahren" und nur die genutzten Dienste freigeben.
Das Problem an Vulnerabilities ist aber im Besonderen, dass deren Möglichkeiten am "normalen Zugang" vorbeigehen. Und da bist Du am Ende doch auf den Hersteller angewiesen.
1
Natürlich kann man alles mit der "Usability" kaputt reden aber machen wir uns nichts vor, die ganzen Cloud-Plattformen die jetzt am Markt sind abzusichern ist auch nicht grade trivial. Onlinebanking mit TAN Liste fand ich auch super und war mir sicher genug, meiner Bank aber nicht. Jetzt muss ich auch MFA mit nem Handy machen, will ich das Handy wechseln muss mir ein Brief geschickt werden.
VPN ist eigentlich einfach und es läuft sehr stabil (wir nutzen OpenVPN auf iPads zur Absicherung von Exchange und DMS). Ich kann den Zugang kappen wenn mir wegen eines Angriffs der Arsch auf Grundeis geht, versuch das mal bei Daten die in der Cloud liegen. Ja es gibt User die sich damit schwer tun aber am Ende ist es ein Schalter für VPN auf so einem Mobilgerät.
VPN ist eigentlich einfach und es läuft sehr stabil (wir nutzen OpenVPN auf iPads zur Absicherung von Exchange und DMS). Ich kann den Zugang kappen wenn mir wegen eines Angriffs der Arsch auf Grundeis geht, versuch das mal bei Daten die in der Cloud liegen. Ja es gibt User die sich damit schwer tun aber am Ende ist es ein Schalter für VPN auf so einem Mobilgerät.
1
Sehr gute Grundsatzdiskussion die zukünftige Konfigurationen beeinflusst.
Besagte Portweiterleitungen wurden gestern abgeschaltet.
Nun werden sukzessive die Clients eingerichtet.
Mit FritzBox-Systemen (DynDNS ist ja bereits nativ vorhanden) und ShrewSoft schnell eingerichtet (da leider nur IKEv1, nicht mit Windows Boardmitteln möglich).
Mittels Batch kann das automatisiert werden oder eine One-Click Sache daraus gemacht werden.
Etwas uneleganter ist es wie bereits gesagt am Handy. Bisher habe ich nicht an allen Endgeräten eine VPN "Always On" Funktion und auch ein Schalter ist nicht bei jedem SmartPhone OS vorhanden. Da gibt es dann wieder zahlreiche einzelne Lösungen oder Apps die man herunterladen muss. Auch muss man bei Fritz für jeden Client eine eigene VPN-Verbindung einrichten, wenn "ein" Benutzer bspw. ein SmartPhone und ein Desktop hat. Prima, denn entfernt kann man das auch nicht immer einrichten, wenn man bei solchen Änderungen die Funktion "Zusätzliche Einstellungen" bei AVM zur Sicherheit aktiviert hat. Dann muss man einmal einen Knopf an der FB drücken oder mittels DECT Telefon eine Zeichenfolge eingeben.
So ist das dann eben und man muss sich da auf den unterschiedlichen Plattformen Android, iOS, etc. durcharbeiten.
Praktisch, wenn der Router VPN bereits implementiert hat und kaum Infrastruktur dahinter vorhanden ist (weil kleiner Kunde), auf der man in einer einer VM z.B. noch einen VPN-Server aufstellt. Ob das dann auch das gelbe vom Ei ist, sowas durch den Host zu routen sei mal dahingestellt. Mit Sicherheit gibt es auch da Möglichkeiten weitere Angriffsziele zu verursachen. Letztes Kritisches Sicherheitsupdate von VMWare.
Nicht jedes der Netzwerke hat überhaupt einen Server und arbeitet nur arbeitsplatzbezogen mit lokaler DASI, usw. Andernfalls gibt es dann natürlich Optionen wie einen Pi dahinter zu setzen. Professionell sieht jedoch anders aus. Scheint aber ja zu funktionieren. Ok, pack das Ding in eine 19" Blende und gut ist, wenn denn dann ein Schrank vorhanden ist. Bei manchen EDV Verteilungen tun mir die Geräte schon fast leid.
Weiter geht es mit DynDNS. AVM hat den Dienst glücklicherweise integriert. Bei allen anderen muss man dann bspw. No-IP nutzen und den Host alle 30 Tage neu verifizieren, wenn man dafür nicht auch noch laufende Kosten verursachen möchte. Vielleicht gibt es da auch noch weitere Angebote die das nicht erfordern.
Und manchmal kann man das auch nicht über die FritzBox machen, selbst wenn sie vorhanden ist, weil dann bspw. eine Firewall von Unify, Sophos, etc dahintersteckt, die das VPN verwaltet.
Dann kann man auch gleich ein Modem benutzen. Wobei man auch hier wieder von einer doppelten Firewall profitieren kann (wie auch der Hinweis von @Visucius an lokalen Geräten hinter dem Router ebenfalls die FW hochzuziehen). Doppeltes NAT ist aufgrund der Weiterleitungen die nur für VPN eingerichtet werden müssen, dann ja vertretbar.
Von einer einfachen und einheitlichen Lösung ist man da meiner Meinung nach noch weit entfernt.
But that's our job.
Besagte Portweiterleitungen wurden gestern abgeschaltet.
Nun werden sukzessive die Clients eingerichtet.
Mit FritzBox-Systemen (DynDNS ist ja bereits nativ vorhanden) und ShrewSoft schnell eingerichtet (da leider nur IKEv1, nicht mit Windows Boardmitteln möglich).
Mittels Batch kann das automatisiert werden oder eine One-Click Sache daraus gemacht werden.
Etwas uneleganter ist es wie bereits gesagt am Handy. Bisher habe ich nicht an allen Endgeräten eine VPN "Always On" Funktion und auch ein Schalter ist nicht bei jedem SmartPhone OS vorhanden. Da gibt es dann wieder zahlreiche einzelne Lösungen oder Apps die man herunterladen muss. Auch muss man bei Fritz für jeden Client eine eigene VPN-Verbindung einrichten, wenn "ein" Benutzer bspw. ein SmartPhone und ein Desktop hat. Prima, denn entfernt kann man das auch nicht immer einrichten, wenn man bei solchen Änderungen die Funktion "Zusätzliche Einstellungen" bei AVM zur Sicherheit aktiviert hat. Dann muss man einmal einen Knopf an der FB drücken oder mittels DECT Telefon eine Zeichenfolge eingeben.
So ist das dann eben und man muss sich da auf den unterschiedlichen Plattformen Android, iOS, etc. durcharbeiten.
Praktisch, wenn der Router VPN bereits implementiert hat und kaum Infrastruktur dahinter vorhanden ist (weil kleiner Kunde), auf der man in einer einer VM z.B. noch einen VPN-Server aufstellt. Ob das dann auch das gelbe vom Ei ist, sowas durch den Host zu routen sei mal dahingestellt. Mit Sicherheit gibt es auch da Möglichkeiten weitere Angriffsziele zu verursachen. Letztes Kritisches Sicherheitsupdate von VMWare.
Nicht jedes der Netzwerke hat überhaupt einen Server und arbeitet nur arbeitsplatzbezogen mit lokaler DASI, usw. Andernfalls gibt es dann natürlich Optionen wie einen Pi dahinter zu setzen. Professionell sieht jedoch anders aus. Scheint aber ja zu funktionieren. Ok, pack das Ding in eine 19" Blende und gut ist, wenn denn dann ein Schrank vorhanden ist. Bei manchen EDV Verteilungen tun mir die Geräte schon fast leid.
Weiter geht es mit DynDNS. AVM hat den Dienst glücklicherweise integriert. Bei allen anderen muss man dann bspw. No-IP nutzen und den Host alle 30 Tage neu verifizieren, wenn man dafür nicht auch noch laufende Kosten verursachen möchte. Vielleicht gibt es da auch noch weitere Angebote die das nicht erfordern.
Und manchmal kann man das auch nicht über die FritzBox machen, selbst wenn sie vorhanden ist, weil dann bspw. eine Firewall von Unify, Sophos, etc dahintersteckt, die das VPN verwaltet.
Dann kann man auch gleich ein Modem benutzen. Wobei man auch hier wieder von einer doppelten Firewall profitieren kann (wie auch der Hinweis von @Visucius an lokalen Geräten hinter dem Router ebenfalls die FW hochzuziehen). Doppeltes NAT ist aufgrund der Weiterleitungen die nur für VPN eingerichtet werden müssen, dann ja vertretbar.
Von einer einfachen und einheitlichen Lösung ist man da meiner Meinung nach noch weit entfernt.
But that's our job.
Wer keinen Server hat hat vermutlich auch keinen 19'' Schrank aber das führt auch alles am Punkt vorbei. Es gibt eigentlich nur drei Arten der Verbindung von Außen:
1) Hersteller spezifisch, z.B. über die Cloud des Herstellers
2) Das Gerät hängt direkt am Internet (Port Weiterleitung)
3) Hersteller unabhängig mit zusätzlicher Tunnelung, sprich irgendeine Form von VPN
Bei Nr.3 hängt die NAS eigentlich gar nicht am Internet, alle Clients kommen aus einem vertrauenswürdigen lokalen Netz. Eigentlich gibt es noch
4) Das Gerät ist einfach schlicht von Außen nicht zugänglich
Nr.3 und Nr.4 haben noch den gravierenden Vorteil das man ein Gerät das EOL ist auch weiter Nutzen kann ohne direkte Gefährdung. Ich hab noch ein Datengrab hier stehen mit QTS 4.x das ist seit 2018 EOL aber erfüllt seinen Zweck ja noch.
1) Hersteller spezifisch, z.B. über die Cloud des Herstellers
2) Das Gerät hängt direkt am Internet (Port Weiterleitung)
3) Hersteller unabhängig mit zusätzlicher Tunnelung, sprich irgendeine Form von VPN
Bei Nr.3 hängt die NAS eigentlich gar nicht am Internet, alle Clients kommen aus einem vertrauenswürdigen lokalen Netz. Eigentlich gibt es noch
4) Das Gerät ist einfach schlicht von Außen nicht zugänglich
Nr.3 und Nr.4 haben noch den gravierenden Vorteil das man ein Gerät das EOL ist auch weiter Nutzen kann ohne direkte Gefährdung. Ich hab noch ein Datengrab hier stehen mit QTS 4.x das ist seit 2018 EOL aber erfüllt seinen Zweck ja noch.
