Zugriffe aus die DiskStation die nicht sein sollten

[Peter_Lehmann]

Ich kann einen eigenen Beitrag hier nicht editieren? Komisch ...

Also eine Ergänzung mittels Antwort:

Ich habe mich entschlossen, auch noch den ersten Beitrag aus der Trefferliste zu erwähnen. Hier ist wirklich sehr gut erklärt, was die Zustände bedeuten: Grundlagen von Port -Scans - Nmap

MfG Peter

 

[hueseyin-lutfi]

Hallo nochmal,

Ich bin doch verwirrt und habe folgende konkrete Frage:

Ich habe zwei DS an verschiedenen Orten (Städten), bei denen ich über Internet gemeinsame Ordner synchronisiere (Unter "Datensicherung und -wiederherstellung->Synchronisierung von gemeinsamen Ordnern"). Dafür wollte die DSM, dass ich den Port 22 für SSH freigebe (oder wie man es auch nennt). Ich habe diese Portweiterleitung auf der Fritz!Box vorher per UPNP durch die DSM-Routerkonfiguration einstellen lassen. Nachdem ich überall gelesen habe, dass UPNP und die automatische Routerkonfiguration nicht zu empfehlen ist, habe ich die Funktion auf der Fritz!Box komplett deaktiviert. Nun sind KEINE Ports freigegeben und die Synchronisierung läuft nicht mehr. Nun meine Frage: Wo sollte ich den Port 22 nun weiterleiten? Auf dem Router, oder auf der DS?

Gruß
Hüseyin

 

[dil88]

Muss im Router sein, denn die DS ist wegen NAT im Internet ja nicht sichtbar. Genau dafür ist der Router ja da.

 

[Peter_Lehmann]

Hallo Hüseyin,

du musst im Router eine Weiterleitung des (ankommenden) Ports 22 auf die IP der dahinter stehenden DS und dort natürlich auch wieder auf Port 22 machen.
Das bedeutet, dass der auf Port 22 der offiziellen IP ankommende Traffic über den Router auf den Port 22 der IP der DS geleitet wird und somit dort ankommt.
Und auf der DS muss dann natürlich auch der entsprechende Dienst (der sshd) gestartet sein, welcher seinerseits wieder auf Port 22 "lauscht". Das dürfte aber, da du ja an der DS keine Veränderungen vorgenommen hast und vorher alles funtionierte, gewährleistet sein.

OK?

MfG Peter

 

[hueseyin-lutfi]

Hallo Peter,

vielen Dank! Es funktioniert. Und ist diese Einstellung nun "gefährlich"? Bzw. wie kann ich gewährleisten, dass dieser Port 22 sicher genutzt wird?

Gruß
Hüseyin

 

[Peter_Lehmann]

Bereits der Kauf und der Besitz eines Rechners ist "gefährlich". Und schließt du ihn ans Internet an, wird es schon sehr gefährlich. Und lässt du ihn aus dem Internet erreichbar sein, dann ist es schon extrem gefährlich ... .
Trotzdem gibt es mittlerweile Milliarden von IT-Geräten, die aus dem Internet ereichbar sind. Es geht eben nicht ohne.
Wie ich bereits mehrfach geschrieben habe, betrachte ich ssh als eine sichere Verbindung (ohne dass ich jetzt und hier "Sicherheit" ausdiskutieren möchte). Du solltest dich mit dem Thema der Härtung des sshd befassen. Material gibt es dazu über die Suchmaschine deines Vertrauens genug. Nutze dazu meine Stichworte, die ich in vorherigen Beiträgen genannt habe.
Und bis du das mit dem Verbot der Authentisierung mit Benutzername und Passwort und dafür der Auth. mit asymmetrischen Schlüsselpaaren eingerichtet hast, vergebe zumindest ordentlich lange Zufallspasswörter. 24 Stellen, a-z, A-Z, 0-1 und ein paar internationale Sonderzeichen halten schon eine ganze Weile.

OK?

MfG Peter

 

[hueseyin-lutfi]

Vielen Dank für die ausführliche Unterscheidung der Gefahren-Klassen Welches Passwort sollte ich denn "verstärken"? Der Benutzer, der die Verbindung vom Quell-DS zur Ziel-DS herstellt?

Gruß
Hüseyin

 

[Peter_Lehmann]

Das Passwort, mit welchem sich der ssh-Client am ssh-Server anmeldet. Also das des jeweiligen "ssh-Benutzers". Bei einem automatischen Backup dürfte das PW wohl in einem Script bzw. einer Konfig-Datei stehen. Damit kann es auch problemlos etwas länger und komplexer sein, als üblich.

MfG Peter

 

[hueseyin-lutfi]

Hallo Peter,

sorry für meine Unwissenheit, aber ich weiss nichts von einem Passwort in einem Script oder einen ssh-Benutzer. Wie im Screenshot zu sehen ist, gebe ich einen Benutzer mit PW der im Ziel-DS hinterlegt ist im Speicherziel der Sicherungseinstellung ein.



