Add a software limit to limit the amount of EPS that a manager can process

[cborla]

Target version	Related issue	Related PR
4.4	12512 13572	https://github.com/wazuh/wazuh/pull/13608

Description

In order to validate the changes of the branch https://github.com/wazuh/wazuh/tree/dev-cloud-limits, some manual testing is required.

As part of https://github.com/wazuh/wazuh/issues/12512, a new mechanism has been created to limit the amount of EPS than a manager can process.

This mechanism is implemented within the wazuh-analysisd daemon and works by using a circular buffer that tracks the total number of events over a defined period of time.

Whenever the circular buffer fills up, the events are held within the related queues until some space is freed. This works like a moving average, this is to support event spikes.

In this first iteration, main configuration will be located in global section from ossec.conf file. Link to documentation.

Configuration

ossec.conf

<global>
  <limits>
    <eps>
      <maximum>500</maximum>
      <timeframe>30</timeframe>
    </eps>
  </limits>
</global>

Events per second (EPS) limitation is disabled by default.

Logs

EPS functionality disabled:

2022/07/13 17:31:46 wazuh-analysisd: INFO: EPS limit disabled

EPS functionality enabled:

2022/07/13 17:31:46 wazuh-analysisd: INFO: EPS limit enabled, EPS: '500', timeframe: '30'

Feature validation

State files could be useful to check if EPS limits are working properly.

cat /var/ossec/var/run/wazuh-analysisd.state 
# State file for wazuh-analysisd

# Total events decoded
total_events_decoded='0'

# Syscheck events decoded
syscheck_events_decoded='0'
syscheck_edps='0'

# Syscollector events decoded
syscollector_events_decoded='0'
syscollector_edps='0'

# Rootcheck events decoded
rootcheck_events_decoded='0'
rootcheck_edps='0'

# Security configuration assessment events decoded
sca_events_decoded='0'
sca_edps='0'

# Hostinfo events decoded
hostinfo_events_decoded='0'
hostinfo_edps='0'

# Winevt events decoded
winevt_events_decoded='0'
winevt_edps='0'

# Database synchronization messages dispatched
dbsync_messages_dispatched='0'
dbsync_mdps='0'

# Other events decoded
other_events_decoded='0'
other_events_edps='0'

# Events processed (Rule matching)
events_processed='0'
events_edps='0'

# Events received
events_received='0'

# Events dropped
events_dropped='0'

# Alerts written to disk
alerts_written='0'

# Firewall alerts written to disk
firewall_written='0'

# FTS alerts written to disk
fts_written='0'

# Syscheck queue
syscheck_queue_usage='0.00'

# Syscheck queue size
syscheck_queue_size='16384'

# Syscollector queue
syscollector_queue_usage='0.00'

# Syscollector queue size
syscollector_queue_size='16384'

# Rootcheck queue
rootcheck_queue_usage='0.00'

# Rootcheck queue size
rootcheck_queue_size='16384'

# Security configuration assessment queue
sca_queue_usage='0.00'

# Security configuration assessment queue size
sca_queue_size='16384'

# Hostinfo queue
hostinfo_queue_usage='0.00'

# Hostinfo queue size
hostinfo_queue_size='16384'

# Winevt queue
winevt_queue_usage='0.00'

# Winevt queue size
winevt_queue_size='16384'

# Database synchronization message queue
dbsync_queue_usage='0.00'

# Database synchronization message queue size
dbsync_queue_size='16384'

# Upgrade module message queue
upgrade_queue_usage='0.00'

# Upgrade module message queue size
upgrade_queue_size='16384'

# Event queue
event_queue_usage='0.00'

# Event queue size
event_queue_size='16384'

# Rule matching queue
rule_matching_queue_usage='0.00'

# Rule matching queue size
rule_matching_queue_size='16384'

# Alerts log queue
alerts_queue_usage='0.00'

# Alerts log queue size
alerts_queue_size='16384'

# Firewall log queue
firewall_queue_usage='0.00'

# Firewall log queue size
firewall_queue_size='16384'

# Statistical log queue
statistical_queue_usage='0.00'

# Statistical log queue size
statistical_queue_size='16384'

# Archives log queue
archives_queue_usage='0.00'

# Archives log queue size
archives_queue_size='16384'

IMPORTANT: After merging these changes, the new API endpoints should be used to check manager stats.

Test cases

For the following tests, always use the same type of events (for example, dbsync) so that they are directed to the same queue. Also, keep in mind that this mechanism works like a moving average (freeing up some space every second), so the results may not always be exactly the same because they depend on the second the events reach the manager, so it should be better to compare between ranges of expected values instead of exact values.

• [x] Tests cases fresh install

  • [x] Check that wazuh-analysisd stops processing events when the limit is reached. For example, if the eps is 50 and the timeframe is 30, it should stop processing events when reaching 1500 in the last 30 seconds (timeframe) until the moving average frees up some space.

  • [x] Check that wazuh-analysisd starts queuing events when the limit is reached and the corresponding queue is not full. For example, if the eps is 50 and the timeframe is 30, it should start queuing events after reaching 1500 in the last 30 seconds (timeframe) and the corresponding queue is not full until the moving average frees up some space.

  • [x] Check that wazuh-analysisd starts dropping events when the limit is reached and the corresponding queue is full. For example, if the eps is 50 and the time frame is 30, it should start discarding events when reaching 1500 in the last 30 seconds (timeframe) and the corresponding queue is full until the moving average frees up some space.

  • [x] Check that wazuh-analysisd processes queued events first instead of new events when the moving average frees up some space. For example, if the eps is 50 and the time frame is 30, it should start processing queued events after freeing up a slot of the 1500 events from the last 30 seconds (timeframe) instead of new events (which are sent to the end of the queue).

  • [x] Check that wazuh-analysisd works as olders versions if the eps is 0.

  • [x] Test the new configuration block.

• [x] Tests cases upgrade from 4.3.6 to 4.4.0

  • [x] Check that wazuh-analysisd stops processing events when the limit is reached. For example, if the eps is 50 and the timeframe is 30, it should stop processing events when reaching 1500 in the last 30 seconds (timeframe) until the moving average frees up some space.

  • [x] Check that wazuh-analysisd starts queuing events when the limit is reached and the corresponding queue is not full. For example, if the eps is 50 and the timeframe is 30, it should start queuing events after reaching 1500 in the last 30 seconds (timeframe) and the corresponding queue is not full until the moving average frees up some space.

  • [x] Check that wazuh-analysisd starts dropping events when the limit is reached and the corresponding queue is full. For example, if the eps is 50 and the time frame is 30, it should start discarding events when reaching 1500 in the last 30 seconds (timeframe) and the corresponding queue is full until the moving average frees up some space.

  • [x] Check that wazuh-analysisd processes queued events first instead of new events when the moving average frees up some space. For example, if the eps is 50 and the time frame is 30, it should start processing queued events after freeing up a slot of the 1500 events from the last 30 seconds (timeframe) instead of new events (which are sent to the end of the queue).

  • [x] Check that wazuh-analysisd works as olders versions if the eps is 0.

  • [x] Test the new configuration block.

    Note: This issue is blocked by https://github.com/wazuh/wazuh/issues/13077

