Integrate Jira with Wazuh

[Khul Sat]

Hello,

I have been trying to integrate Jira with Wazuh. I followed the blog post and tried to replicate the configuration but somehow it is not doing anything.

Below is a snip from my configuration.

cat /var/ossec/etc/ossec.conf <!-- ### Integration with JIRA ### --> <integration> <name>custom-jira</name> <hook_url>https://myorg.atlassian.net/rest/api/3/issue/</hook_url> <api_key>m...@myorg.com:API-HASH</api_key> <level>10</level> <!-- <group>multiple_drops|authentication_failures</group> --> <alert_format>json</alert_format> </integration>

Here is the python script taken from the blog.

cat /var/ossec/integrations/custom-jira #!/var/ossec/framework/python/bin/python3 import sys import json import requests from requests.auth import HTTPBasicAuth # Read configuration parameters alert_file = open(sys.argv[1]) user = sys.argv[2].split(':')[0] api_key = sys.argv[2].split(':')[1] hook_url = sys.argv[3] # Read the alert file alert_json = json.loads(alert_file.read()) alert_file.close() # Extract issue fields alert_level = alert_json['rule']['level'] ruleid = alert_json['rule']['id'] description = alert_json['rule']['description'] agentid = alert_json['agent']['id'] agentname = alert_json['agent']['name'] agentip = alert_json['agent']['ip'] # path = alert_json['syscheck']['path'] # Set the project attributes ===> This section needs to be manually configured before running! project_key = 'WAZUH' # You can get this from the beggining of an issue key. For example, WS for issue key WS-5018 issuetypeid = '11000' # Check https://confluence.atlassian.com/jirakb/finding-the-id-for-issue-types-646186508.html. There's also an API endpoint to get it. # Generate request headers = {'content-type': 'application/json'} issue_data = { "update": {}, "fields": { "summary": 'Wazuh Alert: [' + description + ']', "issuetype": { "id": issuetypeid }, "project": { "key": project_key }, "description": { 'version': 1, 'type': 'doc', 'content': [ { "type": "paragraph", "content": [ { "text": '- State: ' + description + '\n- Rule ID: ' + str(ruleid) + '\n- Alert level: ' + str(alert_level) + '\n- Agent: ' + str(agentid) + ' ' + agentname, "type": "text" } ] } ], }, } } # Send the request response = requests.post(hook_url, data=json.dumps(issue_data), headers=headers, auth=(user, api_key)) print(json.dumps(json.loads(response.text), sort_keys=True, indent=4, separators=(",", ": "))) # <--- Uncomment this line for debugging sys.exit(0)

I enabled debugging from by uncommenting line from above script but I am not able to understand where the debug logs are getting printed.
I checked the permissions too which are as desired.

Executing the script gives below error -

sudo -u wazuh python /var/ossec/integrations/custom-jira Traceback (most recent call last): File "/var/ossec/integrations/custom-lentra-jira", line 5, in <module> import requests ImportError: No module named requests

Any guidance will be highly appreciated.

Thanks, KS

​

[Francisco Tuduri]

Hello Khul!

You need to install the python module requests. It is a dependency of this script so it needs to be previously installed.

You can install it with: pip install requests

Another thing to consider is that the article states that the script must "belong to the root user of the ossec group." That is outdated, since v4.3.0 it must be root user of the wazuh group.

So in your case you should run:

chmod 750 /var/ossec/integrations/custom-jira
chown root:wazuh /var/ossec/integrations/custom-jira

As a result your script should have the same user, group and permissions as the other integration scripts:

Let me know if you have any other problems with this.

Regards!

[Khul Sat]

Hi..
I just came here to update you and found that I have have got a reply! :)
Yeah.. the issue got fixed. Installed python-requests package using yum which did the job! May I request you to update the blog so that it can clearly say that python-requests package is a prerequisite. It will be helpful for non-coders like me.

Thank you again for your support!
KS

​

[Khul Sat]

Hi..

I have one query though:

