OPEN VPN SIcherheit

[pitamerica]

Hi, weiß jemand, ob alle momentanen open ssl Sicherheitslücken mit der aktuellen DSM 5.2 5967 Update 2 behoben sind ? Oder nur in DSM 6.x

Danke !

 

[Fusion]

unbekannte aktuelle Sicherheitslücken also ausgenommen.

Selbst alle bekannten Lücken sind vermutlich nicht behoben (und ja, auch DSM 5.2 und DSM 6 unterscheiden sich offensichtlich), sondern nur jene, welche Synology als relevant betrachtet, oder welche zufällig dann mitbehoben sind mit einem openssl update.
Finden sich ja auch immer noch fast jeden Monat neue, wenn man sich das so ansieht.

https://www.synology.com/de-de/support/security/OpenSSL_Vulnerabilities
https://www.openssl.org/news/vulnerabilities.html#y2016

 

[pitamerica]

weil ich eine DS mit 5.2 5967 Update 2 und eine DS mit 4.2 3256 laufen habe. Beide mit openvpn Server. Ist das dann potenziell unsicher ?

 

[Fusion]

Potentiell unsicher ist es immer bzw jedes System, das einem Netzwerk ausgesetzt ist, solange es unbekannte Lücken/Bugs gibt.

Die OpenVPN Sicherheit hängt ja nicht direkt (is mir grad keine bessere Formulierung eingefallen) mit Lücken in OpenSSL zusammen. Da gilt es ja zu unterscheiden nach Angriffen auf die Verschlüsselung oder Angriffen mit dem Ziel ein System zu kapern.
Zumindest bei DSM 5 habe ich aktuell noch keine Sorge, dass das Risiko unnötig hoch wäre.

Ganz sicher gehen kann man wohl nur, wenn man sich anschaut, welche Versionen auf Synology installiert sind und welche Lücken diese aufweisen und welche Risiken dabei bestehen.
https://www.cvedetails.com/vulnerability-list/vendor_id-3278/Openvpn.html

 

[Andy14]

Da würde ich mir als "normaler" User keine Gedanken machen!
Bei der wirklich schwerwiegenden Lücke "Heartbleed-Bug" gab es auch Patches für 4.2.

 

[pitamerica]

Da würde ich mir als "normaler" User keine Gedanken machen!
Bei der wirklich schwerwiegenden Lücke "Heartbleed-Bug" gab es auch Patches für 4.2.

Ja, die habe ich auch sofort nach Verfügbarkeit installiert.

Es gibt ja noch eine Lücke bzgl. der Cipher Encryption. Wisst ihr da bescheid ?

 

[Andy14]

Falls du "FREAK" meinst
https://www.heise.de/security/meldu...n-Millionen-Webseiten-angreifbar-2566444.html
ja die ist auch geschlossen.
Die letzte 4.2 hat Openssl 1.0.1m
Aber selbst bei dieser Lücke glaube ich kaum das ein Angreifer den Aufwand betreibt um auf ein privates NAS zu kommen.
Aus OpenVPN

An attacker requires a man-in-the-middle position.
An attacker has to invest time and money per OpenVPN instance (restart) to attack a connection, which makes this relevant for targeted attacks only.
OpenVPN always provides PFS with its own key exchange mechanism, making it impossible to decrypt sessions prior to a successful factorization of the temporary export key, even if those connections already used an RSA_EXPORT cipher.

 

[pitamerica]

Das hört sich gut an. Vielen Dank. Nun hoffentlich die letzte Frage

Beim Export der Konfigurationsdateien aus DSM wird ja immer auch die ca.crt Datei mit exportiert. Das ist ja quasi das Zertifikat. Wenn ich diese Dateien in Tunnelblick OS X aktiviere funktioniert die Verbindung ohne Probleme. Aber im Log File von Tunnelblick ist zu lesen : warning no client certificate. Und etwas von nur 128bit lese ich auch. Das klingt seltsam.

 

[Fusion]

Normal findet die Auth per user/pass statt. Man kann nun anstatt oder zusätzlich noch ein Client Zertifikat nutzen um sich gegenüber dem Server auszuweisen. Im Normalfall weist sich eben nur der Server gegenüber dem Client mit einem Zertifikat aus.
Nimm einen extra VPN Nutzer und ein starkes Passwort, dann bist du gut bedient.

"Irgendwas von 128 Bit" ist leider zu unpräzise, als dass man da was drauf antworten könnte.

 

[Andy14]

Das mit den 128 Bit ist schon richtig, default auf der Synology.

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

Bei der ds716+ zeigte sich bei einem Vergleich von AES-128 zu AES-256 ein Verlust von ca. 30% der Performance.
AES 128 bit vs AES 256 bit

Gegen den AES sind zurzeit keine praktikablen Angriffe bekannt, deshalb kann man sich fragen, ob der Verlust von bis zu 30% der Performance sinnvoll ist. Ein führender Kryptografie-Experte hat in mehreren Artikeln sich für AES-128 ausgesprochen, da AES-256 Designschwächen enthalten. Man spricht davon das AES-128 stärker ist, als AES-256 (Thema „key schedules“ und Zufallszahlengenerator).

[1] Bruce Schneider, 2009
[2] Guess why we're moving to 256-bit AES keys, 2013

 

[pitamerica]

Normal findet die Auth per user/pass statt. Man kann nun anstatt oder zusätzlich noch ein Client Zertifikat nutzen um sich gegenüber dem Server auszuweisen. Im Normalfall weist sich eben nur der Server gegenüber dem Client mit einem Zertifikat aus.
Nimm einen extra VPN Nutzer und ein starkes Passwort, dann bist du gut bedient.

"Irgendwas von 128 Bit" ist leider zu unpräzise, als dass man da was drauf antworten könnte.

Genau so läuft es eben gerade bei mir. Dann bin ich ja erst mal beruhigt. Euch allen vielen Dank. Top hier

 

[dany]

Hallo pitamerica

Ich habe vor ein paar Monaten mich mit dem Thema OpenVPN härten auseinander gesetzt. Theoretisch kannst du noch die tls-auth einrichten.
http://www.synology-wiki.de/index.php/OpenVPN_härten

Mit einer HMAC Signatur werden alle Pakete die bei der TLS Handshake involviert sind signiert. Werden Pakete ohne die richtige HMAC Signatur gesendet/empfangen werden sie auf der Stelle verworfen. Damit verhindert man:

• DoS- Attacken oder Port-flooding auf dem OpenVPN UDP port.
• Port scanning um zu verhindern ob der Server UDP Port abhört
• Buffer overflow Sicherheitslecks in the SSL/TLS-Implementation
• SSL/TLS Handshake Initiierung eines nicht-autorisierenden Computers

Grundsätzlich wird die Verbindung fehlschlagen, da das Zertifikat falsch sein wird. Mit der tls-auth Methode wird aber die Verbindung schon an einem früheren Zeitpunkt gekappt.

Gruss Dany