On Thu, Jul 7, 2016 at 10:16 AM, Dominik <[email protected]> wrote:
> Hi Jose,
> thanks - this seems to be the way to go. I managed to get auditd-messages to
> the ossec-server.
>
> However, my system seems to be setup differently.
>
> bin/ossec-logtest -v
> 2016/07/07 16:05:00 ossec-testrule: INFO: Reading local decoder file.
> 2016/07/07 16:05:00 ossec-testrule: INFO: Started (pid: 10047).
> ossec-testrule: Type one log per line.
>
> type=SYSCALL msg=audit(1467900136.633:792): arch=c000003e syscall=59
> success=yes exit=0 a0=1a1ca28 a1=1a
> 29ac8 a2=1a22008 a3=598 items=2 ppid=2872 pid=2883 auid=1001 uid=0 gid=0
> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="ls"
> exe="/bin/ls" key=(null)
>
> **Phase 1: Completed pre-decoding.
>        full event: 'type=SYSCALL msg=audit(1467900136.633:792):
> arch=c000003e syscall=59 success=yes exit=0 a0=1a1ca28 a1=1a'
>        hostname: 'Birnbaum'
>        program_name: '(null)'
>        log: 'type=SYSCALL msg=audit(1467900136.633:792): arch=c000003e
> syscall=59 success=yes exit=0 a0=1a1ca28 a1=1a'
>
> **Phase 2: Completed decoding.
>        decoder: 'auditd'
>
> **Rule debugging:
>     Trying rule: 1 - Generic template for all syslog rules.
>        *Rule 1 matched.
>        *Trying child rules.
>     <long list of Trying rule: ...>
>
> It seems that you have different decoders and filters. No rule exists with a
> rule number 80720
>
> grep -r 80720 rules/*
>
> does not result in a record.
>
> Im running the current ossec available from
> deb http://ossec.wazuh.com/repos/apt/ubuntu trusty main
>
> What do I need to adjust?
>

Looks like this is part of the Wazuh ruleset:
https://github.com/wazuh/ossec-rules/blob/master/rules-decoders/ossec/rules/auditd_rules.xml

> Greetings
> Dominik
>
>
>
> Am Donnerstag, 7. Juli 2016 15:38:23 UTC+2 schrieb jose:
>>
>> Hi Dominik
>>
>> Maybe the best way is log all in auditd,
>>
>> Add these 2 lines to /etc/audit/audit.rules:
>>
>> -a exit,always -F arch=b64 -F euid=0 -S execve
>> -a exit,always -F arch=b32 -F euid=0 -S execve
>>
>> You will have logs like the next under audit.log
>>
>> type=SYSCALL msg=audit(1467905123.502:361): arch=c000003e syscall=59
>> success=yes exit=0 a0=2567ff0 a1=2567f70 a2=2571bf0 a3=7ffcbac478f0 items=2
>> ppid=1513 pid=1526 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=pts1 ses=3 comm="ls" exe="/bin/ls"
>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
>>
>> if you do a ossec-logtest
>>
>> type=SYSCALL msg=audit(1467905123.502:361): arch=c000003e syscall=59
>> success=yes exit=0 a0=2567ff0 a1=2567f70 a2=2571bf0 a3=7ffcbac478f0 items=2
>> ppid=1513 pid=1526 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=pts1 ses=3 comm="ls" exe="/bin/ls"
>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
>>
>>
>> **Phase 1: Completed pre-decoding.
>>        full event: 'type=SYSCALL msg=audit(1467905123.502:361):
>> arch=c000003e syscall=59 success=yes exit=0 a0=2567ff0 a1=2567f70 a2=2571bf0
>> a3=7ffcbac478f0 items=2 ppid=1513 pid=1526 auid=0 uid=0 gid=0 euid=0 suid=0
>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=3 comm="ls" exe="/bin/ls"
>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)'
>>        hostname: 'centos67'
>>        program_name: '(null)'
>>        log: 'type=SYSCALL msg=audit(1467905123.502:361): arch=c000003e
>> syscall=59 success=yes exit=0 a0=2567ff0 a1=2567f70 a2=2571bf0
>> a3=7ffcbac478f0 items=2 ppid=1513 pid=1526 auid=0 uid=0 gid=0 euid=0 suid=0
>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=3 comm="ls" exe="/bin/ls"
>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)'
>>
>> **Phase 2: Completed decoding.
>>        decoder: 'auditd'
>>        action: 'SYSCALL'
>>        id: '361'
>>        proto: '59'
>>        status: 'yes'
>>        dstuser: '0'
>>        url: '3'
>>        extra_data: '/bin/ls'
>>
>> **Phase 3: Completed filtering (rules).
>>        Rule id: '80720'
>>        Level: '0'
>>        Description: 'Auditd: system call to the kernel'
>>
>>
>> So you need to create a child rule to match with dstuser: '0' in your
>> local_rules.xml
>>
>>   <rule id="xxxxx" level="10">
>>     <if_sid>80720</if_sid>
>>      <user>0</user>
>>     <description>Root command</description>
>>   </rule>
>>
>>
>>
>> Regards
>> -----------------------
>> Jose Luis Ruiz
>> Wazuh Inc.
>> [email protected]
>>
>> On July 7, 2016 at 3:19:10 PM, Dominik ([email protected]) wrote:
>>
>> Hi there,
>> I've been using ossec for about half a year now and I'm very happy about
>> it. Thanks for this great tool.
>>
>> I have a linux client on which I need to monitor all activities
>> performed as root. My thought is to watch /root/.bash_history and create
>> alerts on changes in the file.
>>
>> So I created a configuration to watch this file in the clients ossec.conf:
>>
>>  <localfile>
>>    <log_format>syslog</log_format>
>>    <location>/root/.bash_history</location>
>>  </localfile>
>>
>>
>>
>> This works well and creates entries in the log archives of the
>> ossec-sever e.g.:
>>
>> 2016 Jul 07 11:06:28 (TheClient) xx.xx.71.109->/root/.bash_history top
>>
>>
>>
>> I also want to generate alerts.
>>
>> If I understand correctly, the next steps will be to create a decoder
>> and a rule. I tried with the following decoder in
>>
>> etc/decoder_local.xml
>>
>>
>>  <decoder name="bash_history">
>>     <program_name>.bash_history</program_name>
>>  </decoder>
>>
>>
>> and a rule in
>>
>> rules/local_rules.xml
>>
>>
>>
>>
>>  <rule id="105412" level="8">
>>    <decoded_as>bash_history</decoded_as>
>>    <description>Command run as root extracted from
>> bash_history</description>
>>  </rule>
>>
>>
>>
>> This does not create allerts. Thus I used ossec-logtest to see if things
>> go alright:
>>
>>
>> bin/ossec-logtest -v
>> 2016/07/07 14:40:56 ossec-testrule: INFO: Reading local decoder file.
>> 2016/07/07 14:40:56 ossec-testrule: INFO: Started (pid: 4092).
>> ossec-testrule: Type one log per line.
>>
>> 2016 Jul 07 11:06:28 (TheClient) xx.xx.71.109->/root/.bash_history top
>>
>> **Phase 1: Completed pre-decoding.
>>      full event: '2016 Jul 07 11:06:28 (TheClient)
>> xx.xx.71.109->/root/.bash_history top'
>>      hostname: 'ossec-server'
>>      program_name: '(null)'
>>      log: '2016 Jul 07 11:06:28 (TheClient)
>> xx.xx.71.109->/root/.bash_history top'
>>
>> **Phase 2: Completed decoding.
>>     No decoder matched.
>>
>> **Rule debugging:
>>     Trying rule: 1 - Generic template for all syslog rules.
>>       *Rule 1 matched.
>>       *Trying child rules.
>>     Trying rule: 5500 - Grouping of the pam_unix rules.
>> <and so on...>
>>
>>
>> Obviously, the decoder I'm using is not working. Also pre-decoding does
>> not extract information from this log entry.
>>
>> How do I advance to get alerts from the root activities extracted from
>> bash_history?
>>
>> According to the log-archive, OSSEC knows the origin of the message
>> (/root/.bash_history). Is this available to the decoder or to a rule?
>>
>> Im also not sure, this is the best approach to observe activities of the
>> root user. Hints are welcome.
>>
>> Greetings
>> Dominik
>>
>> --
>>
>> ---
>> 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