Hello team,

As well as the API calls that already exist to retrieve information about the OS, hardware, and packages for agents. It would be useful to develop the same calls for the new scans introduced in 3.3 by Syscollector consisting of network, ports, and processes inventory.

Thank you!

Thought I would try out 3.0.
Running in AWS Amazon Linux.

Just pulled master 3.0? Ran ./install_api.

Installing Wazuh API 3.0.0-beta9 from current directory [DEV MODE].

Installing API ['/var/ossec/api'].

Installing NodeJS modules.

Installing service.
----------------------------------------------------------------
Installing for SysVinit
init script installed in /etc/init.d/wazuh-api
We could not enable it. Please enable the service manually.
----------------------------------------------------------------

API URL: http://host_ip:55000/
user: 'foo'
password: 'bar'
Configuration: /var/ossec/api/configuration
Test: curl -u foo:bar -k http://127.0.0.1:55000?pretty
Note: You can configure the API executing /var/ossec/api/scripts/configure_api.sh

### [API installed successfully] ###```

```/etc/init.d/wazuh-api status
WAZUH-API is stopped.

Last 20 log entries:

Full log: /var/ossec/logs/api.log```

But no process or logs.  I am running the latest from the Wazuh repo as well.  

Should this API support OSSEC log collection by REST calls? (syslog still not very microservice friendly)

Hello!

Thank you for your amazing software.

But, the issue #20 is still actual.
I think that the reason in a inconsistency of the charsets.

On the server side:

sqlite3 /var/ossec/var/db/global.db
attach database '/var/ossec/var/db/global.db' as "dbname";
pragma dbname.encoding;
UTF-8

I looked at the commit #b3c734a "Fix bug when microsoft version command has cyrillic characters" and saw that all the changes were in the file src/shared/file_op.c. In this file used function "fopen":
648 finalfp = fopen(finalpath, "w");
But on the MSDN support page

fopen supports Unicode file streams. To open a Unicode file, pass a ccs flag that specifies the desired encoding to fopen, as follows.

FILE *fp = fopen("newfile.txt", "rt+, ccs=encoding");

Allowed values of encoding are UNICODE, UTF-8, and UTF-16LE.

So, all file-IO functions should be rewritten for UTF-8 support. For example like this:
finalfp = fopen(finalpath, "w,ccs=UTF-8");

With the best regards,
Vladislav.

The current deletion behavior does not actually delete an agent from the client.keys file, it simply drops an exclamation point in front of the agent name.

It seems that these "deleted" entries still count against the 8000 node limit -- maybe this should be deleting the matching line instead?

My workaround is sed -i '/ !/d' /var/ossec/etc/client.keys to get rid of those lines

Hello,
I'm trying to delete an agent and I'm getting this response, after which no agent is deleted.

curl -u foo:bar  -X DELETE "http://127.0.0.1:55000/agents/012?pretty"
{
   "error": 0,
   "data": {
      "msg": "Some agents were not removed",
      "ids": [
         "0",
         "1",
         "2"
      ]
   }
}

Log doesn't show additional clues.

WazuhAPI 2017-09-22 17:42:48: ::ffff:127.0.0.1 DELETE /agents/:agent_id
WazuhAPI 2017-09-22 17:42:48: ::ffff:127.0.0.1 DELETE /agents/:agent_id
WazuhAPI 2017-09-22 17:42:48: CMD - Command: python args:/var/ossec/api/models/wazuh-api.py stdin:{"function":"DELETE/agents/:agent_id","arguments":{"agent_id":"012"},"ossec_path":"/var/ossec"}
WazuhAPI 2017-09-22 17:42:48: CMD - Command: python args:/var/ossec/api/models/wazuh-api.py stdin:{"function":"DELETE/agents/:agent_id","arguments":{"agent_id":"012"},"ossec_path":"/var/ossec"}
WazuhAPI 2017-09-22 17:42:48: CMD - Exit code: 0
WazuhAPI 2017-09-22 17:42:48: CMD - STDOUT:
---
{"data": {"msg": "Some agents were not removed", "ids": ["0", "1", "2"]}, "error": 0}

---
WazuhAPI 2017-09-22 17:42:48: CMD - STDOUT: 86 bytes
WazuhAPI 2017-09-22 17:42:48: CMD - Exit code: 0
WazuhAPI 2017-09-22 17:42:48: CMD - STDOUT:
---
{"data": {"msg": "Some agents were not removed", "ids": ["0", "1", "2"]}, "error": 0}

---
WazuhAPI 2017-09-22 17:42:48: CMD - STDOUT: 86 bytes
WazuhAPI 2017-09-22 17:42:48: [::ffff:127.0.0.1] DELETE /agents/012?pretty - 200 - error: '0'.
WazuhAPI 2017-09-22 17:42:48: [::ffff:127.0.0.1] DELETE /agents/012?pretty - 200 - error: '0'.

Version:
wazuh-api-2.1.0-1.el7.x86_64
Nodejs
v6.10.3

Thanks in advance!
Gustavo

