China versucht meine DS 214 zu hacken

[Huede82]

Grüss euch

seit gestern versuchen ständig unterschiedliche IP`s aus China auf meine DS zuzugreifen.
Bemerkt habe ich dies durch die Ereignisanzeige.
Wie kann ich rausfinden, über welche Ports die versuchen reinzukommen?
Soll ich mir Sorgen machen?
Und welche Sicherheitseinstellungen soll ich aktivieren?
Laut DS eigenen Sicherheitsüberprüfung ist alles im grünen Bereich....

aktiviert:
DDOs Attacken über LAN & PPOE
automatische Blockierung
Guest ist deaktiviert

Kennwortstärke ist auf max -> Sonderzeichen, Gr/Kl + Ziffern....




Vielen Dank für Tips.

 

[Puppetmaster]

Vermutlich Port 22, der ist prädestiniert dafür.

Sicherheitsrat No.1: nur die Ports öffnen, die man unbedingt benötigt! Am besten gleich ein VPN verwenden.

Und nur weil ein paar Kids in China deine Zugangsdaten durchprobieren ist das noch keine Gefahr - sehr gut gewählte Passworte einmal vorausgesetzt...

 

[Huede82]

Danke Puppetmaster

habe gerade auch den Thread http://www.synology-forum.de/showth...Hacker-auf-meine-DMS-aus-China-bitte-um-Hilfe gefunden.

Ich habe gestern Test weise die Portweiterleitung für sftp aktiviert gehabt... und ja, Port 22.... seit dem ist das Problem aufgetaucht....
Lustigerweise bei Port 21 war das nicht....

Und die Firewall der DSM wurde jetzt auch mit GEO-IP Filter aktiviert, müsste auch schon mal reichen...

Danke

 

[Puppetmaster]

Und die Firewall der DSM wurde jetzt auch mit GEO-IP Filter aktiviert, müsste auch schon mal reichen...

1) man kann IPs fälschen
2) es gibt nicht nur böse Menschen in China, auch in Deutschland gibt es die

Es bleibt beim oben beschriebenen Sicherheitsrat No.1

 

[Huede82]

klar, Port wurde schon umgestellt auf einen 5 stelligen.

 

[raymond]

Man kann den Zugriff auf bestimmte IPs beschränken oder Zugriff von Ländern zulassen oder verweigern: http://www.synology-wiki.de/index.php/Grundsätzliches_zum_Thema_Netzwerksicherheit

Klar kann man die IP fälschen (Proxy zum Beispiel). Wenn man jedoch nur IPs von Deuschland zulässt: so viele öffentliche Proxys in Deutschland gibt's auch nicht. Ist für den Angreifer wieder eine Hürde mehr.

Autoblock und ein langes Passwort was nicht im Wörterbuch steht ist meiner Meinung nach der beste Schutz. Zusätzlich nicht die IP oder DDNS Namen nirgends in den öffentliches Bereich des Internets posten.

 

[Puppetmaster]

Das hatten wir ja schon oben geklärt.

 

[raymond]

Update meines Posts oben...

 

[Peter_Lehmann]

klar, Port wurde schon umgestellt auf einen 5 stelligen.

Man kann den Zugriff auf bestimmte IPs beschränken oder Zugriff von Ländern zulassen oder verweigern

Sehr gute Tipps! (Wirklich?)
So etwas nennen wir Security through obscurity – Wikipedia

Das ständige automatisierte (!) Rütteln an mit ssh gesicherten Zugängen ist das normale Rauschen des Internets. Wer ssh zur Fernwartung oder in Form von sftp zur Datenübertragung benötigt, muss damit leben. Aber tut uns das wirklich weh? (Außer, dass es die Logs vollmüllt)
Was ich von einer Begrenzung der IP oder gar dem Verbiegen des ssh-Ports von :22 auf einen anderen Port halte => siehe oben.
Ja, Scriptkiddies kann man damit ausbremsen. (OK, das ist die Masser der sichtbaren (!) "Angreifer".) Aber die richten auch keinen Schaden an. Ein geloggter "Angriff" ist ein abgewehrter Angriff.
Angriffe von Fachleuten werden so gut wie nicht geloggt - und durch die o.g. Methoden auch in keinster Weise verhindert.

Klar kann man die IP fälschen (Proxy zum Beispiel). Wenn man jedoch nur IPs von Deuschland zulässt: so viele öffentliche Proxys in Deutschland gibt's auch nicht. Ist für den Angreifer wieder eine Hürde mehr.

Was die zusätzliche Hürde betrifft - meine volle Zustimmung.

Autoblock und ein langes Passwort was nicht im Wörterbuch steht ist meiner Meinung nach der beste Schutz.

Autoblock (oder fail2ban und ähnliche Programme) ist kein Schutz vor Angriffen. Angriffe werden damit wirkungsvoll verlangsamt. Ja, auch so langsam gemacht, dass die meisten "Angreifer" aufgeben. Aber professionelle Angreifer haben Zeit! Und wenn jede Stunde vollautomatisch ein Versuch gestartet wird.
Ein gutes Passwort (Länge, Zeichenumfang, Zufälligkeit und auch dessen regelmäßiger Wechsel) ist immer gut. In meinen Augen der zweitbeste Schutz.

Aber der einzige wirkungsvolle Schutz, gerade bei ssh, ist die Anwendung kryptografischer Verfahren zur Authentisierung!
Wo liegt das Problem, auf einem bzw. allen zugriffsberechtigten Rechner/n je ein Schlüsselpaar mit 4K-Schlüsseln zu erzeugen (Linux: ssh-keygen -b 4096, für die WinDOSe ins Putty-Format konvertieren) und den public key dann beim anmeldeberechtigten Nutzer (root) in die ~/.ssh/authorized_keys des Servers zu kopieren. Noch in der sshd_config (nach dem erfolgreichen Test der neuen Anmeldung!) die Anmeldung mit Benutzername+Passwort verbieten und fertig ist.

Ich kann nicht verstehen, wieso diese Art der Anmeldung hier im Forum nicht favorisiert wird.
Wer einen sshd ohne PubkeyAuthentication frei ins Netzt stellt, der handelt IMHO einfach nur fahrlässig.


So, ich bin jetzt bereit, zerissen zu werden ;-)


MfG Peter

 

[Frogman]

Nö, kein Grund für den Zerriss
Ich sehe das ebenso wie Du - einzig und allein die Konfiguration der Authentifikation mit Schlüsselpaarerzeugung usw. überfordert die meisten User hier. Leider sind das aber genau eben die, die so etwas (aus Unwissenheit?) online stellen, und auch gerne das DSM extern verfügbar machen. Warum? Nun ja, weil man's kann und vielleicht in 2 jahren mal braucht (oder glaubt, es dann zu brauchen).

Bedauerlicherweise ist in diesen Punkten aber auch die Dokumentation seitens Synology mehr als unterirdisch. Im Gegenteil, hier werden ja - frei nach dem Motto "Synology for dummies" - massiv solche Dinge wie QuickConnnect beworben.
Ich habe hier schon mehrfach interveniert, auch in Zusammenhang mit einer intuitiveren Gestaltung der GUI, um Dinge wie VPN, SSL-Ciphren usw. auch dem Nichtexperten leicht zugänglich zu machen. Bisher leider ohne viel Ergebnis, doch die Kommunikation mit den Jungs läuft noch

 

[Peter_Lehmann]

DANKE!

Wenn ich jetzt genau wüsste, wie man auf der WinDOSe ein Schlüsselpaar erzeugt, würde ich gern ein entsprechendes Tutorial schreiben, wie man dann die pub keys auf die DS bringt. Aber "leider" habeichseitjahrenkeinwindowsmehr ;-)
BTW: Ich habe die letzten Tage gelesen, dass M$ in der Powershell nun endlich auch einen ssh-Client (und wenn ich mich recht erinnere) sogar einen sshd implementieren will.

OpenSSL gibt es ja auch unter Windows => ich gehe mal davon aus (kann es aber eben nicht prüfen!), dass dort die Befehle die gleichen sein dürften, wie unter Linux. Damit dürfte das Generieren der Keys wirklich kein Problem sein.
Dann per telnet (ja, wirklich telnet!) auf der Konsole der DS anmelden, dürfte nach Anleitung auch ein daran interessierter Windows-Nutzer hinbekommen. Und der Rest ist ja auch ganz einfach.

Schaun wir mal ....
Vielleicht mache ich doch wieder mal eine VM mit Win 7 unter Linux auf.


MfG Peter

 

[goetz]

Hallo,

Wenn ich jetzt genau wüsste, wie man auf der WinDOSe ein Schlüsselpaar erzeugt

steht doch im Wiki . puttygen (Putty Key Generator).

Gruß Götz

 

[Puppetmaster]

Wer einen sshd ohne PubkeyAuthentication frei ins Netzt stellt, der handelt IMHO einfach nur fahrlässig.

Ja, aber Fahrlässigkeit ist an der Tagesordnung und in weiten Bereichen auch ok. Wenn hinter dem Dienst nur ein paar Musik- oder Videofiles warten, dann trage ich gerne das Risiko, dass es noch jemanden auf der Welt gibt, mit dem ich das (unwissentlich) teile.

Man muss nicht immer mit Kanonen auf Spatzen schießen, bzw. muss man eben einfach kalkulieren, was einem die Staatsgeheimnisse, die man so auf der DS hat, an Schutz wert sind.

Im Grunde gebe ich dir sicher vollumfänglich Recht, allerdings muss man eben abwägen (können). Es gibt eben nicht nur schwarz und weiß.

 

[goetz]

Hallo,

Man muss nicht immer mit Kanonen auf Spatzen schießen, bzw. muss man eben einfach kalkulieren, was einem die Staatsgeheimnisse, die man so auf der DS hat, an Schutz wert sind.

es geht ja nicht nur darum ob jemand Deine Dateien lesen kann. Denke zB an Syno-Locker oder Du wirst plötzlich Anbieter von urheberrechtlich geschütztem Material. Deine Frau findet es bestimmt nicht lustig wenn zwischen den Urlaubsbildern plötzlich XXX Bilder auftauchen usw usf.

Gruß Götz

 

[Puppetmaster]

Ja, goetz, prinzipiell gebe ich dir Recht. Aber wie oft kommt denn sowas vor?

Das ist es eben, was ich mit dem Abwägen meine.
Und soll ich jetzt ersthaft meine PhotoStation nur noch über VPN o.ä. zugänglich machen? Also, nee, dann doch ieber gleich einstampfen, denn wenn sie nicht leicht zugänglich ist, dann hat sie auch keinen praktischen Nutzen.

 

[Peter_Lehmann]

Jetzt wollen wir uns doch alle mal wieder beruhigen ... .

Es ging darum, dass versierte Nutzer (!), die gewillt und in der Lage sind per ssh auf der Konsole bestimmte Konfigurations- oder mit scp oder gar mit sftp und einem Programm wie Filezilla bestimmte sichere Kopieraktionen usw. durchzuführen, dies gleich richtig tun sollten.
Otto NormalUser hat nie etwas von ssh gehört und interessiert sich auch gar nicht dafür.

Und ich bin eben der Meinung, dass denen, die wirklich das wunderbare Werkzeug ssh nutzen wollen, auch gleich zu Beginn gesagt werden soll, wie sie dies richtig machen. Die meisten wissen es einfach nicht!

Unter Linux erzeugen wir mit wenigen Tastenanschlägen und innerhalb weniger Sekunden "Rechenzeit" ein Schlüsselpaar mit 4K-Schlüsseln.
Per scp (oder sogar einem bei openSSL mitgeliefertem Script) wird der public key dann auf dem Server in die authorized_keys kopiert und dann per telnet oder ssh noch die Konfigurationsdatei editiert (1 Eintrag geändert!) und fertig ist die Laube.

Das ganze dauert beim ersten mal (und etwas vorherigem Lesen) ~10 und bei mir vlt. 3 Minuten.

Und dann frage ich mich, wo stehen hier (noch mal: für den Nutzer, der gewillt ist, ssh zu nutzen!) die Kanonen und die Spatzen? Wegen lumpiger 10-15 Minuten sollte man den Sicherheitsgewinn nicht saussen lassen.
Wie hoch der Aufwand für einen Windows-Nutzer ist, weiß ich nicht. Ich habe auch im Moment keine Lust (mehr) dies auszuprobieren.


Schönen Abend noch!

Peter

 

[hopeless]

Ein gutes Passwort (Länge, Zeichenumfang, Zufälligkeit und auch dessen regelmäßiger Wechsel) ist immer gut. In meinen Augen der zweitbeste Schutz.

Wobei gerade das was du extra Fett markiert hast, nicht unbedingt einhellige Meinung ist!
Wenn ein Passwort ausreichend Sicher ist, wird es durch Zeitablauf nicht automatisch unsicher.
Sollte es nicht sicher genug sein, kann es schon sofort, oder kurz vor dem Ablaufdatum (z.B. 30Tage), kompromittiert sein. Warum es nach im Bsp. 31 Tagen unsicher ist und dann gewechselt werden muss, Kai Neahnung.
Bin zwar kein M$ freund aber da halte ich das außnahmsweise eher mit Cormac Herley:
Statt also ständig die Passwörter zu wechseln, lieber ein einziges, dafür aber absolut sicheres Login wählen. Dies sollte mindestens acht Zeichen lang sein und außerdem aus einem Zeichenmix – Groß- und Kleinbuchstaben, Sonderzeichen, Ziffern – bestehen.

 

[whitbread]

Die Frage ist doch: Wer muss ausser mir selbst noch auf meine NAS zugreifen? Gibt es andere, die regelmässig bspw. Photostation oder andere Dienste nutzen dann muss ich diese zu einem sicheren pw zwingen und deren Rechte auf das eben Nötige einschränken.
Wenn ich nur selber auf meine NAS will bzw. muss geht doch nichts über VPN. Und ob ich dann lieber zertifikatsbasiert mit SSH und Tunneling unterwegs bin oder eben nicht (ggf. durch die genutzten Clients bedingt) halte ich nicht für wesentlich. Entscheidend ist doch, dass nur ich zugreifen kann und eine verschlüsselte Verbindung genutzt wird.

 

[Frogman]

...
Wenn ein Passwort ausreichend Sicher ist, wird es durch Zeitablauf nicht automatisch unsicher.
.

Damit hast Du grundsätzlich auch Recht. Hier zählt dann eher der Umstand, dass bei einem über lange Zeit genutzten Passworts immer auch mal die Gefahr höher wird, dass jemand bspw. bei der Eingabe unbemerkt über die Schulter geschaut hat (das passiert schneller, als man so gemeinhin glaubt, ob nun in einem öffentlichen Umfeld oder auch zu Hause). Ein Wechsel des Passworts ist dann also jedes Mal ein Neustart.
Andererseits ist der Zwang, sich immer wieder ein sicheres (und damit auch durchaus auch nicht so kurzes) passwort ausdenken zu müssen, nicht gerade besonders hilfreich, den Überblick zu behalten. Hier helfen dann Methoden wie bspw. mit einem Passwortrumpf, kombiniert mit einer Kennung für den jeweiligen Dienst und einem anderen veränderlichen, doch beherrschbaren Anteils am Passwort.

 

[yosemite]

Eine Frage am Rande: gibt es für iOS-Geräte auch die Möglichkeit das Verfahren mit dem PubKeyAuth?