openvpn sicherer als ssl?

[aportmann]

hallo zusammen

zurzeit habe ich bei meiner ds lediglich den standard-port für openssh geöffnet und greife extern mit dem iphone auf bilder und musik zu. natürlich muss dazu jeweils mittels openvpn-client eingeloggt werden. dieser vorgang ist nicht sonderlich befriedigend.

mit dsm 6 ist das einrichten für let’s encrypt denkbar einfach geworden. wenn ich nun noch port 443 und 5001 öffne und per ssl zugreife, wie hoch ist hier die zusätzliche gefahr?

… oder bin ich einfach zu paranoid?


gruss andi

 

[jahlives]

Also musst du ja wohl noch mindestens den Openvpn Port geöffnet haben.
Solange das Protokoll keine Lücken hat nehmen sich ssl und ssh nichts. Da kann man imho nicht sagen, dass das eine sicherer wäre als das andere.
Ein Zertifikat von LE ändert nichts an der Sicherheit einer SSL Verbindung. Die ist genau gleich sicher wie wenn man ein selbst signiertes Zertifikat verwendet.

 

[aportmann]

sorry, sollte oben openvpn, nicht openssl heissen.

 

[jahlives]

Und wenn ich dir jetzt sage, dass openvpn auch auf openssl basiert?

 

[jugi]

5001 aufzumachen bietet einem Angreifer, der dein PW kennt, halt zugriff auf "alles" - wobei das beim verwenden des ds-vpn-servers auch der fall ist…

Bleibtnoch die Frage nach Bugs im DSM/Webserver und OpenVPN…

 

[aportmann]

stimmt, aus diesem grund noch das 2-weg-login an der ds selber.
was mich ärgert bzw. ich unschön finde ist, dass die weboberfläche von meine.tld/photo ersichtlich ist (wenn auch keine photos selber)


gruss andi

 

[dany]

Ob Openssh oder OpenVPN sicherer ist kommt auf deine Einstellungen sowie auf die Clients an. Du kannst vorgeben, welche Verschlüsselung verwendet werden soll, ausschlaggeben ist aber dein Client. Du kannst OpenVPN oder SSH Optionen einstellen, bei der die Sicherheit erhöht wird. Auf meinen Android nutze ich z.b. die Musik-App der Synology via OpenVPN und bin sehr zufrieden damit.

mit dsm 6 ist das einrichten für let’s encrypt denkbar einfach geworden. wenn ich nun noch port 443 und 5001 öffne und per ssl zugreife, wie hoch ist hier die zusätzliche gefahr

Ich habe immer Bedenken das Admin-Interface für das Internet frei zu geben, den man weiss nie ob ein Sicherheitsleck vorhanden ist. Sollte jemand einbrechen können, könnter er grösseren Schaden anrichten.

 

[aportmann]

geht mir irgendwie genauso. ich glaube, ich belasse es beim offenen openvpn-port.

 

[dany]

Ich habe mich vor kurzem mit dem Thema OpenVPN härten beschäftig. Sollte interesse da sein, werde ich es auf dem Wiki noch ablegen:

https://stastka.ch/knowledge-base/OpenVPN-auf-einem-Synology-NAS-haerten/story/530

Edit; nun auf dem Wiki:

http://www.synology-wiki.de/index.php/OpenVPN_härten

 

[dil88]

Schöne Sache! Fände ich gut, wenn Du das auch ins Wiki setzen könntest.

 

[dany]

Ist nun drauf. Feedback ist wie immer erwünscht

 

[Frogman]

