The two different sets of log entry samples came from two different versions of Linux. The remote servers are using spitting out the first log entries when the remote servers are RHEL v4 based (I have not tested RHEL v5.)
The local ossec management server, that all the agents talk to, is running CentOS 5.4 and the rules I wrote are working. And other remote CentOS 5 systems are spitting out the same log entries. I will change the matching string to match more...I should maybe write a second set of rules to match the RHEL su differences and see what happens. Is a <match> appropriate, or should <regex> be used, and when do I need to be concerned about escaping characters such as parentheses? On Fri, May 7, 2010 at 4:28 PM, dan (ddp) <ddp...@gmail.com> wrote: > Running two of the logs through ossec-logtest shows a few differences: > May 7 09:50:46 Server su(pam_unix)[17639]: authentication failure; > logname=username uid=500 euid=0 tty=pts/0 ruser=username rhost= > user=root > > > **Phase 1: Completed pre-decoding. > full event: 'May 7 09:50:46 Server su(pam_unix)[17639]: > authentication failure; logname=username uid=500 euid=0 tty=pts/0 > ruser=username rhost= user=root' > hostname: 'Server' > program_name: 'su(pam_unix)' > log: 'authentication failure; logname=username uid=500 euid=0 > tty=pts/0 ruser=username rhost= user=root' > > **Phase 2: Completed decoding. > decoder: 'pam' > > **Phase 3: Completed filtering (rules). > Rule id: '5503' > Level: '5' > Description: 'User login failed.' > **Alert to be generated. > > > May 7 09:53:29 server su: pam_unix(su-l:auth): authentication > failure; logname=username uid=504 euid=0 tty=pts/0 ruser=username > rhost= user=root > > > **Phase 1: Completed pre-decoding. > full event: 'May 7 09:53:29 server su: pam_unix(su-l:auth): > authentication failure; logname=username uid=504 euid=0 tty=pts/0 > ruser=username rhost= user=root' > hostname: 'server' > program_name: 'su' > log: 'pam_unix(su-l:auth): authentication failure; > logname=username uid=504 euid=0 tty=pts/0 ruser=username rhost= > user=root' > > **Phase 2: Completed decoding. > decoder: 'pam' > > **Phase 3: Completed filtering (rules). > Rule id: '100003' > Level: '9' > Description: 'SU session to root attempted.' > **Alert to be generated. > > Look at the program_name field: 'su(pam_unix)' for the first and 'su' > for the second. The first alert comes through as rule 5503 because the > log line does not match <match>su</match>, the second log does though. > So that might be part of the problem. > > Does the server use the second log message (pam_unix(su-l:auth)? And > the remote machines the first? > > On Fri, May 7, 2010 at 11:16 AM, Nicholas Ritter <ritter6...@gmail.com> > wrote: > > I did some digging, and gained more insight into what is going on. It > > appears that CentOS and RHEL trigger alarms differently because of how su > is > > setup on the systems out of the box. But because of the way the rules > match > > (I think), I have trouble change the rule config with having to modify > the > > rules that come with OSSEC (which would break upstream updates.) I > verified > > this by looking at the difference in the way SU logs on both systems, and > > the alarms that are generated. I then added some rules to local_rules.xml > > which fixed the local OSSEC server but the local rules don't seem to be > run > > against remote OSSEC agents. I may be doing something wrong with getting > my > > custom rules to execute against the remote agents events. My custom rules > > work against the ossec server (which is CentOS based,) but are not > > running/working against the remote centos and remote RHEL systems, am I > not > > sticking the rules in the right place? > > > > > > Here is some background information that Dan requested, and that I should > I > > have put it in to start with (my apologies.) > > > > > > Log from RHEL 4 based system for failed SU activity: > > > > (/var/log/messages): > > > > May 7 09:50:46 Server su(pam_unix)[17639]: authentication failure; > > logname=username uid=500 euid=0 tty=pts/0 ruser=username rhost= > user=root > > > > > > Assoiated OSSEC 2.4.1 alert: > > > > ** Alert 1273243848.10327129: - pam,syslog,authentication_failed, > > 2010 May 07 09:50:48 (Sumatra.americantv.com) > 10.80.1.101->/var/log/messages > > Rule: 5503 (level 5) -> 'User login failed.' > > Src IP: (none) > > User: (none) > > May 7 09:50:46 Server su(pam_unix)[17639]: authentication failure; > > logname=username uid=500 euid=0 tty=pts/0 ruser=username rhost= > user=root > > > > > > > > Log from RHEL 4 based system for successfull SU activity: > > > > (/var/log/messages): > > > > May 7 09:44:36 Server su(pam_unix)[17144]: session opened for user root > by > > username(uid=500) > > May 7 09:45:16 Server su(pam_unix)[17144]: session closed for user root > > > > > > > > > > > > > > > > > > Log from CentOS 5.4 based system for failed SU activity: > > > > (/var/log/secure): > > > > May 7 09:53:29 server su: pam_unix(su-l:auth): authentication failure; > > logname=username uid=504 euid=0 tty=pts/0 ruser=username rhost= > user=root > > > > > > Associated OSSEC 2.4.1 alerts: > > > > ** Alert 1273244009.10329603: mail - pam,syslog,authentication_failure, > > 2010 May 07 09:53:29 server->/var/log/secure > > Rule: 100003 (level 9) -> 'SU session to root attempted.' > > Src IP: (none) > > User: (none) > > May 7 09:53:29 server su: pam_unix(su-l:auth): authentication failure; > > logname=username uid=504 euid=0 tty=pts/0 ruser=username rhost= > user=root > > > > > > Log from CentOS 5.4 based system for successfull SU activity: > > > > (/var/log/secure): > > > > May 7 09:53:36 server su: pam_unix(su-l:session): session opened for > user > > root by username(uid=504) > > May 7 09:53:40 server su: pam_unix(su-l:session): session closed for > user > > root > > > > > > Associated OSSEC 2.4.1 alerts: > > > > > > ** Alert 1273244017.10331731: mail - pam,syslog,authentication_success, > > 2010 May 07 09:53:37 server->/var/log/secure > > Rule: 100004 (level 9) -> 'SU session to root openned.' > > Src IP: (none) > > User: (none) > > May 7 09:53:36 server su: pam_unix(su-l:session): session opened for > user > > root by username(uid=504) > > > > ** Alert 1273243999.10328437: mail - pam,syslog,authentication_success, > > 2010 May 07 09:53:40 server->/var/log/secure > > Rule: 100005 (level 9) -> 'SU session to root closed.' > > Src IP: (none) > > User: (none) > > May 7 09:53:40 server su: pam_unix(su-l:session): session closed for > user > > root > > > > > > > > Rules I added to local_rules.xml: > > > > <group name="pam,syslog,"> > > > > <!-- Catch and treat su events logged by PAM on CentOS/RHEL --> > > <rule id="100002" level="0" noalert="1"> > > <if_sid>5500</if_sid> > > <match>su</match> > > </rule> > > > > <rule id="100003" level="9"> > > <if_sid>100002</if_sid> > > <match>authentication fail</match> > > <description>SU session to root attempted.</description> > > <group>authentication_failure,</group> > > </rule> > > > > <rule id="100004" level="9"> > > <if_sid>100002</if_sid> > > <match>session opened</match> > > <description>SU session to root openned.</description> > > <group>authentication_success,</group> > > </rule> > > > > <rule id="100005" level="9"> > > <if_sid>100002</if_sid> > > <match>session closed</match> > > <description>SU session to root closed.</description> > > <group>authentication_success,</group> > > </rule> > > > > </group> > > > > > > > > > > > > On Thu, May 6, 2010 at 4:48 PM, dan (ddp) <ddp...@gmail.com> wrote: > >> > >> Can you give us log samples? > >> > >> On Thu, May 6, 2010 at 3:38 PM, Nicholas Ritter <ritter6...@gmail.com> > >> wrote: > >> > I correct my email, I meant rule 5503. > >> > > >> > On Thu, May 6, 2010 at 2:33 PM, Nicholas Ritter <ritter6...@gmail.com > > > >> > wrote: > >> >> > >> >> Has anyone noticed issues with OSSEC 2.4.1 when alerting on SU > related > >> >> events from Linux based hosts? Our Solaris boxes are fine, but I > >> >> noticed > >> >> that when an SU session (say su to root) on a linux box occurs, an > >> >> alert is > >> >> tripped (rule id 5303) but something doesn't seem right because 5303 > is > >> >> a > >> >> successful change UID to root rule, but this is a failure. I think > the > >> >> regex > >> >> might be to blame because the first regex for the rule is not in the > >> >> log > >> >> entry, but the second regex appears to match. > >> >> > >> >> Anyone else seeing this? > >> >> > >> > > >> > > > > > >
