search

ossec / ossec-hids

OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.
http://www.ossec.net
Other
4.49k stars 1.04k forks source link

Active-response grep for full alert is wrong #1126

Closed rink92 closed 5 years ago

rink92 commented 7 years ago

I'm fairly certain that either: A. The way the full alert is retrieved in active response scripts (such as ossec-slack and ossec-tweeter) is wrong, or B. The "full alert" is not what I expect it to be

Here is an example of what I'm talking about. In the above example, it appears that the alertid is "1185590911.25916", however the retrieved alert does not match that alertid.
This issue can be replicated using this file and the alert id "1495121200.928132117". I would expect to get back the following (taking into consideration that the script as-is filters out the "Src IP" and "User" lines)

** Alert 1495121200.928132117: - syslog,paloalto-threat
2017 May 18 11:26:40 (centos.mdc.mlhs.org) 192.168.1.1->/var/log/paloalto_panarama.log
Rule: 102060 (level 8) -> 'Palo Alto Threat match level: informational'
Dst IP: 192.168.1.1
ALERT MESSAGE

But instead I get back:

Rule: 102060 (level 8) -> 'Palo Alto Threat match level: informational'
Dst IP: 192.168.1.1
ALERT MESSAGE

** Alert 1495121200.928131320: - syslog,paloalto-threat
--
Rule: 102060 (level 8) -> 'Palo Alto Threat match level: informational'
Dst IP: 192.168.1.1
ALERT MESSAGE

** Alert 1495121200.928132117: - syslog,paloalto-threat
--
Rule: 102060 (level 8) -> 'Palo Alto Threat match level: informational'
Dst IP: 192.168.1.1
ALERT MESSAGE

** Alert 1495121200.928132921: - syslog,paloalto-threat
--
Rule: 102060 (level 8) -> 'Palo Alto Threat match level: informational'
Dst IP: 192.168.1.1
ALERT MESSAGE

** Alert 1495121200.928133681: - syslog,paloalto-threat
--
Rule: 102060 (level 8) -> 'Palo Alto Threat match level: informational'
Dst IP: 192.168.1.1
ALERT MESSAGE

This issue has been touched on here and here.

I already have a fix for this, and will be more than happy to provide it, but before opening a pull request I wanted to first check that the behaviour described above is in fact undesired.

ddpbsd commented 7 years ago

I don't, and won't, use either of those scripts. Anyone who cares what they output can offer up a solution. I know twitter limits the number of characters in a tweet though (140? 160?), so the truncated alert info might be because of that.

rink92 commented 7 years ago

I'll put in a pull request for the fix I have - just wanted to check if I had misunderstood the intended functionality of those scripts. Thanks!

ddpbsd commented 7 years ago

They are there so people can post their alerts to those platforms. As I said, I don't use them so how they work exactly doesn't matter to me. I'm glad a user wants to take care of them. :-)

nbuuck commented 7 years ago

I've fixed and adjusted ossec-slack.sh in https://github.com/nbuuck/ossec-hids/commit/f42a4e927adfcd789490e28cd9c47ccee6c33adc because of this behavior and, more importantly, an issue that causes the script to repeat alerts when multiple alerts fire at the same timestamp. Is this worth a pull request to https://github.com/ossec/ossec-hids?

rink92 commented 7 years ago

Oops, I forgot about this! I've taken a look at your change @nbuuck and commented there, including the solution we use. Thanks!