HiDrive offline?

Carl_S · 19. Aug 2023

Seit 3.8.23 geht ein Hidrive (Hyper) Backup nicht mehr, das vorher jahrelang fehlerfrei täglich lief.
Ich komme auch garnicht mehr auf das HiDrive drauf aus Hyperbackup. Es wäre offline, nicht erreichbar. Wobei es manchmal Online angezeigt wird, aber dann gleich wieder offline ist.
Backups auf Vaults anderer NAS (HyperBackupVault) laufen.

Und ja, über den Anruf beim Support kam raus, dass das Protokollpaket abgeklemmt werden soll (ohne Benachrichtigung!?!), die haben mir verkündet mein HiDrive Special kostet 50c mehr, und nur die können intern sehen, dass gleichzeitig autom. angestoßen wurde, dass das 'Special'==Protokolle wegfliegt. Frechheit! Das dürfen die nun brav noch nen Jahr machen, immerhin haben die mir den Vertrag verlängert als Special in der Mail. Aber das theoretisch erst am 28.8.23, bis dahin ist es aktiv (und danach auch, da kümmer ich ich drum).

Aber zurück zum Problem:
Wireshark Trace in der Firewall angeschmissen und da sieht man das Problem:
Manchmal klappt der SSH Verbindungsaufbau, aber meistens schickt die Synology im TCP Verbindungsaufbau gleich ein [FIN, ACK] hinterher anstatt die Protokollversion zu schicken.
Also die Synology macht die TCP Verbindung ohne ein Byte gesendet zu haben nach 20µs wieder zu sobald der Server antwortet.
Manchmal schickt sie aber die Protokollversion und der SSH Verbindungsaufbau klappt.
Das geht sogar soweit, dass eine SSH Verbindung steht und weitere scheitern...

Internet sagt: Sowas macht ein Client nur, wenn er keine File Handles mehr für die Verbindung hat, denn das braucht er in dem Moment, in dem der Verbindungsaufbau geklappt hat.
Aber sysctl sagt, da sind nur 7000 von 70000 belegt.

Any ideas?

Anzeige · 19. Aug 2023

Hallo Carl_S,

Bücher und Hardware zum Thema gibt es bei Amazon: HiDrive offline?

Carl_S · 19. Aug 2023

Anbei ein Trace, 217xxx ist die Synology.
Zuerst klappt es nicht, 15s später klappt der Verbindungsaufbau.

Adama · 19. Aug 2023

Also ich kann nur sagen, dass ich seit mehreren Jahren meine Daten ins Strato HiDrive sichere. Derartige Probleme hatte ich bisher nicht.

Carl_S · 19. Aug 2023

Ich bis 3.8.2023 auch nicht. Das lief schon >2 Jahre jede Nacht.
Dazwischen musste ich mal die Synology wechseln, da es das MB erwischt hatte, aber auf einer baugleichen ging es dann weiter...
An dem Tag waren keine Updates und nichts...

Adama · 19. Aug 2023

Deine Internet-Verbindung ist um die Zeit stabil?

Carl_S · 19. Aug 2023

500 MBit Glasfaser, letzter IP Wechsel vor Wochen?
Firewall ist ne PFsense mit 8-Kern Prozessor... Internet steht.
Ach ja, und jede Nacht läuft auch mit der gleichen Synology und dem gleichen Hyperbackup nen Backup von 20-100 GB über VPN, über die gleiche Glasfaser. Fehlerfrei...

Und sonst würden die ja nicht so miteinander reden können...

Paket 1: Synology will eine TCP Verbindung aufmachen
Paket 2: SSH Server antwortet, acknowledge des TCP SYN Verbindungsaufbaus
Paket 3: Synology acknowledge des Verbindungsaufbaus
Paket 4: 200µs später: Synology hat doch keinen Bock und sendet ein FIN, Verbindung bitte beenden...
Was hat die Leitung damit zu tun?