[CamiRomero]

Some tasks remain pending for qa to carry out its tests:

• Some checks were not successful in branch Cloud limits. Check Wazuh CI.
• The Issue Add API protection option for new eps limit configuration is not closed.

Also, could you check our template for new Issue?

In this template we define a list of items that are necessary and facilitate our work

[Deblintrake09]

Note: This issue is blocked by https://github.com/wazuh/wazuh/issues/13077

[damarisg]

It is closed because it is being worked on https://github.com/wazuh/wazuh-qa/issues/2947

[CamiRomero]

Review data

Tester	PR commit
@CamiRomero	032cc7

Testing environment

OS	OS version	Deployment	Image/AMI	Notes
Centos	8	AWS	ami-029496e60f56b4b13

Tested packages

wazuh-manager	wazuh-agent
4.4.0	-

Status

• [x] In progress
• [x] Pending Review
• [x] Team leader approved
• [x] Manager approved

Conclusion 🟡

It proposed two improvements:

• https://github.com/wazuh/wazuh/issues/14665
• https://github.com/wazuh/wazuh/issues/14666

It was discussed with the development team and we decided to improve these issues in another PR.

[CamiRomero]

Tests cases fresh install

Prerequisites

1. Download and install Wazuh 4.4.0: ``` curl -LO https://packages-dev.wazuh.com/warehouse/pullrequests/4.4/rpm/var/wazuh-manager-4.4.0-0.commit032cc76.x86_64.rpm yum install -y wazuh-manager-4.4.0-0.commit032cc76.x86_64.rpm systemctl daemon-reload systemctl enable wazuh-manager systemctl start wazuh-manager ```

Test the new configuration block :yellow_circle:

EPS functionality disabled :green_circle:

1. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/17 14:38:35 wazuh-analysisd: INFO: EPS limit disabled ```

EPS functionality enabled :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 500 30 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` 3. Check status of daemons: ``` /var/ossec/bin/wazuh-control status ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 4. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/17 14:54:51 wazuh-analysisd: INFO: EPS limit enabled, EPS: '500', timeframe: '30' ```

Check without maximum field :yellow_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 30 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` 3. Check status of daemons: ``` /var/ossec/bin/wazuh-control status ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 4. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/17 15:08:29 wazuh-analysisd: INFO: EPS limit disabled ``` Note: The value by default (0) is set correctly and the EPS limit is disabled. I suggest adding a Warning log to informing to users that EPS limit is disabled because is missing a maximum field.

Check without timeframe field :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 500 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` 3. Check status of daemons: ``` /var/ossec/bin/wazuh-control status ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 4. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/17 15:22:31 wazuh-analysisd: INFO: EPS limit enabled, EPS: '500', timeframe: '10' ``` Note: The value by default is set correctly

Check without timeframe and maximum field :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` 3. Check cause of error: ``` journalctl -xe ``` Output: ``` ago 17 15:33:15 ip-172-31-1-52.ec2.internal env[10771]: 2022/08/17 15:33:15 wazuh-maild: ERROR: (1230): Invalid element in the configuration: 'eps'. ago 17 15:33:15 ip-172-31-1-52.ec2.internal env[10771]: 2022/08/17 15:33:15 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. ago 17 15:33:15 ip-172-31-1-52.ec2.internal env[10771]: 2022/08/17 15:33:15 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ago 17 15:33:15 ip-172-31-1-52.ec2.internal env[10771]: wazuh-maild: Configuration error. Exiting ago 17 15:33:15 ip-172-31-1-52.ec2.internal systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 ago 17 15:33:15 ip-172-31-1-52.ec2.internal systemd[1]: wazuh-manager.service: Failed with result 'exit-code'.

Check with and extra field :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 500 30 30 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` 3. Check status of daemons: ``` /var/ossec/bin/wazuh-control status ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 4. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/17 15:42:35 wazuh-analysisd: INFO: EPS limit enabled, EPS: '500', timeframe: '30' ``` Note: The EPS limit was configured correctly but should we detect an extra field?

Check exceeding the maximum limit of maximum :yellow_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 100001 30 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` 3. Check cause of error: ``` journalctl -xe ``` Output: ``` ago 17 15:51:31 ip-172-31-1-52.ec2.internal env[12284]: 2022/08/17 15:51:31 wazuh-maild: ERROR: (1235): Invalid value for element 'maximum': 100001. ago 17 15:51:31 ip-172-31-1-52.ec2.internal env[12284]: 2022/08/17 15:51:31 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. ago 17 15:51:31 ip-172-31-1-52.ec2.internal env[12284]: 2022/08/17 15:51:31 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ago 17 15:51:31 ip-172-31-1-52.ec2.internal env[12284]: wazuh-maild: Configuration error. Exiting ago 17 15:51:31 ip-172-31-1-52.ec2.internal systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 ago 17 15:51:31 ip-172-31-1-52.ec2.internal systemd[1]: wazuh-manager.service: Failed with result 'exit-code'. ``` Note: I suggest modifying this behavior. I think that when we detect a maximum limit is exceeding we can add a Warning log to informing to users that the limit was exceeding and set up the field with the maximum value allowed (100000)

