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 14:04:02 GMT
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/alternative (inline, None, 0 bytes)
View raw message