Gruß
Hüseyin

 

[Peter_Lehmann]

Hallo Hüseyin,

Ja, in diesem Fall (ich habe mir diese Anwendung nie angesehen) ist das etwas anders.
Hier hat Synology ein Anwendung geschrieben, welche ssh als eine Art VPN verwendet ("Übertragungsverschlüsselung aktivieren"). Man kann nämlich ssh nicht nur zur Fernadministration nutzen, sondern darüber auch (fast) alle Protokolle tunneln => verschlüsselt übertragen.
In diesem Fall hast du keine Möglichkeit, selber Hand anzulegen. Oder anders gesagt, ich würde dir (mit deinem Kenntnisstand) niemals mit ruhigem Gewissen empfehlen, selbst die sshd-Konfigurationsdatei (sshd_config) zu editieren und insgesamt händisch auf PubkeyAuthentication umzustellen oder noch andere "Anpassungen" vorzunehmen.
Und dazu kommt, dass ich von diesem Synology-Programm auch selber absolut keine Ahnung habe. Ich traue Synology schon zu, dass sie das von Hause aus bereits sichtig konfiguriert haben. Aber etwas einer Firma zuzutrauen und etwas zu wissen, sind ja (gerade in der IT-Sicherheit) zwei grundverschiedene Sachen.

Meine Empfehlung:
- Du hast mit diesem Programm (als bestandteil des DSM) ein fertiges kommerzielles Produkt gekauft. Nutze es so, wie es ist und lasse die Finger von "Anpassungen".
- Da du in der GUI ein Passwort fest einstellen kannst, "verpasse" diesem Benutzer ein "ordentliches" Passwort, welches du (wie hoffentlich jedes PW) auch regelmäßig wechselst.
- Und solltest du mal in späteren Zeiten irgend ein unixoides System per Konsole warten wollen, denke an meine Ratschläge zum sicheren Betreiben von ssh ;-)


Sorry, wenn ich dich mit meinen vorherigen Postings etwas verunsichert habe!
MfG Peter

 

[hueseyin-lutfi]

Hallo Peter,

ok, ich werde dann diesem Benutzer ein ordentliches PW mit 24 Stellen und allen Möglichen Zeichen verpassen und hoffen, dass es hält. Danke dir für deine Bemühungen und ich bin keineswegs verärgert darüber, dass du mich verunsichert hast. Im Gegenteil, hat mich dieser Thread über das Thema Sicherheit zumindest sensibilisiert.

Gruß
Hüseyin

 

[hier-in-berlin]

@Peter: Danke dir!! Hatte auch die Überlegung aufgestellt, ob das Deaktivieren der Port-Regel dazu führt, dass die Anfrage von der Firewall des Routers einfach nicht geblockt wird, dann wäre die Firewall des NAS die nächste Instanz oder aber: der Zugriff erfolgt ungehindert. Das Schliessen aller Ports führt in jedem Fall dazu, dass ich von ausserhalb keinen Zugriff mehr auf´s NAS habe. Da werde ich noch nach dem entsprechenden Port oder der entsprechenden Port-Kombination suchen.

 

[hueseyin-lutfi]

Hallo Puppetmaster,

wie kann man denn den Port 22 für ssh in einen 5stelligen Portnummernbereich verlegen?

Gruß
Hüseyin

 

[tops4u]

Am einfachsten indem Du das über die NAT Konfig vom Router machst. Also z.B. Incomming Port 54772 auf Port 22 des NAS mappst.

 

[Puppetmaster]

wie kann man denn den Port 22 für ssh in einen 5stelligen Portnummernbereich verlegen?

Das geht nicht in jedem Fall. Bei mir nutze ich SFTP, dazu benötige ich den SSH Zugang. Für SFTP kann man in den Einstellungen angeben, auf welchem Port er die Verbindung aufbauen soll.

Wenn man die "Sicherung und Wiederherstellung" des DSM nutze und dort "gesicherte Verbindung" einstellt, dann hat man dort eigentlich keine Wahl, denn dort läßt sich der Port 22 nicht verbiegen.

 

[Peter_Lehmann]

