Closed roronoasins closed 1 year ago
Today I was not able to connect an agent with the engine to start the testing using the agent
2022/10/25 16:38:52 wazuh-authd: INFO: Agent key generated for 'engine-agent' (requested by any)
2022/10/25 16:39:11 wazuh-agentd: INFO: Trying to connect to server (192.168.0.101:1514/tcp).
2022/10/25 16:40:21 wazuh-agentd: INFO: Closing connection to server (192.168.0.101:1514/tcp).
2022/10/25 16:40:21 wazuh-agentd: INFO: Trying to connect to server (192.168.0.101:1514/tcp).
2022/10/25 16:41:31 wazuh-agentd: INFO: Closing connection to server (192.168.0.101:1514/tcp).
The engine receive the incoming events in
alerts-ECS.json
First, to be able to send the events to the engine, we need to create a localfile section in the agent's side using its
ossec.conf
.<localfile> <log_format>syslog</log_format> <location>/var/log/engine.log</location> </localfile>
original
field contains the specified log :green_circle:location
field contains the specified string :red_circle:queue
field contains the corresponding (decimal) ascii value from the specified string :yellow_circle:kvdb
subcommandThe events and cmd parameters were done but some cases are missing:
env
command for cmd parameters (waiting for testing custom ruleset so the custom env management could be tested)These cases will be done along with the other checks required within this issue https://github.com/wazuh/wazuh-qa/issues/3537
catalog
commandlist
:yellow_circle: get
:green_circle:update
:red_circle:item-type
:red_circle:create
:yellow_circle:delete
:yellow_circle:validate
:yellow_circle:sources
section :green_circle:check
section :green_circle:parse
section :green_circle:load
:yellow_circle:kvdb
command-i/--input-file
:yellow_circle:-t/--input-type
:yellow_circle:During the testing process we could test the following cases:
Events' inputs
Using the agent localfile feature
Sending valid json format log :green_circle:
Sending a log that contains unicode characters :green_circle:
Sending a log with expected syslog format :green_circle:
Sending a log with non-desired log format :green_circle:
Sending a mix of unicode and special characters log :green_circle:
Using wazuh-engine test command
Verify that original
field contains the specified log :green_circle:
Verify that location
field contains the specified string :red_circle:
Verify that queue
field contains the corresponding (decimal) ascii value from the specified string :yellow_circle:
API
catalog
commandlist
parameter :yellow_circle:
get
parameter
update
parameter
create
parameter
delete
parameter
validate
parameter
load
parameter
kvdb
command-i/--input-file
parameter
-t/--input-type
Error logs that are not that descriptive for a user:
Referencing the store
files
Error: [Catalog] Could not get content [rule] from store, [FileDriver] File [/var/ossec/engine/store/rule] does not exist
These logs appear for these cases:
item-type
item-type
delete
without an item-type
at least. The log refers to name
when it can confuse an user because it is the error log when there is something happening, for example, with the name of a decoder(defined in its yaml file). And here the user may try to delete all the possible combinations by just running the delete option. The --help
advice is good, but the name
reference may confuse the useritem-type
Uncompleted logging
Error: Invalid collection type [newtype]
or
Could not convert: --protocol_queue = 128
Run with --help for more information.
These logs appear for these cases:
item-type
JSON wrong format
10:44:00.649499 cmdKvdb.cpp:77 ERR[3870 ] Error parsing JSON: exception: [Json(jsonString)] Unable to build json document because: Invalid encoding in string. at 33
We could add some logging to the stack trace so the last logging message is more user-friendly.
These logs appear for these cases:
Unsupported type
--input_type: yaml not in {json}
This log can be improved so the log do not seem to be a conditional fragment from a source code.
These logs appear for these cases:
Rename the kvdb's -i
option:
The format used for --input-type
is -t
, so we could use the same format.
Check that validation is correct: Is there a way to have a trace of the checks that it performs to know if the validate went good? If not, could we add it?
The catalog list
command must have default rules and filter.
Helper of catalog command:
A clarification about item-type values expected could be usefull, so the users can have detailed info without run the tool and getting errors.
We could also add a reference to the engine's wiki based on the command. For example, if we use the help option with the whole engine, a reference to the index or very first page of wiki. If we use the help option with a command, a reference to the command's entry.
Location being splitted
When the location contains at least a colon, the substring that take place after that colon appears as part of the original log. There is also an aditional colon where this substring and the log are combined.
Input:
root@engine:/home/vagrant/engine/wazuh/src/engine# ./build/main test -l "location:asd"
Current output:
Enter log in single line (Crtl+C to exit):
a sample log
OUTPUT:
{
"wazuh": {
"queue": 49,
"origin": "location"
},
"event": {
"original": "asd:a sample log"
}
}
Expected output:
Enter log in single line (Crtl+C to exit):
a sample log
OUTPUT:
{
"wazuh": {
"queue": 49,
"origin": "location:asd"
},
"event": {
"original": "a sample log"
}
}
Uncorrect logs
Current output
Error: Invalid collection type [newtype] for [error_type]
Expected output
Fix the string error_type
and print the supported item-types
. It could contains a reference to the help option instead (or both).
These logs appear for these cases:
item-type
Description
Since the team is reworking the engine, we need to cover this new engine rework. This issue will test the new engine to ensure all is correct.
Proposed test cases