I have gitlab on a gcp cloud server; gcp alerts me to possible mining on my server, when searching with the clamav antivirus it alerts me to the following files: /var/log/gitlab/postgresql/memory: Multios.Coinminer.Miner-6781728-2 FOUND /var/opt/gitlab/postgresql/data/pg_twophase/memory: Multios.Coinminer.Miner-6781728-2 FOUND /var/opt/gitlab/postgresql/data/memory: Multios.Coinminer.Miner-6781728-2 FOUND
It is possible that it is a clamav or gitlab error, the repository used to install and update is https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh I add a screenshot of the repository
Hi,
No that is not clamav, that means your instance has been compromised by a vulnerability in Gitlab that has allowed those files to be placed in those directories. You don’t mention what version of Gitlab you have installed, but you should really be upgrading your Gitlab regularly so that you don’t have such problems.
You can search the forums about people who have had high CPU usage due to compromised servers and the Gitlab RCE that caused that. You want to be deleting those files, and also checking that you don’t have high cpu usage causing Gitlab to crash. And you want to be upgrading your Gitlab immediately. Ensure you have all necessary backups to recover just in case.
Clamav deleted the infected files and ran the search task again and I no longer get any problems, the server is at version 15.10.0 when I found the viruses it was at 15.9.3 I updated the server after the antivirus search, but It is not clear to me how the files could be violated, only I have access to the operating system, however a few weeks ago I activated the firewall to access the database, I don’t know if there is any vulnerability by having the port open, for now I closed the database port, I have not had problems with high cpu usage other than at the time I report it to gcp
Yeah you want to be careful about opening the port - restrict that to your particular IP address to make sure nobody else attempts to connect. Especially if postgres has a default password for the postgres user, or other such possibilities to get in and cause havoc.
The configuration was not the default, a password was assigned to the database; however, I don’t know where the vulnerability is, since it went directly to the gitlab files corresponding to postgres, that’s what caught my attention
