Hi Christina, 1) I think you could create a child rule of 5503 (if_sid) with level 0. Then, use regex to match a user with backslash. In this way, you are ignoring alert 5503 if the user contains a backslash (or anything you put in the regex). You could do the same with alert 5551. 2) <user> is OS_Match/sregex Syntax <http://ossec-docs.readthedocs.io/en/latest/syntax/regex.html#os-match-sregex-syntax> . 3) There is no "negative match". This is the syntax: http://ossec-docs.readthedocs.io/en/latest/syntax/regex.html. Just for srcip, dstip you can user "!". 4) A child rule of 5551 with level 0 and with the regex for your user it should solve your issue.
Regards. On Wednesday, October 5, 2016 at 6:53:49 PM UTC+2, linuxfancy wrote: > > Hello all, > > My problem: > Erroneous messages are causing rule 5503 (pam_unix authentication failure) > to trigger even when the login was actually successful. This is not > OSSEC's fault - it is due to the pam stack being configured to check both > pam_unix and another module which performs AD authentication. So a > successful AD login still causes a spurious pam_unix failure to be written > into the logs, e.g. > > Oct 5 16:03:22 my-server sudo: pam_unix(sudo:auth): authentication > failure; logname=AD\cplummer1 uid=1010101010 euid=0 tty=/dev/pts/1 > ruser=AD\cplummer1 rhost= user=AD\cplummer1 > > or > > Oct 5 16:03:20 my-server sshd[10362]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=/dev/pts/1 ruser= rhost= > user=AD\cplummer1 > > This isn't a major problem on its own, since rule 5503 is only level 5 and > I only alert on level 7 and higher. However, rule 5551 matches on 6 > instances of 5503 from the same source IP within 180 seconds: > > <rule id="5551" level="10" frequency="6" timeframe="180"> > <if_matched_sid>5503</if_matched_sid> > <same_source_ip /> > <description>Multiple failed logins in a small period of > time.</description> > <group>authentication_failures,</group> > </rule> > > I suppose I could create a local rule using <if_sid>5551</if_sid> and set > the level to 0 if the user= contains a backslash. But I think it makes > more sense to prevent 5503 from triggering at all in these cases, so the > spurious messages don't add to the count. > > So, my questions: > 1) Is there a way to overwrite 5503 (using a single rule) to match as it > does today EXCEPT when the user name contains a backslash? I couldn't tell > from the online docs whether it is possible to have multiple conditions > ANDed in a single rule. > > 2) Is it possible to use regex syntax for the <user> attribute to match > any string containing a backslash? Or would I have to use something like > <regex>user=\S*\\</regex> instead? > > 3) Is it possible to perform a negative match in either regex or match > syntax? > > 4) What's the best way to do this? Since I think the answers to 1-3 are > "no", it seems like the only way to do what I am looking for would be to > create a local rule (e.g. 105503) using <if_sid>5503</if_sid>, and then > overwrite 5551 with <if_matched_sid>105503</if_matched_sid> instead. > > Thanks, > Christina > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
