Hello.
"My current OR platform, which began production a few days ago, is being been affected by Mining Malware ( (kdevtmpfsi and kinsing affect docker in some way). I think the best solution at this point is to install a fresh and clean OR platform and migrate my data to the new platform. Since I am not an experienced PostgreSQL user, I would appreciate some advice on the best way to transfer all my collected data to the new OR installation.
Best regards.
How did this malware get on your system?
Make sure you are using private key auth with password login disabled and use a good level of encryption on your key.
As for backup and restore of data:
Thanks for the reference, Rich. Honestly, I’m not sure how I got the malware. After researching online, I discovered that this malware is related to either postgres or docker. it’s possible that when I started testing OR, two weeks ago, I wasn’t very cautious with the firewall. Although I always use ssh for server access, I may have neglected to start ufw (firewall) until a day later. It’s not entirely clear to me.
The main symptom of the malware is that the CPU server constantly runs at 100%.
Best regards.
Hello.
In my clean and fresh Openremote installation, I got the same malware again. It looks like the ufw firewall in their default configuration does not protect Docker because Docker skips ufw. So the malware can exploit any Docker vulnerability. An additional conf must be added to ufw.
I go for my third try.
Best regards.
Thanks for sharing your findings; where does the malware appear, on the host itself or inside one of the docker containers?
Hello.
I try to follow the instructions to get another dump but I got
or@debian-s-2vcpu-4gb-V5:~/openremote$ docker exec openremote-postgresql-1 pg_dump -Fc openremote -f /tmp/db.bak
pg_dump: warning: there are circular foreign-key constraints on this table:
pg_dump: hypertable
pg_dump: You might not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints.
pg_dump: Consider using a full dump instead of a --data-only dump to avoid this problem.
pg_dump: warning: there are circular foreign-key constraints on this table:
pg_dump: chunk
pg_dump: You might not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints.
pg_dump: Consider using a full dump instead of a --data-only dump to avoid this problem.
pg_dump: warning: there are circular foreign-key constraints on this table:
pg_dump: continuous_agg
pg_dump: You might not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints.
pg_dump: Consider using a full dump instead of a --data-only dump to avoid this problem.
pg_dump: NOTICE: hypertable data are in the chunks, no data will be copied
DETAIL: Data for hypertables are stored in the chunks of a hypertable so COPY TO of a hypertable will not copy any data.
HINT: Use “COPY (SELECT * FROM ) TO …” to copy all data in hypertable, or copy each chunk individually.
pg_dump: NOTICE: hypertable data are in the chunks, no data will be copied
DETAIL: Data for hypertables are stored in the chunks of a hypertable so COPY TO of a hypertable will not copy any data.
HINT: Use “COPY (SELECT * FROM ) TO …” to copy all data in hypertable, or copy each chunk individually.
or@debian-s-2vcpu-4gb-V5:~/openremote$
Kind regards.
Sorry for the delay; this can be ignored according to the timescaleDB team:
Thank you Rich.
Best regards.