SynoLocker TM - Daten auf NAS gecrypted worden durch Hacker

[Waldschrat]

Hab bei mir als zusätzliche Sicherheit folgendes Script laufen:

while true
do
ps -w | grep 'synosync' | head -n 1 | cut -d ' ' -f 1 | xargs kill -kill 2>/dev/null
#       ^ Prozessname     ^ erste Zeile  ^ erster Eintrag  ^ beende Prozess und schreibe allfällige Fehlermeldungen in den Trash
sleep 1   # warte eine Sekunde​
done

Muss root Rechte haben, lässt sich um alle Prozesse erweitern die noch bekannt werden.
Freu mich über Verbesserungen

 

[dil88]

Du solltest auf jeden Fall kill -9 verwenden.

 

[Puppetmaster]

Wenn ihr Euch damit nicht beschäftigen wollt, dann hängt nix ins Netz oder holt euch einen Fachmann.

Fein, dann nenne mir einmal den Experten, der die Sicherheitslücken von morgen schon heute kennt...

openSSL wurde sicher auch von Amateuren programmiert, nehme ich an. Wie hätte es sonst zu heartbleed kommen sollen?!

Ehrlich, sowas bringt absolut gar nichts. Genausowenig, wie sich ständig über die aufzuregen, die vor dir auf der Strasse nicht Autofahren können.
Jeder, auch der DAU, muss das machen können. Aber auch der DAU muss über die Risiken aufgeklärt werden, die nunmal heute so existieren. Dann kann jeder selbst entscheiden, wo er den Cut macht.

 

[Waldschrat]

Du solltest auf jeden Fall kill -9 verwenden.

kill -9 bringt den Fehler

kill: you need to specify whom to kill

[edit] Ich habe den kill Befehl um das Signal -kill ergänzt:

ps -w | grep 'synosync' | head -n 1 | cut -d ' ' -f 1 | xargs kill -kill 2>/dev/nul

 

[Fusion]

kill -9 bringt den Fehler

kill: you need to specify whom to kill

Vielleicht geht da schon vorher was schief. Bei "head -n 1" bleibt bei mir z.B. nur der grep Prozeß übrig, der eigentich zu killende ist dadurch ausgeblendet.

 

[Erebus]

Ehrlich, sowas bringt absolut gar nichts. Genausowenig, wie sich ständig über die aufzuregen, die vor dir auf der Strasse nicht Autofahren können.

WAHHHHH
Du musst auf der gleichen Strasse wie ich heute gewesen sein

 

[Waldschrat]

Vielleicht geht da schon vorher was schief. Bei "head -n 1" bleibt bei mir z.B. nur der grep Prozeß übrig, der eigentich zu killende ist dadurch ausgeblendet.

logisch, solang´s noch keinen 'synosync' Prozesss gibt, werden alle dadurch entstehenden Fehlermeldungen verworfen

 

[rubinho]

Fein, dann nenne mir einmal den Experten, der die Sicherheitslücken von morgen schon heute kennt...

Es geht doch nicht darum die Glaskugel lesen zu können.

Ehrlich, sowas bringt absolut gar nichts. Genausowenig, wie sich ständig über die aufzuregen, die vor dir auf der Strasse nicht Autofahren können.

Der Vergleich hinkt. Der Autofahrer macht schließlich einen Führerschein und muss sich dadurch zwangsläufig mit der Materie auseinandersetzen.

Jeder, auch der DAU, muss das machen können. Aber auch der DAU muss über die Risiken aufgeklärt werden, die nunmal heute so existieren. Dann kann jeder selbst entscheiden, wo er den Cut macht.

Stimmt, das ist aber eine Holschuld des DAUs und keine Bringschuld von irgend Jemanden. Da muss sich der DAU wohl selbst Informieren, die nötigen Infos kommen schließlich nicht von alleine ins Haus geflattert.

Aber was ich in letzter Zeit sehe ist alles andere.
So gut wie keiner macht sich Gedanken über die Sicherheit, auf der Arbeit werde ich teilweise als Paranoid verschriehen (in einer IT Firma) Aber wenns die Leute mal selbst erwischt hat, ist das gejammere groß und es wird einen Schuldigen gesucht, nur nicht bei sich selbst.
Es ist nicht alles Apple like und das ist auch gut so, ein wenig Hirn einschalten hat noch nie jemanden geschadet.

Die Leute die hier in diesem Thread posten oder lesen informieren sich wenigstens, also muss sich hier keiner angegriffen fühlen.

 

[Fusion]

Hab das natürlich mit einem anderen Prozeß getestet, der auch läuft.

 

[Erwe]

Werde mein NAS verkaufen. Denn es ist mein erstes und ich habe nicht Informatik studiert. Und da ich hier jetzt mehrmals gelesen habe, daß man sowas nur in Betrieb nehmen soll (darf) wenn man sich auskennt und ich noch sehr wenig Ahnung habe und es mir nicht leisten will, einen Fachmann zu bezahlen da ich keine Firma bin sondern nur ein einfacher Privatanwender, ist das wohl nichts für mich.

 