Check exceeding the maximum limit of timeframe :yellow_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 500 3601 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` 3. Check cause of error: ``` journalctl -xe ``` Output: ``` ago 17 16:00:45 ip-172-31-1-52.ec2.internal env[12324]: 2022/08/17 16:00:45 wazuh-maild: ERROR: (1235): Invalid value for element 'timeframe': 3601. ago 17 16:00:45 ip-172-31-1-52.ec2.internal env[12324]: 2022/08/17 16:00:45 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. ago 17 16:00:45 ip-172-31-1-52.ec2.internal env[12324]: 2022/08/17 16:00:45 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ago 17 16:00:45 ip-172-31-1-52.ec2.internal env[12324]: wazuh-maild: Configuration error. Exiting ago 17 16:00:45 ip-172-31-1-52.ec2.internal systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 ago 17 16:00:45 ip-172-31-1-52.ec2.internal systemd[1]: wazuh-manager.service: Failed with result 'exit-code'. ``` Note: I suggest modifying this behavior. I think that when we detect a maximum limit is exceeding we can add a Warning log to informing to users that the limit was exceeding and set up the field with the maximum value allowed (3600)

Check with value outside the lower limit :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 500 0 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` 3. Check cause of error: ``` journalctl -xe ``` Output: ``` ago 17 18:59:33 ip-172-31-1-52.ec2.internal env[14237]: 2022/08/17 18:59:33 wazuh-maild: ERROR: (1235): Invalid value for element 'timeframe': 0. ago 17 18:59:33 ip-172-31-1-52.ec2.internal env[14237]: 2022/08/17 18:59:33 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. ago 17 18:59:33 ip-172-31-1-52.ec2.internal env[14237]: 2022/08/17 18:59:33 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ago 17 18:59:33 ip-172-31-1-52.ec2.internal env[14237]: wazuh-maild: Configuration error. Exiting ago 17 18:59:33 ip-172-31-1-52.ec2.internal systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 ago 17 18:59:33 ip-172-31-1-52.ec2.internal systemd[1]: wazuh-manager.service: Failed with result 'exit-code'. ```

Check with invalid values :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 500 $ ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` 3. Check cause of error: ``` journalctl -xe ``` Output: ``` ago 17 16:07:25 ip-172-31-1-52.ec2.internal env[12518]: 2022/08/17 16:07:25 wazuh-maild: ERROR: (1235): Invalid value for element 'timeframe': $. ago 17 16:07:25 ip-172-31-1-52.ec2.internal env[12518]: 2022/08/17 16:07:25 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. ago 17 16:07:25 ip-172-31-1-52.ec2.internal env[12518]: 2022/08/17 16:07:25 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ago 17 16:07:25 ip-172-31-1-52.ec2.internal env[12518]: wazuh-maild: Configuration error. Exiting ago 17 16:07:25 ip-172-31-1-52.ec2.internal systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 ago 17 16:07:25 ip-172-31-1-52.ec2.internal systemd[1]: wazuh-manager.service: Failed with result 'exit-code'. ``` Note: The same test was executed for white spaces and negative numbers. For Maximum and timeframe field

--------------

Check that wazuh-analysisd stops processing events when the limit is reached :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 50 30 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 3. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 13:21:36 wazuh-analysisd: INFO: EPS limit enabled, EPS: '50', timeframe: '30' ``` 4. Generate logs with `simulate-agents` tool: ``` simulate-agents -a MANAGER_IP -n 1 -m logcollector -s 1000 ``` 5. Check State files: ``` events_processed='1000' events_received='1000' events_dropped='0' event_queue_usage='0.00' ... events_processed='0' events_received='1000' events_dropped='0' event_queue_usage='0.37' ``` 6. Decoded events chart:  Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1000 events per second and we can see in `/var/ossec/var/run/wash-analysis.state` that 1000 events were received and 1000 events processed.

Check that wazuh-analysisd starts queuing events when the limit is reached and the corresponding queue is not full :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 50 30 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 3. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 13:56:06 wazuh-analysisd: INFO: EPS limit enabled, EPS: '50', timeframe: '30' ``` 4. Generate logs with `simulate-agents` tool: ``` simulate-agents -a MANAGER_IP -n 1 -m logcollector -s 1600 ``` 5. Check State files: ``` events_processed='1500' events_received='1600' events_dropped='0' event_queue_usage='0.00' ... events_processed='0' events_received='1600' events_dropped='0' event_queue_usage='0.37' ``` 6. Decoded events chart:  Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1600 events and we can see in `/var/ossec/var/run/wash-analysis.state` that 1600 events were received and 1500 events processed.

Check that wazuh-analysisd starts dropping events when the limit is reached and the corresponding queue is full :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 50 3 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 3. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 14:25:17 wazuh-analysisd: INFO: EPS limit enabled, EPS: '50', timeframe: '3' ``` 4. Generate logs with `simulate-agents` tool: ``` simulate-agents -a MANAGER_IP -n 1 -m logcollector -s 1600 ``` 5. Check State files: ``` events_processed='0' events_received='1600' events_dropped='0' event_queue_usage='0.99' ... events_processed='0' events_received='1600' events_dropped='1597' event_queue_usage='1.00' ``` 6. Decoded events chart:  Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1600 events. In the first capture of logs, we can see in `/var/ossec/var/run/wash-analysis.state` that 1600 events were received and 0 events processed. In the second capture of logs, we can see that the queue reached the maximum and began to delete events

Check that wazuh-analysisd processes queued events first instead of new events when the moving average frees up some space :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 5 4 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 3. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 16:04:46 wazuh-analysisd: INFO: EPS limit enabled, EPS: '5', timeframe: '4' ``` 4. Generate logs with `simulate-agents` tool: ``` simulate-agents -a 172.31.12.224 -n 1 -m logcollector -s 10000 -t 20 -f 1 -e 50 -k False -d False ``` 5. Check State files: ``` events_processed='20' events_received='50' events_dropped='0' event_queue_usage='0.00' ``` 6. Check the file with the alerts generated and you can see that the alerts is ordered: [alerts.log](https://github.com/wazuh/wazuh-qa/files/9375748/alerts.log) 7. Decoded events chart:: 

Check that wazuh-analysisd works as olders versions if the eps is 0 :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 0 3 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 3. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 16:35:26 wazuh-analysisd: INFO: EPS limit disabled ``` 4. Generate logs with `simulate-agents` tool: ``` simulate-agents -a 172.31.12.224 -n 1 -m logcollector -s 10000 -t 20 -f 1 -e 10000 -k False -d False ``` 5. Check State files: ``` events_processed='3753' events_received='3753' events_dropped='0' event_queue_usage='0.00' ... events_processed='6247' events_received='6247' events_dropped='0' event_queue_usage='0.00' ``` 6. Decoded events chart: 

[CamiRomero]

Tests cases upgrade from 4.3.6 to 4.4.0

Prerequisites

1. Download and install Wazuh 4.3.6 from the official documentation 2. Check Wazuh version: ``` /var/ossec/bin/wazuh-control info ``` Output: ``` WAZUH_VERSION="v4.3.6" WAZUH_REVISION="40318" WAZUH_TYPE="server" ``` 3. Download and upgrade to Wazuh 4.4.0 ``` curl -LO https://packages-dev.wazuh.com/warehouse/pullrequests/4.4/rpm/var/wazuh-manager-4.4.0-0.commit032cc76.x86_64.rpm yum upgrade wazuh-manager-4.4.0-0.commit032cc76.x86_64.rpm ``` 4. Check Wazuh version: ``` /var/ossec/bin/wazuh-control info ``` Output: ``` WAZUH_VERSION="v4.4.0" WAZUH_REVISION="40400" WAZUH_TYPE="server" ```

