NAS im Internet (wenige Ports weitergeleitet) und IP Filterung - Security - Allow/Deny List

Eine Whitelist wird Dir nicht viel helfen, wenn Du von unterwegs zugreifst, hast Du i.d.R. immer andere IP Adressen.

Woher willst Du wissen, hinter welcher IP sich ein Angreifer befindet?

Auch ein Angreifer könnte sich hinter einer der Provider IPs verstecken.

Ausser VPN gibt es m.E. nicht sicheres um von außen zu zugreifen.

Dann kannst Du den IP Bereich in der Whitelist auch übersichtlich gestalten.

Gruss

Ich war auch lange ein Verfechter von NAS im Internet. Es macht aber keinen Sinn.

Egal was du alles machst, du setzt immer deine komplette NAS ins Internet und damit Dienste die im Internet nichts verloren haben. Das kannst du bei einer NAS nicht umgehen. Wenn du QTS vom Internet erreichbar machst, dann auch die Photostation, MusicStation, ... und genau das sind die Einfallstore, da diese die Bugs haben.

Ebenso kommen die Sicherheitsupdates für QTS viel zu langsam, um im Internet stand halten zu können.

Zitat von UpSpin

Egal was du alles machst, du setzt immer deine komplette NAS ins Internet und damit Dienste die im Internet nichts verloren haben. Das kannst du bei einer NAS nicht umgehen.

Solche pauschalen Aussagen sind doch Käse.

Was spricht z. B. dagegen, nur einen Port für den Zugriff auf PLEX zu "veröffentlichen"?

Dann es mach doch per VPN. Und zwar VPN vom Endgerätr <-> Router realitiblue .

So mache ich das persönlich auch. Vom Android Handy wird ein VPN -> Router aufgebaut. So kann ich alle Apss nutzen als ob ich zu Hause im LAN bin.

Und immer dran denken ... es gibt auch sichere Benutzernamen.

Zitat von Jagi

Und immer dran denken ... es gibt auch sichere Benutzernamen.

Gute Ergänzung zu den sicheren Kennwörtern!

Zitat von Timpov

Solche pauschalen Aussagen sind doch Käse.

Nein! Weil die Angriffe zu 99% über irgendwelche Implementierungsfehler der jeweiligen Webanwendung, und das sind dann die Photostation, Musicstation, Plex etc. pp. passieren. Sichere Kennwörter und noch 2FA ( 2 Faktor Authentifizierung) können das Risiko sicher senken, aber nur solange die Webserver Konfiguration ODER die Anwendung keine bekannte Sicherheitslücke hat. Man begibt sich in eine trügerische Sicherheit. Es ist leider so, das VPN die z.Zt. sicherste Variante und mit Android und iOS eigentlich rel. leicht hanzuhaben ist, sofern es der Router unterstützt. Leider ist der Durchsatz inzwischen häufig niedriger, als dass was die DSL Leitung hergeben würde. Daran krankt es eher, sofern man keine spezielle VPN Hardware nutzt. Wie stark einen das praktisch einschränkt hängt natürlich vom Nutzungsszenario ab. U.u. kann man einen Raspberry als VPN Gateway nutzen, der mehr Power hat, aber da kenne ich keine Details.

Zitat von Timpov

Solche pauschalen Aussagen sind doch Käse.

Was spricht z. B. dagegen, nur einen Port für den Zugriff auf PLEX zu "veröffentlichen"?

Der Wunsch von Unterwegs Dateien hochzuladen. Und darauf bezog ich mich maßgeblich, denn das ist die größte Schwachstelle.

Zusätzlich: Wie läuft denn Plex auf der NAS? In einer VM oder doch nur als App in QTS. D.h. Plex, somit die NAS mit allen Daten, sitzt wieder direkt im Internet. Natürlich nur mit einem bestimmten Port, der nur auf Plex geleitet wird, aber dahinter ist die ganze NAS voll drin. Hat die Plex App eingeschränkte Zugriffsrechte, oder läuft diese als root auf der NAS?

Normalerweise packt man so einen Dienst in eine DMZ und regelt den Zugriff zwischen DMZ und der NAS über eine Firewall.

Welche Möglichkeiten bietet dir denn auch die NAS die Zugriffe auf den Port zu protokollieren und zu blocken? Lässt du fail2ban oder ähnliches auf der NAS laufen?

Sicherheit muss verhältnismäßig sein!

Plex wird sehr gut gepflegt, hält man den aktuell ist das Risiko nach meiner Einschätzung akzeptabel.

Vor allem da man hier ja nicht den default Port nutz, muss den Dienst auch erst mal jemand in den highports finde.

Klar kann man auch @home alles mit einer UTM dicht machen, aber das sprengt die Verhältnisse.

