Hi,
after seeing the IP address of your server in the first email (which by the
way was sent out to all subscribers of this Google Group), it looks like
you have (well, had) an unsecured MongoDB instance running which has been
wiped by a third party.
$ mongo "${YOUR_IP_ADDRESS}:27017"
MongoDB shell version v3.4.0
connecting to: mongodb://${YOUR_IP_ADDRESS}:27017
MongoDB server version: 3.2.5
WARNING: shell and server versions do not match
Server has startup warnings:
2017-01-06T17:52:44.708-0500 I CONTROL [initandlisten]
2017-01-06T17:52:44.708-0500 I CONTROL [initandlisten] ** WARNING:
Insecure configuration, access control is not enabled and no --bind_ip has
been specified.
2017-01-06T17:52:44.708-0500 I CONTROL [initandlisten] ** Read
and write access to data and configuration is unrestricted,
2017-01-06T17:52:44.708-0500 I CONTROL [initandlisten] ** and the
server listens on all available network interfaces.
2017-01-06T17:52:44.708-0500 I CONTROL [initandlisten]
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten]
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten] ** WARNING: You are
running on a NUMA machine.
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten] ** We
suggest launching mongod like this to avoid performance problems:
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten] **
numactl --interleave=all mongod [other options]
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten]
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten] ** WARNING:
/sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten] ** We
suggest setting it to 'never'
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten]
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten] ** WARNING:
/sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten] ** We
suggest setting it to 'never'
2017-01-06T17:52:44.709-0500 I CONTROL [initandlisten]
> show dbs
PLEASE_READ 0.000GB
graylog 0.000GB
> use PLEASE_READ
switched to db PLEASE_READ
> db.PLEASE_READ.find()
{ "_id" : ObjectId("58727dfa0c474c16c83c29a1"), "Info" : "Your DB is Backed
up at our servers, to restore send 0.1 BTC to the Bitcoin Address then send
an email with your server ip", "Bitcoin Address" : "xxx", "Email" :
"[email protected]" }
> use graylog
switched to db graylog
> show collections
nodes
notifications
pipeline_processor_pipelines
sessions
users
>
bye
I'm afraid your only chance is to restore a backup of the configuration,
which you hopefully have, and secure the MongoDB database properly.
Please
read
https://www.bleepingcomputer.com/news/security/mongodb-apocalypse-is-here-as-ransom-attacks-hit-10-000-servers/
and
https://www.mongodb.com/blog/post/how-to-avoid-a-malicious-attack-that-ransoms-your-data
to understand the issue at hand.
Cheers,
Jochen
On Monday, 9 January 2017 19:15:17 UTC+1, Jochen Schalanda wrote:
>
> Hi Wells,
>
> what's the content of the cluster_config collection in MongoDB and
> specifically the document with "type" ==
> "org.graylog2.indexer.management.IndexManagementConfig"?
>
> Example:
>
> $ mongo graylog
> MongoDB shell version v3.4.0
> connecting to: mongodb://127.0.0.1:27017/graylog
> MongoDB server version: 3.4.0
> > db.cluster_config.find({"type":
> "org.graylog2.indexer.management.IndexManagementConfig"}).pretty()
> {
> "_id" : ObjectId("566ff2a6d792d5a5bf0b3860"),
> "type" : "org.graylog2.indexer.management.IndexManagementConfig",
> "payload" : {
> "rotation_strategy" :
> "org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategy",
> "retention_strategy" :
> "org.graylog2.indexer.retention.strategies.DeletionRetentionStrategy"
> },
> "last_updated" : "2016-02-16T13:30:39.325Z",
> "last_updated_by" : "cd03ee44-b2a7-4824-be16-bb7456149dbd"
> }
>
>
> Also check the documents with "type" == $rotation_strategy
> ("org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategy" in
> this example) and $retention_strategy
> ("org.graylog2.indexer.retention.strategies.DeletionRetentionStrategy" in
> this example).
>
> Cheers,
> Jochen
>
> On Monday, 9 January 2017 19:05:18 UTC+1, [email protected] wrote:
>>
>> My graylog instance gave an error message suddenly a few days ago:
>> No index management configuration found, not running index rotation!
>> Please fix your index rotation configuration!
>>
>> Going to the system/indices page on the web ui, this error appeared twice:
>> Could not retrieve retention config
>> Fetching retention config failed: Error: cannot GET http://<server ip
>> address>:9000/api/system/indices/retention/config
>> <http://54.173.34.148:9000/api/system/indices/retention/config> (500)
>>
>> When I tried to check/update the index rotation strategy with the "update
>> configuration" button, it just left me with spinners, never loading any
>> config. I then tried to find index rotation config files on the server:
>>
>> - /system/indices/rotation/config
>> - /system/indices/retention/config
>>
>> But neither of those paths exist. I seem to have lost all inputs,
>> streams, dashboards etc. What happened here? What can I do?
>>
>> I am using graylog version 2.1, using the AWS VM setup with two nodes.
>>
>> Any help would be greatly appreciated.
>>
>> Best,
>> Wells
>>
>
--
You received this message because you are subscribed to the Google Groups
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/graylog2/f6868175-2759-4708-9806-ac71d79cd207%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
