Hmm... Wenn Du jetzt noch mit sowas kommst, ist Deine QTS Installation vielleicht nicht ganz sauber?
Bei Dir häufen sich die Probleme und Phänomene ja ein wenig...
Eventuell nochmal neu initialisieren? 
Bei meinen Linux-Installationen muß man bei der Einstellung erstmal den Kontinent einstellen, also Europa.
Evtl. ist das bei Dir noch nicht der Fall?
Evtl. hat er nicht die globale Firmware sondern eine für US oder China heruntergeladen?
Vielleicht gibt es die Einstellungen da nicht?
Hmm, gibt es spezielle Versionen der QNAPs, z.b. nur für Asien etc.?
Stammt das NAS von einem normalen deutschen oder europäischen Händler?
Edit: Ist das NAS das gleiche, wie aus dem anderen Thread zum Klackern der HDDs?
Wenn ja scheint das etwas im Argen zu sein.
Hmm, dann fällt mir nur noch ein, zu fragen, ob das NAS über das Internet erreichbar war oder ist?
Wenn ja könntest Du Dir einen "Gast" eingefangen haben, der das NAS jetzt kontrolliert.
Spannend finde ich, dass Qnap 15 Niederlassungen in 28 Ländern haben will.
Für mich klappt das mathematisch nur anders herum.
Hmm, gibt es spezielle Versionen der QNAPs, z.b. nur für Asien etc.?
Nicht dass ich wüsste... es gibt aber Geräte die nur für Asien zB sind, nicht allerdings das TS 230.
Das Verhalten insgesamt ist echt etwas schräg, aber weiter geht es für mich erstmal im anderen Thread mit dem RAM (bzw. den HDD Geräuschen) 
Spannend finde ich, dass Qnap 15 Niederlassungen in 28 Ländern haben will.
Das ist ebenso verrückt wie Dein Gerät
Hmm, soweit ich weiß ist das kapern von Geräten via ssh ein Haupteinfallstor.
Ich halte daher einen malware Befall ebenfalls für möglich. Und der würde wegen des DOM auch eine komplette Neuinstallation überleben.
soweit ich weiß ist das kapern von Geräten via ssh ein Haupteinfallstor
Woher weißt du das?
ssh mir RSA-Schlüssel ist sicher und nach heutigen Erkenntnissen nicht zu knacken. Das gilt auch, wenn der Port ins Internet freigegeben ist.
Qnap nutzt OpenSSH 8.0 von 2019. Das ist zwar nicht die allerneueste Version, aber sie enthält keine relevanten Sicherheitslücken.
Unsicher wird ssh erst dann, wenn das Login per Passwort weiterhin gestattet ist und es Accounts mit Trivialpasswörtern oder Admins mit unveränderten Herstellerpasswörtern gibt.
Wie ssh abgesichert ist, lässt sich schnell rauskriegen. Bei einer erfolglosen Anmeldung wird es angezeigt:
$ ssh name@server
name@server: Permission denied (publickey).=> Der Zugang ist sicher. Login geht nur über ssh-keys.
$ ssh name@server
name@server: Permission denied (publickey,password).=> Login auch über Passwort möglich. Bei schlechten Passwörtern unsicher. Man muss ein Auge auf die Passwörter der Accounts, die sich per ssh anmelden dürfen, haben.
Ein geöffneter ssh-Port ist ein Einfallstor in das Heimnetz und damit eine Schwachstelle, die ich persönlich vermeide.
Bei mir geht das nur mit vorheriger Anmeldung im vpn.
Edit: Interessanter Meinungsaustausch siehe hier:
Weil nichts über CVEs bekannt ist, würde ich einer 2 Jahre alten Implementierung auf QNAP trotzdem nicht trauen.
Intel CPUs waren auch mal als sicher an zu sehen und Exchange hatte auch noch nie solchen Probleme.
Ich schalte auch lieber eine aktuelle VPN Lösung vors SSH, dann reichen mir auch PW.
Denn in meiner GE/VPN Lösung sind die weiteren nötigen Härtungen drin.
Selbst intern findet OpenVAS nix, weil die FW das erkennt und dann gar nicht mehr auf das Teil reagiert. Da wird so ein Scan dann nie fertig.
Aber über ssh wurden bisher noch keine QNAPs übernommen, das stimmt.
Aber ich bin mir sicher, das kommt auch noch mal, weil ein Keypair beim testen vergessen wurde und dann in der final Release landet.
Ich schalte auch lieber eine aktuelle VPN Lösung vors SSH
Das VPN könnte ebenso fehlerhaft sein und Angriffe ermöglichen.
Aber irgendwann machen wir uns mit solchen Ideen nur unnötig verrückt.
Sowohl VPN als auch ssh über Keys halte ich für sicher, weil der Angriffsvektor gering ist (gemeint ist, es gibt nur eine Methode, die von außen zugreifbar ist, nämlich der Login, und die kann dann fehlerfrei implementiert werden) und die Schnittstelle sehr gut getestet ist.
Der Grund dafür, dass ich ssh vorziehe, ist, dass es meiner Erfahrung stabiler läuft (insbesondere bei schlechter Internetverbindung) und weil VPN manchmal nicht zur Verfügung steht.
Aber ich bin mir sicher, das kommt auch noch mal, weil ein Keypair beim testen vergessen wurde und dann in der final Release landet.
In authorized_keys steht nur der öffentliche ssh-Schlüssel, und wenn der mit ausgeliefert wird, braucht's den privaten Schlüssel, den nur ein Tester in Taiwan hat (der sich dann aber auf jedem Qnap einloggen könnte). Der Schaden ist also überschaubar.