Na, da feedbacke ich doch gleich einmal: Wenn Du denn den Prozess auf einen gering privilegierten User herunterstufst, solltest Du zeitgleich auch die Option persist-key setzen, weil ansonsten der Daemon bei einem Restart den Key nicht mehr lesen kann (der Key sollte aus Sicherheitsgründen nur von root lesbar sein!). (Hinzu kommt idealerweise auch die Option persist-tun, die die Verbindung bei einem UDP-Reset offenhält bspw. anlässlich der Änderung der IP auf einer Seite (was bspw. bei Androiden bis Kitkat der Regelfall ist, weil dort zB. die Datenverbindung unterbrochen wird, wenn keine Daten fließen.) Zum Thema auth SHA512: Das wirkt nur auf den Hash der zusätzlichen HMAC-Paketauthentifizierung... man kann den getrost auf SHA1 belassen (alles andere bewirkt keine wirksame Sicherheitserhöhung, macht aber mitunter Probleme bei einigen Clients, die damit nicht umgehen können). Ein weiterer Aspekt betrifft die Diffie-Hellman-Parameter, die standardmäßig nur als 1024bit verwendet werden. Hier sollte man sich eigene mit 2048bit generieren (was ausreichend ist) und einbinden. Zum Thema AES 128bit bzw. 256bit hatte ich hier schon einmal etwas geschrieben - da 256bit sicherheitstechnisch keinen Vorteil bringt, dagegen aber spürbare Performanceverschlechterungen, sollte man sinnvollerweise bei 128bit bleiben.

 

[dany]

Mir ging es darum bei der Standardinstallation eine "Härtung" zu erziehlen.

Wenn Du denn den Prozess auf einen gering privilegierten User herunterstufst,
solltest Du zeitgleich auch die Option persist-key setzen,

persist-tun und persist-key sind Standardmässig schon gesetzt, daher nicht erwähnt.

Zum Thema auth SHA512: Das wirkt nur auf den Hash der zusätzlichen HMAC-Paketauthentifizierung... man kann den getrost auf SHA1 belassen (alles andere bewirkt keine wirksame Sicherheitserhöhung, macht aber mitunter Probleme bei einigen Clients, die damit nicht umgehen können).

Kann ich nachvollziehen, da ich keine Probleme hatte, habe ich es auf SHA512 gelassen.

Ein weiterer Aspekt betrifft die Diffie-Hellman-Parameter, die standardmäßig nur als 1024bit verwendet werden.
Hier sollte man sich eigene mit 2048bit generieren (was ausreichend ist) und einbinden.

Die Synology erstellt im Standard einen Schlüssel mit 3072 bit

Zum Thema AES 128bit bzw. 256bit hatte ich hier schon einmal etwas geschrieben - da 256bit sicherheitstechnisch keinen Vorteil bringt, dagegen aber spürbare Performanceverschlechterungen, sollte man sinnvollerweise bei 128bit bleiben.

Kann ich nachvollziehen, wohl ein Paranoia option. Ich konnte keine Performance verschlechterung messen da auf der ds716+ AES-NI verfügbar ist. Diese AES-NI Instruction Set kann soweit ich weiss AES beschleunigt duchführen.

Werde aber deine Anmerkungen einfliessen lassen, da nicht jeder eine Intel basierende Synology hat.

 

[Frogman]

... Ich konnte keine Performance verschlechterung messen da auf der ds716+ AES-NI verfügbar ist.....

Das nehme ich Dir für die DS211+, mit der Du ja auch getestet hast, nicht ab.

... Die Synology erstellt im Standard einen Schlüssel mit 3072 bit.....

Ich rede nicht von Schlüsseln, sondern von DH-Parametern..

Werde aber deine Anmerkungen einfliessen lassen, da nicht jeder eine Intel basierende Synology hat.

Eben darum ging es in meinen Anmerkungen, um die Du ja selbst gebeten hattest! Ansonsten solltest Du im Wiki-Artikel deutlicher auf hardwareseitige Gegebenheiten hinweisen. Desweiteren solltest Du Parameter, wie sie aktuell gesetzt werden, nicht als allgemeingültig voraussetzen - es gibt auch User, die ältere Versionen verwenden, bei denen andere Default-Einstellungen gelten. Daher halte ich es immer für ratsam (zumindest in einem Wiki-Artikel), Dinge eher vollständiger zu beschreiben und dann einzuschränken, wenn es angezeigt ist.

 

[dany]

Ich fand dein Feedback gut, und habe es im Wiki einfliessen lassen, werde sicher noch mehr ergänzen.

Zur Performance habe ich es genau wissen wollen. Mit dem openssl habe ich die Geschwindigkeit der einzelnen cipher Messen wollen und habe sie auf der ds716+ und der ds211+ durchgeführt und durch das Excel gejagt:

openssl speed sha -elapsed

openssl speed aes -elapsed

Dabei zeigte sich, das von der ds716+ zur ds211+ bei 16 bytes 3x Schneller rechnet, und die je grösser die Datenmenge wird bis zu 8x.
Bei der AES-128, AES-192 und AES-256 CBC zeigt sich, das innerhalb des gleichen Gerätes die Performance um 16% bei AES-192 und 26% bei AES-256 veringert.
Die grösste Überraschung war bei der SHA-1 zur SHA-512 berechnung. Da verlor die ds211+ 80% der Geschwindigkeit. Daher würde ich bei der ds211+ sicher empfehlen das man SHA1 als HMAC-Paketauthentifizierung nehmen.

Gruss Dany