This rule seems to work to match on logs both with and without the TSID:
<rule id="5402" level="3" overwrite="yes">
<if_sid>5400</if_sid>
<regex> ; USER=root ; COMMAND=| ; USER=root ; TSID=\S+ ;
COMMAND=</regex>
<description>Successful sudo to ROOT executed - custom1</description>
</rule>
Is this email sufficient, or would you like me to submit it another way?
Thanks,
Christina
On Wed, Dec 31, 2014 at 6:44 AM, dan (ddp) <[email protected]> wrote:
> On Tue, Dec 30, 2014 at 5:31 PM, Christina Plummer <[email protected]>
> wrote:
> > Update - this rule worked for me:
> > <rule id="105402" level="3">
> > <decoded_as>sudo</decoded_as>
> > <regex> ; USER=root ; TSID=\S+ ; COMMAND=</regex>
> > <description>Successful sudo to ROOT executed - custom</description>
> > </rule>
> >
> > Is this the correct approach? Or in this case would it be better to
> update
> > the OSSEC-included rule 5402 to accommodate both cases?
> >
>
> Either approach should work. For inclusion into OSSEC I'd probably combine
> them.
>
> >
> > On Tue, Dec 30, 2014 at 5:15 PM, Christina Plummer <[email protected]>
> > wrote:
> >>
> >> Hello all,
> >>
> >> I noticed while testing today that OSSEC (2.8.1) is failing to properly
> >> match on rule 5402 when the sudo log contains the TSID= field. This
> field
> >> is related to the log_output option, which I think was added in sudo-1.7
> >> (for use along with sudoreplay).
> >>
> >> From the sudoers manpage:
> >>
> >> log_output If set, sudo will run the command in a pseudo tty
> >> and
> >> log all output that is sent to the screen,
> similar
> >> to
> >> the script(1) command. If the standard output or
> >> stan-
> >> dard error is not connected to the user's tty,
> due
> >> to
> >> I/O redirection or because the command is part
> of a
> >> pipeline, that output is also captured and stored
> >> in
> >> separate log files.
> >>
> >> Output is logged to the directory specified by
> the
> >> iolog_dir option (/var/log/sudo-io by default)
> >> using a
> >> unique session ID that is included in the normal
> >> sudo
> >> log line, prefixed with "TSID=". The iolog_file
> >> option
> >> may be used to control the format of the session
> >> ID.
> >>
> >> Output logs may be viewed with the sudoreplay(8)
> >> util-
> >> ity, which can also be used to list or search the
> >> available logs.
> >>
> >> Here is an example log that is failing to match - it just stops after
> >> phase 2:
> >>
> >> Dec 30 19:36:11 rheltest sudo: cplummer : TTY=pts/2 ;
> PWD=/home/cplummer1
> >> ; USER=root ; TSID=0000UM ; COMMAND=/bin/bash
> >>
> >>
> >> **Phase 1: Completed pre-decoding.
> >> full event: 'Dec 30 19:36:11 rheltest sudo: cplummer : TTY=pts/2
> ;
> >> PWD=/home/cplummer ; USER=root ; TSID=0000UM ; COMMAND=/bin/bash'
> >> hostname: 'rheltest'
> >> program_name: 'sudo'
> >> log: 'cplummer : TTY=pts/2 ; PWD=/home/cplummer ; USER=root ;
> >> TSID=0000UM ; COMMAND=/bin/bash'
> >>
> >> **Phase 2: Completed decoding.
> >> decoder: 'sudo'
> >>
> >>
> >> When I remove the "TSID=0000UM ;" from the log, it matches properly.
> >>
> >> I can see the problem is in the rule definition itself assuming that the
> >> COMMAND= section will immediately follow the USER= section:
> >>
> >> <rule id="5402" level="3">
> >> <if_sid>5400</if_sid>
> >> <match> ; USER=root ; COMMAND=</match>
> >> <description>Successful sudo to ROOT executed</description>
> >> </rule>
> >>
> >>
> >> What is the correct way to fix? Should I just add a custom rule in
> >> local_rules.xml that is identical to 5402, except insert the TSID=
> section?
> >> I tried a few variations on this theme and it didn't seem to work, e.g.
> >>
> >> <rule id="105401" level="3">
> >> <decoded_as>sudo</decoded_as>
> >> <regex> ; USER=root ; TSID=\S ; COMMAND=</regex>
> >> <description>Successful sudo to ROOT executed -
> custom2</description>
> >> </rule>
> >>
> >> I'm still only getting to phase 2. I am wondering if I need to update
> the
> >> decoder as well (even though it does seem to be correctly decoding the
> log
> >> as sudo).
> >> But given that this feature of sudo has been around for awhile, might it
> >> be worthwhile to update the OSSEC-included rules/decoder instead of me
> just
> >> doing it locally?
> >>
> >> Thanks in advance,
> >> 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.
>
> --
>
> ---
> 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.
>
--
---
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.
