Wazuh api 500 - cannot register kibana app

[Daniil Sobolev]

Hi team,

I have an issue with wazuh api, hope you might help me to fix it. 

Registering API in kibana failed so I tried to do same api calls with curl and it happened to break down API.

example: 

Hi team,

I have an issue with wazuh api, hope you might help me to fix it. 

Registering API in kibana failed so I tried to do same api calls with curl and it happened to break down API.

example: 

 curl -u foo:bar "http://localhost:55000/agents/000"

{"error":3,"message":"Internal error"}

logs:

WazuhAPI 2019-10-15 14:33:21 foo: Internal Error

WazuhAPI 2019-10-15 14:33:21 foo: TypeError: Cannot read property 'on' of undefined

    at Object.exports.exec (/var/ossec/api/helpers/execute.js:70:18)

    at /var/ossec/api/controllers/agents.js:490:13

    at Layer.handle [as handle_request] (/var/ossec/api/node_modules/express/lib/router/layer.js:95:5)

    at next (/var/ossec/api/node_modules/express/lib/router/route.js:137:13)

    at buildCacheObj (/var/ossec/api/node_modules/apicache/lib/apicache.js:241:9)

    at cache (/var/ossec/api/node_modules/apicache/lib/apicache.js:188:9)

    at Layer.handle [as handle_request] (/var/ossec/api/node_modules/express/lib/router/layer.js:95:5)

    at next (/var/ossec/api/node_modules/express/lib/router/route.js:137:13)

    at Route.dispatch (/var/ossec/api/node_modules/express/lib/router/route.js:112:3)

    at Layer.handle [as handle_request] (/var/ossec/api/node_modules/express/lib/router/layer.js:95:5)

WazuhAPI 2019-10-15 14:33:21 foo: Exiting...

WazuhAPI 2019-10-15 14:33:21 foo: [127.0.0.1] GET /agents/000 - 500 - error: '3'.

WazuhAPI 2019-10-15 14:33:21 foo: Internal Error: uncaughtException

WazuhAPI 2019-10-15 14:33:21 foo: Error: spawn /var/ossec/framework/python/bin/python3 EACCES

    at Process.ChildProcess._handle.onexit (internal/child_process.js:240:19)

    at onErrorNT (internal/child_process.js:415:16)

    at process._tickCallback (internal/process/next_tick.js:63:19)

WazuhAPI 2019-10-15 14:33:21 foo: Exiting...

WazuhAPI 2019-10-15 14:33:21 foo: Internal Error: uncaughtException

WazuhAPI 2019-10-15 14:33:21 foo: TypeError: Cannot read property 'setEncoding' of undefined

    at Timeout._onTimeout (/var/ossec/api/helpers/execute.js:65:25)

    at ontimeout (timers.js:436:11)

    at tryOnTimeout (timers.js:300:5)

    at listOnTimeout (timers.js:263:5)

    at Timer.processTimers (timers.js:223:10)

WazuhAPI 2019-10-15 14:33:21 foo: Exiting...

Code fragment: 

  child.stdout.on('data', (chunk) => {

        output.push(chunk)

        //logger.debug("Chunk: " + Buffer.byteLength(chunk, 'utf8') + " bytes");

    });

The only change I did to default installation is to tamper with client.keys file - I've added several agents from previous installation. 

Now I think it might broke some WZH logic. 

So, two questions: 

1. Is there a quick way to fix this error, or reinstall is the best way to deal with it? 

2. How can I properly import client.keys from another server? 

Thanks! 

[Demetrio Ruiz]

Hi Daniil Sobolev,

It seems that our Python interpreter hasn't got execution permission. I can replicate your error by unsetting execution permission for the Python interpreter.

Please, give execution permission to it as below (I assume that your installation path is /var/ossec):

chmod +x /var/ossec/framework/python/bin/python3.7

After doing that, restart the Wazuh API (systemctl restart wazuh-api or service wazuh-api restart) and try to make another request.

Best regards,

Demetrio.

[Daniil Sobolev]

Hi Demetrio,

Thanks for your input. 

It helped partially, after mentioned changes kibana was able to query API, but it still couldn't find 000 agent(usually it is the manager itself), because somehow manager registered with a different ID in agent list. 

Full reinstall helped though. 

Could you please address my second question - 2. How can I properly import client.keys from another server? 

Thanks,

Daniil.

среда, 16 октября 2019 г., 9:41:42 UTC+3 пользователь Demetrio Ruiz написал:

[Demetrio Ruiz]

Hi Daniil Sobolev,

Could you check the result of this request? The manager always is the agent 000 and it doesn't need to be registered.

# curl -u foo:bar -k "https://localhost:55000/agents/000?pretty"

