Active-response alert ID is different than alert ID in alerts.json log file

[Tanel Peep]

Hi,

I tried to use custom active response script to take active response script alert ID argument and searching relevant alert json from alerts.json file. I discovered that sometimes the alert ID is different than alert ID in alerts.json log.

Does it have to be so or is it bug?

Best regards,

Tanel

[Juan Pablo Saez]

Hello Tanel,

This is a known bug: It seems like active-response is sending the wrong AlertID to any custom active-response script. 

The bug already has two related issues and it's in our roadmap, and can keep track of it if you want to be up to date on the progress: Alert ID in Active Response is different from the one generated in Kibana.

Sorry for the inconvenience. You can also contact us through our #community Slack channel if you need something else.

Best regards, JP Sáez

[Tanel Peep]

Thank you for your answer. 

I was trying to use Integration as an alternative for active-response. Normal log messages will execute script successfully but bigger size alerts didn't execute the integration script and cannot even see information in ossec.log debug mode. Is it possible to change Wazuh to use integration for bigger size of alerts?

Thanks, 

Tanel

[Juan Pablo Saez]

Hello Tanel,

The <max_log> option allows you to set the maximum length of an alert snippet that will be sent to the Integrator. Longer strings will be truncated. I think this option will suit you to solve the string size problem. 

Please, let me know if it helps. Greetings, 

JP Sáez

[Tanel Peep]

It will not even truncate my alert and doesn't have any information in ossec log. Integrated log level is set to 2. 

Where I could look for the issue?

Best regards,

Tanel

[Juan Pablo Saez]

Hi again Tanel,

• The structure that stores the alerts has 65536 Bytes.
• When sending an alert from a long event, if the alert includes the full_log option the maximum size can be easily reached. Maybe your use case requires to disable the full log using <options>no_full_log</options> in the related alert.
• Could you explain more in-depth your use case? Do you want to trigger an alert and then trigger an active-response block trough it? Could you use a little scheme as the one below?

Alert0 -----> Integratord -----> Alert1 ------> Active response script

I hope it helps. Greetings, 

JP Sáez

[Tanel Peep]

Hi Juan, 

Found the problem, it were related with maximum size of log event. I had to add "no_full_log" option and remove some fields to get integration to send notification.

Use case is just to execute custom script that will send notification to our custom system. Currently this works only when I add "no_full_log" and remove some custom fields, but is there any workaround to send maybe only alert ID to integration and then I can use custom script to search event details in alerts.json?

Best regards,

Tanel

[Juan Pablo Saez]

Hello Tanel,

But is there any workaround to send maybe only alert ID to integration and then I can use custom script to search event details in alerts.json?

• The alerts go from the alerts.json file to the integratord queue where the module extracts and processes each alert. 
• You should code some kind of field removal in the integratord code to only send the rule ID field.
  
• If you do this, some fields should remain(location, level, rule, group)as they are necessary to check if the alert should be sent to the integration. 

I think that if you are already receiving the alerts correctly you could already use your custom script to search event details in alerts.json.

I hope it helps. Greetings, 

JP Sáez

[Tanel Peep]

I got integration work to receive the alerts only in reduced form (removed full log in rules and some fields in decoders) because alert log message is containing too much information. Reduced alert log is not good option to continue because there are necessary fields for us. 

• You should code some kind of field removal in the integratord code to only send the rule ID field.

• If you do this, some fields should remain(location, level, rule, group)as they are necessary to check if the alert should be sent to the integration. 

This could be problem because modifying source requires custom modification and build after each new Wazuh release. 

 I think that if you are already receiving the alerts correctly you could already use your custom script to search event details in alerts.json.

Alerts will be received only when log is reduced, including necessary custom fields for us. This reduced log will be stored in alerts.json and full information with removed fields are not available anymore. 

Is it option to add integrationd improvements into Wazuh roadmap to get integration working with alerts that are bigger than 65536 Bytes? Example, maybe sending only location, level, rule, group, alert ID (not all fields) from integratord and if necessary then custom scripts can search for details in alerts.json. 

Thank you,

Tanel

[Juan Pablo Saez]

Hello Tanel, 

Alerts will be received only when log is reduced, including necessary custom fields for us. This reduced log will be stored in alerts.json and full information with removed fields are not available anymore. 

Now I get you, sorry for the late understanding.

Is it option to add integrationd improvements into Wazuh roadmap to get integration working with alerts that are bigger than 65536 Bytes? Example, maybe sending only location, level, rule, group, alert ID (not all fields) from integratord and if necessary then custom scripts can search for details in alerts.json. 

• I just opened an issue with the enhancement request to let Integratord ingest alerts bigger than 65536B. 
• Another workaround for you should be increasing the OS_MAXSTR value and recompiling the manager. You should be able to pass the full alert to Integratord.

I hope it helps. Greetings, 

JP Sáez

[Juan Pablo Saez]

Hello again Tanel,

Here you can check the progress of the feature request https://github.com/wazuh/wazuh/issues/4143

Greetings, JP Sáez