couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sinan Gabel <sinan.ga...@gmail.com>
Subject Re: 100% CPU on only a single node because of couchjs processes
Date Mon, 11 Dec 2017 16:49:40 GMT
I just found this, it may solve the problem by removing it. It is a script
that starts the crypto mining program as user couchdb.

[image: Inline images 1]

On 11 December 2017 at 15:04, Sinan Gabel <sinan.gabel@gmail.com> wrote:

>
>
> I have now checked it, and it is as you @Robert perceived, a crypto mining
> program.
>
> It is a program "fs-manager" with config.json as given below that is
> restarted every 3 hours or so (8:41, 11:41 etc.) unless it keeps running.
>
> I updated couchdb to latest version and changed all admin passwords but
> that has not solved it, so it hidden somewhere on the server.
>
> Anyone have a clue to how to remove this hack completely?
>
>
>
> $ sudo find / -name "fs-manager"
>
> =>
>
> /var/tmp/.X1M-Unix/fs-manager
>
>
> $ ls -al
>
> =>
>
>
> $ less config.json
>
> =>
>
> { "algo": "cryptonight", "av": 0, "background": true, "colors": false,
> "cpu-affinity": null, "cpu-priority": null, "donate-level": 2, "log-file":
> "xmrig.log", "max-cpu-usage": 85, "print-time": 60, "retries": 2,
> "retry-pause": 3, "safe": false, "syslog": false, "threads": null, "pools":
> [ { "url": "pool-proxy.com:8080", "user": "user", "pass": "x",
> "keepalive": true, "nicehash": false } ]}
>
>
>
>
> On 10 December 2017 at 18:11, Robert Samuel Newson <rnewson@apache.org>
> wrote:
>
>> fs-manager is not part of couchdb. You should check that you've not been
>> hacked. See https://justi.cz/security/2017/11/14/couchdb-rce-npm.html <
>> https://justi.cz/security/2017/11/14/couchdb-rce-npm.html>.
>>
>> I've seen another case where a user's couchdb installation was
>> compromised and a bitcoin mining tool installed. This would (obviously) use
>> all your cpu, and I think fs-manager was part of that.
>>
>> B.
>>
>> > On 10 Dec 2017, at 17:07, Sinan Gabel <sinan.gabel@gmail.com> wrote:
>> >
>> > Same problem with latest couchdb clustered version. What is the process
>> "
>> > */.fs-manager*" doing?
>> >
>> > Googling it returned something about a python package called
>> "fs-manager"!?
>> >
>> > For now I have killed the *couchdb fs-manager* process, and couchdb
>> still
>> > seems to be working fine.
>> >
>> > On 10 December 2017 at 16:50, Sinan Gabel <sinan.gabel@gmail.com>
>> wrote:
>> >
>> >> PS I have just now upgraded to latest couchdb clustered version, I will
>> >> see if that solves the 100% CPU usage problem.
>> >>
>> >> On 10 December 2017 at 15:28, Sinan Gabel <sinan.gabel@gmail.com>
>> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I do not have a solution but also experiencing the 100% CPU usage.
>> Here's
>> >>> a .png screen shot of the processes running (my case):
>> >>>
>> >>>
>> >>> On 10 December 2017 at 02:00, Geoffrey Cox <redgeoff@gmail.com>
>> wrote:
>> >>>
>> >>>> Well, I'm back at this and here is the latest info and I think it
>> may be
>> >>>> related to writes and the _global_changes database:
>> >>>>
>> >>>>   1. I run my production env and one of my nodes becomes the
>> "workhorse"
>> >>>>   node with 100% CPU
>> >>>>   2. I stop all my production code from generating any more CouchDB
>> >>>>   requests and eventually the workhorse node goes back to 0% CPU
>> >>>>   3. I can then issue writes on a single database (really any
>> database
>> >>>> and
>> >>>>   ANY node--not just the workhorse node) and the workhorse node
will
>> >>>> kick
>> >>>>   back up to 100% CPU. If I stop the writes, the workhorse node
will
>> >>>> return
>> >>>>   to 0% CPU.
>> >>>>   4. And now the punch line: if I delete the _global_changes
>> database,
>> >>>> the
>> >>>>   CPU drops down to 0% even if I am issuing writes! Pure cray cray
>> >>>>
>> >>>> Any thoughts?
>> >>>>
>> >>>> (Sorry, still working on a reproducible env for everyone)
>> >>>>
>> >>>> On Wed, Dec 6, 2017 at 6:56 AM Geoffrey Cox <redgeoff@gmail.com>
>> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>>
>>
>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message