Hey Michael,
Thanks for doing this. So this is what I get when I run ossec-logtest:
**Phase 1: Completed pre-decoding.
full event: 'type=USER_ACCT msg=audit(1310592861.936:1222):
user pid=24675 uid=0 auid=501 ses=188
subj=system_u:system_r:unconfined_t:s0 msg='op=PAM:accounting
acct="jplee3" exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=pts/5
res=success)''
hostname: 'irprinfntp1'
program_name: '(null)'
log: 'type=USER_ACCT msg=audit(1310592861.936:1222): user
pid=24675 uid=0 auid=501 ses=188
subj=system_u:system_r:unconfined_t:s0 msg='op=PAM:accounting
acct="jplee3" exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=pts/5
res=success)''
**Phase 2: Completed decoding.
decoder: 'auditd'
action: 'USER_ACCT'
id: '1222'
extra_data: '/usr/bin/sudo'
srcip: '?'
status: 'success'
I left out Phase 3 as I created an auditd based rule from the
simplified decoder I created prior. I guess I'm just curious about the
decoder that was identified in Phase 2. Shouldn't it have decoded my
log message as auditd-user?
On Jun 27, 4:45 pm, Michael Starks <[email protected]>
wrote:
> On 06/26/2011 09:48 AM, Michael Starks wrote:
>
> > Here is the current rev (available for one month from the date of this
> > post):http://pastebin.com/8R6S5L1N
>
> Woops, copy and paste error. The auditd-path decoder should look this this:
>
> <!-- path (will only decode if name is not null)-->
> <decoder name="auditd-path">
> <parent>auditd</parent>
> <prematch offset="after_parent">^PATH </prematch>
> <regex offset="after_parent">^(PATH)
> msg=audit\(\d\d\d\d\d\d\d\d\d\d.\d\d\d:(\d+)\): item=\d+ name="(\.+)"
> inode=\d+ dev=\S+ mode=\d+ ouid=\d+ ogid=\d+ rdev=\S+</regex>
> <order>action,id,extra_data</order>
> </decoder>