[Frogman]

Was ich meine ist das doch nicht von jedem verlangt werden kann ein Backup eines Backups an zu fertigen, ...

Doch - wenn es Dir die Daten wert sind. Allerdings verlangt das niemand, das tust Du nur für Dich (oder demjenigen, dem die Daten gehören)!

Klar geht alles automatisch, aber einen Kontrollblick mache ich eigentlich Täglich.

Ja, wie - und der bewahrt Dich vor einem Plattencrash? Oder einem HAcker, der des Nachts, wenn Du selig am Daumen nuckelst, vom anderen Ende der Welt auf Deiner DS herumfuhrwerkt?

Ich mache mir um meine DS keine Sorgen 1. sie ist nicht im Internet 2. Habe ich Backups von 90% der Daten.

Du hast schon Murphy kennengelernt? Falls nicht, zieh Dich warm an - der sucht sich nämlich dann genau die 10% aus, von denen Du kein Backup hast!

 

[Oceanwaves]

Ich habe auch einen Port 22 auf meiner Sicherungs-DS offen. Warum? Weil ich keine Zeit und Lust habe mich mit Linux näher auseindaerzusetzen, um den Port über das Terminal zu ändern. Denn über DSM ist das nicht realisierbar. Zudem nutze ich die Datensicherung der Synology, die Port 22 für verschlüsselten Transfer benötigt.
Aber es gibt eine simple Lösung mit der ich schon seit mehreren Monaten keine durch SSH gesperrten IPs habe. Ich habe nämlich nur meine IP Range, die ich von meinem ISP erhalte, erlaubt.[...]

5000 habe ich nicht offen, aber dafür 5001. Bisher hat noch keiner diesen Port bei mir ausprobiert. Kann ja noch kommen. Aber könnte Google z.B. auch meine IP mit Port 5001 anzeigen? Wenn ja, wie verhinder ich das?

Man benötigt keine Linux-Kenntnisse, um ssh über einen anderen Port verfügbar zu machen. Das erledigt man am einfachsten direkt am Router, indem man dort z.B. Port 54321 freigibt und den dann auf die IP der Syno und Port 22 weiterleitet. Das habe ich bei meinem PC vor Jahren gemacht (nicht auf Port 54321 ;-) und seitdem 0 (null) Login-Versuche! Zuvor mal spaßeshalber 3 Tage Port 22 am Router offen gehabt, aber eigentlich nur um Fail2Ban zu testen (automatisches Blocken einer IP bei n fehlgeschlagenen Logins in m Minuten). Fail2Ban funktioniert, langweilt sich aber seit über 4 Jahren.

Sicherst Du deine Syno über Internet? Oder innerhalb des LANs? Wenn letzteres, dann muss am Router auch kein Port für ssh offen sein.

Nach dem gleichen Verfahren kann man auch den Port 5000 bzw. 5001 sichern. Einfach eine hohe Portnummer nehmen und im Router auf 5000 bzw. 5001 weiterleiten. Das gibt zwar keine absolute Sicherheit, aber hat bei mir z.B. die Login-Versuche per ssh von 5 pro Stunde auf 0 pro 5 Jahre reduziert.

 

[rubinho]

Werde mein NAS verkaufen. Denn es ist mein erstes und ich habe nicht Informatik studiert. Und da ich hier jetzt mehrmals gelesen habe, daß man sowas nur in Betrieb nehmen soll (darf) wenn man sich auskennt und ich noch sehr wenig Ahnung habe und es mir nicht leisten will, einen Fachmann zu bezahlen da ich keine Firma bin sondern nur ein einfacher Privatanwender, ist das wohl nichts für mich.

Du brauchst kein Informatiker zu sein um ein NAS zu bedienen. Du darfst es auch einschalten und in Betrieb nehmen. Nur solltest du, bevor du das NAS vom Internet aus erreichbar machst, wissen was du da machst.

 

[Waldschrat]

Hab das natürlich mit einem anderen Prozeß getestet, der auch läuft.

AFAIK werden nur Prozesse berücksichtigt, die nach dem Start des Scriptes gestartet wurden. Hab das bei mir erfolgreich getestet

 

[Oceanwaves]

Hab bei mir als zusätzliche Sicherheit folgendes Script laufen:

while true
do
ps -w | grep 'synosync' | head -n 1 | cut -d ' ' -f 1 | xargs kill -kill 2>/dev/null
#       ^ Prozessname     ^ erste Zeile  ^ erster Eintrag  ^ beende Prozess und schreibe allfällige Fehlermeldungen in den Trash
sleep 1   # warte eine Sekunde​
done

Muss root Rechte haben, lässt sich um alle Prozesse erweitern die noch bekannt werden.
Freu mich über Verbesserungen