{

  "error": 0,

  "data": {

     "registerIP": "127.0.0.1",

     "name": "fa220762b7f1",

     "os": {

       "arch": "x86_64",

        "major": "8",

        "minor": "0",

        "name": "CentOS Linux",

        "platform": "centos",

        "uname": "Linux |fa220762b7f1 |5.2.18-200.fc30.x86_64 |#1 SMP Tue Oct 1 13:14:07 UTC 2019 |x86_64",

        "version": "8.0"

     },

     "id": "000",

     "node_name": "master",

     "ip": "127.0.0.1",

     "status": "Active",

     "dateAdd": "2019-10-09 10:40:05",

     "manager": "fa220762b7f1",

     "version": "Wazuh v3.10.2",

     "lastKeepAlive": "9999-12-31 23:59:59"

  }

}

About migration, my mate David J. Iglesias made this guide that could be useful for you:

It is recommended to backup to /var/ossec but if you move the directory and install from sources the startup services will not work. To migrate from Wazuh Manager to a new server follow these steps:
1. Install Wazuh Manager in the new server. Do not select to run Manager after installation. To avoid any problems with migration I suggest to install the same version you are migrating from. If you would like to upgrade I suggest to do it after migration is completed and Wazuh is running again.
2. Backup your original files. To avoid losing any configuration, or agent keys, stop manager service and then make a copy of /var/ossec (default installation directory). Make sure you preserve actual owners and permissions for files, you can use something like rsync or tar the backup.
3. Restore configuration. Before you attempt restoration make sure the Manager is stopped in the new server.
   cp -p /var/ossec_backup/etc/client.keys /var/ossec/etc/ MASTER ONLY
   cp -p /var/ossec_backup/etc/ossec.conf /var/ossec/etc/
   cp -p /var/ossec_backup/queue/rids/sender_counter /var/ossec/queue/rids/sender_counter
   cp -p /var/ossec_backup/queue/agents-timestamp /var/ossec/queue/agents-timestamp MASTER ONLY
   If you have made local changes to any of the following then also restore:
   cp -p /var/ossec_backup/etc/local_internal_options.conf /var/ossec/etc/
   cp -p /var/ossec_backup/etc/rules/local_rules.xml /var/ossec/etc/rules/ MASTER ONLY
   cp -p /var/ossec_backup/etc/decoders/local_decoder.xml /var/ossec/etc/decoders/ MASTER ONLY
   cp -rp /var/ossec_backup/etc/lists/* /var/ossec/etc/lists/ MASTER ONLY
   If you have centralized configuration and agent groups you must restore:
   cp -rp /var/ossec_backup/etc/shared/* /var/ossec/etc/shared/ MASTER ONLY
   cp -rp /var/ossec_backup/queue/agent-groups/* /var/ossec/queue/agent-groups/ MASTER ONLY
   Optionally the following files can be restored to preserve alert log files, syscheck/rootcheck databases and stats:
   cp -rp /var/ossec_backup/logs/archives/* /var/ossec/logs/archives/
   cp -rp /var/ossec_backup/logs/alerts/* /var/ossec/logs/alerts/
   cp -rp /var/ossec_backup/queue/rootcheck/* /var/ossec/queue/rootcheck/
   cp -rp /var/ossec_backup/queue/syscheck/* /var/ossec/queue/syscheck/
   cp -rp /var/ossec_backup/stats/* /var/ossec/stats/
4. Start Wazuh Manager service
5. If you are running your agents behind a Load Balancer make sure to change the wazuh-master IP to the new one. Otherwise, you have to change the IP of the agents (ossec.conf) that are reporting to the wazuh-master to the new one.

I hope that this guide helps you.

Best regards,

Demetrio.

[Daniil Sobolev]

Hi Demetrio,

Thanks for sharing guide! 

I cannot check the query now, since I've reinstalled wazuh, but my manager's ID weren't 000, most probably because of me adding content of old server's clint.keys to the new server. 

By the way, I'm wondering if it is possible to combine several client.keys( let's say I will check that there's no duplicates)? 

I'm trying to build some kind of global client keys database that would be shared between multiple servers, so clients can report to any of them.

Right now it seems like stopping the wazuh service, adding data to client.keys file and starting it again working, but I still need more tests on it. 

Anyway, I appreciate you guys are always ready to help. Keep up the good work! 

Thanks,

Daniil.

четверг, 17 октября 2019 г., 9:35:20 UTC+3 пользователь Demetrio Ruiz написал:

[Demetrio Ruiz]

Hi Daniil Sobolev,

Here there is an example when I execute the command /var/ossec/bin/agent_control -l in my environment:


# /var/ossec/bin/agent_control -l

Wazuh agent_control. List of available agents:
   ID: 000, Name: c3baf87e36fa (server), IP: 127.0.0.1, Active/Local
   ID: 001, Name: ffacca7b3a19, IP: 172.18.0.4, Active
   ID: 002, Name: bf5ec4428cb2, IP: 172.18.0.6, Active
   ID: 003, Name: 7bd589abfee7, IP: 172.18.0.7, Active

This command shows a list of the available agents. As you can see, the manager has the ID 000. Could you execute this command and send me the output?

About combine several client.keys, stop the manager and put the data in /var/ossec/etc/client.keys file and ensure that the agents are reporting to the manager IP. Restart the manager and execute the command I put before for checking if the agents are connected.

I hope that it could help you.

Best regards,

Demetrio.