Meine Meinung zu diesem IMHO sinnfreien "Verbiegen" der Standardports => "Security through obscurity" kennt ihr ja ... .
Trotzdem ist es immer möglich, für die ankommende (!) ssh-Verbindung im Router eine Portweiterleitung von einem "beliebigen" Port auf den intern verwendeten Port 22 einzurichten. So kann der Admin bei einer normalen Administrationsverbindung (Konsole, Putty o.ä.) diese über den gewählten Port aufbauen. Und zwar ohne in den Innereien des Servers herumzufummeln.
Natürlich funktioniert das nur, wenn ich diese Verbindung eben "händisch" aufbaue, also den Port dabei frei wählen kann.
(Ja, auch ich verwende das, um damit verschiedene Geräte aus dem Internet anzusprechen: Port = 22<und die letzten drei Stellen aus der IP des Gerätes>

Selbstverständlich kann man versuchen, die Konfiguration des sshd zu verändern. Wer weiß, was er tut, kann das gern tun. Es besteht zumindest die Möglichkeit, dass damit nicht nur der sshd an sich, sondern auch darauf aufbauende Programme dann diesen Port verwenden. (Wenn das so funktioniert, kann man auch gleich "richtig" ssh machen, indem man auch die Benutzername+Passwort-Authentifizierung verbietet und auf public key setzt!)

Trotzdem, ich bleibe bei meiner Aussage, dass ich das Verbiegen der Standardports als sinnfrei ansehe, und dem "unbedarften User" derartige Manipulationen nicht empfehle. Was ihr letztendlich macht, ist eure Sache. Ihr seid erwachsen. Aber heult mir nicht die Ohren voll, wenn ihr nicht mehr "rein" könnt!


MfG Peter

 

[hueseyin-lutfi]

Ok, aber ist die Anleitung von tops4u nicht "einfach" anwendbar?

Gruß
Hüseyin

 

[Peter_Lehmann]

Du hast meine Antwort auch wirklich bis zum Ende gelesen? Ich frage ja nur ... .
Auch Puppetmaster schrieb zu diesem Thema.

 

[Puppetmaster]

Trotzdem, ich bleibe bei meiner Aussage, dass ich das Verbiegen der Standardports als sinnfrei ansehe

Ich gebe dir da grundsätzlich Recht, aber nicht vollumfänglich!!
Meine Motivation, und ich denke andere Benutzer werden das teilen, ist dabei gewesen: SFTP betreiben und nicht ständig logs von unautorisierten Benutzern zu haben.
Das mache ich aus 2 Gründen (bzw. habe das gemacht):

• 
  Wenn du deine DS gerne so nutzen möchtest, dass ein vernünftiger Ruhezustand (der Festplatten) möglich sein soll, wird das mit einem nach aussen offenen Port 22 nicht gelingen. Die Platten fahren halt ständig wieder hoch, um das Log eines fehlerhaften Autorisierungsversuchs zu schreiben.
  In den letzten 12 Monaten habe ich genau 0 fehlerhafte Logs auf einem offenen 5stelligen SSH-Port gehabt.

• 
  Die Zahl der automatisierten "Angriffe" sinkt rapide. Hier muss sich schon jemand anstrengen, wenn er etwas erreichen will. Dann hat er es aber wohl eh gezielt auf mich abgesehen und dann retten mich nur noch starke Passworte oder andere Autentisierungsmechanismen. - Ich trenne damit sozusagen etwas die "Spreu vom Weizen". Grundsätzlich erhöhte Sicherheit verspreche ich mir nicht davon.

Dann die Netzwerksicherung. Da läßt sich mit den Mitteln, die Ports im Router zu verbiegen, leider nicht viel anfangen, ohne in der SSH-Config auf Konsolenebene herumzuwühlen. Die Sicherung wird auf der Quell-DS immer versuchen, eine Verbindung auf Port 22 herzustellen, das läßt sich (leider) nicht über die Oberfläche ändern.

 

[Peter_Lehmann]

OK Puppetmaster, was deine beiden Argumente betrifft: full ack!
Ich habe mich bei meinen entsprechenden Meinungsäußerungen immer auf die Belange der IT-Sicherheit bezogen. Und deshalb bleibe ich dabei, dass der Nutzer, welcher eben die Ports bestimmter Dienste nach eigenem Gutdünken verlegt, keinen wirklichen Sicherheitsgewinn erreicht.

Der Scriptkiddie, der mit seinem aus dem Netz geladenen Programm große IP-Bereiche nach bestimmten für ihn interessanten Ports abklopft, lässt sich durch solche Tricks schnell ablenken. Schließlich produziert er auch geschätzte 95% der nachgewiesenen "Angriffe".
Der professionelle Angreifer der wirklich via ssh "reinkommen" will, lässt sich viel Zeit, hat professionelle Werkzeuge und lacht über Versteckspiele. Aber der produziert ja auch den geringsten Anteil an überhaupt nachweisbaren Angriffen.
=> deshalb volle Zustimmung zu deinem Argument 2

Was dein erstes Argument betrifft, so habe ich dieses überhaupt nicht in meine Überlegungen einbezogen. (Danke für den Hinweis!)
Zum einen ist der Ruhezustand von Festplatten im professionellen/kommerziellen Serverbetrieb eine sehr seltene Spezies - im Unterschied zum zumeist privaten NAS. Und in KMU wird man bestimmt das NAS Timergesteuert in der Nacht herunterfahren. (So wie ich das mache).
=> OK, für diesen Fall und für ein langes Leben der HD ist der versteckte sshd eine gute Lösung. Wobei ich mir auch gut vorstellen kann, bestimmte Logs auf angesteckte USB-Speichersticks zu verlinken. (Ist aber auch nichts für den ONU).

BTW: Freuen wir uns auf ssh Version 6.5.


MfG Peter