Damit grep sich nicht selbst findet, basteln wir uns eine ganz kleine Range:

ps -w | grep ynosync ... 

Und dann hast du natürlich noch ein Problem, weil das kill jede Sekunde aufgerufen wird, auch wenn "synosync" nicht gefunden wird. Und kill ohne Angabe einer PID meckert halt . Da wirst du um eine Abfrage, ob überhaupt ein entsprechender Prozess vorhanden ist oder nicht, nicht herum kommen.

 

[gizmo21]

Hab bei mir als zusätzliche Sicherheit folgendes Script laufen:

while true
do
ps -w | grep 'synosync' | head -n 1 | cut -d ' ' -f 1 | xargs kill -kill 2>/dev/null
#       ^ Prozessname     ^ erste Zeile  ^ erster Eintrag  ^ beende Prozess und schreibe allfällige Fehlermeldungen in den Trash
sleep 1   # warte eine Sekunde​
done

Muss root Rechte haben, lässt sich um alle Prozesse erweitern die noch bekannt werden.
Freu mich über Verbesserungen

gr8! wäre natürlich noch schön wenn das "anschlagen" im log/mail... gemeldet wird.

Und man könnte es natürlich noch um die älteren Bitcoinminer Prozesse erweitern ,aber das ist relativ aufwenig weil viele verschiedene Namen:

https://www.synology.com/en-us/company/news/article/437
http://www.df.eu/blog/2014/02/12/angriff-auf-synology-nas/

 

[süno42]

Dass die Informationspolitik in diesem Fall mangelhaft ist, müssen wir nicht diskutieren, aber... wären alle Synology Geräte betroffen, hätte Synology wahrscheinlich bereits reagiert (so wie sie es bei dem Heartbleed Bug getan haben). Auch wenn ich nun meine Kiste gestern abgetrennt habe, vermute ich mal, dass es vornehmlich ältere DSM Versionen betrifft. Riskieren möchte ich trotzdem nichts.

Das würde ich so nicht unterschreiben. In der Vergangenheit hat sich Synology in ähnlichen Situationen alles andere als mit Ruhm bekleckert.

 

[Erwe]

Es ist halt so, daß fast jeder irgendwann bei Null angefangen hat. Und ich glaube nicht, daß die, die diese "hilfreichen" Tipps gegeben haben erst alles über Netzwerk, Sicherheit, Routereinstellungen theoretisch gelernt haben bevor sie ihr erstes Gerät ans Internet angeschlossen haben. Und nur weil ich erwähnt habe, daß eine kurzes Tutorial für die wichtigsten Funktionen super wäre, damit man den einen oder anderen Fehler nicht macht, wird einem sofort empfohlen die Finger davon zu lassen.

 

[dil88]

kill -9 bringt den Fehler

kill: you need to specify whom to kill

[edit] Ich habe den kill Befehl um das Signal -kill ergänzt:

ps -w | grep 'synosync' | head -n 1 | cut -d ' ' -f 1 | xargs kill -kill 2>/dev/nul

Einfacher wäre btw., auf den grep etc. zu verzichten und gleich

killall KILL synosync 2> /dev/nul

zu verwenden.

 

[süno42]

Single Point of error wäre hier ein Stichwort. Ein Nachteil beim VPN: wenn der geknackt ist kann man so ziemlich alles erreichen als wäre man im LAN. Wer hat schon Firewall Regeln um sich gegen sein VPN zu schützen?

Ist nicht wirklich ein Nachteil dem man einem VPN anlasten kann. Genauso kannst Du im LAN vergleichbares machen, wenn Du…

• irgendwo anders eine Lücke im TCP/IP-Stack ausnutzen kannst
• eine Lücke in einem privilegierten Dienst ausnutzen kannst
• eine Lücke in einem nicht priviligierten Dienst ausnutzen kannst zzgl. einer Lücke, welche Dir höhere Rechte (z.B. root) verleiht

Genauso kann auch zusätzliche Sicherheitssoftware, welche Dich eigentlich schützen soll, erst Lücken ins System reißen, z.B.

• Virenscanner (gerade erst wieder in der Diskussion)
• Firewalls, IDS, IPF, ALG etc.

Die Liste ließe sich endlos weiterführen, verabschiedet euch mal von offenen Ports.

Zudem wenn man öffentlich erreichbare Dienste hat bringt ein VPN nichts, da kann man gleich das Netzwerkkabel ziehen. Oder wie bringst du einen externen Mailserver dazu via VPN auf Port 25 deines Mailservers auf der DS zuzugreifen?

Stimmt. Da verfallen leider zu viele Leute dem Marketing von Synology. Einen einzelnen Mailserver direkt ins Internet zu hängen, gehört sich einfach nicht. Professionell wird dies über eine Serverkaskade gelöst (ist für einen Privatmenschen jedoch zu groß).


Viele Grüße
Süno42