Not sure if this is an API or manager issue, but we made the unfortunate mistake of attempting to register ~100 agents at just about exactly the same time. This resulted in dual registrations of the same ID, an inability to resolve keys, and requirement to wipe the offending ID twice from the managers CLI to remove both artifacts, and then re-register each node separately.
This smells from the outside of a missing semaphore or a threadsafe ID dereference somewhere, but the end result can be very unpleasant. We've never run into this before because the Chef runs arent usually done in 100+ concurrent ssh shells making collisions quite likely. We also saw that a number of nodes had to be re-run as apparently the API has some limit in how many new keys it can generate at the same time (granted, this is an older AMD system, but still 100 key generations shouldnt cause failures, just longer response times to the registration requests).

Hello API team, it would be nice if we can fetch unique values for specific column.

I'm going to show an example, this way you'll have a better understanding of the issue:

I need to know all unique Wazuh agents version in my environment.

Today:

• I have 20.000 agents using Wazuh 3.2.0, 3.2.1 and 3.2.2
  • Iterate over 20.000 agents to compose an array of 3 elements
    • ['Wazuh 3.2.0', 'Wazuh 3.2.1', 'Wazuh 3.2.2']

With this feature:

• Add a new parameter or create new routes
• Use SQL directly to achieve the same task

This feature should be available for any kind of list from the Wazuh API and for any field from the list.

Thanks in advance,

Jesús

Trying to add multiple agents at the same time often return the same agent id for multiple requests. Generate multiple entries in clients.keys with the same agent id. Also, some of the shared secret will have a matching end half.

This presents a problem when attempting to automate key management with tools like salt, puppet, etc.

Steps to reproduce

1. Setup a freshly installed wazuh-manager and wazuh-api with no auth/ssl configured on ubuntu 16.04
2. Then try and add 10 agents at same time.

root@master:~$ for i in `seq 1 10`; do { curl -X PUT "http://127.0.0.1:55000/agents/myagentname$i?pretty" & } 2>/dev/null; done; wait 2>/dev/null
{
   "error": 0,
   "data": "001"
}
{
   "error": 0,
   "data": "002"
}
{
   "error": 0,
   "data": "003"
}
{
   "error": 0,
   "data": "004"
}
{
   "error": 0,
   "data": "004"
}
{
   "error": 0,
   "data": "005"
}
{
   "error": 0,
   "data": "006"
}
{
   "error": 0,
   "data": "006"
}
{
   "error": 0,
   "data": "007"
}
{
   "error": 0,
   "data": "007"
}
root@master:~$ cat /var/ossec/etc/client.keys
001 myagentname10 any cdbef82797197a5d13c53ceed24a8a48878f2a249288aa861ee4244d91306a03
002 myagentname8 any 58d981c501e84239bd88d242e5b33a5da88ca47804744af52d36742b61004271
003 myagentname5 any 130398127b6dc1a28fb4910b95790c7b003b7166d32c1373fe54992beb4dd7d5
004 myagentname9 any 43ffb2da13374aeb50de63ae8db62818556dcd93bf99b475c9cfbbeabb99ac88
004 myagentname6 any b9bc5b05d3c6ba38ae45fc2a7505dac1556dcd93bf99b475c9cfbbeabb99ac88
005 myagentname4 any 66ed6bf4f2f598ae7f00cab43678b16aa2e5f2fc76e433e20be359f5cd7433b8
006 myagentname1 any db5a0c4ebfd17514fe91cff2ac5a6ec31fb019b96bbadf4c799916475532f53a
006 myagentname2 any 8606bf6a7ecd8df140e6bb4af80363e11fb019b96bbadf4c799916475532f53a
007 myagentname7 any 2f55396540dbe5ec8c36005b57c4c235a139f693dee30e894bf452f4b8e90dc7
007 myagentname3 any d1244742f481652e67f579c4559beb5da139f693dee30e894bf452f4b8e90dc7

Version

