On Wed, Dec 31, 2014 at 12:39 PM, Christina Plummer <[email protected]> wrote:
> 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?
>

Perfect, thanks! I submitted pull request #474 on github to update this rule.

> 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.

-- 

--- 
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.

Reply via email to