Ich habe da wenig Lust ständig Seiten zu entblocken oder Dienste wieder aus der IDS Blockliste zu nehmen, nur weil die kein sauberes Protokoll fahren und daher als verdächtig eingestuft werden.

Und selbst ein UTM bietet keinen 100% Schutz, das wird scheinbar vergessen.

Denn alle arbeiten Signatur basiert.

@home geht es um strukturellen Grundschutz und da zählt für mich das vermeiden von externen Zugriffen auf bekannt unsichere Systeme dazu.

Ich kenne keinen Fall bei dem Plex geknackt wurde und darüber dann das NAS.

QTS und seine Dienste hat aber jetzt in 1 Jahr bereits 3 mal ein Einfallstor das auch automatisch ausgenutzt wurde.

Das ist also ganz anders zu bewerten.

Zitat von nasferatu

Weil die Angriffe zu 99% über irgendwelche Implementierungsfehler der jeweiligen Webanwendung, und das sind dann die Photostation, Musicstation, Plex etc. pp. passieren.

nasferatu

Dass Du Plex hier mit aufführst, erweckt bei mir den Eindruck, dass Du meinen Punkt nicht verstanden hast - oder nicht verstehen willst !?

Zitat von nasferatu

Es ist leider so, das VPN die z.Zt. sicherste Variante [...] ist.

Lass mich hierzu eine provozierende Frage stellen:

Woher weisst Du, dass nicht auch die verwendete VPN Lösung - z. B. FRITZ!Box VPN Server - einen Implementierungsfehler hat, der nicht bekannt ist aber bereits aktiv ausgenutzt wird?

Zitat von UpSpin

[...] Wie läuft denn Plex auf der NAS? In einer VM oder doch nur als App in QTS. D.h. Plex, somit die NAS mit allen Daten, sitzt wieder direkt im Internet. Natürlich nur mit einem bestimmten Port, der nur auf Plex geleitet wird, aber dahinter ist die ganze NAS voll drin.

UpSpin

Wie kommt man von einem veröffentlichen Port für PLEX auf das NAS dahinter?

Nehmen wir an, folgende URL für PLEX ist bekannt:

http://ip_address:12345/web/index.html

Wie kommt man nun z. B. auf http://ip_address:8080/cgi-bin/, wenn Port 8080 nicht offen ist?

Zitat von Timpov

Woher weisst Du, dass nicht auch die verwendete VPN Lösung - z. B. FRITZ!Box VPN Server - einen Implementierungsfehler hat, der nicht bekannt ist aber bereits aktiv ausgenutzt wird?

Ich kenn ja Deinen technischen Background nicht, aber ich bin in der Software-Entwicklung tätig. Und natürlich kann eine VPN Implementierung fehlerhaft sein. Es gab auch schon Fixes in diversen breit eingesetzten Kryptolibs. Das ist auch normal. Der Unterschied zu Plex ist, dass Plex eine komplett proprietäre SW ist, die von keinem außer dem Hersteller selbst (und den Hackern natürlich) auf Lücken abgesucht wird. Die VPN Implementierungen sind 1.) offen und 2.) hat das Protokoll eine festgelegte Funktionalität. Da hat sich seit Jahren nix dran geändert. Jede Webanwendung wird permanent erweitert, Plugins werden installiert etc. pp. Irgendeins hat dann eine Lücke und bumms, war es das mit der Sicherheit. Ein stabiles Protokoll, was nach derzeitigem Stand keine bekannten Sicherheitslücken hat und auch deswegen keinen oder sehr geringen Veränderungen mehr unterliegt ist da einfach durch die geringere Komplexität im Vorteil. Es hat nur einen Zweck: einen verschlüsselten Tunnel nach einem festgelegten Verfahren zu öffnen. Geringe Komplexität und festgelegte Standards sind das A und O bei sicherheitskritischen Anwendungen. Natürlich gibt es keine 100%ige Sicherheit. Aber schau Dir mal die Security Bulletins an und guck, wie häufig Webanwendungen komprommitiert werden und wie häufig VPN Lösungen gravierende Lücken aufweisen. Die Statistik dürfte da ziemlich eindeutig sein. Und dann kommt noch hinzu, das m.E. das ganze Webzeug auf dem QNAP häufig noch nichtmal in einem separaten Nutzerkontext mit eingeschränkten Rechten läuft, sondern einfach als root. Zumindest war das bisher mein Eindruck, ich will mich da nicht zu weit aus dem Fenster lehnen, aber es schien mir mal so als ich mir die Prozessliste angeschaut habe. Ich lass mich aber auch gerne korrigieren.

Dieser Artikel über eine Sicherheitslücke in Plex zeigt genau das, was dem einen Diskutanten (Cracyhorse) als nicht bekannt und dem anderen (Timpov) offensichtlich als unvorstellbar erscheint.

Zitat von Heise