Das gleiche 15s später:
Die ersten 3 Pakete identisch (auch das Timing).
Paket 4: 500µs später: Die Synology sendet ihre SSH Protokollversion... (statt Verbindung beenden...)
-> Verbindung wird aufgebaut...

Carl_S · 19. Aug 2023

Hier das Synology Log dazu, ich denk mal die wichtige Zeile ist:
network/network.cpp:182 [85.214.3.70:22] select() timeout, Operation now in progress
Irgendwo da muss der Wurm in deren Code sein...

2023-08-07T04:30:24+02:00 GmbH_Intern img_backup[25353]: (25353) [info] snapshot.cpp:359 take share [docker] backup snapshot [/volume1/@sharesnap/docker/GMT+02-2023.08.07-04.30.23]
2023-08-07T04:30:39+02:00 GmbH_Intern img_worker[25821]: network/network.cpp:182 [85.214.3.70:22] select() timeout, Operation now in progress
2023-08-07T04:32:46+02:00 GmbH_Intern img_worker[25821]: rsync_wrapper.cpp:806 Fail to create ssh session ret[255] user[incognito] ip[85.214.3.70]
2023-08-07T04:32:46+02:00 GmbH_Intern img_worker[25821]: rsync_wrapper.cpp:1056 Failed to execute rsync command. cmd=[/usr/bin/ssh -d /tmp/RSYNC_PWD_DTZrLa -oNumberOfPasswordPrompts=1 -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oServerAliveInterval=30 -oServerAliveCountMax=3 -nNf -oControlPersi st=60 -oControlMaster=yes -oControlPath=/tmp/rsync-5139779296703010781-%u-%r@%h:%p incognito@85.214.3.70], ret=255
2023-08-07T04:35:00+02:00 GmbH_Intern img_worker[25821]: rsync_wrapper.cpp:806 Fail to create ssh session ret[255] user[incognito] ip[85.214.3.70]
2023-08-07T04:35:00+02:00 GmbH_Intern img_worker[25821]: rsync_wrapper.cpp:1056 Failed to execute rsync command. cmd=[/usr/bin/ssh -d /tmp/RSYNC_PWD_YYu1By -oNumberOfPasswordPrompts=1 -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oServerAliveInterval=30 -oServerAliveCountMax=3 -nNf -oControlPersi st=60 -oControlMaster=yes -oControlPath=/tmp/rsync-5139779296703010781-%u-%r@%h:%p incognito@85.214.3.70], ret=255
2023-08-07T04:37:14+02:00 GmbH_Intern img_worker[25821]: rsync_wrapper.cpp:806 Fail to create ssh session ret[255] user[incognito] ip[85.214.3.70]
2023-08-07T04:37:14+02:00 GmbH_Intern img_worker[25821]: rsync_wrapper.cpp:1056 Failed to execute rsync command. cmd=[/usr/bin/ssh -d /tmp/RSYNC_PWD_dpuPzS -oNumberOfPasswordPrompts=1 -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oServerAliveInterval=30 -oServerAliveCountMax=3 -nNf -oControlPersi st=60 -oControlMaster=yes -oControlPath=/tmp/rsync-5139779296703010781-%u-%r@%h:%p incognito@85.214.3.70], ret=255

Username hab ich geändert, sowas gibt man nicht raus...

Carl_S · 19. Aug 2023

Mal in der Console SSH aufgerufen, gleiches Spiel:

Carl_Admin@GmbH_Intern:/var/log$ ssh -v incognito@85.214.3.70
OpenSSH_8.2p1, OpenSSL 1.1.1o 3 May 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 85.214.3.70 [85.214.3.70] port 22.
debug1: Connection established.
Could not create directory '/var/services/homes/Carl_Admin/.ssh'.
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_rsa type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_rsa-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_dsa type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_dsa-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ecdsa type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ecdsa-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ecdsa_sk type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ed25519 type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ed25519-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ed25519_sk type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_xmss type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH-7.5p1
debug1: match: OpenSSH-7.5p1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 85.214.3.70:22 as 'incognito'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:nMzqtMicxgSJMPkDASkKzWebzGNnT200ipaAxwER03k
The authenticity of host '85.214.3.70 (85.214.3.70)' can't be established.
ECDSA key fingerprint is SHA256:nMzqtMicxgSJMPkDASkKzWebzGNnT200ipaAxwER03k.
Are you sure you want to continue connecting (yes/no/[fingerprint])? no
Host key verification failed.
Carl_Admin@GmbH_Intern:/var/log$ ssh -v incognito@85.214.3.70
OpenSSH_8.2p1, OpenSSL 1.1.1o 3 May 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 85.214.3.70 [85.214.3.70] port 22.
^C
Carl_Admin@GmbH_Intern:/var/log$ ssh -v incognito@85.214.3.70
OpenSSH_8.2p1, OpenSSL 1.1.1o 3 May 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 85.214.3.70 [85.214.3.70] port 22.
^C
Carl_Admin@GmbH_Intern:/var/log$ ssh -v incognito@85.214.3.70
OpenSSH_8.2p1, OpenSSL 1.1.1o 3 May 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 85.214.3.70 [85.214.3.70] port 22.
^C
Carl_Admin@GmbH_Intern:/var/log$ ssh -v incognito@85.214.3.70
OpenSSH_8.2p1, OpenSSL 1.1.1o 3 May 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 85.214.3.70 [85.214.3.70] port 22.
^C
Carl_Admin@GmbH_Intern:/var/log$ ssh -v incognito@85.214.3.70
OpenSSH_8.2p1, OpenSSL 1.1.1o 3 May 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 85.214.3.70 [85.214.3.70] port 22.
^C
Carl_Admin@GmbH_Intern:/var/log$ ssh -v incognito@85.214.3.70
OpenSSH_8.2p1, OpenSSL 1.1.1o 3 May 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 85.214.3.70 [85.214.3.70] port 22.
^C
Carl_Admin@GmbH_Intern:/var/log$ ssh -v incognito@85.214.3.70
OpenSSH_8.2p1, OpenSSL 1.1.1o 3 May 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 85.214.3.70 [85.214.3.70] port 22.
debug1: Connection established.
Could not create directory '/var/services/homes/Carl_Admin/.ssh'.
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_rsa type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_rsa-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_dsa type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_dsa-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ecdsa type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ecdsa-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ecdsa_sk type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ed25519 type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ed25519-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ed25519_sk type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_xmss type -1
debug1: identity file /var/services/homes/Carl_Admin/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH-7.5p1
debug1: match: OpenSSH-7.5p1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 85.214.3.70:22 as 'incognito'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:nMzqtMicxgSJMPkDASkKzWebzGNnT200ipaAxwER03k
The authenticity of host '85.214.3.70 (85.214.3.70)' can't be established.
ECDSA key fingerprint is SHA256:nMzqtMicxgSJMPkDASkKzWebzGNnT200ipaAxwER03k.
Are you sure you want to continue connecting (yes/no/[fingerprint])? no
Host key verification failed.

Adama · 20. Aug 2023

Irgendwie sehen meine Logs anders aus.

Gehst du über die HiDrive-Option in HyperBackup oder gehst du über rsync-Server?

Nebenbei, wenn du bereits DSM 7.2 nutzt, gibt es eine neue HB-Version:
https://www.synology-forum.de/threads/hyperbackup-vault-4-1-0-3716.128272/

Vielleicht ändert das ja was. Ansonsten bleibt dir vermutlich nur ein Ticket bei Synology aufzumachen

Carl_S · 22. Aug 2023

Ich hab leider in die Log geschaut, das hätte ich vielleicht nicht machen sollen.
Spätestens als da stand 'unable to execute payload' wurde ich stutzig und habe mich mal über synowedjat schlau gemacht, was wohl mit DSM7 kam.