Test the new configuration block :yellow_circle:

EPS functionality disabled :green_circle:

1. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 23:26:16 wazuh-analysisd: INFO: EPS limit disabled ```

EPS functionality enabled :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 500 30 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` 3. Check status of daemons: ``` /var/ossec/bin/wazuh-control status ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 9. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 23:29:02 wazuh-analysisd: INFO: EPS limit enabled, EPS: '500', timeframe: '30' ```

Check without maximum field :yellow_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 30 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` 3. Check status of daemons: ``` /var/ossec/bin/wazuh-control status ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 4. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 23:30:43 wazuh-analysisd: INFO: EPS limit disabled ``` Note: The value by default (0) is set correctly and the EPS limit is disabled. I suggest adding a Warning log to informing to users that EPS limit is disabled because is missing a maximum field.

Check without timeframe field :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 500 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` 3. Check status of daemons: ``` /var/ossec/bin/wazuh-control status ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 4. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 23:32:01 wazuh-analysisd: INFO: EPS limit enabled, EPS: '500', timeframe: '10' ``` Note: The value by default is set correctly

Check without timeframe and maximum field :green_circle:

1. Download and install Wazuh 4.4: ``` curl -LO https://packages-dev.wazuh.com/warehouse/pullrequests/4.4/rpm/var/wazuh-manager-4.4.0-0.commit032cc76.x86_64.rpm yum install -y wazuh-manager-4.4.0-0.commit032cc76.x86_64.rpm systemctl daemon-reload systemctl enable wazuh-manager systemctl start wazuh-manager ``` 2. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` ``` 4. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` 6. Check cause of error: ``` journalctl -xe ``` Output: ``` ago 18 23:32:46 ip-172-31-12-21.ec2.internal env[9229]: 2022/08/18 23:32:46 wazuh-maild: ERROR: (1230): Invalid element in the configuration: 'eps'. ago 18 23:32:46 ip-172-31-12-21.ec2.internal env[9229]: 2022/08/18 23:32:46 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. ago 18 23:32:46 ip-172-31-12-21.ec2.internal env[9229]: 2022/08/18 23:32:46 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ago 18 23:32:46 ip-172-31-12-21.ec2.internal env[9229]: wazuh-maild: Configuration error. Exiting ago 18 23:32:46 ip-172-31-12-21.ec2.internal systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 ago 18 23:32:46 ip-172-31-12-21.ec2.internal systemd[1]: wazuh-manager.service: Failed with result 'exit-code'. ```

Check with and extra field :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 500 30 30 ``` 4. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` 6. Check status of daemons: ``` /var/ossec/bin/wazuh-control status ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 7. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 23:37:10 wazuh-analysisd: INFO: EPS limit enabled, EPS: '500', timeframe: '30' ``` Note: The EPS limit was configured correctly but should we detect an extra field?

Check exceeding the maximum limit of maximum :yellow_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 100001 30 ``` 4. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` 6. Check cause of error: ``` journalctl -xe ``` Output: ``` ago 18 23:38:28 ip-172-31-12-21.ec2.internal env[10635]: 2022/08/18 23:38:28 wazuh-maild: ERROR: (1235): Invalid value for element 'maximum': 100001. ago 18 23:38:28 ip-172-31-12-21.ec2.internal env[10635]: 2022/08/18 23:38:28 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. ago 18 23:38:28 ip-172-31-12-21.ec2.internal env[10635]: 2022/08/18 23:38:28 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ago 18 23:38:28 ip-172-31-12-21.ec2.internal env[10635]: wazuh-maild: Configuration error. Exiting ago 18 23:38:28 ip-172-31-12-21.ec2.internal systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 ago 18 23:38:28 ip-172-31-12-21.ec2.internal systemd[1]: wazuh-manager.service: Failed with result 'exit-code'. ``` Note: I suggest modifying this behavior. I think that when we detect a maximum limit is exceeding we can add a Warning log to informing to users that the limit was exceeding and set up the field with the maximum value allowed (100000)

Check exceeding the maximum limit of timeframe :yellow_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 500 3601 ``` 4. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` 6. Check cause of error: ``` journalctl -xe ``` Output: ``` ago 18 23:39:46 ip-172-31-12-21.ec2.internal env[10671]: 2022/08/18 23:39:46 wazuh-maild: ERROR: (1235): Invalid value for element 'timeframe': 3601. ago 18 23:39:46 ip-172-31-12-21.ec2.internal env[10671]: 2022/08/18 23:39:46 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. ago 18 23:39:46 ip-172-31-12-21.ec2.internal env[10671]: 2022/08/18 23:39:46 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ago 18 23:39:46 ip-172-31-12-21.ec2.internal env[10671]: wazuh-maild: Configuration error. Exiting ago 18 23:39:46 ip-172-31-12-21.ec2.internal systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 ago 18 23:39:46 ip-172-31-12-21.ec2.internal systemd[1]: wazuh-manager.service: Failed with result 'exit-code'. ``` Note: I suggest modifying this behavior. I think that when we detect a maximum limit is exceeding we can add a Warning log to informing to users that the limit was exceeding and set up the field with the maximum value allowed (3600)

Check with value outside the lower limit :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 500 0 ``` 4. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` 6. Check cause of error: ``` journalctl -xe ``` Output: ``` ago 18 23:40:52 ip-172-31-12-21.ec2.internal env[10707]: 2022/08/18 23:40:52 wazuh-maild: ERROR: (1235): Invalid value for element 'timeframe': 0. ago 18 23:40:52 ip-172-31-12-21.ec2.internal env[10707]: 2022/08/18 23:40:52 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. ago 18 23:40:52 ip-172-31-12-21.ec2.internal env[10707]: 2022/08/18 23:40:52 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ago 18 23:40:52 ip-172-31-12-21.ec2.internal env[10707]: wazuh-maild: Configuration error. Exiting ago 18 23:40:52 ip-172-31-12-21.ec2.internal systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 ago 18 23:40:52 ip-172-31-12-21.ec2.internal systemd[1]: wazuh-manager.service: Failed with result 'exit-code'. ```

Check with invalid values :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log` without `maximum`: ``` 500 $ ``` 4. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` 6. Check cause of error: ``` journalctl -xe ``` Output: ``` ago 18 23:41:55 ip-172-31-12-21.ec2.internal env[10743]: 2022/08/18 23:41:55 wazuh-maild: ERROR: (1235): Invalid value for element 'timeframe': $. ago 18 23:41:55 ip-172-31-12-21.ec2.internal env[10743]: 2022/08/18 23:41:55 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. ago 18 23:41:55 ip-172-31-12-21.ec2.internal env[10743]: 2022/08/18 23:41:55 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ago 18 23:41:55 ip-172-31-12-21.ec2.internal env[10743]: wazuh-maild: Configuration error. Exiting ago 18 23:41:55 ip-172-31-12-21.ec2.internal systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 ago 18 23:41:55 ip-172-31-12-21.ec2.internal systemd[1]: wazuh-manager.service: Failed with result 'exit-code'. ``` Note: The same test was executed for white spaces and negative numbers. For Maximum and timeframe field

--------------

Check that wazuh-analysisd stops processing events when the limit is reached :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 50 30 ``` 4. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 5. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/18 23:47:50 wazuh-analysisd: INFO: EPS limit enabled, EPS: '50', timeframe: '30' ``` 7. Generate logs with `simulate-agents` tool: ``` simulate-agents -a MANAGER_IP -n 1 -m logcollector -s 1600 ``` 8. Check State files: ``` events_processed='1500' events_received='1600' events_dropped='0' event_queue_usage='0.00' ... events_processed='0' events_received='1600' events_dropped='0' event_queue_usage='0.00' ``` 9. Decoded events chart:  Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1600 events and we can see in `/var/ossec/var/run/wash-analysis.state` that 6400 events were received and 1500 events processed.

Check that wazuh-analysisd starts queuing events when the limit is reached and the corresponding queue is not full :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 50 30 ``` 4. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 5. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/19 00:08:16 wazuh-analysisd: INFO: EPS limit enabled, EPS: '50', timeframe: '30' ``` 7. Generate logs with `simulate-agents` tool: ``` simulate-agents -a MANAGER_IP -n 1 -m logcollector -s 1600 ``` 8. Check State files: ``` events_processed='1500' events_received='3200' events_dropped='0' event_queue_usage='0.10' ... events_processed='0' events_received='1600' events_dropped='0' event_queue_usage='0.37' ``` 9. Decoded events chart:  Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1600 events and we can see in `/var/ossec/var/run/wash-analysis.state` that 3200 events were received and 1500 events processed.

Check that wazuh-analysisd starts dropping events when the limit is reached and the corresponding queue is full :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 50 30 ``` 4. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 5. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/19 00:12:03 wazuh-analysisd: INFO: EPS limit enabled, EPS: '50', timeframe: '30' ``` 7. Generate logs with `simulate-agents` tool: ``` simulate-agents -a MANAGER_IP -n 1 -m logcollector -s 1600 ``` 8. Check State files: ``` events_processed='1500' events_received='1600' events_dropped='0' event_queue_usage='0.98' ... events_processed='1500' events_received='3200' events_dropped='1348' event_queue_usage='1.00' ``` 9. Decoded events chart:  Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1600 events per second. In the first capture of logs, we can see in `/var/ossec/var/run/wash-analysis.state` that 1600 events were received and 1500 events processed. In the second capture of logs, we can see that the queue reached the maximum and began to delete events

Check that wazuh-analysisd processes queued events first instead of new events when the moving average frees up some space :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 5 4 ``` 2. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 3. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/19 11:10:39 wazuh-analysisd: INFO: EPS limit enabled, EPS: '5', timeframe: '4' ``` 4. Generate logs with `simulate-agents` tool: ``` simulate-agents -a MANAGER_IP -n 1 -m logcollector -s 10000 -t 20 -f 1 -e 50 -k False -d False ``` 5. Check State files: ``` events_processed='20' events_received='50' events_dropped='0' event_queue_usage='0.00' ``` 6. Check the file with the alerts generated and you can see that the alerts is ordered: [alert.log](https://github.com/wazuh/wazuh-qa/files/9381841/alert.log) 7. Decoded events chart: 

Check that wazuh-analysisd works as olders versions if the eps is 0 :green_circle:

1. Add configuration for EPS in `/var/ossec/logs/ossec.log`: ``` 0 3 ``` 4. Restart Wazuh manager in order to apply changes: ``` systemctl restart wazuh-manager ``` Output: ``` wazuh-clusterd not running... wazuh-modulesd is running... wazuh-monitord is running... wazuh-logcollector is running... wazuh-remoted is running... wazuh-syscheckd is running... wazuh-analysisd is running... wazuh-maild not running... wazuh-execd is running... wazuh-db is running... wazuh-authd is running... wazuh-agentlessd not running... wazuh-integratord not running... wazuh-dbd not running... wazuh-csyslogd not running... wazuh-apid is running... ``` 5. Check logs located in `/var/ossec/logs/ossec.log`: ``` 2022/08/19 00:59:38 wazuh-analysisd: INFO: EPS limit disabled ``` 7. Generate logs with `simulate-agents` tool: ``` simulate-agents -a 172.31.12.224 -n 1 -m logcollector -s 10000 -t 20 -f 1 -e 10000 -k False -d False ``` 9. Check State files: ``` events_processed='4656' events_received='4656' events_dropped='0' event_queue_usage='0.00' ... events_processed='3569' events_received='3569' events_dropped='0' event_queue_usage='0.00' ``` 10. Decoded events chart: 

[jmv74211]

🟡 Everything seems to be working properly. Several suggestions have been proposed in https://github.com/wazuh/wazuh/issues/14665 https://github.com/wazuh/wazuh/issues/14666 and will be reviewed in future PRs.

[jmv74211]

The issue is reopened because we still need to test the settings using the configuration uploaded through the API.

[juliamagan]

Review data

Tester	PR commit
@juliamagan	24d2fd4

Testing environment

OS	OS version	Deployment	Image/AMI	Notes
CentOS	CentOS 8	Vagrant	qactl/centos_8

Tested packages

wazuh-manager
4.4.0

Status

• [x] In progress
• [x] Pending Review
• [x] QA Manager approved (@jmv74211)
• [x] Development team leader approved (@vicferpoy)

Conclusion 🟡

Everything seems to work as expected. However, there are some suggestions:

• If we try to update the configuration with the default ossec.conf, it will fail, because there are two <ossec_config> blocks.
• If we set an invalid value in the API configuration, the default configuration (yes), will be set, but no warning will appear.

[juliamagan]

Testing results

Default configuration - Configure maximum and timeframe 🟡

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections # upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] # limits: # eps: # allow: yes ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714138/new_ossec.conf.txt) ⚠️ : ```xml 100 30 ``` The default configuration has two `` blocks, but if we try to update the configuration from the API with this, we receive the following error: ```json { "data":{ "affected_items":[ ], "total_affected_items":0, "total_failed_items":1, "failed_items":[ { "error":{ "code":1113, "message":"XML syntax error: junk after document element: line 318, column 0", "remediation":"Please, ensure file content has correct XML" }, "id":[ "manager" ] } ] }, "message":"Could not update configuration", "error":1 } ``` So for the rest of the tests, this part has been commented out: ```xml ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration' -H "Authorization: Bearer $TOKEN"`: ```json { "data":{ "affected_items":[ "manager" ], "total_affected_items":1, "total_failed_items":0, "failed_items":[ ] }, "message":"Configuration was successfully updated", "error":0 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml 100 30 ```

