Wie mache ich meinen NAS möglichst sicher?

[itari]

Natürlich ist es auch ein Unterschied ob ein Angreifer dich aussucht oder generell Systeme mit Defaulteinstellungen angegriffen werden.

ich will jetzt nicht der Besserwisser sein, aber ich denke, diese Diskussion hier wird auch noch von vielen anderen gelesen und deshalb möchte ich den Faden noch ein wenig weiter spinnen ...

angenommne Szenarien:

(1) Da will jemand eine DiskStation via DSM angreifen. Dann informiert er sich darüber, wie eine DiskSation tickt und er weiß dann, dass in der Regel der DSM auf den Ports 5000 und 5001 liegt und vom System-Apache gehalten werden (sofern man sie denn im Router aufmacht). Und er weiß, dass man die Ports manchmal 'verstecken' möchte, also auf andere (z. B. im Router) umlegt. Dann ist es nicht wirklich schwer oder langsam, man gerade alle 2^16 Ports auf Webserver zu scannen, denn andere Protokolle interessieren ja bei dieser Intention nicht. Da das so ist, ist es offensichtlich eine scheinbare Sicherheit.

(2) Will jemand nur per Zufall offene Ports scannen, dann wird er die erfolgsversprechendste Strategie wählen, nämlich Windows-PCs suchen und sich nicht mit DiskStatons abgeben.

(3) Will jemand Linux-PCs/Linux-Server (da wäre dann auch unsere DiskStation als NAS dabei) auf offene Ports scannen, wird er ftpd, telnetd, sshd und anderes suchen, aber weil er sich ja nicht auf DiskStations spezialisiert hat, kaum den System-Apachen im Visier haben. Wäre das so, dann wäre es ja wieder so, wie unter (1) beschrieben.

=> für mich bedeutet das, dass die Portverlagerung des DSM keinen sonderlichen Schutz ausmacht, denn tritt Fall (1) ein, dann hilft nur ein starkes (für mich ab 12 Zeichen) und häufig gewechseltes Admin-Passwort (ungleich nie, ist schon häufig *gg*)

Absicherung wäre für mich, möglichst überhaupt nicht den DSM (System-Apachen) ins Web freizugeben, sondern alle 'administrativen Aufgaben' von außen entweder komplett zu unterlassen oder eben auf VPN umzustellen

Itari

 

[jahlives]

nur um das Thema auch für mich abzuschliessen Was ist denn wenn der DSM Login einen Fehler hat? z.B. wenn eine bestimmte Zeichenfolge dazu führen würde, dass der String direkt auf dem System ausgeführt würde? Dann würde auch https und Autoblock ned viel ausrichten können. Ich sage ja ned, dass Syno solche Lücken hätte, aber wie gesagt Potential ist vorhanden wenn ein Prozess unter root läuft

 

[jahlives]

@itari
habs bei mir mal gemessen mit einem TCP Scan (SYN Scan) über alle Ports (allerdings im LAN): 65535 TCP Ports in etwas über 6 Sekunden gescannt. Auch ein TCP connect scan geht mit 8 Sekunden nicht wirklich deutlich länger.

 

[itari]

@itari
habs bei mir mal gemessen mit einem TCP Scan (SYN Scan) über alle Ports (allerdings im LAN): 65535 TCP Ports in etwas über 6 Sekunden gescannt. Auch ein TCP connect scan geht mit 8 Sekunden nicht wirklich deutlich länger.

okay, gut zu wissen

Itari

 

[mskassel]

Hallo,

ich will mich dem Thema mal anschließen und ebenfalls etwas dazu beitragen. Ich stimme grundsätzlich itari zu. Damit wir dieses Thema nicht sprengen, fasse ich mal meine "big points" zusammen und nehme nur Bezug auf die Aspekte, die bis jetzt wenig oder noch gar nicht genannt wurden.

SSH solltest du mittels eines 2048 bit Zertifikates absichern und das login über Passwort gänzlich ausschalten. Port 22 darf ruhig offen aus dem Netz erreichbar sein, wenn du diese Methode angewendet hast!
1. ) Synology mittels SSH Zertifikat absichern

Lieber Port 5000 und 5001 Ich hasse euch, also habe ich mittels dem proxy_module die Ports auf https://meineip/dsm/ umgeleitet
2.) Mittels proxy_module den DSM umleiten auf z.B. https://meineip/dsm/

3.) Alle nicht benötigten Ports schließen und zwar schon am Router, nicht nur auf der Synology.

Jetzt kann man sich anfangen darüber zu streiten, aber... ich halte es für vertretbar diesen Weg zu beschreiten, denn wie bereits auf Seite 1 festgehalten wurde, nicht von überall kann man eine VPN Verbindung aufbauen!

