Matching certain rule crashes the system

[Mone]

Hi,

I'm fairly new to OSSEC. I have a local OSSEC installation on a ubuntu machine that acts as an apache web server. I'm trying to identify fatal PHP errors through the apache error log, and for this purpose I created a local rule (var/ossec/rules/local_rules.xml) as follows:

Code: Select all

 
  <rule id="100103" level="10" ignore="60">
    <if_sid>30301</if_sid>
    <pcre2> Fatal error: </pcre2>
    <description>Apache fatal error.</description>
  </rule>

Adding the rule works well, I'm able to start OSSEC without it complaining about syntax error in the configuration.

But when I test the rule by triggering a fatal error in the apache log the whole machine becomes unresponsive after a few seconds. The web server dies and it is not even possible to do remote login to the machine.
After a while, the rule seems to have been triggered because it is correctly sending a notification email about the error).

I have looked through the ossec.log file but only found the following relevant lines:
2022/07/06 10:03:18 ossec-analysisd(1210): ERROR: Queue '/queue/alerts/ar' not accessible: 'Queue not found'.
2022/07/06 10:03:18 ossec-analysisd(1301): ERROR: Unable to connect to active response queue.
2022/07/06 10:03:18 ossec-analysisd: INFO: Connected to '/queue/alerts/execq' (exec queue)
2022/07/06 10:03:29 ossec-maild: DEBUG: Running OS_Sendmail()
2022/07/06 10:03:42 ossec-execd: INFO: Active response command not present: '/var/ossec/active-response/bin/restart-ossec.cmd'. Not using it on this system.
2022/07/06 10:03:54 ossec-maild: DEBUG: Running OS_Sendmail()
2022/07/06 10:04:01 ossec-syscheckd: INFO: Starting syscheck scan (forwarding database).
2022/07/06 10:04:01 ossec-syscheckd: INFO: Starting syscheck database (pre-scan).

Other local rules that I have added work as intended, however, those have all been added to eliminate false positives, i.e. decreasing the amount of triggered errors.

Would be really happy to get some pointers about how to troubleshoot this further.

Best regards

[cponton]

Have you taken a look into the active response log if that is enabled? /var/ossec/logs/active-responses.log

[Mone]

Yes, active response is on, and it looks like from the log that I have been blocking my own IP when triggering the rule...
That actually explains a lot. Thanks for the help!

Now I have to figure out how to not block an IP for triggering this error a single time. Any suggestions on which predefined rule I might look for?

Best regards

[mikeshinn]

The active-responses.log file should tell you the rule that was triggered, for example:

Tue Jul 12 12:32:21 PDT 2022 /var/ossec/active-response/bin/host-deny.sh add - 1.2.3.4 1657654341.8325652 477641

477641 is the rule that was triggered.

[Mone]

Wonderful, thanks a lot!

My solution to the problem was to change the level to 5 instead of 10 for the rule, as alerts of level 6 and above (default setting) triggered a block of IP.

[OtisReber]

As alerts of level 6 and higher (the default value) resulted in an IP block, I decided to modify the level for the rule from 10 to 5 as a workaround