Re: [graylog2] Re: Index rotation problem - "config not found"

2017-01-09 Thread wells
I see, thanks, that makes sense. I changed the servers anyway.

On Monday, January 9, 2017 at 2:52:42 PM UTC-5, Jochen Schalanda wrote:
>
> Hi Wells,
>
> On Monday, 9 January 2017 20:10:54 UTC+1, Wells Johnston wrote:
>>
>> I noticed that mistake and I thought I deleted that post! How are you 
>> still able to see it?
>>
>
> Each post on this Google Group is automatically sent out to the (email) 
> subscribers, see https://www.mail-archive.com/graylog2@googlegroups.com/ 
> for an independent mailing list archive of this group.
>
> If you delete a post, it's only deleted on the Google Groups web interface.
>
> Cheers,
> Jochen
>

-- 
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 graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/096fe10b-fa3d-4c02-bdae-6d65839c71f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [graylog2] Re: Index rotation problem - "config not found"

2017-01-09 Thread Jochen Schalanda
Hi Wells,

On Monday, 9 January 2017 20:10:54 UTC+1, Wells Johnston wrote:
>
> I noticed that mistake and I thought I deleted that post! How are you 
> still able to see it?
>

Each post on this Google Group is automatically sent out to the (email) 
subscribers, see https://www.mail-archive.com/graylog2@googlegroups.com/ 
for an independent mailing list archive of this group.

If you delete a post, it's only deleted on the Google Groups web interface.

Cheers,
Jochen

-- 
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 graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/6dd6490f-1890-4de1-a61c-437f24206ac0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[graylog2] Re: Index rotation problem - "config not found"

2017-01-09 Thread wells
I'm realizing now the mongo instance being wiped was part of a massive 
attack that happened a few days ago. This has been an eye-opening 
experience...lesson learned :(

Thank you for your help Jochen...

On Monday, January 9, 2017 at 1:26:07 PM UTC-5, Jochen Schalanda wrote:
>
> 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" 
> : "x...@example.com " }
> > 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, we...@littlstar.com 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 

Re: [graylog2] Re: Index rotation problem - "config not found"

2017-01-09 Thread Wells Johnston
I noticed that mistake and I thought I deleted that post! How are you still
able to see it?

Wiped by a third party?  What?? :|

On Mon, Jan 9, 2017 at 1:26 PM, Jochen Schalanda  wrote:

> 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"
> : "x...@example.com" }
> > 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.manageme
>> nt.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.manageme
>> nt.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.retentio
>> n.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.retenti
>> on.strategies.DeletionRetentionStrategy" in this example).
>>
>> Cheers,
>> Jochen
>>
>> On Monday, 9 January 2017 19:05:18 UTC+1, we...@littlstar.com 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 

[graylog2] Re: Index rotation problem - "config not found"

2017-01-09 Thread Jochen Schalanda
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" : 
"x...@example.com" }
> 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, we...@littlstar.com 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://> address>: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 

[graylog2] Re: Index rotation problem - "config not found"

2017-01-09 Thread Jochen Schalanda
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, we...@littlstar.com 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:// address>: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 graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/c95806ca-1c9b-4f8f-9d55-e2d1c1cbf592%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.