Sicherheit bei freigegebenen Ports

[nassa]

Hallo,
ich habe jetzt an meinem Router die Ports 443, 5001 und 5006 freigegeben und leite sie direkt zu meiner Diskstation.
Die gleichen Freigaben habe ich auch in der DSM Firewall eingepflegt!

Nur für mich zum Verständnis:
Wenn von außen mein Router eine Anfrage mit der Portnummer 5001 erhält, leitet er diese Weiter an meine Dickstation.
Die Dickstation lauscht auf Port 5001.
Die Sicherheit besteht jetzt darin, das meine Dickstation über HTTPS ein Weboberfläche anbietet, in dem man einen
Benutzernamen und Passwort eingeben muss um weiter auf die Verwaltungsoberfläche zu gelangen.
Also sollte das Passwort logischerweise sehr starkes sein!

Das bedeutet wenn ich bei Heise den Firewalltest direkt auf die Ports 443, 5001 und 5006 durchführe, bekomme ich logischerweise
die Rückmeldung das die Ports offen sind! die Sicherheit liegt dann auch wieder in der Anmeldung (Passwortstärke)!
Das ich nur über verschlüsselte Verbindungen zu meiner Dickstation gelange, ist mein Passwort über die Verbindung nicht mitzusniffen (was für ein wort

Sehe ich das bisher so richtig?

Für Bestätigungen, Anmerkungen und sonstige Hinweise schon mal jetzt vielen Dank
nassa

 

[dil88]

Willkommen im Forum!

Das siehst Du m.E. richtig. Allerdings will ich zwei Dinge zu bedenken geben: 1. Das Passwort ist nur für diejenigen nicht mitzusniffen, die nicht imstande sind, die Verschlüsselung zu knacken. Dass es hier bei Akteuren wie der NSA Bemühungen und Möglichkeiten gibt, dürfte bekannt sein. 2. Neben der Frage der Passwortstärke muss Dir klar sein, dass auch Lücken in der Software eine Rolle spielen. Welche Auswirkungen diese haben können, hat aus meiner Sicht auch etwas damit zu tun, welche Fähigkeiten die Software hat. Und genau da gibt es einen nicht unterheblichen Unterschied beispielsweise zwischen der PhotoStation, die Port 443 nutzt, und dem DSM-Webfrontend, dass man über Port 5001 erreichen kann. Insofern würde ich mir gut überlegen, ob ich beispielsweise Port 5001 öffne.

 

[nassa]

Willkommen im Forum!

Danke

Deine Anmerkungen finde ich richtig gut.
zu 1) Zum Thema "Verschlüsselung" ist klar, wer es knackt, hat er auch die Passwörter und damit auch Zugang. Wenn das mal geknackt wird, dann denke ich wird es im Netz
herumgehen wie ein Feuerwerk und ich kann dann noch handeln. Das bestimmte Sicherheitsbehörden mit Hilfe des Quellcodes an unsere Daten herankommen, davon gehe ich aus.
Apple hat ja auch nicht offiziell (und damit rufschädigend) das Handy geöffnet, wer weiß wie die sich im Hintergrund geeinigt haben, auf jeden Fall hat Apple hierbei sein Gesicht gewahrt (naja, ich weiß) und das FBI die Handydaten.

zu 2)
Die Lücke in der Software plane ich mit ein und hoffe das Synology dank der doch sehr großen Anzahl an versierten Fach-Usern frühzeitig Kenntnis von Problemen und Lücken erhält und uns mit sofortigen Updates schützt ;-)
Den Hinweis zur Fähigkeit der jeweiligen Software und bei Lücken entsprechend die Möglichkeit für Angreifer zeigt mir, dass ich den Port 5001 wohl wieder schließe. Die Station muss ich nicht von Unterwegs administrieren.

 

[Frogman]

...1. Das Passwort ist nur für diejenigen nicht mitzusniffen, die nicht imstande sind, die Verschlüsselung zu knacken. Dass es hier bei Akteuren wie der NSA Bemühungen und Möglichkeit gibt, dürfte bekannt sein..

Eine solche Aussage könnte falsche Eindrücke erwecken. Eine aktuelle TLS-Verschlüsselung, wie sie auch die DS per default verwendet, ist aktuell nicht "zu knacken", das gilt sowohl für PFS-Varianten mit Schlüsseltausch zB. über ECDHE wie auch für gewöhnliche AES128-Verschlüsselung! Man muss sich also bei Verwendung von SSL beim Zugriff auf die DS keine großen Gedanken über die Güte der Verschlüsselung selbst machen
Wenn Gefahr besteht, dann liegt sie eher bei dem Einsatz von MITM-Attacken. Dagegen hilft bspw. Certificate Pinning oder Vergleichbares.

 

[dil88]

Zu 1. Entsprechende Informationen hat es ja bereits gegeben, dass die NSA beispielsweise aktiv in die Gestaltung von Algorithmen eingegriffen hat, die verschlüsselungsrelevant sind. Das zieht in Teilen Konsequenzen nach sich, dennoch sollte man sich dessen bewusst sein.

Zu 2. Synology hat hier in letzter Zeit deutlich mehr Aufmerksamkeit an den Tag gelegt. Nichtsdestotrotz ist der Verzicht auf die Nutzung der Administration aus der Ferne aus meiner Sicht eine gute Entscheidung.

 

[Frogman]

Gestaltung der Algorithmen beeinflusst? Welche? Die mathematische Stärke der heute eingesetzten Algorithmen ist ungebrochen.

...Das bestimmte Sicherheitsbehörden mit Hilfe des Quellcodes an unsere Daten herankommen, davon gehe ich aus.

Das DSM nutzt OpenSSL - das ist offen. Was aber mitnichten bedeutet, dass jemand deswegen an Deine Daten kommt!

 

[dil88]

Bei den Algorithmen sind es Sorgen (siehe z.B. dieser Bericht zu elliptischen Kurven). Ich habe aber auch einen Bericht gesehen, in dem der Einfluss der NSA auf Software-Entwicklung beschrieben wurde, finde den aber nicht so schnell. Mir geht es einfach darum, darauf hinzuweisen, dass beispielsweise https allein nicht reicht, sondern dass man sich ansehen muss, wie diese https-Verbindung verschlüsselt wird, dass man auf aktuelle Technologie achten muss. Und mir geht die Zertifikatsthematik (siehe z.B. hier) durch den Kopf und noch ein paar andere Dinge. Ich will das aber eigentlich gar nicht vertiefen, ist m.E. dann doch schon etwas zu weit weg vom topic.

Wenn da seitens Synology alles im Lot ist, bitte ich, meine Aussage zu ignorieren.

 

[Frogman]

Der Artikel ist aus 2013. In den letzten 3 Jahren gab es diverse Analysen und Publikationen zu der Frage der Kurvenparameter in der NIST-Suite B - die letztlich aber selbst bei Skeptikern zu der Einschätzung führen, die Suite B im Pre-Quantum-Zeitalter als sicher einzustufen. Letztlich wurden die P-Kurven mit 90er-Jahre-Equipment standardisiert - was nicht die Komplexitätsanforderungen erfüllt hat, um eine schwache Kurve zu konstruieren. Kurzum: niemand, der auf seiner DS mit DSM 5.2 eine SSL-Verbindung nutzt, muss sich Gedanken über die mathematische Härte der Verschlüsselung selbst machen. Und zum Thema SSL-Proxy hatte ich ja oben ein Stichwort geliefert.