root@master:~$ curl  http://127.0.0.1:55000/manager/info?pretty
{
   "error": 0,
   "data": {
      "installation_date": "Tue Sep 19 12:03:54 UTC 2017",
      "version": "v2.1.1",
      "openssl_support": "yes",
      "max_agents": "8000",
      "ruleset_version": "v2.1.0",
      "path": "/var/ossec",
      "tz_name": "UTC",
      "type": "server",
      "tz_offset": "+0000"
   }
}```

Hello, when I try to show the following config:

<agent_config os="rhel: 6">


  <syscheck>
    <frequency>43200</frequency>


    <!-- Directories to check  (perform all possible verifications) -->
    <directories check_all="yes" restrict="^test$">/etc,/usr/bin,/usr/sbin</directories>

</syscheck>

</agent_config>

If I run

GET /agents/groups/test/configuration

The API Message is:

{"message":"3013 - Error getting configuration: mismatched tag: line 31, column 79","code":3013,"statusCode":500}

Where the line 31 is the line with the restrict

Hello team, this API is awesome but we have some limitations regarding to accepted characters. I know it could be weird and we can't accept all kind of character but it would be nice if we add characters like à,è,á,é, etc. French users will agree with this.

Regards,
Jesús

[root@localhost wazuh-api-3.0.0]# npm list
[email protected] /home/apps/wazuh3.0/wazuh-api-3.0.0
├── UNMET DEPENDENCY apicache@^0.2.0
├── UNMET DEPENDENCY body-parser@^1.15.2
├── UNMET DEPENDENCY cors@^2.7.1
├── UNMET DEPENDENCY express@^4.14.0
├── UNMET DEPENDENCY htpasswd@^2.3.4
├── UNMET DEPENDENCY http-auth@^3.0.1
└── UNMET DEPENDENCY moment@^2.15.0

npm ERR! missing: apicache@^0.2.0, required by [email protected]
npm ERR! missing: body-parser@^1.15.2, required by [email protected]
npm ERR! missing: cors@^2.7.1, required by [email protected]
npm ERR! missing: express@^4.14.0, required by [email protected]
npm ERR! missing: htpasswd@^2.3.4, required by [email protected]
npm ERR! missing: http-auth@^3.0.1, required by [email protected]
npm ERR! missing: moment@^2.15.0, required by [email protected]

Current request POST:/agents/purge is removing never connected agents, the ones could be agents registered recently and pending to report data.

The purge is based on timeframe value which can not be applied to non connected agents, that is why we should add a new flag to force/decide when to remove those agents.

If the API password for basic authentication contains spaces, the variable substitution does not correctly take place during both curl commands, causing the script to fail with no error message (very unhelpful). It likely won't handle other special characters as well.

# agent_groups -h

    /var/ossec/bin/agent_groups [ -l [ -g group_id ] | -c -g group_id | -a (-i agent_id -g groupd_id | -g group_id) [-q] | -s -i agent_id | -r (-g group_id | -i agent_id) [-q] ]

    Usage:
    ./agent_groups.py [-l]                                  # List all groups
    ./agent_groups.py -l -g group_id                        # List agents in group
    ./agent_groups.py -c -g group_id                        # List configuration files in group

    ./agent_groups.py -a -i agent_id -g group_id [-q]       # Set agent group
    ./agent_groups.py -r -i agent_id [-q]                   # Unset agent group
    ./agent_groups.py -s -i agent_id                        # Show group of agent

    ./agent_groups.py -a -g group_id [-q]                   # Create group
    ./agent_groups.py -r -g group_id [-q]                   # Remove group

We should remove the .py extension.

Hi!

First, thank you for your software!

I installed wazuh-manager&api&app, opened last on kibana.
Than I added a new agent with kibana. After that when i go "agents" or "manager" in kibana i have "Wazuh API returned an error message. Error: Error executing internal command. Exit code: 1" message.
Tab "Agents" shows only the manager.
curl -u foo:bar -k "http://127.0.0.1:55000/agents/?offset=0&limit=30&sort=id&pretty" returns

{
   "error": 0,
   "data": {
      "totalItems": 2,
      "items": [
         {
            "status": "Active",
            "ip": "127.0.0.1",
            "os": {
               "platform": "centos",
               "version": "7",
               "name": "CentOS Linux"
            },
            "id": "000",
            "name": "clog6"
         }
      ]
   }
}

in logs there are:

---
WazuhAPI 2017-09-05 18:21:32: CMD - STDOUT: 254 bytes
WazuhAPI 2017-09-05 18:21:32: [::ffff:192.168.100.106] GET /manager/info? - 200 - error: '0'.
WazuhAPI 2017-09-05 18:21:32: CMD - Exit code: 1
WazuhAPI 2017-09-05 18:21:32: [::ffff:192.168.100.106] GET /agents/?offset=0&limit=1&sort=-id - 500 - error: '1'.
WazuhAPI 2017-09-05 18:21:32: Response: {"error":1,"message":"Error executing internal command. Exit code: 1"} HTTP Status: 500
WazuhAPI 2017-09-05 18:21:32: ::ffff:192.168.100.106 GET /rules
WazuhAPI 2017-09-05 18:21:32: CMD - Command: python args:/var/ossec/api/models/wazuh-api.py stdin:{"function":"/rules","arguments":{"offset":"0","limit":"1"},"ossec_path":"/var/ossec"}
WazuhAPI 2017-09-05 18:21:33: CMD - Exit code: 0
WazuhAPI 2017-09-05 18:21:33: CMD - STDOUT:
---

Please help me:)

P.S. Sorry for my language, I've just started study)

Was working great on 3.0 then I started adding a bunch of agents. Now getting this in Kibana.

Tried restarting the service and received same error. Agents should be in the 200-300 range.

Sorry more context:

This is only happening on the Agents tab in the Wazuh Kibana app.

I haven't updated this since I moved to 3.0. Is there a version I should update to here as well?

Hello team,

Currently, the GET/agents request only allows filtering by:

• Status
• Timeframe / Last keep alive
• Node name
• OS platform
• OS version
• Manager host
• Version

The GET/agents request returns much more fields, such as group, which have no filter yet.

Best regards,
Marta

Hello team, it's not enough to use negated search, we need an excluding option.

• Using negated search could not work as expected.
• Using excluding option by specific field should work always as expected.

This way the negated search should be still available but the excluding option should work as follow:

• Given a route which returns an array of items /agents
  • It would be nice if I can say "give me all the agents except agents whose OS is CentOS 7"

Regards,
Jesús

What setting should i use to make the WAZUH api run on IPv4 and not IPv6 as illustrated on the screenshot above.

wazuh-manager: 3.1.0
wazuh-api: 3.1.0

Hi,

i tested a few local rules and decoders in the scope of wazuh/wazuh-ruleset#102 . After those changes i've noticed that opening the "status" page within the Wazuh Kibana App the following error is shown without giving any information about the reason:

Manager - Status: Unexpected error. Please, report this error.

The only hint i've found was within the api.log:

WazuhAPI 2018-02-11 20:34:33: [::ffff:192.168.0.1] GET /decoders/?offset=0&limit=1 - 200 - error: '1501'.

which has lead me to the changes to the decoder i had done today. And indeed the decoder had wrong permissions like:

-rw-r----- 1 root root 4301 Feb 11 16:49 0450-openvas_decoders.xml

instead of the expected:

-rw-r----- 1 root ossec 4301 Feb 11 16:49 0450-openvas_decoders.xml

I think catching this "1501" error in some way and making the user aware that there might be some permission errors might be useful instead of the plain "Unexpected error" currently thrown.

Hi,

Not sure if this is API or Manager related. However, we've been using Wazuh v2.0 for about 2 weeks now and today when we loaded up the manager logs page in the app we were greeted the the above kibana error.

The full Kibana log shows this:
{"type":"log","@timestamp":"2017-03-23T13:44:59Z","tags":["\u001b[34mwazuh\u001b[39m","client","error"],"pid":6744,"message":"Could not connect with Wazuh API. Error: socket hang up. Please, check the URL at settings tab."}

The API log when tailed at the same time shows this:

WazuhAPI 2017-03-23 13:44:54: [::ffff:127.0.0.1] GET /manager/logs? - 200 - error: '0'.
WazuhAPI 2017-03-23 13:44:54: [::ffff:127.0.0.1] GET /manager/logs?offset=0&limit=250 - 200 - error: '0'.
WazuhAPI 2017-03-23 13:44:59: [::ffff:127.0.0.1] GET /manager/logs/summary? - 200 - error: '0'.

Whereas the successful attempt looks like this:

WazuhAPI 2017-03-23 13:47:00: [::ffff:127.0.0.1] GET /manager/logs?offset=0&limit=250 - 200 - error: '0'.
WazuhAPI 2017-03-23 13:47:00: [::ffff:127.0.0.1] GET /manager/logs/summary? - 200 - error: '0'.
WazuhAPI 2017-03-23 13:47:00: [::ffff:127.0.0.1] GET /manager/logs?category=all&type_log=all&offset=0&limit=250 - 200 - error: '0'.
WazuhAPI 2017-03-23 13:47:09: [::ffff:127.0.0.1] GET /manager/logs?category=all&type_log=all&offset=101&limit=250 - 2 00 - error: '0'.
WazuhAPI 2017-03-23 13:47:10: [::ffff:127.0.0.1] GET /manager/logs?category=all&type_log=all&offset=0&limit=250 - 200 - error: '0'.

So it looks as if the API response maybe hangs?

The way we fixed this was to move the current ossec.log file to ossec.log.bak and restart the manager to generate a clean log file.

This fixed the issue for us and maybe shows that once the log file grows to a certain size the api call from the Kibana app times out.

Not sure which it may be but if you need more logs let me know :)

Thanks,
Steve

Hi guys, just noticed about a detail on the /agents/{id} request. I know this could be on the wazuh/wazuh, any case my question is if we can fetch the real IP whenever an agent has been configured using any as IP using the /agents/{id} route.

Example:

{
   "error": 0,
   "data": {
      ...
      "ip": "any",
      ...
   }
}

If you configure it using any and/or using authd you'll see that output.

Best,
Jesús

Steps to reproduce

Setup

The FQDN of the host running wazuh-manager is manager.local.

curl -u foo:bar -k -X GET "https://127.0.0.1:55000/agents?pretty"
{
   "error": 0,
   "data": {
      "totalItems": 2,
      "items": [
         {
            "status": "Active",
            "ip": "127.0.0.1",
            "id": "000",
            "name": "manager.local"
         },
         {
            "status": "Active",
            "ip": "any",
            "id": "001",
            "name": "agent1.local"
         }
      ]
   }
}

What happened

Then we try to add an agent with the same hostname.

curl -u foo:bar -k -X PUT "https://127.0.0.1:55000/agents/manager.local?pretty"
{
   "error": 0,
   "data": "002"
}

curl -u foo:bar -k -X GET "https://127.0.0.1:55000/agents?pretty"
{
   "error": 0,
   "data": {
      "totalItems": 3,
      "items": [
         {
            "status": "Active",
            "ip": "127.0.0.1",
            "id": "000",
            "name": "manager.local"
         },
         {
            "status": "Active",
            "ip": "any",
            "id": "001",
            "name": "agent1.local"
         },
         {
            "status": "Never connected",
            "ip": "any",
            "id": "002",
            "name": "manager.local"
         }
      ]
   }
}

Result is the same if I use POST method of adding an agent.

Expected

To get an error that agent already exists

Trying to create an agent through the API with POST so that I can define the IP at the same tame always gives me this error.

{
  "error": "601",
  "response": null,
  "message": "Param not valid. Valid characters: a-z, A-Z, 0-9, ., _, -,/,\. Field: agent_name"
}

The body is

 name:server01
 ip:192.168.1.1

Is my formatting wrong of the body?

I've installed Wazuh onto Ubuntu 16.04.4. Most of it has gone pretty well up until logging into the browser and adding the API. There are 4 things to enter: Username, password, address, and port. No matter what username and password I use, as long as the address and port are correct, I get "Settings. Wazuh API throws socket hang up". If I put the wrong port I get "Settings. Wrong Wazuh API port, please check it and try again" so it appears there is communication. I've reset the password so I know the credentials are correct.

What do I need to do to figure this out?

Thanks in advance.

I get this error when i try to run 'api-register-agent.ps1'.

Pls advice

Creating a new host via the REST api with ANY as ip-address will crash wazuh-modulesd.
ANY is an allowed value according to the docs.
Restarting this service does not fix the problem.

example:

$ curl -u foo:bar -k -X POST -d '{"name":"NewHost","ip":"ANY"}' -H 'Content-Type:application/json' "http://127.0.0.1:55000/agents?pretty"

{
   "error": 0,
   "data": "003"
}

To get wazuh-modulesd running again, i deleted the new entry from /var/ossec/etc/client.keys and restarted the service.

Findings

I tried the POST /agents/:name endpoint because it inserts ANY into the 'ip' -field.
This didn't crash the service.

The working entry in client.keys looks like this:
003 myNewAgent any 42ab5b029044ab295a45837da5776570003b7166d32c1373fe54992beb4dd7d5
The breaking entry looks like this:
003 myNewAgent ANY 42ab5b029044ab295a45837da5776570003b7166d32c1373fe54992beb4dd7d5

Solution

I found [input_validation.js](https://github.com/wazuh/wazuh-api/blob/master/helpers/input_validation.js.
Removing the last entry from the 'ips' regex solves the problem, but only allows 'any' as input value.
I have not made a pull-request because i don't know if this is the best solution to the problem.

Hi,

currently running the following setup:

Debian jessie 8.7
Python 2.7.9
wazuh-manager 2.0-1jessie
wazuh-api: 2.0-1jessie

After following the complete setup tutorial everything working so far except i'm getting the following errors shown in the Kibana -> Wazuh -> Manager Dashboards "Status", "Ruleset" and "Configuration":

Manager - Status: Wazuh API returned an error message. Error: Error getting configuration.
Manager - Rules: Wazuh API returned an error message. Error: Error getting configuration.
Manager - Configuration: Wazuh API returned an error message. Error: Error getting configuration.

When raising the debug level of the API the following logentries are found:

WazuhAPI 2017-06-04 16:01:22: ::ffff:xxx.yyy.zzz GET /rules
WazuhAPI 2017-06-04 16:01:22: CMD - Command: python args:/var/ossec/api/models/wazuh-api.py stdin:{"function":"/rules","arguments":{},"ossec_path":"/var/ossec"}
WazuhAPI 2017-06-04 16:01:22: CMD - Exit code: 0
WazuhAPI 2017-06-04 16:01:22: CMD - STDOUT:
---
{"message": "Error getting configuration.", "error": 1101}

---
WazuhAPI 2017-06-04 16:01:22: CMD - STDOUT: 59 bytes
WazuhAPI 2017-06-04 16:01:22: [::ffff:xxx.yyy.zzz] GET /rules/? - 200 - error: '1101'.

WazuhAPI 2017-06-04 16:04:20: ::ffff:xxx.yyy.zzz GET /manager/configuration
WazuhAPI 2017-06-04 16:04:20: CMD - Command: python args:/var/ossec/api/models/wazuh-api.py stdin:{"function":"/manager/configuration","arguments":{},"ossec_path":"/var/ossec"}
WazuhAPI 2017-06-04 16:04:20: CMD - STDOUT:
---
{"message": "Error getting configuration.", "error": 1101}

---
WazuhAPI 2017-06-04 16:04:20: CMD - Exit code: 0
WazuhAPI 2017-06-04 16:04:20: CMD - STDOUT: 59 bytes
WazuhAPI 2017-06-04 16:04:20: [::ffff:xxx.yyy.zzz] GET /manager/configuration? - 200 - error: '1101'.


WazuhAPI 2017-06-04 16:10:48: ::ffff:xxx.yyy.zzz GET /rules
WazuhAPI 2017-06-04 16:10:48: CMD - Command: python args:/var/ossec/api/models/wazuh-api.py stdin:{"function":"/rules","arguments":{"offset":"0","limit":"1"},"ossec_path":"/var/ossec"}
WazuhAPI 2017-06-04 16:10:49: CMD - Exit code: 0
WazuhAPI 2017-06-04 16:10:49: CMD - STDOUT:
---
{"message": "Error getting configuration.", "error": 1101}

---
WazuhAPI 2017-06-04 16:10:49: CMD - STDOUT: 59 bytes
WazuhAPI 2017-06-04 16:10:49: [::ffff:1xxx.yyy.zzz] GET /rules/?offset=0&limit=1 - 200 - error: '1101'.
WazuhAPI 2017-06-04 16:10:49: CMD - Exit code: 0

Those seems to be the only two URLs / calls causing such an error. All other API calls / URLS like /manager/logs?category=all&type_log=all&offset=0&limit=250 - 200 - error: '0'. are not throwing such errors.

Unfortunately its not really clear what Error getting configuration. means and how to solve this from user side.

Could it be possible to extend this message to have a little bit more context?

Anything what needs to be done here from user-side to fix this?

Thanks in advance for a reply.

Hi,
I've been encountering a race condition between registering the agent and immediately trying to get the key. I assume this happens since authd will take a bit of time to write the file, but wazuh-api just read client.keys to get the key. That leads the the following situation:

$ curl -u foo:bar -k -X POST -d 'name=NewAgent&ip=10.0.0.8' https://API_IP:55000/agents
{"error":0,"data":"001"}
$ curl -u foo:bar -k -X GET https://API_IP:55000/agents/001/key
{"error":1701,"message":"Agent does not exist: 001"}

I could wait between the two calls but that is not a good solution. Alternative, perhaps the API can return the key in the response when adding an agent and make the whole process a single API call.

Not using authd is not an option due to #26

Hi Folks, i'm following the examples from here and according to the documentation, this is the method to get outdated agents:

curl -u foo:bar -X GET -k "http://127.0.0.1:55000/agents/outdated?pretty"

However, when we run it, we get below response:

curl -u user:token -X GET -k "https://serverip:portnumber/agents/outdated?pretty"
{

   "error": 600,
   "message": "Param not valid. Integer expected.  Field: agent_id"

}

Note that we used surrogate values in below request for example purposes.

Can you please advise what might be wrong here?

https://github.com/aol/moloch
this would be a nice tool to bridge into the Centos 7 VM. working on and or packetbeats file beats etc.
https://github.com/StamusNetworks/SELKS nextgen devs @ HPE.com like centos...
https://github.com/StamusNetworks/scirius
https://github.com/inliniac/suricata

however down the road , it would bolster things as a full suite of products.

A call to host_to_api:55000/manager/logs returns something like this:

{
  "error": 0,
  "data": {
    "totalItems": 2,
    "items": [
      "2017\/10\/14 15:48:24 ossec-remoted: WARNING: (1213): Message from '10.0.0.221' not allowed.",
      "2017\/10\/14 15:48:18 ossec-remoted: WARNING: (1213): Message from '10.0.0.221' not allowed.",
    ]
  }
}

The output in a JSON format would be something like (this is an example structure, actually there's already a defined one in the ossec.json, should follow that one):

{
   "error": 0,
   "data": {
      "totalItems": 2,
      "items": [
         {
            "timestamp": 2017\/10\/14 15:48:24,
            "daemon": "ossec-remoted",
            "message": "WARNING: (1213): Message from '10.0.0.221' not allowed."
         },
         {
            "timestamp": 2017\/10\/14 15:48:18,
            "daemon": "ossec-remoted",
            "message": "WARNING: (1213): Message from '10.0.0.221' not allowed."
         }
      ]
   }
}

Hello team, what I meant with the title is the next scenario:

• If my search is using "002" you are using 2, I think because you are parsing to integer or something similar. But if I search for "002" maybe I'm looking for specific items not all items whose include 2.

From my view this shouldn't be so hard to fix and makes sense.

Regards,
Jesús

Hi team,

Since this commit: 0a8cf7be7d28dc121f2c13c33a12868f51b23c23
there exists a new table in the agents' databases to store the CIS-CAT stats of the scans.

For Wazuh v3.3.0, we would new a new API call to retrieve that data from the DB.

Thanks!

Here's the relevant output from journalctl -u wazuh-api:

Apr 26 16:21:06 barricades nodejs[14466]: /var/ossec/api/app.js:113
Apr 26 16:21:06 barricades nodejs[14466]: auth_secure.on('fail', (result, req) => {
Apr 26 16:21:06 barricades nodejs[14466]: ^
Apr 26 16:21:06 barricades nodejs[14466]: TypeError: Cannot read property 'on' of undefined
Apr 26 16:21:06 barricades nodejs[14466]: at Object.<anonymous> (/var/ossec/api/app.js:113:12)
Apr 26 16:21:06 barricades nodejs[14466]: at Module._compile (module.js:570:32)
Apr 26 16:21:06 barricades nodejs[14466]: at Object.Module._extensions..js (module.js:579:10)
Apr 26 16:21:06 barricades nodejs[14466]: at Module.load (module.js:487:32)
Apr 26 16:21:06 barricades nodejs[14466]: at tryModuleLoad (module.js:446:12)
Apr 26 16:21:06 barricades nodejs[14466]: at Function.Module._load (module.js:438:3)
Apr 26 16:21:06 barricades nodejs[14466]: at Module.runMain (module.js:604:10)
Apr 26 16:21:06 barricades nodejs[14466]: at run (bootstrap_node.js:393:7)
Apr 26 16:21:06 barricades nodejs[14466]: at startup (bootstrap_node.js:150:9)
Apr 26 16:21:06 barricades nodejs[14466]: at bootstrap_node.js:508:3
Apr 26 16:21:06 barricades systemd[1]: wazuh-api.service: main process exited, code=exited, status=1/FAILURE

PR incoming.

Hello team,

The API request GET/agents returns all available information by default:

# curl -u foo:bar "localhost:55000/agents?pretty&limit=1&offset=1"
{
   "error": 0,
   "data": {
      "totalItems": 4,
      "items": [
         {
            "status": "Disconnected",
            "configSum": "ab73af41699f13fdd81903b5f23d8d00",
            "group": "default",
            "name": "perico",
            "mergedSum": "d9835ca466a5f6ede52e0684537f76bd",
            "ip": "any",
            "node_name": "node02",
            "dateAdd": "2018-06-04 15:17:28",
            "version": "Wazuh v3.2.4",
            "manager_host": "localhost.localdomain",
            "lastKeepAlive": "2018-06-05 18:33:59",
            "os": {
               "major": "7",
               "name": "CentOS Linux",
               "uname": "Linux |localhost.localdomain |3.10.0-693.el7.x86_64 |#1 SMP Tue Aug 22 21:09:27 UTC 2017 |x86_64",
               "platform": "centos",
               "version": "7",
               "codename": "Core",
               "arch": "x86_64"
            },
            "id": "001"
         }
      ]
   }
}

This makes the select parameter only serve for reducing information. Also, if there are lots of agents the result is very big and it's harder to read.

I think we should define which fields to return by default.

Best regards,
Marta

Steps to replicate:

1. Have empty line in clients.keys
2. Attempt to add an agent via the API

$ curl -u user:pass -k -X POST -d 'name=MyAgent&ip=1.2.3.4' http://API_HOST:55000/agents
{"error":1000,"message":"Wazuh-Python Internal Error: invalid literal for int() with base 10: ''"}

Issue is located at

The code on line 465 fails to filter out empty lines ending with line 470 trying to do int('\n')

Seeing something weird after upgrading to 2.1.0 -- seems like the delete endpoint is breaking ID's into individual strings, quite weird.

curl -X DELETE http://abc.123.net:55000/agents/208 -H 'authorization: Basic ABC123'

{
    "error": 0,
    "data": {
        "msg": "Some agents were not removed",
        "ids": [
            "2",
            "0",
            "8"
        ]
    }
}

Hello!
I met a problem, I click on the ADD NEW API error in Kibana:
Unexpected error. Wazuh - Python Internal error: Wazuh - framework is not found.

Wazuh-API error log is as follows:

WazuhAPI 17:05:06:2017-05-31: : FFFF: 192.168.162.58 GET/agents / : agent_id
WazuhAPI 17:05:06:2017-05-31 CMD -command: python args: / var/ossec/API/models/wazuh - API. Py stdin: {" function ":"/agents / : agent_id ", "the arguments" : {" agent_id ":" 000 "}, "ossec_path" : "/ var/ossec"}
WazuhAPI 17:05:06 2017-05-31: CMD - Exit code: 0
WazuhAPI 17:05:06:2017-05-31 CMD - STDOUT:
-- -- --
{" message ":" Wazuh - Python Internal Error: Wazuh - framework is not found. ", "Error" : 1000}
-- -- --
WazuhAPI 17:05:06:2017-05-31 CMD - STDOUT: 86 bytes
WazuhAPI 2017-05-31 17:05:06: [: : FFFF: 192.168.162.58] GET/agents / 000?- 200 - error: '1000'.

HI,

I have this error:

root@wazuh01:/var/ossec/api/configuration/auth# sudo node htpasswd -c user wazuh
path.js:1142
cwd = process.cwd();
^

Error: ENOENT: no such file or directory, uv_cwd
at Error (native)
at Object.resolve (path.js:1142:25)
at startup (bootstrap_node.js:127:32)
at bootstrap_node.js:504:3

I have install nodejs and wazuh-api too wazuh-manager

Can you to do, please?

Thx

Hi,
I am working on getting ossec wazuh running inside a Kubernetes cluster. Inside Kubernetes we use a self-signed certificate. We need to a way to pass the ca cert to the api server. I added a commit like
https://github.com/appscode/wazuh-API/commit/ddf951acdefbedea996670c49e694b94482f42ef

in my fork. Can this be supported here, so that I can delete my fork?

Thanks.

Hi team,

if you restart the wazuh-api with systemctl restart wazuh-api.service, and then you check the status of the service, the wazuh-api.services exited with exit code 1 and then it restarts successfully.

[root@manager ~]# systemctl status wazuh-api
● wazuh-api.service - Wazuh API daemon
   Loaded: loaded (/etc/systemd/system/wazuh-api.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2018-05-21 12:38:51 UTC; 1 weeks 5 days ago
     Docs: http://wazuh-documentation.readthedocs.org/en/latest/ossec_api.html
 Main PID: 21358 (node)
   CGroup: /system.slice/wazuh-api.service
           └─21358 /bin/node /var/ossec/api/app.js

            --> May 21 12:38:51 manager systemd[1]: wazuh-api.service: main process exited, code=exited, status=1/FAILURE
Check this |--> May 21 12:38:51 manager systemd[1]: Unit wazuh-api.service entered failed state.
            --> May 21 12:38:51 manager systemd[1]: wazuh-api.service failed.
May 21 12:38:51 manager systemd[1]: Started Wazuh API daemon.
May 21 12:38:51 manager systemd[1]: Starting Wazuh API daemon...

It happens the same when you stop the wazuh-api.service, so, maybe, something is wrong with the wazuh-api.service file.

Regards,
Braulio.

Hi! I found an error in the API when I was trying the "search" filter.

We can find agents if we insert the name or the ID, but the ID only works when you type the same number as the stored in the DB.

This is not very functional, as the users always see the ID with zeros ("001" instead of just "1").

# curl -u centos:centos -k -X GET "https://192.168.56.104:55000/agents/groups/default?pretty&search=1"
{
   "error": 0,
   "data": {
      "totalItems": 1,
      "items": [
         {
            "merged_sum": "61d689c2e2e7a7a678756f89b4fc0a35",
            "os_name": "CentOS Linux",
            "last_keepalive": "2017-11-02 10:07:52",
            "ip": "192.168.56.101",
            "os_version": "007",
            "version": "Wazuh v3.0.0-beta10",
            "config_sum": "ab73af41699f13fdd81903b5f23d8d00",
            "manager_host": "localhost.localdomain",
            "os_platform": "centos",
            "id": "001",
            "name": "AgenteUno"
         }
      ]
   }
}
# curl -u centos:centos -k -X GET "https://192.168.56.104:55000/agents/groups/default?pretty&search=001"
{
   "error": 0,
   "data": {
      "totalItems": 0,
      "items": []
   }
}

Best regards!
Juanjo

Hi ,

GET /agents/groups/:group_id route returns the following error message when '?sort=' argument is used with any value:

{"error":1000,"message":"Wazuh-Python Internal Error: 'set' object has no attribute '__getitem__'"}

Thanks team

According to documentation I executed:

$curl -s -o install_api.sh https://raw.githubusercontent.com/wazuh/wazuh-api/2.0/install_api.sh \

&& bash ./install_api.sh download

The output I get:

Wazuh API

Downloading API from https://github.com/wazuh/wazuh-api/archive/v2.0.tar.gz

Installing Wazuh API 2.0.0

Installing API ['/var/ossec/api'].

Installing SQLite library.
Error executing command: 'gcc -pipe -O2 -shared -fPIC -o /var/ossec/api/framework/lib/libsqlite3.so.0 framework/database/sqlite3.c'.

Exiting.

Facts:

OS Ubuntu 14.04.4 LTS
libsqlite3 package is installed 3.8.2-1ubuntu2.1
/var/ossec/api/framework/lib/ directory is empty
/var/ossec/api/framework/database directory doesn't exist
nodejs version is v6.11.0

Hello team,

curl foo:bar@localhost:55000/rules?offset=99999
{"error":1400,"message":"Invalid offset."}

I know this is an invalid offset but now take a look at the next command:

curl foo:bar@localhost:55000/agents?offset=99999
{"error":0,"data":{"totalItems":6,"items":[]}}

Different result for two iterable lists. From the App team we desire the second result, it means no error and empty array.

Best regards,
Jesús

Featured files' MD5 returned by API does not match the actual MD5 of those files:

/var/ossec/etc# find . -name "merged.mg" -o -name "agent.conf" | xargs md5sum
81ba8a30c5d37ac05f219746dcf8793f  ./hello/merged.mg
ab73af41699f13fdd81903b5f23d8d00  ./default/agent.conf
6842791efc7d34e3248f08f5536a3102  ./default/merged.mg

# curl -X GET -u foo:bar localhost:55000/agents/groups?pretty
{
   "error": 0,
   "data": {
      "totalItems": 2,
      "items": [
         {
            "count": 0,
            "conf_sum": "d497a2fc9b24c39ce80b9d28eae5063f",
            "merged_sum": "aba93316a67e2bd60ed69013fab5cf13",
            "name": "default"
         },
         {
            "count": 1,
            "conf_sum": "8037020d132c66cf0033aa48797b5a5e",
            "merged_sum": "81ba8a30c5d37ac05f219746dcf8793f",
            "name": "hello"
         }
      ]
   }
}

In fact, group hello had no file called agent.conf.

Branch 3.0-beta.

i register agent via sh api but finsh with erros ->

2017/04/27 11:10:46 ossec-agentd(1237): ERROR: Invalid ip address: 'MANAGER_IP'.
2017/04/27 11:10:46 ossec-agentd(1202): ERROR: Configuration error at ''. Exiting.
2017/04/27 11:10:46 ossec-agentd(1215): ERROR: No client configured. Exiting.

server debian 8.7.1 and agents debian 8.7.1

after set ip server in /var/ossec/etc/ossec.conf and var/ossec/bin/ossec-control restart

list agent it ok and active

When I want to grab agent details, or key, I need to know the agent id. It would be helpful if all that information can be looked up by hostname instead for the purpose of automated registration using something like salt, puppet, etc.

Currently, you have to workaround that by getting a list of all the agents, looking up the hostname to get the agent id, and then getting agent details, or key.