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.

Reply via email to