Danach hätte ich am liebsten in jedes Drivebay einzeln gekotzt und beschlossen, dass Synology ab DSM 7 weder für mich privat noch für meine GmbH tragbar ist, wenn jede Nacht aus China nen skript geladen wird und als root ausgeführt, dann beliebige Daten nach China gehen und dann der chinesische Server gefragt wird, ob man den Besitzer 'punish'en soll.

Zum Glück hat das nicht geklappt, Firewall sei dank. Daher standen die Fehler in dem Log, die Synology kommt nicht raus (Strato ausgenommen).
Aber ohne gehen vermutlich auch keine Updates.

Sämtliche Kisten von denen landen auf Kleinanzeigen, sobald ich die Daten auf alternative Server migriert habe. Bis dahin ist die FW komplett ZU.

Auf Wiedersehen Synology...

Für mehr als die Spielfilmsammlung ist das nicht mehr zu gebrauchen. Und das bitte im separaten Netz nur mit der Glotze.

Ach ja, ich lenk die HTTPS Zugriffe kommende Nacht mal auf nen HAproxy (HTTPS self-signed) um. Mal sehen ob die Synology Serverzertifikate prüft oder das auch schon egal ist wo das root-skript her kommt...

Zur Info (aus dem XPEnology Community Forum):

Synowedjat is a backdoor from Synology. When checking package updates, it is downloaded from the server and executed, no matter whether you are using a genuine Synology device or not. It is highly recommended to remove it.
Specifically:
1. When the background service checks for updates, "synopkg chkupgradepkg" is invoked
2. "synopkg chkupgradepkg" starts synowedjat-exec
3. synowedjat-exec
- Uploads hardware info to account.synology.com/wedjat
- Downloads and extracts synowedjat.sa, a synology archive which contains the backdoor
- Runs the main binary "synowedjat protection"
4. synowedjat has several modes
- Debugging modes (controlled by argv[1])
- "collect" and "collect-enc" uploads a comprehensive set of host info to synology's server, in plain text, or encrypted
- "punish" resets the login page's background, and sends a piracy notification
- "protection" is the default mode
- Runs /run/ai_tool.cpython-38.pyc to twiddle with the "Active Insight" package settings, periodically
- Uploads a comprehensive set of host info to synology's server
- Enters the "punish" mode according to the servers' response

ctrlaltdelete · 23. Aug 2023

Dabei handelt es sich um Standardtechniken zur Pirateriebekämpfung sowie um die Überprüfung, ob das Gerät für das entsprechende Update qualifiziert ist.
Edit: Welche DSen verkaufst du denn? Wäre interessiert.

metalworker · 23. Aug 2023

Naja wenn du danach gehst musst dein NAS selbst programmieren .
Die Möglichkeit zur Backdoor hast bei allen Anbietern.

Carl_S · 23. Aug 2023

