OSSEC Ignore Alert

Question

I have OSSEC 2.94 setup and running on CentOS7. I have it sending a emails upon qualifying alert conditions. Everything appears to be functioning properly with regards to sending alerts. However, each night as part of a backup process, one server scp's a file to another server. Thus, each morning I have an alert about this login.

I have been trying, for days, without any success, to ignore that one alert. Meaning, write a OSSEC rule to not send an alert upon that one expected login.

The alert I am attempting to ignore is:

** Alert 1535623261.244876: mail  - pam,syslog,authentication_success,
2018 Aug 30 10:01:01 (myserver.mydomain.com) my.public.ip.addy ->/var/log/secure
Rule: 5501 (level 5) -> 'Login session opened.'
Aug 30 09:59:50 myhostname sshd[1611]: pam_unix(sshd:session): session opened for user dbBackupUser by (uid=10)

I have been attempting to write rules into /var/ossec/rules/local_rules.xml - such as:

<group name="pam,syslog,authentication_success,">
  <rule id="104040" level="0">
    <if_sid>5501</if_sid>
    <user>dbBackupUser</user>
    <options>no_email_alert</options>
    <description>Attempt to ignore sshd logins by dbBackupUser.</description>
  </rule>
</group> <!-- pam,syslog,authentication_success, -->

...I have tried many variations of this rule. This is only one example.

Can anyone point me towards what I may be doing wrong?

I was using this example I found as my basis:

  <!-- This example will ignore failed ssh logins for the user name XYZABC.
    -->
  <!--
  <rule id="100020" level="0">
    <if_sid>5711</if_sid>
    <user>XYZABC</user>
    <description>Example of rule that will ignore sshd </description>
    <description>failed logins for user XYZABC.</description>
  </rule>
  -->

Ultimately I would like for the ignore rule to examine the src IP as well as the username, but I have not been able to get it to work at all just yet.

Thanks!

Answer 1

I was working on something like that and found that user wasn't picking up with my decoder. I ended up switching to using a match instead.

If you run the log entry through ossec-logtest you should be able to see if user is getting set to anything.