It has been observed that if the same alert gets triggered multiple times, duplicate tickets get generated. Is there any way where such triggers get appended to single ticket rather than creating multiple tickets?

Timeframe could be 30 minutes or so.

Thanks, KS

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/djaONs4kUbM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/4453b76a-5b0f-4e9c-b316-df1835b62573n%40googlegroups.com.

[Khul Sat]

Requesting your help! Thanks.

[Francisco Tuduri]

Hello Khul!

Keep in mind that the article with the Jira integration is a demonstration of how to integrate external software using the integration functionality of Wazuh. The Jira integration script is provided as a sample with very simple functionality. The script receives the data of an alert, arranges that data to fit the Jira API and creates a Jira issue.

You can use the script as a starting point to add more functionality.

But before going in that direction you could analyze the alerts that are duplicated and see if some change in the ruleset could make it better.
Is it just a few rules that are causing this issue duplication? If they are just a few we could look into some custom rules to prevent calling the integration script repeatedly.

https://documentation.wazuh.com/current/user-manual/ruleset/custom.html
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules

The integration configuration could also be tweaked to be called on certain conditions only (rule id, rule group, event location, level):
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/integration.html

Regards!

[Khul Sat]

Greetings Francisco!

Thank you for sharing your thoughts.

I have created custom Nginx rules which will trigger the alerts for 4xx & 5xx error codes. The frequency of these web server log is high and hence trigger frequency is also high.

[Francisco Tuduri]

Hello Khul!

You could check the ignore option of the rule tag. For example <rule id="100020" level="10" ignore="600">

https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#rule

If this is not good for your use case, please share one of your custom rules that are causing this problem, any custom decoder(if necessary for the rule), and a few sample logs.

Regards!

[Khul Sat]

Thank you so much for your reply!

Just wanted to clear a confusion- How this ignore option will work?

Scenarios-

Multiple hits come from same source IP > Error code is 4xx.

Multiple hits come from same source IP > Error code is either 4xx or 5xx

Multiple hits come from various source IPs > Error code is same - 404.

Regards,

KS

[Francisco Tuduri]

Hi KS!

The ignore option works like this:
Let's say you have a rule with id "X" that has the ignore option set to "Y" seconds:
<rule id="X" ignore="Y" />

ignore="Y" makes the manager drop the current alert if less than Y seconds have passed since the last alert with the same rule ID, no matter the source agent.
This option works on a rule id basis.

The exact behavior of each scenario will depend on the active ruleset.

Let's say error code 4xx trips the rule id 100400, and that that rule has an ignore option set to 60 seconds and that it matches any source IP.
You will get one alert for rule 100400 the first time the rule is tripped, then for the following 60 seconds you will not get any alert for rule 100400, no matter the source IP.
However, if rule 100400 has a child rule that matches when the source IP is 5.5.5.5, even if alerts for 100400 are being ignored, the child rule will be evaluated and will fire an alert for the child rule.

Back to your scenarios:

"Multiple hits come from same source IP > Error code is 4xx."

You will get only one alert for the duration of the ignore time.

"Multiple hits come from same source IP > Error code is either 4xx or 5xx"

If error code 4xx/5xx fire the same alert then it is the same case as above. One alert for the duration of the ignore time.
If error code 4xx and 5xx trip different rules, you will get one alert for the first event that trips the rule for 4xx and one alert for the first event that trips the rule for 5xx.

"Multiple hits come from various source IPs > Error code is same - 404."

You will get only one alert for the duration of the ignore time.

That is assuming that the involved rules don't make any distinction on the source IP.
Keep in mind that you could change the ruleset by modifying the rules or by creating new child rules to exclude/include certain source IPs. So for example you could set the ignore option for error code 4xx only if the IP is 10.x.x.x. You would have to create a child rule (of the rule for 4xx) that matches those IPs, and set the ignore option on this new rule.

If you have any problems with this please include in your reply a sample of the log that is giving you problems and the rules that are being fired.

Regards!