In der Server-Komponente der Mediastreaming-Software Plex klaffen kritische Sicherheitslücken, durch die Angreifer etwa auf beliebige Dateien im Dateisystem des Servers zugreifen können – unter Umständen sogar übers Internet.

Hi nasferatu !

klingt gut, was Du schreibst. Nur, was hat mein technischer Background damit zu tun?

Zitat von phoneo

[...] und dem anderen (Timpov) offensichtlich als unvorstellbar erscheint.

Hallo phoneo

Wenn Du 'mal das Persönliche weglässt, kann das echt noch 'was werden mit uns Beiden!

Die Lücke von 2014 (!) ist mir durchaus bekannt; es gibt, bzw. gab sogar noch zwei weitere, wie man hier nachsehen kann.

Da kann man nur hoffen, dass die Plex Entwickler die vergangenen 5 Jahre (!) genutzt haben und die Schwachstelle mittlerweile behoben ist.

Im Übrigen finde ich 3 Lücken seit 2014 jetzt nicht 'mal soooo schlecht - Du nicht evtl. auch?

Grüße!

Ok das ist 5 Jahre her, der Patch kam nach 2 Wochen.

Da müssen andere erstmal ran kommen.

Intel bekommt es ja selbst in Gen 10 nicht gebacken.

Und das man einen Webservice immer pflegen muss, ist auch selbstverständlich.

Zitat von Timpov

klingt gut, was Du schreibst. Nur, was hat mein technischer Backround damit zu tun?

Nun ja, Du hast dezent angedeutet, dass ich DIch vielleicht nicht verstehen __will__ . Deswegen habe ich etwas weiter ausgeholt, um Dir meinen Standpunkt zu erklären. Du kannst gerne auf meine Argumentation eingehen, falls da was unklar sein sollte. Aber es könnte ja auch einfach sein, dass Dir die technische Problematik dahinter nicht ganz klar ist. Entweder hat man ein Haus mit einer fetten Panzertür mit exakt festgelegten Spezifikationen bezüglich Stahlsorte, Dicke, Schloßwiderstandsfähigkeit. Oder man hat einen bunten Strauß von Türen, die mal mehr oder weniger robust aussehen, was aber nie jemand ernsthaft überprüft hat. Auch die Panzertür kann Fehler haben. Aber die Wahrscheinlichkeit ist aufgrund der geringeren Zahl an Freiheitsgraden doch spürbar geringer.

Hast Du Erfahrung in der Webentwicklung , mit den üblichen Fehlern, die da gerne mal auftreten wie nicht überprüfte Parameter, Code Injection, Directory Traversal etc. ? Und das Argument, dass es "nur" 3 Sicherheitslücken gegeben habe ist ja auch nur bedingt stichhaltig. Kennst Du Shodan ? Immer mal einen Besuch wert.

Ihr könnt natürlich machen, was ihr wollt. Ich mache es aus den genannten Gründen NICHT! Wenn es ein einzelnes NAS wäre, was ausser Musik und FIlmchen nix privates enthielte würde ich das Riskiko zugunsten der Bequemlichkeit vielleicht wagen. Aber auch nur in einem abgeschotteten Netz. Wie gesagt, jeder hat das Recht, sich selbst ins Knie zu schießen. Vielleicht wirds ja auch nur ein Streifschuss...

Zitat von Timpov

Du nicht evtl. auch?

Lenk mal jetzt nicht vom Thema ab. Vielleicht habe ich ja deine Frage an UpSpin nur falsch verstanden. Ich denke, dass die 2014er Sicherheitslücke ein passendes Beispiel dafür ist, auch über Plex an Daten des dahinterliegenden Servers zu kommen.

Zitat von phoneo

Ich denke, dass die 2014er Sicherheitslücke ein passendes Beispiel dafür ist, auch über Plex an Daten des dahinterliegenden Servers zu kommen.

Hm, um ehrlich zu sein, glaube ich, dass Du hier eine 5 (!) Jahre alte Lücke ausgräbst, weil Du mich nicht leiden kannst.

Mein Standpunkt sollte doch mittlerweile klar sein: "nur", weil sich QNAP in letzter Zeit wahrlich nicht mit Ruhm bekleckert hat, ist nicht alles andere automatisch ebenfalls schlecht und voller Fehler.

Und wenn man diverse Dienste und Anwendungen von außen verfügbar machen möchte, kann man das mit Augenmaß meiner Ansicht nach ebenfalls tun - solange man eben nicht die ganze Kiste ins Internet stellt.

Und was Plex angeht, habe ich gerade 'mal nachgeschaut: von Anfang Dezember 2018 bis Ende Oktober 2019 habe ich 24 (!) Updates mitbekommen.

