The matching does not seem to work regardless of what I put it in.

On Mon, May 10, 2010 at 5:06 PM, dan (ddp) <[email protected]> wrote:

> The ossec regex rules are in the wiki or the manual, can't remember which.
> I prefer using matches where possible, regex if necessary. Ossec's
> pretty fast though, so regex is probably ok.
>
> On Mon, May 10, 2010 at 9:42 AM, Nicholas Ritter <[email protected]>
> wrote:
> > 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) <[email protected]> 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 <[email protected]>
> >> 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) <[email protected]> wrote:
> >> >>
> >> >> Can you give us log samples?
> >> >>
> >> >> On Thu, May 6, 2010 at 3:38 PM, Nicholas Ritter <
> [email protected]>
> >> >> wrote:
> >> >> > I correct my email, I meant rule 5503.
> >> >> >
> >> >> > On Thu, May 6, 2010 at 2:33 PM, Nicholas Ritter
> >> >> > <[email protected]>
> >> >> > 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?
> >> >> >>
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>

Reply via email to