Default configuration - Configure maximum 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections # upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] # limits: # eps: # allow: yes ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714235/new_ossec.conf.txt): ```xml 100 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration' -H "Authorization: Bearer $TOKEN"`: ```json { "data":{ "affected_items":[ "manager" ], "total_affected_items":1, "total_failed_items":0, "failed_items":[ ] }, "message":"Configuration was successfully updated", "error":0 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml 100 ```

Default configuration - Configure timeframe 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections # upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] # limits: # eps: # allow: yes ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714376/new_ossec.conf.txt): ```xml 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [ "manager" ], "total_affected_items": 1, "total_failed_items": 0, "failed_items": [] }, "message": "Configuration was successfully updated", "error": 0 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml 30 ```

Allow upload configuration (yes) - Configure maximum and timeframe 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: yes ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714370/new_ossec.conf.txt): ```xml 100 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [ "manager" ], "total_affected_items": 1, "total_failed_items": 0, "failed_items": [] }, "message": "Configuration was successfully updated", "error": 0 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml 100 30 ```

Allow upload configuration (yes) - Configure maximum 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: yes ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714398/new_ossec.conf.txt): ```xml 100 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [ "manager" ], "total_affected_items": 1, "total_failed_items": 0, "failed_items": [] }, "message": "Configuration was successfully updated", "error": 0 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml 100 ```