Hm, was vergessen? Das SSL Zertifikat vom Apache sollte man ggf. auch mal ändern, aber den Key schön brav auf einen USB Stick sichern und im Tresor verschließen!!! Nicht auf der DS liegen lassen!!!
Überlegt euch, ob ihr wirklich FTP benutzen wollt. Der Dateimanger lässt sich ja auch umleiten auf z.B. eine Subdomain oder was auch immer. Man kann auch eine Subdomain z.B. admin.meineds.synology.me erstellen und die Seite über .htaccess schützen. Auf der Subdomain setzt ihr euch die Links zum DSM oder anderen Applikationen. So muss man sie sich nicht merken. Ich habe eine Feste IP Adresse und anfangs ohne diese Methoden, wurden täglich mindestens 10-12 Emails an mich verschickt, dass schon wieder jemand versucht hat port 22 oder wen auch immer mittels brute force zu knacken. 3 Loginversuche in 5 min und ban für 365 Tage sollte die meisten abhalten es zu schnell erneut zu versuchen. Viele Angriffe finden über gehackte Rootserver statt, so dass ein ban auf die IP durchaus Sinnvoll ist, da die sich im Regelfall nicht ändern sollte! Aber ACHTUNG, nicht selbst aussperren

 

[jahlives]

1) das bringt echte Sicherheit
2) solang der DSM von aussen direkt erreichbar ist gewinnst du imho nicht wirklich Sicherheit dazu. Das Risiko macht aus, dass der DSM erreichbar ist, und nicht so sehr auf welchem Port der läuft. SSL ist sicher immer besser als kein-SSL
3) da schliess ich mich an

Das Zertifikat des Apache kannst du draussen vor die Tür hängen oder hier im Forum posten. Ein Zertifikat (crt-File) ist immer für die Öffentlichkeit gedacht. Schützen musst du den Schlüssel, also das key File. Nur wird es sehr schwierig wenn du den Schlüssel ned auf der DS hast, denn wie willst sonst der Apache mit SSL starten? Dazu muss er sowohl Key als auch Zertifikat lesen können.
Zum Abschluss noch was: ein Ban für 365 wird mehr schaden als nützen. Denn die meisten IPs werden dynamisch sein. Also was heute der böse Hacker ist, ist morgen vielleicht dein Nachbar Mehr als ein paar Tage macht bei dynamisch vergebenen IPs imho nicht wirklich Sinn

 

[mskassel]

Bei Punkt 2 geht es mir um die alltäglichen "Angriffe" die dadurch ins leere laufen. Die Bots oder Portscanner sehen zwar Port 443 aber den DSM auf /DSM/ oder in einer Subdomain ... glaube kaum, dass diese Eventualität berücksichtigt wird. Die meisten werden versuchen Port 5000 oder 5001 zu scannen, scheitern zunächst und lassen es sein. Klar bleibt die Unsicherheit auf Port 80 oder 443... jedoch wer seine Webseite hosten möchte oder ähnliches hat es ja so oder so offen. Ich z.B. komme ja gar nicht drum herum. Nehme aber das kleinere Übel gern in kauf, indem ich Port 5000&5001 zu gemacht habe und lasse den DSM über 443 laufen.

 

[jahlives]

noch was zu dieser Proxy Geschichte: das kann u.U. auch böse ins Auge gehen, zumindest wenn man Autoblock aktiviert hat. Da der Request dann eigentlich von 127.0.0.1 an den DSM kommt könnte ich mir vorstellen (weiss es aber ned wirklich ob Synology das nicht abfängt), dass der Autoblock dann 127.0.0.1 blocken könnte
Leider kann man sich den Quellcode vom Autoblock ned angucken. Das könnte man nur verhindern wenn der Autoblock nicht die IP der Gegenseite sondern den Header des Proxy auswertet (meist X-FORWARDED-FOR). Das wiederum wäre aber wieder ein Risiko wenn der DSM ned hinter einem Proxy läuft, denn dann könnte man den FORWARDED Header so setzen, dass er auf dein LAN Netz passen könnte.
Teste doch mal was passiert wenn du von aussen auf den DSM zugreifst und das PW mehrfach falsch eingibst. Wirst du dann von Autoblock geblockt oder nicht?

 

[mskassel]

Also er blockt die öffentliche IP Adresse des Anschlusses, was für mich heißt, es geht nicht ins Auge. Er blockiert somit nicht den localhost! Zur Not hab ich ja noch mein UMTS Zugang und kann darüber per Putty oder DSM mich entsperren.