hi Nikolay,
I think the simplest solution to this problem is to use two Pair rules
instead of one EventGroup3, since Pair rules have the ability to share
match variable data between two regular expressions. This will ensure
that the regular expressions for CWD and PATH events will actually
match events for given timestamp and event id. Also, unlike
EventGroup3, the Pair rule expects events to occur in specific order
which matches your scenario better. The following set of two rules
keeps elaborating the original SYSCALL event with additional fields:
type=Pair
ptype=RegExp
pattern=^type=SYSCALL msg=audit\((\d+\.\d+):(\d+)\): arch=(\w+)
syscall=(\d+) success=(\w+).+?ppid=(\d+) pid=(\d+) auid=(\d+)
uid=(\d+) gid=(\d+) euid=(\d+) suid=(\d+) fsuid=(\d+) egid=(\d+)
sgid=(\d+) fsgid=(\d+) tty=(\w+) ses=\d+ comm="(\w+)" exe="(.+?)"
key=\((.+?)\)$
varmap=time=1; event_id=2; arch=3; syscall=4; success=5; ppid=6;
pid=7; auid=8; uid=9; gid=10; euid=11; suid=12; fsuid=13; egid=14;
sgid=15; fsgid=16; tty=17; comm=18; exe=19; key=20
desc=wait for CWD event for $+{time} $+{event_id}
action=none
ptype2=RegExp
pattern2=type=CWD msg=audit\($+{time}:$+{event_id}\):\s+cwd="(?<cwd>.+?)"
desc2=CWD event seen
action2=event %0 cwd="$+{cwd}"
window=10
type=Pair
ptype=RegExp
pattern=^type=SYSCALL msg=audit\((\d+\.\d+):(\d+)\): arch=(\w+)
syscall=(\d+) success=(\w+).+?ppid=(\d+) pid=(\d+) auid=(\d+)
uid=(\d+) gid=(\d+) euid=(\d+) suid=(\d+) fsuid=(\d+) egid=(\d+)
sgid=(\d+) fsgid=(\d+) tty=(\w+) ses=\d+ comm="(\w+)" exe="(.+?)"
key=\((.+?)\) cwd="(?<cwd>.+?)"$
varmap=time=1; event_id=2; arch=3; syscall=4; success=5; ppid=6;
pid=7; auid=8; uid=9; gid=10; euid=11; suid=12; fsuid=13; egid=14;
sgid=15; fsgid=16; tty=17; comm=18; exe=19; key=20; cwd=21
desc=wait for PATH event for $+{time} $+{event_id}
action=none
ptype2=RegExp
pattern2=type=PATH msg=audit\($+{time}:$+{event_id}\): item=\d+
name="(?<obj_name>.+?)" (inode=|objtype=).*
desc2=PATH event seen
action2=event %0 obj_name=$+{obj_name}
window=10
As you can see, you don't need to set up any additional objects like
contexts, action list variables, or extra perl hashes. My apologies
for not integrating this solution with the rest of your ruleset. There
are other ways to potentially improve these rules -- for example, the
varmap statement can be completely dropped from both rules, since
named match variables can be easily created from regular expressions
in 'pattern' fields (like it is done in 'pattern2' fields).
kind regards,
risto
2016-11-16 19:38 GMT+02:00 Risto Vaarandi <[email protected]>:
> hi Nikolay,
>
> the Eventgroup3 rule that you have written might not be the best
> option for addressing this task, since it has been designed for
> scenarios where events can appear in arbitrary order. However, in the
> case of auditd records the three events should always have a fixed
> order: SYSCALL, CWD, PATH (any event order can of course change if you
> are collecting events from other hosts, since specific
> protocols/implementations can alter original event order).
>
> Also, your Eventgroup3 rule has one caveat -- since the SYSCALL event
> is always coming first, it will initialize the event correlation
> operation, and at that point all match variables are getting
> substituted (that includes the 'action' field). In the 'action' field,
> you have used variables $:{vcwd:cwd} and $+{obj_name}, but these
> variables do not have any values at the time of substitution. For the
> same reason, If the PATH event would come first, you would have only
> $+{obj_name} variable set, and all other variables without values.
> Also, if you store match variables into a pattern match cache with
> 'varmap' statement, they remain accessible during the current input
> line processing, and after all rules have been matched against the
> line, the pattern match cache is cleared. So there is no way to access
> the value of match variable $:{vcwd:cwd} from previous CWD event when
> sec is currently processing the PATH event.
>
> In order to address the matching of three events, there are several
> workarounds:
>
> 1) define count* fields for storing $+{cwd} and $+{obj_name} into
> contexts (e.g., count2=add PATH $+{obj_name} ), and extract the
> content of these contexts when the action is executed (e.g., copy PATH
> %obj_name). This approach works, since the contexts (unlike match
> variables) are persistent entities and disappear only when it is
> explicitly configured.
>
> 2) If the events are always appearing in the same order and no other
> events can appear in between them, these three events can be simply
> handled by one Single rule that uses the RegExp3 pattern (RegExp3
> matches three consecutive lines).
>
> 3) if the given three events are not always consecutive, you could try
> several other strategies like storing match variables into a Perl hash
> table and updating its content, until you have seen all three events.
>
> But before suggesting anything more concrete, how exactly are input
> events appearing? Are the events consecutive and always in the same
> order?
>
> kind regards,
> risto
>
> 2016-11-16 16:22 GMT+02:00 Nikolay Srebniuk
> <[email protected]>:
>> Hi Everybody,
>>
>> i'm struggling 2nd day to make this rule to be working, but no results.
>>
>> What I want to achieve:
>> 1. I have 3 auditd log messages: SYSCALL, CWD, PATH
>> 2. I want to correlate these messages by fields time_id and event_id
>> 3. Generate one correlate rules with:
>> a) all fields from SYSCALL message
>> b) with one filed (cwd) from CWD message
>> c) with one filed (name) from PATH message
>>
>> ISSUE:
>> 1. Only fields from SYSCALL message are inserting in CORRELATED event.
>> 2. Fileds from CWD and PATH are emptry
>>
>> Question:
>> How to get this to work? Kindly appreciate your help.
>>
>> Rule:
>> type=EventGroup3
>> ptype=RegExp
>> pattern=type=CWD msg=audit\((\d+\.\d+):(\d+)\):\s+cwd="(.+?)"
>> varmap=vcwd; time=1; event_id=2; cwd=3
>> ptype2=RegExp
>> pattern2=type=PATH msg=audit\((\d+\.\d+):(\d+)\): item=\d+ name="(.+?)"
>> (inode=|objtype=).*
>> varmap2= time=1; event_id=2; obj_name=3
>> ptype3=RegExp
>> pattern3=type=SYSCALL msg=audit\((\d+\.\d+):(\d+)\): arch=(.+?)
>> syscall=(\d+) success=(.+?).+?ppid=(\d+) pid=(\d+) auid=(\d+) uid=(\d+)
>> gid=(\d+) euid=(\d+) suid=(\d+) fsuid=(\d+) egid=(\d+) sgid=(\d+)
>> fsgid=(\d+) tty=(.+?) ses=\d+ comm="(.+?)" exe="(.+?)" key=\(.+?\)
>> varmap3= time=1; event_id=2; arch=3; syscall=4; success=5; ppid=6; pid=7;
>> auid=8; uid=9; gid=10; euid=11; suid=12; fsuid=13; egid=14; sgid=15;
>> fsgid=16; tty=17; comm=18; exe=19; key=20
>> desc=Rules matched $+{time}_$+{event_id}
>> action=create FINAL_MATCH_$+{time}_$+{event_id}; event type=SYSCALL
>> msg=audit($+{time}:$+{event_id}): arch=$+{arch} syscall=$+{syscall}
>> success=$+{success} ppid=$+{ppid} pid=$+{pid} auid=$+{auid} uid=$+{uid}
>> gid=$+{gid} euid=$+{euid} suid=$+{suid} fsuid=$+{fsuid} egid=$+{egid}
>> sgid=$+{sgid} fsgid=$+{fsgid} tty=$+{tty} comm=$+{comm} exe=$+{exe}
>> key=$+{key} cwd=$:{vcwd:cwd} obj_name=$+{obj_name}
>> init=create $+{time}_$+{event_id} 20
>> slide=delete $+{time}_$+{event_id}; reset 0
>> end=delete $+{time}_$+{event_id}
>> window=20
>>
>> Sec service configuration:
>> [Service]
>> Type=forking
>> PIDFile=/run/sec.pid
>> ExecStart=/usr/bin/sec --detach --pid=/run/sec.pid
>> --conf=/etc/sec/auditd-sec.conf --input=/var/log/audit/audit.log
>> --log=/var/log/sec.log --intevents --syslog=20 --debug=6
>> --dump=/tmp/sec_dump --bufsize=100
>>
>> Raw log input:
>> type=SYSCALL msg=audit(1479282206.600:23242): arch=c000003e syscall=2
>> success=yes exit=3 a0=7ffede744e2a a1=0 a2=0 a3=7ffede743d80 items=1
>> ppid=16533 pid=16670
>> auid=1003 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
>> ses=10 comm="tail" exe="/usr/bin/tail" key=(null)
>> type=CWD msg=audit(1479282206.600:23242): cwd="/home/user"
>> type=PATH msg=audit(1479282206.600:23242): item=0 name="/var/log/sec"
>> inode=16837888 dev=ca:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
>> objtype=NORMAL
>>
>>
>> --
>> Best regards,
>> Nikolay
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Simple-evcorr-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>>
------------------------------------------------------------------------------
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