Allow upload configuration (yes) - Configure timeframe 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: yes ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714414/new_ossec.conf.txt): ```xml 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [ "manager" ], "total_affected_items": 1, "total_failed_items": 0, "failed_items": [] }, "message": "Configuration was successfully updated", "error": 0 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml 30 ```

Allow upload configuration (true) - Configure maximum and timeframe 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: true ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714465/new_ossec.conf.txt): ```xml 100 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [ "manager" ], "total_affected_items": 1, "total_failed_items": 0, "failed_items": [] }, "message": "Configuration was successfully updated", "error": 0 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml 100 30 ```

Allow upload configuration (true) - Configure maximum 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: true ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714486/new_ossec.conf.txt): ```xml 100 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [ "manager" ], "total_affected_items": 1, "total_failed_items": 0, "failed_items": [] }, "message": "Configuration was successfully updated", "error": 0 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml 100 ```

Allow upload configuration (true) - Configure timeframe 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: true ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714490/new_ossec.conf.txt): ```xml 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [ "manager" ], "total_affected_items": 1, "total_failed_items": 0, "failed_items": [] }, "message": "Configuration was successfully updated", "error": 0 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml 30 ```

Do not allow upload configuration (no) - Configure maximum and timeframe 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: no ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714532/new_ossec.conf.txt): ```xml 100 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [], "total_affected_items": 0, "total_failed_items": 1, "failed_items": [ { "error": { "code": 1127, "message": "Forbidden section detected: global > limits > eps", "remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html" }, "id": [ "manager" ] } ] }, "message": "Could not update configuration", "error": 1 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml ```

Do not allow upload configuration (no) - Configure maximum 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: no ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714547/new_ossec.conf.txt): ```xml 100 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [], "total_affected_items": 0, "total_failed_items": 1, "failed_items": [ { "error": { "code": 1127, "message": "Forbidden section detected: global > limits > eps", "remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html" }, "id": [ "manager" ] } ] }, "message": "Could not update configuration", "error": 1 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml ```

Do not allow upload configuration (no) - Configure timeframe 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: no ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714567/new_ossec.conf.txt): ```xml 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [], "total_affected_items": 0, "total_failed_items": 1, "failed_items": [ { "error": { "code": 1127, "message": "Forbidden section detected: global > limits > eps", "remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html" }, "id": [ "manager" ] } ] }, "message": "Could not update configuration", "error": 1 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml ```

Do not allow upload configuration (false) - Configure maximum and timeframe 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: false ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714594/new_ossec.conf.txt): ```xml 100 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [], "total_affected_items": 0, "total_failed_items": 1, "failed_items": [ { "error": { "code": 1127, "message": "Forbidden section detected: global > limits > eps", "remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html" }, "id": [ "manager" ] } ] }, "message": "Could not update configuration", "error": 1 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml ```

Do not allow upload configuration (false) - Configure maximum 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: false ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714611/new_ossec.conf.txt): ```xml 100 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [], "total_affected_items": 0, "total_failed_items": 1, "failed_items": [ { "error": { "code": 1127, "message": "Forbidden section detected: global > limits > eps", "remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html" }, "id": [ "manager" ] } ] }, "message": "Could not update configuration", "error": 1 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml ```

Do not allow upload configuration (false) - Configure timeframe 🟢

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: false ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714620/new_ossec.conf.txt): ```xml 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [], "total_affected_items": 0, "total_failed_items": 1, "failed_items": [ { "error": { "code": 1127, "message": "Forbidden section detected: global > limits > eps", "remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html" }, "id": [ "manager" ] } ] }, "message": "Could not update configuration", "error": 1 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml ```

Invalid allow value :yellow_circle:

**If the value is invalid, it will take the default configuration, but we will not receive any warning.** - `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: ffalse ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714620/new_ossec.conf.txt): ```xml 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [ "manager" ], "total_affected_items": 1, "total_failed_items": 0, "failed_items": [] }, "message": "Configuration was successfully updated", "error": 0 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml 30 ```

Repeated allow configuration :green_circle:

**If the configuration is repeated, it will take the last one.** - `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: yes allow: no ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714620/new_ossec.conf.txt): ```xml 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [], "total_affected_items": 0, "total_failed_items": 1, "failed_items": [ { "error": { "code": 1127, "message": "Forbidden section detected: global > limits > eps", "remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html" }, "id": [ "manager" ] } ] }, "message": "Could not update configuration", "error": 1 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml ```