Kurz:
a) Ne Qualifizierung für Updates ist das nicht, das macht man lokal. Hat nix damit zu tun, läuft auch nicht auf dem Update Server/greift nicht drauf zu. Macht nen anderer Prozess.
b) Anti Piracy ist das auch nicht, die Kerle von XPEnology killen den Prozess und sind glücklich. Oder meine FW blockiert den Server, biegt den DNS um etc. Synology könnte für 20c nen HSM Chip auf ihren Pfostenstecker USB Stick knallen und darauf in zig Prozessen abfragen machen, Signatur prüfen. Das würde dann sogar was bringen, wäre lokal und nicht umgehbar, siehe Tintenpatronen. Diese Abfrage zum Server bringt nix.
c) Ungefragt Daten 'nach Hause' zu schicken (Telemetrie) machen viele, aber bekannt und nicht mit nem Skript/Exe, das sie jeden Tag neu vom Server holen sondern im Rahmen eines abgesicherten und bewusst installierten Updates. Ungefragt root executables jede Nacht zu laden ist ne klassische Backdoor.
d) Die Synology hat um Mitternacht und 8 meinen Proxy kontaktiert letzte Nacht, ich hatte alle Zugrife drauf umgebogen. Zumindest der SSL Handshake wurde abgebrochen, also wird wohl irgendwie nen Serverzertifikat geprüft. Wenn ich nun der Synology das selfsigned von dem HAproxy gebe wäre es auch noch mal spannend...
e) Die Möglichkeit zur Backdoor besteht überall da, wo ich SW runter lade, klar. Daher muss ein gewisses Vertrauensverhältnis bestehen, dass der Hersteller eben genau sowas nicht macht. Und dieses Vertrauen ist nun weg, das Zeug in meinen Augen nicht kommerziell oder selbst privat DSGVO gerecht einsetzbar. Denn diese Backdoor ist so konzipiert, dass damit die Kiste beliebig kompromitierbar und fernauslesbar ist, man hat sich nicht ansatzweise die Mühe gemacht hier den Zugriff des Herstellers zu limitieren, was einfach gewesen wäre. Der Hersteller hat vollen ROOT Zugriff auf alle Daten jede Nacht unbemerkt fernauslesbar per SSL verschlüsselt. Orwell lässt grüßen.
f) Wie war das mit chinesischen Dingen in kritischer Infrastruktur? BSI weiß wohl warum...

Fazit für mich, das Ding kompromitiert alles komplett für eine Anti Piracy Maßnahme, die mit 50 Klicks auf dem Keyboard oder gleich per install-skript in Sekunden dauerhaft deaktivierbar ist. Damit ist da für mich Piracy ne schlechte Ausrede für ne Vollzugriff-Backdoor made/controllled in China. Jede Tintenpatrone kann das besser, aber ohne das der Text in China landen könnte.

metalworker · 23. Aug 2023

Also Synology ist nun auch kein Huawei . Aber weiß was du meinst.

Die möglichkeiten hast am ende aber bei jedem Device was zugriffs auf Internet hast. Ob nun Qnap , Synology oder co.

Ich finde du reagierst da etwas über . Aber das ist meine persönliche Meinung.

Aber nun verrate mal welche Geräte du verkaufst ? vielleicht ist was Interessantes dabei

Carl_S · 23. Aug 2023

Ich muss erst mal alles umziehen, dann kann ich mich noch mal melden wenn die Kisten nicht mehr gebraucht werden.

Und ja, Synology ist Taiwan (wobei inzwischen auch mit Büro in Shanghai), aber sowas darf nicht sein.
Angenommen die kompromitiert einer. Da hilft es nicht Updates manuell zu installieren, ne, da sollt sich der Schadcode über Nacht komplett automatisch aus.

Ach ja, account.synology.com ist in der AWS Cloud, noch besser...

Und es ist nicht klar ob überhaupt was geprüft wird, wenn man per Browser drauf geht heißt es SSL_ERROR_NO_CYPHER_OVERLAP. Evtl. nutzen die einfach nur einen komischen Cypher und kein HTTPS, aber auf dem Port damit es überall durch geht...
Werd wohl mal so nen Verbindungsaufbau mitschneiden, das interessiert mich.

mayo007 · 23. Aug 2023

Carl_S schrieb:
wenn die Kisten nicht mehr gebraucht werden.

Naja kannst ja trotzdem schreiben welche Geräte. Hehe

Carl_S · 23. Aug 2023

RS819, DS1819+, DS219+, RS1221RP+ wenn ich mich nicht täusche...
Ne DS219play werd ich behalten um die Backups weiter lesen zu können. Aber ohne Internet in Quarantäne.

synfor · 23. Aug 2023

Es gibt weder eine DS219+, noch eine DS219play.

Carl_S · 23. Aug 2023

218 jeweils

HiDrive offline?

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Kaffeautomat