Wie Crazyhorse ja auch schon geschrieben hat - die scheinen ihr Produkt echt weiterzuentwickeln, zu patchen etc. und sind flott unterwegs.

Gruß!

PS:

Deiner Argumentation folgend, sollte man Produkte der Firma Cisco besser nicht mehr einsetzen - die scheinen vor Jahren auch schon 'mal Probleme gehabt zu haben... - Link

Zitat von Timpov

Hm, um ehrlich zu sein, glaube ich, dass Du hier eine 5 (!) Jahre alte Lücke ausgräbst, weil Du mich nicht leiden kannst.

Ich kann deine Art zu argumentieren nicht leiden. Aber gegen den Menschen Timpov habe ich nichts. Du stellst Aussagen, die von anderen Forenteilnehmern gemacht werden infrage, aber bleibst selber in der Unterstützung der eigenen Standpunkte recht dünn und lenkst dann vom Thema ab.

Das Alter der Sicherheitslücke ist unerheblich, wenn es darum geht zu zeigen, dass man offensichtlich über eine Schwachstelle im Webserver von Plex auf die Daten des dahinter liegenden Servers zugreifen konnte. Mit der Frage an Upspin wollten du eigentlich zu dem Ergebnis kommen, dass ein über einen einzelnen Port freigegeber Webserver kein großes Sicherheitsrisiko darstellt, weil der Angreifer nicht aus der Umgebung des Webserverdienstes ausbrechen könnte. Und diese Annahme ist damit wiederlegt.

Zitat von Timpov

Und wenn man diverse Dienste und Anwendungen von außen verfügbar machen möchte, kann man das mit Augenmaß meiner Ansicht nach ebenfalls tun - solange man eben nicht die ganze Kiste ins Internet stellt.

Ach, nun kommt der Sprung von einem einzelnen Dienst von außen verfügbar machen, zu diversen Diensten und Anwendungen. Es wird dich keiner daran hindern. VPN wird trotzdem die sicherere Lösung sein und das lässt sich schlecht wegzudiskutieren.

Zitat von Timpov

Hm, um ehrlich zu sein, glaube ich, dass Du hier eine 5 (!) Jahre alte Lücke ausgräbst, weil Du mich nicht leiden kannst.

Mein Lieber, es ging niemals um das Alter der Sicherheitslücken, sondern um das dahinterliegende Prinzip. Und da Du ja offensichtlich auf die technischen Argumente nicht eingehen kannst oder willst brauchen wir das nicht weiter auszudiskutieren. Du kannst gerne glauben, dass ein Webinterface sicher ist wenn man den Port ein bisschen verdreht oder auch dem Hersteller glauben, dass alles supi ist. Solange man Äpfel mit Birnen vergleicht kommt eben bestenfalls Obstsalat dabei raus...

Zitat von phoneo

[...] Das Alter der Sicherheitslücke ist unerheblich, wenn es darum geht zu zeigen, dass man offensichtlich über eine Schwachstelle im Webserver von Plex auf die Daten des dahinter liegenden Servers zugreifen konnte. [...]

Du gehst also davon aus, dass Dinge unsicher bleiben, weil sie unsicher waren?

Ich bin übrigens der Ansicht, dass man bei solchen Beispielen dann wirklich auch genau hinschauen muss.

Im von Dir aufgeführten Fall, wurde der Fix für die Lücke bereitgestellt, BEVOR die Lücke öffentlich gemacht wurde. Durch eine Aktualisierung seines Systems war man also durch die Lücke nicht angreifbar.

Und 'mal im Ernst: wenn es im Falle Plex aktuell keine bekannten Sicherheitslücken gibt - von mir aus auch: zu geben scheint -, kannst Du doch nicht eine 5 Jahre alte Lücke als Beleg dafür anführen, dass man aktuell auch besser die Finger davon lassen sollte.

Zitat von phoneo

aber bleibst selber in der Unterstützung der eigenen Standpunkte recht dünn

Und Du gehst auf die Unterstützung meiner Standpunkte nicht ein - oder magst Du noch ein Wort zu Cisco sagen?

Ich gehe doch davon aus, dass Deine Argumentation Plex betreffend auch für Cisco gilt.

Zitat von nasferatu

Mein Lieber

Sorry, soweit sind wir noch nicht...

Zitat von nasferatu

Du kannst gerne glauben, dass ein Webinterface sicher ist wenn man den Port ein bisschen verdreht oder auch dem Hersteller glauben, dass alles supi ist.

Solange mir keine erfolgreichen Angriffe auf die von mir verwendete Konfiguration bekannt sind, tue ich genau das.

Im Übrigen erklärt Deine sachliche und gute Argumentation ausschließlich, wie es zu Schwachstellen kommen KANN. Das bedeutet aber eben nicht, dass es auch aktuell bei allem so IST.

Um nicht mehr und nicht weniger geht es mir.