Invalid allow configuration :green_circle:

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: enabled: yes ``` - [new_ossec.conf](https://github.com/wazuh/wazuh-qa/files/9714620/new_ossec.conf.txt): ```xml 30 ``` - `curl -k --upload-file "/tmp/new_ossec.conf" -X PUT 'https://localhost:55000/manager/configuration?pretty=true' -H "Authorization: Bearer $TOKEN"`: ```json { "data": { "affected_items": [], "total_affected_items": 0, "total_failed_items": 1, "failed_items": [ { "error": { "code": 1113, "message": "XML syntax error: 'allow'", "remediation": "Please, ensure file content has correct XML" }, "id": [ "manager" ] } ] }, "message": "Could not update configuration", "error": 1 } ``` - `egrep -A 5 -B 1 "limits" /var/ossec/etc/ossec.conf` ```xml ```

[jmv74211]

QA review

• Type: Manual testing.
• Status: Requested improvements 🟡
• Comments: Everything seems to be working properly, but two cases have been detected in which the behavior could be improved:
  • (1) If we try to update the configuration with the default ossec.conf, it will fail, because there are two <ossec_config> blocks. (cc @vicferpoy @davidjiglesias).
  • (2) No message is displayed when entering a wrong value in the API configuration, taking the default value (cc @vicferpoy @davidjiglesias).
  • (3) It is suggested to add a log message for when available credits are consumed. This would be quite useful to let users know that they have to upgrade to a higher plan (cc @TomasTurina @vikman90).
  • (4) It is suggested to add a log message for when the wazuh-manager start dropping events because the queue is full. This is quite important to let the user know that they are losing event analysis (cc @TomasTurina @vikman90).
  • (5) It is suggested to add WARNING logs when parameters are missing in the block. Reported in this issue (cc @TomasTurina @vikman90) .
  • (6) Check if the normal behavior after exceeding the value of <maximum> is an error that does not start the wazuh-manager. Reported in this issue (cc @TomasTurina @vikman90).

This will be discussed with the development team.

[vicferpoy]

Requested improvements update

If we try to update the configuration with the default ossec.conf, it will fail, because there are two blocks.

This is not related to this development, but it is something we must address. Thus, it should not block this development but a new issue should be opened to investigate it.

No message is displayed when entering a wrong value in the API configuration, taking the default value.

This was actually a bug introduced in this development. A fix has been added in https://github.com/wazuh/wazuh/pull/13608/commits/2f789dc794e6409ea29cb0807ca10bf7a99b9583.

[juliamagan]

Testing after requested changes

• Tester: @juliamagan
• PR commit: https://github.com/wazuh/wazuh/commit/2f789dc794e6409ea29cb0807ca10bf7a99b9583
• Package: 4.4.0

---

Results

Invalid allow value :green_circle:

- `api.yaml`: ```yaml # Uploadable Wazuh configuration sections upload_configuration: # remote_commands: # localfile: # allow: yes # exceptions: [] # wodle_command: # allow: yes # exceptions: [] limits: eps: allow: yyes ``` - `systemctl restart wazuh-manager`: ``` Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details. ``` - `journalctl -xe`: ``` Oct 06 07:22:29 c3 systemd[1]: Starting Wazuh manager... -- Subject: Unit wazuh-manager.service has begun start-up -- Defined-By: systemd -- Support: https://access.redhat.com/support -- -- Unit wazuh-manager.service has begun starting up. Oct 06 07:22:30 c3 env[5244]: Configuration not valid. ERROR: 2000 - Some parameters are not expected in the configuration file (WAZUH_PATH/api/configuration/api.yaml). Please check the documentation for further details: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html#api-configuration-options: 'yyes' is not of type 'boolean'. Oct 06 07:22:30 c3 env[5244]: wazuh-apid: Configuration error. Exiting Oct 06 07:22:30 c3 systemd[1]: wazuh-manager.service: Control process exited, code=exited status=1 Oct 06 07:22:30 c3 systemd[1]: wazuh-manager.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://access.redhat.com/support -- -- The unit wazuh-manager.service has entered the 'failed' state with result 'exit-code'. Oct 06 07:22:30 c3 systemd[1]: Failed to start Wazuh manager. -- Subject: Unit wazuh-manager.service has failed -- Defined-By: systemd -- Support: https://access.redhat.com/support -- -- Unit wazuh-manager.service has failed. -- -- The result is failed. ```

Conclusion 🟢

Everything seems to work correctly after the added fix.

[jmv74211]

QA review update

🟢	Solved
🟡	Pending resolution in this development
🔵	Proposed to be fixed in future versions or developments
⚫	Discarded

After discussions with the development team, the following has been decided:

(1) If we try to update the configuration with the default ossec.conf, it will fail, because there are two <ossec_config> blocks 🔵

This appears to have been introduced in previous developments within 4.4.0 (does not occur in earlier versions). The following issue wazuh#15076 https://github.com/wazuh/wazuh/issues/15082 has been opened and will be looked into to see if it is fixed in 4.4.0.

(2) No message is displayed when entering a wrong value in the API configuration, taking the default value 🟢

This has been fixed in this development itself. After this fix, it has been tested here and it is now working correctly

(3) It is suggested to add a log message for when available credits are consumed. This would be quite useful to let users know that they have to upgrade to a higher plan (cc @TomasTurina @vikman90). ⚫

It has been discussed with the development team and it has been concluded that it can be confusing for the user and that it is not very useful, so it is accepted to discard this idea.

(4) It is suggested to add a log message for when the wazuh-manager start dropping events because the queue is full. This is quite important to let the user know that they are losing event analysis (cc @TomasTurina @vikman90). 🟡

The development team is in agreement with this idea, and will endeavor to implement it in this very development.

(5) It is suggested to add WARNING logs when parameters are missing in the block. Reported in this issue (cc @TomasTurina @vikman90). 🟡

The development team is in agreement with this idea, and will endeavor to implement it in this very development.

(6) Check if the normal behavior after exceeding the value of <maximum> is an error that does not start the wazuh-manager. Reported in this issue (cc @TomasTurina @vikman90). ⚫

It has been discussed with the development team and it has been concluded that this is the designed and expected behavior. We accept the discarding of this idea.

---

We look forward to the implementation of the changes suggested in (3) and (4).

[TomasTurina]

Update

To solve https://github.com/wazuh/wazuh/issues/14665, this warning was added when the maximum setting is not defined in the eps limits block:

"EPS limit disabled. The maximum value is missing in the configuration block."

To solve:

(4) It is suggested to add a log message for when the wazuh-manager start dropping events because the queue is full. This is quite important to let the user know that they are losing event analysis

This warning was added when wazuh-analysisd starts dropping because eps limit:

"Events are being dropped due to there are no analysis credits."

Beside, when it stops dropping events, this information message was added:

"Events dropping has stopped due to there are available analysis credits now."

These logs can flood the ossec.log file if wazuh-analysisd continues to go in and out of drop state for a period of time. To control this, only the first time in the current hour will display these warning and information messages, and subsequent times will display a debug 2 message until the current system hour changes.

[jmv74211]

Testing after requested changes

• Tester: @jmv74211
• PR commit: https://github.com/wazuh/wazuh/pull/13608/commits/74b748fc66391af72b373bbd01472a68db66ae60
• Package: 4.4.0

---

Results

(4) It is suggested to add a log message for when the wazuh-manager start dropping events because the queue is full. This is quite important to let the user know that they are losing event analysis 🟢

This has been resolved by adding the following logs: - Events are being dropped due to no credits available and the event queue is full. The first time is a `WARNING`. ``` WARNING: Events are being dropped due to there are no analysis credits. ``` The rest of the times in less than 1h are `DEBUG`. ``` DEBUG: Events are being dropped due to there are no analysis credits. ``` - It has stopped dropping events The first time is a `WARNING`. ``` INFO: Events dropping has stopped due to there are available analysis credits now. ``` The rest of the times in less than 1h are `DEBUG`. ``` DEBUG: Events are being dropped due to there are no analysis credits. ``` This has been tested and verified to work correctly, and the final behavior is as expected. For this, a limit setting of maximum 1000 and timeframe of 30s (30000 events in total every 30s) has been specified. Then, an event simulator has been used, sending a large amount to force queue filling and event dropping. The following video shows how the process was performed and the results obtained. https://user-images.githubusercontent.com/23462183/196398805-6e93603d-b1a5-4d75-b9ce-682142d13ea3.mp4

(5) It is suggested to add WARNING logs when parameters are missing in the block 🟡

> Conclusion: Spamming of Warning messages is not accepted. Only 1 should appear **Missing \** 🟡 When starting the `wazuh-manager` with the EPS limitation block but without the `` tag, multiple warnings come up, flooding the log and proving annoying. ``` 2022/10/18 09:42:09 wazuh-maild: WARNING: EPS limit disabled. The maximum value is missing in the configuration block. 2022/10/18 09:42:09 wazuh-maild: WARNING: EPS limit disabled. The maximum value is missing in the configuration block. 2022/10/18 09:42:09 wazuh-analysisd: WARNING: EPS limit disabled. The maximum value is missing in the configuration block. 2022/10/18 09:42:10 wazuh-remoted: WARNING: EPS limit disabled. The maximum value is missing in the configuration block. 2022/10/18 09:42:10 wazuh-monitord: WARNING: EPS limit disabled. The maximum value is missing in the configuration block. 2022/10/18 09:42:10 wazuh-testrule: WARNING: EPS limit disabled. The maximum value is missing in the configuration block. 2022/10/18 09:42:14 wazuh-analysisd: WARNING: EPS limit disabled. The maximum value is missing in the configuration block. 2022/10/18 09:42:15 wazuh-remoted: WARNING: EPS limit disabled. The maximum value is missing in the configuration block. 2022/10/18 09:42:17 wazuh-monitord: WARNING: EPS limit disabled. The maximum value is missing in the configuration block. ``` **Missing \** 🟢 In this case the module is started with the default value of `` of 10s. ``` 2022/10/18 09:48:13 wazuh-analysisd: INFO: EPS limit enabled, EPS: '1000', timeframe: '10' ``` **Missing \ and \** 🟢 In this case, the `wazuh-manager` does not start. ``` 2022/10/18 09:50:12 wazuh-maild: ERROR: (1230): Invalid element in the configuration: 'eps'. 2022/10/18 09:50:12 wazuh-maild: ERROR: (1202): Configuration error at 'etc/ossec.conf'. 2022/10/18 09:50:12 wazuh-maild: CRITICAL: (1202): Configuration error at 'etc/ossec.conf'. ```

Conclusion 🟡

When <maximum> tag is missing, 9 WARNING messages are showed instead of 1.

[jmv74211]

Closing conclusion 👍🏼

🟢	Solved
🔵	Proposed to be fixed in future versions or developments
⚫	Discarded

After talking with the development team, the testing has been approved taking into account the following considerations proposed in the QA review:

(1) If we try to update the configuration with the default ossec.conf, it will fail, because there are two <ossec_config> blocks 🔵

This appears to have been introduced in previous developments within 4.4.0 (does not occur in earlier versions). The following issue wazuh#15076 https://github.com/wazuh/wazuh/issues/15082 has been opened and will be looked into to see if it is fixed in 4.4.0.

(2) No message is displayed when entering a wrong value in the API configuration, taking the default value 🟢

This has been fixed in this development itself. After this fix, it has been tested here and it is now working correctly

(3) It is suggested to add a log message for when available credits are consumed. This would be quite useful to let users know that they have to upgrade to a higher plan. ⚫

It has been discussed with the development team and it has been concluded that it can be confusing for the user and that it is not very useful, so it is accepted to discard this idea.

(4) It is suggested to add a log message for when the wazuh-manager start dropping events because the queue is full. This is quite important to let the user know that they are losing event analysis. 🟢

Log messages are now displayed for the indicated cases. Added in https://github.com/wazuh/wazuh/pull/13608/commits/87aaf72bbacbde295d700b8e0f3cf928770b54cc

(5) It is suggested to add WARNING logs when parameters are missing in the block. Reported in this issue. 🟢 and 🔵

Log messages are now displayed for the indicated cases. Added in https://github.com/wazuh/wazuh/pull/13608/commits/87aaf72bbacbde295d700b8e0f3cf928770b54cc, although it has been reported that the log appears multiple times. After discussing this with the development team, it seems that this has been happening before. The following issue has been opened to report it wazuh#15188.

(6) Check if the normal behavior after exceeding the value of <maximum> is an error that does not start the wazuh-manager. Reported in this issue. ⚫

It has been discussed with the development team and it has been concluded that this is the designed and expected behavior. We accept the discarding of this idea.

---

In addition, all analysisd tests have been released, along with the new ones introduced to test the EPS limitation and the results are both 🟢 for local and Jenkins.